Hogar › Tarifas › Exceder el límite de CPU: reducir la carga en el hosting. ¿Qué métodos he probado para combatir la carga crítica en la CPU? Cómo llegó la realización

Exceder el límite de CPU: reducir la carga en el hosting. ¿Qué métodos he probado para combatir la carga crítica en la CPU? Cómo llegó la realización

Hola, queridos lectores del blog. ¡Felices vacaciones!

Durante este período de tiempo (aproximadamente media hora), el panel de administración muestra un error 502 y, aunque los visitantes pueden acceder al sitio, las páginas se abren con bastante lentitud (de 5 a 15 segundos). Si no se hubiera utilizado el almacenamiento en caché en el blog, habrían emitido un error 502. Lo único que ayuda es reiniciar el servidor dos veces o esperar estúpidamente hasta que todo se resuelva por sí solo.

Además, en momentos de mucha carga, la búsqueda del sitio no funciona y no se envían comentarios, pero son cosas menores. En general, la situación, como comprenderá, es desagradable, aunque no crítica. Parece tolerable, pero es molesto... terrible.

En general, WordPress requiere ojo y ojo. Sí, el motor es gratuito, al mismo tiempo profesional y simplemente loco, pero todo tipo de malos excesos, no, no, e incluso se escapan. Aquí. Esta vez también me llamó la atención “algo nuevo”. Estas eran tres líneas de código (o mejor dicho, tres hipervínculos de servicio) nuevamente en el encabezado de la página generada por WordPress:

Después de buscar un poco en Google, me di cuenta de que "esto" apareció en WordPress 4.4 y era necesario para algo (todavía tengo una idea vaga de qué; si lo sabe, explíquelo). Porque "Esto" apareció recientemente, no fue posible buscar en Google muchas recetas de eliminación, y lo que se encontró funcionó de alguna manera torcida (el primer enlace fue eliminado, pero los otros dos no, y comenzaron a conducir a la misma página, el código de los cuales estaba abierto).

En general, decidí posponer esto por ahora hasta que se aclare la situación y aparezcan recetas para "cortar procesos innecesarios". Sí, de nuevo, si se trata de un tema, dímelo, porque estos enlaces realmente me irritan. Al menos para qué se necesitan y si son destructivos para la promoción de blogs. Pero aquí me he retirado por ahora.

Además, también hubo un bloqueo muy notable en el código fuente:

Recuerdo que él estuvo allí antes. Recuerdo que supuestamente antes sabía de dónde venía, pero ahora por más que lo intenté no lograba recordar ni siquiera conseguir de dónde venía esta “belleza” en la cabecera del blog (también estaba presente en otros blogs). ). Dudé un poco mentalmente y me quedé mirando la palabra emoji en el código. Escribí recientemente. Busqué en Google un poco y me convencí de que sí, este código ayuda a mostrar estos mismos emoticones emoji en las páginas de WordPress.

Como solo muestro emoticones emoji en dos o tres artículos, decidí eliminar esta desgracia, para lo cual busqué una receta en Internet. La solución, como siempre en estos casos, fue agregar filtros desde la carpeta del tema de WordPress que estás utilizando. En general, encontramos en él el punto final de alguna función (punto y coma) y agregamos varias líneas de código incomprensible (para mí), pero bastante funcional:

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

Esta es la opción más completa para desactivar la compatibilidad con emojis en WordPress. Si quieres déjalo en el panel de administración. Eso es todo, después de esto hubo una agradable sensación de limpieza del código de todo tipo de cosas diferentes.

En aquellas páginas donde usé emoji, tuve que corregir ligeramente el texto. Simplemente abrí estos artículos para editarlos en el panel de administración y desde el principio (en el editor HTML, no en el visual) agregué este mismo código, que eliminé del encabezado de todas las páginas:

window._wpemojiSettings = ("baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4") );

img.wp-smiley, img.emoji (pantalla: en línea !importante; borde: ninguno !importante; box-shadow: ninguno !importante; altura: 1em !importante; ancho: 1em !importante; margen: 0 .07em !importante; alineación vertical: -0.1em !importante; fondo: ninguno !importante relleno: 0 !importante )

Eso es todo, recibí satisfacción de al menos una solución parcial al problema con la pureza del código fuente y continué con mi rutina (escribir artículos y otras tonterías).

