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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
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
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
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 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."
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."
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 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
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 :
rico@dove:~$ 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 ?
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 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
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
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 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
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 ;)
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 20 Oct 2011 15:47:51 GMT, Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
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
Le 20 Oct 2011 15:47:51 GMT,
Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
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
Le 20 Oct 2011 15:47:51 GMT, Eric Belhomme <rico-{nntp}@ricozome.net> écrivait :
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 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
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
