IBM Server prend beaucoup de temps pour démarrer après UEFI sur OS

J'ai une paire de serveurs IBM System x3620. Ces serveurs fonctionnent bien une fois qu'ils ont finalement atteint le point où le système d'exploitation prend le relais, mais il leur faut une éternité pour dépasser le nouveau système de démarrage UEFI ... environ cinq bonnes minutes; peut-être plus. Je ne l'ai pas chronométré, mais c'est le genre de chose où vous allez prendre une tasse de café pendant que vous attendez et ça continue quand vous revenez.

Normalement, la seule fois où je les arrête, c'est pour un cycle de maintenance mensuel (généralement juste des mises à jour Windows). C'est un temps de maintenance intégré, et donc les 5 minutes supplémentaires ne comptent pas pour nos SLA et ne sont pas un gros problème. Cependant, dans le cas où je pourrais avoir une panne, je voudrais certainement récupérer ces 5 minutes. Puis-je faire quelque chose pour leur dire d'aller de l'avant et de démarrer déjà? J'ai déjà désactivé tout ce que je peux trouver pour désactiver les options de démarrage supplémentaires.

Toutes les machines IBM uEFI prennent du temps à démarrer, car après l'initialisation eEFI et le démarrage du module, l'émulation BIOS héritée entre en action et les ROM optionnelles PCI-E sont exécutées, etc. etc. Ceci est "normal" sur toutes les machines IBM uEFI - qu'il s'agisse d'un serveur lame ou rack standard.

Vous pouvez désactiver le démarrage du BIOS hérité, les ROM optionnelles, optimiser l'ordre de démarrage et généralement garder cette machine au niveau de micrologiciel le plus récent proposé par IBM.

Je conviens que l'implémentation héritée de System X uEFI est si douloureusement lente que je pourrais même éviter de les vendre en tant que plate-forme à mes clients.

La mesure de la forme IBM au moment où il démarre un démarrage de clé USB hérité jusqu'à ce que j'obtienne une invite de système d'exploitation est ridiculement longue. J'utilise SmartOS (un dérivé illumos / opensolaris à toutes fins utiles une fois démarré, il fonctionne et agit beaucoup comme Solaris 11) qui agit comme un chiot Linux, par exemple, il charge un blob "compressé" de 275 Mo (l'ensemble du système d'exploitation), puis démarre le OS en mémoire. Cela présente vraiment le problème de la mise en œuvre uEFI d'IBM du démarrage hérité .

  BEG: 1:27:05 pm (démarrer la clé USB SmartOS USB 2.0)
  FIN: 13 h 33 min 38 s (terminé pour exécuter SmartOS - nous lisons 275 Mo)
  ---
  A PRIS: 6h33 (six minutes et 33 secondes - assez lent - seulement 0,75 Mo / sec.)

C'est presque comme si l'implémentation UEFI utilise une taille de bloc minuscule comme des lectures de 512 octets, plutôt qu'un tampon plus grand pendant les lectures. Une fois que je suis dans le système d'exploitation, je peux comparer les performances de la clé USB que j'ai démarrée, à mon humble avis si le code IBM UEFI ne ferait que lire une taille de bloc 8192 ou mieux encore une taille de bloc 32768, le démarrage résultant serait super rapide.