Cómo llegó la realización

En cualquier caso, basándose en el momento y en que el problema no aparece tras eliminar el código de soporte emoji, se podrían sacar ciertas conclusiones. Los hice y escribí esta publicación. Si el problema vuelve a surgir, P.D. aparecerá justo debajo. con arrepentimiento por el tiempo perdido (por usted al leer y por mí al escribir).

La decisión resultó ser realmente incómoda, al menos desde mi punto de vista mental más bajo. ¿Dónde está la lógica? No lo sé, pero sigue siendo agradable que, aunque sea por accidente, el incidente técnico que me atormentaba durante bastante tiempo se haya resuelto con mayor o menor éxito. Por ello, permítame despedirme. Gracias por su atención y una vez más Felices Fiestas.

¡Buena suerte para ti! Nos vemos pronto en las páginas del blog.

Puedes ver más vídeos yendo a ");">

Quizás te interese

El menú de la izquierda en el panel de administración de WordPress desapareció después de una actualización. Dónde descargar WordPress: solo desde el sitio web oficial wordpress.org.
Instalar WordPress en detalles e imágenes, iniciar sesión en el área de administración de WP y cambiar la contraseña Página en blanco al ver publicaciones (artículos) grandes en WordPress
Reducir el consumo de memoria en WordPress al crear páginas: complemento WPLANG Lite para reemplazar el archivo de localización
Cómo iniciar sesión en el área de administración de WordPress, así como cambiar el nombre de usuario y la contraseña del administrador que se le proporcionaron al instalar el motor

Saludos a todos los lectores del sitio del blog. Tarde o temprano, todo autor de un blog de WordPress se enfrenta a la pregunta: ¿cómo reducir la carga en el servidor? Algunas personas piensan en esto de antemano (teniendo conocimiento), mientras que otras (novatos) comienzan a recibir cartas de "felicidad" del anfitrión. Se vuelve aún más triste cuando el blog comienza a cerrarse periódicamente por exceder los límites.

A mí me pasó una historia similar en 2010. El tráfico en mi primer blog finalmente apareció, creciendo de manera lenta y segura. No pasó mucho tiempo para alegrarse. Pronto me sucedió exactamente lo que describí anteriormente.

Todo es maravilloso, me gustó todo, excepto el precio: 30 dólares. En aquel entonces costaba exactamente esa cantidad.

Millones no salieron de mi blog y pasé de largo, dejando el uso de la opción de almacenamiento en caché con MaxCache para más adelante. Resolví mi problema con el aumento de carga en el servidor de otra manera. Después de otra oferta para cambiar el plan tarifario, cambié de hosting.

Y luego llegó el día en que, por primera vez, en lugar de uno de los complementos de almacenamiento en caché de WordPress, instalé MaxCache. En 2013, mientras escribía un blog sobre televisión por satélite, decidí usarlo para almacenar en caché el blog.

Utilicé la versión ligera gratuita durante dos días, me convencí de que iba por el camino correcto y compré la versión completa de pago.

Ahora, cuando hago un blog para alguien o lanzo algo propio, sin dudarlo, instalo MaxCache para el almacenamiento en caché del blog.

Como puede ver, este blog también se utiliza para reducir la carga en el servidor. El precio actual de MaxCache es de 10 dólares.

Algoritmo de trabajo: cómo MaxCache reduce la carga en el servidor

Para mayor claridad, tomé capturas de pantalla del pie de página de la página principal del sitio de la carga creada en el servidor antes de usar el script de almacenamiento en caché y después de conectar MaxCache.

Para aquellos que no saben cómo mostrar información sobre la carga en el servidor, la cantidad de solicitudes y el tiempo de generación de la página, se lo diré. Todo se hace de forma muy sencilla.

Abra el archivo footer.php de su tema y pegue el siguiente código antes de la etiqueta de cierre.

Consultas MySQL Velocidad de generación de páginasSin script 11,68 MB 31 0,68Con MaxCache 0,82 MB 0 0,00025

¡La carga del servidor ha disminuido más de 14 veces!

¡La cantidad de llamadas a la base de datos cuando se usa el script es cero!

¡La velocidad de generación de páginas ha aumentado 2720 veces!

Los números son buenos, pero incluso sin ellos, el trabajo más rápido del blog se nota visualmente. Las páginas se abren con mucha más alegría.

