Diagnóstico de conexión MySQL y lentitud del servidor

Diagnóstico de conexión MySQL

Este caso comenzó con un error alarmante: Aborted connection 321 to db: 'wp_hostalhost' user: 'root'. Al revisar los registros, también descubrimos que el servicio Apache se cerraba inesperadamente con un error de «Función incorrecta».

Parecía una combinación de ataques o fallos críticos en la base de datos. Sin embargo, decidimos tomar una medida drástica: copiamos todo el directorio XAMPP a una máquina más potente y redirigimos los puertos 80 y 443 hacia ella.

El salto de hardware

La nueva máquina no solo tenía más recursos, sino un procesador completamente diferente. La comparación entre las dos plataformas es reveladora:

Pasar de un procesador básico a uno con diez núcleos cambió el entorno por completo. El uso de CPU bajó del 100% al fluctuar entre el 15 y el 17%, lo cual ya era una mejora operativa importante.

¿Por qué sigue siendo lento?

A pesar del nuevo hardware, al navegar por la web local notamos que las páginas tardaban varios segundos. Lanzamos comandos en consola para medir los tiempos de respuesta usando curl.exe. Los resultados fueron reveladores: el acceso directo a Apache local respondía en menos de un milisegundo, pero el tráfico externo por HTTPS tardaba más de 26 segundos.

Inicialmente pensamos que era un problema del router o del NAT loopback. Añadimos una entrada al archivo hosts para evitar ese recorrido innecesario y comentamos algunas etiquetas HTML en el contenido.

El verdadero culpable

Al revisar los procesos de MySQL, notamos algo sorprendente: antes de comentar esas etiquetas, había ocho procesos apareciendo y desapareciendo constantemente. Después de la optimización, ese número cayó a dos o cero. El consumo de CPU de MySQL bajó del 15% al 2,2%.

La conclusión es clara: el problema no era el hardware ni la red, sino nuestro propio blog. Los indexadores estaban descubriendo miles de enlaces temáticos adicionales que habíamos creado, y cada página de etiqueta generaba consultas pesadas a la base de datos.

Al comentar ese contenido específico, eliminamos la carga innecesaria del servidor. El i5-12600K puso los músculos, pero fue la reducción de trabajo innecesario lo que realmente resolvió el cuello de botella.