Comment empêcher Apache de tomber?

8

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?

Dave Child
la source
2
Courriel de 38 Go? Découvrez ce qui se passe là-bas. Et puis corrigez-le.
Alister Bulman
2
" Comment puis-je empêcher Apache de tomber " - Donnez-lui une jambe en bois et éloignez-le de la planche.
Shaz
Le fichier courrier est probablement dû à une sortie cron root ou à une erreur crontab. Si vous avez des tâches bavardes, elles remplissent ce fichier.
Kyle Smith
1
Il a 6 Go de RAM, mais est-ce un système d'exploitation 64 bits? Êtes-vous réellement en mesure d'utiliser plus de 4 Go que vous utilisez actuellement? S'il s'agit d'une boîte critique pour la mission, j'exécuterais certainement Linux-HA et la diviserais en deux boîtes juste à des fins de basculement. Je penserais que votre patron ne serait pas aussi coché si vous n'aviez pas d'impact sur le résultat net à chaque crash.
Ori

Réponses:

3

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.

Martijn Heemels
la source
J'ai jeté un œil à Varnish et cela semble être une bonne solution pour réduire la charge du processeur, au moins jusqu'à ce que je puisse passer à un hôte avec une meilleure configuration du processeur. Merci.
Dave Child
3

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.

Alister Bulman
la source
D'abord merci! La charge est encore assez élevée, donc je peux essayer certaines de ces choses tout de suite, ce qui est utile :). J'ai augmenté MaxRequestsPerChild à 4000 - la charge a immédiatement bondi et est restée très élevée. Je l'ai ramené à 1000 et la charge a quelque peu baissé, bien qu'elle soit encore trop élevée. APC est installé. SHM est 256. La substitution include_once est activée.
Dave Child
si APC est déjà installé, que rapporte le rapport apc.php? - Télécharger depuis svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup
Alister Bulman
Voici la sortie (je préfère ne pas lier directement le site / serveur): dl.dropbox.com/u/16366/apc.htm
Dave Child
Désolé, je ne savais pas que vous aviez modifié votre réponse. Oui, c'est un VPS dual-core (Xeon 2.4ghz). J'aurais pensé que ce serveur devrait être capable de gérer sa charge actuelle, c'est pourquoi je crains d'avoir manqué quelque chose dans la configuration ou de ne pas avoir repéré un goulot d'étranglement quelque part.
Dave Child
2

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.

abat-jour
la source
2

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.

symcbean
la source
Normalement, quelque chose comme 10-20 traite activement les demandes à tout moment. Lorsque la charge est extrêmement élevée, alors beaucoup plus. Magento est quelque chose d'un monstre à exécuter, alors même si je m'attendrais à ce que d'autres systèmes acceptent ce trafic et cette configuration, je peux croire que Magento pourrait être trop grand pour la boîte. Merci pour la recommandation du livre.
Dave Child
mod_pagespeed aide beaucoup Magento. Essayez-le.
laebshade
2

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)?

3molo
la source
Ils sont enregistrés dans un tmpfs.
Dave Child
1

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

Abhishek Dujari
la source