Le 8 sept. 05 à 17:10, Nicolas Dorfsman a écrit :
Bof. Le fait de "nicer" un process va lui donner moins de ticks
CPU (si je dis pas de bêtises), mais il n'empêche que quand ton
load average monte à 2xnbCPU, c'est tous process confondu, et ça
veut bel et bien dire que tu as 2 runnable process en attente par
CPU, ce qui commence à faire beaucoup de monde qui attend les CPUs
Bof, autant que la machine serve. J'ai des serveurs de calculs qui
monte à 30 & 2 serveurs web biproc qui tourne couramment à 10 & +.
Dans le premier cas, je dirais que de toute façon je me fous du temps
de réponse. Pour mon serveur web, l'impact est minime sur le temps de
réponse, vu que y a surtout du réseau.
En résumé, rien ne vaut un bon bench, en ayant des objectifs de QOS
pour savoir où est réellement le goulot d'étranglement. Bon une load
qui passe de 0,05 à 25 brutalement, là oui, y a un problème.
Pour revenir sur la notion de load. Pour moi, c'est la runqueue de
LWP. Un process avec deux thread qui attendent pour faire des
calculs : load de 2.
10 process en attente d'IO : load de 0.
Je viens de vérifier. J'ai une octoprocesseur sur laquel il y a un
seul process multi-thread qui tourne. Il fait effectivement beaucoup
de calcul & la load monte facilement à 3 en période de pique.
Pour valider le disque, un peu plus compliqué, pas trop le temps.
Mais si on jette un coup d'œil sur le man de vmstat :
The fields of vmstat's display are
kthr Report the number of kernel threads in each of
the three following states:
r in run queue
b blocked for resources I/O, paging, and so
forth
w swapped
_______________________________________________
Solaris_fr liste de diffusion en français pour Solaris, sur toutes architectures
[email protected]
http://x86.sun.com/mailman/listinfo/solaris_fr
