IBM Server долго загружается после UEFI для ОС


10

У меня есть пара серверов IBM System x3620. Эти серверы преуспевают, как только они наконец достигают точки, когда операционная система вступает во владение, но им требуется вечность, чтобы пройти через новомодную загрузочную систему UEFI ... добрых пять минут или около того; возможно дольше. Я не рассчитал это, но это такая вещь, когда вы идете за чашкой кофе, пока вы ждете, и она все еще идет, когда вы вернетесь.

Обычно я отключаю их только для ежемесячного цикла обслуживания (обычно только обновления Windows). Это встроенное время обслуживания, поэтому дополнительные 5 минут не считаются нашими SLA и не имеют большого значения. Тем не менее, в случае, если у меня может произойти сбой, я бы хотел вернуть эти 5 минут назад. Могу ли я что-нибудь сделать, чтобы сказать им, что нужно просто загрузиться? Я уже отключил все, что смог найти, чтобы отключить дополнительные параметры загрузки.


Для меня проблема в том, что загрузка USB - это ОС, например, 275 МБ в сжатом архиве, это занимает 6 минут 33 секунды. (около 0,75 МБ / с). Тогда, как вы сказали, «операционная система перехватит», и устройство USB может поддерживать скорость 22 МБ / с. Эта проблема возникает только в реализации устаревшей реализации IBM uEFI, я не вижу ее ни в Oracle / Sun, ни в Supermicro (я знаю, что SUpermicro выполняет uEFI, не уверен насчет Oracle / Sun).

Вы думаете, что это плохо, попробуйте загрузить их из коробки. 15 минут от питания переменного тока в разъеме до приглашения загрузки PXE. Вот почему я использую это оборудование только для установок VMWare и Linux, и все установки Windows виртуализированы.
Магеллан

Ответы:


14

Все машины IBM uEFI загружаются целую вечность , так как после полной инициализации uEFI и запуска модуля активируется устаревшая эмуляция BIOS, запускаются дополнительные ПЗУ PCI-E и т. Д. И т. Д. Это "нормально" на всех машинах IBM uEFI - независимо от того, блейд-сервер или стандартный сервер

Вы можете отключить устаревшую загрузку BIOS, дополнительные ПЗУ, оптимизировать порядок загрузки и, как правило, поддерживать на этой машине новейший уровень прошивки, предлагаемый IBM.


3
Хорошая точка зрения. И отключите все, что не используется, как загрузка по сети.
Мэтт

Есть идеи о том, какое время загрузки у этих зверей самое быстрое?
cJ Zougloub

Я надеялся на что-то лучшее, ну да ладно.
Джоэл Коэль

я знаю, что опера очень старая, но она мне действительно помогает.
Франциско Тапиа

3

Я согласен, что устаревшая реализация System X uEFI настолько болезненно медленная, что я мог бы даже не продавать их в качестве платформы своим клиентам.

Измерение формы IBM в тот момент, когда она запускает загрузку устаревшего USB-ключа до тех пор, пока я не получу приглашение операционной системы, смехотворно долго. Я использую SmartOS (производная illumos / opensolaris для любых целей и задач после загрузки, она работает и во многом похожа на Solaris 11), которая работает как щенок Linux, например, загружает «сжатый» большой двоичный объект объемом 275 МБ (всю ОС), а затем загружает ОС в памяти. Это действительно демонстрирует проблему с реализацией устаревшей загрузки IBM-uEFI .

  BEG: 13:27:05 (запустите SmartOS USB 2.0 USB-ключ)
  КОНЕЦ: 1:33:38 вечера (сделано для запуска SmartOS - мы читаем 275 МБ)
  ---
  TOOK: 6:33 (шесть минут и 33 секунды - довольно медленно - всего 0,75 МБ / с)

Это почти как если бы реализация 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 года, здесь я вижу ту же проблему

Время загрузки слишком медленное. При использовании EFI загрузка VMware ESX занимает около 20 минут, а при обычной BIOS - менее 2 минут.

это то же самое замедление в 10 или 11 раз, которое я испытываю, надеюсь, однажды IBM исправит это.

Джон Страбала


2
Я думаю, что это на самом деле отдельная проблема ... Я в порядке со скоростью загрузки моей операционной системы, как только она наконец-то позволяет операционной системе начать загружаться сама. Это каждая вещь, ведущая к этому моменту, которая занимает так много времени.
Джоэл Коэль

Возвращаясь к этому, я думаю, что я неправильно прочитал ваш пост в первый раз ... но я все еще думаю, что это отдельная проблема, так как мы загружаем окна с дисков с прямым подключением, а не ожидаем загрузки полного образа через USB ,
Джоэл Коэль
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.