Planificación de capacidades y problemas de productividad con Solaris 2.6

Indice

2. ¿Dónde es la Lentitud?
3. Aplicaciones con lentitud.
4. Escalamiento horizontal y vertical

1. Las bases de un cuello de botellas
Que hacer cuando un sistema presenta lentitud?  La lentitud puede ser atribuida a uno o más cuellos de botellas, estos pueden ser causados por un componente del sistema que no se ejecuta de la forma rápida y eficiente de acuerdo a lo que demandan o requieren los restantes elementos del sistema, los más comunes cuellos de botellas, pueden ocurrir en algunas de las siguientes áreas:

• Lentitud en discos o arreglos que no están habilitados para responder a la demanda de I/O en forma rápida.
• El sistema esta necesitando mas capacidad de memoria, así la aplicación se ve forzada a ir a disco ( swap) y en este caso la respuesta es mucho más lenta ( promedio ->memoria = 3 nanosegundos, disco = 17 milisegundos)
• El sistema esta sobre la capacidad de(los) procesador(es).
• Las interfaces de red están saturadas o sobre cargadas.

¿Cómo puede usted saber cuál de estos elementos del sistema presenta un problema.
Para esto se pueden usar varias herramientas para planificar como son: sar, netstat, lockstat y top sar
sar es una herramienta principal para el administrador con ella puede disponer de estadísticas pasadas y predecir las demandas futuras. Para verificar que la herramienta sar esta instalada en su sistema:
pkginfo -l SUNWaccu
Si no se encuentra instalada la herramienta sar, Ud., puede adicionarla e instalar desde SUNWaccu.
Una vez instalada, debe configurar para iniciar la colección de la información.
Edite en el sistema crontab:
crontab -e sys

Remueva los comentarios así tendrá las siguientes líneas:
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

Entonces edite vi /etc/init.d/perf
Quite los comentarios abajo de "Uncomment the following lines"
Este podría habilita el sistema sar para iniciar la colección de información y reportar las actividades, también se puede incrementar el tiempo de retención del log de sar.
vi /usr/lib/sa/sa2  
/usr/bin/find /var/adm/sa \( -name 'sar*' -o -name 'sa*' \) -mtime +30 -exec /usr/bin/rm {} \;
Una vez realizado lo anterior el sistema ya esta recolectando información, para mayores detalles como se usa edite man sar.  He aquí una rápida lista de opciones de SAR:

• sar  ejecutada sin opción, muestra el uso del CPU.
• sar -q  muestra el promedio de tamaño de las colas.
• sar -p  y sar -g  muestra la actividad de paginas.
• sar -d  muestra la utilización de los discos.
• sar -f <filename> lee y guarda en el file, sar -f /var/adm/sa/sa03

netstat
La herramienta sar no entrega estadísticas sobre él trafico de la red, para esto se usa netstat.  netstat -in  podría mostrar las interfaces con la red y como esta su utilización y si existen problemas

netstat -in
Name Mtu Net/Dest  Address Ipkts Ierrs Opkts Oerrs Collis Queue
hme1  1500 192.168.100.0 192.168.100.1  1477758588 0  2897473608 0 0 0     
hme2  1500 192.168.101.0 192.168.101.1  3228181693 157415 3365694030 0 0 0 
En este ejemplo , se puede visualizar que las interfaces hme1 y hme2 están muy ocupados, en las interfaces hme2 existen errores de "incoming errors" .

Lockstat
Con Solaris 2.6 o superior, SUN incluye una utilidad llamada lockstat la cual permite visualizar los locking causados en el kernel,   man lockstat esta disponible para mayor información, he aquí un ejemplo de como usar:
lockstat sleep 30 > /tmp/lock.out
more /tmp/lock.out
"Callers" este parámetro reflejando una cantidad mayor de lock puede ser causa de problemas. Si observa "hmestart" o "qfestart" y existen algunos kernel locks, tal vez se necesite sumar otra interface en la red.

Top
top es una herramienta de snapshot en tiempo real donde se presenta que esta pasando con el sistema, con esta herramienta se puede saber cuanta memoria esta libre y como las aplicaciones y procesos están usando el CPU o la memoria.

2. ¿Dónde es la Lentitud?
Usando algunas de las herramientas como sar, netstat, y lockstat pueden ayudarlo a determinar donde esta la lentitud y que esta sucediendo.
He aquí algunos ejemplos de cómo usar estas herramientas:

• sar  sin opciones nuestra el estado de idle ( sin uso - desocupado) del CPU.  Si su estadística de CPU el uso de %usr o %sys es muy alto, entonces puede ser que se necesite incrementar CPU y esperar un incremento en la demanda ( por demanda latente), si es %wio el alto, su sistema puede estar esperando por el subsistema de I/O, esto significa lentitud en un disco o en un arreglo.
• sar -g  si se observa algún índice alto en pgscan/s, entonces el sistema esta realizando swapping. No tener swapping es lo optimo, pero se existe es probable que se necesite
• incrementar memoria. Use sar -r para verificar esto.
• netstat -in  observar si una interface esta saturada con trafico, si esto es así es posible que se deba sumar otra interface.  Debe observar "Ierrs, Oerrs, and Collis."  , estos deben ser números relativamente bajos, casi cero. Altos números en estas columnas pueden indicar problemas en la red, algunos como velocidad, cableado malo o un port de un switch.
• top  si todo lo anterior no esta disponible, observe en top.  ¿ Que proceso esta monopolizando los recursos?.

Analice la información y sus recomendaciones
Si Ud. , ha iniciado sus herramientas debe obtener la información y todos los reportes, por lo tanto esta posibilitado para analizar la tendencia pasadas y hacer predicciones sobre el crecimiento futuro basado en la herramienta sar, puede apoyarse en la herramienta top para obtener un snapshots en tiempo real. ¿ Cómo podría Ud. , asegurar una mayor y mejor productividad del sistema actual y así mismo en el futuro?.
Es importante notar que si se identifica y resuelve un cuello de botella, debe analizarse que esto no sea la causa la generación de peores. Por ejemplo, si se observa que tiene %idle de CPU y un alto %wio, esto puede resolverse cambiando el disco por otro más rápido; pero esto puede causar cuellos de botella en el ámbito de CPU. , debe recordarse que la Planificación de Capacidades es un ejercicio constante y no una actividad puntual, he aquí algunos escenarios:

1. Busy I/O subsystems.  Se debe determinar usando sar -d si existe uno o más discos con alta demanda ( ocupado) (> 90% busy). Existen varias alternativas, mover el I/O hacia otro disco o un arreglo más rápido o dividir el I/O en varios arreglos dependiendo del uso de la data. Recuerde de las interfaces SCSI también pueden sobrecargarse, esta dificultad a determinar, puede solucionarse sumándose una nueva interface SCSI y balanceando el trafico del I/O, no preocuparse del acceso de I/O puede tener un impacto mayor en CPU o al performance de la red.
3. Busy CPU's.  Observando el sar este puede presentar un alto uso en el sistema de %usr y %sys., esto también puede verificarse con el comando mpstat que entrega información sobre el uso de los CPU.  Adicionar CPU's en esta situación puede ayudar; pero puede no resolver el problema, si existe una pobre programación en las aplicaciones que usa mal los recursos de CPU.
4. Busy network.  netstat -in y lockstat si muestran que están ocupadas las interfaces de red, debe sumarse otra interface, pero debe tenerse cuidado por el posible incremento del I/O y demanda de CPU.
5. System con swapping.  Adicionar memoria; pero también puede colocarse el swap sobre discos rápidos.

3. Aplicaciones con lentitud.
Algunas veces el hardware del sistema no es causa de todos los problemas de performance, recuerde que las aplicaciones son las que consumen los recursos del sistema y si se escriben pobres aplicaciones.  He aquí algunos tips a tener en mente:

• Tratar de evitar aplicaciones que contengan un único hilo de ejecución (single-threaded). Generalmente es muy rápido desarrollar este tipo de aplicaciones; pero sus costos están en la ejecución. Muchas aplicaciones desarrolladas in-house están bajo esta categoría.  El peor ejemplo es una aplicación que contiene un único hilo de ejecución y no se puede así misma copiar, por lo tanto solo se ejecutan bajo un CPU, así se sumen mas CPU. Cambiar este tipo de aplicación una vez desarrolladas es desafiante a veces es más recomendable cambiar en forma radical de aplicación que soporte multi-hilos de ejecución.
• Trate de conocer la aplicación. Aprenda lo máximo posible acerca de la aplicación que Ud., esta negociando, hable con el vendedor o el autor para conocer los trucos y o tip´s para su mejor ejecución. A menudo las entradas de datos necesitan realizarse /etc/system así que esta aplicación puede causar que el hardware se ejecute como si estuviera en un pico de su capacidad, los parámetros ndd tal vez se necesiten modificar de acuerdos a las necesidades actuales del sistema, considere todas estas sugerencias antes de sumar nuevas capacidades de hardware.

 

