Bonjour,
Je patine un peu sur un problème de charge sur un Dell r300 équipé d'un contrôleur SAS Fusion MPT / LSISAS1068E.
Dès que l'on lance un index des fichiers, que ça soit par le client retrospect ou rsync, la charge monte en peu à peu jusqu'à plus de 200... et là les connexions réseau SSH et autres tombent.
Vu que la sauvegarde de la machine est tout de même nécessaire ;)... je m'acharne depuis plusieurs heures à essayer de trouver le pourquoi de ce record... sans grand succès jusqu'à présent.
Le même script rsync sur une autre machine assez proche au niveau des versions de packages Debian, ayant plus de données et un processeur beaucoup moins puissant mais équipée d'un contrôleur Intel ICH ne pose pas de problèmes. D'ailleurs dans les deux cas le processeur est très très loin de la surcharge.
Le problème se pose véritablement au niveau de l'accès disque avec un taux d'io wait extrêmement élevé.
Je pense donc que le problème se situe au niveau des drivers du contrôleur SAS. Mais google n'est pas mon ami aujourd'hui et je ne trouve pas d'informations.
J'ai tenté une mise à niveau vers un noyau plus récent (le 2.6.32-5-vserver-686-bigmem de Squeeze) mais cela ne change rien au problème. A la base j'utilisais le 2.6.26-2-vserver-686-bigmem de Lenny.
Bref si quelqu'un ici est familier de ces contrôleurs raid ou a des pistes à me proposer je suis preneur.
Je télécharge actuellement la dernière version des drivers sur le site de LSI pour tenter une compilation manuelle mais vu que le driver est prévu pour une RHEL je sens que je n'ai pas fini de m'amuser.
# je vais surement dire une betise
Posté par NeoX . Évalué à 3.
et sans PAE (bigmem)
car d'apres : http://packages.debian.org/fr/squeeze/linux-image-2.6.32-5-v(...)
c'est un kernel 32 bits, avec extensions PAE pour gerer plus de 4Go de ram
mais aussi avec les extensions de virtualisation (vserver et xen)
vu ta machine tu dois pouvoir tester avec le meme kernel mais "simplifié"
http://packages.debian.org/fr/squeeze/kernel/linux-image-2.6(...)
qui va supporter le 64bits (donc la memoire >4Go)
mais qui n'apporte pas la virtualisation vserver
[^] # Re: je vais surement dire une betise
Posté par Chris K. . Évalué à 1.
Pour le noyau 64 bit malheureusement mon install de Debian est en i386 donc c'est mort. (car migration depuis une machine équipée d'un P4 D).
Merci.
[^] # Re: je vais surement dire une betise
Posté par NeoX . Évalué à 3.
mais comme ton souci semble etre sur les I/O, ca ne devrait pas trop posé de soucis.
Si ca marche et pour remettre les fonctionnalités qui te manqueraient il faudra ensuite essayer le noyau
2.6.32-5-686-bigmem (donc avec juste PAE)
puis
2.6.32-5-vserver-686 (sans PAE mais avec vserver)
ou en version 2.6.26 si tu souhaites rester en lenny (mais squeeze est bientot sortie)
[^] # Re: je vais surement dire une betise
Posté par Chris K. . Évalué à 1.
C'est donc la surcouche VServer ou Xen qui pose problème. Cette aprem petite recherche google pour voir le le problème est connu d'un coté ou de l'autre et si besoin recompilation du noyau avec uniquement VServer pour voir si ca passe. En ettandant je vais quand même aller manger.
Un grand merci à toi NeoX, c'était une très bonne piste.
[^] # Re: je vais surement dire une betise
Posté par Chris K. . Évalué à 1.
J'ai recompilé un 2.6.36.3 manuellement avec VServer et PAE et ça marche aux petits oignons je n'ai pas dépassé les 3.50 de load même si iostat peut monter à 30% durant la phase d'indexation (en fait tout comme le 2.6.26-2-686-bigmem de Debian sans les extensions Xen et VServer).
Alors pour info voci les embuches de l'après midi :
Pour utiliser la méthode de packaging debian pour compiler des noyaux de kernel.org dont la version est supérieure à 2.6.32, il faut patcher kernel-package comme indiqué ici : http://ubuntuforums.org/showpost.php?p=9000573&postcount(...) .
Et également recompiler utils-vserver avec la dernière version disponible pour éviter d'avoir un vc_set_sched(): Function not implemented au lancement des VServers.
Après ça tout roule.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.