У меня есть пара серверов IBM System x3620. Эти серверы преуспевают, как только они наконец достигают точки, когда операционная система вступает во владение, но им требуется вечность, чтобы пройти через новомодную загрузочную систему UEFI ... добрых пять минут или около того; возможно дольше. Я не рассчитал это, но это такая вещь, когда вы идете за чашкой кофе, пока вы ждете, и она все еще идет, когда вы вернетесь.
Обычно я отключаю их только для ежемесячного цикла обслуживания (обычно только обновления Windows). Это встроенное время обслуживания, поэтому дополнительные 5 минут не считаются нашими SLA и не имеют большого значения. Тем не менее, в случае, если у меня может произойти сбой, я бы хотел вернуть эти 5 минут назад. Могу ли я что-нибудь сделать, чтобы сказать им, что нужно просто загрузиться? Я уже отключил все, что смог найти, чтобы отключить дополнительные параметры загрузки.
Ответы:
Все машины IBM uEFI загружаются целую вечность , так как после полной инициализации uEFI и запуска модуля активируется устаревшая эмуляция BIOS, запускаются дополнительные ПЗУ PCI-E и т. Д. И т. Д. Это "нормально" на всех машинах IBM uEFI - независимо от того, блейд-сервер или стандартный сервер
Вы можете отключить устаревшую загрузку BIOS, дополнительные ПЗУ, оптимизировать порядок загрузки и, как правило, поддерживать на этой машине новейший уровень прошивки, предлагаемый IBM.
источник
Я согласен, что устаревшая реализация System X uEFI настолько болезненно медленная, что я мог бы даже не продавать их в качестве платформы своим клиентам.
Измерение формы IBM в тот момент, когда она запускает загрузку устаревшего USB-ключа до тех пор, пока я не получу приглашение операционной системы, смехотворно долго. Я использую SmartOS (производная illumos / opensolaris для любых целей и задач после загрузки, она работает и во многом похожа на Solaris 11), которая работает как щенок Linux, например, загружает «сжатый» большой двоичный объект объемом 275 МБ (всю ОС), а затем загружает ОС в памяти. Это действительно демонстрирует проблему с реализацией устаревшей загрузки IBM-uEFI .
Это почти как если бы реализация UEFI использовала крошечный блок размером, например, 512 байт для чтения, а не больший буфер во время чтения. Как только я нахожусь в ОС, я могу оценить производительность USB-ключа, который я загрузил, ИМХО, если код IBM UEFI просто прочитал бы размер блока 8192 или лучше, а размер блока 32768, итоговая загрузка была бы очень быстрой.
Итак, однажды в операционных системах SmartOS я увидел следующие характеристики производительности для моего USB-ключа, в диапазоне от 512 байт до 131072 байт. Похоже, что размер блока 8192 (12,3 МБ / с в загруженной ОС) или лучше, но размер блока 32768 (20,2 МБ / с в загруженной ОС) будет хорошим выбором. Это также похоже на то, что размер блока 512 (0,64 МБ / с в загруженной ОС) совпадает с результатами, которые я, похоже, получаю в своих длинных ботинках.
время dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 512 count = 524288 524288 + 0 записей в 524288 + 0 записей настоящие 31м19.499 => 00,64 МБ / с на SmartOS, как Solaris 11 (это скорость загрузки IBM bios) время dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144 262144 + 0 записей в 262144 + 0 записей настоящий 1м39.989с => 02,56 МБ / с SmartOS как солярис 11 время dd if = / dev / dsk / c1t0d0p0 из = / dev / null bs = 2048 count = 131072 131072 + 0 записей в 131072 + 0 записей реальный 0m50.215s => 05.09MB / сек SmartOS как солярис 11 время dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 4096 count = 65536 65536 + 0 записей в 65536 + 0 записей реальный 0m33.056s => 07,74 МБ / с SmartOS как солярис 11 время dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 8192 count = 32768 32768 + 0 записей в 32768 + 0 записей реальный 0m20.757s => 12,33 МБ / с SmartOS как солярис 11 время dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 32768 count = 8192 8192 + 0 записей в 8192 + 0 записей реальный 0m12.785s => 20,02 МБ / с на SmartOS, как Solaris 11 (как ожидалось и видно на коробке Win7) время dd if = / dev / dsk / c1t0d0p0 из = / dev / null bs = 131072 count = 2048 2048 + 0 записей в 2048 + 0 записей реальный 0m11.532s => 22,19 МБ / с SmartOS как солярис 11Я использовал следующий новый IBM x3550 M3 с UEFI (BIOS) ред. 1.13 (12 Гбайт оперативной памяти и один ксеноновый процессор 2,266 ГГц)
Тип прошивки Версия Строка Дата выпуска IMM YUOOC7E 30.09.2011 UEFI D6E154A 23.09.2011 DSA DSYT89P 28.10.2011Я должен сказать, что очень разочарован «скоростью» загрузки с USB в устаревшем режиме BIOS в реализации IBM UEFI.
Подумайте над тем, что для моего образа размером 275 МБ Supermicro XSCA9F или Oracle-Sun X4275 загрузят образ USB-ключа размером 275 МБ всего за 32 или 33 секунды соответственно, в то время как IBM x3550 M3 для этого же образа требуется более 363 секунд (в 11 раз медленнее) ,
Эта производительность совершенно неприемлема, и проблема существует во всей линейке System X. Я связывался с IBM, и они просто говорят, что попробуйте загрузочную загрузку uEFI (это как сказать мне изучить спецификацию UEFI, изучить GRUB2 и написать свой собственный загрузчик, да, это выполнимо, но у меня нет лишних 2 -3 недели возиться с этим мелочами). Да, использование «чистой» загрузки uEFI должно работать быстро, но я не могу доказать это, однако тогда я не мог использовать «стандартные дистрибутивы», а также, как я указал, я был бы вынужден написать свой собственный загрузчик uEFI.
Я сообщил об этой проблеме «медленная устаревшая загрузка» в IBM Problem / Ticket # A02PGGK, я даже пытался связаться с разработчиком uEFI (я думаю, это Майкл Бринкман) напрямую, однако IBM, похоже, не хочет признавать эту проблему и большое сообщество людей и компаний, которые затронуты.
Я также опубликовал аналогичный анализ в ветке на http://communities.intel.com/thread/3909?wapkw=uEFI, где также обсуждается «медленная загрузка» еще в сентябре 2009 года, здесь я вижу ту же проблему
это то же самое замедление в 10 или 11 раз, которое я испытываю, надеюсь, однажды IBM исправит это.
Джон Страбала
источник