IBMサーバーがUEFIからOSへの起動に長い時間がかかる

IBM System x3620サーバーのペアを持っています。彼らは最終的には、オペレーティング・システムが引き継ぐポイントに達すると、これらのサーバーは罰金を行いますが、それはそれらを取る永遠に ...新fangled UEFIブートシステムを乗り越えるために良い5分ほどを。多分もっと。計時はしていませんが、待つ間に一杯のコーヒーを飲みに行くようなもので、戻ってきたときもそうです。

通常、これらをシャットダウンするのは、毎月のメンテナンスサイクル（通常はWindowsの更新のみ）のみです。組み込みのメンテナンス時間なので、余分な5分はSLAにカウントされず、大したことではありません。ただし、機能停止が発生する可能性がある場合は、その5分を元に戻したいと思います。先に進んで起動するように伝えるために何かできることはありますか？追加のブートオプションに関する限り、無効にできることがわかっているものはすべて無効にしています。

すべてのIBM uEFIマシンは、古くなったuEFI初期化とモジュールの起動後、レガシーBIOSエミュレーションが起動し、PCI-EオプションROMが実行されるなど、起動に時間がかかります。これは、すべてのIBM uEFIマシンで「正常」です-ブレードサーバーか標準ラックサーバーかに関係なく。

レガシーBIOSブート、オプションROMを無効にし、ブート順序を最適化して、通常はそのマシンをIBMが提供する最新のファームウェアレベルに保つことができます。

System X uEFIのレガシー実装は非常に遅いため、クライアントへのプラットフォームとしての販売を回避することすらできるかもしれません。

OSプロンプトが表示されるまでレガシーUSBキーブートを開始する時間をIBMから測定するのは、途方もなく長いです。私はSmartOS（すべてのインテント用のillumos / opensolaris派生物を使用しています。起動すると、実行され、Solaris 11のように動作します）は、puppy Linuxのように動作します。メモリ内のOS。 これは、レガシーブートのIBM uEFI実装の問題を実際に示しています。

  BEG：午後1:27:05（SmartOS USB 2.0 USBキーを開始）
  終了：午後1:33:38（SmartOSの実行に取り掛かった-読み取り275MB）
  ---
  TOOK：6:33（6分33秒-かなり遅い-わずか0.75MB /秒）

これは、UEFI実装が、読み取り中に大きなバッファーではなく、512バイトの読み取りのような小さなブロックサイズを使用するかのようです。OSに入ると、起動したUSBキーのパフォーマンスをベンチマークできます。IBMUEFIコードが8192ブロックサイズ以上の32768ブロックサイズを読み取れば、起動は非常に高速になります。

そのため、SmartOSオペレーティングシステムで、USBキーの512バイトから131072バイトまでのパフォーマンス特性を確認しました。8192ブロックサイズ（ブートされたOSで12.3 MB /秒）または32768ブロックサイズ（ブートされたOSで20.2 MB /秒）のどちらかが良い選択のようです。また、512ブロックサイズ（ブートされたOSでは0.64 MB /秒）と一致しているように見えます。これは、長いブーツで経験したように見える結果にかなり近いものです。

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 512 count = 524288
    524288 + 0レコード
    524288 + 0レコードアウト
    実数31分19.499秒
    => 00.64MB /秒。Solaris 11のようなSmartOS（これはIBM BIOSの起動速度です）

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144
    262144 + 0レコード
    262144 + 0レコードアウト
    実数1分39.989秒
    => 02.56MB /秒。Solaris 11のようなSmartOS

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 2048 count = 131072
    131072 + 0レコード
    131072 + 0レコードアウト
    実数0分50.215秒
    => 05.09MB /秒。Solaris 11のようなSmartOS

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 4096 count = 65536
    65536 + 0レコード
    65536 + 0レコードアウト
    実数0m33.056s
    => 07.74MB /秒。Solaris 11のようなSmartOS

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 8192 count = 32768
    32768 + 0レコード
    32768 + 0レコードアウト
    実数0m20.757s
    => 12.33MB /秒。Solaris 11のようなSmartOS

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 32768 count = 8192
    8192 + 0レコード
    8192 + 0レコードアウト
    実数0分12.785秒
    => 20.02MB /秒。Solaris 11のようなSmartOS（Win7ボックスで予想され、見られるように）

時間dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 131072 count = 2048
    2048 + 0レコード
    2048 + 0レコードアウト
    実数0m11.532s
    => 22.19MB /秒。Solaris 11のようなSmartOS

UEFI（BIOS）rev 1.13（12GB ram、1つの2.266GHz Xenonプロセッサー）を搭載した次の新しいIBM x3550 M3を使用していました

    ファームウェアタイプバージョン文字列リリース日
    IMM YUOOC7E 09/30/2011
    UEFI D6E154A 09/23/2011
    DSA DSYT89P 2011/10/28

IBM UEFI実装のレガシーBIOSモードでのUSBブートの「速度」に私は非常にがっかりしていると言わざるを得ません。

Supermicro XSCA9FまたはOracle-Sun X4275が 275MBのイメージを検討するための食料は、それぞれ32MBまたは33秒で275MBのUSBキーイメージを起動しますが、IBM x3550 M3は同じイメージで363秒以上かかります（11倍遅い）。

このパフォーマンスは完全に許容できず、問題はSystem Xライン全体に存在します。私はIBMと連絡を取りましたが、彼らはuEFIブートロードを試してみると言っています（これは、UEFI仕様を学び、GRUB2を学び、独自のカスタムブートローダーを書くように言うのと同じですが、実行可能ですが、追加の2はありません-3週間でこの問題が発生します）。はい、「純粋な」uEFIブートを使用すると高速に動作するはずですが、それを証明することはできませんが、「標準のディストリビューション」を使用できず、また、自分のuEFIブートローダーを書かざるを得ませんでした。

この「遅いレガシーブート」の問題は、IBMの問題/チケット番号A02PGGKで報告されました。uEFI開発者（Michael Brinkmanだと思います）に直接問い合わせてみましたが、IBMはこの問題を認めようとしていないようです。影響を受ける人々や企業の大きなコミュニティ。

2009年9月に「スローブート」についても議論しているスレッドと同様の分析をhttp://communities.intel.com/thread/3909?wapkw=uEFIに投稿しました。ここでは、これまで見たのと同じ問題です。

起動時間が遅すぎる。EFIを使用する場合、VMware ESXの起動には約20分かかりますが、通常のBIOSでは2分未満です

これは、私が経験する10倍または11倍のスローダウンと同じです。うまくいけば、いつかIBMがこれを修正するでしょう。

ジョン・ストラバラ