Performances samba trop juste par rapport au FTP en local
21 réponses
hameau
bonjour,
Je viens d'installer un serveur de fichier sous Ubuntu serveur 13.04,
j'ai un raid 5 logiciels fait avec 3*1 To WD Black, un CPU Intel
E8400@3Ghz et 4 Go de RAM.
Le transfert entre le serveur et mon PC ne dépasse pas 60 Mo/s au maxi,
aussi bien en lecture quand écriture, cela sous Samba, j'ai fait
plusieurs tests en FTP et la je suis entre 100 et 120 Mo/s.
Pourquoi il y a t'il u,e si grosse différence de performances entre
Samba et FTP, comment faire pour augmenter les performances sous smb.
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer /désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sans garantie coté perf, j'ai pas joué avec NFS et Win7.
Mais à l'époque XP/2003, avec les SFU (service for Unix) à télécharger, c'était tout à fait honnéte et souvent plus efficace que de monter les samba sur Solaris ou RedHat (pas testé intensivement les autres distrib, ça faisait pas parti du projet).
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
hameau a présenté l'énoncé suivant :
Le 04/05/2013 21:44, Baton .rouge a écrit :
On Sat, 04 May 2013 14:25:41 +0200, hameau <hameau.cl@free.fr> wrote:
cela sous Samba,
Et pourquoi pas NFS ?
Salut,
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer
/désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sans garantie coté perf, j'ai pas joué avec NFS et Win7.
Mais à l'époque XP/2003, avec les SFU (service for Unix) à télécharger,
c'était tout à fait honnéte et souvent plus efficace que de monter les
samba sur Solaris ou RedHat (pas testé intensivement les autres
distrib, ça faisait pas parti du projet).
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer /désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sans garantie coté perf, j'ai pas joué avec NFS et Win7.
Mais à l'époque XP/2003, avec les SFU (service for Unix) à télécharger, c'était tout à fait honnéte et souvent plus efficace que de monter les samba sur Solaris ou RedHat (pas testé intensivement les autres distrib, ça faisait pas parti du projet).
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Baton .rouge
On 04 May 2013 22:28:56 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
http://fr.wikipedia.org/wiki/Services_for_UNIX
C'est bien de donner des liens, c'est encore mieux de les lire : dernière version en 2004, sur architecture 32 bits évidemment.
on s'en fout. Je lui donne une piste. SFU n'est pas sencé tourner sur XP home et pourtant après une petite bidouille ça tourne.
J'ai laché vista/7/8. il y a un mode compatibilité dans ces version : "xp mode"
Il y a peut être un magouille pour le faire tourner en 32 bits avec un peut de bricolage ou bien utiliser le service unix des version entreprise ou ultimate en leurant l'installateur (comme ce fut le cas pour xp home)
Sinon, chercher sur google un client nfs pour 64bits : http://code.google.com/p/nekodrive/downloads/detail?name=NFSClient_1_3.zip&can=2&q Free NFS Client for windows 1.7 (No dokan required, Pure .NET, XP/2003/Vista/7 x64 compatible)
On 04 May 2013 22:28:56 GMT, Nicolas George
<nicolas$george@salle-s.org> wrote:
Baton .rouge , dans le message
<a52bo81j2s2gqb0msvkqrvrf84ffm0mvf5@4ax.com>, a écrit :
http://fr.wikipedia.org/wiki/Services_for_UNIX
C'est bien de donner des liens, c'est encore mieux de les lire : dernière
version en 2004, sur architecture 32 bits évidemment.
on s'en fout. Je lui donne une piste.
SFU n'est pas sencé tourner sur XP home et pourtant après une petite
bidouille ça tourne.
J'ai laché vista/7/8. il y a un mode compatibilité dans ces version :
"xp mode"
Il y a peut être un magouille pour le faire tourner en 32 bits avec un
peut de bricolage ou bien utiliser le service unix des version
entreprise ou ultimate en leurant l'installateur (comme ce fut le cas
pour xp home)
Sinon, chercher sur google un client nfs pour 64bits :
http://code.google.com/p/nekodrive/downloads/detail?name=NFSClient_1_3.zip&can=2&q Free NFS Client for windows 1.7 (No dokan required, Pure .NET,
XP/2003/Vista/7 x64 compatible)
On 04 May 2013 22:28:56 GMT, Nicolas George <nicolas$ wrote:
Baton .rouge , dans le message , a écrit :
http://fr.wikipedia.org/wiki/Services_for_UNIX
C'est bien de donner des liens, c'est encore mieux de les lire : dernière version en 2004, sur architecture 32 bits évidemment.
on s'en fout. Je lui donne une piste. SFU n'est pas sencé tourner sur XP home et pourtant après une petite bidouille ça tourne.
J'ai laché vista/7/8. il y a un mode compatibilité dans ces version : "xp mode"
Il y a peut être un magouille pour le faire tourner en 32 bits avec un peut de bricolage ou bien utiliser le service unix des version entreprise ou ultimate en leurant l'installateur (comme ce fut le cas pour xp home)
Sinon, chercher sur google un client nfs pour 64bits : http://code.google.com/p/nekodrive/downloads/detail?name=NFSClient_1_3.zip&can=2&q Free NFS Client for windows 1.7 (No dokan required, Pure .NET, XP/2003/Vista/7 x64 compatible)
Baton .rouge
On Sun, 05 May 2013 00:41:04 +0200, Ascadix wrote:
hameau a présenté l'énoncé suivant :
Le 04/05/2013 21:44, Baton .rouge a écrit :
On Sat, 04 May 2013 14:25:41 +0200, hameau wrote:
cela sous Samba,
Et pourquoi pas NFS ?
Salut,
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer /désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sur le site microsoft c'est spécifié entreprise et ultimate uniquement. La version pro peut se brosser (sauf peut etre en bricolant.
On Sun, 05 May 2013 00:41:04 +0200, Ascadix <ascadix.ng@free.fr>
wrote:
hameau a présenté l'énoncé suivant :
Le 04/05/2013 21:44, Baton .rouge a écrit :
On Sat, 04 May 2013 14:25:41 +0200, hameau <hameau.cl@free.fr> wrote:
cela sous Samba,
Et pourquoi pas NFS ?
Salut,
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer
/désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sur le site microsoft c'est spécifié entreprise et ultimate
uniquement. La version pro peut se brosser (sauf peut etre en
bricolant.
On Sun, 05 May 2013 00:41:04 +0200, Ascadix wrote:
hameau a présenté l'énoncé suivant :
Le 04/05/2013 21:44, Baton .rouge a écrit :
On Sat, 04 May 2013 14:25:41 +0200, hameau wrote:
cela sous Samba,
Et pourquoi pas NFS ?
Salut,
Il y a t'il un client NFS pour W7 pro 64 bits (OS installé sur mes 2 PC)
@+
Panneau de config -> Programmes et fonctionalités -> Activer /désactiver des fonctionalités Windows
Vers le bas de la liste : Services pour NFS / Client pour NFS
Sur le site microsoft c'est spécifié entreprise et ultimate uniquement. La version pro peut se brosser (sauf peut etre en bricolant.
Emmanuel Florac
Le Sat, 04 May 2013 14:25:41 +0200, hameau a écrit:
Le transfert entre le serveur et mon PC ne dépasse pas 60 Mo/s au maxi, aussi bien en lecture quand écriture, cela sous Samba, j'ai fait plusieurs tests en FTP et la je suis entre 100 et 120 Mo/s.
Pourquoi il y a t'il u,e si grosse différence de performances entre Samba et FTP, comment faire pour augmenter les performances sous smb.
Le protocole CIFS est assez peu efficace. Quel est l'OS du PC client? Il y a une différence énorme entre un Win XP et un Win 7 (typiquement, 100% ou plus). Si ton client est un windows XP 32 bits, la performance minable vient de là.
Si ton client est un linux, il faut savoir qu'il y a eu de très, très grosses améliorations sur les version récentes de noyau. Noyau < 3.2 = performance CIFS très basse.
Autres points à voir, le paramétrage du serveur: l'IO scheduler par défaut des noyaux Linux est CFQ. CFQ est à chier par terre pour les serveurs en général et pour le RAID en particulier. Utilise deadline ou noop pour les disques de ton RAID:
for DISK in sdb sdc sdd sde sdf do echo deadline > /sys/block/$DISK/queue/scheduler done
Tu peux aussi augmenter la file d'attente du RAID:
echo 512 > /sys/block/md0/queue/nr_requests
enfin augmenter la taille du buffer d'antélecture:
echo 4096 > /sys/block/md0/queue/read_ahead_kb
On peut aussi beaucoup gagner en paramétrant correctement le filesystem.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Sat, 04 May 2013 14:25:41 +0200, hameau a écrit:
Le transfert entre le serveur et mon PC ne dépasse pas 60 Mo/s au maxi,
aussi bien en lecture quand écriture, cela sous Samba, j'ai fait
plusieurs tests en FTP et la je suis entre 100 et 120 Mo/s.
Pourquoi il y a t'il u,e si grosse différence de performances entre
Samba et FTP, comment faire pour augmenter les performances sous smb.
Le protocole CIFS est assez peu efficace. Quel est l'OS du PC client? Il
y a une différence énorme entre un Win XP et un Win 7 (typiquement, 100%
ou plus). Si ton client est un windows XP 32 bits, la performance minable
vient de là.
Si ton client est un linux, il faut savoir qu'il y a eu de très, très
grosses améliorations sur les version récentes de noyau. Noyau < 3.2 =
performance CIFS très basse.
Autres points à voir, le paramétrage du serveur: l'IO scheduler par
défaut des noyaux Linux est CFQ. CFQ est à chier par terre pour les
serveurs en général et pour le RAID en particulier. Utilise deadline ou
noop pour les disques de ton RAID:
for DISK in sdb sdc sdd sde sdf
do
echo deadline > /sys/block/$DISK/queue/scheduler
done
Tu peux aussi augmenter la file d'attente du RAID:
echo 512 > /sys/block/md0/queue/nr_requests
enfin augmenter la taille du buffer d'antélecture:
echo 4096 > /sys/block/md0/queue/read_ahead_kb
On peut aussi beaucoup gagner en paramétrant correctement le filesystem.
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Sat, 04 May 2013 14:25:41 +0200, hameau a écrit:
Le transfert entre le serveur et mon PC ne dépasse pas 60 Mo/s au maxi, aussi bien en lecture quand écriture, cela sous Samba, j'ai fait plusieurs tests en FTP et la je suis entre 100 et 120 Mo/s.
Pourquoi il y a t'il u,e si grosse différence de performances entre Samba et FTP, comment faire pour augmenter les performances sous smb.
Le protocole CIFS est assez peu efficace. Quel est l'OS du PC client? Il y a une différence énorme entre un Win XP et un Win 7 (typiquement, 100% ou plus). Si ton client est un windows XP 32 bits, la performance minable vient de là.
Si ton client est un linux, il faut savoir qu'il y a eu de très, très grosses améliorations sur les version récentes de noyau. Noyau < 3.2 = performance CIFS très basse.
Autres points à voir, le paramétrage du serveur: l'IO scheduler par défaut des noyaux Linux est CFQ. CFQ est à chier par terre pour les serveurs en général et pour le RAID en particulier. Utilise deadline ou noop pour les disques de ton RAID:
for DISK in sdb sdc sdd sde sdf do echo deadline > /sys/block/$DISK/queue/scheduler done
Tu peux aussi augmenter la file d'attente du RAID:
echo 512 > /sys/block/md0/queue/nr_requests
enfin augmenter la taille du buffer d'antélecture:
echo 4096 > /sys/block/md0/queue/read_ahead_kb
On peut aussi beaucoup gagner en paramétrant correctement le filesystem.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
pehache
Le 04/05/13 23:52, Nicolas George a écrit :
Baton .rouge , dans le message , a écrit :
cela sous Samba,
Et pourquoi pas NFS ?
Ah, tu préfères le choléra à la peste ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
Le 04/05/13 23:52, Nicolas George a écrit :
Baton .rouge , dans le message
<59pao8dbc8b3q5tjudt8ol4a1oc37fes7a@4ax.com>, a écrit :
cela sous Samba,
Et pourquoi pas NFS ?
Ah, tu préfères le choléra à la peste ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour
faire du partage réseau ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
webdav ;)
T'as un serveur efficace ? Parceque mod_dav c'est pas ça et owncloud non plus...
-- Les simplifications c'est trop compliqué
Yliur
Le Sun, 12 May 2013 17:25:17 +0200 pehache a écrit :
Le 04/05/13 23:52, Nicolas George a écrit : > Baton .rouge , dans le message > , a écrit : >>> cela sous Samba, >> Et pourquoi pas NFS ? > > Ah, tu préfères le choléra à la peste ? >
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce n'est sans doute pas meilleur d'un point de vue performances. Par contre NFS j'avais essayé sur un réseau local et c'était un peu sensible, régulièrement c'était en vrac côté client et il fallait tout casser à la main. En fouillant un peu, il semble que si les machines ne sont pas précisément à la même heure certaines opérations ne se déroulent pas de manière optimale, ... J'ai l'impression (mais vu de mon peu de connaissances sur le sujet) que NFS c'est fait pour fonctionner dans un environnement soigneusement contrôlé. sshfs s'en sort beaucoup mieux.
Le Sun, 12 May 2013 17:25:17 +0200
pehache <pehache.7@gmail.com> a écrit :
Le 04/05/13 23:52, Nicolas George a écrit :
> Baton .rouge , dans le message
> <59pao8dbc8b3q5tjudt8ol4a1oc37fes7a@4ax.com>, a écrit :
>>> cela sous Samba,
>> Et pourquoi pas NFS ?
>
> Ah, tu préfères le choléra à la peste ?
>
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour
faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce
n'est sans doute pas meilleur d'un point de vue performances. Par
contre NFS j'avais essayé sur un réseau local et c'était un peu
sensible, régulièrement c'était en vrac côté client et il fallait tout
casser à la main. En fouillant un peu, il semble que si les machines ne
sont pas précisément à la même heure certaines opérations ne se
déroulent pas de manière optimale, ... J'ai l'impression (mais vu de
mon peu de connaissances sur le sujet) que NFS c'est fait pour
fonctionner dans un environnement soigneusement contrôlé. sshfs s'en
sort beaucoup mieux.
Le Sun, 12 May 2013 17:25:17 +0200 pehache a écrit :
Le 04/05/13 23:52, Nicolas George a écrit : > Baton .rouge , dans le message > , a écrit : >>> cela sous Samba, >> Et pourquoi pas NFS ? > > Ah, tu préfères le choléra à la peste ? >
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce n'est sans doute pas meilleur d'un point de vue performances. Par contre NFS j'avais essayé sur un réseau local et c'était un peu sensible, régulièrement c'était en vrac côté client et il fallait tout casser à la main. En fouillant un peu, il semble que si les machines ne sont pas précisément à la même heure certaines opérations ne se déroulent pas de manière optimale, ... J'ai l'impression (mais vu de mon peu de connaissances sur le sujet) que NFS c'est fait pour fonctionner dans un environnement soigneusement contrôlé. sshfs s'en sort beaucoup mieux.
pehache
Le 12/05/13 23:09, Yliur a écrit :
Le Sun, 12 May 2013 17:25:17 +0200 pehache a écrit :
Le 04/05/13 23:52, Nicolas George a écrit :
Baton .rouge , dans le message , a écrit :
cela sous Samba,
Et pourquoi pas NFS ?
Ah, tu préfères le choléra à la peste ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce n'est sans doute pas meilleur d'un point de vue performances. Par contre NFS j'avais essayé sur un réseau local et c'était un peu sensible, régulièrement c'était en vrac côté client et il fallait tout casser à la main. En fouillant un peu, il semble que si les machines ne sont pas précisément à la même heure certaines opérations ne se déroulent pas de manière optimale, ... J'ai l'impression (mais vu de mon peu de connaissances sur le sujet) que NFS c'est fait pour fonctionner dans un environnement soigneusement contrôlé. sshfs s'en sort beaucoup mieux.
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et sécurisé aux données d'une machine distante, mais pas vraiment comment un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais vraiment testé intensivement, je m'en sers juste ponctuellement. Il me semblait notamment qu'un fichier ouvert par sshfs était transféré en entier, non ?
Le 12/05/13 23:09, Yliur a écrit :
Le Sun, 12 May 2013 17:25:17 +0200
pehache <pehache.7@gmail.com> a écrit :
Le 04/05/13 23:52, Nicolas George a écrit :
Baton .rouge , dans le message
<59pao8dbc8b3q5tjudt8ol4a1oc37fes7a@4ax.com>, a écrit :
cela sous Samba,
Et pourquoi pas NFS ?
Ah, tu préfères le choléra à la peste ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour
faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce
n'est sans doute pas meilleur d'un point de vue performances. Par
contre NFS j'avais essayé sur un réseau local et c'était un peu
sensible, régulièrement c'était en vrac côté client et il fallait tout
casser à la main. En fouillant un peu, il semble que si les machines ne
sont pas précisément à la même heure certaines opérations ne se
déroulent pas de manière optimale, ... J'ai l'impression (mais vu de
mon peu de connaissances sur le sujet) que NFS c'est fait pour
fonctionner dans un environnement soigneusement contrôlé. sshfs s'en
sort beaucoup mieux.
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et
sécurisé aux données d'une machine distante, mais pas vraiment comment
un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais
vraiment testé intensivement, je m'en sers juste ponctuellement. Il me
semblait notamment qu'un fichier ouvert par sshfs était transféré en
entier, non ?
Le Sun, 12 May 2013 17:25:17 +0200 pehache a écrit :
Le 04/05/13 23:52, Nicolas George a écrit :
Baton .rouge , dans le message , a écrit :
cela sous Samba,
Et pourquoi pas NFS ?
Ah, tu préfères le choléra à la peste ?
Quoi d'autre à part Samba et NFS qui soit couramment disponible pour faire du partage réseau ?
ssh/sshfs ? Mais ça dépend de ce que tu entends par "couramment". Et ce n'est sans doute pas meilleur d'un point de vue performances. Par contre NFS j'avais essayé sur un réseau local et c'était un peu sensible, régulièrement c'était en vrac côté client et il fallait tout casser à la main. En fouillant un peu, il semble que si les machines ne sont pas précisément à la même heure certaines opérations ne se déroulent pas de manière optimale, ... J'ai l'impression (mais vu de mon peu de connaissances sur le sujet) que NFS c'est fait pour fonctionner dans un environnement soigneusement contrôlé. sshfs s'en sort beaucoup mieux.
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et sécurisé aux données d'une machine distante, mais pas vraiment comment un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais vraiment testé intensivement, je m'en sers juste ponctuellement. Il me semblait notamment qu'un fichier ouvert par sshfs était transféré en entier, non ?
Nicolas George
pehache , dans le message , a écrit :
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et sécurisé aux données d'une machine distante, mais pas vraiment comment un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais vraiment testé intensivement, je m'en sers juste ponctuellement. Il me semblait notamment qu'un fichier ouvert par sshfs était transféré en entier, non ?
Non, justement. SSHFS, c'est du SFTP comme protocole, et contrairement à ce que le nom indique, ce n'est pas juste du transfert comme FTP, mais bien de la manipulation à distance : les commandes du protocole SFTP correspondent assez directement aux primitives de manipulation de fichiers Unix : ouvrir, lire ou écrire un segment, etc.
pehache , dans le message <avbc6fF1a3nU1@mid.individual.net>, a écrit :
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et
sécurisé aux données d'une machine distante, mais pas vraiment comment
un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais
vraiment testé intensivement, je m'en sers juste ponctuellement. Il me
semblait notamment qu'un fichier ouvert par sshfs était transféré en
entier, non ?
Non, justement. SSHFS, c'est du SFTP comme protocole, et contrairement à ce
que le nom indique, ce n'est pas juste du transfert comme FTP, mais bien de
la manipulation à distance : les commandes du protocole SFTP correspondent
assez directement aux primitives de manipulation de fichiers Unix : ouvrir,
lire ou écrire un segment, etc.
J'avais toujours vu sshfs comme un accès pratique (comme webdav) et sécurisé aux données d'une machine distante, mais pas vraiment comment un protocole de fs réseau efficace. Peut-être à tort, je n'ai jamais vraiment testé intensivement, je m'en sers juste ponctuellement. Il me semblait notamment qu'un fichier ouvert par sshfs était transféré en entier, non ?
Non, justement. SSHFS, c'est du SFTP comme protocole, et contrairement à ce que le nom indique, ce n'est pas juste du transfert comme FTP, mais bien de la manipulation à distance : les commandes du protocole SFTP correspondent assez directement aux primitives de manipulation de fichiers Unix : ouvrir, lire ou écrire un segment, etc.
