IBM Server需要很长时间才能通过UEFI引导至操作系统

我有一对IBM System x3620服务器。这些服务器一旦最终到达操作系统的接管点，它们的性能就会很好，但是要经过全新的UEFI引导系统却要花上一辈子 ……大约五分钟左右的时间。也许更长。我还没有计时，但是这是一种您可以在等待时喝杯咖啡的事情，而当您回来时它仍在继续。

通常，我关闭这些设备的唯一时间是每月维护一次（通常只是Windows更新）。它是内置的维护时间，因此，额外的5分钟不会算在我们的SLA中，也没什么大不了的。但是，如果我可能要中断服务，我希望可以将这5分钟恢复。我有什么办法告诉他们继续进行引导？我已经禁用了所有可以找到的禁用所有启动选项的功能。

所有IBM的UEFI计算机上采取的年龄来启动，作为EON回吐UEFI初始化后和模块启动了传统BIOS仿真踢和PCI-E选项ROM得到执行等等等等，这是“正常”的所有IBM UEFI机-无论刀片服务器还是标准机架服务器。

您可以禁用旧版BIOS引导，可选的ROM，优化​​引导顺序，并通常使该计算机保持IBM提供的最新固件级别。

我同意System X uEFI的旧版实现是如此缓慢，以至于我什至可以避免将它们作为平台出售给客户。

从开始传统USB密钥启动直到我收到操作系统提示的时间来衡量IBM表格的时间太长了。我正在使用SmartOS（从所有目的来看都是illumos / opensolaris衍生物，一旦启动，它就会运行，其行为类似于Solaris 11），其行为类似于小狗Linux，例如，它加载275MB的“压缩” blob（整个OS），然后启动内存中的操作系统。 这确实说明了IBM uEFI实现旧引导的问题。

  BEG：1:27:05 pm（启动SmartOS USB 2.0 USB密钥）
  结束：下午1:33:38（已完成运行SmartOS的操作-我们读取了275MB）
  ---
  TOOK：6：33（六分钟33秒-相当慢-仅0.75MB /秒。）

UEFI实施几乎就像使用512字节读取这样的微小块大小，而不是在读取期间使用较大的缓冲区。进入操作系统后，我可以对我启动的USB密钥的性能进行基准测试，恕我直言，如果IBM UEFI代码将读取8192块大小或更佳的32768块大小，则启动速度将非常快。

因此，一旦在SmartOS操作系统中，我就会看到我的USB密钥具有以下性能特征，范围从512字节到131072字节。看起来是8192块大小（在已引导的操作系统中为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记录了
    真实31m19.499s
    => 00.64MB /秒。在像Solaris 11这样的SmartOS上（这是IBM bios引导速度的速度）

时间dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144
    262144 + 0条记录在
    262144 + 0条记录
    真实1m39.989s
    => 02.56MB /秒。像Solaris 11这样的SmartOS

时间dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 2048 count = 131072
    131072 + 0条记录在
    131072 + 0条记录
    真正的0m50.215s
    => 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条记录
    真正的0m12.785s
    => 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）版本1.13的新IBM x3550 M3（12GB内存和一个2.266GHz氙气处理器）

    固件类型版本字符串发布日期
    IMM YUOOC7E 2011年9月30日
    UEFI D6E154A 09/23/2011
    DSA DSYT89P 2011年10月28日

我必须说，我对IBM UEFI实现中传统BIOS模式下USB引导的“速度”感到非常失望。

对于我的275MB映像而言，值得深思的是Supermicro XSCA9F或Oracle-Sun X4275将分别在32或33秒内启动275 MB USB密钥映像，而IBM x3550 M3花费363秒才能生成同一映像（慢11倍）。

这种性能是完全不能接受的，并且问题在整个System X系列中都存在。我一直在与IBM联系，他们只是说尝试uEFI引导加载（这就像对我说学习UEFI规范，学习GRUB2并编写自己的自定义引导加载程序一样，是可行的，但是我没有多余的2个-3周内弄乱了这些东西）。是的，使用“纯” uEFI引导程序应该可以快速运行，但我无法证明这一点，但是后来我无法使用“标准发行版”，而且正如我指出的那样，我将被迫编写自己的uEFI引导加载程序。

此问题是我在IBM问题/票号A02PGGK下报告的“缓慢的旧版引导”问题，我什至尝试直接与uEFI开发人员（我认为是Michael Brinkman）联系，但是IBM似乎并不愿意承认这个问题，并且受影响的大型人员和公司社区。

我还在http://communities.intel.com/thread/3909?wapkw=uEFI上发布了与线程类似的分析，它在2009年9月也讨论了“缓慢启动”，这是我所看到的同一问题

引导时间太慢。使用EFI时，启动VMware ESX大约需要20分钟，而使用普通BIOS只需不到2分钟

这与我遇到的10倍或11倍速度下降相同，希望有一天IBM会解决此问题。

乔恩·斯特拉巴拉