Estamos teniendo problemas con nuestro servidor rackspace wordpress que se cae con un tráfico medio después de enviar un correo electrónico.
Las especificaciones del servidor son:
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
Correr:
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
La instalación es bastante estándar, hasta donde yo sé, y la base de datos es bastante estándar, indexada y bastante pequeña. También estamos almacenando en caché objetos de WordPress.
Según Nueva Reliquia; Durante el tráfico normal, el sitio pasa aproximadamente el 80% del tiempo en PHP, el 15% del tiempo en web externa y sólo un pequeño porcentaje en la base de datos. El tiempo promedio de aplicación de página estándar es de alrededor de 800 ms, lo que me parece lento.
Ejecutar una prueba de carga de 250 conexiones en 1 minuto hace que las conexiones tomen progresivamente más tiempo y luego comiencen a agotarse después de aproximadamente 30, y el servidor deje de responder (incluso cuando el tráfico vuelve a disminuir). Requiere un reinicio completo para volver a estar activo.
No puedo conectarme usando PuTTY y la página de inicio oscila entre el tiempo de espera y la devolución del temido "Error al establecer la conexión a la base de datos".
Al utilizar el agente de monitoreo de rackspace en la prueba más reciente, parece que la CPU está alcanzando un máximo del 100 % justo antes de morir, la memoria utilizada alcanza un máximo de aproximadamente 1,6 GB con una caída libre a aproximadamente 100 MB. Parece que también se están utilizando unos 2 GB de memoria intercambiable (4 GB en total). El uso estándar parece ser aproximadamente un 15% de CPU, 800 MB de memoria y 400 MB de intercambio.
Nuestra configuración de Apache no establece ninguno de los siguientes (no hay archivos en /etcdo); Tiempo de espera, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; entonces supongo que está usando los valores predeterminados.
He mirado la configuración de mariadb:
innodb_buffer_pool_size = 1400M
max_user_connections = 0
Lo cual no parece ser la causa.
También activé performance_schema, pero realmente no sé lo que estoy buscando. Ni siquiera estoy seguro de que la base de datos sea el problema.
Me siento tentado a actualizar la instancia, pero prefiero tener una visión más clara de dónde está el cuello de botella y qué está provocando que el servidor muera en lugar de simplemente ralentizarse.
¿Alguna idea sobre por dónde empezar? Parece que hay muchos ajustes posibles y mucha información.
Respuesta1
Es fundamental realizar un seguimiento estrecho durante cualquier tipo de evento. Como vemos, la verdad salió a la luz:
Al utilizar el agente de monitoreo de rackspace en la prueba más reciente, parece que la CPU está alcanzando un máximo del 100 % justo antes de morir, la memoria utilizada alcanza un máximo de aproximadamente 1,6 GB con una caída libre a aproximadamente 100 MB. Parece que también se están utilizando unos 2 GB de memoria intercambiable (4 GB en total). El uso estándar parece ser aproximadamente un 15% de CPU, 800 MB de memoria y 400 MB de intercambio.
Se sabe que PHP consume bastante CPU. Ha utilizado toda la CPU disponible y casi toda la RAM disponible.
Primero debe tomar medidas para solucionarlo, como el almacenamiento en caché de código de operación (por ejemplo, Zend OPcache) y el almacenamiento en caché de archivos (por ejemplo, el complemento W3 Total Cache de WordPress). Si eso no ayudasuficiente, entonces es hora de actualizar la instancia.
Respuesta2
Probablemente esté ejecutando demasiados procesos a la vez, quedándose sin memoria y realizando intercambios. Puede ser que algo más se esté bloqueando, pero solucione esto primero y luego vea dónde se encuentra.
No nos has dicho si estás usando mod_php o algo como php-fpm. Este último maneja mejor la carga, pero en cualquier caso asegúrese de no ejecutar más procesos php de los que tiene memoria. Probablemente no obtendrá ningún beneficio de rendimiento al ejecutar más de 5 o 10 procesos, pero la ejecución predeterminada de mod_php en particular ejecutará mucho más de lo que tiene memoria. Además, recicle los procesos cada aproximadamente 30 solicitudes. Si le da 1 GB a su base de datos y sistema operativo, entonces su otro GB probablemente no manejará 10 procesos de WordPress. Mira cuánta memoria toman y resuélvela, con un poco de autorización. No deberías utilizar ningún swap en el curso normal de las cosas.
Mire su configuración de mantenimiento de vida. Con Apache probablemente sea mejor apagarlo o configurarlo en 1 segundo. Nginx maneja el mantenimiento de vida mucho mejor. De hecho, esta es la única razón realmente importante por la que es probable que nginx funcione mejor con una aplicación php como WordPress (aunque tiene el costo de una configuración menos agradable). Es muy probable que esto no sea un factor en sus pruebas, pero es importante con los navegadores reales.
100% CPU me sorprende. Utilice la parte superior para ver qué lo está usando. Recuerde también que 100% suele significar el 100% de un núcleo. Es posible que estés viendo que se activa un trabajo cron, que en WordPress generalmente no es "cron" como tal, sino que los trabajos se ejecutan como extra mientras se procesan las solicitudes web. La falta de almacenamiento en caché del código de operación también podría estar provocando un uso elevado de la CPU.