¿Deberían ejecutarse 2 del cron estándar siempre?

8

Mi pregunta se reduce a, ¿deberían múltiples procesos de magento cron: ejecutar -vvv siempre se ejecutan y golpean MySql constantemente.

Estoy configurando Magento 2.2.1 a través de Google Cloud y tengo los 3 trabajos cron estándar que se preconfiguraron a través de la instalación de Magento en 1 clic de Google.

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/update/cron.php 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento setup:cron:run -vvv 2>&1

Mirando la parte superior -c, siempre hay 2 procesos php.bin en ejecución, que afectan constantemente a MySql y hacen que use alrededor del 50% - 70% de CPU todo el tiempo. Aquí hay una instantánea de cómo se ve normalmente.

 PID USER      PR  NI    VIRT    RES    SHR  S   %CPU   %MEM 
19327 mysql     20   0 3872884 332876  19172 S  60.8  3.4 332:42.45 /opt/bitnami/mysql/bin/mysqld.bin --defaults-file=/opt/bitnami/mysql/my.cnf --basedir=/opt/bitnami+
26458 bitnami   20   0  679516 476444  64492 S  24.6  4.9   0:24.85 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv
26415 bitnami   20   0  677532 475672  64588 R  23.6  4.9   1:36.11 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv

También he cambiado los crons para que se ejecuten cada 5 minutos, en lugar del predeterminado cada minuto, pero el comportamiento sigue siendo el mismo.

Mi último cambio fue alternar cada 7 minutos y 8 minutos con los 2 cron: ejecutar trabajos que comienzan con 3 y 4 minutos de diferencia, y con eso solo se ejecuta 1 trabajo cron a la vez con 30% - 40% de CPU de MySQL.

Mi sitio tampoco tiene tráfico en este momento porque aún no lo he lanzado. ¿Es normal este comportamiento de Magento ya que no está pasando nada con el sitio? Lo dejé reposar durante 12 horas sin hacer nada en absoluto y cuando miro desde arriba, el cron todavía se está ejecutando y golpeando MySQL.

ACTUALIZACIÓN: Ahora está claro que el problema es solo el primer cron: ejecutar el proceso que está causando problemas. Cambié los elementos segundo y tercero a cada minuto y dejé el primero a los 8 minutos y solo hay un cron en ejecución: proceso de ejecución a la vez. Según el comentario a continuación, podría ser un problema con las instalaciones de Bitnami Magento, pero esta es mi primera experiencia con Magento, así que no sé si se trata de un comportamiento esperado (realmente espero que no lo sea).

magento2 database cron magento-2.2.1 código menor
fuente
Tengo problemas similares, con una instalación de Bitnami. A partir de ahora, no puedo entender por qué, pero cuando miro la utilización de la CPU en el panel de control de GCE, puedo ver que comenzó en algunos porcentajes de la CPU hace casi 30 días. Ahora, lo estoy maximizando y agregué 4 x RAM y 4 x número de vCPU para mantener vivo el servidor. En lugar de arriba, solía htop. Con ella veo que tengo más de diez líneas con magento cron:run -vvv. Algunos han estado en vivo por varios minutos. Intentaré averiguar por qué el cron no se está ejecutando como se esperaba.
user5198077
Recibo el mismo comportamiento cuando hice que el cron establezca el valor predeterminado cada 1 minuto. Lo cambié para que se ejecutara cada 7 y 8 minutos como lo describí en mi pregunta y solo genera 1 proceso, pero todavía parece que está haciendo demasiado. Suena como tal vez un problema de bitnami magento posiblemente.
codemaller
Sí, cambiar a cada 7 minutos hizo feliz a mi servidor. Pasó de una utilización de CPU de más del 300% y 8 GB de RAM a un 40% (para uno de MySQL pagado) y 1,7 GB de RAM. Investigará cómo puedo activar el registro completo de Cron.
user5198077
Además, -vvv es el registro detallado máximo, por lo que arg puede eliminarse de crontab.
codemaller
Eché un vistazo al gráfico Operaciones de disco (E / S). Cuando el servidor parece estar "funcionando", las operaciones de lectura son cercanas a cero, mientras que las escrituras son bastante altas. Lo que sucede cuando el servidor se cae (o deja de responder) es que las operaciones de lectura pasan las escrituras. Comparando mi instalación de Magento Bitnami 2.2.0 no tan saludable con otro BItnami (creo que todavía en 2.1.6 o 2.1.8), la lectura / escritura están en niveles muy bajos, menos de 2, mientras que para el no tan- saludable (pero ahora funciona) ¡las lecturas están por debajo de 2 pero las escrituras a menudo van más allá de 1000! : O
user5198077

Respuestas:

6

Proporcionando al menos un trabajo temporal para solucionar el problema, para evitar dañar su servidor MySQL. Problema de Git que describe el problema

Al menos parte del problema se reduce a la tabla cron_schedule. Recomiendo hacer un select count(*) from cron_schedule;y si eso devuelve más de unos pocos cientos, entonces tienes el problema. Para mí, esa consulta devolvió 208,046 en un servidor que ha estado ejecutándose durante solo unas pocas semanas.

Si tiene el problema, ejecute esta consulta para eliminar todo en esa tabla, excepto las filas recientes delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Luego ejecute la consulta de recuento nuevamente y debería ser muuuucho más baja. La mía pasó de 208k a 252.

Después de ejecutar esa consulta, configuré los 3 cron estándar nuevamente al estándar una vez por minuto, y como por arte de magia, los 3 se ejecutan casi al instante. De vuelta a la normalidad por lo que puedo decir.

En el problema de github, otro usuario sugiere agregar esa consulta a crontab para evitar que la tabla vuelva a crecer. 

0 * * * * <path_to_mysql_bin_dir>/mysql <magento_db_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)"

La última respuesta del equipo de Magento sobre el problema fue en septiembre diciendo que no pueden reproducir el problema, pero varios usuarios han seguido diciendo que experimentan lo mismo, incluido yo mismo. Así que espero que arreglen esto para que este truco pueda ser eliminado.

EDITAR: Para usar ese comando en el crontab, deberá pasar sus credenciales a MySQL de alguna manera. Vea mi comentario a continuación si está en una máquina virtual o servidor dedicado y desea poner su usuario / pase en crontab, de lo contrario, deberá configurar un archivo de credenciales MySQL. Y puede utilizar which mysqlpara encontrar la ruta a su directorio binario mysql.

código menor
fuente
Su respuesta funcionó para mí, pero agregando crontab, con mysql magento-db -e "query", donde magento-db es el nombre de la base de datos (en mi caso, es bitnami_magento), ¿también funciona cuando hay una contraseña para la base de datos? Normalmente ingreso la base de datos como mysql -u somename -py luego ingreso la contraseña en un mensaje.
user5198077
Usando su motor de búsqueda preferido, será fácil encontrar un par de soluciones para eso; Dejé esa parte para la información de usuario / pase, pero la publicaré, después de dar el descargo de responsabilidad: no haga esto en el alojamiento compartido porque será visible para otros con top -c, entre otras cosas. En ese caso, busque cómo usar un archivo de credenciales MySQL, .mycnf o algo así. Esto es lo que tengo*/15 * * * * <path_to_mysql_binary_dir>/mysql -u<sql_user> -p'<sql_user_pass>' <database_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)";
codemaller