Serwer IBM długo ładuje się z systemu UEFI do systemu operacyjnego

10

Mam parę serwerów IBM System x3620. Te serwery mają się dobrze, gdy w końcu osiągną punkt, w którym system operacyjny przejmuje kontrolę, ale potrzeba im wieczności, aby ominąć nowy system rozruchowy UEFI ... dobre pięć minut; może dłużej. Nie mierzyłem jej czasu, ale jest to rodzaj rzeczy, w której idziesz po filiżankę kawy, gdy czekasz, i wciąż wraca, kiedy wrócisz.

Zwykle wyłączam je tylko na comiesięczny cykl konserwacji (zwykle tylko aktualizacje systemu Windows). Ma wbudowany czas konserwacji, więc dodatkowe 5 minut nie wlicza się do naszych umów SLA i nie jest wielkim problemem. Jednak w przypadku, gdy mogę mieć awarię, z pewnością chciałbym odzyskać te 5 minut. Czy jest coś, co mogę zrobić, aby powiedzieć im, aby po prostu uruchomili już system? Wyłączyłem już wszystko, co mogę znaleźć, aby wyłączyć dodatkowe opcje rozruchu.

Joel Coel
źródło
Problemem jest dla mnie to, że obciążenie USB to system operacyjny, np. 275 MB w skompresowanym archiwum, co zajmuje 6 minut 33 sekund. (około 0,75 MB / s). Następnie, jak powiedziałeś, „system operacyjny przejmuje”, a urządzenie USB może utrzymywać prędkość 22 MB / s. Ten problem pojawia się tylko w implementacji starszej wersji IBM uEFI, nie widzę go ani w Oracle / Sun, ani w Supermicro (wiem, że SUpermicro robi uEFI, nie jestem pewien co do Oracle / Sun).
Myślisz, że to źle, spróbuj uruchomić je od razu po wyjęciu z pudełka. 15 minut od zasilania prądem przemiennym we wtyczce do monitu rozruchowego PXE. Dlatego używam tego sprzętu tylko do instalacji VMWare i Linux, a wszystkie instalacje Windows są zwirtualizowane.
Magellan,

Odpowiedzi:

14

Wszystkie UEFI Maszyna IBM wziąć wieku do buta, a po UEFI inicjalizacji eon podejmowania i moduł starcie kopnięć emulacji Legacy BIOS i PCI-E ROM opcja zostanie wykonany itd. Itd. To jest „normalne” na wszystkich maszynach IBM UEFI - bez względu na to, czy jest to serwer typu blade czy standardowy.

Możesz wyłączyć starsze uruchamianie systemu BIOS, opcjonalne ROM-y, zoptymalizować kolejność uruchamiania i ogólnie utrzymać ten komputer na najnowszym poziomie oprogramowania układowego oferowanym przez IBM.

pfo
źródło
3
Słuszna uwaga. I wyłącz wszystko, co nie jest używane, jak rozruch sieciowy.
Matt
Wiesz, jaki jest najszybszy czas rozruchu tych bestii?
cJ Zougloub,
Miałem nadzieję na coś lepszego, ale no cóż.
Joel Coel
wiem, że operacja jest bardzo stara, ale naprawdę mi to pomaga.
Francisco Tapia,
3

Zgadzam się, że starsze wdrożenie uEFI w Systemie X jest tak boleśnie powolne, że mógłbym nawet uniknąć sprzedaży ich jako platformy moim klientom.

Pomiar czasu IBM od momentu uruchomienia starszego rozruchu z klucza USB, dopóki nie pojawi się monit systemu operacyjnego, jest absurdalnie długi. Używam SmartOS (pochodna illumos / opensolaris do wszystkich celów i celów po uruchomieniu, działa i działa podobnie jak Solaris 11), który działa jak szczeniak Linux, np. Ładuje 275 MB „skompresowanego” obiektu blob (cały system operacyjny), a następnie uruchamia System operacyjny w pamięci. To naprawdę pokazuje problem z implementacją starszego rozruchu IBM uEFI .

  BEG: 13:27:05 (uruchom klucz USB SmartOS USB 2.0)
  ZAKOŃCZENIE: 13:33:38 pm (gotowe do uruchomienia SmartOS - czytamy 275 MB)
  ---
  ZADANIE: 6:33 (sześć minut i 33 sekund - dość wolno - tylko 0,75 MB / sek.)

To prawie tak, jakby implementacja UEFI używa małego rozmiaru bloku, takiego jak 512-bajtowe odczyty, zamiast większego bufora podczas odczytów. Gdy jestem w systemie operacyjnym, mogę porównać wydajność klucza USB, który uruchomiłem, IMHO, jeśli kod IBM UEFI odczytałby tylko rozmiar bloku 8192 lub lepszy, ale rozmiar bloku 32768, wynikowy rozruch byłby super szybki.

