El uso de memoria de los procesos php-cgi está creciendo constantemente


8

Estoy tratando de configurar un servidor web en un VPS. Mi problema es que el uso de memoria de los procesos php-cgi aumenta con el tiempo a pesar de que el sitio web no recibe ningún tráfico. (por el momento está detrás de un firewall)

El VPS tiene 360 ​​MB de RAM. Estoy usando Debian Lenny 32bit y sus paquetes lighttpd y php5-cgi. Además de algunos cambios de configuración (enumerados a continuación), estoy usando la configuración de stock de Debian.

El sitio web está basado en Drupal. Usando el módulo de desarrollo de Drupal, puedo decir que el uso de memoria de los scripts PHP es menos de 20 KB en promedio, y nunca excede los 8 MB.

Aquí están las partes relevantes de la salida 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
  • ¿Es normal tener php-cgi tan grande?
  • ¿Es posible estimar el uso de memoria php-cgi en función de la configuración?
  • ¿Algún consejo para reducir el consumo de memoria de los procesos php-cgi?

La búsqueda de errores conocidos de pérdida de memoria no produjo nada relevante. Y me sorprendería si los paquetes / configuración predeterminados de Debian tuvieran una pérdida de memoria tan obvia. Otros usuarios en el mismo host no tienen este problema.

Lo que he hecho hasta ahora está configurado PHP_FCGI_MAX_REQUESTSen un valor bajo para que los procesos php-cgi se reciclen rápidamente. Cuando uso abpara simular una carga alta, esto funciona muy bien. Los procesos mueren rápidamente antes de crecer más de 10 MB. Sin embargo, bajo una carga de baja a media, todos los procesos crecen de manera constante (debido al equilibrio de carga) y la mayoría de ellos consumen 28 MB + simultáneamente, poniendo mi VPS en riesgo de intercambio. Tenga en cuenta que incluso sin ningún tipo de tráfico, los procesos crecen de manera constante.

Puedo reducir la cantidad de procesos php-cgi, pero esto parece más una solución que una solución. Me sorprendería si php-cgi normalmente creciera así.

Además, sumar los números RSS totales para los procesos php-cgi da:

$ ps -C php-cgi -o rss= | awk '{s+=$1}END{print s/1024}'
195.738

Sin embargo, free -mda el siguiente resultado:

             total       used       free     shared    buffers     cached
Mem:           360        351          8          0         33        190
-/+ buffers/cache:        127        232
Swap:          255          0        255
  • ¿Me estoy perdiendo de algo? ¿Cómo es que la memoria utilizada (sin buffers) es menor que la memoria residente total de los procesos php-cgi en el host?

Tengo las siguientes extensiones de PHP:

php5-cgi php5-common php5-curl php5-gd php5-mysql php5-xcache

xcache.sizeestá configurado en 24M. Solía ​​ser 32M pero reducirlo no ayudó. xcache.var_sizese establece en 0. Los complementos restantes están utilizando la configuración estándar. Las páginas de administración de xcache muestran que xcache está utilizando menos de 1 MB.

PHP memory_limitestá configurado en 32M.

Aquí está mi configuración 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" 
  ))
)

Estoy usando más o menos el stock lighttpd.confque se envía con Debian.

Avíseme si hay otros datos que pueda proporcionar.

Cualquier ayuda es apreciada. He estado tratando de solucionar esto por días. Me he quedado sin ideas.

Respuestas:


2

Intenta bajar var_size. Si teníamos un valor de 64 MB, después de algunas horas comenzó a intercambiarse mucho, y después de las siguientes horas estaba completamente inactivo. Intente mantener la configuración original a 32M, tal vez esto debería ayudarlo mucho: tuvimos el mismo problema en nuestro sitio de viajes Xcache todavía es un montón de software con errores :(


1

Establecer las solicitudes máximas es la idea correcta. Esa es la forma de evitar que la RAM del sistema se llene cuando hay una pérdida de memoria.

Una cosa que sugiero que intentes es cambiar a apache + mod_php. Si eso funciona sin pérdida de memoria, significa que su problema estaba relacionado con CGI. Si continúa perdiendo con mod_php, entonces probablemente haya una pérdida de memoria en el código en alguna parte.

Dijiste que estás usando Drupal. ¿Tiene algún tipo de módulos Drupal instalados? Dudo que una versión estable de Drupal tenga pérdidas de memoria en el núcleo, por lo que es más probable que ocurran problemas en los módulos y otros complementos y personalizaciones de terceros.


Gracias por tu respuesta. Todos los módulos de Drupal son bien conocidos, y el módulo de desarrollo no informa ninguna pérdida de memoria en Drupal. Además, la pérdida de memoria ocurre incluso si no hay golpes en absoluto. En cuanto a probar Apache, dejaría esto como último recurso cuando no tenga ideas. Gracias de nuevo.
John

Tengo los mismos problemas ... ¿Cómo matas el proceso PHP-CGI cuando terminas? Solo estoy usando la misma configuración con Wordpress, y casi está matando mi porción de 256 mib.
Kyle

Use Nginx ya que es más pequeño que ambos servidores y no tiene pérdidas de memoria de PHP. Wordpress y otros sitios grandes lo usan.
Xeoncross

0

Muchas veces, este tipo de problemas se debe a algún caché de código de operación, como XCache o debido a la extensión de PHP memcached.


0

Elimine las bibliotecas no utilizadas de /etc/php5/apache2/conf.d. Probablemente no necesite pdo.ini y pdo_mysq.ini o mysqli.ini. Esto le ahorrará unos pocos Mega de Ram

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.