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 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 es 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 ;).
Comentarios