optimisation de serveur NFS

Le 09-06-2009, ? propos de
optimisation de serveur NFS,
Eric Belhomme ?crivait dans fr.comp.os.linux.configuration :

Bonjour,

Bonjour,

Je suis en train de monter un filer avec les éléments suivants :
- carte mère supermicro X7SBU, avec CPU Intel Xeon E3110 et 4GB de RAM,
- controlleur RAID 3Ware 9650SE-12 avec 12 disques 750GB en RAID6
- 4 interfaces ethernet Gbit Intel (2x 82571EB, 2x 82573)
- GNU/Linux Debian Lenny (amd64)


Le but est d'en faire un serveur de fichiers. J'ai donc installé et
configuré NFS (paquet nfs-kernel-server), et j'ai notamment modifié le
nombre de daemons nfsd de 8 à 128.
J'ai aussi aggrégé les 4 interfaces en une seule 802.11ad de façon à
avoir un max de bande passante vers mon serveur.

Ceci fait, j'ai fais quelques tests en créant simultanément une 12aine
de fichiers de 100GB depuis une 12aine de machines reliées au même
switch, en Gbit :

[rico@kapa3 ~]$ time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat
104857600+0 enregistrements lus.
104857600+0 enregistrements écrits.

real 293m34.745s
user 0m9.419s
sys 170m30.693s

Il m'a fallu près de 5 heures pour générer 1,1TB sur le filer, soit une
moyenne de de 65KB/seconde... Pas terrible pour une machine qui devrait
plafonner à 4Gbps !!!

La bonne nouvelle, c'est que je dois avoir une bonne marge de
progression pour optimiser tout ca, la mauvaise, c'est que je ne vois
pas trop ce que je peux faire... Toute suggestion sera donc la bien venue !

Ma boule de cristal est en panne. Made in China, mauvaise
fabrication, toussa ;-)

On n'a _aucune_ information. La machine en question tourne avec
knfsd (c'est bien, c'est mieux que unfs ou userland-nfsd).

Je commencerais à mettre un NFSv3/TCP (pas de v4, parce que ce truc
est actuellement inutilisable sous Linux) avec des paquets de 32 Ko.
J'espère que le mode async est activé (parce que sinon ça risque de
ramouiller très fort). Je ne suis vraiment pas sûr que le fait de passer
à 128 threads soit une excellente idée surtout dans le cas d'un daemon
UDP (ça pourrait se justifier en TCP, et encore). Bref :
- 8 threads pour commencer
- mode async pour tout le monde
- NFSv3

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

Ici, avec le serveur que tu as vu la dernière fois (une U60 avec
deux procs à 450 MHz), j'ai des opérations de lecture et d'écriture sur
du raid6 soft à 12 Mo/s (réseau à 100 Mbps). Donc, il n'y a aucune
raison que cela ne fonctionne pas.

Autre chose, j'espère que le noyau est récent, parce qu'entre les
2.6.18 et 2.6.24 inclus, le NFS était particulièrement déconnant.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On Tue, 09 Jun 2009 16:18:16 +0200, Eric Belhomme
<{rico}+no/spam@ricospirit.net>:

time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat

Pendant que j'y pense : /dev/urandom est peut-être le goulot
d'étranglement.
Que donne cette ligne ?
time dd if=/dev/urandom bs=1k count4857600 of=/dev/null

Le 09-06-2009, Eric Belhomme <{rico}+no/spam@ricospirit.net> a écrit :

[rico@kapa3 ~]$ time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat
104857600+0 enregistrements lus.
104857600+0 enregistrements écrits.

real 293m34.745s
user 0m9.419s
sys 170m30.693s

Je pense que la source n'est pas la bonne (et c'est pour ça que je
redirige vers fcolc)
kevin@zipslack:~$ time dd if=/dev/urandom bs=1k count48 of=/dev/null
1048+0 enregistrements lus
1048+0 enregistrements écrits
1073152 octets (1,1 MB) copiés, 4,86159 s, 221 kB/s

real 0m4.969s
user 0m0.068s
sys 0m4.876s
kevin@zipslack:~$ time dd if=/usr/src/linux-2.6.29.tar.bz2 bs=1k count48
of=/dev/null
1048+0 enregistrements lus
1048+0 enregistrements écrits
1073152 octets (1,1 MB) copiés, 0,019132 s, 56,1 MB/s

real 0m0.104s
user 0m0.076s
sys 0m0.020s


