Le serveur ne fait pas face, la charge moyenne du processeur monte à 33.0

Le nombre de "charge moyenne" n'est pas réellement la charge - c'est le nombre de threads en état "d'exécution" ou "exécutable". Les threads mentionnés ci-dessus peut attendre quelque chose - des opérations de pagination ou d'E/S par exemple (ce qui serait mauvais du point de vue des performances - les E/S sont généralement des ressources partagées et si un certain nombre de threads les attendent, il y a de bonnes chances que d'autres encore rejoignent la file d'attente).

Dans une configuration avec un serveur MySQL en fonctionnement, j'ai vu des chiffres similaires dus à contention des verrous sur une table populaire lors d'opérations de mise à jour prolongées . Vous pouvez vérifier en envoyant la commande SHOW PROCESSLIST à votre serveur MySQL (PHPMyAdmin a même exposé cette fonction). La solution rapide pour ce problème était d'activer les mises à jour à faible priorité dans la configuration de MySQL.

Vous devez obtenir des mesures plus détaillées pour cerner le problème.

Je passe généralement en revue

• disque io
• utilisation de la mémoire vive
• utilisation des swaps
• utilisation du réseau
• connexions/sec en apache
• requêtes/sec dans la base de données
• problèmes de pare-feu
• pile réseau (par exemple, temps d'attente, connexions ouvertes)

De là, je remonte dans les journaux d'Apache, de MySQL et du système.

Enfin, abordez les questions spécifiques à l'application.

Quelques outils :

• Munin ou Cacti (ou autre outil permettant d'obtenir des statistiques détaillées)
• Sysstat et outils groupés (iostat, vmstat, etc.)
• Statut étendu dans Apache
• Consigner les requêtes lentes dans MySQL
• Rapport sur les caches pour tous les caches opcode, memcache, etc.
• http://www.webpagetest.org/ pour les contrôles frontaux
• Pour les problèmes liés aux applications, certains de mes clients ont utilisé avec succès New Relic.

Avec une bonne boîte à outils et une approche systématique, vous pouvez généralement commencer à démêler le problème.

Quelques tests utiles :

• Accéder à un contenu statique (img ou css)
• Accéder à une page phpinfo ou hello world
• Accéder à une page php avec une simple connexion à une base de données et la fermer
• Accéder à une page php avec une connexion DB, sélectionner, fermer
• Accéder à une page php avec une connexion DB écrire et fermer
• Accédez à votre application web

En chronométrant chacun de ces tests, vous pouvez commencer à comprendre où se situe la latence. J'ai vu des serveurs très chargés renvoyer du contenu statique très rapidement. Le temps jusqu'au premier octet était très bas. Cela suggère un problème au niveau de la couche applicative. Continuez à travailler sur la pile d'applications jusqu'à ce que vous puissiez trouver le ralentissement.

Bien que fastidieux, ce processus m'a bien servi et une fois que l'on s'y est habitué, on peut le passer très rapidement.

Cela se produit-il régulièrement ? Par exemple, chaque jour, vous savez quand cela va se produire ?

Les tâches Cron en cours d'exécution à ce moment-là ?

Quels sont les processus en cours d'exécution (top ou htop devrait le montrer) ?

Quel sous-système de disque utilisez-vous ? Type de RAID ? Type de contrôleur ? (sur différents canaux... ?)

La charge du serveur ne se limite pas à l'utilisation du processeur. Il peut s'agir d'une surcharge du réseau ou du système d'entraînement.

Vous vérifiez vos disques pour voir s'il y a un problème sur les lecteurs ? L'un d'entre eux peut être défaillant ?

Vous devez déterminer ce qui se passe exactement, si c'est la base de données qui s'engorge, si vous obtenez un nombre réel de visites élevées sur le site Web, à quoi ressemble votre trafic, s'il y a des messages dans les journaux, si le serveur exécute un travail par lots qui consomme beaucoup d'E/S de disque... ? Toutes ces choses peuvent provoquer un pic de "charge" du serveur. Vous devez alors déterminer où et ce qui ne va pas. Si cela se produit à peu près au même moment de la journée, vérifiez les programmes cron et tout ce qui peut faire le ménage sur le serveur, y compris les sauvegardes ou les vidages de disque.

S'il y a une corrélation avec autre chose... peut-être la mise à jour d'un type particulier de nouvelles... vérifiez votre utilisation de la bande passante. Vérifiez vos journaux pour voir si vous faites l'objet d'une sorte de scan ou de sonde de la part d'utilisateurs malveillants.

La mise à l'échelle, pour les impatients ou les paresseux :

• Mise en cache des résultats des bases de données (memcached) et des données statiques (varnish, nginx) ;
• Séparez le service de ressources du service d'applications (images, js, css, servez-les depuis un hôte différent) ;
• Séparer la base de données de l'application ;
• Équilibrez la charge de l'accès aux applications sur plusieurs serveurs ;

Bien sûr, vous devez faire cela avant de vérifier votre serveur comme l'a dit Bart et être sûr que le serveur fait tout ce qu'il peut. Je veux dire, s'il y a de la place pour améliorer votre conception actuelle, faites-le d'abord, mais même dans cette situation, la mise en cache aidera beaucoup.