Kiedyś w systemach operacyjnych SmartOS widziałem następujące parametry wydajności mojego klucza USB, od 512 bajtów do 131072 bajtów. Wygląda na to, że albo rozmiar bloku 8192 (12,3 MB / s w rozruchowym systemie operacyjnym), albo jeszcze lepiej rozmiar bloku 32768 (20,2 MB / s w rozruchowym systemie operacyjnym) byłby dobrym wyborem. Wygląda też na to, że rozmiar 512 bloku (0,64 MB / s w uruchomionym systemie operacyjnym) odpowiada dość blisko wyników, które wydaje mi się występować w moich długich butach.

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 512 count = 524288
    524288 + 0 rekordów w
    524288 + 0 zapisów
    prawdziwe 31m19.499s
    => 00,64 MB / s w systemie SmartOS, takim jak Solaris 11 (jest to prędkość uruchamiania systemu BIOS w IBM)

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144
    262144 + 0 rekordów w
    262144 + 0 zapisów
    prawdziwe 1m 39,989s
    => 02,56 MB / s SmartOS jak Solaris 11

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 2048 count = 131072
    131072 + 0 rekordów w
    131072 + 0 zapisów
    prawdziwe 0m50.215s
    => 05.09 MB / s SmartOS jak Solaris 11

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 4096 liczba = 65536
    65536 + 0 rekordów w
    65536 + 0 zapisów
    prawdziwe 0m33.056s
    => 07.74 MB / sek. SmartOS jak Solaris 11

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 8192 count = 32768
    32768 + 0 rekordów w
    32768 + 0 zapisów
    prawdziwe 0m20.757s
    => 12,33 MB / s SmartOS jak Solaris 11

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 32768 count = 8192
    8192 + 0 rekordów w
    8192 + 0 zapisów
    prawdziwe 0m 12,785s
    => 20,02 MB / s na SmartOSie, takim jak Solaris 11 (zgodnie z oczekiwaniami i widocznymi na pudełku Win7)

czas dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 131072 count = 2048
    2048 + 0 rekordów w
    2048 + 0 zapisów
    prawdziwe 0m11.532s
    => 22,19 MB / s SmartOS jak Solaris 11

Korzystałem z następującego nowego IBM x3550 M3 z UEFI (BIOS) wersja 1.13 (RAM 12 GB i jeden procesor ksenonowy 2.266 GHz)

    Typ oprogramowania układowego Wersja Data wydania
    IMM YUOOC7E 30.09.2011
    UEFI D6E154A 23.09.2011
    DSA DSYT89P 28.10.2011

Muszę powiedzieć, że jestem bardzo rozczarowany „szybkością” rozruchu USB w starszym trybie BIOS w implementacji IBM UEFI.

Zastanów się nad moim obrazem 275 MB Supermicro XSCA9F lub Oracle-Sun X4275 uruchomi obraz klucza usb 275 MB w ciągu odpowiednio 32 lub 33 sekund, podczas gdy IBM x3550 M3 zajmuje ponad 363 sekundy dla tego samego obrazu (11 razy wolniej) .

Ta wydajność jest całkowicie niedopuszczalna, a problem występuje w całej linii System X. Byłem w kontakcie z IBM i mówią tylko, że wypróbuj ładowanie rozruchowe uEFI (co jest jak powiedzenie mi, że poznaj specyfikację UEFI, naucz się GRUB2 i napisz własny niestandardowy moduł ładujący, tak, jest to wykonalne, ale nie mam dodatkowych 2 -3 tygodnie na bałagan z tymi rzeczami). Tak, użycie „czystego” rozruchu uEFI powinno działać szybko, ale nie mogę tego udowodnić, jednak wtedy nie mogłem użyć „standardowych dystrybucji”, a także, jak wskazałem, będę zmuszony napisać własny moduł ładujący uEFI.

Ten problem „wolne starsze uruchamianie” został zgłoszony przeze mnie pod adresem IBM Problem / Ticket # A02PGGK, nawet próbowałem skontaktować się bezpośrednio z programistą uEFI (myślę, że to Michael Brinkman) bezpośrednio, jednak IBM nie wydaje się, aby chciałby uznać ten problem i duża społeczność ludzi i firm, których to dotyczy.

Opublikowałem również podobną analizę do wątku na stronie http://communities.intel.com/thread/3909?wapkw=uEFI, który omawia także „powolne uruchamianie” we wrześniu 2009 r. Tutaj jest to ten sam problem, który widziałem

Czas uruchamiania jest zbyt wolny. Uruchomienie VMware ESX zajmuje około 20 minut, gdy używany jest EFI, w porównaniu do mniej niż 2 minut przy normalnym biosie

jest to to samo spowolnienie 10-krotnie lub 11-krotne, jakiego doświadczam, mam nadzieję, że pewnego dnia IBM to naprawi.

Jon Strabala

Jon Strabala
źródło
2
Myślę, że to właściwie osobny problem ... Nie mam nic przeciwko szybkości rozruchu mojego systemu operacyjnego, gdy w końcu pozwala on systemowi samemu się załadować. To wszystko, co prowadzi do tego momentu, trwa tak długo.
Joel Coel
Wracając do tego, myślę, że po raz pierwszy źle przeczytałem twój post ... ale nadal uważam, że to osobny problem, ponieważ uruchamiamy okna z bezpośrednio podłączonych dysków, zamiast czekać na załadowanie pełnego obrazu przez USB .
Joel Coel