¿Cómo funciona el script de almacenamiento en caché? Un usuario que visitó su sitio abrió la página que le interesaba, MaxCache la colocó inmediatamente como una página estática en la carpeta Cache. Ahora se entrega a los usuarios desde esta carpeta sin consultas a la base de datos y sin carga adicional en el servidor.

La caché de la página se restablece cada 4 horas. Si lo desea, puede especificar su propia configuración.

El script viene con un complemento que, cuando se activa, nos permite ver las versiones actuales de las páginas no almacenadas en caché cuando iniciamos sesión y trabajamos en el panel de administración del blog. Para los visitantes en este momento, como se esperaba, el script los recupera del caché.

Es posible habilitar la compresión de tráfico gzip. Aumenta la velocidad de carga de páginas “pesadas”. Habilitar la compresión gzip supone una carga adicional para el servidor. Se debe decidir si habilitar o no esta función en función de la disponibilidad de los límites de carga de la CPU. Antes de habilitar la compresión gzip, debe verificar con su proveedor de alojamiento si el servidor admite esta función.

A menudo utilizo imágenes y capturas de pantalla en las páginas cuando escribo artículos. Aunque los comprimo al máximo no siempre el peso que sale es el que me gustaría. Tengo habilitada la compresión gzip.

Los resultados de la página principal fueron los siguientes.

Antes de la compresión, el peso de mi página era de 23,7 KB, después de la compresión era de 6,5 KB. El ahorro ascendió al 72,4%. Como dicen - Sin comentarios. El servicio de prueba de compresión gzip se encuentra en esta dirección: http://www.whatsmyip.org/http_compression/.

Además, en un archivo separado en la configuración del script, puede especificar una lista de páginas con prohibición de almacenamiento en caché. Cuando se lanza una nueva versión del script, la actualización es gratuita para todos los clientes.

Al final del artículo, me gustaría subrayar que me gusta el enfoque del autor del guión en sus ventas. Después de pagar por MaxCache, el comprador recibe la versión Lite del script. Esta versión tiene una funcionalidad limitada. Se diferencia de la versión completa en que el caché no se restablece automáticamente. Es decir, la versión simplificada funciona casi igual que la completa. El autor reserva dos semanas de tiempo para realizar pruebas. A continuación, se niega a comprar y el autor le devuelve el dinero o envía una solicitud para obtener la versión completa de MaxCache.

Al comprar este dispositivo, para reducir la carga en el servidor, pedí que me enviaran la versión completa de inmediato, ya que ya conocía el trabajo del script desde hacía mucho tiempo y estaba satisfecho con su trabajo. MaxCache es la solución ideal para un blog de WordPress.

Hola. Después de intentar piratear uno de mis sitios, escribí sobre esto en un artículo, de alguna manera todo estaba tranquilo, la carga en el hosting se volvió normal y no hubo problemas. Pero en un buen momento fui al panel de ihc.ru y abrí la pestaña "Cargar" para ver cómo iban las cosas allí y, para ser honesto, estaba un poco asustado. La carga en la CPU ya había excedido el límite permitido y era solo por la mañana.

Inmediatamente comencé a analizar lo que había estado haciendo en el sitio últimamente, pero resultó que no había cambiado nada. Miré la asistencia, era normal, es decir, no aumentaba y de ninguna manera podía provocar un aumento de la carga, y tan brusco.

Inmediatamente pensé que el alojamiento cerraría mis sitios. En este panel, solo tengo un sitio visitado, aproximadamente 10,000 páginas vistas por día, esto no es poco para un hosting compartido por 400 rublos por mes. Pero la carga siempre estuvo aproximadamente en el medio; si 120 es aceptable en la CPU, entonces tenía 70.

Me senté a escribir una carta al soporte de ihc y le expliqué la situación. La respuesta llegó muy rápido, como siempre. Escribieron que nadie cerraría el sitio por un aumento único en la carga, huuu, me tranquilizaron. También señalaron un sitio que crea una gran carga e indicaron una dirección IP que se comporta de manera muy extraña y realiza muchas solicitudes al sitio. También nos recomendaron analizar el archivo de registro domain_access.log.

