Cómo saber si tu servidor (compartido) está saturado
Publicado el Sábado 28 de Abril del 2007 @ 23:16 por Armonth.
A menudo los que usamos un servidor compartido tenemos un problema de fondo: si la compañía de hosting abusa a la hora de “apiñar” gente en una misma máquina a la larga acabará saturada.
Otro problema de usar servidores compartidos es que si bien los planes para controlar el consumo pueden ser “razonables” siempre puede aparecer un usuario que por desconocimiento (o malicia…) sature el servidor con algún script mal optimizado o algo similar.
En general yo puedo decir que con Dreamhost aunque esté en un compartido estoy muy contento, sé que a algunas personas no les ha ido bien pero a la mayoría que conozco no les ha dado ningún problema.
El caso es que normalmente los servidores ocultan los procesos ejecutándose actualmente que no son tuyos (los procesos se pueden ver con — por ejemplo — el comando ps -ax). Esto aparte de ser una medida de seguridad es una comodidad: es de locos buscar entre cientos de procesos los tuyos (aunque bien es cierto que siempre podríamos usar top + u para ver sólo los de un usuario).
Vamos a ver las formas más habituales de mirar la saturación de una máquina, principalmente en GNU/Linux.
A nivel de CPU
Una forma interesante de ver la carga de tu servidor es con uptime un “clásico” de los comandos que ya de paso te dice el tiempo que la máquina lleva encendida, veamos el de mi servidor:
11:27:21 up 43 days, 22:39, 6 users, load average: 5.61, 5.39, 5.25
Cabe aclarar que la “carga de tu servidor” no es el % de CPU usándose en ese momento, si no el número de procesos en la cola de procesos listos para ejecutar.
Según ese uptime lleva 43 días, 22 horas y 39 segundos online. Los valores son en el último minuto 5.61 de carga, en los últimos 5 minutos 5.39 y en los últimos 15 minutos 5.25.
Podemos decir que una carga de 0 a 4 es razonable, de 4 a 6 moderada y 6 o más es alta. También hay que aclarar que son valores totales o al menos creo que en GNU/Linux y BSD es así (tengo entendido que en algunos Unix varía) por lo que si tenemos más de una CPU hay que dividir la carga por el número de procesadores.
Ahí también tengo la duda de que si eso incluye los DualCore ya que son 1 microprocesador con doble núcleo, al menos la máquina donde estoy alojado en Dreamhost es un AMD Opteron (Dual Core) por lo que en teoría la carga sería 5.61 / 2 = 2.80.
La forma de ver la CPU es leyendo el fichero /proc/cpuinfo por ejemplo con cat /proc/cpuinfo y nos saldrá el número de microprocesadores que “encuentra” con toda la información, si es un microprocesador simple pues saldrá información de un microprocesador, si es DualCore o un Pentium 4 con HyperThreading saldrán dos (y seguramente idénticos) o más si ya hablamos de algo más potente.
Apuntes sacados a Ricardo Galli: depende del tipo de carga, si es por muchas aperturas de sockets aguanta mucho más que por E/S. El Apache cuando se sobrecarga genera cargas muy altas por la cantidad de cambios de contexto que genera.
Varía en lo que hace, si tienes 200 de carga (un valor aparentemente alto) y Apache sólo sirve ficheros estáticos, aguantará bien aunque sea alto, si es dinámico y BBDD estará hecho una mierda.
El Load average de por sí no sirve para saber si “está bien”, es sólo orientativo, hay que mirar otras cosas, por ejemplo el tiempo de espera (wait) y el uso real de la CPU, ambas se pueden ver en el top o en el vmstat.
Valores altos de waits significa que se está perdiendo mucho tiempo esperando por E/S, por ejemplo una bbdd mal diseñada o sobrecargada y el wait hace subir exponencialmente los procesos apaches, que a su vez hacen subir la carga.
A nivel de memoria (RAM)
Está es fácil: con “free” aunque mejor todavía ejecutar free -m para verlo en megabytes. Aquí lo único que hay que tener en cuenta es que no hay que mirar la memoria libre.
GNU/Linux (y supongo que el resto de Unix más o menos igual) usan toda la memoria RAM posible y mantienen datos “en cache”, por ejemplo si abrimos un programa y lo cerramos se mantendrá en memoria RAM “cacheado” y si lo vuelves a abrir en lugar de volver a acceder al disco duro lo abrirá desde RAM.
Si una aplicación de repente necesita más RAM de la disponible pues el sistema liberará la memoria usada para datos cacheados “por si se vuelven a usar” y llegado a cierto punto empezará a “raspar” memoria SWAP (memoria de intercambio) es decir usará una una partición o un fichero del disco duro como si fuera más memoria RAM.
La forma correcta de ver la memoria es viendo el valor buffers/cache, un ejemplo en mi máquina (PC de trabajo):
total used free shared buffers cached
Mem: 504 494 9 0 12 313
-/+ buffers/cache: 169 335
Swap: 0 0 0
Medio GB de RAM, se ha usado casi todo pero 313MB están cacheados, “en uso” realmente están 169.
En el caso de la máquina de Dreamhost obviamente está bastante más cargada, 4GB de ellos 2GB cacheados, 1.6GB en buffers y 170MB libres (y raspa de swap pero no mucho: máximo 500MB).
Escrituras I/O a dispositivos
El mayor cuello de botella en un PC doméstico para acceder a Internet suele ser la conexión y la tarjeta ethernet pero para ejecutar aplicaciones la lectura a disco, en un servidor no es tan raro que debido a algunas operaciones (aún estando bien de CPU, RAM y ancho de banda) el rendimiento caiga por tener que esperar a operaciones de I/O (input/output) o en cristiano: esperar para poder acceder al dispositivo, en este caso el disco duro.
Para ello tenemos iostat (forma parte del paquete “sysstat” en Debian/Gentoo) que nos da mucha información:
avg-cpu: %user %nice %sys %iowait %idle
56.75 1.25 10.80 0.00 31.21
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 15.99 43.91 314.65 167088814 1197432548
sda1 0.43 6.40 1.14 24337978 4331616
sda3 12.30 35.72 244.97 135949674 932259906
sda5 0.08 1.63 1.79 6185976 6803424
sda6 0.00 0.00 0.00 8 0
sda7 0.00 0.00 0.00 8 0
sda8 3.18 0.16 66.75 615130 254037602
Los datos ordenados por dispositivos, sinceramente y con todas las palabras no tengo ni puta idea de qué significan (o mejor dicho: qué valores son normales), pero lo interesante es la parte avg-cpu: nos dice el % de CPU usado en procesos en espacio de aplicación (%user), en espacio de aplicación pero con valores “nice” para darles mayor o menor prioridad (%nice), en espacio de kernel (%sys) y los que nos interesan:
- %iowait: porcentaje de procesos que están esperando a una operación I/O, cuanto más bajo mejor, si es un valor alto continuamente (que pase esporádicamente es normal sobretodo con los picos de tráfico) tenemos un cuello de botella ahí: toca meter otro disco duro más rápido, un segundo disco duro o incluso una máquina adicional para hacer balanceo de carga.
- %idle: el % de la CPU que está en espera por una razón que no tenga que ver con exceso de peticiones I/O. Tener un porcentaje alto de idle no es malo ya que habitualmente significa “CPU libre”, por ejemplo mi CPU ahora mismo marca un 90% Idle.
Cualquier cosa a añadir/mejorar, correcciones, dudas y demás comentarios como siempre son bien recibidos. Por otro lado este artículo bien se podría haber llamado “Cómo saber si una máquina con GNU/Linux está saturada… y dónde están sus cuellos de botella” o incluso más génerico, que muchos Unix tienen comandos iguales o similares.
PD: Si tu hosting es tan receloso que ni siquiera te permite ver datos tan inocuos pero interesantes como los devueltos por /proc/cpuinfo, free, iostat, etcétera, mejor cambiate de hosting ;).
19 Comentarios (feed)
-
Rarok nos comenta:
Creo que un día de estos voy a tener que leerme una buena guía para aprender a manejarme con una linea de comandos. Por cierto, muy útil esta mini-guia para poder saber lo saturados que están nuestros hostings.
-
Juan nos comenta:
Por mi experiencia en Dreamhost (larga y de varias cuentas) pude comprobar que tu estadía con ellos depende mucho de en que servidor te tiren. Algunos son un lujo, van bárbaro y pocas veces se caen, y hay otros que no pasan la semana de uptime sin tener algún problema.
Y aparte hay que tener en cuenta otra cosa (siempre hablando de DH): Por más que estés en un servidor web específico, tus mails están en otro y las bases de datos en otro (y no se si los archivos en varios más), por lo que el rendimiento de tu hosting va a depender del buen funcionamiento (y no-stauracion) de tres o más servidores, lo que aumenta la probabilidad de fallas.
-
Rarok nos comenta:
Pues yo pensaba que el estar los servicios en distintos servidores era mejor (excepto a la hora de configurar alguna página que no sirve con ponerle localhost como dirección de la base de datos XD) porque si tienen un servidor para archivos, otro para bases de datos… lo lógico sería que cada uno esté optimizado para su función en concreto tanto en hardware (los de DB con mas CPU y RAM, los de archivos con buenos discos duros…) como en software, ya que si un servidor solo hace una cosa solo tendrá que tener un par de programas y por tanto cualquir problema debería ser mucho mas fácil de solucionar.
-
Armonth nos comenta:
Rarok y es correcto, a lo que Juan se refiere es que si una máquina está saturada pues la web se resiente por lo que si tenemos 3 máquinas (web, mysql y ficheros) las posibilidades de que nos toque una saturada aumentan, obviamente si hablamos de 3 máquinas NO compartidas pues es la hostia en verso…
-
Jordi Planas Manzano nos comenta:
Soy un novato en esto y tengo contratado hosting en varios sitios, entre ellos site5.
¿Qué tengo que hacer para poder introducir los comando que dices?
Gracias de antemano por la ayuda. -
David Villarreal nos comenta:
Muy práctico
El problema que yo veo en Dreamhost son la cantidad de microcortes que se producen y algunos cortes largos tambien que a veces duran horas, aunque estos se producen rara vez
-
Armonth nos comenta:
Jordi: manual de ssh (conexión remota a un interprete de comandos) + manual de bash (interprete de comandos). Es la forma más habitual de administrar un servidor…
-
ricardo galli nos comenta:
armonth, desde mi punto de vista la mejor forma de ver la carga de un servidor es el vmstat.
-
Armonth nos comenta:
Ricardo pero para ver cuellos de botella por I/O hay que lidiar con los block-out y los block-input y es un poco lío, no sé tú pero yo veo más fácil saber que % de procesos están parados por I/O (%iowait) con iostat :)
-
Manuchis nos comenta:
Muy buen artículo, hace unas semanas que tarda en cargar mi pagina en Dreamhost. Hice el uptime y el ultimo valor que me dió es de 9,41… bastante mal… y eso que ninguna de las páginas tienen mucho tráfico continuo.
hay alguna forma de solventar esto? -
Armonth nos comenta:
Manuchis si la web es de la firma no creo que sea del servidor: la página carga bien pero el blog no…
El HTML no llega a tardar ni dos segundos en descargar, mirate este enlace sobre Octate y usa esa herramienta para comprobar que se lleva más tiempo.
Principales problemas:
1. El Javascript se le nota que ralentiza un poco (lo he deshabilitado y tal) pero eso no es nada.
2. Las imágenes son tu problema: muchas y además hasta que no son descargadas no acaba de cargar la hoja de estilo (esto no es el comportamiento estándar esperado)PD: Estás haciendo _hot-linking_ de algunas imágenes de fuera, eso crea problemas de seguridad, tráfico a terceras personas y aumenta el tiempo de carga…
Erm… lo RETIRO, al menos en parte, el problema son las imágenes pero fijo, ¡pedazo animal! (esto dicho con coña) que ¡¡¡son imágenes de 1.350KB!!! ¡en cinco fotos tienes 3 o 4 megabytes!. Una imagen de 450×350 (usas la misma resolución que yo) debería quedarse en 20-50kB pero tú en su lugar has pillado la fotografía original a 2048×1536 (o similar).
Hay varias de esas, pero también las hay (por ejemplo en al entrada “Pancho Chino”) de 200kB, te toca pillar todas las imágenes y bajarles la resolución de verdad + usar WP-Cache si no lo usas y ya veras que bien…
-
Manuchis nos comenta:
jeje, si, es posible, pero no es la unica web, no es uqe tarde, en eso estoy deacuerdo, es muy pesada, pero bueno ya lo veré.
pero el gran problema es que todas ms paginas a veces se trabaan y no cargan siquiera el doctype, se ve que el pedido en el servidor a veces queda un poco trabado, no se, si pero no sucede siempre sino aleatoriamente. si quieres te paso una lista como para que veas, pero no quiere decir que no te carguen cuando lo pruebes, si no que a veces no carga, en 24×7 me marca timeout como 5 veces por dia, eso no es normal. Fijate en www.franjafadu.com.ar que tampoco uso mucha imagen, pero se cuelga… -
Nicolás nos comenta:
Sin dudas hay varios truquitos que entre todos ayudan a mejorar el rendimiento del servidor. Yo recomiendo usar Phpsuexec. php se ejecuta como un script de usuario y no como un nobody. Así si algún sitio causa problemas no afecta a los demás alojado en el mismo servidor.
-
Armonth nos comenta:
Nicolás en todo caso PHP as CGI + FastCGI para controlar carga, que el PHPsuexec lo único que hace es lanzar el PHP como un programa (igualito que un CGI) pero con FastCGI se mantiene en memoría y no consume un huevo en cada petición… es casi como tenerlo como módulo de Apache.
Manuchis las imágenes hacen que una vez empieza a cargar la página vaya lenta, si se queda trabado (a veces me pasa) tiene pinta de ser por intentar acceder a MySQL… hazme caso y empieza por usar WP-Cache, es un imprescindible con WordPress independientemente de que vaya bien o mal…
Haz tres cosas:
1. Pega por aquí el contenido de logs/resources/tu-usuario.analized.0 o similar y veremos qué te está consumiendo…
2. Luego ve poniendo el WP-Cache. Repito que independientemente de que vaya bien o mal es un imprescindible (ayuda y mucho).
3. Reduce las imágenes, tus usuarios te lo agradecerán.
Con esas tres cosas (sobretodo 1 y 2) ya luego seguimos :)
-
Manuchis nos comenta:
bueno, he instalado wp-cache, yo antes lo usaba pero luego de repetidos post sobre la inseguridad de tal plugin lo he sacado y nunca volvi a pensar en el ;)
por otro lado, los logs que me da dreamhost son un o de accesos y otro de errores, a esos te refieres?gracias nuevamente.
-
Armonth nos comenta:
¿Repetidos post sobre la inseguridad? Que yo recuerde bugs de seguridad en WP-Cache ha habido más bien pocos (al menos anunciados) lo que sí hubo fue parches para añadirle funcionalidad que rompieron un par de cosas (y arreglados). Vamos el único que me suena es un XSS que anunció Alex (Buayacorp) y que se corrigió.
Sobre los logs me refiero al fichero logs/resources/tu-usuario.sa.analyzed.0 el cual contiene el tiempo de CPU gastado por cada proceso en segundos.
-
Manuchis nos comenta:
Process CPU seconds user machine count average
php5.cgi 158.1300 99.994% 0.659% 869 0.182
bash 0.0100 0.006% 0.000% 2 0.005
sendmail 0.0000 0.000% 0.000% 1 0.000
bash 0.0000 0.000% 0.000% 1 0.000
iostat 0.0000 0.000% 0.000% 1 0.000
cat 0.0000 0.000% 0.000% 1 0.000
uptime 0.0000 0.000% 0.000% 1 0.000
postdrop 0.0000 0.000% 0.000% 1 0.000
free 0.0000 0.000% 0.000% 1 0.000
vmstat 0.0000 0.000% 0.000% 1 0.000
———————————————————————-
Total: 158.1400 100.000% 0.659% 879
Average per day: 158.1400 1 days
CPU percentage assumes 24000 cpu seconds per day total. -
daniel nos comenta:
en un servidor compartido utlizando wordpress hasta cuantas visitas diarias soparta sin saturar el cpu?
-
Armonth nos comenta:
Depende del servidor, de lo saturado que éste, de las limitaciones que imponga el mismo, etcétera. Yo sé de gente que en Dreamhost con servidores compartidos y 15.000 diarias soporta el tráfico sin problemas…