El comando `drush cc all` lleva demasiado tiempo, ¿qué puedo hacer?

En un sitio mío, drush cc alltarda más de 4 minutos en ejecutarse. El sitio db es de unos pocos GB. Sin embargo, no puedo ver una razón clara de por qué lleva demasiado tiempo. ¿Qué puedo hacer para localizar el cuello de la botella?

El borrado de la memoria caché por sí mismo no lleva mucho tiempo, ya que solo está truncando las tablas de la memoria caché. Lo que lleva más tiempo es reconstruir el registro de caché después de eso. Por lo general, es el registro de temas el que escanea todos los nuevos ganchos y todas sus carpetas de Drupal para nuevos archivos de plantilla, el sistema que escanea los archivos para los nuevos módulos y archivos de clase, y similares.

Siempre puede borrar el caché específico especificando drush cc theme-registryo cualquier otro.

Se recomienda encarecidamente que utilice el mecanismo de almacenamiento en caché de PHP (por ejemplo, OPCache, XCache, etc.) para acelerar el procesamiento. Y la memoria caché basada en la memoria para reemplazar el uso intensivo en las tablas SQL (por ejemplo, memcached o redis), por lo que borrar la memoria caché no llevaría tiempo, simplemente vaciando la memoria caché (por ejemplo, echo flush_all > /dev/tcp/127.0.0.1/11211en Bash).

Alternativamente, siempre puede borrar la memoria caché manualmente , por ejemplo:

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

Depuración

Para verificar qué lleva más tiempo específicamente, necesita depurarlo / perfilarlo (por ejemplo, XDebug, XHProf, phpdbg, dtrace).

En OS X / Unix, esto se puede lograr dtrace(después de ejecutar drush):

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

En Linux, use strace, p. Ej.

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

Para buscar algunas cosas específicas, por ejemplo, trate de añadir: strace ... 2>&1 | grep -C5 UPDATE.

Si tiene una base de datos realmente grande y su sistema funciona bien cuando no está borrando la memoria caché, es probable que no tenga suficiente memoria para admitir completamente su configuración.

Si su sitio se ejecuta en un cuadro de Linux, ejecute 'top' (desde su shell) y presione shift-M para ordenar la lista de procesos por la memoria utilizada. Luego, ejecute su operación de borrado de caché desde otra terminal. Debería ver que mysql y apache suben a la parte superior de la lista. Podrá ver qué porcentaje de la memoria total está usando cada uno de estos procesos y cuánta RAM libre se usa. Si tiene una gran cantidad de espacio virtual, pero toda su RAM física está agotada, esta operación podría causar que la memoria de la VM se bloquee, lo que puede reducir el tiempo de ejecución a una pequeña fracción de lo que normalmente es.

Una vez, estaba ejecutando un sitio Drupal de tráfico medio en una caja sin memoria suficiente para soportar la configuración. Cuando ejecuté un borrado de caché en un sitio de bajo tráfico no relacionado, la reconstrucción de caché empujó el sistema más allá de su límite, y todo se cerró. Entonces, el comportamiento total del sistema es importante aquí; Es por eso que las herramientas simples como 'top' son un lugar útil para comenzar.

Voy a estar en desacuerdo (algo) con @ greg_1_anderson aquí.

Si el sistema no se bloquea por completo durante un cc all, entonces no creo que tenga un problema de memoria general. Cuando un servidor LAMP se queda sin memoria, golpeará el intercambio. Un servidor activo que golpea el intercambio causará una avalancha de maldad. Los procesos httpd comenzarán a acumularse debido a la desaceleración del sistema (el intercambio hace que el sistema funcione muy lento), lo que hará que se use más intercambio, etc. En los sitios donde he visto que esto sucede, vería que la carga del proceso llega a 100 y una tonelada de procesos httpd activos.

Si su sistema finalmente regresa, entonces creo que está mal ajustado. drush cc alldará como resultado muchos accesos a la base de datos, por lo que creo que muestra más el problema. Mi sugerencia sería ejecutar mysqltuner en el sitio. Si tiene una base de datos de varios GB, supongo que innodb_buffer_pool_sizeni siquiera tiene el tamaño adecuado de forma remota, y su instancia de MySQL se está agitando. También investigaría un backend de caché alternativo para tratar de mantener la huella de la base de datos más pequeña.

Podría ser su entorno de alojamiento web. ¿Te refieres a una configuración local, o algo de alojamiento en alojamiento compartido o un VPS / servidor?

• entorno de alojamiento : si tiene un alojamiento web compartido, la cantidad de memoria que Drupal / drush puede usar será limitada, consulte: https://drupal.org/node/207036
• tiempo de ejecución máximo : debe aumentarse

Esta no es una solución completa, solo una herramienta más para ayudar a identificar la fuente de sus retrasos.

Además de usar toppara monitorear procesos, puede encontrar la salida de mytopinformativo. (Otras respuestas anteriores suponen MySQL, pero si está utilizando otro back-end de DB, deberá cambiar mytop por una herramienta equivalente).

mytopsimplemente ejecuta MySQL SHOW FULL PROCESSLISTen un bucle y le muestra qué consultas se están ejecutando (lo que lleva mucho tiempo). Si el borrado de la memoria caché está tardando mucho en limpiar esta o aquella tabla, verá exactamente lo que está reteniendo aquí. Si no tiene acceso para instalar mytop, solo haga una versión cruda en su shell -

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

Si el retraso no se debe a las consultas de MySQL, entonces esta herramienta al menos puede confirmarlo por usted.

Encontré una publicación de blog titulada Speed ​​Up Cache Clearing en Drupal 7 que es muy útil para reducir con precisión qué parte del proceso de borrado de caché estaba ralentizando las cosas. Los problemas que señala en el módulo de características y el módulo de API de la entidad estaban afectando a mi sitio, pero el proceso detallado en la publicación también me ayudó a rastrear los problemas que estábamos encontrando en el módulo Drupal core y breakpoints .

Me lleva algún tiempo trabajar en el proceso, pero me ha ayudado a reducir la eliminación de caché de varios minutos a menos de un minuto.