[NFS / SMB] Problèmes de vitesse

Support Debian
#1

Bonjour à tous.

J’ai réussi à convaincre la plupart du bureau d’étude dans lequel je bosse de passer sous GNU/Linux (concernant les postes de travail).

Tous nos serveurs sont sous Debian (une 20ène), et je viens de recevoir notre nouveau serveur qui va nous servir de NAS.
C’est un serveur HP, raid 5 (4 disques). Installation du système sans problème, tout roule.

Etant donné la quantité de personnes ayant migré vers GNU/Linux, je souhaitais faire quelques tests pour passer nos partages SAMBA en partages NFS.

J’install donc nfs-kernel-server, et je lance quelques tests depuis mon poste. Seulement voilà, la lecture de fichiers sur le serveur est rapide (très rapide), mais l’écriture est excessivement lente.
Je me demande d’abord si ce n’est pas due à mon raid (raid5 = écriture plus lente), mais je tente par curiosité d’installer un serveur SAMBA et de retenter le même test (via un “time cp”).

Voilà les résultats que j’ai obtenu pour un fichier ISO de 300Mo (en secondes):

Copie de mon NAS vers mon pdt:
Via NFS: 1.397 8)
Via SMB: 3.413

Copie de mon pdt vers mon NAS:
Via NFS: 32.293 :open_mouth:
Via SMB: 7.68
[b]
On voit que NFS est largement plus rapide (>2x) que Samba pour lire un fichier, mais il est >4x plus lent pour écrire un fichier.

Savez vous d’où ce problème peut venir?[/b]

Infos:
[ul]
NAS RAID5 matériel (4DD 1TO 7200Tr/min)
NAS OS: Debian 6
NAS FS: ext4

Pdt DD: SSD
Pdt FS: ext4

Le tout réseau Gb/s (le client, le serveur + routeur).
[/ul]

#2

salut,

Tu as essayé une connection ssh pour voir si ça freine aussi en écriture ?

Pour un bureau d’ étude, ton boss ou un collègue risque sûrement de se connecter depuis l’ extérieur donc un partage avec montage sshfs serait mieux indiqué q’un smb ou nfs non sécurisé.
et pratiquement rien à configurer, Nautilus ou WinSCP se connecte en toute transparence.

#3

J’avais pensé à SSHfs mais quid des perfs? Je vais essayer demain.

Je me connecte tous les jours en SSH depuis mon poste de travail (administration, transferts de fichiers, etc.), mais je n’ai jamais envisagé le fait de pouvoir l’appliquer à tout le monde. Le fait qu’il soit crypté m’a fait faire le raccourcis crypté = plus lent (probablement une erreur). Rien de mieux que la pratique pour confirmer ou infirmer tout ca, je vais tester ca demain.

Ils ne se connectent jamais depuis l’extérieur directement sur le NAS. Le seul accès qu’ils ont est déport X de leur poste via SSH (freenx pour les postes sous GNU/Linux).
Je n’ai donc pas besoin de crypter les données qui transitent entre le NAS et les postes de travail mais je vais quand même tenter le sshfs demain, on ne sait jamais.

En attendant si vous avez des réponses concernant ces lenteurs via NFS je suis preneur!

#4

[quote=“boulate”]J’avais pensé à SSHfs mais quid des perfs? Je vais essayer demain.

[/quote]

en théorie on pourrait penser que le chiffrement ralentit, mais pratiquement je ne vois pas la différence, même les vidéos en .flv que j’ enregistre depuis FT circulent en toutes fluidités, du coup NFS je l’ ai enlevé.

#5

Bon, je viens de tester par sshfs et je mets les données ici. C’est un peu plus lent que Samba et beaucoup plus lent que NFS en lecture.

Par contre en écriture ca reste plus long que Samba, mais vu le problème que j’ai avec NFS, forcement c’est plus rapide. Je pense vraiment qu’il y a un probleme quelque part concernant NFS en écriture. J’aimerai vraiment pouvoir le régler :confused:

Copie de mon NAS vers mon pdt:
Via NFS: 1.397 :smiley:
Via SMB: 3.413
Via SSHFS: 4.807

Copie de mon pdt vers mon NAS:
Via NFS: 32.293 :astonished:
Via SMB: 7.68
Via SSHFS: 8.781

#6

Je me permets juste un petit “up”, si l’un de vous a une réponse à me donner (qui pourrait probablement m’aider à régler ce problème).

Ca m’embête vraiment de passer par du SMB si 80% de mon parc est en GNU/Linux … question de perfs, mais aussi de philosophie.