stabilit

Le
Eric Belhomme
Bonjour,

Je me pose des questions sur la stabilité de Linux lorsqu'on l'utilise en
tant que serveur NFS sur des archi amd64 NUMA (en gros Nehalem et
supérieur)

Le contexte :

Différents serveurs de fichiers installés en Debian Squeeze/amd64. Tous
utilisent des cartes RAID 3ware 9650-12 ou 9650-16, avec BBU, et ont
leurs interfaces Gbit aggrégées en 802.1ad
Le détail des machines :

- filer1 : Supermicro X7SBU : 1 Xeon E3110, 4G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer2 : Supermicro X8DTU : 2 Xeon E5520, 6G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer3 : Supermicro X8DTU : 2 Xeon E5620, 12G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer4 : Supermicro X8DT3 : 2 Xeon E5506, 6G de RAM, 12 disques en
RAID0 (stripes de 64k) formatté en XFS avec su et sw adéquat

Le problème constaté : sur les machines disposant d'un bus QPI, une
utilisation intensive de NFS fait monter la charge système à des valeurs
*très* élevées, genre 70. Arrivé à ce stade, ça se termine en général
avec des Kernel Oops en général dans les modules xfs ou nfs.
Le problème semble cependant plus lié à nfs, car on constate les mêmes
problèmes en utilisant ext3 à la place de xfs.
Un fois qu'on en est là, on ne peut plus rien faire : nfsd ne répond pas
et est impossible à tuer, on ne peut pas décharger les modules puisqu'ils
sont toujours "in use". il ne reste qu'à utilier les sysrq keys pour
forcer un sync et rebooter sauvagement

Sur ma machine pré-nehalem (filer1) qui est poussive en comparaison des
autres serveurs, la machine peut monter en charge de la même façon, mais
ne crashe jamais.

J'ai eu beau googler, je n'ai rien trouvé qui fasse état de problèmes de
stabilité de NFS sur les "nouvelles" archi Intel. Vous auriez des pistes ?

merci,

--
Rico
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Emmanuel Florac
Le #23887961
Le Thu, 20 Oct 2011 15:47:51 +0000, Eric Belhomme a écrit:

Bonjour,

Je me pose des questions sur la stabilité de Linux lorsqu'on l'utilise
en tant que serveur NFS sur des archi amd64 NUMA (en gros Nehalem et
supérieur)...



Ben non, ça inclut aussi tous les Opteron :)

Le problème constaté : sur les machines disposant d'un bus QPI, une
utilisation intensive de NFS fait monter la charge système à des valeurs
*très* élevées, genre 70. Arrivé à ce stade, ça se termine en général
avec des Kernel Oops en général dans les modules xfs ou nfs.



Question con, combien de processus nfsd? Combien de clients simultanés?
Quel noyau? Est-ce que le noyau est optimisé NUMA? Si le noyau n'est PAS
un noyau explicitement NUMA, tu vas au devant de gros problèmes.

J'ai eu beau googler, je n'ai rien trouvé qui fasse état de problèmes de
stabilité de NFS sur les "nouvelles" archi Intel. Vous auriez des pistes
?




Rien en particulier, mais si le kernel n'est pas NUMA, la localité de la
mémoire n'est pas respectée, et tu peux avoir des délais d'attentes très
longs lors des changements de contexte processeur. Pire, si ton nombre de
clients/nombre de démons/nombre de coeurs n'est pas vraiment optimisé...
la migration non contrôlée d'un démon d'un processeur à l'autre peut
prendre un temps quasi infini à l'échelle du processeur.

Si l'utilisation NFS est intense, je te conseille de surveiller (avec
nfsstat) le nombre de clients simultanés, et de faire tourner AUTANT de
nfsd que de clients (/etc/defaults/nfs-kernel-server). Sauf si tu n'as
pas beaucoup de coeurs et/ou de RAM.

