Charge moyenne élevée, faible utilisation du processeur - pourquoi?

Nous constatons d'énormes problèmes de performances sur une application Web et nous essayons de trouver le goulot d'étranglement. Je ne suis pas administrateur système, alors il y a des choses que je ne comprends pas très bien. Certaines études de base montrent que le processeur est inactif, que beaucoup de mémoire est disponible, pas de permutation, pas d’E / S, mais une charge moyenne élevée.

La pile de logiciels sur ce serveur ressemble à ceci:

• Solaris 10
• Java 1.6
• WebLogic 10.3.5 (8 domaines)

Les applications exécutées sur ce serveur parlent avec une base de données Oracle sur un autre serveur.

Ce serveur a 32 Go de RAM et 10 processeurs (je pense).

Courir prstat -Zdonne quelque chose comme ça:

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
  3836 ducm0101 2119M 2074M cpu348  58    0   8:41:56 0.5% java/225
 24196 ducm0101 1974M 1910M sleep   59    0   4:04:33 0.4% java/209
  6765 ducm0102 1580M 1513M cpu330   1    0   1:21:48 0.1% java/291
 16922 ducm0102 2115M 1961M sleep   58    0   6:37:08 0.0% java/193
 18048 root     3048K 2440K sleep   59    0   0:06:02 0.0% sa_comm/4
 26619 ducm0101 2588M 2368M sleep   59    0   8:21:17 0.0% java/231
 19904 ducm0104 1713M 1390M sleep   59    0   1:15:29 0.0% java/151
 27809 ducm0102 1547M 1426M sleep   59    0   0:38:19 0.0% java/186
  2409 root       15M   11M sleep   59    0   0:00:00 0.0% pkgserv/3
 27204 root       58M   54M sleep   59    0   9:11:38 0.0% stat_daemon/1
 27256 root       12M 8312K sleep   59    0   7:16:40 0.0% kux_vmstat/1
 29367 root      297M  286M sleep   59    0  11:02:13 0.0% dsmc/2
 22128 root       13M 6768K sleep   59    0   0:10:51 0.0% sendmail/1
 22133 smmsp      13M 1144K sleep   59    0   0:01:22 0.0% sendmail/1
 22003 root     5896K  240K sleep   59    0   0:00:01 0.0% automountd/2
 22074 root     4776K 1992K sleep   59    0   0:00:19 0.0% sshd/1
 22005 root     6184K 2728K sleep   59    0   0:00:31 0.0% automountd/2
 27201 root     6248K  344K sleep   59    0   0:00:01 0.0% mount_stat/1
 20964 root     2912K  160K sleep   59    0   0:00:01 0.0% ttymon/1
 20947 root     1784K  864K sleep   59    0   0:02:22 0.0% utmpd/1
 20900 root     3048K  608K sleep   59    0   0:00:03 0.0% ttymon/1
 20979 root       77M   18M sleep   59    0   0:14:13 0.0% inetd/4
 20849 daemon   2856K  864K sleep   59    0   0:00:03 0.0% lockd/2
 17794 root       80M 1232K sleep   59    0   0:06:19 0.0% svc.startd/12
 17645 root     3080K  728K sleep   59    0   0:00:12 0.0% init/1
 17849 root       13M 6800K sleep   59    0   0:13:04 0.0% svc.configd/15
 20213 root       84M   81M sleep   59    0   0:47:17 0.0% nscd/46
 20871 root     2568K  600K sleep   59    0   0:00:04 0.0% sac/1
  3683 ducm0101 1904K 1640K sleep   56    0   0:00:00 0.0% startWebLogic.s/1
 23937 ducm0101 1904K 1640K sleep   59    0   0:00:00 0.0% startWebLogic.s/1
 20766 daemon   5328K 1536K sleep   59    0   0:00:36 0.0% nfsmapid/3
 20141 daemon   5968K 3520K sleep   59    0   0:01:14 0.0% kcfd/4
 20093 ducm0101 2000K  376K sleep   59    0   0:00:01 0.0% pfksh/1
 20797 daemon   3256K  240K sleep   59    0   0:00:01 0.0% statd/1
  6181 root     4864K 2872K sleep   59    0   0:01:34 0.0% syslogd/17
  7220 ducm0104 1268M 1101M sleep   59    0   0:36:35 0.0% java/138
 27597 ducm0102 1904K 1640K sleep   59    0   0:00:00 0.0% startWebLogic.s/1
 27867 root       37M 4568K sleep   59    0   0:13:56 0.0% kcawd/7
 12685 ducm0101 4080K  208K sleep   59    0   0:00:01 0.0% vncconfig/1
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
    42      135   22G   19G    59%  87:27:59 1.2% dsuniucm01

Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11

Je comprends que le processeur est principalement inactif, mais que la charge moyenne est élevée, ce qui m'est assez étrange. La mémoire ne semble pas être un problème.

