Abonnement aux commentaires

S'abonner pour recevoir les commentaires suivants par email

まこと の ブログ

MaKoTo no burogu — Journal de bord…

Aller au contenu | Aller au menu | Aller à la recherche

Apache2 en mode multi-thread

Depuis déjà 6 mois, comme cela s'était déjà produit, mon serveur plante de temps à autre…
Le démon Apache2 devient fou et déclenche les foudres d'anon, le killer de démon, qui vise à libérer de l'espace mémoire Ram+Swap, mais la Machine est à ce point submergée que rien n'y fait, il est impossible de prendre la main et le disque dur gratte comme un fou, jusqu'à ce qu'on veuille bien lui administrer les magic syst key (SEIUB)

En fait mon serveur s'est retrouvé non pas victime de son succès, mais de la coïncidence de plusieurs événements simultanés :
. scan par les robots de divers moteurs de recherche
+ scan de divers planet
+ consultation de visiteurs de mes deux sites
+ mon propre usage de TinyTinyRSS
= Autant de démon Apache2 qui se lancent que de requêtes html, php5, etc.

Bref, le temps de cerner le coupable et comprendre le problème, j'ai enfin décidé de tenter quelque chose… Apache2 en mode multi-thread

Il m'avait bien semblé voir passer un billet au titre intéressant, et en fouillant les tréfonds de ce cher TinyTinyRSS j'ai pu le retrouver et le mettre en œuvre !

Très clair, on y explique ce qui semble être la solution à mon problème, et la méthode fonctionne très bien !
Maintenant il y a très peu de lourd démon Apache2 et beaucoup de léger démon php.
On peut aussi vérifier la config en créant la fameuse page phpinfo.

Mais ayant eu quelques soucis avec ma config, je vais préciser certaines choses :

  • En premier lieux, si vous utilisez un accès https pour lire votre Webmail ou votre TinyTinyRSS, vous risquez de tomber sur une erreur de type :
ERROR : Wrong 'suhosin.session.encrypt' option value

Et effectivement, comme pour /etc/php5/cgi/php.ini, la config cgi de suhosin est elle aussi placée ailleurs.
Il faudra alors éditer /etc/php5/cgi/conf.d/suhosin.ini et dé-commenter puis mettre à off la ligne suhosin.session.encrypt

suhosin.session.encrypt = off
  • Seconde chose, l'upload de fichiers de plus de 130 kio au travers de php s'est révélé impossible (via Dotclear, Owncloud…) avec notamment des erreurs 500.

Et ceci alors même que la configuration dans le nouveau fichier /etc/php5/cgi/php.ini était correcte, c'est à dire :

file_uploads= On

ou Off permet d'autoriser ou non l'envoi de fichiers.

upload_max_filesize = 2M

permet de définir la taille maximale autorisée pour le fichier. Si cette limite est dépassée, le serveur enverra un code d'erreur.

post_max_size = 2M

indique la taille maximale des données envoyées par un formulaire. Cette directive prime sur upload_max_filesize, il faut donc s'assurer d'avoir post_max_size supérieure à upload_max_filesize.

En fait, c'est un autre fichier de config qui fixait la limite de 130 kio !
C'est donc /etc/apache2/mods-available/fcgid.conf qu'il faut amender d'une ligne MaxRequestLen

<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
  MaxRequestLen 1073741824
</IfModule>

Ici j'ai donc mis 1 Gio, valeur configurée par défaut lorsqu'on utilise Apache2 en mode « pas multi-thread»
Ce qui au passage, explique enfin pourquoi avec Owncloud je ne pouvais pas uploader plus d'1 Gio par fichier ^^

Sources :
- http://www.commentcamarche.net/faq/889-php-upload-de-fichiers#configuration-de-php-pour-permettre-l-upload
- http://blog.philippklaus.de/2011/04/fix-mod_fcgid-http-request-length-xyz-so-far-exceeds-maxrequestlen-131072/
- http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

Commentaires

1. Le samedi, 31 décembre 2011, 18:57 par Comete

Il m'est arrivé la même chose il y a 2 ans avec un serveur Apache en prod. Mais j'ai été beaucoup moins persévérant de toi, je suis directement passé à Nginx et ce ne fut que du bonheur ;)
Depuis je ne jure que par ce serveur web/reverse-proxy/proxy-imap

2. Le lundi, 2 janvier 2012, 16:03 par skc

Passer en mode worker n'est pas une mauvaise idée, mais quand on a des problèmes de performances liés à PHP, c'est a mon avis une mauvaise idée puisque ça entraine une baisse des performances.

Rien n'indique non plus que la nouvelle configuration est à l’abri de ce qui s'est produit en mode prefork.

La BONNE solution est de configurer le système pour qu'il n'accepte pas plus de requêtes qu'il n'est capable d'en traiter. Cela est valable quelque soit le serveur web (Apache ou Nginx) ou le mode de fonctionnement (prefork, worker).

Pour des applis PHP, cela se fait principalement sur deux points:

1. La configuration d'Apache indique le nombre maximum de requêtes simultanées que l'on doit accepter.

2. La configuration de PHP permet de limiter la mémoire maximum par requêtes et éventuellement le temps maximum de traitement d'une requête.

Calcule rapidement le nombre de requêtes max par la mémoire max, mets le en regard de la mémoire que tu as sur ton serveur, tu verras rapidement le problème.

En prime, lorsqu'on commence à taper dans le swap, il y a un phénomène d’avalanche: les requêtes sont plus lentes à traiter et du coup on en accumule plus en parallèle.

3. Le vendredi, 6 janvier 2012, 13:50 par MaKoTo

Merci à vous deux !
J'étudierais donc çà aussi histoire d'optimiser le bidule.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

Fil des commentaires de ce billet