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

nings · Mars 28, 2019, 12:06pm

Hello,

J’ai quand même pas mal de soucis au niveau de l’utilisation de la mémoire sous Linux.
J’utilise CIFS car je n’ai jamais réussi à obtenir de bons résultats en 1gb/s avec SMB malgré tous les paramètres possibles et jumbo frame niveau réseau.

En CIFS, je suis à environ 110/120mo/s pour 54mo/s sur le même fichier avec SMB.
Par contre, CIFS prend absolument toute la RAM donc environ 16go très rapidement. SMB semble faire pareil mais beaucoup plus lentement probablement lié à la faible vitesse de transfert.

Il y a un moyen niveau kernel ou paramètre logiciel de limiter un peu l’usage de la mémoire y compris cached ?
Je n’ai pas de swap et j’ai réussi à faire planter complétement le système plusieurs fois faute de ram et le système qui est censé libérer la mémoire cached ne doit pas bien fonctionner car malgré la fin du transfer cela reste à 16Go et s’il libérait au fur et à mesure, je n’aurai pas de crash lié à l’utilisation mémoire.

Quelqu’un a une solution miracle pour faire du 1gb full duplex lors de transferts dans les deux sens simultanés et une solution pour les problèmes d’utilisation mémoire ?

Merci pour votre aide

sk4hrr · Mars 25, 2019, 8:49am

Bonjour,

C’est à dire?

Le switch est lui aussi en jumbo frame?

Le message lors de l’installation qui indique qu’un système sans swap peut être instable semble au final totalement inutile…

Les 120 Mo/s mentionnés sont le maximum possible via une liaison Gigabit de type Ethernet. Si un deuxième transfert est lancé, le débit est alors réparti.

Pour en revenir à “SMB” et “CIFS”, j’avoue que je ne comprends pas. Il y a un autre moyen de faire du CIFS sous Linux que d’utiliser samba?

Sinon, j’utilise pratiquement que des systèmes Linux, donc NFS.

nings · Mars 25, 2019, 3:56pm

mount -t cifs …
si je dis que j’utilise des jumbo frame s’est que toute la ligne est en jumbo frame avec le même paramètrage de bout en bout et qu’il est fonctionnel
ce n’est pas inutile, c’est juste que ce n’est pas “up to date”. On n’est plus à 512Mb de ram sur le PC, les disques ne sont plus à plateaux mais sont sur des lignes PCIe à plusieurs go/sec avec des temps de réponses de moins de 1ms. Par contre, l’écriture inutile (swap) n’est pas adapté à ce type de disques.
Le swap ne devrait plus être utilisé vu que les disques sont très rapide. Par contre, la ram devrait être gérée correctement sans faire crasher le système et une application ne devrait pas pouvoir tout utiliser surtout avec 16go de ram ou plus pour un simple transfert sur le réseau. Les disques suivent sans même passer par la ram donc cela ne devrait être qu’un buffer de quelques mb en ram en cas d’interruption/baisse perf réseau ou disque.
J’ai marqué “dans les deux sens” donc oui c’est partagé dans le “même sens” mais si on fait un transfert à 120mo/sec en download, on devrait pouvoir en faire un deuxième de 120mo/sec en upload ce qui ne fonctionne pas ni en cifs, ni en smb mais je ne sais pas si c’est un problème de ram car elle est très vite remplie à 96% sur les deux machines.

J’utilise CIFS en direct et SMB avec Samba.
NFS, il me semble que c’était la cata aussi mais je peux bien refaire un test.
Je n’ai que du linux sur toutes mes machines, les perfs sont de 120mo/sec en up/down simultanément en NFS sur un share tmp monté en ram pour éviter tout problème de perf disque ?
Et l’utilisation de la ram en tant que “buffer” est plus correct qu’avec SMB ou CIFS ?

Merci

sk4hrr · Mars 25, 2019, 4:18pm

Bon déjà, tu pourrais essayer d’être un petit peu plus courtois, bref.

Ne disant pas de quel coté tu étais, j’ai considérer que tu étais du coté serveur.

Un forum est ouvert à tous, donc ce n’était pas si évident que ça !

Les trois principaux systèmes d’exploitation utilisent du swap, donc ça n’a rien à voir avec le matériel. La preuve en est que tu arrives à planter ta machine. Il est effectivement possible de s’en passer, ça fonctionne, mais comme le dit le fameux message, y a des risques d’instabilité.