Cependant sur Opteron (ce que j'utilise préférentiellement), avec 4
coeurs et 64 démons NFS je sers facilement 400 à 500 clients. Mais
toujours avec un noyau NUMA.

Si tu aimes vivre dangereusement tu peux essayer un noyaux NUMA compilé
par mes soins je te donnerai l'url :)

--
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning.
Rich Cook
Emmanuel Florac
Le #23888061
Le Thu, 20 Oct 2011 19:56:09 +0000, Emmanuel Florac a écrit:


Si tu aimes vivre dangereusement tu peux essayer un noyaux NUMA compilé
par mes soins je te donnerai l'url





Tu peux essayer celui-là:
<http://update.intellique.com/repository/pool/storiq3/unstable/amd64/
kernel-image-2.6.35.13-storiq64-i7_2_amd64.deb>

J'ai un 3.0.4 qui marche du feu de dieu quelque part (nettement plus
rapide que le 2.6.35...) faut que je l'uploade :)

--
"If you're not paying for it, you're not the customer; you are
the product being sold."
Eric Belhomme
Le #23888351
Le Thu, 20 Oct 2011 19:56:09 +0000, Emmanuel Florac a écrit :

Ben non, ça inclut aussi tous les Opteron :)



oui mais non : je ne parle que de plate-formes Intel ;)

Question con, combien de processus nfsd? Combien de clients simultanés?
Quel noyau? Est-ce que le noyau est optimisé NUMA? Si le noyau n'est PAS
un noyau explicitement NUMA, tu vas au devant de gros problèmes.



64, mais j'ai aussi essayé avec moins (32) et le même résultat. Pour le
noyau, j'ai tenté avec le noyau stock debian Squeeze (2.6.32-5) ainsi
qu'un noyau recompilé par mes soins (un Vanilla 2.6.39) et ça ne change
rien. J'avais opté pour le 2.6.39 car j'ai lu dans les changelogs du
noyau qu'il y avait eu de grosses améliorations sur nfs *et* xfs entre le
2.6.36 et le 2.6.39...

Ah, et NUMA semble actif :

:~$ dmesg|grep -i numa
[ 0.000000] NUMA: Initialized distance table, cnt=2
[ 0.000000] NUMA: Node 0 [0,a0000) + [100000,c0000000) -> [0,c0000000)
[ 0.000000] NUMA: Using 32 for the hash shift.
[ 2.032544] pci_bus 0000:00: on NUMA node 0 (pxm 0)

Rien en particulier, mais si le kernel n'est pas NUMA, la localité de la
mémoire n'est pas respectée, et tu peux avoir des délais d'attentes très
longs lors des changements de contexte processeur. Pire, si ton nombre
de clients/nombre de démons/nombre de coeurs n'est pas vraiment
optimisé... la migration non contrôlée d'un démon d'un processeur à
l'autre peut prendre un temps quasi infini à l'échelle du processeur.



A priori ce n'est pas le cas.

Si l'utilisation NFS est intense, je te conseille de surveiller (avec
nfsstat) le nombre de clients simultanés, et de faire tourner AUTANT de
nfsd que de clients (/etc/defaults/nfs-kernel-server). Sauf si tu n'as
pas beaucoup de coeurs et/ou de RAM.