L'on voit donc que chercher un fichier sur le disque va quand même largement
plus vite que piocher dans /dev/urandom ...

La bonne nouvelle, c'est que je dois avoir une bonne marge de
progression pour optimiser tout ca, la mauvaise, c'est que je ne vois
pas trop ce que je peux faire... Toute suggestion sera donc la bien venue !

J'ai fait des tests équivalent avec des images iso de
distribution linux. Ca tient encore dans la RAM si besoin, et c'est
varié dans son contenu.
--
Kevin

On Tue, 09 Jun 2009 16:18:16 +0200, Eric Belhomme
<{rico}+no/spam@ricospirit.net>:

Il m'a fallu près de 5 heures pour générer 1,1TB sur le filer, soit une
moyenne de de 65KB/seconde...

Va falloir commencer par détecter d'où le problème vient.

Commence par garder en permanence un "top" ouvert dans une fenêtre,
histoire de repérer les processus trop gourmands.

Si j'ai bien saisi, tu essaies de tester en même temps plusieurs
maillons d'une chaîne :
1- l'ensemble disques + contrôleur
2- NFS
3- le réseau (Ethernet + TCP/IP)

Pour savoir d'où vient le problème, il faut tester chaque partie
séparément.

Pour (1), c'est facile, il suffit de créer les fichiers séparément.
Pour (3) ou (1+3), nc et dd sont tes amis :

- sur le serveur :

for i in $(seq 1 10)
do
nc -l -p 400$i > $i.tmp &
done

(remplacer "$i.tmp" par "/dev/null" pour ne tester que le réseau)

- sur chaque client :

dd if=/dev/zero count=... | nc 192.168.0.x 400y

(où y est le numéro du client, de 1 à 10)

On Tue, 09 Jun 2009 16:18:16 +0200, Eric Belhomme
<{rico}+no/spam@ricospirit.net>:

time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat

Pendant que j'y pense : /dev/urandom est peut-être le goulot
d'étranglement.
Que donne cette ligne ?
time dd if=/dev/urandom bs=1k count4857600 of=/dev/null

Eric Belhomme a écrit :
...

La bonne nouvelle, c'est que je dois avoir une bonne marge de
progression pour optimiser tout ca, la mauvaise, c'est que je ne vois
pas trop ce que je peux faire... Toute suggestion sera donc la bien venue !

Quelles sont les options de montage côté clients ?

JKB a écrit :

Le 09-06-2009, ? propos de
optimisation de serveur NFS,
Eric Belhomme ?crivait dans fr.comp.os.linux.configuration :

Bonjour,

Bonjour,

Je suis en train de monter un filer avec les éléments suivants :
- carte mère supermicro X7SBU, avec CPU Intel Xeon E3110 et 4GB de RAM,
- controlleur RAID 3Ware 9650SE-12 avec 12 disques 750GB en RAID6
- 4 interfaces ethernet Gbit Intel (2x 82571EB, 2x 82573)
- GNU/Linux Debian Lenny (amd64)


Le but est d'en faire un serveur de fichiers. J'ai donc installé et
configuré NFS (paquet nfs-kernel-server), et j'ai notamment modifié le
nombre de daemons nfsd de 8 à 128.
J'ai aussi aggrégé les 4 interfaces en une seule 802.11ad de façon à
avoir un max de bande passante vers mon serveur.

Ceci fait, j'ai fais quelques tests en créant simultanément une 12aine
de fichiers de 100GB depuis une 12aine de machines reliées au même
switch, en Gbit :

quel type de switch

il en existe avec des firmwares bien pourri

[rico@kapa3 ~]$ time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat
104857600+0 enregistrements lus.
104857600+0 enregistrements écrits.

real 293m34.745s
user 0m9.419s
sys 170m30.693s

Il m'a fallu près de 5 heures pour générer 1,1TB sur le filer, soit une
moyenne de de 65KB/seconde... Pas terrible pour une machine qui devrait
plafonner à 4Gbps !!!

pour les perf locales cela donne quoi le systeme de fichier

euh il n'y a pas une petite erreur de calcul 65KB/S ;-)

La bonne nouvelle, c'est que je dois avoir une bonne marge de
progression pour optimiser tout ca, la mauvaise, c'est que je ne vois
pas trop ce que je peux faire... Toute suggestion sera donc la bien venue !

Ma boule de cristal est en panne. Made in China, mauvaise
fabrication, toussa ;-)

