Le 16 août 05 à 12:53, Gérard Henry a écrit :
bonjour,
en lisant les diverses docs de sun relatives a ce produit, je lis
qu'il faut regler la taille de l'entrelacement par rapport a
l'usage du serveur.
Mais sur un serveur generaliste (serveur nfs), il est plutot
difficile de connaitre la taille moyenne des blocs utilises par les
applis.
Il y a une doc "Sun Performances best practices" (http://
www.sun.com/blueprints/1103/817-4368.pdf), on parle de split d'I/O
si la largeur de l'entrelacement est trop faible.
Mais ce qui manque dans ces docs, ce sont les moyens de mesurer les
performances actuelles d'un systeme pour voir si il y a
effectivement des regalges a faire.
Peut on mesurer le split des I/O?
La taille moyenne des requêtes est déjà un bon indicateur. Si elle
est plus grande que la taille de strip, c'est sur y a éclatement des
requêtes. En dessous, ça va dépendre de l'alignement. Ça doit être
pour ça que Sun prends 16 ko par défaut : 2 x la taille de page.
lorsqu'on utilise iostat, il y a la colonne svc_t, comment
l'interpreter?
Le svc_t, c'est le temps moyen que passe les requêtes à l'intérieur
du disque (ou de la baie), c'est lui qu'il s'agit de réduire.
en general, il semble que les exemples de sun emploient un stripe
de 16ko, est ce que c'est parce que c'est la meilleure valeur pour
un serveur generaliste?
Est ce que vous mettriez du raid5 sur un JBOD style D1000? par
rapport a du raid 0+1, est ce que la chute de perfs se limitera a
20% ou plus?
l'ideal serait d'acheter du nouveau materiel, mais sur sparc, ca
fait un peu cher...
raid5 soft c'est hors de question. Trop de perte de performance &
quand un disque à un problème, c'est vraiment la mort. Faut
obligatoirement avoir un disque de secours & même, j'ose pas imaginer
l'état de la machine pendant la migration des données. Quelqu'un a
parlé d'infortrend, dont j'avais déjà entendu dire du bien. HP aussi,
il parait que c'est pas mal. Si t'as que du soft, regarde l'écart de
prix entre du 0+1 soft & un contrôleur hard raid 5 en intégrant le
disque de spare. Tu vas peut-être t'y retrouver si tu prends pas des
disques Sun.
au fait, il y a qq temps, qqun proposait de faire des benches
est ce que des benches du type:
time dd if=/dev/zero of=file bs=taille count=1
avec taille prenant des valeurs comme 512,2040,8192,16ko, 256k, 1Mo
et en lancant plusieurs en parallele? (ici 16ko est la taille du
stripe)
dd fait des accès séquentiel, donc même en jouant sur la taille du
strip, ça va pulser. Donc regarde plutôt du coté de iozone ou bonnie+
+, qui génère aussi des accès aléatoire. Surtout si tu fais du NFS
avec plein d'utilisateurs qui tape au hasard dans l'arbo, dont un qui
fait un find / parce qu'il retrouve plus ses fichiers.
PS: si 16ko est la taille du stripe, est ce ca un interet de
choisir aussi 16ko comme taille de bloc avec ufsdump lors de la
sauvegarde d'un sous mirroir sur le lto?
Bof, une sauvegarde, c'est du séquentiel donc les mécanismes
d'anticipation de lecture vont jouer à fond je pense. Je pense qu'il
faut plutôt optimiser pour le lto que pour les disques.
_______________________________________________
Solaris_fr liste de diffusion en français pour Solaris, sur toutes
architectures
[email protected]
http://x86.sun.com/mailman/listinfo/solaris_fr
--
Comme les gars de 9Télécom sont des branquignoles & surtout ceux de
la messagerie, vous pouvez oublier l'adresse 9online.fr & m'écrire à
partir de maintenant à [EMAIL PROTECTED]
_______________________________________________
Solaris_fr liste de diffusion en français pour Solaris, sur toutes architectures
[email protected]
http://x86.sun.com/mailman/listinfo/solaris_fr
