Bonjour,
 
Depuis plusieurs mois maintenant nous avons un souci de perte brutale de performance sur un serveur r820 de dell dans une infra VMware esx1.
Les vm hébergées deviennent extrêmement lentes comme si on était revenu à l'époque des 386. Dans les VM pas de bsod ni de kernel panic seulement une extrème lenteur pour le moindre clic.
 
Les supports Dell et VMware sont sur le problème mais se rejettent joyeusement la faute  l'un sur l'autre.
 
Je voulais savoir si dans les habitués du forum, quelqu'un a rencontré des soucis sur des PowerEdge R820 et si oui quel a été le diagnostic et le sous-ensemble réparé ?
 
Merci

tu veux pas décrire l'infra ?

Ce ne sera pas significatif car il y a 4 autres serveurs avec une configuration  identique qui ne posent pas de pb.
Mais en gros il y deux cluster de 2 esx dans 2 datacenter séparés.
 
Chaque serveur R820 a 4x XEON E5-4640  + 384 Go ram + 2x HBA Qlogic FC 8Gb vers des fabrics Brocade et du stockage Datacore  
 
Le truc de fou c'est que les vm marchent nickel sur les hotes ESX1, 2, 3, 4 mais sur ESX5 au bout de 4 jours ça rame d'un seul coup.
Rien dans les logs Dell de la carte iDrac, rien dans les logs VMware des vm ou du host ESXi.
 
Les hotes esx sont tous identiques.
 
J'ai eu un echo indirect que Dell avait d'autres pb avec la dernière génération (la 12) des serveurs PowerEdge Rack. Mais n'est-ce pas qu'une rumeur ?
 
Ma question était plus dans ce sens. Avez vous entendu parler d'un ou des pb sur les PE R820 ?

Mais c'est quoi comme type de soucis ? cpu ? ram ? io ?
Tes cartes FC sont bien configurées ? Taille des Buffer and co ?

La lenteur !!! Comme si le serveur était devenu un 386 !!!
Les VM win 2008, 2012, ou bien linux centos ou debian continuent de fonctionner mais très lentement.
 
Dans les VM qui hébergent des bases de données et/ou des sites web on ne s'en rend pas compte immédiatement mais sur des VM TSE les users nous appellent illico !!!
Et quand on rentre dans une vm, effectivement, un simple clic demande 5 à 10 secondes pour réagir.
 
La seule trace visible c'est le graphique des perf CPU dans le vcenter qui chute brutalement.
Pas de blue screen ou kernel panic, rien dans les logs des vm ou de l'esx.  
Donc apparemment il y a quelque chose au niveau ressource CPU mais comment l'expliquer : est-ce un des caches CPU L1, L2 ou L3 qui se désactive, est-ce le bus RAM ou une sorte de mise en protection d'un des proc ?
 
Les i/o sont faibles, réseau ou disque dur quelques Ko.
Les latences lecture ou écriture varient entre 2 et 16 ms.
Donc c'est pas de ce coté.
 
Nous avons changé les patch fibre optique, les modules SFP, les cartes HBA, interverti les switch Brocade ; pareil.  
Les Bios/Firmware sont à jour : même plusieurs versions ont été testées : même pb.
Une version ESXi 5.1 et 5.5 ont été installé : pareil.
 
Les quelques VM qui tournent dessus fonctionnent correctement sur un autre serveur si on les migrent.
Le tout fonctionne dans des datacenter refroidi à température constante et sur onduleur filtré évidemment.
 
Vraiment on s'arrache les cheveux. Et les supports Dell et Vmware se renvoient la balle.
 
Quelqu'un a-t-il connu ce genre de pb ou a-t-il rencontré des bugs bien vicieux avec les R820 ?

Tu as foutu des compteurs de perf sur l'OS ?

http://kb.vmware.com/selfservice/m [...] Id=1018206 ?
http://en.community.dell.com/suppo [...] 52611.aspx

Merci de t’intéresser à mon souci en cette pleine période de vacances.
 
Nous avons bien évidement mis à jour tous les bios et firmware possibles et changer les réglages du bios en mode max perf (à la demande du support Dell) et nous avons aussi testé avec le réglage OS management (à la demande du support Vmware en opposition du support Dell - sic -). Le problème apparait dans les 2 cas.
 
Dans le 2é lien que tu m'indiques je vois que déjà des pb de perf assez inexplicable existent sur le couple Dell/Vmware.
 