Donc, une fois dans un système d'exploitation SmartOS, j'ai vu les caractéristiques de performance suivantes pour ma clé USB, allant de 512 octets à 131072 octets. Il semble que la taille de bloc 8192 (12,3 Mo / s dans un système d'exploitation démarré) ou mieux encore une taille de bloc 32768 (20,2 Mo / s dans un système d'exploitation démarré) soient de bons choix. Il semble également qu'une taille de bloc de 512 (0,64 Mo / s dans un système d'exploitation démarré) correspond assez près aux résultats que je semble rencontrer dans mes longues bottes.

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 512 count = 524288
    524288 + 0 enregistrements dans
    524288 + 0 enregistrements en sortie
    réel 31m19.499s
    => 00,64 Mo / sec. sur SmartOS comme Solaris 11 (c'est la vitesse de la vitesse de démarrage du bios IBM)

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 1024 count = 262144
    262144 + 0 enregistrements dans
    262144 + 0 enregistrements en sortie
    réel 1m39.989s
    => 02,56 Mo / sec. SmartOS comme Solaris 11

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 2048 count = 131072
    131072 + 0 enregistrements dans
    131072 + 0 enregistrements sortis
    réel 0m50.215s
    => 05,09 Mo / sec. SmartOS comme Solaris 11

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 4096 count = 65536
    65536 + 0 enregistrements dans
    65536 + 0 enregistrements sortis
    réel 0m33.056s
    => 07,74 Mo / sec. SmartOS comme Solaris 11

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 8192 count = 32768
    32768 + 0 enregistrements dans
    32768 + 0 enregistrements sortis
    réel 0m20.757s
    => 12,33 Mo / sec. SmartOS comme Solaris 11

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 32768 count = 8192
    8192 + 0 enregistrements dans
    8192 + 0 enregistrements sortis
    réel 0m12.785s
    => 20,02 Mo / sec. sur SmartOS comme Solaris 11 (comme prévu et vu sur une boîte Win7)

temps dd if = / dev / dsk / c1t0d0p0 of = / dev / null bs = 131072 count = 2048
    2048 + 0 enregistrements dans
    2048 + 0 enregistrements sortis
    réel 0m11.532s
    => 22,19 Mo / sec. SmartOS comme Solaris 11

J'utilisais ce qui suit un nouveau IBM x3550 M3 avec UEFI (BIOS) rev 1.13 (12 Go de RAM et un processeur Xenon 2.266GHz)

    Type de micrologiciel Version Chaîne Date de sortie
    IMM YUOOC7E 30/09/2011
    UEFI D6E154A 23/09/2011
    DSA DSYT89P 28/10/2011

Je dois dire que je suis profondément déçu de la «vitesse» du démarrage USB en mode BIOS hérité dans la mise en œuvre d'IBM UEFI.

Matière à réflexion pour mon image de 275 Mo, un Supermicro XSCA9F ou un Oracle-Sun X4275 démarrera une image de clé USB de 275 Mo en seulement 32 ou 33 secondes respectivement, tandis que l'IBM x3550 M3 prend plus de 363 secondes pour la même image (11 fois plus lentement) .

Cette performance est totalement inacceptable et le problème existe sur l'ensemble de la gamme System X. J'ai été en contact avec IBM et ils disent juste d'essayer un chargement de démarrage uEFI (ce qui revient à me dire d'apprendre les spécifications UEFI, d'apprendre GRUB2 et d'écrire votre propre chargeur de démarrage personnalisé, oui, c'est faisable mais je n'ai pas de supplément 2 -3 semaines pour jouer avec ce truc). Oui, l'utilisation d'un démarrage uEFI "pur" devrait fonctionner rapidement, mais je ne peux pas le prouver, cependant je ne pouvais pas utiliser de "distributions standard" et, comme je l'ai indiqué, je serais obligé d'écrire mon propre chargeur de démarrage uEFI.

Ce problème "démarrage hérité lent" a été signalé par moi sous IBM Problem / Ticket # A02PGGK, j'ai même essayé de contacter directement le développeur uEFI (je pense que c'est Michael Brinkman) directement, mais IBM ne semble pas vouloir prendre en compte ce problème et la grande communauté de personnes et d'entreprises concernées.

J'ai également publié une analyse similaire sur un sujet à http://communities.intel.com/thread/3909?wapkw=uEFI qui traite également du "démarrage lent" en septembre 2009 ici, c'est le même problème que j'ai vu

Le temps de démarrage est trop lent. Il faut environ 20 minutes pour démarrer un VMware ESX lorsque EFI est utilisé, contre moins de 2 minutes avec le BIOS normal

c'est le même ralentissement 10X ou 11X que j'éprouve, j'espère qu'un jour IBM corrigera cela.

Jon Strabala