??? comment tu vois ça ? on doit pas avoir le même nfsstat (ou tu sais
mieux t'en servir que moi, ce qui est plus probable)

Cependant sur Opteron (ce que j'utilise préférentiellement), avec 4
coeurs et 64 démons NFS je sers facilement 400 à 500 clients. Mais
toujours avec un noyau NUMA.




Je me suis souvenu que tu préfèrais la plate-forme Opteron pour tes
filers, alors je viens de me faire livrer une config avec 2 Opteron 6128
et 16G de RAM : on va voir si elle résiste mieux au stress que les Xeon

Si tu aimes vivre dangereusement tu peux essayer un noyaux NUMA compilé
par mes soins je te donnerai l'url :)



Je vais tenter. Tu l'as pas optimisé que pour AMD au moins ?

--
Rico
Emmanuel Florac
Le #23888921
Le Thu, 20 Oct 2011 21:32:56 +0000, Eric Belhomme a écrit:


Je vais tenter. Tu l'as pas optimisé que pour AMD au moins ?



J'en ai un optimisé pour AMD mais celui que j'ai posté est optimisé pour
i7 et suivants. Pour ce qui est du nfsstat je vais re-regarder...

--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
George Bernard Shaw
Eric Belhomme
Le #23889871
Le Fri, 21 Oct 2011 07:09:39 +0000, Emmanuel Florac a écrit :


J'en ai un optimisé pour AMD mais celui que j'ai posté est optimisé pour
i7 et suivants. Pour ce qui est du nfsstat je vais re-regarder...



Ce sont des noyaux Vanilla ou des noyaux Debian que tu recompiles ?
tes .config m'intéressent ;)

--
Rico
JKB
Le #23890831
Le 20 Oct 2011 15:47:51 GMT,
Eric Belhomme
Bonjour,



Bonsoir,

Je me pose des questions sur la stabilité de Linux lorsqu'on l'utilise en
tant que serveur NFS sur des archi amd64 NUMA (en gros Nehalem et
supérieur)...



Je fais cela depuis des années sur des Opterons et des Sparcs. Ça ne
pose pas de problème particulier en NFSv2/UDP ou NFSv3/TCP ou UDP.
Je n'ai jamais eu l'occasion de monter du v4, plus exactement si,
mais entre un client linux et un serveur solaris et, comment dire,
les problèmes que j'ai eu n'étaient pas de l'ordre de la stabilité
;-)

Le contexte :

Différents serveurs de fichiers installés en Debian Squeeze/amd64. Tous
utilisent des cartes RAID 3ware 9650-12 ou 9650-16, avec BBU, et ont
leurs interfaces Gbit aggrégées en 802.1ad
Le détail des machines :

- filer1 : Supermicro X7SBU : 1 Xeon E3110, 4G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer2 : Supermicro X8DTU : 2 Xeon E5520, 6G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer3 : Supermicro X8DTU : 2 Xeon E5620, 12G de RAM, 12 disques en
RAID6 (stripes de 64k) formatté en XFS avec su et sw adéquat
- filer4 : Supermicro X8DT3 : 2 Xeon E5506, 6G de RAM, 12 disques en
RAID0 (stripes de 64k) formatté en XFS avec su et sw adéquat

Le problème constaté : sur les machines disposant d'un bus QPI, une
utilisation intensive de NFS fait monter la charge système à des valeurs
*très* élevées, genre 70. Arrivé à ce stade, ça se termine en général
avec des Kernel Oops en général dans les modules xfs ou nfs.
Le problème semble cependant plus lié à nfs, car on constate les mêmes
problèmes en utilisant ext3 à la place de xfs.



Jamais vu ce genre de problème. Cela ressemble surtout à un problème
réseau. N'y aurait-il pas des processus en état 'D' ?

Un fois qu'on en est là, on ne peut plus rien faire : nfsd ne répond pas
et est impossible à tuer, on ne peut pas décharger les modules puisqu'ils
sont toujours "in use". il ne reste qu'à utilier les sysrq keys pour
forcer un sync et rebooter sauvagement...

Sur ma machine pré-nehalem (filer1) qui est poussive en comparaison des
autres serveurs, la machine peut monter en charge de la même façon, mais
ne crashe jamais.

J'ai eu beau googler, je n'ai rien trouvé qui fasse état de problèmes de
stabilité de NFS sur les "nouvelles" archi Intel. Vous auriez des pistes ?



Je regarderais du côté du réseau. Au fait, quelle version de NFS, et
surtout quel serveur et quel client ? Il y a des implantations de
NFS particulièrement boguées.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Emmanuel Florac
Le #23891761
Le Fri, 21 Oct 2011 11:21:23 +0000, Eric Belhomme a écrit:

]

Ce sont des noyaux Vanilla ou des noyaux Debian que tu recompiles ? tes
.config m'intéressent



Vanilla pur et dur. Pour le .config, télécharge le paquet, il est
dedans :)

--
a script is what you give the actors, a program is what you give the
audience.
Ada Lovelace according to Larry Wall
Publicité
Poster une réponse
Anonyme