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:
- 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. - 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. - 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. - 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.
 Página anterior | Volver al principio del trabajo | Página siguiente  |