Tengo un par de servidores que alojan un solo sitio de comercio electrónico de Magento con tráfico moderado (60,000 páginas vistas por día reportadas por Google Analytics, creo que 80,000 reportadas en el servidor). El servidor de la base de datos funciona sin problemas y rápidamente, aparte de un raro inconveniente ocasional, pero el servidor Apache se ha estado cayendo de vez en cuando.
He configurado magento para usar el almacenamiento en caché PHP recomendado (APC), así como mantener sus propios archivos de caché en un tmpfs de 1.5 gig (este tmpfs regularmente se llena bastante, y tengo un script ejecutándose para borrar los archivos de caché cuando el tmpfs es más del 80% lleno). Sirvo la mayoría de las imágenes de Amazon Cloudfront. Recientemente configuré nginx como proxy inverso de apache (nginx también sirve los archivos estáticos). He configurado Apache lo mejor que he podido: keepalives y hostnamelookups están apagados, y el prefork está configurado de la siguiente manera:
<IfModule prefork.c>
StartServers 50
MinSpareServers 50
MaxSpareServers 100
ServerLimit 512
MaxClients 256
MaxRequestsPerChild 400
</IfModule>
No he desactivado los archivos .htaccess, y el registro de acceso está activado. Sé que hay algunos módulos que puedo desactivar. No estoy seguro de qué efecto tendría alguno de esos tres cambios, si lo hubiera.
El servidor apache es un VPS con 6 gig de RAM. Al momento de escribir esto, el servidor está informando load average: 17.77, 18.27, 49.76, pero hay aproximadamente 2 gig de RAM libre. Cuando se pone realmente mal, la carga se eleva a más de 120 y permanece allí: al reiniciar Apache, el sitio vuelve a funcionar y la carga vuelve a caer.
vmstates (mientras el servidor informa la carga anterior), creo que muestra un valor inactivo de la CPU que fluctúa entre 0 y 70 más o menos. iostatmuestra un valor de iowait entre 0 y 0.2%.
Estoy un poco atascado. Lo poco que sé es que me dice que el problema es que la CPU está sobrecargada como resultado de la combinación del código que se está ejecutando y la cantidad de usuarios. Pero no tengo suficiente experiencia para estar seguro de que ese es el problema. Si ese es el problema, creo que las soluciones son mejorar el código o dividir el alojamiento del sitio en dos VPS con un equilibrador de carga.
Entonces, supongo que mis preguntas son:
- ¿Qué más puedo hacer para encontrar problemas o cuellos de botella en el servidor?
- ¿Hay algún cambio obvio que pueda hacer en la configuración del servidor para mejorar esto?
- ¿Es una buena idea configurar un sistema automatizado para reiniciar Apache cuando la carga supera un cierto nivel?
- De lo anterior, ¿qué tan probable es que el sitio haya superado al servidor?
Editar:
Encontré algo extraño: / var / spool / mail / root era grande ... 38 conciertos. Eso suena ... poco saludable. ¿Podría ser el problema?
fuente
Respuestas:
Magento y Zend Framework son bastante pesados para la CPU, como habrás notado. La mejor manera de evitar la carga de la CPU es simplemente renderizando cualquier contenido solo una vez, hasta que cambie. La mayoría de las partes de su catálogo no cambian tan a menudo, y a menudo solo el bloque del carrito de compras en su página, o el bloque de "artículos más populares" son las únicas partes dinámicas.
Sugeriría poner un caché de barniz frente a Apache. Esto le proporciona almacenamiento en caché de páginas de alto rendimiento que puede descargar seriamente su pila LAMP. Recientemente sobrevivimos a un lanzamiento muy público de un sitio web gracias a Varnish y me impresionó seriamente la velocidad y la baja carga de la CPU. El barniz es gratuito y lo suficientemente flexible como para almacenar en caché páginas enteras, o almacenar en caché solo las partes relativamente estáticas e incluir el carrito de forma dinámica.
Sin embargo, Varnish no almacenará mucho en caché en una instalación predeterminada de Magento, ya que hay mucho contenido dinámico por usuario, cookies, etc. Un módulo de Magento como ' PageCache con tecnología de Varnish ' modifica Magento para que funcione bien con Varnish. También proporciona un archivo de configuración de Varnish que coincide con la configuración de Magento. Estos dos juntos hacen una configuración muy eficiente. Es un módulo comercial, pero mucho más asequible que un servidor más potente.
Las partes que estás descargando a un CDN o Nginx no son tu verdadero problema, aunque sí ayudan. Incluso Apache puede manejar una gran cantidad de solicitudes estáticas. Necesita almacenar en caché las cosas que requieren esfuerzo generar una y otra vez, es decir, sus partes dinámicas.
fuente
Normalmente configuro el MaxRequestsPerChild para que esté en los miles, generalmente, más cerca de 10,000.
Usted dice que tiene "el almacenamiento en caché PHP recomendado", pero ¿tiene instalado APC? Finalmente, ¿cuántos usuarios ves golpeando el sitio web al mismo tiempo? Si tiene estadísticas extendidas de Apache, podrá ver cuántos de los procesos de Apache están realmente en el estado Ejecutando a la vez.
800 visitas a archivos APC por segundo, y otros 200 usuarios de caché son muchos. Sin embargo, si se trata de un núcleo doble o cuádruple, espero que se mantenga bien. Si la base de datos está realmente al día, entonces obtener una máquina más grande y más CPU puede ser lo mejor para ella, al menos en este momento.
fuente
Su carga promedio es demasiado alta para un VPS de doble núcleo. 8 debe ser el máximo.
He tenido mucho éxito con el uso de mod_pagespeed y MPM de eventos para Magento. Recomendaría cambiar a usar MPM de eventos e instalar mod_pagespeed.
Más información sobre Event MPM: documentación de Apache Event MPM
Y mod_pagespeed: Código de Google: mod_pagespeed
Si continúa teniendo problemas de carga incluso después de realizar los cambios anteriores, puede considerar cambiar a un plan VPS mejor y diferente.
fuente
Como sugiere Alister, un valor MaxRequestsPerChild de 400 es absurdamente bajo.
El promedio de carga es muy alto, pero 60k visitas a la página por día no es mucho tráfico.
¿Cuántos procesos tiene normalmente solicitudes de servicio?
No estoy familiarizado con Magento, pero parece que hay algo mal con esta configuración. Esperaría que pudiera obtener un rendimiento significativamente mayor a un nivel de carga más bajo.
Ve a buscar una copia del libro de Steve Souders y léelo. Habilite la compresión de todo el contenido HTML saliente (estático y dinámico). Y asegúrese de tener una buena configuración de almacenamiento en caché. Comience a registrar% D en su archivo access_log y cree algunas herramientas para analizar los datos / aislar la lentitud. Similar para MySQL.
Pruebe mysqltuner.pl y vea si detecta algún problema.
fuente
Ejecuto una configuración similar, pero con nginx / php-fpm / apc (opcode y fast_backend / memcached (slow_backend). Creo que php es el mayor problema de recursos, probablemente porque magento es increíblemente grande o está mal codificado. mira qué es exactamente lo que está comiendo los recursos, ¿podría ser php como en mi caso?
Además de lo que escribe Martijn Heemels, hay un módulo de barniz de código abierto que puedes probar. Visita http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ y https://github.com/madalinoprea/magneto-varnish .
Solo lo he probado en un entorno de prueba, y hasta ahora tan bueno.
¿Guarda las sesiones en la base de datos o en el disco (y si es así, en tmpfs)?
fuente
Cuando usa VPS, está compartiendo la CPU. Te recomendaría hablar con tu host para mover tu VPS a un hardware menos ocupado o dedicarte.
Debido a la CPU compartida, sus aplicaciones no pueden ejecutarse a tiempo y siguen en cola acumulando solicitudes más altas para ser procesadas y también los gastos generales que vienen con ella. Eventualmente, existe una condición en la que Apache o php o mysql habrían maximizado sus propios límites y eso causa problemas.
En resumen es. VPS es básicamente una CPU compartida. Su host puede estar poniendo demasiadas cuentas VPS en la misma CPU.
Si desea hacer un uso completo de la CPU asignada, solicite un servidor mejor con menos VPS si es posible (mover el host aunque sea problemático) o dedicarse.
También puede elegir Amazon por completo y no preocuparse por nginx utilizando su equilibrador de carga, que son unos pocos clics para configurar todos sus servidores en su nube.
la carpeta /var/mail.../root es hue significa que está recolectando una gran cantidad de correos electrónicos que generalmente provienen de sus aplicaciones. Por ejemplo, un script php con errores intenta enviar un correo electrónico o todos los trabajos cron están configurados para enviarle por correo electrónico el estado de las ejecuciones cron y la salida. Puede mirar dentro del correo y ver qué tiene el archivo. Estoy adivinando sus mensajes de error para que pueda encontrar de dónde viene.
Agregaré más si necesita más información y es posible que también necesite información.
fuente