Moyenne de charge é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 un administrateur système, il y a donc des choses que je ne comprends pas très bien. Une enquête de base montre que le CPU est inactif, beaucoup de mémoire disponible, pas de permutation, pas d'E/S, mais une charge moyenne élevée.
La pile logicielle 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 CPU (je pense).
Fonctionnement prstat -Z donne quelque chose comme ceci:
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 la moyenne de charge est élevée, ce qui est assez étrange pour moi. La mémoire ne semble pas être un problème.
Fonctionnement vmstat 15 donne quelque chose comme ceci:
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 CPU est principalement inactif, aucun processus n'attend dans la file d'attente pour être exécuté, peu de swaps se produisent.
Fonctionnement iostat 15 donne 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
Fonctionnement netstat -i 15 donne ce qui suit:
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?
Avec une enquête plus approfondie, il semble que le problème de performances est 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 du processeur (en attente principalement d'E/S), la moyenne de charge élevée (de nombreux appels en attente de traitement) et surtout les longs temps de réponse (par accumulation de petits temps de réponse).
Merci pour votre compréhension de ce problème!
Lorsque vous dites "moyenne de charge élevée", je suppose que vous voulez dire que prstat indique "moyenne de charge" au bas des chiffres de sortie de
Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11
Ces chiffres, similaires à ceux fournis par top, représentent probablement la taille moyenne de la file d'attente du processus en cours d'exécution. Ce n'est pas le pourcentage de temps processeur utilisé, mais le nombre de `` choses '' qui harcèlent le processeur pendant le temps d'exécution. Certes, ceux-ci semblent assez élevés, mais tout dépend de l'application que vous exécutez; les processus ne font peut-être pas grand-chose une fois qu'ils ont leur place. Voir ici pour une belle explication concernant le haut.
Je ne suis pas familier avec WebLogic, mais j'ai remarqué qu'en général, avec Apache Tomcat, de nombreux threads Java peuvent être générés simultanément pour ce qui apparaît comme peu de requêtes. Ce pourrait être cela qui provoque ces Assurez-vous que vous utilisez le regroupement de connexions le cas échéant pour vous connecter au backend et envisagez d'augmenter le nombre de threads inactifs disponibles pour votre application pour gérer les connexions (vous ne savez pas comment procéder sur WebLogic; Tomcat a un par pool de threads de connecteur ou pool de threads exécuteur général). Si vous ne le faites pas, de nouveaux threads peuvent être générés pour traiter les demandes.
En ce qui concerne les performances, vous devez déterminer la partie de votre application qui souffre. Est-ce le traitement qui se passe du côté 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 comment il communique avec la base de données qui retarde les choses. Ensuite, ce sera la configuration de l'application Web. Passé ce point, vous travaillerez à extraire les dernières millisecondes de votre application ou à fournir une concurrence plus élevée avec le même matériel. Pour ce réglage des performances plus fin, vous avez besoin de mesures.
Pour Java je suggère d'installer Java Melody . Il peut fournir de nombreuses informations sur ce que fait votre programme et aider à préciser où il passe du temps. I Je ne l'ai utilisé qu'avec Tomcat mais devrait fonctionner correctement avec tout Java EE container/servlet thingy.
Il existe un certain nombre de façons de régler Java, alors jetez un œil à leurs directives de performances (je suis sûr que vous en avez probablement) et assurez-vous de définir la bonne taille de tas, etc. adaptée à votre programme. Java Melody peut vous aider à suivre la taille du tas de Java que vous consommez ainsi que la force de travail 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'affiner davantage en fonction de vos besoins.
En remarque, la moyenne de charge comprend également les choses en attente d'activité sur le disque (c'est-à-dire le harcèlement du disque) ainsi que celles en attente de processeur, c'est une somme des deux ... donc vous pourriez avoir des problèmes dans l'un ou l'autre.
Voir http://en.wikipedia.org/wiki/Load_ (informatique) "Linux inclut également [dans sa moyenne de charge] des processus dans des états de veille sans interruption (généralement en attente d'activité du disque)"
En remarque, le problème particulier que j'ai rencontré est que j'avais une moyenne de charge élevée, mais aussi beaucoup de processeurs inactifs et une faible utilisation du disque.
Il semble que, du moins dans mon cas, les threads/processus en attente d'E/S apparaissent parfois dans la moyenne de charge, mais ne provoquent pas une augmentation dans la colonne "attendre". Mais ils sont toujours liés aux E/S.
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 celle-ci:
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 pouvez donc voir qu'il a beaucoup de processeurs inactifs, 0,0% wa, mais une moyenne de charge très élevée.
iostat montre également le disque comme essentiellement 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
Comme note supplémentaire, cela semble également impliquer que (au moins dans ce cas - exécution de CentOS) la moyenne de charge inclut chaque thread séparément dans le total.
Eu le même problème aujourd'hui. Après quelques recherches et diagnostics, j'ai réalisé que mon petit VPS était à court de disque.
Dans le type Shell/Prompt (Linux/Unix)
df -h
pour voir le sans disque sur votre machine. Si vous manquez de disque, cela peut être le problème/problème.
Un autre outil utile qui vous aidera dans cette situation est nmon.
Il comprend une variété de façons de visualiser les mêmes données présentées par les autres outils, dans un petit package.
S'il s'agit d'un contenu qui ne peut pas être mis en cache, je recommanderais 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 outils spécifiques à Solaris qui n'ont pas été mentionnés et qui sont utiles pour déboguer de tels problèmes sont "intrstat", "mpstat" et "lockstat". Ayant rencontré un problème similaire auparavant sur un hôte exécutant de lourdes charges ETL, mpstat a révélé une grande quantité d'interruptions traitant de nombreuses E/S, ce qui a fait allusion au problème.
À l'époque, sur un T4-4 avec mpstat, nous avons vu des vcpus passer plus de 30000 interruptions sur un court cycle de surveillance, après quoi les performances ont commencé à souffrir. Dans ce cas, la seule solution de contournement consistait à y injecter davantage de CPU, mais des travaux ont ensuite été effectués pour améliorer le code.
Brendan Gregg a beaucoup écrit sur les performances, en particulier sur les E/S au fil des ans et mérite une recherche si vous souhaitez en savoir plus.