Planificando las futuras capacidades
Algunas veces la mejor manera de realizar un plan para el futuro es analizando las estadísticas pasadas de performance. Usando sar se puede averiguar una tendencia en el consumo de recursos del sistema. Hace tres meses atrás el sistema presento CPU al 90% idle; y ahora 80% idle., no es irracional suponer que el sistema presentara un uso de un 70% idle CPU en los próximos tres meses.  Algunas partes de su sistema pueden tener crecimiento exponencial, como el I/O o el subsistema de red, es muy importante estar constantemente recolectando información, así tendrá información de lo que sucedió y de lo que podría suceder con su sistema. Es necesario escribir scripts para poder monitorear los parámetros principales de forma de tener umbrales que permitan un seguimiento, así si una umbral como que el subsistema de I/O esta en una semana ocupado en un 70%, entonces es probable que sea altamente recomendable considerar un upgrade.
La comunicación con la organización le permite obtener por un lado un plan de crecimiento de capacidad más acorde a las necesidades y planes de negocio y al mismo tiempo se compromete a la organización a dar el apoyo gerencial y económico, el área de mercadeo debe participar activamente en la planificación del crecimiento aportando información sobre nuevos productos o aumento de clientes por nuevos servicios que pueden traducirse posibles indicadores que permiten proyectar posibles demanda de servicios computacionales versus la plataforma actual.

4. Escalamiento horizontal y vertical

Para grandes aplicaciones, es muy importante que tengan la habilidad de escalar en forma horizontal y vertical.  Escalabilidad horizontal es permitir que se puedan adicionar servidores para obtener una ampliación de la misma aplicación, mientras que escalamiento vertical es particionar la aplicación en diferentes piezas que se permita crecer en forma horizontal. Si un sistema fue diseñado para permitir escalar horizontal y vertical esto significa que sumar servidores le permite aumentar la demanda con un riesgo e impacto mínimo a los usuarios y/o clientes, esto le permite a escapar de la "trampa" de escalar en una sola "gran caja".

He aquí algunos ejemplos de escalabilidad horizontal y vertical:

• Horizontal web servers. Múltiple web servers son organizados sirviendo idéntico contenido usando independiente hardware sobre diferentes redes. DNS se encarga de realizar el balance de carga.
• Horizontal y vertical como solución de e-mail. Cada componente del servidor de e-mail (mx, smtp, pop, web mail) pueden ejecutarse en servidores independientes. Múltiples servidores pueden ser organizados para balancear la carga, por ejemplo una forma seria 4 mx servers, 2 smtp servers, 2 pop servers, y 1 web mail server, o cualquier configuración que este de acuerdo a la demanda.
• Horizontal y vertical web servers. Múltiples web servers pueden organizarse, algunos para servidores de gráficas y otros como servidores de scripts cgi.

Permanecer delante de la curva de crecimiento.
Usando herramientas de reporte algunas como sar asegura la posibilidad de identificar las tendencies de sus sistemas, aprende acerca de las aplicaciones que se ejecutan sobre sus sistemas y comunicándose con su organización puede ayudar efectivamente en la planificación de crecimiento futura. Finalmente asegurando que en el diseño de sus aplicaciones estas puedan escalar tanto horizontal como vertical , esto le permitirá estar un paso delante de la curva de crecimiento

Resumen
El incremento de la demanda puede causar que los recursos computacionales sean insuficientes para el trabajo desarrollado por los servidores . Los clientes no podrán entender el porque de la lentitud a sus operaciones. Existe una infinidad de motivos que van desde el crecimiento exponencial del uso de la red, que es un motivo digamos fácil de evidenciar, pero que sucede cuando el "cuello de botella " puede estar en los elementos de la plataforma o en la aplicación, para esto se necesita tener algunas estadisticas o detalles técnicos que permitan analizar la actual demanda y planificar las capacidades para el crecimiento futuro.
Algo que nunca como administrador desea recibir es una llamada telefónica donde le informan "... el servidor esta muy lento y no puedo realizar mis operaciones..".. a menudo los administradores también realizan reclamos a la organización solicitando información de las aplicaciones con la finalidad de planificar el crecimiento de las capacidades de la plataforma computacional, para esto es necesario que el usuario entregue una información " básica " de crecimiento por medio de un cuestionario que debe realizar la área de informática de la organización, en algunos casos el crecimiento puede ser predecible si es lineal, pero cambia totalmente el panorama si el crecimiento es al azar, exponencial o más complicado mezclado con crecimiento estacional ( esto es periodos del año como carnaval, feriados largos, periodo vacacional, fin de año, etc.) además crecimientos por nuevos productos o servicios para los clientes las áreas de mercadeo.
Pero volviendo al problema de lentitud, existen algunas maneras de entender los cuellos de botellas dentro de los sistemas y generar estadísticas que puedan ayudar a conocer la demanda actual y las necesidades futuras.

 

 

 

 

Autor:

Néstor Espíndola