Inmediatamente bloqueé la dirección IP que indicaron en el archivo .htaccess en la raíz del sitio. Simplemente agregando la línea deny from **.***.***.** . Y comencé a esperar que todo esto terminara y la carga en el alojamiento disminuyera.

Es solo el fin de semana, me fui de vacaciones. Pero resultó que al día siguiente la carga aumentó aún más. Escribí nuevamente al soporte y me dijeron que necesitaba analizar los registros. Trabajé a través de Internet de tal manera que me resultó difícil descargarlos. Además, ya miré estos registros y no entendí nada allí.

Al día siguiente, ayer, la carga de la CPU en el hosting aumentó aún más, de los 120 permitidos a 300. Y decidí que aún necesitaba comprender estos registros y comencé a mirar el archivo domain_access.log, que descargué a través de FTP desde el hosting. Un archivo tan grande era difícil de entender al abrirlo con el bloc de notas. Aquí mi Notepad ++ favorito fue útil, todo se mostró allí en una nueva línea, en resumen, todo fue como debería ser.

Miré este archivo durante mucho tiempo, muestra la dirección IP, la hora de la solicitud, el tipo de solicitud, etc. Lo miré y lo cerré. Esta mañana me desperté y fui a ver qué pasaba con la carga, ya superaba el límite permitido. Decidí que necesitaba resolverlo. Abrí nuevamente el registro del servidor y comencé a mirarlo detenidamente. Noté varias IP desde las cuales las solicitudes al sitio eran muy activas incluso de noche. Además, en un segundo puede haber más de 10 solicitudes a la misma página del sitio. Y hubo muchas solicitudes de este tipo. Bloqueé todas las IP que me parecían raras en .htaccess.

Esta misma mañana recibí una carta informándome que la carga en el hosting había aumentado durante varios días seguidos. Les respondí, les describí la situación, que había bloqueado la IP y esperaría el resultado. En respuesta, el soporte envió una lista de cinco direcciones IP que, en su opinión, crean una gran carga, nuestros resultados de búsqueda casi coincidieron :).

Después de bloquear esas IP, la carga pareció calmarse. Por la noche, cuando las IP aún no estaban bloqueadas, se notaba la carga, pero este día todo parece estar bien.

Bueno, mañana será posible sacar conclusiones sobre si el bloqueo de estas direcciones IP ayudó o no. Realmente no quiero cambiar la tarifa ahora; hay una prima de 1.000 rublos al mes. Pero con tal carga, incluso esta tarifa puede no ser suficiente. Sin embargo, esperaré hasta mañana y decidiré algo.

En cuanto al host ihc.ru en este asunto, me parece que son geniales. En primer lugar, un sitio con diez mil visitas al día en un alojamiento virtual por 400 rublos al mes, me parece genial. Muchas gracias por su ayuda para resolver problemas de carga y encontrar estas IP.

Casi todos mis sitios funcionan con motores personalizados, pero hasta hace poco uno de ellos todavía funcionaba con el ahora tan extendido WordPress. El hecho es que WordPress se instaló inicialmente debido a la facilidad de uso del panel de administración por parte de la persona que dirige este sitio (no yo). Pero después del lanzamiento de la línea de la versión 2.8, me di cuenta de que este ya no era el caso...

La carga en el hosting ha aumentado significativamente, con un número de visitas, digamos 500-600, Wordpress ya superó tres veces los límites de uso de recursos MySQL, lo que significa que la solución estaba en el caché (bastante hemorrágica, nuevamente en Wordpress ), o al cambiar a otro motor.

Probé la mayoría de los motores de blogs ya preparados en locales y llegué a una conclusión decepcionante:
ninguno de ellos (!), incluso con la importación desde wordpress, podría proporcionar la misma estructura CNC (y más aún en un modo automático e intuitivo), lo que significa que cuando se accede a -> redirecciones 301 y no está claro qué tipo de reacción el PS en términos de posiciones existentes.

Al final, resultó como siempre: miré las fuentes de WordPress, importé datos de una base de datos existente y escribí una pequeña apariencia de un CMS.

Carga: en MySQL disminuyó en promedio 10 veces, en porcentaje 2 veces. Me parece que todavía hay margen de mejora en términos de optimización, pero hay que admitir que incluso esto ya es un resultado indicativo.

