2 votes

Centos/MySQL serveur haute charge

Actuellement, je gère un site web qui reçoit environ 15 000 à 20 000 visites par jour. Nous avons actuellement un forum très actif, hébergé avec le logiciel Vbulletin. Nous avons 4,5 millions de messages, 80 000 sujets, avec environ 11 000 membres dont un peu moins d'un tiers est actif tout le temps. Actuellement, j'utilise un Intel Xeon Quad Core (2,13Ghz) avec 4 Go de RAM, Centos 5.5 et j'utilise DirectAdmin sur la machine pour le gérer. J'utilise également la version stable actuelle d'Apache, MySQL et PHP. C'est le seul site hébergé sur cette machine. Parfois, à des moments aléatoires de la journée, lorsque cela devient chargé, la charge du serveur peut atteindre jusqu'à 20, mais cela peut aussi arriver lorsque nous n'avons que 200 utilisateurs actifs. Je ne comprends pas ce qui cause ces problèmes. Parfois, les pages peuvent se générer en .2 secondes, d'autres fois cela prend 5 à 8 secondes. J'ai personnalisé le fichier my.cnf et cela n'a rien résolu, je ne savais pas vers qui me tourner, donc si quelqu'un a des suggestions, merci de me le faire savoir.

2voto

NegativeFriction Points 293

Avez-vous mis en place une journalisation :
Malheureusement, beaucoup de gens oublient souvent de consulter les journaux pour avoir un aperçu de leur problème.

Je commencerais par quelques outils de surveillance, de journalisation et de diagnostic de base.

  1. top
  2. mtop http://mtop.sourceforge.net
  3. innotop http://innotop.sourceforge.net
  4. Processlist MySQL / mysqladmin proc
  5. MySQLTuner http://mysqltuner.pl
  6. MySQLidxchk: http://hackmysql.com/scripts/mysqlidxchk-1.1 (idéal pour l’analyse des journaux)
  7. MySQLSLA - rapport d'état pour MySQL : http://hackmysql.com/scripts/mysqlsla
  8. MySQLReport - http:// hackmysql.com/scripts/mysqlreport (excellente utilité qui interprète les valeurs de l'opération SHOW de MySQL dans un rapport détaillé sur le fonctionnement de MySQL
  9. IOTOP / SAR
  10. Êtes-vous sûr que tout le trafic est un trafic valide ? Vous voudrez peut-être vérifier à nouveau les journaux et vous assurer que le trafic est valide.
  11. Toutes les connexions - y en a-t-il plusieurs en provenance des mêmes adresses IP ? (plus que d'habitude) Utilisez ceci pour vérifier combien de connexions proviennent d'une seule adresse IP : netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
  12. Vous pourriez également travailler avec Mod_Evasive
  13. En fonction de vos conclusions - déplacer MySQL vers un autre serveur
  14. Pensez à un répartiteur de charge - ou à Nginx ou passez d'une solution d'hébergement web Apache à une autre comme Cherokee, Nginx, etc...

Si ce message vous a aidé - pourquoi ne pas voter pour lui :-) Bénédictions

0voto

uesp Points 3384

Quelques autres choses en plus de la excellente liste de Glenn:

  • Vérifiez 'top' et 'free' pour vous assurer que vous n'utilisez pas de mémoire d'échange car cela tuera les performances. Si vous constatez que vous commencez à utiliser l'échange, réduisez les besoins en mémoire d'Apache (réduisez principalement MaxClients) et de MySQL (toutes les diverses options de cache/tampon).
  • Si le forum est en PHP, assurez-vous d'exécuter un cache d'opcode comme eAccelerator ou APC.
  • Envisagez de tester les performances du site en utilisant quelque chose comme ab ou siege. Cela vous donnera les capacités actuelles de votre serveur et vous permettra de tester l'effet de certaines optimisations spécifiques.
  • Utilisez top pour voir quelles applications utilisent le CPU aux heures de pointe. Cela vous donnera une idée de base d'où commencer à optimiser.
  • Si vous servez beaucoup de contenu statique, envisagez d'utiliser un serveur web plus léger uniquement pour cela (comme lighttpd ou nginx).
  • Vérifiez les statistiques du journal des requêtes dans MySQL pour vous assurer qu'il est activé et fonctionne bien. Si vous obtenez beaucoup de "LOW MEM Prunes", envisagez d'utiliser plus de mémoire pour le cache si possible.
  • Vous obtiendrez probablement de meilleures performances si vous donnez plus de mémoire à MySQL plutôt qu'à Apache. Idéalement, vous voulez que votre ensemble d'enregistrements actifs puisse être entièrement stocké en RAM, ce qui minimise l'accès au disque. Ce n'est pas la taille totale de la base de données, juste la taille de tous les enregistrements qui sont généralement lus chaque jour. Sur une machine de 4 Go, je m'assurerais que MySQL reçoit au moins 1 Go au total.
  • Sachez que le trafic arrive généralement par vagues et que votre serveur doit non seulement gérer le débit de trafic moyen mais aussi les pics de trafic. Ne vous retrouvez pas dans une situation où votre configuration ne peut gérer que le trafic moyen mais commence à prendre du retard lorsque le trafic atteint des sommets. Vous vous retrouvez alors dans une situation où le serveur peine à suivre mais continue à être de plus en plus surchargé.

Juste d'après mon expérience, votre serveur 'devrait' être suffisant pour prendre en charge un site de 20k vues/jour avec une bonne configuration et quelques ajustements d'optimisation. Je ne serais pas surpris si vous pouviez théoriquement obtenir 10 fois plus que cela ou plus avec un peu de travail.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X