On n'a _aucune_ information. La machine en question tourne avec
knfsd (c'est bien, c'est mieux que unfs ou userland-nfsd).

Je commencerais à mettre un NFSv3/TCP (pas de v4, parce que ce truc
est actuellement inutilisable sous Linux) avec des paquets de 32 Ko.
J'espère que le mode async est activé (parce que sinon ça risque de
ramouiller très fort). Je ne suis vraiment pas sûr que le fait de passer
à 128 threads soit une excellente idée surtout dans le cas d'un daemon
UDP (ça pourrait se justifier en TCP, et encore). Bref :
- 8 threads pour commencer
- mode async pour tout le monde
- NFSv3

entierement d'accord pour la partie NFS

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

Ici, avec le serveur que tu as vu la dernière fois (une U60 avec
deux procs à 450 MHz), j'ai des opérations de lecture et d'écriture sur
du raid6 soft à 12 Mo/s (réseau à 100 Mbps). Donc, il n'y a aucune
raison que cela ne fonctionne pas.

Autre chose, j'espère que le noyau est récent, parce qu'entre les
2.6.18 et 2.6.24 inclus, le NFS était particulièrement déconnant.

Cordialement,

JKB

Philippe Weill a écrit :

quel type de switch

il en existe avec des firmwares bien pourri

C'est un Dell pc5448, configuré comme ceci :

interface range ethernet g41-44
no switchport mode
channel-group 2 mode auto
interface port-channel 2
switchport mode access
switchport access vlan 9


Je graphe avec snmp mon bond0 sur le serveur et le ch2 sur le switch, et
mes 2 courbes sont cohérentes

pour les perf locales cela donne quoi le systeme de fichier

hem... en fait j'ai pas testé :))

On n'a _aucune_ information. La machine en question tourne avec
knfsd (c'est bien, c'est mieux que unfs ou userland-nfsd).

Que veux-tu savoir exactement ?

Je commencerais à mettre un NFSv3/TCP (pas de v4, parce que ce truc
est actuellement inutilisable sous Linux) avec des paquets de 32 Ko.

Je n'ai pas précisé TCP dans l'automonteur... Il me semble que depuis
nfs v3 TCP est utilisé par défaut non ?
Pour ce qui est du V3, est-ce qu'il y a moyen de préciser à nfs de ne
faire que du V3 et rien d'autre ?

J'espère que le mode async est activé (parce que sinon ça risque de
ramouiller très fort). Je ne suis vraiment pas sûr que le fait de passer
à 128 threads soit une excellente idée surtout dans le cas d'un daemon
UDP (ça pourrait se justifier en TCP, et encore). Bref :
- 8 threads pour commencer
- mode async pour tout le monde
- NFSv3

oups :

rico@filer1:~$ cat /etc/exports
/data/fae *(rw,sync,no_subtree_check)

coté automonteur, j'ai fais dans la simplicité :

[rico@kapa4 ~]$ mount | grep filer1
filer1:/data/fae on /auto/filer1_fae type nfs (rw,addr=x.x.x.x)

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

Cette machine est destinée à être lourdement sollicitée, et aura besoin
de ses 4gbps de bande passante, donc il _FAUT_ que nfs se dépatouille
avec le bonding !

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

je me suis contenté de ça :
options bonding mode=4 miimon0 downdelay 0 updelay 0
Quel est l'intéret du xmit_hash_policy ?

Autre chose, j'espère que le noyau est récent, parce qu'entre les
2.6.18 et 2.6.24 inclus, le NFS était particulièrement déconnant.

Je suis en Lenny, donc avec le noyau 2.6.26-2-amd64 officiel de Debian.
On peut dire qu'il est relativement récent donc.
Qu'as-tu rencontré comme pb avec les 2.6.18 et 2.6.24 ?

--
Rico

Le 09-06-2009, ? propos de
Re: optimisation de serveur NFS,
Eric Belhomme ?crivait dans fr.comp.stockage :

Philippe Weill a écrit :

quel type de switch

il en existe avec des firmwares bien pourri

C'est un Dell pc5448, configuré comme ceci :

interface range ethernet g41-44
no switchport mode
channel-group 2 mode auto
interface port-channel 2
switchport mode access
switchport access vlan 9


Je graphe avec snmp mon bond0 sur le serveur et le ch2 sur le switch, et
mes 2 courbes sont cohérentes

pour les perf locales cela donne quoi le systeme de fichier

hem... en fait j'ai pas testé :))

