php - remove - strip_tags wordpress

PHP 5.5, bajo qué circunstancias PHP causará memoria comprometida muy alta (3)

Hay dos cosas que debes entender sobre Committed_AS,

Es una estimación
Alude a la cantidad de memoria que necesitaría en el peor de los casos (más el intercambio). Depende de la carga de trabajo de su servidor en ese momento. Si tiene una carga de trabajo menor, Committed_AS será menor y viceversa.

Si esto no fue un problema con la iteración anterior de la cola de marcos y siempre que no haya introducido ningún cambio de código nuevo en el entorno de producción, querrá comparar las dos iteraciones. Tal vez girar otra caja y ejecutar algunas pruebas. También puede perfilar la aplicación con xdebug o zend_debugger para descubrir posibles factores causales con el código en sí. Otra herramienta útil es strace.

¡Todo lo mejor, vas a necesitarlo!

Estoy tratando de descubrir una situación en la que PHP no consume mucha memoria, pero en su lugar causa un muy alto resultado de Committed_AS .

Tome este informe de memoria Munin, por ejemplo:

Tan pronto como inicio nuestra cola de Laravel (10 ~ 30 trabajadores), la memoria comprometida se dispara. Tenemos 2G mem + 2G swap en esta instancia de vps y hasta ahora hay alrededor de 600M de memoria no utilizada (eso es aproximadamente 30% gratis).

Si entiendo Committed_AS correctamente, se supone que es una garantía del 99.9% de que no haya falta out of memory dada la carga de trabajo actual, y parece sugerir que necesitamos triplicar nuestra memoria vps solo para estar seguros.

Traté de reducir el número de colas de 30 a alrededor de 10, pero como puede ver, la línea verde es bastante alta.

En cuanto a la configuración: Laravel 4.1 con PHP 5.5 opcache habilitado. La secuencia de comandos upstart que usamos instancia spawn como la siguiente:

instance $N exec start-stop-daemon --start --make-pidfile --pidfile /var/run/laravel_queue.$N.pid --chuid $USER --chdir $HOME --exec /usr/bin/php artisan queue:listen -- --queue=$N --timeout=60 --delay=120 --sleep=30 --memory=32 --tries=3 >> /var/log/laravel_queue.$N.log 2>&1

He visto muchos casos cuando el uso de intercambio alto implica memoria insuficiente, pero nuestro uso de intercambio es bajo, por lo que no estoy seguro de qué paso de solución de problemas es el apropiado aquí.

PD: no tenemos este problema antes de Laravel 4.1 y nuestra actualización de vps, aquí hay una imagen para demostrarlo.

Tal vez debería reformular mi pregunta como: ¿cómo se calcula Committed_AS exactamente y cómo factor PHP en él?

Actualizado el 2014.1.29:

Tenía una teoría sobre este problema: desde laravel queue worker realmente usa PHP sleep() cuando esperaba un nuevo trabajo de cola (en mi caso beanstalkd ), sugeriría que la alta estimación de Committed_AS se debe a la carga de trabajo relativamente baja y la memoria relativamente alta consumo.

Esto tiene sentido ya que veo Committed_AS ~ = avg. memory usage / avg. workload avg. memory usage / avg. workload avg. memory usage / avg. workload Como PHP sleep() correctamente, se usa poca CPU o ninguna; sin embargo, cualquier memoria que consuma todavía está reservada. Lo que resulta en el pensamiento del servidor: hey, usa tanta memoria (en promedio) incluso cuando la carga es mínima (en promedio), debe estar mejor preparado para una mayor carga (pero en este caso, una carga mayor no da como resultado una memoria superior huella)

Si alguien quisiera probar esta teoría, estaré encantado de otorgarle la recompensa.

Recientemente encontré la causa raíz de este problema de memoria altamente comprometido: la configuración de OPcache de PHP 5.5 .

Resulta que poner opcache.memory_consumption = 256 hace que cada proceso de PHP reserve mucha más memoria virtual (puede verse en la columna VIRT en su comando top ), por lo tanto Munin estima que la memoria potencialmente comprometida es mucho más alta.

El número de colas de laravel que tenemos en segundo plano solo exagera el problema.

Al poner opcache.memory_consumption en los 128 MB recomendados (realmente no usamos todos esos 256 MB de forma efectiva), hemos reducido el valor de estimación a la mitad, junto con la actualización reciente de RAM en nuestro servidor, la estimación es de alrededor de 3 GB, mucho más razonable y dentro de nuestro límite total de RAM

Committed_AS es el tamaño real que el kernel prometió procesar. Y las queues ejecutan de manera independiente y no tienen nada que ver con PHP o Laravel. Además de lo que dijo Rijndael, recomiendo instalar New Relic que se puede usar para descubrir el problema.

Consejo: Noté una gran reducción en la carga del servidor con la combinación NginX-HHVM. Darle una oportunidad.