1 votes

Site Drupal à fort trafic - erreurs apache

Je reçois un tas d'erreurs apache que j'ai du mal à retracer. Elles se produisent sur un système RHEL qui exécute un site Web Drupal à très fort volume.

\[Mon Sep 14 12:48:44 2009\] \[info\] \[client xx.xx.xxx.xx\] (70007)The timeout specified has expired: core\_output\_filter: writing data to the network
\[Mon Sep 14 12:50:19 2009\] \[info\] \[client xx.xxx.xx.xx\] (104)Connection reset by peer: core\_output\_filter: writing data to the network
\[Mon Sep 14 12:51:28 2009\] \[info\] \[client xx.xxx.xx.xx\] (32)Broken pipe: core\_output\_filter: writing data to the network

Occasionnellement (toutes les 24 à 36 heures), il y aura un pic de charge et le site ne répondra plus du tout. La charge moyenne passe d'un niveau normal de 1-1,5 à 200. La plupart des processus httpd en cours d'exécution affichent 'D' - deadlocked - et la seule façon de ramener le serveur en mode "interactif" est de saluer avec trois doigts ou d'attendre jusqu'à ce que vous obteniez un message d'invite et un message de confirmation. killall -9 httpd .

Évidemment, le site ne peut pas être mis hors service pour que je puisse faire un tas de travail de strace. J'ai vérifié la configuration d'Apache et (encore) pour autant que je puisse dire, EnableMMAP et EnableSendFile sont désactivés. Les fichiers sont sur un montage NFS v3, mais ni le serveur NFS, ni le serveur mysql, ni rien d'autre ne rapporte d'erreurs. Rien d'approprié dans le journal système ou dmesg. La charge du site est également trop élevée pour pouvoir rapprocher les requêtes individuelles des erreurs qui en résultent.

À ce stade, je pense à une erreur matérielle de réseau et je préférerais mettre le site en ligne sur une deuxième machine. Quelqu'un a-t-il une idée avant que je fasse cela ?

1voto

user13993 Points 257

C'est une supposition hasardeuse, mais avez-vous vérifié combien de tables temporaires Drupal crée sur le disque ?

J'ai vu cela causer des problèmes d'iowait (charge).

mysqladmin -u root -p ext -ri 30 | grep Created_tmp_disk

La première exécution vous dira combien de tables temporaires sur disque ont été créées depuis le dernier redémarrage de MySQL. Ensuite, il vous dira combien ont été créées dans la fenêtre de temps de 30 secondes (jusqu'à ce que vous fassiez Control-C pour en sortir).

La solution (provisoire) consiste à placer le tmpdir de MySQL sur un système de fichiers basé sur la RAM (par exemple, tmpfs).

Je pense que ce que je veux dire, c'est que cela déclenche la cascade - et que les messages que vous voyez sont juste des connexions abandonnées.

Cheers

0 votes

Jason, bonne suggestion. Le problème est que mysql est sur une machine distante qui alimente quelques autres machines à partir de la même base de données, et que cette machine fonctionne bien.

1voto

epic9x Points 1608

En bref, dans votre configuration apache, essayez ce qui suit :

EnableMMAP Off

Désactivation du fichier d'envoi

En long :

Apparemment, Apache met en correspondance les fichiers et tente d'utiliser le sendfile de linux ( http://linux.die.net/man/2/sendfile ) pour des raisons de performance lorsqu'il est disponible, mais selon la documentation d'Apache, cela peut causer des problèmes de stabilité sur les systèmes de fichiers en réseau s'il ne parvient pas à lire le fichier :

http://httpd.apache.org/docs/2.0/mod/core.html#enablesendfile

Ils donnent des informations spécifiques à ce sujet ici :

http://httpd.apache.org/docs/2.0/faq/all_in_one.html#error.sendfile

Vous trouverez des informations sur les directives EnableMMAP et EnableSendfile ici :

http://httpd.apache.org/docs/2.0/mod/core.html#enablemmap

0 votes

Ces paramètres sont déjà présents et désactivés pour l'ensemble du site. D'autres suggestions ?

1voto

RP. Points 191

Nous avons réussi à équilibrer le site en passant à InnoDB sur toute la ligne et en configurant correctement le cache des clés, ainsi qu'en ajoutant un certain nombre de memcache et autres. Toutes les erreurs que j'ai citées plus haut étaient apparemment causées par des clients qui annulaient les demandes de processus longs, car dès que la base de données a été réglée, les erreurs ont disparu.

0voto

GJ. Points 717

Ajoutez nginx comme proxy de votre apache et servez directement le contenu statique. ou même, remplacez complètement apache. Cela réduira considérablement les charges d'apache.

0 votes

Maintenant que vous le dites, j'imagine que remplacer complètement apache pourrait bien faire baisser les charges d'apache, en y réfléchissant bien, oui...

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