Un interessant problème de performances avec Samba: nous avons un
serveur Samba sous un système Unix et des clients sous XP. Les clients
mettent des plombes à ouvrir certains fichiers, toujours les mêmes, qui
pourtant ne sont pas très gros en volume. D'autres fichiers s'ouvrent
très vite. Le problème ne suit donc pas la taille du fichier.
Si les fichiers problematiques sont copiés en local, le client les ouvre
rapidement. Le problème est donc lié au montage SMB.
Enfin, le même fichier s'ouvre lentement avec Word mais rapidement avec
le bloc-note. Il y a donc une influence de l'application qui ouvre. Ca
n'est pas le seul facteur, car certains documents Word s'ouvrent vite,
et on a des documents qui s'ouvrent lentement dans d'autres
applications.
En résumé: le problème suit la conjonction (fichier, application,
partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en
ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques
centaines de ko qui mettent 20 secondes à s'ouvrir.
Un interessant problème de performances avec Samba: nous avons un serveur Samba sous un système Unix et des clients sous XP. Les clients mettent des plombes à ouvrir certains fichiers, toujours les mêmes, qui pourtant ne sont pas très gros en volume. D'autres fichiers s'ouvrent très vite. Le problème ne suit donc pas la taille du fichier.
Si les fichiers problematiques sont copiés en local, le client les ouvre rapidement. Le problème est donc lié au montage SMB.
Enfin, le même fichier s'ouvre lentement avec Word mais rapidement avec le bloc-note. Il y a donc une influence de l'application qui ouvre. Ca n'est pas le seul facteur, car certains documents Word s'ouvrent vite, et on a des documents qui s'ouvrent lentement dans d'autres applications.
En résumé: le problème suit la conjonction (fichier, application, partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
A voir: - Les documents sont ils liés à d'autres (sur le serveur) ? - La feuille de style est-elle sur le serveur ou en local ? - Un document .txt s'ouvre-t-il aussi lentement ? - Le même document est-il ouvert par plusieurs postes en même temps ? - Cela fait-il pareil sur tous les postes du réseau ? - Le paramêtre TCP_NO-DELAY est il à Yes dans smb.conf ?
Emmanuel Dreyfus >>
Bonjour à tous
Un interessant problème de performances avec Samba: nous avons un
serveur Samba sous un système Unix et des clients sous XP. Les clients
mettent des plombes à ouvrir certains fichiers, toujours les mêmes,
qui pourtant ne sont pas très gros en volume. D'autres fichiers
s'ouvrent très vite. Le problème ne suit donc pas la taille du
fichier.
Si les fichiers problematiques sont copiés en local, le client les
ouvre rapidement. Le problème est donc lié au montage SMB.
Enfin, le même fichier s'ouvre lentement avec Word mais rapidement
avec le bloc-note. Il y a donc une influence de l'application qui
ouvre. Ca n'est pas le seul facteur, car certains documents Word
s'ouvrent vite, et on a des documents qui s'ouvrent lentement dans
d'autres applications.
En résumé: le problème suit la conjonction (fichier, application,
partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en
ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques
centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
A voir: - Les documents sont ils liés à d'autres (sur le serveur) ? - La
feuille de style est-elle sur le serveur ou en local ? - Un document
.txt s'ouvre-t-il aussi lentement ? - Le même document est-il ouvert par
plusieurs postes en même temps ? - Cela fait-il pareil sur tous les
postes du réseau ? - Le paramêtre TCP_NO-DELAY est il à Yes dans
smb.conf ?
Un interessant problème de performances avec Samba: nous avons un serveur Samba sous un système Unix et des clients sous XP. Les clients mettent des plombes à ouvrir certains fichiers, toujours les mêmes, qui pourtant ne sont pas très gros en volume. D'autres fichiers s'ouvrent très vite. Le problème ne suit donc pas la taille du fichier.
Si les fichiers problematiques sont copiés en local, le client les ouvre rapidement. Le problème est donc lié au montage SMB.
Enfin, le même fichier s'ouvre lentement avec Word mais rapidement avec le bloc-note. Il y a donc une influence de l'application qui ouvre. Ca n'est pas le seul facteur, car certains documents Word s'ouvrent vite, et on a des documents qui s'ouvrent lentement dans d'autres applications.
En résumé: le problème suit la conjonction (fichier, application, partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
A voir: - Les documents sont ils liés à d'autres (sur le serveur) ? - La feuille de style est-elle sur le serveur ou en local ? - Un document .txt s'ouvre-t-il aussi lentement ? - Le même document est-il ouvert par plusieurs postes en même temps ? - Cela fait-il pareil sur tous les postes du réseau ? - Le paramêtre TCP_NO-DELAY est il à Yes dans smb.conf ?
manu
mdnews wrote:
A voir: - Les documents sont ils liés à d'autres (sur le serveur) ?
Non. Le problème n'est d'ailleurs pas spécifique à Office: certains PDF trainent aussi.
- La feuille de style est-elle sur le serveur ou en local ?
Pas de feuille de style
- Un document .txt s'ouvre-t-il aussi lentement ?
Je n'ai pas trouvé de .txt à ouverture lente. A noter qu'un document qui s'ouvre lentement dans Office ou Acrobat va s'ouvrir vite dans le bloc notes.
- Le même document est-il ouvert par plusieurs postes en même temps ?
Non.
- Cela fait-il pareil sur tous les postes du réseau ?
Oui, et les fichiers lents sont les mêmes quel que soit le client.
- Le paramêtre TCP_NO-DELAY est il à Yes dans smb.conf ?
Oui.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
mdnews <mdnews@wanadoo.fr> wrote:
A voir: - Les documents sont ils liés à d'autres (sur le serveur) ?
Non. Le problème n'est d'ailleurs pas spécifique à Office: certains PDF
trainent aussi.
- La feuille de style est-elle sur le serveur ou en local ?
Pas de feuille de style
- Un document .txt s'ouvre-t-il aussi lentement ?
Je n'ai pas trouvé de .txt à ouverture lente. A noter qu'un document qui
s'ouvre lentement dans Office ou Acrobat va s'ouvrir vite dans le bloc
notes.
- Le même document est-il ouvert par plusieurs postes en même temps ?
Non.
- Cela fait-il pareil sur tous les postes du réseau ?
Oui, et les fichiers lents sont les mêmes quel que soit le client.
- Le paramêtre TCP_NO-DELAY est il à Yes dans
smb.conf ?
Si les fichiers problematiques sont copiés en local, le client les ouvre rapidement. Le problème est donc lié au montage SMB.
...crouic...
Une idée de la nature du problème?
Ta resolution de noms WINS est OK ?
-- pc
Kevin Denis
Le 24-06-2006, Emmanuel Dreyfus a écrit :
En résumé: le problème suit la conjonction (fichier, application, partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
Une analyse des trames permet elle de cerner le probleme?
-le fichier est il recupere d'un coup, puis met longtemps a etre traite en local? -le fichier est recupere par de tous petits morceaux? -le fichier met tres longtemps a demarrer la copie en local? -autre chose? -- Kevin
Le 24-06-2006, Emmanuel Dreyfus <manu@netbsd.org> a écrit :
En résumé: le problème suit la conjonction (fichier, application,
partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en
ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques
centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
Une analyse des trames permet elle de cerner le probleme?
-le fichier est il recupere d'un coup, puis met longtemps a etre traite
en local?
-le fichier est recupere par de tous petits morceaux?
-le fichier met tres longtemps a demarrer la copie en local?
-autre chose?
--
Kevin
En résumé: le problème suit la conjonction (fichier, application, partage réseau) et disparait si on modifie l'un de ces parametres.
Les débits sont corrects en FTP et en SMB, aussi bien en lecture qu'en ecriture: on est à plusieurs Mo/s, et on parle de fichiers de quelques centaines de ko qui mettent 20 secondes à s'ouvrir.
Une idée de la nature du problème?
Une analyse des trames permet elle de cerner le probleme?
-le fichier est il recupere d'un coup, puis met longtemps a etre traite en local? -le fichier est recupere par de tous petits morceaux? -le fichier met tres longtemps a demarrer la copie en local? -autre chose? -- Kevin
manu
Emmanuel Florac wrote:
Oui, et les fichiers lents sont les mêmes quel que soit le client. Est-ce que tu as essayé de recopier un fichier "lent" (juste le copier
avec un autre nom, par exemple)?
Ah, une piste: copier le fichier lent ne change rien, mais par contre le changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Oui, et les fichiers lents sont les mêmes quel que soit le client.
Est-ce que tu as essayé de recopier un fichier "lent" (juste le copier
avec un autre nom, par exemple)?
Ah, une piste: copier le fichier lent ne change rien, mais par contre le
changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires
rapides. Enfin pour certaines applications, puisque pour le bloc note,
tout s'ouvre vite.
Oui, et les fichiers lents sont les mêmes quel que soit le client. Est-ce que tu as essayé de recopier un fichier "lent" (juste le copier
avec un autre nom, par exemple)?
Ah, une piste: copier le fichier lent ne change rien, mais par contre le changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Emmanuel Florac
Le Wed, 28 Jun 2006 21:37:40 +0200, Emmanuel Dreyfus a écrit :
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
Est-ce qu'il y a beaucoup de fichiers dans les répertoires fautifs? Ou bien des ACLs tarabiscotées?
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Wed, 28 Jun 2006 21:37:40 +0200, Emmanuel Dreyfus a écrit :
J'ai l'impression qu'il y a des repertoires lents et des repertoires
rapides. Enfin pour certaines applications, puisque pour le bloc note,
tout s'ouvre vite.
Est-ce qu'il y a beaucoup de fichiers dans les répertoires fautifs? Ou
bien des ACLs tarabiscotées?
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Le Wed, 28 Jun 2006 21:37:40 +0200, Emmanuel Dreyfus a écrit :
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
Est-ce qu'il y a beaucoup de fichiers dans les répertoires fautifs? Ou bien des ACLs tarabiscotées?
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Philippe Michel
On 2006-06-28, Emmanuel Dreyfus wrote:
Ah, une piste: copier le fichier lent ne change rien, mais par contre le changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
Le bloc-note ouvre simplement le fichier qu'on lui demande alors qu'il y a des chances que les autres applications fassent plus que ça.
Un truss/strace du smbd impliqué devrait permettre de vérifier ce qui se passe réellement sur le serveur dans les différents cas.
On 2006-06-28, Emmanuel Dreyfus <manu@netbsd.org> wrote:
Ah, une piste: copier le fichier lent ne change rien, mais par contre le
changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires
rapides. Enfin pour certaines applications, puisque pour le bloc note,
tout s'ouvre vite.
Le bloc-note ouvre simplement le fichier qu'on lui demande alors qu'il y a
des chances que les autres applications fassent plus que ça.
Un truss/strace du smbd impliqué devrait permettre de vérifier ce qui se
passe réellement sur le serveur dans les différents cas.
Ah, une piste: copier le fichier lent ne change rien, mais par contre le changer de repertoire change quelque chose.
J'ai l'impression qu'il y a des repertoires lents et des repertoires rapides. Enfin pour certaines applications, puisque pour le bloc note, tout s'ouvre vite.
Le bloc-note ouvre simplement le fichier qu'on lui demande alors qu'il y a des chances que les autres applications fassent plus que ça.
Un truss/strace du smbd impliqué devrait permettre de vérifier ce qui se passe réellement sur le serveur dans les différents cas.
manu
Philippe Michel wrote:
Un truss/strace du smbd impliqué devrait permettre de vérifier ce qui se passe réellement sur le serveur dans les différents cas.
Oui, sauf que une trace des appels système raconte vraiment trop de choses...
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Philippe Michel <philippe.michel3@tele1plus1.fr.invalid> wrote:
Un truss/strace du smbd impliqué devrait permettre de vérifier ce qui se
passe réellement sur le serveur dans les différents cas.
Oui, sauf que une trace des appels système raconte vraiment trop de
choses...
