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

Lorsque vous dites "Moyenne de charge élevée", je suppose que vous voulez dire que prstat affiche la "moyenne de charge" en bas des chiffres de sortie de l'ordinateur.

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

Ces chiffres, qui ressemblent à ceux fournis par Top, représentent probablement la taille moyenne des files d'attente des processus en cours. Il ne s'agit pas du pourcentage du temps processeur utilisé, mais du nombre de "choses" qui harcèlent le CPU pour obtenir du temps d'exécution. Certes, ces chiffres semblent assez élevés, mais tout dépend de l'application que vous exécutez ; les processus peuvent ne pas faire grand-chose une fois qu'ils ont obtenu leur créneau. Voir aquí pour une bonne explication concernant le sommet.

Je ne connais pas bien 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 semble être un petit nombre de requêtes. C'est peut-être cela qui est à l'origine de ces chiffres de charge moyenne élevés. Assurez-vous que vous utilisez le pooling de connexion lorsque cela est approprié pour vous connecter au backend et envisagez d'augmenter le nombre de threads inactifs qui sont disponibles pour votre application afin de gérer les connexions (je ne sais pas comment vous faites cela sur WebLogic ; Tomcat a un pool de threads par connecteur ou un pool de threads d'exécuteur général). Si vous ne le faites pas, de nouveaux threads peuvent être créés pour traiter les demandes.

En ce qui concerne les performances, vous devez déterminer ce que Une partie de votre application en souffre. Est-ce le traitement qui se déroule du côté de WebLogic/Java, l'accès à la base de données, les recherches DNS (si elles sont effectuées pour une raison quelconque...), les problèmes de réseau ou quelque chose au niveau du système d'exploitation ?

Dans 99% des cas, c'est 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. Passé ce stade, vous vous efforcerez d'extraire les dernières millisecondes de votre application ou de fournir une plus grande simultanéité avec le même matériel. Pour ce réglage plus fin des performances, vous avez besoin de métriques.

Pour Java, je suggère d'installer Mélodie de Java . Il peut fournir beaucoup d'informations sur ce que fait votre programme et aider à déterminer où il passe son temps. Je ne l'ai utilisé qu'avec Tomcat mais il devrait fonctionner avec n'importe quel conteneur/servlet Java EE.

Il existe de nombreuses façons de régler Java, alors jetez un coup d'œil à leurs directives de performance (je suis sûr que vous l'avez déjà fait) et assurez-vous que vous définissez la taille de tas correcte, etc. adaptée à votre programme. Java Melody peut vous aider à déterminer la taille du tas de Java que vous consommez, ainsi que l'intensité du travail du ramasseur d'ordures et la fréquence à laquelle il interrompt votre programme pour vider les objets.

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

En outre, la moyenne de charge inclut également les éléments qui attendent une activité sur le disque (c'est-à-dire qui harcèlent le disque) ainsi que ceux qui attendent le processeur, c'est la somme des deux... vous pouvez donc 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] les processus en état de veille ininterrompue (généralement en attente d'une activité sur le disque)".

En passant, le problème particulier que j'ai rencontré était que j'avais une charge moyenne élevée, mais aussi beaucoup de processeur inactif 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 le font pas. pas provoquent une augmentation de la colonne "await". Mais ils sont toujours liés aux entrées/sorties.

Vous pouvez constater que c'est le cas avec le code suivant, si vous l'exécutez dans jruby (fait juste 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 cpu inactif, 0.0%wa, mais une moyenne de charge très élevée.

iostat montre également 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

Par ailleurs, cela semble également impliquer que (au moins dans ce cas - sous CentOS) la moyenne de charge inclut chaque thread séparément dans le total.

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

Dans Shell/prompt (Linux/Unix)tapez

df -h

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

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

Il permet de visualiser de diverses manières les mêmes données que celles présentées par les autres outils, dans un seul et même paquet.

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.