J'essaie de configurer un serveur Web sur un VPS. Mon problème est que l'utilisation de la mémoire des processus php-cgi augmente avec le temps, même si le site Web ne reçoit aucun trafic. (il est pour l'instant derrière un pare-feu)
Le VPS a 360 Mo de RAM. J'utilise Debian Lenny 32bit et ses paquets lighttpd et php5-cgi. Mis à part quelques changements de configuration (répertoriés ci-dessous), j'utilise la configuration de stock de Debian.
Le site Web est basé sur Drupal. En utilisant le module de développement de Drupal, je peux dire que l'utilisation de la mémoire des scripts PHP est inférieure à 20 Ko en moyenne, et qu'elle ne dépasse jamais 8 Mo.
Voici les parties pertinentes de la sortie de ps aux
:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
www-data 29871 0.0 1.7 54552 6368 ? Ss Aug12 0:00 /usr/bin/php-cgi
www-data 29873 0.0 7.4 65808 27468 ? S Aug12 0:00 /usr/bin/php-cgi
www-data 29874 0.0 3.7 55808 13736 ? S Aug12 0:00 /usr/bin/php-cgi
www-data 29875 0.0 4.3 58040 16204 ? S Aug12 0:00 /usr/bin/php-cgi
www-data 29876 0.0 4.4 57444 16288 ? S Aug12 0:00 /usr/bin/php-cgi
www-data 29877 0.0 1.7 54552 6368 ? Ss Aug12 0:00 /usr/bin/php-cgi
www-data 29879 0.0 9.6 67140 35684 ? S Aug12 0:26 /usr/bin/php-cgi
www-data 29880 0.0 6.6 59172 24492 ? S Aug12 0:23 /usr/bin/php-cgi
www-data 29881 0.0 7.1 59784 26388 ? S Aug12 0:22 /usr/bin/php-cgi
www-data 29882 0.0 7.4 60880 27440 ? S Aug12 0:23 /usr/bin/php-cgi
- Est-il normal d'avoir un php-cgi aussi grand?
- Est-il possible d'estimer l'utilisation de la mémoire php-cgi en fonction des paramètres?
- Des conseils pour réduire la consommation de mémoire des processus php-cgi?
La recherche de bogues de fuite de mémoire connus n'a rien donné de pertinent. Et je serais surpris si les paquets / config Debian par défaut avaient une fuite de mémoire aussi évidente. Les autres utilisateurs sur le même hôte n'ont pas ce problème.
Ce que j'ai fait jusqu'à présent est réglé PHP_FCGI_MAX_REQUESTS
sur une valeur faible afin que les processus php-cgi soient recyclés rapidement. Lorsque j'utilise ab
pour simuler une charge élevée, cela fonctionne très bien. Les processus meurent rapidement avant de dépasser 10 Mo. Cependant, sous une charge faible à moyenne, tous les processus se développent régulièrement (en raison de l'équilibrage de charge) et la plupart d'entre eux consomment 28 Mo + simultanément, mettant mon VPS à risque de permutation. Veuillez noter que même sans aucune sorte de trafic, les processus se développent régulièrement.
Je peux réduire le nombre de processus php-cgi, mais cela ressemble plus à une solution de contournement qu'à un correctif. Je serais surpris si php-cgi grandissait normalement comme ça.
De plus, la somme des nombres RSS totaux pour les processus php-cgi donne:
$ ps -C php-cgi -o rss= | awk '{s+=$1}END{print s/1024}'
195.738
Pourtant, free -m
donne la sortie suivante:
total used free shared buffers cached
Mem: 360 351 8 0 33 190
-/+ buffers/cache: 127 232
Swap: 255 0 255
- Suis-je en train de manquer quelque chose? Comment se fait-il que la mémoire utilisée (sans tampons) soit inférieure à la mémoire résidente totale des processus php-cgi sur l'hôte?
J'ai les extensions PHP suivantes:
php5-cgi php5-common php5-curl php5-gd php5-mysql php5-xcache
xcache.size
est réglé sur 24M. Auparavant, il était de 32M, mais sa réduction n'a pas aidé. xcache.var_size
est défini sur 0. Les autres plugins utilisent la configuration de stock. Les pages d'administration de xcache montrent que xcache utilise moins de 1 Mo.
PHP memory_limit
est réglé sur 32M.
Voici ma configuration FastCGI:
fastcgi.server = ( ".php" =>
((
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket",
"max-procs" => 2,
"idle-timeout" => 20,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "4",
"PHP_FCGI_MAX_REQUESTS" => "1000"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
))
)
J'utilise plus ou moins le stock lighttpd.conf
fourni avec Debian.
Veuillez me faire savoir s'il y a d'autres données que je peux fournir.
Toute aide est appréciée. J'essaie de résoudre ce problème depuis des jours. J'ai manqué d'idées.