Mais chez nous, nous sommes dans la même  conf serveur : 5 serveurs R820 avec même CPU, carte Raid, DDur, HBA FC, NIC,  seul la quantité de ram change : au lieu de 384 Go sur les serveurs qui fonctionnent bien, le serveur qui pose pb a 512 Go de Ram. Tout est du matos Dell et les versions ESX (5.1 ou 5.5) ont été installées depuis un dvd fait depuis les images ISO fournies sur le site de téléchargement Dell.
 
Pour plaisanter je dis que si, ni le support Dell ni le support Vmware ne trouvent l'origine du pb, on va aller chez HP et Hyper-V, mais je ne suis pas loin de le faire vraiment.
Bon je leur fait confiance malgré tout , ils discutent entre eux pour trouver une solution à notre souci.
 
Ou alors Xen et SuperMicro !  
Mais de toute façon fin Aout il faudra que ce soit résolu car immobiliser un serveur qui coute 1 bras 2 yeux et 3 genoux pour faire un "tit lab test" c'est pas au gout de mon boss et l'activité reprend à fond à la rentrée.

Les compteurs de perf sont pas utiles ; si tu ouvre une session sur un Windows serveur par exemple, tu as l'efficacité d'un pc de 1990, chaque clic de souris répond en 10 ou 20 secondes !!!
 
Sinon voilà un graphe au moment où apparait le pb :
 

 

Euh et si tu descends la RAM de 512 à 384 comme sur ceux où ça roule ?
Les problèmes réapparaissent ?

Oui c'est prévu. Je teste demain.
Mais cela n'enlève rien au caractère étrange de ce type de panne.
De plus nous avions sizé la ram pour nos besoins, si on enlève 128 Go ce n'est plus dans nos objectifs de ressources RAM dispo pour les VM.
 
Mais oui il faudra peut-être en passer par là.
Un changement de motherboard et carte mezzanine est prévu demain aussi.

Le CPU qui est flingué ?
 
Si c'est possible, voir pour intervertir les CPU entre deux serveurs.

Tu as lancé des bench de CPU ?
Déjà pour comparer entre un bon et un mauvais serveur

Pour tester les CPU, normalement les Xeon E5-4600 peuvent tourner par 2. Le plus simple est donc de faire un test avant seulement 2 CPU.
 
Tes configs mémoire sont quand même bien tordues... 384 Go, obtenus probablement en 48 modules de 8 Go, c'est ce qu'il y a de pire pour la BP mémoire. Comment sont obtenus les 512 Go sur la machine qui pose problème ?
 
Ahlala, les commerciaux Dell...

Quel bench CPU est conseillé dans mon cas ?
 
Les E5-4600 peuvent même être associé par 4 ( le 4 de 4600).
 
Oui je reconnais que 384 Go ça parait un peu dy-symetrique mais ça fait moins mal au porte monnaie.
Néanmoins les Xeon E5-4600 sont assez souples en organisation RAM.
 
Dans notre cas la conf en 384 Go est celle qui fonctionne !!! et pas la conf 512 Go.
 
Demain batterie de tests avec le support Dell sur site.  
Wait & see.

tien nous au courant

Pour les CPU, ce que je te dis, c'est qu'ils fonctionnent aussi par 2. Du coup, si tu penses avoir un CPU HS, le plus simple est de les tester 2 par 2. Attention, il faut toujours peupler les sockets 0 et 1 en revanche.

As-tu fais un test des DIMMs ? Une dizaine de passes Memtest86+ te donneras peut-être une indication à ce niveau-là.
Est-ce que tu utilises du memory mirroring ? Je ne sais pas si ça peut influencer sur ce genre de problèmes...
 
Pour l'histoire de la taille de la RAM, nous avons bien des R720 avec 288Gb de RAM, alors je ne m'étonne plus de rien

 
 
C'est quoi le problème d'avoir 384Go de RAM en 48x8Go ?

C'est une configuration qui limite énormément la bande passante mémoire.
 
Sur les architectures Intel Sandy Bridge (Xeon E5-1600, E5-2600 et E5-4600), tu as 4 canaux mémoire par CPU et les cartes mères disposent généralement de 1 à 3 slots mémoire par canal. Globalement, la règle est la suivante :

• avec 1 module par canal, la mémoire fonctionne à sa fréquence nominale ;
• avec 2 modules par canal, la mémoire fonctionne au plus à 1600 MHz ;
• avec 3 modules par canal, la mémoire fonctionne au plus à 1066 MHz.