On n'a _aucune_ information. La machine en question tourne avec
knfsd (c'est bien, c'est mieux que unfs ou userland-nfsd).

Que veux-tu savoir exactement ?

Version du noyau (des deux côtés), type de système de fichiers,
options de montages (locales et distantes), type de NFS.

Je commencerais à mettre un NFSv3/TCP (pas de v4, parce que ce truc
est actuellement inutilisable sous Linux) avec des paquets de 32 Ko.

Je n'ai pas précisé TCP dans l'automonteur... Il me semble que depuis
nfs v3 TCP est utilisé par défaut non ?
Pour ce qui est du V3, est-ce qu'il y a moyen de préciser à nfs de ne
faire que du V3 et rien d'autre ?

Oui.

J'espère que le mode async est activé (parce que sinon ça risque de
ramouiller très fort). Je ne suis vraiment pas sûr que le fait de passer
à 128 threads soit une excellente idée surtout dans le cas d'un daemon
UDP (ça pourrait se justifier en TCP, et encore). Bref :
- 8 threads pour commencer
- mode async pour tout le monde
- NFSv3

oups :

rico@filer1:~$ cat /etc/exports
/data/fae *(rw,sync,no_subtree_check)

Bon, ça n'aide pas.

coté automonteur, j'ai fais dans la simplicité :

[rico@kapa4 ~]$ mount | grep filer1
filer1:/data/fae on /auto/filer1_fae type nfs (rw,addr=x.x.x.x)

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

Cette machine est destinée à être lourdement sollicitée, et aura besoin
de ses 4gbps de bande passante, donc il _FAUT_ que nfs se dépatouille
avec le bonding !

J'ai toujours fait sans en faisant des sous-réseaux indépendants. Je
ne répondrais donc pas à la question.

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

je me suis contenté de ça :
options bonding mode=4 miimon0 downdelay 0 updelay 0
Quel est l'intéret du xmit_hash_policy ?

Autre chose, j'espère que le noyau est récent, parce qu'entre les
2.6.18 et 2.6.24 inclus, le NFS était particulièrement déconnant.

Je suis en Lenny, donc avec le noyau 2.6.26-2-amd64 officiel de Debian.
On peut dire qu'il est relativement récent donc.
Qu'as-tu rencontré comme pb avec les 2.6.18 et 2.6.24 ?

_Entre_ les deux noyaux. Des fonctionnements erratiques (plantages
inexpliqués, gestion des droits exportés à la limite de l'absurde, bref,
que des trucs pas utilisables en production. J'ai écrit des patches,
mais je n'ai jamais pu suivre l'instabilité de l'API des noyaux 2.6...).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Eric Belhomme wrote:

Bonjour,

Je suis en train de monter un filer avec les éléments suivants :
- carte mère supermicro X7SBU, avec CPU Intel Xeon E3110 et 4GB de
RAM, - controlleur RAID 3Ware 9650SE-12 avec 12 disques 750GB en RAID6
- 4 interfaces ethernet Gbit Intel (2x 82571EB, 2x 82573)
- GNU/Linux Debian Lenny (amd64)


Le but est d'en faire un serveur de fichiers. J'ai donc installé et
configuré NFS (paquet nfs-kernel-server), et j'ai notamment modifié le
nombre de daemons nfsd de 8 à 128.
J'ai aussi aggrégé les 4 interfaces en une seule 802.11ad de façon à
avoir un max de bande passante vers mon serveur.

......

Il m'a fallu près de 5 heures pour générer 1,1TB sur le filer, soit
une moyenne de de 65KB/seconde... Pas terrible pour une machine qui
devrait plafonner à 4Gbps !!!

Vu la marge disponible je tenterai de "désagréger" les interfaces Ethernet.
J'ai toujours vu des bonnes perfs réseaux avec les nunux donc tant que tu ne
sature pas une interface à au moins 80% c'est qu'il y a autre chose qui
coince (avec les réserves afférentes au switch au bout de tout ça, parce
qu'il va quand même s'en prendre plein les ports !!).
Au pire débranche tous les fils sauf un ;)

Tu devrais pouvoir atteindre du 80~90 Mo/s sur du gros fichier, et sans
forcer ;-))

Essais peut être aussi un transfert entre un disque USB branché direct sur
ton serveur et sa grappe en RAID, des fois que ;))

Tu es sûr que tous les disques sont en bon état ? L'alimentation pour tout
ça est à la hauteur ? (Tu dois au moins tirer 200 W rien que pour les DD !!)
--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!