Question Réponse personnalisée de Linux MOO


J'utilise le serveur Web Apache et j'aimerais améliorer un peu la gestion de la situation de MOO.

Je suis au courant des partitions de MOO et j'ai déjà effectué quelques personnalisations à cet égard. Ainsi, lorsque quelque chose de grave se produit, Linux tue les processus appropriés. Mais ce n'est pas suffisant.

Le problème est que parfois, lorsque le MOO se produit, le serveur est surchargé, puis se bloque et doit être redémarré. Je voudrais gérer cela sans le redémarrage complet du serveur. Je dois donc en quelque sorte "accrocher" un script sur l'invocation de tueur OOM qui tuerait tous les processus apache (et ses CGI), libérant ainsi la mémoire et le relançant (Apache).

Je sais que cela fonctionnerait, car si le MOO se produit et que je suis assez rapide pour me connecter au serveur et tuer Apache manuellement, tout va bien alors.

FYI, je suis maintenant courir près d'une centaine de ces serveurs Web, c'est pourquoi je cherche une solution entièrement automatique.

Une solution possible serait bien sûr d'utiliser un chien de garde qui analyserait le syslog et détecterait les MOO de cette manière - j'ai déjà quelque chose comme ça, qui informe des meurtres de MOO par courrier électronique. Cette approche peut résoudre certaines situations, mais si le MOO est vraiment mauvais, le serveur est trop surchargé et mon script ne démarre même pas (il est exécuté par cron). Il peut être amélioré en utilisant inotify pour regarder le syslog ou en dirigeant le syslog directement (c'est-à-dire par fifo) vers le script.

Mais je me demande tout de même: n'y a-t-il pas moyen de "lier" le script directement au tueur de MOO? Je mettrais donc quelque chose comme ça dans un fichier / etc / ..:

oom_action="sh /path/to/my/script.sh kill"

Ou ce n'est tout simplement pas possible de le faire comme ça?

J'utilise Centos 6, Apache 2.2 et PHP comme FastCGI.


6
2018-04-28 07:52


origine




Réponses:


Pourquoi ne pas simplement surveiller les processus Apache et définir leur oom_adj valeur à 15 pour être sûr qu'ils seront les premiers à se terminer sur le MOO? Ici sont des instructions sur ce paramètre.

Selon votre configuration, vous pouvez soit modifier les scripts de démarrage d’apache, soit configurer une tâche simple pour le faire.

Vous pouvez aussi regarder périodiquement le résultat de la commande dmesg | grep -i oom. S'il y a des lignes, le tueur de MOO a tué quelqu'un depuis le dernier démarrage du serveur. Vous pouvez ensuite effacer le tampon avec dmesg --clear


3
2018-05-05 12:03



J'ai déjà configuré le tueur OOM de cette façon, donc il tue d'abord PHP et HTTP. Donc, dans une situation "normale", cela tue peu de processus et tout va bien. Mais dans les situations critiques, cela ne suffit pas et il est vraiment nécessaire de tuer tous les processus HTTP et PHP (puis de relancer Apache). - dave
@dave Ensuite, vous devez regarder périodiquement la sortie de la commande dmesg | grep -i oom. S'il y a des lignes, le tueur de MOO a tué quelqu'un depuis le dernier démarrage du serveur. Vous pouvez ensuite effacer le tampon avec dmesg --clear - Vladislav Rastrusny


Je sais qu'il existe des applications PHP épouvantables dans la nature, beaucoup d'entre elles, mais n'y en a-t-il pas quelque chose vous pourriez faire du côté Apache / FastCGI / PHP? Apache constamment OOMing n'est pas quelque chose que vous devriez rencontrer très souvent.

Essayez de réduire le nombre maximal de processus Apache et de gestionnaires FastCGI, et voyez si vos paramètres php.ini actuels sont trop élevés pour la mémoire maximale par script.

En outre, il est parfaitement possible d'utiliser ulimit avec Apache et limiter le nombre de mémoire qu'un processus peut utiliser. Cela peut vous aider avant que le serveur ne meurt presque en spirale.

OOM est un dernier recours, et tout ce qui peut y conduire doit être inspecté.


0
2018-05-05 13:34



C’est vrai et, bien sûr, j’ai de nombreux ajustements à faire à cet égard. Mais j'ai aussi beaucoup de serveurs avec beaucoup d'applications PHP différentes, etc. Je ne dis pas que ces situations se produisent tous les jours, mais bien sûr, elles se produisent de temps en temps. - dave


Comme je n’ai pas trouvé de meilleure solution, j’ai implémenté le chien de garde pour lire les messages syslog du noyau (via fifo):

/etc/rsyslog.d:

(...)
kern.err         |/path/to/fifo

et recherchez-les pour l'activité de tueur au MOO:

while read /path/to/fifo; do (..)

et lorsque le tueur-mortifère se reproduit massivement (j’ai vraiment besoin de ne vérifier que les situations d’urgence), je tue (puis je commence) Apache.


0
2018-05-05 14:20





Je pense qu'il est préférable de mettre votre processus dans un sous-ensemble de mémoire cgroup et d'utiliser le release_agent appeler un script externe quand la mémoire arrive

notify_on_release
    contains a Boolean value, 1 or 0, that either enables or disables the execution of the release agent. If the notify_on_release is enabled, the kernel executes the contents of the release_agent file when a cgroup no longer contains any tasks (that is, the cgroup's tasks file contained some PIDs and those PIDs were removed, leaving the file empty). A path to the empty cgroup is provided as an argument to the release agent. 

release_agent (present in the root cgroup only)
    contains a command to be executed when a “notify on release” is triggered. Once a cgroup is emptied of all processes, and the notify_on_release flag is enabled, the kernel runs the command in the release_agent file and supplies it with a relative path (relative to the root cgroup) to the emptied cgroup as an argument. The release agent can be used, for example, to automatically remove empty cgroups

En utilisant cgroup, vous pouvez contrôler la quantité de ressources que vous pouvez traiter et ne pas surcharger votre serveur.

Using cgroup you can control the server resources

0
2018-05-05 16:28



Eh bien, cgroups sonne bien. J'ai définitivement besoin de les regarder de près (car je n'ai presque aucune expérience avec eux). Je ne savais pas qu'ils sont capables de quelque chose comme ça (le release_agent). D'autre part, si je définissais des limites "strictes" sur la quantité de mémoire pouvant être utilisée par certains processus, je pourrais dans certains scénarios "gaspiller" de la mémoire, qui n'est pas utilisée par d'autres services (par exemple, MySQL). Pour que ce soit vraiment utile, il faudrait beaucoup de peaufinage et il serait beaucoup plus difficile de maintenir sur de nombreux serveurs, je crois. - dave