Archive for December, 2007
December 28, 2007 a las 2:42 pm por Edwin Plauchu · Archivado en FreeBSD, Linux, Solaris
Los siguientes criterios de configuracion, los he aplicado a un servidor de 8 cores y 8 gb en RAM, y la cosa funciona de maravilla.
Sobre el MYSQL que corre en este servidor hay tablas tanto innodb como myisam. incluyo parametros para las dos engines.
[mysqld]
innodb_log_buffer_size=8M
#Explicacion: medida del buffer que innodb usara para su archivo de log.
#Consecuencia:Un buffer de log grande, permite a transacciones extensas ejecutarce, sin necesidad de acceso a disco antes de que la
# transaccion se confirme.
#Criterio de calculo: 1MB por cada GB de RAM.
innodb_buffer_pool_size=4294967296
#Explicacion: Empleado para almacenamiento intermedio de los datos e indices de sus tablas
#Consecuencia: Mientras mas grande sea este valor menos operaciones de IO disco seran necesarias para acceder a los datos de las tablas.
#Criterio de calculo: En un servidor de base de datos dedicado se puede asignar hasta el 80% de la memoria RAM. No dedicados Menos del 50% de RAM.
innodb_buffer_mem_pool_size=16M
#Explicacion: almacena info del diccionario de datos y estructuras internas, el valor por defecto es de 1MB
#Consecuencia: Evita que se haga paginacion a disco cuando, se acaba la memoria de este pool.
#Criterio de calculo: Entre mas tablas se tengan en la aplicacion, mayor debera ser el tamaño de este buffer,.
join_buffer_size=16777216
#Explicacion: buffer que se usa para joins que no usan índices (full joins)
#Consecuencia: obtencion de un full join más rápido ( cuando se añaden índices no es posible.)
#Criterio de calculo:2097152 bytes por cada Gigabyte de RAM.
skip-bdb
skip-ndbcluster
#Explicacion: Deshabilita el soporte para base de datos bdb y ndbcluster
#Consecuencia: Ahorro en la memoria asignada por sistema operativo al proceso mysqld
innodb_data_file_path=/dev/hdc1:250MBraw;/dev/hdc2:250MBraw
#Explicacion: Utilizar dispositivos crudos como Datafiles
#Consecuencia: Aumento en velocidad relacionada a operaciones de IO sobre disco.
query_cache_size=134217728
#Explicacion: Almacena el texto de una consulta SELECT junto con el resultado que se le envió al cliente.
#Consecuencia: Si se recibe una consulta idéntica posteriormente, el servidor devuelve el resultado de la
# caché de consultas en lugar de parsear y ejecutar la consulta de nuevo.
#Criterio de calculo:16777216 bytes por cada Gigabyte de RAM.
query_cache_limit=1M
#Criterio de calculo: consultas menores a 1MB no merecen ser cacheadas.
query_cache_type=1
#Consecuencia: Permite el cacheo excepto para aquellos comandos que empiecen con SELECT SQL_NO_CACHE
key_buffer_size=100663296
#Explicacion: Cachea los bloques de índices para tablas MyISAM. Cada vez que una búsqueda usa un índice,
# MySQL mirará antes de nada a ver si el índice relevante está o no en memoria.
#Consecuencia: Incrementando el valor se obtiene un mejor tratamiento de índices y por consecuencia, mejor rendimiento.
#Criterio de calculo:12582912 bytes por cada Gigabyte de RAM. Pero si solo se utilizan tablas MyISAM utilice 5% a 50% de la RAM.
sort_buffer=67108864
#Explicacion: Búffer de ordenación se usa para responder a búsquedas que involucren el ordenamiento de los datos -aquellas
# con una sentencia ORDER BY en ellas. Además, el búffer de ordenaciónse usa para las búsquedas que involucren
# agrupar datos -aquellas con una sentencia GROUP BY.
#Consecuencia: Reduce dramáticamente la cantidad de tiempo que se usa para ordenar grandes grupos de resultados
#Criterio de calculo: 8388608 bytes por cada Gigabyte de RAM.
read_buffer_size=8M
#Explicacion: Cada thread que realiza un escaneo secuencial reserva un buffer de su tamaño (en bytes) para cada tabla que escanea.
# Si realiza muchos escaneos secuenciales, puede incrementar este valor.
#Consecuencia: Mejora el rendimiento en los escaneos secuenciales.
#Criterio de calculo: 1MB por cada Gigabyte de RAM.
open_files_limit=4096
#Explicacion: limite de archivos abiertos por mysql
#Consecuencia: Ciertas operaciones requeriran mas de 1024 descriptores de archivos abiertos en mysqld, sobre todo aplicaciones web.
#Criterio de calculo: 1024 es el predeterminado, aumente este valor si observa errores referentes a esto en el log de errores de mysql.
# No aumente este valor mas alla de 4kb.
[mysqldump]
quick
Si tienen algo que agregar a esta configuracion, u algun otro criterio, lo anexare a este articulo a la brevedad.
Feliz año nuevo 2007 
December 27, 2007 a las 12:33 pm por Edwin Plauchu · Archivado en Linux
Dandole Tuning al swappiness para prevenir una catastrofe en RAM improvisada
Swappiness es el termino que los desarrolladores del kernel de linux dieron al rendimiento entre aplicaciones que paginan hacia el disco y (en la practica) a la contraccion de las caches. Si Swappiness fuece establecida a 0, Linux preferirá mantener applicaciones en RAM y no engrandecer los caches. Caso contrario, si establecieramos Swappiness a 100, Linux preferirá hacer swap a las aplicaciones, y alargar los caches lo mas posible. El parametro de 60 por default que viene en la mayoria de los sistemas linux suele ser algo saludable.
La ironia de esta preferencia Swappiness radica en este factor, paginando una aplicacion no esta siendo utilizada generalmente producira un incremento sobre el rendimiento de red, ya que el cache realmente ayuda a esto muchisimo cuando este es requerido — pero este aumento sobre el rendimiento de red, se traducira en una fuga del rendimiento percivida, lo notaras cuando tu aplicacion descomprima un archivo con algunos segunditos de retraso, tal vez eso no te importe en el momento que suceda, pero cuando si te llega a importar, sera el momento en que tu aplicacion ya no te responda de manera instantanea :).
Sobre mi laptop, se me ha ocurrido aplicar el swappiness lo mas cercano a cero. La razon de por que se me ocurrio hacer esto? Lo hago por que deseo inmunizar mi laptop contra esas pequeñas interrupciones de tiempo causadas por la manipulacion de grandes archivos temporales (pienso hacer una copia de un archivo grande de video hacia otro disco). El cache debera de ser lo mas grande posible, pero esto no debera desplazar a las demas aplicaciones que ya se encuentran corriendo.
No me crees ? Si tienes 2 gb para usar sobre tu particion / , entonces que esperas incredulo corre los siguientes comandos en el siguiente orden:
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=/tmp/archivobasurita count=1 bs=900M
find / > /dev/null && cp /tmp/archivobasurita /tmp/archivobasurita2
La tiempo consumido en la ejecucion de los anteriores comandos fue de 6:20 min:seg. Desesperantemente lento no ? Imagina como pueden tus aplicaciones podrian esperar, mientras el disco duro centellea con su lucecita frenéticamente :)…..
Muy bien, ahora modifiquemos el swappiness de nuestro sistema. (por supuesto como root):
sysctl -w vm.swappiness=1
intenta otra vez con los comandos de arriba. Sientes la diferencia, el tiempo se redujo a 2:05 min:seg?
La razon de esta rapidez, cuando tenemos el swappiness casi a cero, El nucleo de Linux no aumenta el cache para que las aplicaciones paginen, dandote una experiencia de rapido acceso a memoria.
Para hacer este cambio permanente, escribe vm.swappiness=1 sobre tu archivo /etc/sysctl.conf.
Los caches del sistema de archivos son mas importantes que otros caches
Existen dos tipos de caches en un Linux VFS.
* Block cache: contiene cache de dispositivos de bloque
* inode/dentry(inodo y de entrada de directorio): una capa sobre el block cache, el cache de entrada de directorios y otros sistemas de archivos relacionados, tienen para el sistema linux un costo de busqueda mucho mayor, al del cache de dispositivos de bloque.
Ya establecimos que la cache del sistema de archivos es importante ya que, sin esta, la busqueda y manejo de los archivos seria extremadamente lenta. Ahora aprenderemos como decirle a linux que cache preferimos inode/dentry u otras caches.
Probemos esto:
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=/tmp/basurita count=1 bs=900M
sysctl -w vm.vfs_cache_pressure=100
find / > /dev/null
cp /tmp/basurita /tmp/basurita2
time find / > /dev/null
sysctl -w vm.vfs_cache_pressure=50
find / > /dev/null
cp /tmp/basurita2 /tmp/basurita3
time find / > /dev/null
rm -f /tmp/basurita /tmp/basurita2 /tmp/basurita3
Esta serie de comandos lo que hace basicamente es, buscar todos los archivos sobre tu disco, despues crear grandes archivos. Esto se hace 2 veces, la primera vez con las parametros por default del cache, y la segunda vez con los parametros del cache fuertemente orientados a favor de la cache inode/dentry.
Observaste la salida de los anteriores comandos. Notaste que la segunda vez que se corren los comandos realmente se consume menos tiempo? Esto definitivamente reduce los tiempos sobre nuestro equipo gnu linux. Cuando este knob(perilla o boton de mando, segun el diccionario de proyecto lucas Ver 0.1.6 ) esta cercano a 1, el kernel preferira proteger la cache inode/dentry por estar liberando block cache primero.
Para hacer este cambio permanente, agrega vm.vfs_cache_pressure=50 sobre tu archivo /etc/sysctl.conf.
Experimenta con este valor. Valores proximos a 100 no proveen ninguna ganancia en rendimiento. Valores cercanos a cero pueden causar enorme actividad swap durante la escaneo de grandes sistemas de archivos.
December 27, 2007 a las 10:52 am por Edwin Plauchu · Archivado en Linux
En MySQL 5.0, puedes usar particiones crudas(raw disk partitions) como espacio de tables(tablesspace) con datafiles. El rendimiento obtenido al hacer uso de una particion o dispositivo crudo, es considerable, con esto se evita el uso de el buffer-cache, recurso generalmente utilizado cuando se accesa a cualquier sistema de archivo en entornos Linux, lo cual generalmente decrementa el rendimiento de Mysql cuando este usa Innodb.
Cuando creas un data file, deberas colocar la palabra clave newraw inmediatamente despues la medida del data file en innodb_data_file_path. Deberas de especificar una medida que no sea mas grande que el tamaño de tu particion.
Nota: Un 1MB sobre InnoDB es 1024 * 1024 bytes, donde 1MB usualmente es 1,000,000 bytes en especificaciones de disco.
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdc1:250MBnewraw;/dev/hdc2:250MBnewraw
[root@localhost ~]$ /etc/init.d/mysql stop
Shutting down MySQL [ OK ]
[root@localhost ~]$ /etc/init.d/mysql start
Starting MySQL [ OK ]
Retocamos el archivo de configuracion y procedemos a quitar el prefijo new
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdc1:250MBraw;/dev/hdc2:250MBraw
[root@localhost ~]$ /etc/init.d/mysql restart
Shutting down MySQL [ OK ]
Listo, ya tienes a mysql funcionando con innodb datafiles en particiones raw.
December 27, 2007 a las 10:48 am por Edwin Plauchu · Archivado en Varios
Introduccion — De que sirve un dispositivo crudo?
Existen tres tipos de interfaz para un dispositivo en Linux: dispositivos de red, dispositivos de caracteres y dispositivos de bloques. Los tres son descritos en detalle en cualquier libro de texto acerca de la arquitectura interna de un SO POSIX, y para una comprensión detallada y maximizar su explotación, sería necesario que se estudiara propiamente (cosa que es típica de una clase de Sistemas Operativos).
De los primeros no hablaré. Son algo muy basto.
Los segundos son aquellos cuya interfaz natural de acceso es “caracter a caracter”, como puede ser un puerto serial, una tarjeta de sonido, un puerto paralelo o un puerto USB. Cada vez que se quieren obtener/enviar datos desde/hacia el dispositivo en cuestión se hacen lecturas de números arbitrarios de bytes, que son procesados directamente desde el espacio kernel al espacio usuario.
Los terceros son aquellos cuya interfaz natural de acceso es “en bloques de tamaño fijo”, como puede ser un disco duro, una unidad de CD-ROM o un RAM-disk. Cada vez que se quieren obtener/enviar datos desde/hacia el dispositivo en cuestión se hacen lecturas de bloques de un tamaño fijo, usualmente optimizado para adaptarse a las características de la plataforma particular, que son procesados desde el espacio kernel hacia el buffer cache, y desde allí son llevados a espacio usuario. En efecto se hacen _dos_ transferencias de memoria, pero la intención del cache es que solamente se haga una transferencia física con la esperanza de que varios procesos quieran “leer lo mismo”. Suena simple pero es bastante complicado: algoritmos LRU, algoritmos de ascensor, algoritmos de lectura anticipada, algoritmos de lectura en demanda y copia en escritura son combinados delicadamente para maximizar el rendimiento y minimizar la latencia y retardo en las operaciones de I/O.
Los requerimientos Ocacionales
En ocasiones, se requiere que un dispositivo de bloques sea manipulado directamente sin pasar por el buffer cache.
Linux permite manipular un dispositivo de bloques a través de la interfaz cruda, queriendo decir que se le indica al kernel “a partir de este momento, cualquier operación sobre el dispositivo de bloques X, que usualmente harías a través del buffer cache, quiero que se haga directo de espacio kernel a espacio usuario… porque yo sé lo que estoy haciendo”. Eso se logra enlazando un /dev/rawX con el dispositivo de bloques deseado.
Creacion de nuestra particion Cruda (raw)
Dentro de nuestro escenario de pruebas, tenemos al sistema operativo linux instalado sobre /dev/sda/. Visualicemos las particiones existentes en /dev/sda:
[root@localhost ~]$ fdisk -l /dev/sda
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 1044 8281507+ 8e Linux LVM
Nuestro dispositivo de bloques /dev/sda se encuentra completamente particionado, a razon de esto, hemos agregado otro disco duro (un disco IDE) sobre /dev/hdc. Actualmente dicho dispositivo no alberga particion alguna.
[root@localhost ~]$ fdisk -l /dev/hdc
Disk /dev/hdc: 524 MB, 524288000 bytes
16 heads, 63 sectors/track, 1015 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk /dev/hdc doesn't contain a valid partition table
Generando las particiones Raw
[root@localhost ~]$ fdisk /dev/hdc
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1015, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1015, default 1015): +250M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (486-1015, default 486):
Using default value 486
Last cylinder or +size or +sizeM or +sizeK (486-1015, default 1015):
Using default value 1015
Command (m for help): p
Disk /dev/hdc: 524 MB, 524288000 bytes
16 heads, 63 sectors/track, 1015 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hdc1 1 485 244408+ 83 Linux
/dev/hdc2 486 1015 267120 83 Linux
p
Disk /dev/hdc: 524 MB, 524288000 bytes
16 heads, 63 sectors/track, 1015 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hdc1 1 485 244408+ 83 Linux
/dev/hdc2 486 1015 267120 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Agregando reglas udev
udev es el administrador de dispositivos para la serie de kerneles 2.6. Su funcion primaria es la administracion de nodos dispositivo sobre el directorio /dev. Este es el sucesor de devfs y hotplug. Para agregar un dispositivo raw a nuestro sistema linux 2.6, agregaremos entradas a el archivo /etc/udev/rules.d/60-raw.rules utilizando el siguiente formato:
ACTION=="add", KERNEL=="hdc1", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add", KERNEL=="hdc2", RUN+="/bin/raw /dev/raw/raw2 %N"
Podemos comprobar que los dispositivos raw han sido asignados correctamente ejecutando:
[root@localhost ~]$ raw -qa
December 27, 2007 a las 10:40 am por Edwin Plauchu · Archivado en Varios
Una de las novedades de la rama 2.6 del núcleo de Linux es la posibilidad de cambiar la gestión de la memoria virtual o SWAP. LA SWAP nos sirve para que las aplicaciones que necesiten más memoria que la que tenemos físicamente (RAM) puedan usar una parte del disco duro como tal, este uso se llama Swapping. El problema es que el acceso al disco duro es más lento que a la RAM.
Para saber nuestro valor de Swapping haremos desde la consola:
cat /proc/sys/vm/swappiness
El resultado es un valor entre 0 y 100, por defecto Ubuntu tiene un valor de 60, con lo que vemos que tiene mucha tendencia a usar este tipo de memoria.
Abrimos el archivo /etc/sysctl.conf con el edito que nos sea más cómodo de usar, en este caso con vi;
$vi /etc/sysctl.conf
Añadir la siguiente linea al final del archivo:
vm.swappiness=10
En este caso le hemos puesto un valor de 10, cada uno deberá encontrar el que más se adapte a su sistema.
Una vez se reinicie el sistema se cargara esta nueva configuración.
El resultado es un número entre 0 y 100 que nos dice la tendencia que tiene el núcleo a transferir memoria no usada a la partición de intercambio. A valor más alto, más swapping. El valor por defecto en Ubuntu y en la mayoría de las distribuciones es 60. Esto será útil en un servidor con mucha carga de trabajo y poca RAM, pero para un ordenador de escritorio con distintas aplicaciones ejecutándose puede ser que este valor sea demasiado elevado y que se este abusando del Swapping.
Si bajamos el valor del Swappiness, forzaremos al sistema para que haga más uso de la memoria RAM que de la partición Swap con lo que si hay suficiente RAM para esta demanda (los ordenadores actuales acostumbran a tener un mínimo de 512Mb, que es más que suficiente) el sistema ira más fluido.
Si queremos probar el sistema antes de cambiar definitivamente el valor del Swappiness, haremos lo siguiente:
$ sysctl -w vm.swappiness=10
Y ejecutamos algunas aplicacioens para ver el rendimiento, si es de nuestro agrado podemos configurar definitivamente el sistema del siguiente modo.
December 21, 2007 a las 10:25 am por Edwin Plauchu · Archivado en Linux
Introduccion — Que es un prueba de Stress ?
Las pruebas de stress, son aquellas pruebas que tratan de probar o visualizar el comportamiento de un sistema gnu/linux bajo condiciones demandantes. Las pruebas de stress sobre un periodo de tiempo, permitiran darnos la confianza que realmente estamos comparando manzanas con manzanas y naranjas con naranjas.
Pero cual es la metodologia a seguir para llevar a cabo una prueba de stress sobre sistemas gnu/Linux?.
Metodologia — Evaluacion de la utilizacion de los recursos del sistema
La seleccion de pruebas adecuadas puede stresar los recursos del sistema. Cuatro areas principales del sistema gnu/Linux afectaran la respuesta y tiempo de ejecucion:
* CPU: Tiempo consumido en el procesado de daatos sobre el o los CPU(s) de una maquina.
* Memory: Tiempo consumido en lectura y escritura para y proveniente de la memoria real.
* I/O: Tiempo consumido en lectura y escritura para y proveniente de la unidad de almacenamiento.
* Networking: Tiempo consumido en lectura y escritura para y proveniente de la red.
Metodologia — Las Herramientas de los Testers
Los diseñadores de pruebas deberan conocer muy bien las siguientes dos herramientas, ya que les permitiran evaluar los niveles de utilizacion de los recursos del sistema.
* top: Una herramienta open source, cuyo proyecto es lidereado por Albert D. Cahalan, herramienta que por lo general esta incluida en la mayoria de las distribuciones linux sobre los kernels 2.4.X y 2.6.X.
* sar: Otra herramienta open source; la cual es lidereada por Sebastien Godard. Esta herramienta es tambien incluida en la mayoria de las distribuciones Linux y trabaja sobre los kernels 2.4.X y 2.6.X.
* stress: Generador de carga de trabajo (workload) para sistemas POSIX. Cargara de trabajo a la CPU(s), memoria, discos. Programa escrito en ensamblador bajo la licencia GPL.
Para evaluar la utilizacion de los recursos del sistema, se requerira multiples pruebas combinadas, que puedan alcanzar el nivel de utilizacion deseado. La Sobre-Utilizacion es siempre un objetivo de las pruebas que se aplicaran. Haciendo referencia a esto, podriamos tener el siguiente caso, escoger una combinacion de pruebas con bastante I/O que pueda llevar a la o los CPU(s) ha tener un rendimiento pobre y vice versa.
Metodologia — Las Herramientas de los Testers — Diferencias entre sar y top
La herramienta top es muy usada para determinar rapidamente cuales recursos (CPU, memory, o I/O) afecta cada prueba y que proporcion de estos es utlizada en el preciso momento en que se ejecuta la prueba. En cambio la herramienta sar es usada para la recoleccion de datos estadisticos de la utilizacion de red y tambien registrara los estados(snapshots) de la utilizacion total del sistema en cierto periodo de tiempo.
Una vez que has seleccionado una combinacion de pruebas a correr sobre tu gnu/linux, una prueba debera de ejecutarce durante cierto periodo de tiempo que sea adecuado para la evaluacion de la utilizacion del recurso. El monto de tiempo que la prueba corra sera algo muy particular de cada prueba. Asumiendo que multiples pruebas estan siendo executadas concurrentemente, El monto de tiempo debera de ser lo suficientemente largo para que todas esas pruebas se completen. La herramienta sar debera de estar corriendo durante este periodo de evaluacion. Mientras las pruebas corren sar se mantendra recolectando todos los niveles de utilizacion de todos los recursos.
El siguiente ejemplo muestra la salida referente a CPU, memoria, y utilizacion de red:
10:48:27 CPU %user %nice %system %iowait %idle
10:48:28 all 0.00 0.00 0.00 0.00 100.00
10:48:29 all 3.00 0.00 1.00 0.00 96.00
10:48:30 all 100.00 0.00 0.00 0.00 0.00
10:48:31 all 100.00 0.00 0.00 0.00 0.00
02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused
02:29:31 200948 53228 20.94 530104 0 0.00
02:31:31 199136 55040 21.65 530104 0 0.00
02:33:31 198824 55352 21.78 530104 0 0.00
02:35:31 199200 54976 21.63 530104 0 0.00
02:27:31 IFACE rxpck/s txpck/s rxbyt/s txbyt/s
02:29:31 eth0 738.79 741.66 76025.55 136941.85
02:31:31 eth0 743.30 744.97 76038.82 136907.77
02:33:31 eth0 744.80 745.02 76135.53 136901.38
02:35:31 eth0 742.35 744.34 75947.45 136864.77
Metodologia — Las Herramientas de los Testers — Recopilar datos sobre el rendimiento con sar
El programa que se ocupa de recopilar la informacion se llama sadc (system activity data collector o recolector de datos de la actividad del sistema). Obtiene su informacion, principalmente del kernel, a traves del sistema de archivos virtual en /proc. Despues guarda los datos sobre un archivo (uno por dia en /var/log/sa/sarDD, donde DD hace referencia al dia del mes). sar tambien inclulle 2 scripts que se ejecutaran con cron:
* sa1: recopila datos de forma regular.
* sa2: utlizado para crear los informes sintetizados
Un ejemplo de estos script sobre la tabla cron:
# Ejecuta la herramienta de recopilacion de datos cada 10 minutos
*/10 * * * * root /usr/lib/sa/sa1 1 1
# Genera un informe diario del rendimiento de los procesos a la 23:59
59 23 * * * root /usr/lib/sa/sa2 -A
Metodologia — Las Herramientas de los Testers — Creando informes para medir el rendimiento del sistema
Si los informes diarios creados por el script sa2 no son suficientes, puedes crear los tuyos propios utilizando sar. Por defecto este programa obtiene la informacion del archivo de datos del dia actual, a menos que se especifique lo contrario. Para hacer que sar obtenga los datos de un archivo en particular, utilizamos la bandera -f /var/log/sa/saDD. Puedes seleccionar multiples archivos usando varias banderas -f. Dado que muchos de los informes que crea sar tienen un tamaño considerable, puede que quieras redirigir la salida a un archivo.
Para crear un informe basico que muestre el uso de CPU y el porcentaje de tiempo gastado esperando E/S, ejecutamos sar sin ningun argumento:
01:10:00 PM CPU %user %nice %system %iowait %idle
01:20:00 PM all 7.78 0.00 3.34 20.94 67.94
01:30:00 PM all 0.75 0.00 0.46 1.71 97.08
01:40:00 PM all 0.65 0.00 0.48 1.63 97.23
01:50:00 PM all 0.96 0.00 0.74 2.10 96.19
02:00:00 PM all 0.58 0.00 0.54 1.87 97.01
02:10:00 PM all 0.80 0.00 0.60 1.27 97.33
02:20:01 PM all 0.52 0.00 0.37 1.17 97.94
02:30:00 PM all 0.49 0.00 0.27 1.18 98.06
Average: all 1.85 0.00 0.44 2.56 95.14
* Si %idle (desocupado) esta cerca de cero, la CPU entonces esta sobrecargada.
* Si el valor %iowait(espera por e/s) es grande, tus discos estan sobrecargados.
Para comprobar como se comporta el fichero de paginacion, ejecuta sar -B para obtener un informe similar al siguiente:
11:00:00 AM pgpgin/s pgpgout/s fault/s majflt/s
11:10:00 AM 8.90 34.08 0.00 0.00
11:20:00 AM 2.65 26.63 0.00 0.00
11:30:00 AM 1.91 34.92 0.00 0.00
11:40:01 AM 0.26 36.78 0.00 0.00
11:50:00 AM 0.53 32.94 0.00 0.00
12:00:00 PM 0.17 30.70 0.00 0.00
12:10:00 PM 1.22 27.89 0.00 0.00
12:20:00 PM 4.11 133.48 0.00 0.00
12:30:00 PM 0.41 31.31 0.00 0.00
Average: 130.91 27.04 0.00 0.00
Puede que el número de veces que se ha tenido que recurrir a la paginación no sea determinante, pero el que exista un alto número de fallos mayores de página (majflt/s) indica que el sistema necesita más memoria.
Para obtener estadísticas de red, utilizamos sar -n DEV. Este comando genera un informe que muestra estadísticas con los datos transmitidos y recibidos para cada interfaz de red. Veamos una versión abreviada de este informe:
11:00:00 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s
11:10:00 AM lo 0.62 0.62 35.03 35.03
11:10:00 AM eth0 29.16 36.71 4159.66 34309.79
11:10:00 AM eth1 0.00 0.00 0.00 0.00
11:20:00 AM lo 0.29 0.29 15.85 15.85
11:20:00 AM eth0 25.52 32.08 3535.10 29638.15
11:20:00 AM eth1 0.00 0.00 0.00 0.00
Para ver los errores de red, prueba con el comando sar -n EDEV
Metodologia — Las Herramientas de los Testers — Creando informes para medir el rendimiento del sistema — Informes en tiempo real
También podemos utilizar sar para ver que está pasando en este preciso momento con un componente del sistema. Si le pasamos un intervalo de tiempo (en segundos) y el número de informes a producir, podemos obtener información inmediata sobre un posible cuello de botella.
Por ejemplo, para ver el informe básico cada segundo durante los próximos 10 segundos, usaríamos sar 1 10. Cualquiera de las combinaciones de banderas anteriores se pueden ejecutar con estos parámetros para obtener resultados cercanos al tiempo real.
Metodologia — Las Herramientas de los Testers — Recopilar datos sobre el rendimiento con sar — Fugas de rendimiento (extra topic)
Fuera del tema de las pruebas de strees en linux. Si sospechas que puede existir algun problema de rendimiento con cierto programa en particular que ya le causa bastante stress a tu sistema gnu/linux, tambien puedes utilizar sadc para recopilar datos sobre ese proceso(-x), o sus hijos(-X), pero necesitaras crear tu propio script que use estas banderas.
Incluso si contamos con potencia de sobra para correr nuestras aplicaciones, sar siempre puede ser útil para registrar cambios en el volumen de trabajo a lo largo del tiempo. Para hacer esto, guardaremos los informes (sar sólo guarda siete) en un directorio diferente durante un periodo de tiempo de unas pocas semanas o un mes. Este grupo de informes pueden servir como ejemplo del volumen de trabajo normal del sistema. Se pueden comparar los siguientes informes con estos resultados previos para ver cómo cambia el volumen de trabajo con el tiempo. Podemos incluso automatizar estos informes usando python, ruby, perl.
En la gestión de grandes sistemas, las pruebas de rendimiento son importantes para predecir qué hardware actualizar y cuándo hacerlo. También nos proporciona datos con los que justificar estas actualizaciones.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux
Stressar un sistema no significa que le haremos un benchmark, significa que le daremos una carga especifica para cada uno de sus subsistemas (cpu,user,nice,system,irq,softirq,iowait,idle). Los siguientes screenshots fueron realizados sobre un equipo llamado rome con 8 cpu(s).
Utilizare la herramienta top (tambien lo puedes hacer con sar si asi lo deseas) y la herramienta stress para mandarle cargas de trabajo a rome.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo nula
Como ya estaras viendo en este screenshot, se muestran 2 terminales, una que espera cualquier orden especifica sobre bash y la otra ejecutando top (para visualizar el modo de multiples cpu(s) precione C en top).
Actualmente el sistema se encuentra en lo que podriamos llamar un estado muy relax. Tan solo habra que dar un vistazo a %idle cuyos niveles estan muy cerca del 100%.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para los CPU(s)
Sobre este screenshot, observa como al saturar las CPU(s) de carga, %idle se acerca cada vez mas a 0% y las CPU(s) cada vez mas al 100% de su saturacion.
Aqui la app stress es lanzado con 8 procesos sqrt(), lo que significa que ejecutaran 8 multiples ciclos infinitos de raices cuadradas.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para las llamadas al sistema
En este screenshot observa como el parametro -i 4 , introduce 4 ciclos infinitos que ejecutan la llamada al sistema sync(), generando con esto carga de trabajo para el subsistema system.
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Carga de trabajo para los discos
Ejecutaremos con stress una carga de escritura de 3gb para los discos, observe como se dispara el %iowait:
Una vez finalizada la carga de trabajo, observa que en el directorio donde ejecutaste la app stress se te genero un archivo ascii producto de esta carga de trabajo realizada para el disco ( un archivo ascii de 3.0 gb ).
Las herramientas de los testers — Provocando stress a nuetro sistema GNU/linux — Mas informacion sobre la app stress
El formato para correr la aplicacion stress es la siguiente:
stress [opciones [args]] ...
stress suporta las siguientes opciones:
`-?'
`--help'
Show help information.
`--version'
Show version information.
`-v'
`--verbose'
Turn up verbosity.
`-q'
`--quiet'
Turn down verbosity.
`-n'
`--dry-run'
Show what would have been done.
`-t secs'
`--timeout secs'
Time out after secs seconds.
`--backoff usecs'
Wait for factor of usecs microseconds before starting work.
`-c forks'
`--cpu forks'
Spawn forks processes each spinning on `sqrt()'.
`-i forks'
`--io forks'
Spawn forks processes each spinning on `sync()'.
`-m forks'
`--vm forks'
Spawn forks processes each spinning on `malloc()'.
`--vm-bytes bytes'
Allocate bytes number of bytes. The default is 1.
`--vm-hang'
Instruct each vm hog process to go to sleep after allocating memory. This contrasts with their normal behavior,
which is to free the memory and reallocate ad infinitum. This is useful for simulating low memory conditions on a machine.
For example, the following command allocates 256M of RAM and holds it until killed.
% stress --vm 2 --vm-bytes 128M --vm-hang
`-d forks'
`--hdd forks'
Spawn forks processes each spinning on `write()'.
`--hdd-bytes bytes'
Write bytes number of bytes. The default is 1GB.
`--hdd-noclean'
Do not unlink file(s) to which random ASCII data is written.
Nota: Sufijos pueden ser s,m,h,d,y (para tiempo) o k,m,g (para tamaño).
Conclusiones
La cantidad de carga de trabajo que puedes asignar con la app stress, es algo muy variable, ya que la app stress al permitir combinar sus diferentes opciones de carga, te permitira la ejecucion de multiples pruebas combinadas. Y gracias a las herramientas sar y top, la medicion de recursos del sistema ya sea a modo de estadistica a intervalo de tiempo (con sar) o de informacion en el momento (con top), estaran siempre a disposicion de cualquier administrador de sistema gnu/linux.
