Normalement, les requêtes semblent sauvegarder, et Apache commence à consommer de plus en plus de mémoire et de CPU, jusqu'à ce qu'il finisse par manquer de RAM et tous les processus apache meurent, laissant tous les visiteurs sans site web.Comment puis-je arrêter le crash d'apache2 lorsque le site web est occupé?
Cela semble être un problème commun des gens à qui je parle mais je n'arrive pas à trouver une solution!
Toute aide très appréciée!
Un moyen plutôt simple serait de limiter le nombre d'utilisateurs autorisés à accéder à votre site. La configuration réelle dépend du MPM que vous utilisez. Mais généralement ce sera MaxClients (http://httpd.apache.org/docs/2.2/en/mod/mpm_common.html#maxclients) pour les mpms Unix apache typiques (préfork et travailleur).
En outre, si vous utilisez prefork, vous voudrez peut-être passer au travailleur-mpm, car il est plus rapide (mais tous les modules doivent être des versions thread-safe pour cela, par exemple PHP anciens ne sont pas)
Oui , C'est un problème commun. C'est aussi le point où la connaissance/connaissance du système Apache de la plupart des gens se termine :-)
C'est un long sujet. Premièrement, pouvez-vous reproduire le comportement ou le voir fréquemment? Ou cela arrive-t-il "parfois" et vous ne le remarquez que lorsqu'il est trop tard pour déboguer quoi que ce soit? Le fait est que le débogage de l'échec est également possible post-mortem en analysant les logs, mais ceux-ci doivent être préparés pour l'événement avant, mais comme vous ne savez pas quoi chercher, cela peut être plus de travail. Pour savoir où le goulet d'étranglement des ressources pourrait être, une bonne première étape pourrait être d'activer mod_status, de le rendre accessible depuis localhost ou un emplacement de confiance et de regarder l'état du serveur (/ server-status). Il peut être impossible de regarder l'état du serveur quand il est "trop tard" et Apache ne réagit plus, mais il est possible de rassembler des données intéressantes avant.
Depuis que vous avez étiqueté votre question "mysql", une autre question serait de savoir s'il y a une base de données backend qu'Apache doit attendre. Un petit réglage mysql pourrait résoudre tous vos problèmes, mais cela ne serait qu'une des possibilités de l'échec que vous voyez. Consigner l'état du serveur, un peu de sortie «top» et mysqls slow-query-log donnerait un aperçu de cela. En outre, vérifiez la configuration de la mémoire de mysql, si vous avez des doutes sur le fait que cela ne soit pas déjà pris en compte.
Enfin, il est important de vous assurer que Apache ne sera pas utiliser trop de mémoire, quand il fait la queue demande, ou la machine commencera à échanger et enfin tuer Apache (ou autre chose). Évaluer la quantité de mémoire dont chaque processus Apache a besoin. Ce n'est pas facilement visible dans l'état du processus, mais peut être calculé avec ce script: http://cmdline.net/misc/httpd2-memusage. Ensuite, voyez combien de mémoire votre système peut dépenser au maximum sur les processus Apache, et définissez MaxClients en conséquence - de sorte qu'Apache n'utilisera jamais plus que ce qui est disponible. (Vous multipliez le besoin en RAM d'un processus moyen par le nombre de processus, maths simples.) D'autres directives de dimensionnement devront probablement être également ajustées, de sorte qu'elles correspondent aux MaxClients. C'est quelque chose que de nombreuses configurations manquent - mais c'est une protection essentielle contre les petites "explosions".
Enfin, votre Apache est-il relativement occupé? Ensuite, je peux presque aveuglément recommander de réduire KeepaliveTimeout à 2 secondes.
Semble que la base de données pourrait causer le problème en "accrochant". Pour cela, KeepAlive et le type MPM ne feront aucune différence.
Vérifiez que vos tables utilisent le moteur InnoDB et non le moteur MyISAM. MyISAM va "OPTIMISER" à des moments aléatoires, ce qui est une opération de blocage de table, et pourrait prendre quelques minutes pour une grande table. Ce serait une situation "pathognomonique" qui ferait décrocher Apache (et même la fourchette à la mort, si elle n'est pas correctement limitée). -> "show table status"
L'absence de mémoire affectée à la base de données serait la prochaine chose à vérifier. /etc/my.cnf est généralement livré avec de très petites valeurs par défaut. Si les tables utilisent le moteur InnoDB, une valeur innodb_buffer_pool_size trop petite pourrait être le coupable. Vous avez probablement plus de mémoire à dépenser; l'état de la table vous donne des détails sur la taille réelle des données.
Je peux le reproduire en effaçant le cache sur le CMS drupal pendant une période occupée, ce qui augmente considérablement la charge de la base de données. J'ai réduit le KeepAlive de 5-2 secondes. Je ne sais pas si cela fera une grande différence. J'ai également essayé de passer de la version préforme d'Apache à la version MPM-worker en utilisant PHP via fastcgi. Cela ne semble pas avoir fait beaucoup de différence, même si je pense que les temps de réponse des pages sont un peu plus rapides. – cjm2671
Tout cela est très utile. Merci, Peter Poeml. Je comprends que cet article est un peu vieux, mais pourriez-vous commenter les avantages de KeepaliveTimeout = 2? Est-ce aussi simple que de tuer le processus de fonctionnement afin qu'ils ne s'accumulent pas? –