Planificación de capacidades y problemas de productividad con Solaris 2.6 (página 2)

• 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 capacidadesAlgunas 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.