Vitesse De Transfert (Tr

[frk]

Bonjour,

a force de raler sur les transferts de fichiers trop lents sur mon DS209j, j'ai cherché une solution pour accelerer les choses... et j'ai lu ici et la des débits qui me laissent rêveur, 20, 60, 100Mb/s !. J'ai changé tous mes cables (Cat6) et vérifié que j'atais en Gigabyte partout, mais mon débit est resté à ... 4~6Mb/s avec des pointes exceptionelles à 8mb/s !. (Pour info, j'arrive à 25Mb/s avec le HDD de ma freebox).

Mon routeur est ma freebox revolution. J'ai 2 pc fixes et mon nas branchés derrière la box + un switch (3com GB) pour mon imprimante et autres besoin de RJ45.

Les deux postes sont sous Linux et connectés au nas par NFS.

Je ne sais plus de quel coté chercher !.

Merci d'avance pour votre aide.

frk

[MS_Totor]

salut est ce que tu as changé de port de connexion sur ton switch, teste un truc, garde uniquement les connexions nas et pc linux, eteins et remets en marche ton switch, fais un transfert....

est ce que c'est mieux ?

de chaque côté pc via une console et syno via ssh, verifies si tu n'as pas de collisions ou des pertes etc avec la commande netstat

voir la syntaxe netstat ou encore nfsstat pour avoir plus d'info sur le montage

exemple

netstat -s

sur la question nfs, il est souvent dit de verifier avec quel protocole est effectué le montage, udp ou tcp..... tcp est ton ami

exemple:

mount -t nfs4 -o proto=tcp,etc......

encore un truc, as tu changer le MTU de tes cartes reseaux pour bidouiller ou un truc dans le genre à un moment ou un autre ?

voili voila de quoi t'occuper ce soir

++

Modifié le 20 septembre 2013 par MS_Totor

[frk]

Bonsoir,

merci pour ce retour

Je n'ai laissé que mon nas et mon pc derrière ma box. Redemarrage des 2 machines et transfert d'ue vidéo de 800mo à 5 mb/s en moyenne. rien de mieux

mon montage nfs est fait avec auto.nfs genre : (192.168.0.50 est l'ip du nas)

mon_rep_local -fstype=nfs,rw,intr 192.168.0.50:/volume1/rep_nas

j'ai aussi un dossier monté par mon fstab :

192.168.0.50:/volume2/backup    /media/backup    nfs    user    0    2

les seules redirections e ma freeebox sont

le DMZ vers l'ip du nas

20, 21, , 5000 pointe en TCP vers le nas

la freebox voit les 2 machines connectées en 1000BaseT-FD

J'avais regardé l'histoire des MTU. J'ai fait quelques essais (sans réels gains) mais j'ai désactivé le jumbo frame et remis à 1500 le MTU

entre freebox et mon pc, je transfert à presque 40MB/s ! (c'est bien sauf que j'en ia pas réellement besoin ;-)

[MS_Totor]

il manque quand même le principal, le retour d'info via des commandes netstat pour y voir plus clair ainsi que des infos via nfsstat..

sans cela dificile d'aller plus loin, si etranglement il y a , logiquement ces deux outils le dirons ...

c'est le switch qu'il faut redemarrer pas les pc, si tu n'as pas de switch administrable, tu ne peux pas connaitre l'état des tables internes, ni à quelle vitesse le port est up.... relis ce que je t'ai suggeré

sinon fais un essais de transfert via rsync tu seras en dehors de NFS, et d'un eventuel soucis de ce côté là , pour comparer de facon sérieuse tes vitesses et celle des autres, si du coup tu n'es plus bridé en transfert pur non crypté etc...

tu devras quand même aller toucher un peu de commande en mode console de toutes les facons, pour diagnostiquer un minimum..sinon tu n'avanceras pas

bonne soirée

Modifié le 20 septembre 2013 par MS_Totor

[frk]

netsat m'a renvoyé une très longue liste assez incompréhensible (pour moi):

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp 0 0 192.168.0.51:56772 192.168.0.50:5000 ESTABLISHED
tcp 0 0 192.168.0.51:848 192.168.0.50:nfs ESTABLISHED
tcp 0 0 192.168.0.51:54986 grape.canonical.c:https ESTABLISHED

etc...

et nfsstat me renvoie :

Server rpc stats:
calls badcalls badauth badclnt xdrcall
1 0 0 0 0

Server nfs v3:
null getattr setattr lookup access readlink
1 100% 0 0% 0 0% 0 0% 0 0% 0 0%
read write create mkdir symlink mknod
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
fsstat fsinfo pathconf commit
0 0% 0 0% 0 0% 0 0%

Client rpc stats:
calls retrans authrefrsh
15948 0 0

Client nfs v3:
null getattr setattr lookup access readlink
0 0% 4272 26% 0 0% 3555 22% 99 0% 0 0%
read write create mkdir symlink mknod
7205 45% 0 0% 0 0% 0 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 33 0% 33 0%
fsstat fsinfo pathconf commit
735 4% 10 0% 5 0% 0 0%

[MS_Totor]

Server nfs v3: ce n'est pas version 4 ?

lors d'un transfert NFS tu regarde le taux d'occupation CPU du syno, il est pas à fond ?

voir un minima la syntaxe de ces deux outils, pour presenter le resultat plus proprement, car je vais me coucher

et fais un test de transfert rsync

Modifié le 20 septembre 2013 par MS_Totor

[frk]

Le cpu est tojours au taquet en NFS et avec samba (qui ne réalise pas de meilleures performances)

J'utilise Grsync et le débit est similaire (autour de 6MB/s)

Modifié le 21 septembre 2013 par frk

[MS_Totor]

ton cpu à 100 % ..... pas DL en cour ou autre activité ?

ton syno a vraiment un tout petit proco et ram, il vas avoir bien du mal à gerer les requetes nfs de mon point de vue....tu es peu etre à fond de ces capa.......

sinon pour les autres causes, de facon générale

pas de nouvelles du switch.... saches que sans réponse je reponds pas non plus ou de moins en moins

un switch resté en 10 au 100 au lieu de d'un giga ce n est pas vraiment une premiere pour moi......

et seul le fait de l'eteindre electriquement puis de le rallumer permet de faire un up correct en full duplex à la bonne vitesse. cet arret/marche est important.... et cette panne m'est arrivée souvent lors d'utilisation de machine virtualisée, avec des couples mac/ip differents, le switch etait planté.

voir à regarder la syntaxe de netstat... car pas de nouvelle pour les stats

du côté du syno via ssh, tu dois faire sur le syno et sur le pc....

si eth0 est bien la carte reseau du pc et bien sur à faire la même manip sur le syno.

ifconfig eth0

pour voir si il y a des collisions, ou pertes, ou errors la valeur du MTU bien à 1500

cette commande est à refaire aussi sur un des PC apres un transfert. idem verification des erreurs

plus ton transfert comporte de petits fichiers, plus il est lourd à traiter, donc long, 1 go d'un fichier iso ira plus vite que 2000 petits fichiers valant au total 1 go. on fait du stress test grace à ce principe, et on regarde si il n'y pas de pertes, à cause de latence en réponse trop long, dépassement de pile etc...... d'ou mes up repetées de faire du netstat exemple

netstat -tpns

te reste à lire la syntaxe de nfsstat................ nfsstat -rs par exemple

recherche peu etre aussi si tu ne peux pas augmenter le cache nfs

après avoir recu ces infos, il sera alors posible de trancher

je n'aime pas nfs et samba ....

Modifié le 21 septembre 2013 par MS_Totor

[frk]

mon cpu est bien à 100% sans autre tache sue le transfert de fichier

Je ne comprends pas bien a quoi tu fais référence a propos du switch ? tu parles de la freebox ou du switch 3com que j'ai débranché pour faire les tests ?

Je t'assure que la freebox est reglée en 1000 et voit des périphériques 1000 (1000BaseT-FD). Le reglag eest Automatique, mais j'ai aussi forcé à 1000 full duplex sans qu ecla n'est d'effet

Je n'ai pas fait de netstat -s, car le man ne connait pas -s

netstat -tpns :

IcmpMsg:
OutType3: 3
Tcp:
3927 ouvertures de connexions actives
10 connexions passives ouvertes
14 tentatives de connexion échouées
36 reinitialisation de la connection détéctée
16 connexions établies
367124 segments reçus
2443844 segments envoyés
28 segments retransmis
0 mauvais segments reçus
222 réinitailisations envoyées
UdpLite:
TcpExt:
652 TCP sockets finished time wait in fast timer
7 time wait sockets recycled by time stamp
1920 accusés de réception envoyés en retard
10 delayed acks further delayed because of locked socket
Le mode ACK rapide a été activé 909 fois
6321 paquets directement mis en attente dans la file d'attente recvmsg.
9317029 bytes directly in process context from backlog
19611205 bytes directly received in process context from prequeue
70130 en-têtes de paquets prédits
19854 packets header predicted and directly queued to user
109387 acknowledgments not containing data payload received
112373 accusés de réception prédits
8 congestion windows recovered without slow start after partial ack
3 timeouts after reno fast retransmit
24 other TCP timeouts
18 connections reset due to unexpected data
22 connections reset due to early user close
18 connections aborted due to timeout
IpExt:
InMcastPkts: 653
OutMcastPkts: 140
InBcastPkts: 2259
OutBcastPkts: 1915
InOctets: 102585283
OutOctets: -774842413
InMcastOctets: 439570
OutMcastOctets: 48628
InBcastOctets: 359823
OutBcastOctets: 311824

ifconfig eth0:

eth0 Link encap:Ethernet HWaddr 90:e6:ba:25::6a
inet adr:192.168.0.51 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: 2a01:e34:ee0a:9c30:92e6:baff:fe25:806a/64 Scope:Global
adr inet6: fe80::92e6:baff:fe25:806a/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:378711 erreurs:0 :0 overruns:0 frame:0
TX packets:2448774 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:129432667 (129.4 MB) Octets transmis:3557874997 (3.5 GB)
Interruption:35 Adresse de base:0x2000

nfsstat -rs :

Server rpc stats:
calls badcalls badauth badclnt xdrcall
1 0 0 0 0

Quelles alternatives à NFS et samba ? ssh ?

Mes connaissances en la matière sont assez limitées...

Modifié le 21 septembre 2013 par frk

[MS_Totor]

ce netstat est pris ou ? syno ou sur un pc ? pour voir la chose au mieux, il aurrait fallut les deux

je vois pas mal de time out, il n'y a pas de perte, mais de l'attente, de la reconnexions, à mon avis dus à un temps de latence trop long, ton CPU est à fond et ton syno a du mal à répondre aux requetes NFS

jamais refait de NFS depuis un bail, tu peux via le reglage du mount choisir UDP au lieu de TCP, et voir si cela ameliore ton debit, je ne pense pas de memoire.

un expert réseau t'en diras plus ! à ce sujet je passe la main

le switch je parlais du 3com car de suite j'ai eu un doute !

perso je passe principalement par de l'encapsulation via socket ssh pour pas mal de protocoles, ftp, web etc..... crosoft ou lux

exemple au quel je pensais......mais je ne l'ai pas testé, j'utilisais fuse pour le montage de mes "backup" à voir si un membre syno utilise ce truc sous une station linux

http://doc.ubuntu-fr.org/sshfs

Modifié le 21 septembre 2013 par MS_Totor

[frk]

Merci pour ton aide !

Je vais tenter sshfs quand j'aurai un moment.

Ce qui m'étonne c'est que même par l'interface DSM le débit est aussi faible et le cpu toujours à fond (ou presque). On dirait que c'est la puissance du syno qui est trop juste, mais alors pourquoi est-il (soit-disant) parametrable pour du Gigabyte si techniquement il e peut pas l'assumer. J'avoue que je suis un peu perplexe et je doute maintenant d'arriver un jour a faire décoller le débit... C'est quand même un comble pour un nas de rencontrer tant de difficultés à faire fonctionner (corectement) une connexion réseau...

en tout cas merci encore de t'être penché sur mon pb!

[MS_Totor]

salut

en fait après une petite recherche tout à l'heure

si tu vas dans le moteur de recherche du site en haut à droite, ou via google, et que tu fait "DS209j NFS lenteur reseau" ou "DS209j NFS cpu" etc... il y a foulitude de réponses qui redonne plus ou moins le même verdict.

je n'en ai pas fait le tour et lu en diagonale..

@++