Performance samba

[atomio]

Bonjour,

J'ai un bi-proG4 1,25 sous 10.3.9.
J'aivais utilisé SharePoint pour partager un repertoire contenant env 40000 img/5Go entre des mac et pc sous Windows .Çà fonctionne très bien, mais j'ai un gros problème de process, quand on visualise le contenu du répertoire en réseau (Mac où pc), le bipro s'emballe et le(s) process smbd s'accapare à chaque fois 90-95% du temps machine .
En pensant que c'etait SharePoint qui était la cause du problème, j'ai configuré manuellement et de façon "basique" le fichier smb.conf, le résultat est identique ...
Avec vous rencontrez aussi ce probleme ?
Quelles seraient les paramètres à rajouter dans le fichier smb.conf pour optimiser ce serveur de fichier .
Chose curieuse, l'affichage du contenu du répertoire en réseau est beaucoup plus rapide sous Windows .

Merci de votre aide .

 

[pupa]

Salut,
ce qui serait bien c'est que tu nous mettes une copie de ton smb.conf (complet)
pour pouvoir vérifier tous tes paramètres
@ +

 

[atomio]

Excusez-moi du retard de réponse, j'arrive pas à me logguer dans le forum depuis chez moi :mouais: .

Voici une copie du fichier, je suis repassé par SharePoint, c'est plus pratique pour le partage Mac/Mac ...

fichier smb.conf:

encrypt passwords = yes
auth methods = guest opendirectory
passdb backend = opendirectorysam guest
printer admin = @admin, @staff
server string = Mac OS X
unix charset = UTF-8-MAC
display charset = UTF-8-MAC
dos charset = CP0
use spnego = no
client ntlmv2 auth = no
defer sharing violations = no
map to guest = Bad User
security = USER
local master = yes
hide dot files = yes
workgroup = WORKGROUP


[homes]
comment = User Home Directories
browseable = yes
read only = no


;[public]
;path = /tmp
;public = yes
;only guest = yes
;writable = yes
;printable = no


[printers]
path = /tmp
printable = yes



path = /Volumes/TAF2/IMG
read only = No
inherit permissions = Yes
guest ok = No
;Created by SharePoints
[/B]
j'ai survolé le Howto de Samba et lu divers docs, dont bcp sont traitées sur LINUX, alors je ne sais pas si c'est adapté pour MacOSX 10.3 .
Voici quand même les modifications que j'avais fait manuellement:

[B] [IMG]
comment = IMG
path = /Volumes/TAF2/IMG
read only = no
browseable = yes
create mode = 755[/B]

J'aivais aussi rajouté en dessous de [B]workgroup = WORKGROUP[/B] (bien que je ne sache pas vraiment où le placé) : [B]tcp options = TCP_NODELAY[/B] .

merci de votre aide .

 

[Zeusviper]

L'affolement du processeur est-il vraiment du à l'accès au réseau ou a des considérations d'affichage?

Lorsque tu liste ton repertoire partagé via le terminal par ex, est ce que ca rame de la meme facon?
Si non, la différence de temps d'affichage windows/mac sera du aux apercus éventuels, à la création automatique d'apercu, ou autres trucs du meme genre.

et sinon chez moi, "seulement" 7000 images en affichage par liste : smbd monte a 70% (ibook G4 1,3) et 5min pour tt afficher.


le protocole smb n'est pas rapide à la base..
pour le partage mac/mac privilegier afp.

et sinon vive les arborescences!! Y a vraiment besoin d'avoir 40000 images dans un unique dossier??

++

 

[atomio]

Merci de ta reponse Zeusviper,

Les procs s'emballent m^me avec un ls mais comme il n'y a pas d'aperçu, tout redevient normal rapidement .Dans le Finder où l'exporateur sous windows même sans aperçu (affichage sur le poste client en mode liste) les procs s'emballent .
Du coup sur Mac je passe par AFP, le "serveur" est moins sollicité étrangement .
C'est étonnant que tu me dises que samba n'est pas très rapide (je le constate aussi) , c'est utilisé en entreprise pour le partage de grand volume pourtant, bon c'est sûr, ils ont du RAID etc ...

