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

Support Debian
Tags: #<Tag:0x00007f50a0045f68>
#23

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

#24

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.

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

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

#25

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.

#26

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 ?

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.

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.

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.

#27

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 :slight_smile:
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 :wink:
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 !

#28

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.

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 :wink:

1 J'aime