Comment empêcher Apache de tomber?

J'ai une paire de serveurs hébergeant un seul site de commerce électronique Magento avec un trafic modéré (60 000 pages vues par jour rapportées par Google Analytics, je pense que 80 000 signalées sur le serveur lui-même). Le serveur de base de données fonctionne correctement et rapidement, à part un hoquet occasionnel rare, mais le serveur apache est tombé de temps en temps.

J'ai configuré magento pour utiliser la mise en cache PHP recommandée (APC), ainsi que pour conserver ses propres fichiers de cache dans un tmpfs de 1,5 gig (ce tmpfs est régulièrement assez plein, et j'ai un script en cours d'exécution pour effacer les fichiers de cache lorsque le tmpfs est à plus de 80%). Je sers la plupart des images d'Amazon Cloudfront. J'ai récemment configuré nginx comme proxy inverse pour apache (nginx sert également les fichiers statiques). J'ai configuré apache au mieux de mes capacités - keepalives et hostnamelookups sont désactivés et la préfork est configurée comme suit:

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

Je n'ai pas désactivé les fichiers .htaccess et la journalisation des accès est activée. Je sais que je peux désactiver certains modules. Je ne sais pas quel effet aurait ces trois changements, le cas échéant.

Le serveur apache est un VPS avec 6 gig de RAM. Au moment de l'écriture, le serveur signale load average: 17.77, 18.27, 49.76, mais il y a environ 2 gig de RAM libre. Quand ça va vraiment mal, la charge passe à 120+ et y reste - le redémarrage d'Apache fait remonter le site et la charge vers le bas.

vmstatest (alors que le serveur signale la charge ci-dessus), je pense, montrant une valeur d'inactivité du processeur oscillant entre 0 et 70 environ. iostataffiche une valeur comprise entre 0 et 0,2%.

Je suis un peu coincé. Le peu que je sais me dit que le problème est que le CPU est surchargé en raison de la combinaison du code en cours d'exécution et du nombre d'utilisateurs. Mais je n'ai pas assez d'expérience pour être certain que c'est le problème. Si tel est le problème, je pense que les solutions consistent à améliorer le code ou à diviser le site hébergeant sur deux VPS avec un équilibreur de charge.

Donc, je suppose que mes questions sont:

1. Que puis-je faire d'autre pour trouver des problèmes ou des goulots d'étranglement sur le serveur?
2. Y a-t-il des changements évidents que je peux apporter à la configuration du serveur pour améliorer cela?
3. Est-ce une bonne idée de configurer un système automatisé pour redémarrer apache lorsque la charge dépasse un certain niveau?
4. D'après ce qui précède, est-il probable que le site soit devenu trop grand pour le serveur?

Éditer:

J'ai trouvé quelque chose de bizarre - / var / spool / mail / root était grand ... 38 gig. Cela semble ... malsain. Est-ce que cela pourrait être le problème?

Magento et Zend Framework sont assez gourmands en CPU, comme vous l'avez remarqué. La meilleure façon d'éviter la charge du processeur est simplement de ne rendre le contenu qu'une seule fois, jusqu'à ce qu'il change. La plupart des parties de votre catalogue ne changent pas souvent, et souvent, seul le bloc du panier sur votre page ou le bloc des «articles les plus populaires» sont les seules parties dynamiques.

Je suggérerais de mettre un cache Varnish devant Apache. Cela vous donne une mise en cache de pages haute performance qui peut sérieusement décharger votre pile LAMP. Nous avons récemment survécu au lancement très public d'un site Web grâce à Varnish et j'ai été sérieusement impressionné par la vitesse et la faible charge du processeur. Le vernis est gratuit et suffisamment flexible pour mettre en cache des pages entières, ou ne mettre en cache que les parties relativement statiques et inclure le panier de manière dynamique.

Cependant, Varnish ne mettra pas beaucoup en cache sur une installation Magento par défaut, car il y a beaucoup de contenu dynamique par utilisateur, de cookies, etc. Un module Magento tel que « PageCache powered by Varnish » modifie Magento pour qu'il fonctionne bien avec Varnish. Il fournit également un fichier de configuration Varnish qui correspond à la configuration de Magento. Ces deux ensembles permettent une configuration très efficace. C'est un module commercial, mais beaucoup plus abordable qu'un serveur plus puissant.

Les pièces que vous déchargez vers un CDN ou un Nginx ne sont pas votre vrai problème, bien que cela aide. Même Apache peut gérer un certain nombre de requêtes statiques. Vous devez mettre en cache les éléments qui nécessitent des efforts pour générer encore et encore, c'est-à-dire vos parties dynamiques.

