Autor: Vincent Caron Data: A: guilde Assumpte: Re: augmenter le debit d'un partage de fichier sur reseau
On lun., 2012-03-26 at 15:08 +0200, ALD wrote: >
> - si je passe mon reseau en Gigabit, le débit sera t'il meilleur?
> (normalement oui sauf si nfs a une limitation)
J'obtiens systématiquement les 145 MB/s max en NFS-over-TCP sur mon
réseau Gigabit au boulot, mais il s'agit de serveurs dimensionnés pour
de bout en bout (interfaces réseau, disques et switches...).
Sur un LAN à la maison avec seulement 2 ou 3 équipements, je dirais
que tu vas être limité par les perfs du disque dur, probablement qqchoes
dans les 80 à 100 MB/s sur du SATA (dans le cas idéal, c'est-à-dire des
accès séquentiels et soutenus).
Sur des distances courtes (<10m), nimporte quel cordon Ethernet fait
l'affaire, pourvu qu'il soit en bon état. Sinon à l'achat préfère du
CAT6 avec un blindage (quelconque).
J'utilise 'iperf' pour vérifier les perfs 'brutes' en TCP entre 2
machines, on lance un 'iperf -s' sur la machine A et un 'iperf -c A' sur
la machine B.
> pourquoi cette différence entre lecture et enregistrement avec smb?
> (pour mon instruction perso)
Il peut s'agir de sémantiques différentes entre ta conf SMB et NFS.
Par ex. on exporte traditionnellement les partages NFS en 'async', car
en synchrone les perfs sont assez abyssales - par contre les garanties
de cohérence entre clients et de persistence sur le serveur ne sont pas
les mêmes (voire elles n'existent plus). Peut être que Samba était
configuré en mode 'safe' et donc lent.
Ca peut aussi dépendre du programme, s'il fait plein de petites
opérations de lecture ou écriture, ou préfère traiter ça par large lots.
Sur les filesystems réseau, chaque opération I/O se voit rajouter le
coût de la latence du réseau (en particulier en mode synchrone). Même
0,1ms de latence à 10,000 IO/s ça commence à bien se sentir...