Courir vmstat 15donne quelque chose comme ça:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s4 sd   in   sy   cs us sy id
 0 0 0 32531400 105702272 317 1052 126 0 0 0 0 13 13 -0 8 9602 107680 10964 1 1 98
 0 0 0 15053368 95930224 411 2323 0 0 0 0 0 0  0  0  0 23207 47679 29958 3 2 95
 0 0 0 14498568 95801960 3072 3583 0 2 2 0 0 3 3  0 21 22648 66367 28587 4 4 92
 0 0 0 14343008 95656752 3080 2857 0 0 0 0 0 3 3  0 18 22338 44374 29085 3 4 94
 0 0 0 14646016 95485472 1726 3306 0 0 0 0 0 0 0  0  0 24702 47499 33034 3 3 94

Je comprends que le processeur est principalement inactif, qu’aucun processus n’attend dans la file pour être exécuté, que peu d’échanges ont lieu.

Courir iostat 15donne ceci:

   tty        sd0           sd1           sd4           ssd0           cpu
 tin tout kps tps serv  kps tps serv  kps tps serv  kps tps serv   us sy wt id
   0  676 324  13    8  322  13    8    0   0    0  159   8    0    1  1  0 98
   1 1385   0   0    0    0   0    0    0   0    0    0   0    0    3  4  0 94
   0  584  89   6   24   89   6   25    0   0    0  332  19    0    2  1  0 97
   0  296   0   0    0    0   0    0    0   0    0    0   0    0    2  2  0 97
   1 1290  43   5   24   43   5   22    0   0    0  297  20    1    3  3  0 94

En cours d'exécution netstat -i 15donne les éléments suivants:

    input   aggr26    output       input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls
1500233798 0     1489316495 0     0      3608008314 0     3586173708 0     0
10646   0     10234   0     0      26206   0     25382   0     0
11227   0     10670   0     0      28562   0     27448   0     0
10353   0     9998    0     0      29117   0     28418   0     0
11443   0     12003   0     0      30385   0     31494   0     0

Qu'est-ce que je rate?

Après des recherches plus poussées, il semble que le problème de performances soit principalement dû à un nombre élevé d'appels réseau entre deux systèmes (Oracle SSXA et UCM). Les appels sont rapides mais nombreux et sérialisés, d’où la faible utilisation de la CPU (principalement des E / S en attente), la charge moyenne élevée (nombreux appels en attente de traitement) et surtout les temps de réponse longs (par accumulation de temps de réponse courts).

Merci pour votre perspicacité sur ce problème!

Lorsque vous dites «Charge moyenne élevée», je suppose que vous voulez dire que prstat indique «charge moyenne» au bas des chiffres de sortie de

Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11

Ces chiffres ressemblent à ceux fournis par le haut et indiquent probablement la taille moyenne de la file d'attente du processus en cours d'exécution. Ce n'est pas le pourcentage de temps utilisé par le processeur, mais le nombre de choses qui harcèlent le processeur pendant le temps d'exécution. Certes, cela a l'air assez élevé, mais tout dépend de l'application que vous utilisez; les processus risquent en réalité de ne pas faire grand chose une fois qu'ils ont obtenu leur place. Voir ici pour une bonne explication concernant top.

