pic soudain dans l'utilisation du processeur

Il y a beaucoup de problèmes avec Elastic Search et en cherchant rapidement sur Google, vous pouvez en trouver quelques-uns. Mais le problème majeur de l'utilisation élevée du processeur peut être causé par le manque de contrôle de l'utilisation du cache. Veuillez trouver ci-dessous des références :

https://github.com/elasticsearch/elasticsearch/issues/4288 http://elasticsearch-users.115913.n3.nabble.com/Very-high-sys-cpu-usage-with-HTTP-KeepAlive-td4049998.html http://blog.sematext.com/2012/05/17/elasticsearch-cache-usage/

Les processus qui utilisent beaucoup de CPU devraient apparaître dans atop comme le suggère Ian Macintosh, mais comme il est basé sur l'échantillonnage de la table des processus sur un cycle régulier, cette visibilité peut dépendre de la durée d'exécution de ces processus.

Les utilitaires de comptabilité GNU peuvent également être très utiles pour ce genre de choses. (package = 'acct' sur les systèmes basés sur debian, ou 'psacct' sur ceux basés sur redhat). J'exécute régulièrement atop et le paquetage de comptabilité est activé ( accton on ) pour la plupart des serveurs.

Après avoir activé la collecte de données comptables, des statistiques sont conservées sur l'utilisation du CPU de chaque processus en cours d'exécution, ainsi que sur le moment où il a commencé et terminé son exécution. Cela peut être très utile lorsqu'un tas de processus de courte durée consomment votre CPU, ce qui est difficile à voir avec atop, strace, etc. -f o -ff drapeau). C'est moins utile lorsque vous avez des processus avec une durée de vie beaucoup plus longue que le pic du CPU, mais dans ces cas, atop devrait vous donner ce que vous voulez. lastcomm est probablement l'outil que vous souhaitez pour accéder aux statistiques collectées.

Bien que très utile, strace ne vous renseigne que sur les appels système. Si vous avez quelque chose qui utilise intensivement le processeur, mais qui n'appelle pas le système, cela n'apparaîtra pas. Parfois, ltrace peut être utile pour cela, mais encore une fois, seulement si l'activité pertinente se produit dans un appel de bibliothèque, et ce n'est pas toujours le cas.

Des outils comme strace et ltrace, et peut-être même un débogueur comme gdb, n'entrent en jeu qu'une fois que vous avez identifié le processus qui consomme le CPU, et il ne semble pas que vous l'ayez encore fait. A ce stade, atop et lastcomm sont probablement la solution.

Quels autres tests pourriez-vous effectuer ?

(Il manque des informations comme le pourcentage du processeur du système lorsqu'il est bloqué par rapport au pourcentage du processeur de l'utilisateur) mais vérifiez quel pourcentage du processeur est une IRQ, juste au cas où cela mène quelque part.

En supposant que le pourcentage de CPU du système est assez élevé et qu'il ne s'agit pas d'IRQ, vous pouvez vérifier la mémoire. Un outil pratique pour une vue d'ensemble est atop, il devrait vous dire si quelque chose comme des balayages de pages ou des vols de pages est à l'origine de ce problème parce que vous êtes sous une forte pression mémoire.

Je vais supposer que vous avez exclu l'échange comme étant un problème.

Parce qu'atop vous donne un aperçu assez complet de l'état de la machine, c'est très pratique pour avoir une idée de l'état général. Il serait également utile de comparer atop sur un système fonctionnant correctement par rapport à un système qui se comporte mal.

Si le seulement L'anomalie est le % de CPU de l'utilisateur et le système lui-même fonctionne correctement, sinon vous avez probablement affaire à un bogue logiciel et vous devrez demander de l'aide aux auteurs - ou changer la façon dont vous l'utilisez pour éviter de déclencher le bogue que vous avez trouvé. Vérifiez simplement que vous n'avez pas affaire à votre propre bogue - c'est-à-dire que vous l'appelez mal ou dans une boucle ou quelque chose de ce genre. J'ai vu cela à plusieurs reprises.

En résumé, creusez dans la mémoire, irq, swap etc. et voyez si vous pouvez les exclure - je suggère de le faire pour une comparaison rapide entre le comportement normal et le comportement aberrant et pour mettre en évidence les éléments critiques.