Malheureusement dans mon cas il faut toutes ces images, il y a 100 clichés qui se rajoutent chaque jour .Même si je dispatche les img sur des volumes différents le problème demeurera (dans ce cas precis il s'agit d'un DD dédié non partitionné), il suffira que tout le monde accède en même temps au partage quel que soit le volume cible pour que çà s'emballe à nouveau .

je continue mes investigations .
merci
A+

 

[Zeusviper]

SMB est utilisé car c'est le protocole utilisé par windows, et parce que c'est un des seuls à fonctionner correctement sous windows!
Comme en plus samba, version open-source de SMB en gros, porte ce protocole sur toute plateforme, il est plutot bien implanté!

Mais il conserve des bases vieillottes d'ou sa relative lenteur. Je pense qu'en analysant vraiment les utilisations, il y aurai moyen d'optimiser le tout en bloquant certains services (smb permet le partage imprimante périphériques et fichiers entre autres).

Sinon, quand je disais de créer une arborescence, je ne pensais pas à plusieurs disques, mais simplement les regrouper par dossiers. Tu dis avoir 100 photos par jour. pkoi ne pas créer un nouveau dossier chaque jour tout en conservant un seul dossier racine en partage smb. Cela améliorera la réactivité vu que l'utilisateur ne demandera l'affichage que de 100 photos à la fois.


Après c'est trés cher c sur, mais un véritable serveur de fichiers sera forcément bcp plus rapide (NAS par ex). D'autres protocoles de transfert aussi(NFS par ex). Voir s'intéresser à la structure même du réseau, taille de fragmentation, taux de correction d'erreur, ... mais là ca se complique sérieusement!

A++

 

[atomio]

Salut,

Merci pour tes suggestions, malheureusement, on ne peut pas créer un nouveau repertoire automatiquement chaque jour, le logiciel et matériel d'export est proprio sous Windows ne permet pas de le faire, je vais essayer avec un script shell de le faire partir du serveur afin que les nouveaux clichés soit rangé et daté chaque fin de journée.
Le NAS, je vais me renseigné sur les perf/prix, je pense que c'est la meilleur solution .
LE NFS, je ne connais pas sont implémentation sous windows et MacOS, çà vaut peut être le coup de m'y interessé .
Merci encore .
A+:zen:

 

[bompi]

NFS est implémenté depuis "toujours" sur Mac OS X (et NeXT avant lui). C'est sympa mais pas très performant et un véritable gruyère en terme de sécurité.
Les implémentations pour Windows existent mais bon ...

 

[atomio]

NFS est implémenté depuis "toujours" sur Mac OS X (et NeXT avant lui). C'est sympa mais pas très performant et un véritable gruyère en terme de sécurité.
Les implémentations pour Windows existent mais bon ...

Merci pour l'info

 

[atomio]

Pour ceux qui sera aussi interessé, j'ai trouvé ce matin dans un tuto LINUX, qqs options suppplémentaires à rajouter au fichier smb.conf :

# A la connexion, le client et le serveur négocie la taille maximale
# des commandes SMB (performance)
# On définit ici la taille maximale acceptée par le serveur
# Valeur par defaut : 65535
max xmit = 65535
# Active le code de lecture avec prédiction. (performance)
# N`est plus active a partir de samba 2.0.0
# Valeur par defaut : False
read prediction = False
# lecture en mode raw - paquets de 64K - (performance)
# Valeur par defaut : yes read raw = yes
# Valeur par defaut : 2048
read size = 8192
# (performance)
socket options = TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096
# active un algorithme de cache. (performance)
# Valeur par defaut : no
getwd cache = yes
# écriture en mode raw - paquets de 64K - (performance)
# Valeur par defaut : yes
write raw = yes

Je vais tester ces valeurs à tête reposé ce we .:zen:

 

[atomio]

bonjour,

j'ai pu tester avec ces nouvelles valeurs, y a pas photo, c'est extrement plus rapide, environ 20s sous un poste Windows pour lister mon repertoire de 40000 élements .De Mac à Mac c'est plus lent même en passant par AFP :mouais: .
je vais voir si on peut faire qqchose ...
Sinon il y a d'autres valeurs possibles que j'ai pu lire sur "http://www.macosxhints.com" à cette page:
http://www.macosxhints.com/article.php?story=20040324053434397
Peut être plus adapté à notre OS .
Les procs sont aussi moins sollicités .

Voilà qui me rassure un peu sur les perfs de MacOSX .
Bonne journée .