La conclusión de esta publicación no es en absoluto que todos deban apresurarse a escribir sus propios scripts (al menos pensar en la protección contra la piratería), sino pensar un par de veces antes de instalar Wordpress como motor de blog, porque entonces puede resultar problemático. para cambiar el CNC y más aún las direcciones de los enlaces existentes (a menos, por supuesto, que sean comprados).

15 comentarios

Buenos pensamientos, pero todos los tienen. Me gustaría leer una posible solución a los problemas con la descarga de la base de datos cambiando los parámetros del motor.

La dirección principal en una optimización significativa de WordPress es el almacenamiento en caché del lado del servidor. Creo que puedes leer esto en muchos otros blogs. Actualmente no tengo ningún sitio web creado en Wordpress y, por lo tanto, no puedo describir la solución a los problemas de optimización.

Siempre decían en línea que VP era fácil y yo lo creía, aunque uso Drupal en mi vida. Luego, en septiembre, conseguí un cliente que deseaba "pasar de este vicepresidente defectuoso a Drupal". Resultó lo siguiente:
1. El sitio se ejecutó en un VPS de 500 Mhz y 384 cuadros.
2. La asistencia es de aproximadamente 1000 visitas por día.
3. Se incluyen todos los cachés imaginables e inconcebibles.
Todo este sistema fallaba constantemente una vez al día y era terriblemente lento el resto del tiempo. Como resultado, comenzó el duro y minucioso proceso de migración a Drupal:
1. Se volvieron a estirar todos los materiales.
2. Donde estaban ordenadas las URL, las dejamos; donde no estaban ordenadas, hicimos nuevas URL, redirecciones 301 a las antiguas.
3. Nos mudamos sin ninguna pérdida. Con la misma funcionalidad, y en algunos lugares incluso más.
Ahora la carga de la CPU del servidor en los momentos más difíciles, cuando llegan Gosha y Yasha, no supera el 30 por ciento, con el almacenamiento en caché deshabilitado.
Entonces, piense en Drupal, no es tan malo como todos dicen.
Aquí está el paciente - surlaterre.ru

No tengo nada en contra de Drupal, es un buen sistema. Mi principal queja es que los motores modernos no tienen un sistema sencillo para pasar de otro CMS manteniendo el antiguo sistema CNC.

Si tomamos la misma transferencia de un VP, entonces el módulo existente se transfiere junto con las URL de VP, pero lo transferí con mi módulo, todo fue un poco diferente para mí.

Si tal o cual módulo es capaz de transferir cualquier tipo de dirección que se pueda crear usando herramientas estándar de Wordpress, honor y alabanza, +1 a Drupal, pero cuando busqué algo como esto entre los motores, no encontré algo, o lo encontré, pero no todo se implementó.

En general, puedo decir: "No hay nada que no sea portátil", si el tema es interesante, bienvenido a ICQ/mail/Skype. Contactos en mi sitio web

No sé cómo configuraste WordPress, el servidor y las cachés. Pero tengo sitios que se ejecutan en WP que tienen 4000 visitantes por día en máquinas virtuales y no hay problemas. Hay sitios con 10.000 visitantes por visita, pero en privado. Allí la carga no supera el 10% en picos. ¡Así que WP todavía es genial!

Actualmente estoy aprendiendo MovableType. A pesar de su naturaleza inusual (usa perl y genera html estático), este CMS es muy liviano y bastante funcional. Mucho más rápido que WP.

MovableType es bueno, pero todavía hay poca información al respecto en ruso.

Personalmente no puedo entender qué tipo de carga hay. Nunca he tenido ningún proyecto importante de WP y no puedo comprobarlo yo mismo. Y no importa dónde lea, no entenderás nada: algunos dicen que las reglas de wp, otros dicen que el motor es una mierda. En general, nunca he visto en ningún lado qué tipo de carga y qué puede soportar wp. Queda una pregunta: ¿por qué entonces wp está en la zona ru en las posiciones de liderazgo? ¿Tal vez debido a su simplicidad?

Ha pasado un período de aproximadamente 30 días, ya no hay problemas en el funcionamiento del sitio y no hay carga alta en el servidor, ya no se observa el procesador. Ahora debería contarles cómo logré hacer frente a la alta carga periódica de WordPress en el procesador y el servidor.

