Interpréter les différences entre prstat et 'prstat -m' sous Solaris

Question

J'utilise prstat et prstat -ma beaucoup pour étudier les problèmes de performances dernièrement, et je pense avoir essentiellement compris les différences entre l'échantillonnage et la comptabilité par micro-état. Solaris 10. Je ne m'attends donc pas à ce que les deux affichent toujours exactement le même nombre.

Aujourd'hui je suis tombé sur une occasion où les 2 ont montré des sorties tellement différentes, que j'ai du mal à les interpréter et à donner un sens à la sortie. La machine est un Solaris 10 à 8 processeurs très chargé, avec plusieurs processus WebSphere importants et une base de données Oracle. Le système s'est pratiquement arrêté aujourd'hui pendant environ 15 minutes (moyenne de charge> 700). J'ai eu des difficultés à obtenir des informations préliminaires, mais j'ai pu obtenir quelques sorties de "prtstat 1 1" et "prtstat -m 1 1", publiées peu de temps après l'autre.

Les premières lignes des sorties:

prstat 1 1:

 
    PID USERNAME SIZE RSS STATE PRI NICE  TIME CPU PROCESS/NLWP 
    8379 was  3208M 2773M cpu5 60 0 5:29:13 19% java/145 
    7123 was  3159M 2756M run  59 0 5:26:45 7.7% java/109 
    5855 app1  1132M 26M cpu2 60 0 0:01:01 7.7% java/18 
16503 monitor 494M 286M run  59 19 1:01:08 7.1% java/106 
    7112 oracle  15G 15G run  59 0 0:00:10 4.5% oracle/1 
    7124 oracle  15G 15G cpu3 60 0 0:00:10 4.5% oracle/1 
    7087 app1  15G 15G run  58 0 0:00:09 4.0% oracle/1 
    7155 oracle  96M 6336K cpu1 60 0 0:00:07 3.6% oracle/1 
... 
Total: 495 processes, 4581 lwps, load averages: 74.79, 35.35, 23.8 

prstat -m 1 1 (quelques secondes plus tard)

 
    PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/NLWP 
    7087 app1  0.1 56 0.0 0.2 0.4 0.0 13 30 96 2 33 0 oracle/1 
    7153 oracle 0.1 53 0.0 3.2 1.1 0.0 1.0 42 82 0 14 0 oracle/1 
    7124 oracle 0.1 47 0.0 0.2 0.2 0.0 0.0 52 77 2 16 0 oracle/1 
    7112 oracle 0.1 47 0.0 0.4 0.1 0.0 0.0 52 79 1 16 0 oracle/1 
    7259 oracle 0.1 45 9.4 0.0 0.3 0.0 0.1 45 71 2 32 0 oracle/1 
    7155 oracle 0.0 42 11 0.0 0.5 0.0 0.1 46 90 1 9 0 oracle/1 
    7261 oracle 0.0 37 9.5 0.0 0.3 0.0 0.0 53 61 1 17 0 oracle/1 
    7284 oracle 0.0 32 5.9 0.0 0.2 0.0 0.1 62 53 1 21 0 oracle/1 
... 
Total: 497 processes, 4576 lwps, load averages: 88.86, 39.93, 25.51 

J'ai beaucoup de mal interpréter le résultat. prstat semble me dire qu'une bonne partie du traitement Java est en cours, ainsi que certaines choses Oracle, comme je m'y attendais normalement. prtstat -m montre une machine totalement dominée par Oracle, consommant énormément de temps système, et le CPU global étant fortement surchargé (grand nombre en LAT). Je suis enclin à croire la sortie de prstat -m, parce que cela correspond beaucoup plus à ce que le système ressenti pendant cette période. Totalement léthargique, presque pas de traitement des requêtes utilisateur en cours depuis WebSphere, etc. Mais pourquoi prstat montrerait-il des nombres si fortement différents?

Toute explication de ce serait la bienvenue!

CU, Joe

Answer 1

Il y a un problème connu avec prstat -m sur Solaris dans les chiffres d'utilisation cpu mode de calcul - la valeur que vous voyez a été en moyenne sur toutes les discussions (lwps) dans un processus, et est donc bien loin trop faible pour les processus fortement multithread - tels que vos serveurs d'applications Java, qui peuvent avoir des centaines de threads chacun (voir votre NLWP). Moins d'une douzaine d'entre eux sont probablement des processeurs CPU, d'où l'utilisation du processeur par Java semble "faible". Vous auriez besoin de l'appeler avec prstat -Lm pour obtenir la répartition par thread (LWP) pour voir cet effet. Référence:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6780169

Sans d'autres données de surveillance des performances, il est difficile de donner des explications non spéculatives de ce que vous avez vu là-bas. J'assume le conflit de verrou dans Java. Une charge de travail particulière qui peut provoquer cela est fortement E/S mappé mémoire multithread, ils s'accumulent tous sur le verrou d'espace adresse de processus. Mais il pourrait bien s'agir d'un verrou java useride, bien sûr. Un plockstat sur l'un des processus Java, et/ou un simple profilage dtrace serait utile.