Quel est le rapport entre la vitesse de ton disque et le swap ? Personnellement j’utilise du SSD pour le système, mais le swap est sur du HDD.

Je t’invite à proposer des patch pour le noyau Linux, mais aussi Windows et MacOS.

De mon point de vu c’est moins compliquer que le CIFS sur Linux, mais bon, chacun ses outils hein.

Je laisse des experts répondre à l’ensemble de tes autres questions.

nings · Mars 25, 2019, 7:46pm

Désolé, ce n’était pas le but de ne pas être courtois vu que c’est moi qui demande de l’aide

Je fais tous mes tests de vitesse côté client, le serveur hébergeant le partage samba.
Oui désolé mais c’est limite de dire qu’on a mis en place du jumbo frame si on a un élément le bloquant entre deux mais ça peut arriver surtout si on ne vérifie pas la taille des paquets à l’arrivée.
Je ne connais absolument pas macos mais on peut le supprimer sous Windows ce qui conduit à des messages d’erreur lorsqu’on abuse sur les applications gourmandes en ram mais j’ai jamais vu un windows crasher pour ça mais il arrive qu’il devienne très lent et qu’il tue lui-même le processus le plus gourmand pour libérer de la ram.
Sous Linux, je pense que je suis capable maintenant de crasher le système à la demande juste en lançant un gros transfert de fichiers et un ou deux download avec aria en ouvrant plusieurs connections en parallèle par exemple. On ne peut plus rien faire même accéder à un terminal tout est comme figé sans aucun message nul part comme si les applications réservaient plus de ram que disponible et que le système n’était pas capable de libérer la ram assez rapidement pour les applis.
Le swap est censé remplacer le manque de ram est nécessite donc un support rapide avec des temps d’accès rapide. 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. C’est pour ça que le swap n’a plus trop raison d’être actuellement avec beaucoup de ram et des disques rapides, il faut juste mieux gérer la gestion mémoire.
Je ne sais pas d’où vient le bug si c’est l’équipe Samba qui gère mal la ram ou si c’est le kernel qui cache trop de ram ou peut-être même les deux.
Je cherche et je prends ce qu’il y a de plus rapide et si ça peut ne pas consommer toute la ram s’est tant mieux. Après, j’ai vu qu’on pouvait utiliser les cgroups mais c’est peut-être un peu “too much” pour pouvoir juste utiliser du 1gb symétrique. Ce n’est pas pour une entreprise et encore moins du 10gb/s voir plus.

Tu as quoi comme débit en NFS ?
Tu arrives à faire du 120mo/sec en bi-directionnel sans que ça ne te mette toute la ram en cache ?

nings · Mars 25, 2019, 8:48pm

CIFS/NFS, j’arrive sur le même débit mais pas contre dès que je lance en bi-directionnel un des deux diminue très rapidement. Si je prends en NFS et envoie en CIFS ou inversement, j’arrive à avoir du ~110mb et ~110mb et le débit tient bon sur plusieurs go pourtant avec les même dossiers/disques. Tout ce qui est hardware tient bel et bien la route.

La RAM est prise entièrement en cache, il me reste ~140mo de dispo des deux côtés que NFS libère en partie une fois le fichier copié ce que samba ne fait pas.

littlejohn75 · Mars 26, 2019, 4:40pm

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).

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 · Mars 26, 2019, 9:07pm

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 · Mars 27, 2019, 1:24am

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

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

Merci de signaler cet outil que je connaissait pas.

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.

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 )

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 · Mars 27, 2019, 5:48pm

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 · Mars 28, 2019, 6:59pm

@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 · Mars 28, 2019, 7:01pm

@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 · Mars 29, 2019, 12:37am

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 ?

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

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.

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 · Mars 29, 2019, 9:43am

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.

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.

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)

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.

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 !

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 · Mars 29, 2019, 11:57am

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

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 · Mars 29, 2019, 8:49pm

@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 · Mars 29, 2019, 9:07pm

@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 · Mars 29, 2019, 9:29pm

@ 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 · Mars 31, 2019, 6:15pm

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

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

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…

Tu as essayé avec du swap ou pas?

nings · Avril 1, 2019, 8:39pm

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.