Normalement, je configure MaxRequestsPerChild pour qu'il soit par milliers - généralement près de 10 000.

Vous dites que vous avez "la mise en cache PHP recommandée" - mais avez-vous installé APC? Enfin, combien d'utilisateurs voyez-vous frapper le site Web en même temps. Si vous avez des statistiques étendues Apache, vous pourrez voir combien de processus Apache sont réellement en cours d'exécution à la fois.

800 hits de fichier APC par seconde, et 200 autres cache utilisateur, c'est beaucoup. Si c'est un dual ou quad-core, je m'attendrais à ce qu'il continue bien. Si la base de données se maintient véritablement, alors obtenir une machine plus grande - et plus de CPU, peut être la meilleure chose pour elle, du moins en ce moment.

Votre charge moyenne est entièrement trop élevée pour un VPS double cœur. 8 devrait être le max.

J'ai eu beaucoup de succès avec l'utilisation de mod_pagespeed et de l'événement MPM pour Magento. Je recommanderais de passer à l'utilisation de l'événement MPM et d'installer mod_pagespeed.

Plus d'informations sur Event MPM: documentation Apache Event MPM

Et mod_pagespeed: Code Google: mod_pagespeed

Si vous continuez à rencontrer des problèmes de chargement même après avoir apporté les modifications ci-dessus, vous souhaiterez peut-être envisager de passer à un autre plan VPS, meilleur.

Comme l'indique Alister, une valeur MaxRequestsPerChild de 400 est absurdement faible.

La charge moyenne est très élevée, mais 60 000 pages vues par jour ne représentent pas beaucoup de trafic.

Combien de processus avez-vous normalement à traiter les demandes?

Je ne connais pas Magento, mais il semble qu'il y ait un problème avec cette configuration. Je m'attendrais à ce que vous puissiez obtenir un débit considérablement plus élevé à un niveau de charge inférieur.

Allez chercher un exemplaire du livre de Steve Souders et lisez-le. Activez la compression pour tout le contenu HTML sortant (statique et dynamique). Et assurez-vous d'avoir une bonne configuration de mise en cache. Commencez à enregistrer% D dans votre fichier access_log et créez des outils pour analyser les données / isoler la lenteur. Similaire pour MySQL.

Essayez mysqltuner.pl et voyez s'il signale des problèmes.

J'exécute une configuration similaire, mais avec nginx / php-fpm / apc (opcode et fast_backend / memcached (slow_backend). Je trouve que php est le plus gros problème de ressources, probablement parce que magento est soit incroyablement gros ou simplement mal codé. regardez ce qui mange exactement les ressources, pourrait-il être php comme dans mon cas?

En plus de ce que Martijn Heemels écrit, il existe un module de vernis open source que vous pouvez essayer. Consultez http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ et https://github.com/madalinoprea/magneto-varnish .
Je ne l'ai testé que dans un environnement de test, et jusqu'ici tout va bien.

Enregistrez-vous les sessions dans la base de données ou sur le disque (et si oui, sur tmpfs)?

Lorsque vous utilisez VPS, vous partagez le processeur. Je vous recommande de parler à votre hôte pour déplacer votre VPS vers un matériel moins occupé ou de vous consacrer.

En raison du processeur partagé, vos applications ne peuvent pas s'exécuter à temps et continuer à être mises en file d'attente pour générer des demandes plus élevées à traiter et également les frais généraux qui l'accompagnent. Finalement, il y a une condition où Apache ou php ou mysql aurait atteint ses propres limites et cela cause des problèmes.

La ligne de fond est. VPS est essentiellement un processeur partagé. Votre hôte peut mettre trop de comptes VPS sur le même processeur.

Si vous voulez utiliser pleinement le CPU alloué, demandez un meilleur serveur avec moins de VPS si possible (déplacez l'hôte bien que cela soit gênant) ou allez dédié.

Vous pouvez également choisir complètement Amazon et ne vous inquiétez pas si nginx utilise son équilibreur de charge, qui est en quelques clics à configurer pour tous vos serveurs sous leur cloud.

le dossier /var/mail.../root est hue signifie qu'il recueille beaucoup d'e-mails qui proviennent généralement de vos applications. Par exemple, un script PHP buggy essaie d'envoyer des e-mails ou tous les travaux cron sont configurés pour vous envoyer par e-mail l'état des exécutions cron et la sortie. Vous pouvez regarder à l'intérieur du courrier et voir ce que contient le fichier. Je devine ses messages d'erreur afin que vous puissiez trouver d'où cela vient.

J'en ajouterai plus si vous avez besoin de plus d'informations