Je ne connais pas WebLogic, mais j’ai remarqué que, généralement, avec Apache Tomcat, de nombreux threads Java peuvent être créés simultanément pour ce qui apparaît comme peu de requêtes. C'est peut-être cela qui cause ces nombres de charge moyens élevés. Assurez-vous que vous utilisez le regroupement de connexions le cas échéant pour vous connecter au back-end et envisagez d'augmenter le nombre de threads inactifs disponibles dans votre application pour gérer les connexions (vous ne savez pas comment procéder avec WebLogic; Tomcat dispose d'un pool de threads par connecteur ou un pool de threads exécuteur général). Si vous ne le faites pas, de nouvelles discussions peuvent être créées pour traiter les demandes.

En ce qui concerne les performances, vous devez déterminer quelle partie de votre application souffre. S'agit-il du traitement qui se passe dans les domaines WebLogic / Java, l'accès à la base de données, les recherches DNS (si elles sont effectuées pour une raison quelconque ...), des problèmes de réseau ou quelque chose sur le système d'exploitation.

99% du temps, ce sera votre code et la façon dont il communique avec la base de données qui bloque les choses. Ensuite, ce sera la configuration de l'application Web. Au-delà de cette étape, vous travaillerez à réduire les dernières millisecondes de votre application ou à fournir une simultanéité supérieure avec le même matériel. Pour un réglage de performance plus fin, vous avez besoin de métriques.

Pour Java, je vous suggère d'installer Java Melody . Il peut fournir beaucoup d’informations sur ce que fait votre programme et aider à préciser les domaines dans lesquels il passe du temps. Je ne l'ai utilisé qu'avec Tomcat, mais cela devrait fonctionner avec n'importe quel conteneur / servlet Java EE.

Vous pouvez ajuster Java de différentes façons. Consultez leurs consignes de performances (je suis certain que vous l’avez probablement fait) et assurez-vous de définir la taille correcte du tas, etc., adaptée à votre programme. Java Melody peut vous aider à déterminer la taille du segment de mémoire Java que vous consommez, ainsi que le fonctionnement du ramasse-miettes / la fréquence à laquelle il interrompt votre programme pour effacer les objets.

J'espère que cela a été utile. Si vous fournissez plus d'informations, je pourrai peut-être mettre à jour cette réponse et l'ajuster davantage à vos besoins.

En passant, la charge moyenne inclut également les choses en attente d'activité sur le disque (c.-à-d. Harceler le disque) ainsi que celles en attente de processeur, c'est la somme des deux ... vous pourriez donc avoir des problèmes dans l'un ou l'autre.

Voir http://en.wikipedia.org/wiki/Load_(computing) "Linux inclut également [dans sa charge moyenne] les processus en état de veille ininterruptible (généralement en attente d'activité du disque)"

En passant, le problème particulier que j’ai rencontré est que j’avais une charge moyenne élevée, mais aussi beaucoup de processeurs inactifs et une faible utilisation du disque.

Il semble que, du moins dans mon cas, parfois des threads / processus en attente d'E / S apparaissent dans la charge moyenne, mais n'entraînent pas une augmentation de la colonne "wait". Mais ils sont toujours liés I / O.

Vous pouvez dire que c'est le cas avec le code suivant, si vous l'exécutez dans jruby (ne fait que 100 threads avec beaucoup d'E / S chacun):

100.times { Thread.new { loop { File.open('big', 'w') do |f| f.seek 10_000_000_000; f.puts 'a'; end}}}

Ce qui donne une sortie supérieure comme ceci:

top - 17:45:32 up 38 days,  2:13,  3 users,  load average: 95.18, 50.29, 23.83
Tasks: 181 total,   1 running, 180 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.5%us, 11.3%sy,  0.0%ni, 85.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32940904k total, 23239012k used,  9701892k free,   983644k buffers
Swap: 34989560k total,        0k used, 34989560k free,  5268548k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31866 packrd    18   0 19.9g  12g  11m S 117.0 41.3   4:43.85 java
  912 root      11  -5     0    0    0 S  2.0  0.0   1:40.46 kjournald

Vous voyez donc qu’il a beaucoup de processeurs inactifs, 0,0% wa, mais une charge moyenne très élevée.

De même, iostat montre que le disque est pratiquement inactif:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       9.62    0.00    8.75    0.00    0.00   81.62

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    49.00  0.00  6.40     0.00   221.60    69.25     0.01    0.81   0.66   0.42
sda1              0.00    49.00  0.00  6.40     0.00   221.60    69.25     0.01    0.81   0.66   0.42
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

voir aussi http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html

De plus, cela semble impliquer que (du moins dans ce cas - CentOS), la charge moyenne inclut chaque thread séparément dans le total.

A eu le même problème aujourd'hui. Après quelques recherches et diagnostics, je me suis rendu compte que mon petit VPS était à court de disque .

Dans le type shell / prompt (Linux / Unix)

df -h

pour voir le disque libre sur votre machine. Si vous manquez de disque, cela peut être le problème.

Un autre outil utile qui aidera dans cette situation est nmon.

Il comprend une variété de moyens pour afficher les mêmes données présentées par les autres outils, dans un petit paquet.

S'il s'agit d'un contenu qui ne peut pas être mis en cache, je vous recommande de placer plusieurs serveurs derrière un équilibreur de charge tel que haproxy en mode TCP pour répartir la charge.

Pour ajouter à cela, certains des outils spécifiques à Solaris qui n’ont pas été mentionnés et qui sont utiles au débogage de tels problèmes sont "intrstat", "mpstat" et "lockstat". Avoir rencontré un problème similaire auparavant sur un hôte exécutant des charges ETL lourdes, mpstat a révélé un grand nombre d'interruptions concernant de nombreuses entrées / sorties qui laissaient deviner le problème.

À l'époque, sur un T4-4 avec mpstat, nous avons vu vcpus verser plus de 30000 interruptions au cours d'un cycle de surveillance court, après quoi les performances ont commencé à se dégrader. Dans ce cas, la seule solution envisageable consistait à utiliser plus de ressources processeur. Toutefois, des travaux ont ensuite été effectués pour améliorer le code.

Brendan Gregg a beaucoup écrit sur la performance, en particulier sur les E / S au fil des ans, et mérite une recherche si vous souhaitez en savoir plus.