Problème de mémoire et vitesse de transfert CIFS SMB

[littlejohn75]

Si le swap écrit sur mon disque à plateaux sur lequel je transfère mes fichiers cela va absolument tout ralentir le transfert et le système car le disque aura une queue avec beaucoup de latence.

Je vous invite à réaliser des tests grandeur nature pour étayer ce genre d’affirmations. Vous pourrez alors évaluer le ralentissement et son caractère inéluctable (vous dites ça va absolument tout ralentir le transfert).

C’est pour ça que le swap n’a plus trop raison d’être actuellement avec beaucoup de ram et des disques rapides,

Même avec beaucoup de mémoire vive, certains estiment Why You Should Almost Always Add Swap Space qu’il est bon de prévoir du swap.

Pourrait-on avoir plus de précisions sur la configuration utilisée, la manière de procéder ? A tout le moins les commandes utilisées pour réaliser les transferts, les commandes pour déterminer les débits, les caractéristiques des systèmes de fichiers source et destinations (et des fichiers transférés ), les commandes pour déterminer la charge système (source et destination ) ( free -m| ,uptime` , …)
Quelle est la fréquence des transferts de fichiers ? Combien de fois par heure, jour, ?

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

---

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

[nings]

• Si j’active le swap est qu’il n’est pas utilisé cela ne va rien changer mais un disque à plateaux n’est pas capable de lire et écrire en même temps. Les têtes doivent se déplacer pour faire autre chose puis revenir pour lire les données. Il y a un buffer sur le disque mais il montre vite ces limites en ajoutant plusieurs secondes de latence. Lancer un “dd” sur le disque ainsi qu’un “ioping” d’un bête secteur 4k et vous verrez qu’il peut mettre jusqu’à 2sec pour récupérer un seul secteur de 4k de données. (le temps de déplacement des têtes)

• Le OOM killer ne semble pas faire effet ou pas assez vite car j’ai déjà eu plusieurs fois le système qui ne répondait plus du tout lorsqu’il était trop sollicité. Ni localement, ni en réseau malgré un swap sur certaines machines.
  Tous les transferts sont fait via l’interface graphique et c’est aussi un compteur graphique qui me montre le débit en temps réel “Netspeed”.
  Sinon, je ne vois pas trop pour les questions sur le système de fichier et les fichiers transférés, le système de fichiers et le hardware tiennent les débits en utilisant deux protocoles différents sans problème donc cela n’a pas vraiment d’importance vu qu’ils atteignent du 120mo/sec sans problème. Pour le type de fichiers, je ne vois pas trop non plus la différence entre un zip, avi, iso de 100go mais oui c’est un seul et unique fichier de plusieurs go.
  Je ne peux pas dissocier le transfert d’un fichier d’un autre flux sur le réseau donc très difficile d’estimer la chose mais plusieurs to par mois sur les interfaces en tx comme en rx.

Mais ma principale question et est-ce que vous avez les mêmes problèmes ?
Tant au niveau samba qui devrait être un des protocoles les plus rapides sinon quelle est votre config côté serveur et client pour obtenir les débits max en 1gb donc ~120mo/sec ?
Ainsi que le débit lors d’un transfert dans les deux sens en simultanés, vous arrivez à avoir du 120mo/sec en up et down avec samba/nfs/cifs ?
Et vous utilisez les cgroup pour limiter l’utilisation de la mémoire de certains processus ? (celle-ci dépend de la version du kernel, les versions plus anciennes utilisent la ram directement “used” tandis que les plus récentes utilisent le “cached/buffer” à la place)

[littlejohn75]

un disque à plateaux n’est pas capable de lire et écrire en même temps.

Pourriez-vous définir « en même temps » ?

Il y a un buffer sur le disque mais il montre vite ces limites en ajoutant plusieurs secondes de latence.

J’ai franchement beaucoup de mal à vous suivre. C’est quoi exactement qui ajoute plusieurs secondes de latence ?

“ioping”

Merci de signaler cet outil que je connaissait pas.

peut mettre jusqu’à 2sec pour récupérer un seul secteur de 4k de données. (le temps de déplacement des têtes)

2 secondes : Bigre. Je suis à peu près sûr que même le disque dur de mon Amstrad 512 (de capacité 20Mo ) fait beaucoup mieux que cela. Peut-être 50 à 80 msec, soit 0.050 à 0.08 secondes, plus d’un ordre de grandeur de différence.
Avec un disque actuel

fp2@debpacha:~$ ioping /data/download/
4 KiB <<< /data/download/ (ext4 /dev/dm-2): request=1 time=99.5 us (warmup)
4 KiB <<< /data/download/ (ext4 /dev/dm-2): request=2 time=204.6 us
4 KiB <<< /data/download/ (ext4 /dev/dm-2): request=3 time=173.7 us
4 KiB <<< /data/download/ (ext4 /dev/dm-2): request=4 time=203.7 us
4 KiB <<< /data/download/ (ext4 /dev/dm-2): request=5 time=169.8 us
^C
--- /data/download/ (ext4 /dev/dm-2) ioping statistics ---
4 requests completed in 751.9 us, 16 KiB read, 5.32 k iops, 20.8 MiB/s
generated 5 requests in 4.76 s, 20 KiB, 1 iops, 4.20 KiB/s
min/avg/max/mdev = 169.8 us / 188.0 us / 204.6 us / 16.3 us
fp2@debpacha:~$ ioping -c 4 -R  /data/download/

--- /data/download/ (ext4 /dev/dm-2) ioping statistics ---
3 requests completed in 10.1 ms, 12 KiB read, 295 iops, 1.16 MiB/s
generated 4 requests in 17.1 ms, 16 KiB, 233 iops, 935.7 KiB/s
min/avg/max/mdev = 156.7 us / 3.38 ms / 5.38 ms / 2.30 ms
fp2@debpacha:~$ 

En déplacement aléatoire on arrive à 3 ou 5 millisecondes, vous vous trompez de 3 ordres de grandeur.

Tous les transferts sont fait via l’interface graphique et c’est aussi un compteur graphique qui me montre le débit en temps réel “Netspeed”.

Le problème avec tous ces machins graphiques et en particulier avec ce compteur graphique qui n’a pas de nom, c’est qu’on est fasciné par les chiffres qui s’affichent, on voit clairement que cela "tourne autour’ de 2 (par exemple entre 1.96 et 2.08 ) mais 2 quoi ? That is the question. On a oublié l’unité et confondu 2 millisecondes avec 2 secondes.
De plus, ces logiciels ont une empreinte mémoire non négligeable et sont donc de piètres outils pour estimer et analyser finement les nombreux facteurs qui interviennent dans la performance du système. ( voir la notion de Bug logiciel inhabituel )

plusieurs to par mois sur les interfaces en tx comme en rx.

Avec si peu d’information sur le réseau il est impossible de donner le moindre avis. Parmi les milliards d’octets qui transitent chaque jour, vous êtes sûr qu’ils sont tous légitimes ? qu’il n’y en a pas qui circulent à des heures indues ?
Je peux tout au plus vous conseiller d’installer atop pour avoir un point sur la charge système ( CPU, IO, …) toutes les 20 minutes et de générer avec atopsar des rapports d’utilisation de ces machines qui brassent tant d’informations.
Bon, c’est en ligne de commandes mais au moins cela fait le job
En supposant que les serveurs ont plusieurs interfaces réseau, lisez la documentation sur le module bondingdu noyau et en particulier sur l’Agrégation de liens IEE 802.3ad
en combinaison avec un commutateur administrable.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

---

F. Petitjean
Ingénieur civil du Génie Maritime.

Linux: the operating system with a CLUE… Command Line User Environment.
– seen in a posting in comp.software.testing

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

[Clochette]

Je ne peux pas dissocier le transfert d’un fichier d’un autre flux sur le réseau donc très difficile d’estimer la chose mais plusieurs to par mois sur les interfaces en tx comme en rx.

Avec une estimation de plusieurs To par mois c’est pas avec un disque qu’il faut compter mais avec une baie de disque voir avec du SAN ou du NAS selon l’usage.

Sur du cluster de Synology nous parvenons à monter sur un taux de 520 mo/s (stockage sur SSD) en random depuis des montage NFS sur une plateforme Xen nous avons même l’idée de test avec du cache sur NVME).
Nous n’utiliserons pas du CIFS et si le besoin de performance est là nous devrions nous orientez vers autre chose tel que de la FABRIC …

CIFS c’est vraiment pas le top en environnement GNU/Linux

[nings]

@littlejohn
Un HDD à plateaux est fait pour faire une opération à la fois ensuite il y a une “queue” qui s’allonge en fonction du nombre de requête. Si vous lancez une opération qui prend 5h, il va faire en parallèle les autres requêtes et c’est là qu’il va prendre un temps fou car le tête doit faire autre chose et les têtes ne bougent (bougeaient) pas indépendemment l’une de l’autre ce qui augmente la latence qui est en partie comblé par le buffer mais je vous laisser aller vous renseignez sur Internet concernant la technologe des HDDs.

Mais voici ce que la donne en visuel un disque “busy” au niveau temps de réponse :

2sec est un bon temps de réponse correct, 6sec sur un disque “récent” est catastrophique.
Je n’ai jamais fait de test sur un disque à plateaux mais j’ai les temps de réponse que vous citez sur un SSD. Vous êtes sûr que vous avez un bon vieux disque à plateaux sans raid, cache, etc ?

Le compteur graphique utilise le compteur de l’interface réseau après je peux bien aller vérifier sur le switch mais je trouve un peu inutile car tout semble précis et correct.
A priori non car ils sont tout le temps actif et je n’ai jamais 10go de mémoire qui parte en cache avec ces compteurs
Un PC avec une interface 1GO et un serveur avec une interface 1Go peut faire du 2Go en full duplex. 1Go dans un sens et 1G dans l’autre sens et c’est tout ce que je demande. Si je veux du 10go, je passe tout en 10go mais cela ne me sert à rien. J’aimerais juste arriver à utiliser mon matériel à 100% ce qui peut être fait en utilisant 2 protocoles différents ce que je trouve vraiment dommage et plutôt étrange alors que cela devrait fonctionner en utilisant le même.

[nings]

@Clochette
Une interface 1Go de secondes utilisé 24/24h est capable de transférer ~311to par mois dans un seul sens donc plusieurs to, c’est plutôt faible comme utilisation mensuel

520mo/sec donc sur une interface 10go ou sur plusieurs liens aggrégés de 1go ?
Et vous avez essayé en même temps de transférer des données dans l’autre sens ?
Vous arrivez à 520mo/sec down et up sur un lien 10Go (ou aggrégé) ?

Même en NFS, je n’y arrive pas le débit ne tient pas et vous arrivez à gérer les droits en NFS ?
C’est pour cela que j’étais parti sur samba à la base, il me semblait plus simple de gérer les droits mais vu les perfs, j’ai fait mes montages en cifs pour finir.

[littlejohn75]

J’aimerais juste arriver à utiliser mon matériel à 100%

Pourquoi pas ? Nous attendons toujours les informations relatives à ce matériel. Du genre combien de machines de tel modèle (avec des liens vers les pages des constructeurs ), caractéristiques techniques des machines et des équipements réseau, etc …
D’autre part, quel est le but réel de faire tourner le bouzin à 100 % ? de transférer chaque jour des centaines de milliards d(octets d’une machine à une autre ? Pourquoi donc ?
Vous travaillez dans le séquençage du génome ? Vous avez détourné les images de vidéo surveillance de votre ville ?

1Go

2Go en full duplex.

J’ai bien peur que vous êtes trop jeune pour avoir connu les anciennes technologies de cartes Ethernet avec des débits théoriques de 10 Mb/s (10 megabits/sec) pour l’Ethernet et de 100Mb/s pour le “Fast Ethernet”.
Les cartes “giga” ont un débit de 1000Mb/s, ou 1 giga bits/sec Gb/s. SVP n’écrivez pas “Go” car on va lire giga octets ou

Go = gigo  = garbage in, garbage out

Vous êtes sûr que vous avez un bon vieux disque à plateaux sans raid, cache, etc ?

Ce dont je suis sûr, c’est que vous n’avez pas pris la peine de publier les sorties des commandes ioping comme je l’ai fait et que je n’ai pas mis les sorties concernant le SSD qui équipe mon portable acheté il y a 2 ans, où les résultats étaient nettement meilleurs.

ce qui peut être fait en utilisant 2 protocoles différents

Quelle est votre définition de protocole dans ce contexte ?

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

---

F. Petitjean
Ingénieur civil du Génie Maritime.

“Have you seen the new Ubuntu release?”
“Nah, I’m not into Pokemon.”

[sk4hrr]

Tu as quoi comme débit en NFS ?

Je ne vais pas pouvoir te montrer les statistiques là tout de suite, mais en gros oui, je sature facilement mon lien Gigabit. Toutefois derrière il s’agit de RAID-Z2 avec 8 disques. Sans compter que le serveur dispose de 32Go de RAM et de 10Go swap.

Si vous lancez une opération qui prend 5h

L’opération va prendre 5h, mais il n’est pas possible de le savoir à l’avance étant donné que si le disque est sollicité par une autre tâche, le temps va s’allonger. Faut pas prendre le problème à l’envers.

Un PC avec une interface 1GO et un serveur avec une interface 1Go peut faire du 2Go en full duplex.

Je fais peut-être erreur, mais pour moi “full duplex” ne veut pas dire ça. Cela veut dire que les deux périphérique peuvent parler en même temps sur le transport. Par contre, une carte Gigabit fournit en tout et pour tout 1 Gbps. (arrêtez moi si je me trompe)

Une interface 1Go de secondes utilisé 24/24h est capable de transférer ~311to par mois dans un seul sens donc plusieurs to, c’est plutôt faible comme utilisation mensuel

Bon comme le dit @littlejohn75, arrêtes d’utiliser “Go” ! Comme tu l’as dit au début, sur du Gigabit tu peux avoir au maximum 120 Mo/s ! En revanche, ton calcul est bon, en théorie.

520mo/sec donc sur une interface 10go ou sur plusieurs liens aggrégés de 1go ?

Donc en fait lorsque tu multiplie par 10, ça te donne un chiffre complètement différent ? Si tu as 120 Mo/s en Gigabit, ça donne du 1.2 Go/s en TenGigabit. Encore une fois, tout ça c’est de la théorie !

vous arrivez à gérer les droits en NFS ?

En NFS, ce sont les droits Unix, tout simplement. Contrairement à Samba où tu peux foutre un beau merdier avec les droits Windows.

J’utilise pas mal le mot “théorie” parce que cela dépend de beaucoup de choses. Chaque élément de la chaine peut constituer un goulot d’étranglement: cpu, mémoire, réseau, disque, switch, câble, distance, perturbation… Bref, lorsqu’on voit certains test en laboratoire, on voit clairement qu’ils sont dans des conditions qui n’existent que dans le dit labo.

[Clochette]

520mo/sec donc sur une interface 10go ou sur plusieurs liens aggrégés de 1go ?
Et vous avez essayé en même temps de transférer des données dans l’autre sens ?
Vous arrivez à 520mo/sec down et up sur un lien 10Go (ou aggrégé) ?

C’est du lien agrégée, mais la limitation viens plus en fait du controller et du matériel à l’autre bout.

Une interface 1Go de secondes utilisé 24/24h est capable de transférer ~311to par mois dans un seul sens donc plusieurs to, c’est plutôt faible comme utilisation mensuel

Ce que je relève c’est quel e transit de plusieurs To par mois implique une utilisation très chargé, il est rare de voir un serveur surchargé des liens giga là où je travaille, et les liens 10Go sont plus là pour prendre en charge les pics d’activité sans avoir de goulot d’étranglement.

Je vois souvent des clients commandé des infrastructure de porcin et qui n’en exploite finalement à peine 1/3 des ressources, et généralement à ce que l’on pourrais croire ce sont plus les I/O qui sont véritablement limitantes.

Pour aller au plus simple en local tu la machine peux fournir quel taux d’écriture ?

[nings]

@littlejohn75
Ca ne change absolument rien que le disque soit un WD/Seagate/Hitachi/Toshiba s’est juste une perte de temps. Le matériel supporte sans problème du 120mo/sec en bi-directionnel donc ce n’est pas un problème hardware mais “software”. Ce qui serait intéressant, c’est comment atteindre ces débits en software.
Si on a une interface 10Gbps, le but est de la faire tourner à 10Gbps et non si c’est utile de la faire tourner à 10Gbps pour enregistrer des recettes de cuisines…
Mais faites du montage vidéo en haute résolution et vous verrez que le stockage ainsi que le débit utilisé monte très rapidement.

J’ai tout connu y compris le 56k mais tout cela est bien fini et on a jusqu’à du 1-10gbps sur fibre optique à la maison. Le 10mbps était en half-duplex ce qui n’était pas réellement top.
ioping n’était pas là pour vous donnez le résultat mais pour vous montrez qu’un disque peut avoir une latence de quelques secondes en fonction de la queue et vous avez pu le voir.

cifs et nfs par exemple

[nings]

@sk4hrr
Tu arrives à saturer en bi-directionnel ? Plus de 80mo/sec dans un sens comme dans l’autre ou ça ne tient pas et la ram est utilisé entièrement j’imagine ?
Je ne sais pas si cela vient du kernel ou si c’est logiciel mais si le fichier fait 100go, il semble mettre le fichier au complet donc 100go en “cached” enfin il remplit tant qu’il y a de la place même si la lecture ou l’écriture suit.
Peut-être que cela réagit différement avec un kernel plus récent ? (je suis sur du stable ce sont des vieux kernels)

Si, si le full duplex ça donne bien 1gbps dans un sens en même temps que 1gbps dans l’autre sens. Et j’ai pu l’expérimenter sur mon réseau donc il tient bien cette charge. Je dois juste utiliser cifs dans un sens et nfs dans l’autre pour atteindre ce débit symétrique.

C’est 8 le ratio et non 10 donc ~125mo/sec pour 1gbps. Avec les en-têtes même en utilisant des jumbo frames, on n’arrive jamais à ce débit. C’est ~119mo/sec chez moi avec jumbo frame pour 980mbps sur atop mais je n’ai pas pris le chrono, je ne suis quand même pas à 10mo/sec de différence

C’est très light les droits unix justement owner/group/other mais je vais jeter un oeil au NFS voir comment il réagit comme il me donne à peu près le même résutat qu’en CIFS.

Oui, c’est sûr et j’ai passé pas mal de temps à tester la bonne valeur pour les jumbo frames afin d’obtenir le meilleur débit possible sur mes liens 1gbps.
Le CPU, le réseau, les disques, les switchs, les câbles,… n e sont pas la cause car je peux atteindre le débit maximal en utilisant deux “softs” différents. Maintenant, il me reste la mémoire qui est liée au kernel(version)/software utilisé.

Cela peut paraître étrange mais linux est le premier système d’exploitation qui me laisse totalement libre de toute restriction. Mon disque système a crashé (le système tournait toujours avec des erreurs sur dev/sda), je l’ai enlevé et remplacé par une carte compact flash pour copier le système en ram et tout tournait en ram. Une nouvelle version de grub m’a bloqué et mon ups ayant lâché, je suis reparti avec le système sur un ssd.
Donc oui, peut-être que je gratte un peu mais je suis sûr qu’il y a moyen de régler les problèmes que je rencontre et voilà pourquoi je creuse un peu déjà en essayant de savoir si je suis seul ou si d’autres ont les mêmes soucis. Linux permet très souvent d’utiliser bien mieux les ressources que sur des OS où on ne sait pas à quoi servent la moitié des choses qui tournent

[nings]

@ clochette
Oui car c’est un sacré débit et impossible de l’atteindre chez moi.
Mais en utilisant disons plus de 100mo/sec en download ce débit reste stable lorsqu’il y a un fichier qui est uploadé ?
C’est mon gros soucis dès que je lance un débit en download de plus de 100mo/sec celui-ci diminue à quelque chose comme 10mo/sec alors que l’upload monte à plus de 100mo/sec. Dès que l’upload est terminé le download revient à 100mo/sec. A part lorsque j’utilise CIFS en download et NFS en upload par exemple où là le débit de 120mo/sec de chaque côté est stable pourtant avec les mêmes machines, même quantité de ram et même swap.

Une interface 1gbps, c’est ~300to par mois peu de monde exploite ne serait-ce que 1%
Oui mais les I/O = ssd et le stockage en ssd coûte encore trop cher par rapport à des disques classique.

Environ 150mo/sec sur les HDD et ~250mo/sec sur les SSD.

[sk4hrr]

En me connectant au boulot ce soir, j’en ai profité pour faire quelques tests sur notre NAS d’archivage.

Matériel

Réseau

Netgear gamme pro, non administrable et sans jumbo frame
Câbles en catégorie 6

NAS (archives)

FreeNAS 11.2
1 CPU 2C/2T à 2.2 GHz (je n’ai pas pensé à vérifier)
32 Go de mémoire vive
10 Go de swap
Gigabit sur la carte mère
1 clef USB pour le système
8 disques Seagate BarraCuda en RAID-Z2

NB: pas de compression ni dé-duplication

Client (mufasa)

Debian Buster
1 CPU 6C/12T à 3.6-4 GHz
16 Go de mémoire vive
8 Go de swap
Gigabit sur la carte mère
1 SSD pour le système
1 SSD additionnel notamment utilisé pour ces tests

Tests basiques

Dans cette partie, j’écris, je redémarre le NAS et le client, puis je lis.

Locaux

NAS

root@archives[~]# dd if=/dev/zero of=/mnt/achives/local/test1.img bs=1G count=10
10+0 records in
10+0 records out
10737418240 bytes transferred in 22.765970 secs (471643342 bytes/sec)
root@archives[~]# dd if=/mnt/achives/local/test1.img of=/dev/null bs=1G
10+0 records in
10+0 records out
10737418240 bytes transferred in 19.393928 secs (553648456 bytes/sec)

Client

root@mufasa:~# dd if=/dev/zero of=/home/test1.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 16,2849 s, 659 MB/s
root@mufasa:~# dd if=/home/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 4,10749 s, 2,6 GB/s

NFS

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/nfs/test1.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 163,775 s, 65,6 MB/s
root@mufasa:~# dd if=/mnt/achives/nfs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 92,4577 s, 116 MB/s

CIFS (cifs-utils)

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/cifs/test1.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 92,7434 s, 116 MB/s
root@mufasa:~# dd if=/mnt/achives/cifs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 91,7545 s, 117 MB/s

Tests parallèles

Dans cette partie, après avoir redémarrer le NAS et le client, j’écris un nouveau fichier et lis le précédent.

Locaux

NAS

root@archives[~]# dd if=/dev/zero of=/mnt/achives/local/test2.img bs=1G count=10
10+0 records in
10+0 records out
10737418240 bytes transferred in 27.070581 secs (396645288 bytes/sec)
root@archives[~]# dd if=/mnt/achives/local/test1.img of=/dev/null bs=1G
10+0 records in
10+0 records out
10737418240 bytes transferred in 22.190839 secs (483867154 bytes/sec)

Client

root@mufasa:~# dd if=/dev/zero of=/home/test2.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 23,7924 s, 451 MB/s
root@mufasa:~# dd if=/home/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 25,7933 s, 416 MB/s

NFS

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/nfs/test2.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 143,443 s, 74,9 MB/s
root@mufasa:~# dd if=/mnt/achives/nfs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 205,801 s, 52,2 MB/s

CIFS (cifs-utils)

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/cifs/test2.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 94,8191 s, 113 MB/s
root@mufasa:~# dd if=/mnt/achives/cifs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 161,048 s, 66,7 MB/s

Pas inutiles ces tests, ça m’a permis de voir que sur ce serveur, le NFS est moins performant

---

En cherchant pourquoi NFS était si lent sur ce serveur, je suis tombé sur l’option sync de ZFS, lorsqu’elle est désactivée:

Tests basiques

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/nfs/test1.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 93,1501 s, 115 MB/s
root@mufasa:~# dd if=/mnt/achives/nfs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 81,7583 s, 131 MB/s

Tests parallèles

root@mufasa:~# dd if=/dev/zero of=/mnt/achives/nfs/test2.img bs=1G count=10
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 95,3334 s, 113 MB/s
root@mufasa:~# dd if=/mnt/achives/nfs/test1.img of=/dev/null bs=1G
10+0 enregistrements lus
10+0 enregistrements écrits
10737418240 octets (11 GB, 10 GiB) copiés, 130,609 s, 82,2 MB/s

---

Peut-être que cela réagit différement avec un kernel plus récent ? (je suis sur du stable ce sont des vieux kernels)

Je pense que la mise en cache est paramétrable, mais dit toi que rien n’est plus rapide que la RAM.

C’est très light les droits unix justement owner/group/other mais je vais jeter un oeil au NFS voir comment il réagit comme il me donne à peu près le même résutat qu’en CIFS.

C’est vrai que c’est light, mais c’est surtout propre. Je hais les droits Windows et malheureusement, le NAS des fichiers utilisateurs de mon boulot, est en Windows…

Maintenant, il me reste la mémoire qui est liée au kernel(version)/software utilisé.

Tu as essayé avec du swap ou pas?

[nings]

Merci pour ce test !
Je vais faire pareil de mon côté pour pouvoir comparer les débits car je ne procédais pas tout à faire de la même manière en testant le disque source + le disque de destination mais je peux aussi tester via /dev/null

Donc CIFS était plus rapide que le même volume qu’en NFS juste lié à ce paramètre ?
Je trouve vraiment étonnant quand même mais au moins tu n’as pas fait tout ça pour rien heureusement

Pour les questions :
Je sais bien pour la ram mais je ne comprends pas pourquoi il n’utilise pas un buffer de 1Gb par exemple et qu’il ne libère pas au fur et à mesure ce buffer surtout que disque et réseau suivent dans ce cas.

J’ai vraiment du mal avec les droits linux quand un utilisateur doit avoir les droits en lecture mais en écriture dans un autre dossier, l’autre en écriture partout et les autres qu’en lecture. J’ai souvent des soucis avec ça mais c’est surement un problème de mon côté et je sais qu’on peut activer des droits plus étendus mais je ne suis pas encore parti là-dedans.

J’ai du swap mais en swapiness 0 et c’est un stick usb qui ne suit plus du tout très rapidement surtout en cas de surcharge massive.

[nings]

LOCAL - SERVER HDD

=>
dd if=/dev/zero of=test1.img bs=1G count=10
10737418240 bytes (11 GB) copied, 53.6624 s, 200 MB/s
<=
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB) copied, 64.2106 s, 167 MB/s

LOCAL - CLIENT SSD

=>
dd if=/dev/zero of=test1.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 42.3201 s, 254 MB/s
<=
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 20.5375 s, 523 MB/s

CIFS

=>
dd if=/dev/zero of=test1.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 91.9326 s, 117 MB/s
<=
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 88.6105 s, 121 MB/s

NFS

=>
dd if=/dev/zero of=test1.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 92.8013 s, 116 MB/s
<=
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 92.2745 s, 116 MB/s

NFS parallèle

<==>
dd if=/dev/zero of=test2.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 91.4574 s, 117 MB/s
<==>
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 120.16 s, 89.4 MB/s

CIFS parallèle

<==>
dd if=/dev/zero of=test2.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 101.25 s, 106 MB/s
<==>
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 166.856 s, 64.4 MB/s

CIFS(Write)-NFS(Read) parallèle

<==>
dd if=/dev/zero of=test2.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 94.6904 s, 113 MB/s
<==>
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 98.535 s, 109 MB/s

CIFS(Read)-NFS(Write) parallèle

<==>
dd if=/dev/zero of=test3.img bs=1G count=10
10737418240 bytes (11 GB, 10 GiB) copied, 91.143 s, 118 MB/s
<==>
dd if=test1.img of=/dev/null bs=1G
10737418240 bytes (11 GB, 10 GiB) copied, 93.2534 s, 115 MB/s

C’est ce que j’expliquais mais c’est peut-être plus clair avec les chiffres.
Il y a clairement un problème et très probablement “soft” vu que le hardware tient la route et en utilisant CIFS/NFS en parallèle cela fonctionne très bien que ce soit d’un côté comme de l’autre (lecture-écriture).

[sk4hrr]

Je sais bien pour la ram mais je ne comprends pas pourquoi il n’utilise pas un buffer de 1Gb par exemple et qu’il ne libère pas au fur et à mesure ce buffer surtout que disque et réseau suivent dans ce cas.

Parce que rien n’est plus rapide que la RAM et donc autant utiliser celle qui est libre pour accélérer les échanges de données. J’imagine que c’est réglable, mais je pense que tu vas perdre en performance sur les petits fichiers.

Donc CIFS était plus rapide que le même volume qu’en NFS juste lié à ce paramètre ?

Oui, parce que je soupçonne CIFS d’ignorer le mode synchrone du disque derrière. Faut que je fasse des recherches là dessus.

Il y a clairement un problème et très probablement “soft” vu que le hardware tient la route

Que ce soit samba ou NFS, il y a des processus derrière, peut-être faudrait-il augmenter leur nombre? De mon coté, FreeNAS me recommande de mettre le nombre de processus NFS égal au résultat de sysctl -n kern.smp.cpus (nombre de cœur dans mon cas).

[nings]

Oui bien sûr pour la ram mais utiliser toute la ram “cached” disponible pour un fichier de 100go, c’est quand même dommage surtout que le système peine à libérer cet espace pour d’autres process par la suite. Je fais des clean de la mémoire “cached” régulièrement pour éviter de passer par la case swap.

CIFS semble ouvrir un seul process tandis que NFS en ouvre plusieurs en parallèle. La RAM est très certainement utilisé pour “recoller” les morceaux. Par contre, comment voir s’il ouvre un seul thread en écriture sur le disque physique ou plusieurs ?
iotop me montre plusieurs écritures en parallèle mais je ne sais pas si cela arrive en ram ou si c’est le disque qui doit gérer directement ces flux. Il y a un autre outil qui permettrait de voir cela ?

Le nombre de threads est à 8 pour NFS chez moi par défaut et en diminuant ce nombre, cela réduit aussi la vitesse de transfert. J’ai quand même du mal à en saisir l’utilité d’un point de vue “hardware”. Le disque de stockage “standard” ne permet pas plus d’une seule opération, le réseau effectue toujours du transfert de type “série” donc un paquet après l’autre et c’est pareil pour la réception et le stockage de l’autre côté donc pourquoi faire du parallélisme sur du hardware qui ne l’est pas du tout vu que tout fonctionne en série avec des buffers/ram.
Il devrait être possible de tout faire avec un flux unique en gardant une taille de buffer réduite.

Je vais vérifier sur windows en smb4 voir comment il gère les flux et la mémoire ce serait intéressant de voir si cela fonctionne de la même manière.

[sk4hrr]

Tu devrais laisser faire le noyau, il sait mieux que toi ce qu’il doit faire, crois-moi. Tiens d’ailleurs, t’as quoi comme noyau ?

Par contre, comment voir s’il ouvre un seul thread en écriture sur le disque physique ou plusieurs ?

Aucune idée, mais la cuisine interne, j’ai tendance à la considérer comme bien faite. Surtout sur des protocole qui existent et sont utilisés depuis des années par énormément de personnes/entreprises à travers le monde.

J’ai quand même du mal à en saisir l’utilité d’un point de vue “hardware”.

Sans doute aucune, par contre faut aussi voir que là tu fais du NAS low-cost. En SAS les disques, ou plutôt le contrôleur, est capable de gérer les instructions parallèles. Par ailleurs avoir plusieurs processus pour gérer le nombre de client semble plutôt cohérent.

Je vais vérifier sur windows en smb4 voir comment il gère les flux et la mémoire ce serait intéressant de voir si cela fonctionne de la même manière.

Le problème de ce genre de test, surtout dans ton cas, c’est que tu n’auras pas d’autre choix que de laisser le noyau faire ce qu’il veut sous Windows. Par ailleurs il faut tester avec le même matériel, sinon ça n’a pas de sens.

[nings]

Ce n’est pas si low cost que ça, ces disques sont sur un contrôleur SAS2 certes en 6Gb et non en SAS3 12Gb avec des disques SAS2 6Gb derrière
Il a une mémoire pour faire du cache surtout utile lorsqu’il y a un raid pour le calcul de la parité mais pas tant pour décharger le système enfin un peu mais ce n’est pas suffisant.
Cela ne change pas grand chose SAS ou SATA même symptôme…

Windows, c’est juste pour voir comment il réagit niveau ram/nombre de process et vitesse, le hardware est plus ou moins indépendant du moment qu’il tient du 120mo/sec sur les disques et les interfaces réseaux.

Ce que je remarque, c’est que je ne suis pas le seul avec exactement les mêmes soucis sauf que la plupart ne s’en rendent pas compte
Après, j’ai d’autres ralentissements mais je n’ai pas encore trouvé du tout la cause. Ici, je sais qu’il y a un souci software quelque part. Il faudrait que je teste une version très récente voir s’il y a une différence et si quelque chose a été corrigé entre deux.

Merci pour tes tests !

[sk4hrr]

le hardware est plus ou moins indépendant du moment qu’il tient du 120mo/sec sur les disques et les interfaces réseaux.

Ceci est faux dans la mesure où c’est le software qui prend en charge le hardware. En gros d’une référence à une autre, tu peux avoir des comportements totalement différents.

Ce que je remarque, c’est que je ne suis pas le seul avec exactement les mêmes soucis sauf que la plupart ne s’en rendent pas compte

C’est vrai, mais il est aussi rare de s’attarder sur les performances lorsque celles-ci donnent satisfaction. Avant ton sujet, je n’aurais jamais pensé à tester les perf’ sur le FreeNAS que je viens tout juste de mettre en place à mon boulot. Notamment parce que ce n’est pas spécialement un critère pour ce NAS. Par contre, sur une baie SAN, c’est autre chose, et nous avons du matériel dédié avec des capacité en IO “garanties” par le constructeur. En même temps la baie fourni du stockage pour du VMware et de l’Oracle.

Bon j’arrête de te répondre, ne pouvant t’apporter plus de réponse. Par contre je continue à suivre des fois que quelqu’un donne une explication