Todo empezó de forma completamente espontánea y cada día la respuesta del servidor era cada vez más larga. Luego, en un momento, apareció la correspondiente notificación crítica en el panel para webmasters de Yandex. En el que se indicó una larga respuesta del servidor en casi 40 - 50 páginas del sitio. Todo está en orden.

Contenido del artículo: Alta carga creada por un sitio de WordPress en la CPU del servidor: los principales síntomas de este problema

En mi sitio, el problema surgió de forma completamente espontánea y en diferentes períodos de tiempo. La carga del 100% en la CPU del servidor fue impulsada por las transiciones entre las páginas del sitio. Alrededor de la segunda página, hubo un fuerte salto en el rendimiento del procesador del servidor. Me gustaría señalar que en este momento la RAM prácticamente no tiene fluctuaciones. Y la cantidad de procesos es completamente insignificante y no debería suponer una carga tan perjudicial para el procesador del servidor.

Los principales signos característicos de carga de trabajo que experimentan muchos webmasters son:

Aumentar el límite de carga de la CPU en el servidor de alojamiento.
WordPress comenzó a crear una carga de CPU inaceptable.
Valores máximos, sobrecarga severa de CPU en el alojamiento.
Respuesta larga del servidor, el valor variable oscila entre 5 y 30 segundos.
La carga excesiva se produce de forma espontánea, en diferentes períodos de tiempo.
El sitio se ralentiza, las páginas apenas se cargan o este proceso lleva mucho tiempo.
El sitio colapsa en niveles máximos.
WP crea una respuesta larga del servidor, el sitio no es estable. Durante los picos de aumento de la CPU, la RAM funciona en su modo estable normal.
La cantidad de procesos afectados y ejecutados durante los períodos de aumento es mínima.
El acceso por lotes de transmisión y las conexiones involucradas en nginx o apache son mínimas.
Esta anomalía ocurre varias veces al día, en diferentes intervalos. Termina tan rápido como empezó.

Esto es exactamente lo que le pasó a mi sitio durante un mes. Un buen ejemplo serían las siguientes imágenes:

Como puede ver, la cantidad de procesos involucrados es mínima. La RAM se mantiene en un valor estable, teniendo en cuenta el navegador abierto y una gran cantidad de páginas. Pero todos los núcleos de la CPU funcionan bajo una carga crítica y al principio es imposible entender el motivo.

¿Qué métodos he probado para combatir la carga crítica en la CPU?

Lo más común es que tuve la culpa de los complementos de WP y de la falta de memoria. Aunque, para ser honesto, el motor utiliza sólo 16 MB de memoria de los 512 MB permitidos que asigné. Lo que realmente probé:

Hice una actualización completa de Debian y luego limpié todo el sistema.
Se eliminó el 99% de las revisiones de bases de datos guardadas en VestaCp.
Revisé los archivos de configuración en VestaCp veinte veces en busca de errores.
Encontré una gran cantidad de registros del sistema en el servidor de correo Exim (completamente eliminados).
Revisé el sitio en busca de virus (no hay ninguno).
Rastreé el sitio y verifiqué la velocidad de la conexión a Internet.
En el sitio, desactivé el guardado de revisiones de registros; no hice nada más en el sitio. El sitio está optimizado en un 98% por lo que es recomendable visitarlo.

Después de todas las medidas tomadas, el problema no se resolvió. Durante el mes continuaron los aumentos repentinos y las cargas críticas máximas de WP en el procesador del servidor.

¿Cuál fue exactamente el problema de la carga excesiva de WP en la CPU y cómo lo resolví?

El problema fue un error de WP Cron. Hace unos cuatro meses instalé un complemento que impide que el motor, los temas y los complementos se actualicen. La primera llamada, según tengo entendido, fueron errores en los registros del servidor del sitio dirigidos a wp-cron.php. El error estaba en la asignación de memoria para el proceso, o más bien memoria insuficiente. Cuando recordé esta situación, inmediatamente lo noté.

Lo que me ayudó:

Instalé el complemento WP Crontrol: programador de tareas cron WP. Te aconsejo que lo instales inmediatamente, muy buena solución.
Después de la instalación, vi una carga máxima de aproximadamente 900 eventos idénticos que, según tengo entendido, se relacionan con imágenes.

La solución más sencilla es restablecer todos los eventos cron de wp a su estado original, esto se hace en funciones.php. Simplemente insértelo al principio del archivo debajo

Popular en la categoría: