Después de actualizar a 4.3, nuestra carga de CPU comenzó a aumentar lentamente y al día siguiente era 9.0 cuando solo teníamos 2 núcleos e idealmente se mantiene alrededor de 1.9. Deshabilitamos los complementos que usaban más potencia de CPU y se detuvo por un tiempo, pero al día siguiente pasó a 10.0 nuevamente y las cosas empeoraron, el zócalo php-fmp expiró y nuestro sitio se volvió muy lento. Cambiamos a 4 núcleos y las cosas fueron normales durante unos días. Volvieron a pasar las mismas cosas y fue realmente molesto. Finalmente, aplicamos la corrección de errores de WordPress de alta CPU y las cosas volvieron a la normalidad.
Esto es lo que nos sucedió debido a este error de WordPress con alta carga de CPU:
Creíamos en la comunidad de WordPress para las actualizaciones básicas de WordPress y sufrimos mucho, y muchos más todavía lo hacen. Este artículo fue escrito para alertar a todos los bloggers de WordPress sobre este error fatal de WordPress con alta carga de CPU y llevarlos a un «Hot Fix». He visto gente llorar en los foros porque su servidor fue estafado.
Por eso sucedió –
https://core.trac.wordpress.org/changeset/33646/trunk/src/wp-includes/taxonomy.php
El autor «dd32» invirtió el argumento al corregir el término rutina dividida en las nuevas instalaciones y lo arruinó. Los argumentos opuestos a la. Han sido entregadas wp_schedule_single_event() causó entradas no válidas en el sistema WP Cron.
La pregunta es, ¿por qué no se ha realizado la revisión del código o por qué el código de WordPress está en línea sin pruebas ni revisiones de código? Bueno, Dios nos salve la próxima vez que actualicemos WordPress. De todos modos, aquí está el «Hot Fix» de Samuel Wood (Otto)por los que aún sufren. Asegúrese de poner su sitio web en mantenimiento y aplique estos cambios para corregir el error de carga alta de CPU de WordPress.
Etapa 1. Resuelve el problema real aplicando parte del parche de este ticket. Es de una sola línea. Abra el archivo wp-includes/taxonomy.php y vaya a la línea 4448. Aquí está esa línea:
wp_schedule_single_event( 'wp_batch_split_terms', time() + MINUTE_IN_SECONDS );El problema es que los argumentos están invertidos. Cámbialos de la siguiente manera:
wp_schedule_single_event( time() + MINUTE_IN_SECONDS, 'wp_batch_split_terms' );Esto soluciona el problema subyacente, pero no detiene la carga. Para hacer esto, creamos un complemento mu temporal.
2do paso Vaya a su directorio /wp-content. Cree un subdirectorio llamado «mu-plugins» en /wp-content/mu-plugins. El nombre del directorio es importante. Si ya tienes este directorio, adelante.
Los complementos de MU son «para usar». Todos los archivos PHP en este directorio son integrados automáticamente por WordPress. Es una forma conveniente de ejecutar código en su instancia de WordPress sin tener que ir a la página de complementos para activarlos.
Cree un nuevo archivo llamado «fix.php» o algo así, el nombre no importa. Aquí está el contenido de este archivo:
<?php
function clear_bad_cron_entries() {
// Fix incorrect cron entries for term splitting
$cron_array = _get_cron_array();
if ( isset( $cron_array['wp_batch_split_terms'] ) ) {
unset( $cron_array['wp_batch_split_terms'] );
_set_cron_array( $cron_array );
}
}
clear_bad_cron_entries();Es el mismo código en 4.3.1 para solucionar el problema y lo necesitará para ejecutarlo. Pegue este código en el archivo fix.php y guárdelo.
Ahora navegue a su sitio web. El problema debería desaparecer en breve. Una vez que lo haga, puede eliminar el archivo fix.php. Solo debe ejecutarse una vez, no cada vez que se carga su sitio.
Si está utilizando varios sitios, debe cargar cada sitio al menos una vez para que este código se ejecute en cada uno. Los trabajos cron se almacenan por sitio, no por instancia.
Para obtener más información, siga este hilo: https://wordpress.org/support/topic/high-cpu-load-after-update-to-v43. Para obtener más información sobre los desastres 4.3, consulte https://wordpress.org/support/topic/read-this-first-%E2%80%93-wordpress-43-master-list?replies=3&view=all.
Espero que esto ayude a alguien que todavía tiene problemas con la alta carga de CPU de WordPress después de migrar a WordPress 4.3. Por favor háznoslo saber en los comentarios más abajo.
Lea nuestra historia: Un año de fossBytes: ayer, hoy y mañana
