Comment puis-je empêcher des tonnes de processus Apache d'apparaître lorsque je démarre Apache et continue de tuer ma machine?
J'ai une application très trafiquée sur une machine Debian et Apache a commencé à agir bizarrement.
Chaque fois que je démarre Apache, des tonnes de processus Apache sont générés, l'application ne se charge pas du tout, et très rapidement l'ensemble de la machine se fige et doit être mis sous tension pour redémarrer.
Voici ce que j'obtiens pour top immédiatement après le démarrage d'Apache:
haut - 20:14:44 jusqu'à 1:16, 2 utilisateurs, charge moyenne: 0,48, 0,10, 0,03 Tâches: 330 au total, 5 en cours d'exécution, 325 en sommeil, 0 à l'arrêt, 0 zombie CPU: 12,0% us, 21,4% sy, 0,0% ni, 65,7% id, 0,2% wa, 0,1% hi, 0,7% si, 0,0% st Mem: 8179920k total, 404984k utilisé, 7774936k gratuit, 60716k tampons Échange: 2097136k total, 0k utilisé, 2097136k gratuit, 43424k mis en cache 10251 www-data 15 0 467m 8100 4016 S 6 0,1 0: 00,04 Apache2 10262 www-data 15 0 467m 8092 4012 S 6 0,1 0: 00,05 Apache2 10360 www-data 15 0 468m 8296 4016 S 6 0,1 0: 00,05 Apache2 10428 www-data 15 0 468m 8272 3992 S 6 0,1 0: 00.05 Apache2 10241 www-data 15 0 467m 8256 4012 S 4 0,1 0: 00.03 Apache2 10259 www-data 15 0 467m 8092 4012 S 4 0,1 0: 00,04 Apache2 10274 www-data 15 0 467m 8056 4012 S 4 0,1 0: 00,03 Apache2 10291 w ww-data 15 0 468m 8292 4012 S 4 0,1 0: 00.03 Apache2 10293 www-data 15 0 468m 8292 4012 S 4 0,1 0: 00.03 Apache2 10308 www-data 15 0 468m 8296 4016 S 4 0.1 0: 00.02 Apache2 10317 www-data 15 0 468m 8292 4012 S 4 0.1 0: 00.02 Apache2 10320 www-data 15 0 468m 8292 4012 S 4 0.1 0: 00.04 Apache2 10325 www-data 15 0 468m 8292 4012 S 4 0,1 0: 00.04 Apache2
Et ainsi de suite .. avec plus de processus Apache2.
Moins d'une minute plus tard, vous pouvez voir ci-dessous que la charge est passée de 0,48 à 2,17. Si je n'arrête pas Apache à ce stade, la charge continue d'augmenter pendant quelques minutes ou moins jusqu'à ce que la machine meure.
haut - 20:15:34 jusqu'à 1:17, 2 utilisateurs, charge moyenne: 2,17, 0,62, 0,21 Tâches: 1850 au total, 5 en cours d'exécution, 1845 en sommeil, 0 arrêté, 0 zombie Cpu (s): 0,3% us, 2,1% sy, 0,0% ni, 96,4% id, 0,0% wa, 0,1% hi, 1,0% si, 0,0% st Mem: 8179920k total, 1938524k utilisé, 6241396k libre, tampons 60860k Échange: 2097136k total, 0k utilisé, 2097136k gratuit, 44196k mis en cache
Nous avons un pare-feu où nous mettons en liste blanche les adresses que nous savons autorisées à accéder à notre site.
Toute idée de ce que pourrait être le problème est la bienvenue.
Merci!
Vous avez probablement fait l'erreur de configurer Apache pour utiliser bien plus que tout votre ram. C'est une erreur facile à faire.
Je suppose que vous utilisez un Prefork Apache et un serveur d'applications en cours (tel que PHP ou mod_Perl). Dans ce modèle, vous vous retrouverez avec un maximum de (MaxClients * max utilisation de la mémoire de votre application par processus) mémoire utilisée. Si vous n'en avez pas beaucoup, il est temps de diminuer l'une, l'autre ou les deux.
Dans le cas général, cela signifie diminuer MaxClients au point où votre serveur a suffisamment de RAM pour faire face.
Les valeurs par défaut généralement utilisées pour MaxClients (150 est typique) ne conviennent pas pour exécuter un serveur d'applications lourd en cours sur une machine modeste si vous utilisez le modèle Prefork (la plupart des serveurs d'applications ne prennent pas en charge ou découragent l'utilisation de modèles filetés).
Cependant, la diminution de MaxClients finira par rendre l'application indisponible, en particulier si vous avez des keepalives activées et le délai d'attente de keepalive trop long. Les processus qui ne font que maintenir une connexion en vie (état K dans l'état du serveur) utilisent encore beaucoup de RAM, et cela peut être un problème - essayez de minimiser le délai d'expiration de Keepalive, ou désactivez-le complètement.
Vous devez garder un œil sur l'état du serveur (tel que fourni par mod_status).
Bien sûr, vous ne devez effectuer AUCUNE de ces modifications si vous en comprenez les conséquences. Réfléchissez bien, changez la configuration une fois. Si vous avez la possibilité de tester les modifications avec une charge simulée sur une machine de production non similaire, faites-le.
utiliser ps -aux | grep Apache pour connaître le nombre de processus sur lesquels Apache est exécuté. Recherchez la colonne "RSS" qui donne une estimation de la mémoire utilisée par chaque processus. Vous pouvez également utiliser "top", où vous déplacez + f, puis sélectionnez la colonne% MEM pour trier les processus par utilisation de la mémoire.
Le nombre de processus est déterminé par la directive "MaxClients" dans votre fichier Apache.conf. La façon dont vous arrivez à cette figure est celle décrite par cette page ;
- SSH sur votre serveur en tant que root.
- Courez en haut.
- Appuyez sur Maj + m.
- Notez la mémoire RES la plus élevée utilisée par httpd.
- Appuyez sur Q pour quitter le haut.
- Exécuter: arrêt du service httpd (dans debian,
Sudo service Apache2 stop) - Une fois httpd arrêté, exécutez: free -m
- Notez la mémoire répertoriée sous "utilisé".
- Trouvez la mémoire garantie pour votre plan VPS. Le support peut vous dire combien vous avez garanti si vous ne le trouvez pas.
- Soustrayez la mémoire UTILISÉE de la mémoire que votre plan est GARANTI. Cela vous donnera votre PISCINE DE MÉMOIRE GRATUITE.
- Multipliez la valeur de votre PISCINE DE MÉMOIRE GRATUITE par 0,8 pour trouver votre PISCINE Apache DISPONIBLE moyenne (cela vous permettra une réserve de mémoire de 20% pour les périodes de rafale).
- Divisez votre POOL Apache DISPONIBLE par la mémoire RES la plus élevée utilisée par httpd. Cela vous donnera la valeur MaxClients qui doit être définie pour votre système. (Arrondissez-le à l'entier le plus proche inférieur à cette valeur s'il a une composante de fraction.)
La bonne valeur pour "MaxClients" garantira la bonne allocation de mémoire pour votre serveur Apache. Voilà comment je l'ai résolu.
Dans Debian, le fichier de conf Apache est à /etc/Apache2/Apache2.conf
Avez-vous récemment modifié votre fichier de configuration? Si oui, j'espère que vous gardez l'ancienne version pour diffing?
Sinon, recherchez les directives "StartServers", "MaxSpareServers" et "MinSpareServers". En règle générale, vous souhaitez laisser ces paramètres par défaut, mais il est possible qu'ils aient été intentionnellement définis comme élevés (mauvaise idée) ou accidentellement définis de cette façon en raison d'une mauvaise modification de configuration.
Si cela ne vous aide pas, il est temps de regarder en dehors d'Apache, pour un processus qui ouvre des connexions à un rythme rapide (il pourrait y avoir un processus de test qui se déroule de manière folle).
La première étape est le journal d'accès. La deuxième étape consiste à exécuter netstat, pour voir d'où les connexions peuvent provenir. Et s'il fonctionne sur le même système, vous pouvez regarder dans/proc/*/fd pour trouver les deux extrémités de la connexion.
Cette question est ancienne, mais je me sens obligé d'ajouter une réponse ici parce que toutes les réponses existantes donnent sur une information clé de l'OP: après que la charge a commencé à augmenter pendant quelques minutes, top rapports qu'il y a encore suffisamment de ressources CPU et mémoire disponibles. Il reste généralement un coupable, à savoir les E/S.
Vérifiez s'il existe une partition complète avec df -h. Si ce n'est pas le cas, vérifiez si votre application débite le disque à l'aide de vmstat 1 10 ou iostat 1 10 (ceux-ci sont fournis par le paquet 'sysstat' sur Debian/Ubuntu). Si vous ne voyez toujours pas de problème, vous avez peut-être des erreurs d'E/S au niveau du périphérique ou des problèmes de réseau pour le stockage monté sur le réseau. Vérifiez les fichiers journaux du système et du démon.
Comme cela a été dit (en supposant Prefork Apache) - MaxClients = max processus à la fois.
Si vous constatez que vous obtenez un trafic réel (et non un StartServers/Min/MaxSpareServers mal configuré), vous pouvez faire d'autres choses:
- Configurez un processus Apache léger et séparé (ou lighttpd) pour votre contenu statique. De cette façon, toutes les petites choses statiques ne "polluent" pas votre processus d'application lourd. Cela peut être sur le même serveur ou sur un autre. Peu importe.
- Mettez un proxy inverse comme Squid devant votre processus Apache. Le proxy inverse aspire rapidement le contenu d'Apache et le stocke en mémoire, puis le renvoie au client. De cette façon, les utilisateurs d'AOL sur des modems de 14,4 Ko ne monopolisent pas l'un de vos précieux emplacements Apache. En prime, une telle configuration peut être configurée pour mettre en cache une partie de votre contenu afin de réduire la charge sur vos processus Apache.
Votre sortie `` supérieure '' montre que vous avez beaucoup de mémoire libre, donc je ne pense pas que MaxClients soit un problème (sauf s'il y a un problème avec Apache allouant plus de 2 Go de mémoire?) Votre journal d'erreurs devrait afficher des erreurs s'il est avoir des problèmes pour créer plus d'enfants.
Très probablement, vos processus Apache utilisent vraiment beaucoup de ressources. Si vous exécutez des applications PHP, essayez d'installer eAccelerator qui fait un bon travail d'optimisation et de mise en cache PHP code. D'autres choses peuvent inclure de lourdes requêtes MySQL, une lente Résolveur DNS, etc. Au-delà de cela, il permet de mieux comprendre quels programmes sont touchés et ce qu'ils font.