Sachant que la mémoire vive généralement utilisée sur archi Sandy Bridge est de la DDR3 ECC Registered à 1600 MHz (sauf chez les marchands de tapis comme... Dell qui n'hésitent pas à te fourguer de la 1333 MHz si tu ne prends pas garde), la conclusion est que la mémoire fonctionnera à sa fréquence nominale jusqu'en configuration 2 modules par canal.
 
48 modules de 8 Go, c'est une configuration 3 modules par canal, la plus mauvaise donc. Souvent, mieux vaut passer directement à 512 Go en 32 x 16 Go. On pourrait croire que le surcoût est important mais même pas tant que ça en fait, pour la bonne et simple raison qu'un module de 16 Go ne coûte pas le double d'un module de 8 Go.
 
Et là on ne parle que de performances mais on pourrait aussi évoquer l'évolutivité de la machine, la consommation électrique, le taux de panne forcément supérieur, etc.

OK merci pour l'info

Bonjour,

Cette information est très intéressante !
Peux-tu me dire où trouver plus d'infos à ce sujet pour les différentes archi Xeon? (Sandy, Ivy, Haswell, etc (et éventuellement les archis plus anciennes comme Core qui tournent en DDR2-FBDIMM))
Comment savoir quelle est la fréquence utilisée en fonction du nombres de DIMMs par chan ?

EDIT : sur CPU-World on trouve de temps en temps des infos.
Comme nous avons des fujitsu et des dell, j'ai trouvé des infos, mais rien du côté d'Intel.
http://globalsp.ts.fujitsu.com/dms [...] -ww-en.pdf
http://i.dell.com/sites/doccontent [...] -guide.pdf

Le plus simple est de récupérer le manuel d'une carte mère de l'architecture visée. Typiquement SuperMicro puisque c'est chez eux que l'info est la plus facilement accessible.
 
Les limitations étant liées au chipset et/ou au CPU, tous les constructeurs produisent de toute façon les mêmes spécifications.

http://forum-images.hardware.fr/ic [...] gif?f-ed=1
Salut,
 
Retour de vacances et comme promis voici le retour d'expérience sur mon pb.
 
Dell a consenti à l'échange carte mère et la carte mezzanine plus 2 cpu.http://forum-images.hardware.fr/icones/smile.gif?f-ed=1
Petit aparté matériel : ce que j'appelle la carte mezzanine est une demie carte mère puisque le R820 étant un 4 sockets CPU dans un châssis de 2U de hauteur, Dell a choisi de mettre une demie carte mère avec 2 sockets+slots RAM dans le fond du châssis (au rez-de-chaussée on peut dire) et la seconde moitié au dessus avec 2 sockets CPU+slots RAM.http://forum-images.hardware.fr/icones/smilies/pt1cable.gif?f-ed=1
 
2 CPU ayant déjà été changées il y a quelques mois, c'est les 2 autres qui ont été changées ce coup ci.
 
Au final après échange des 4 CPU et de la carte mère ET mise à jour de TOUS les firmwares, ce serveur monté en ESXi 5.1 fonctionne depuis 30 jours comme on est en droit de l'espérer.  
 
85 vm tournent dessus (mais ne sont pas au max des sollicitations : tout le monde n'est pas rentré de vacances). Les vmotions et les snapshots se font sans pb.
 
Je garde pour moi mon avis sur la méthode de résolution du problème.
 
Coté hardware je voulais dire à ceux qui m'ont recommandés de faire des tests en changeant des barrettes RAM et/ou CPU, c'est une trés bonne démarche mais pas forcément applicable dans le cas de serveur localisés sur des sites différents, sur des serveurs en prod, avec plusieurs clients connectés .... Sur mes bécanes chez moi je peux tyranniser la famille comme je veux; c'est moi l'admin réseau/system/appli  http://forum-images.hardware.fr/ic [...] gif?f-ed=1
 
Ce qui est à retenir de cette expérience, c'est de ne pas partir comme acquis, sans mise en tests éprouvés de la solution qui a pourtant déjà fait ses preuves. Car nous avions déjà 4 serveurs en prod depuis 1 an dans cette conf sans pb. Pourquoi le 5éme a-t-il créé autant d'ennuis ?http://forum-images.hardware.fr/icones/smilies/non.gif?f-ed=1
 
Le bench passmark situe les vm windows entre un core i7 3720qm et core i7 3770K selon les tests. Ce qui est pas mal étant donné le nombre de vm qui tournent simultanément.
 
Si durant quelques semaines tout continue de tourner rond, nous allons upgrader l'archi en vmware 5.5.
Si parmi vous certains ont des retours d'expérience fâcheuses, je suis preneur de leurs conseils.http://forum-images.hardware.fr/icones/smilies/jap.gif?f-ed=1

Hello,  
Sur la 5.5 (sans update), j'ai eu des soucis de PSOD. Visiblement c'est un bug connu chez VMWare avec les cartes réseau virtuelles E1000, théoriquement résolu avec la 5.5 update 1.

Vi ça j'étais au courant déjà.  
Merci.  
 
Puisque tu as l'air d'être utilisateur Vmware, as-tu souvent des messages :
Les performances du périphérique naa.8d3ae5......se sont  
détériorées. La latence d'E/S est passée de la valeur moyenne de 4967 microsecondes à 1048704 microsecondes.
 
Si on analyse le message on se rend compte que passer de 5 ms à 100ms sur une infra où une dizaine de serveur accèdent aux ressources SAN c'est pas dramatique. Surtout que ça dure 1 ou 2 secondes à peine. D'ailleurs d'après la kb vmware,  je crois me souvenir que le message est déclenché quand la latence est multipliée par 4. Donc si tu es mauvais tout le temps, tu n'as pas de message ???!!!
Cela n'impacte pas la réactivité de nos vm mais c'est agaçant et un peu inquiétant kan même sans parler des logs remplis inutilement.
 
Si quelqu'un a eu le pb et l'a résolu, je suis preneur de pistes à fouiner.

Euh là c'est de 5ms à 1seconde

Oui là c'est le mauvais exemple mais même des différences plus faibles comme ici  
" La latence d'E/S est passée de la valeur moyenne de 9539 microsecondes  
à 191250 microsecondes.
avertissement
29/08/2014 14:38 "  
et crac avertissement pas très significatif !!
 
Dans mon infra j'ai vérifié les modules SFP fibre channel, les switch fabrics, les jarretière optiques, changer le mode de liaison FC dans les HBA de loop à per to per ... pareil. Je vois pas où j'ai de l'embouteillage au point de m'envoyer un avertissement.  
J'ai même modifier dans les paramètres avancées la valeur DiskMaxIOSize, pareil.

non, jamais eu d'alertes de ce style ! ...mais je suis d'accord avec ton ESX : 191ms, c'est pas génial !
 
côté baie, tu as moyen d'avoir des stats d'accès à tes LUN ? Si elle voit des latences élevées, ca peut juste être une surcharge temporaire (backup, scan antivirus, ...). Si la baie ne voit rien par contre c'est étrange !

Stats d'accès aux lun : rien que du normal coté Datacore que je monitore en permanence et coté baies Dell MD3600 il y a un monitoring possible, il faut juste que je me penche dessus plus en profondeur.
 
Merci pour ton retour.

salut en ce qui concerne les alertes de latence j'ai la meme chose avec un cluster esx 5.5 et baie san md3200i le tout via du iscsi.

je ne trouve pas la raison de ces alertes je me suis rapproché de Dell a ce sujet j'ai fait tourner sur mon infra leur produit Dell DPACK censé analyser mon infra et envoyer a Dell les résultats. j'attends leur réponse.

Hello,
pour le message sur la latence, quelques pistes :

• vérifie si le message apparait pendant une opération sur les VM ou sur le stockage (snapshot, backup, dump database...)
• vérifie combien d'IO/s sont envoyées à ton SAN, et compare au bench que tu as fait avant de le mettre en production. Si tu n'as pas fait de bench, calcule le nombre d'IO max en fonction du nombre de disque et du RAID utilisé.
• la best practice est d'activer Storage IO control sur tous les datastores, et de paramétrer le seuil de déclenchement de l'algorithme en fonction du type de disque. De cette façon tu ne devrais pas dépasser les 30ms de latence...
• vérifie si l'une des VM prend toutes les ressources IO pour elle, genre 3000 IO/s en continu. Dans ce cas, soit il faut mettre en place une limit (500 ou 1000 par exemple), soit acheter plus de disque/cache, soit changer le comportement de l'appli sur la VM.
• enfin, vu que c'est du fibre channel, vérifie le taux de subscription par port sur le SAN. Si tout le monde cause en même temps, tu peux avoir des erreurs du type "queue full". Peu probable si il n'y a que 5 ESXi, car la plupart des SAN ont un qdepth de 1500 ou 2000 par port, mais j'en ai vu quelques uns à 512...

Merci Exo 7 pour tes pistes.
 
Par contre le storage i/o control est une option de l'édition enterprise Plus il me semble non, donc qui coute des $ou$ou$ ?
 
@ snipereyes : si tu as un retour de Dell après les analyses de DPACK (chez moi il bug leur soft) ça sera sympa de faire un retour. Merci d'avance.