En todos los años que llevo administrando sistemas Linux y HP-UX, no paro de recibir una y otra vez incidencias de los clientes reportando al equipo de sistema operativo lentitud en la aplicación, cuando la que realmente va lenta es la propia aplicación en el 95% de los casos.
Ahora bien, los técnicos de sistemas siempre tenemos que cubrirnos las espaldas y analizar el rendimiento del sistema operativo, por si acaso, aunque luego el problema esté en una query SQL muy pesada o en un memory leak de Java, por ejemplo. De hecho, muchas veces los clientes, fruto de su leve conocimiento técnico, nos piden gráficas de consumo de una semana, como si en una gráfica tan amplia se pudiese detectar un problema puntual de un pico de consumo. Lo normal, es revisar un intervalo horario concreto donde se ha detectado el problema de lentitud. En fin… así es nuestro trabajo.
Para analizar el rendimiento del sistema operativo reviso tres cosas:
- Consumo de CPU: No me estoy refiriendo a que el consumo de CPU es de un 100%. Eso no es malo por sí solo. Lo que es malo es que tengamos muchas peticiones encoladas en la CPU. Por lo tanto, hay que mirar cuántas peticiones hay en la cola de CPU. Cuando esto sucede, casi siempre veremos que la CPU está al 100% de uso y el load se ha disparado. El load hace referencia al nivel de carga de la CPU (en un sistema con un core, un load de uno equivaldría a un uso del 100% de la CPU, si es mayor de uno tendríamos peticiones encoladas en la CPU con toda seguridad).
- Consumo de memoria: Igual que ocurre con la CPU, no es malo que estemos utilizando el 100% de la memoria física. Lo que es malo es que estemos haciendo mucho uso de swap. Esto significa que cuando un proceso necesita acceder a datos ubicados en memoria (ocurre todo el tiempo) pero estos datos no están en la memoria física (RAM), sino en la swap, se tienen que mover páginas de memoria de la memoria física a swap (disco duro) para mover las páginas que ahora están en la swap a la física para que el proceso pueda acceder a los datos que necesita. Esto es lo que se llama «page-in» y «page-out» y es una métrica de sistema operativo que podemos capturar. El hecho de utilizar mucha swap, implica mucho movimiento de page-in y page-out, y este es un proceso lento que provoca lentitud.
- Consumo de disco: Aquí siempre me estoy refiriendo a los discos de la SAN, que es donde suelen estar los datos de las aplicaciones, bases de datos, etc. Lo que suelo mirar aquí es el tiempo de respuesta de los discos (en milisegundos) y los niveles de lectura y escritura por segundo (KB/s o MB/s). Lo que suelo ver siempre es que, incluso cuando aumenta el tráfico de lecturas y escrituras, los tiempos de respuesta de los discos no cambian. Son discos de fibra y son muy rápidos. El problema estaría si los tiempos comienzan a subir y vemos peticiones encoladas a nivel de disco.
- Tráfico de red: Esta métrica se suele analizar más desde el equipo de comunicaciones, pero a nivel de sistema operativo podemos analizar la cantidad de tráfico que recibe una tarjeta de red (KB/s o MB/s). Conociendo el ancho de banda o la velocidad de nuestra tarjeta, podremos saber si estamos recibiendo mucho o poco tráfico. Rara vez el problema está ahí.
Por mi trabajo, utilizamos el agente de rendimiento de Openview para extraer estar métricas pero hay muchas herramientas en el mercado capaces de obtenerlas.
Linux, incluye sar como herramienta nativa de análisis del rendimiento.
Te puede interesar
Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.
Más sobre mí en el este enlace,
