Linux es un sistema operativo que en general se distribuye de forma que pueda ser ejecutado en la mayoría de las máquinas existentes.
Debido a esto, es un sistema que viene sin muchas optimizaciones para una máquina en específico porque podría ser perjudicial para otra.
Aquí listamos algunos consejos sobre cómo optimizar nuestro servidor linux para mejorar el performance.
Este artículo lo publique el 02-Dic-2003 en la página de ecualug.org
La situación es bien simple: con la configuración por defecto que vienen los linux, cada vez que se accede a cualquier archivo del sistema linux actualizá el inodo de este archivo con la hora actual, marcando así lo que se llama access time: la última vez que se accedió.
¿Qué tal con un servidor que tenga apache y sendmail entre otros binarios, que son llamados constantemente? ¿O que tenga cientos o miles de buzones de usuarios que son leídos constantemente?: Pues bueno, linux se tomará la molestia de actualizar el accestime (atime) del inodo que referencia al buzón de los usuarios con el tiempo de acceso, generando una escritura más.
Con un servidor ligeramente usado (dígase una carga de procesador mayor a 0.7) ya se puede notar una ventaja, si montamos las particiones de éste con la opción de atime desactivada.
Probemos primero, esta prueba no debe ser destructiva, al momento no me ha fallado nunca: solamente remontemos una partición, digamos /var con la opción noatime para desactivar los tiempos de acceso:
mount (para ver cómo tenemos montada la partición y si existe esta. De no existir usen otra de prueba.)
w (para ver la carga del procesador anotar la carga)
y ahora procedamos a remontar con noatime:
mount -o remount,noatime /var
remontamos con la opción noatime a /var
esperemos un rato, y si nuestro servidor tenía una carga apreciable, veremos que ésta ha disminuido un poco.
w (comparemos la carga con el comando w anterior)
En servidores ligeramente cargados ésta opción no tiene sentido, ya que no se notará la diferencia.
Debo aclarar que esta opción de todas formas, no nos daña en lo absoluto el normal funcionamiento de nuestros servidores.
La podemos poner en todas las particiones que tengamos formato ext2 y ext3 (la he probado con Unix Tru64 e igual funciona de bien). No la pongan en swap, swap para comenzar no tiene inodos !!! Igual no debe aceptar que la pongas en swap.
Para levantarla cada vez que querramos, sencillamente agregamos la opción noatime al lado de la palabra default en /etc/fstab, aquí va una línea de ejemplo del fstab:
[root@ecualinux hosting]# cat /etc/fstab
LABEL=/ / ext3 defaults 1 1
La idea es poner en cada partición (ext2, ext3) la palabra noatime además:
LABEL=/ / ext3 defaults,noatime 1 1
Así cada vez que levante el sistema, tendremos esta opción habilitada. Repito, no afecta para nada el poner esta opción en cada partición ext2/3 que tengamos.
¿Qué logramos con esto? Disminuir los accesos de escritura (por demás lentos) al disco duro y ayudar a aumentar el performance del sistema.
Aunque no soy partidario de incrementar la swap, en realidad a veces sí nos hace falta.
En este artículo explicaremos cómo agregar mas swap al sistema sin tener siquiera que reiniciarlo. Para crear espacio swap no hay una ley definida, hay quien tiene por regla de oro el poner de swap 2 veces el tamanno de la RAM. Hay quien pone una sola vez el tamanno de RAM.
Yo, si mi maquina tiene menos de 512MB de RAM, pongo 2XRAM, si tiene mas de 512MB de RAM, pongo el mismo tamaño.
Pero ocurre a veces que ponemos digamos, 256M de swap porque teníamos 128 de RAM, qué pasa si un día incrementamos la RAM de la maquina a 512M por ejemplo, cómo hacemos para poner algo apropiado como digamos 1GB de SWAP?
Lo común es acomodar las particiones reinstalando el linux, o usando alguna utilería para acomodarlas, otra variante es poner un disco extra y ahi crear la nueva swap.
Bueno, yo no tenía ninguna de esas opciones, tenía que incrementar mi swap puesto que le habia agregado esa memoria a mi servidor (512MB) y solamente había 128MB de SWAP. Mis servidores estan en Norteamérica, no he tenido la suerte de ni siquiera ver como son mis servidores.. por lo tanto, tenia que encontrar alguna forma de incrementar la swap sin ninguna de las variantes anteriores y sin acceso físico al servidor.
Esto es muy simple, linux, desde los kernel 2.2 permite usar ficheros como espacio de swap. La idea entonces es crear un fichero de unos 256mb para agregárselo a mi espacio de swap actual.
Bueno, ¿cómo hacer? Veamos:
Primero reviso que swap existe en mi sistema:
free -m
Creo con dd un archivo llamado swap dentro de /home con un tamaño de 256M (262144K)
dd if=/dev/zero of=/home/swap bs=1024 count=262144
A este archivo lo convierto en swap:
mkswap /home/swap
Le quito algunos derechos innecesarios:
chmod go-rwx /home/swap
Activo la swap:
swapon /home/swap
Y ahora compruebo como ha cambiado la swap de mi sistema:
free -m
Si reinicio el sistema, se perderá esta memoria swap, por lo que, si vemos que la solución ha sido efectiva, debemos proceder a activar la swap desde el fstab por ejemplo:
editamos /etc/fstab y agregamos la siguiente linea:
/home/swap swap swap defaults 0 0
Esto levantará la swap con este fichero además de la swap original que tenía el sistema.
Supuestamente linux puede tener 8 particiones swap, cada una con hasta 2GB de tamaño. En éste caso sencillamente hemos agregado una 2 swap.
Para finalizar: no es una solución el agregar swap bajo ciertas condiciones. Lo mejor es agregar memoria y revisar qué pasa que esta consumiendo memoria.
Agregar swap no es una solucion común a problemas de memoria. Recomiendo esta opción cuando hemos cometido un error y hemos puesto poca swap al sistema o cuando hemos agregado mucho mas memoria que la original y ahora la swap nos queda pequeña.
La próxima vez hablaremos sobre como mejorar un poco la seguridad en nuestros sistemas sin tener que invertir mucho mas que un poco de seso.
La forma más común de hacer respaldos, ya sea a cinta o a disco o a cualquier medio de almacenamiento, está siendo el comando tar. En realidad es un comando antiguo, probado, realmente casi siempre funciona para hacer respaldos.
¿Cómo hacer respaldos con tar?
Bien simple, supongamos que tenemos una cinta, normalmente localizada en /dev/st0 y queremos hacer un respaldo de los directorios de home, los logs y los archivos de configuración. Un buen acercamiento sería:
tar -cf /dev/st0 /var/log /home /etc
Este comando haría un paquete sin comprimir en formato tar. De los directorios /var/log, /home y /etc
Para hacer un paquete pero guardar comprimido este, pongámosle una z o una j:
tar -zcf /dev/st0 /var/log /home /etc
Esto comprimiría en gzip antes de pasar a la cinta. Este comando usa mucho más procesador y posiblemente más memoria que el comando que no comprimía pero guardará en menos espacio los respaldos.
Si queremos comprimir en formato BZIP2 (mucho más compacto pero demorado):
tar -jcf /dev/st0 /var/log /home /etc
Si no tuviéramos cinta, podemos en vez de mandar a un dispositivo de cinta, mandar el paquete a otro disco, supongamos está montado en /backup:
tar -zcf /backup/respaldo.tar.gz /var/log /home /etc
Así haríamos un respaldo a otro disco de los directorios antes mencionados.
Ahora, el comando tar tiene ciertas dificultades ya probadas por nosotros. Y es que al realizar respaldos muy grandes, tiende a dejar de responder y a veces hasta nos echó la máquina al piso.
Por eso aquí veremos otro comando más moderno llamado star. Definitivamente hemos comprobado que es un gran porcentaje (posiblemente 25% más rápido) que el antiguo tar. Y es más eficiente en el manejo de memoria y procesador por lo que en máquinas que demoraban un mundo o fallaban haciendo un respaldo con tar hemos logrado hacer los respaldos usando star sin mayor complicación.
Al momento la utilidad star es la más rápida conocida que imita al tar. Se ha comprobado que puede trabajar a velocidades superiores a 14mbit/s y que ofrece una tecnolocía de doble buffering que mantiene la unidad de cinta alimentada con datos constantemente.
El star comenzó a implementarse por el año 1982 y sigue siendo un trabajo en progreso. Es muy eficiente además con respaldos mayores a 1GB y es capaz de manejar una enorme cantidad de archivos (inodos) sin mayor uso de memoria.
El star tiene cierta compatibilidad con el tar, es capaz de abrir archivos hechos en tar.
Definitivamente por todas estas razones y muchas más, aqui pondremos el procedimiento para usar el star.
¿Cómo hacer respaldos con star?
Primero verificar que tengan el comando star en la máquina, en redhat y clones de redhat, está en un paquete aparte que se llama star, buscar este rpm e instalarlo si es que no está instalado ya en el sistema. Este paquete no sobreescribe al tar, siguen siendo dos comandos apartes e independientes.
yum install star
Seguidamente, hagamos el respaldo, comencemos con el más simple:
star -cv f=/dev/st0 /var/log /home /etc
Con este comando haríamos un respaldo (como el ejemplo anterior de: tar -cf /dev/st0 ...) a cinta.
Si queremos comprimirlo:
star -zcv f=/dev/st0 /var/log /home /etc
Esto lo comprimiría con gzip. No conocemos de compresión vía bzip2 de forma directa.
Si queremos hacer un respaldo a archivo en vez de cinta pondríamos:
star -cv f=/backup/respaldo.tar /var/log /home /etc
y listo, crearía el tar en un archivo dentro de un directorio.
¿Cómo se abre un archivo star?
star -xv f=/dev/st0
abriría todos los contenidos.
Si deseamos solamente un directorio o archivo en específico, se lo hacemos saber con el nombre al lado, sin / inicial:
star -xv f=/dev/st0 etc/passwd
este sacaría sólo /etc/passwd y nada más de todo el respaldo, lo que me permitiría recuperar cierto archivo si conozco su nombre o directorio.
Definitivamente consideramos por la capacidad que puede trabajar el star, que este es el recomendado para manejar grandes cantidades de archivos dispersos o respaldos mayores a 1GB, es mucho más rápido en estas circunstancias y seguro les dará menos problemas de performance.
Bueno, sigo con los discos.
Lamentablemente la mayoría de los discos son mecánicos y los medios mecánicos son sumamente lentos comparados con los medios electrónicos (memorias, procesadores, etc). Aquí veremos cómo pedirle a nuestro linux que disminuya accesos a disco evitando las escrituras síncronas al syslog
Y bueno pues, ya hemos hecho todo lo posible por optimizar el disco montándolo con noatime y ajustándole los parámetros con hdparm, pero la máquina sigue con algunos problemas de performance.
Sobre todo las máquinas que manejan mensajería (en grandes cantidades, digamos, 1 millon o más de mails al día). El mail, genera muchos accesos a disco pues se escribe en /var/log/maillog por cada mail que llega al menos dos líneas, una para el remitente y otra para el destinatario, sin contar los logs que se hacen del que hace pop o imap y cuando una conexión falla y hay que repetirla o rebotarla.
Una máquina que procesa más de un millon de mensajes diarios está generando al menos 2 millones de escrituras. Una opción es reducir la verbosidad de los logs del sendmail. Pero la primera que debemos tomar es la de reducir los accesos del syslog a disco.
Sendmail, al igual que muchas utilerías, usan al syslog para enviar sus mensajes a los logs, y lo interesante es que podemos indicarle al syslog que no escriba de forma síncrona (es decir, cada vez que llegue un mensaje escribirlo inmediatamente al disco) sino asíncrona (cada cierto tiempo cuando estime que ya debe escribir).
De esta forma he logrado reducir máquinas con carga de hasta 6 a menos de 1 pues la mayoría de los recursos de acceso a disco estaban siendo consumidos por el syslog escribiendo a disco. ¿Cómo lo hacemos? Veamos:
esto le indica al syslog dónde escribir cada tipo de mensaje, pero además le indica que lo haga de forma síncrona. La forma de indicarle que lo haga asíncronamente es bien simple, sólo agreguemos un - al inicio del camino, de esta forma:
Fíjense que - va inmediatamente delante del camino, sin espacios ni nada, así podemos ponerle a cada linea del syslog el - para indicarle al syslog que escriba asíncronamente ahorrándonos seguramente accesos a disco y evitando procesos bloqueados en el SO esperando por accesos a disco.
Parece tonto, pero realmente ayuda mucho a sistemas medianamente cargados, y para los que tengan sistemas poco cargados, no importa, pueden poner lo mismo, no les afectará en nada, sólo que posiblemente tampoco les ayudará, esto sería porque si los logs son bien pocos igual los accesos a disco son bien esporádicos y no ayudaría nada la escritura asíncrona.. o muy poco, pero uno nunca sabe cuándo se nos puede ocupar el sistema de verdad por eso, pónganlo.
Ah, para activar esto, debemos reiniciar el proceso de syslog:
killall -HUP syslogd
Esto hará que se relea la configuración o para los que tenemos redhat o whitebox podemos:
service syslog reload
o
/etc/rc.d/init.d/syslog reload
cualquier alternativa es válida siempre y cuando logremos que se relea la configuración, es más, reiniciando la máquina también reinicia el servicio. Pero no me parece tan acertado llegar a esos extremos.
En todo caso, espero esto les ayude. Y hasta otro día.
Muchos, muchísimos, seguimos teniendo y seguiremos usando discos IDE para manejar nuestros servidores y máquinas de desktop. En este artículo veremos cómo hacer para optimizar un poco los accesos a nuestro disco duro.
Simple: las distribuciones de linux instalan por defecto sin hacer mucho esfuerzo en optimizar los accesos a disco. Y la razón es muy lógica.. los discos son muy variados, y es virtualmente imposible una receta mágica para que todos los discos den lo mejor de sí.
En este artículo, veremos unos simples parámetros que podemos cambiar usando la utilería hdparm.
Advertencia: Estos cambios pueden hacer que el disco duro deje de funcionar. Es más, estos cambios pueden eventualmente echar a perder la información y hasta dañar el disco propiamente.
Aunque nunca he tenido ningun problema más que el de reiniciar la máquina porque el disco deje de responder, nunca está de más advertir que cualquier cambio que haga, lo debe hacer bajo su total responsabilidad
1- Verifiquemos que tenemos la ultilería hdparm, para los que usan una distribución basada en rpm:
rpm -q hdparm
Suponiendo que nuestro disco esté en /dev/hda:
2- verifiquemos los parámetros actuales del disco:
hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 39704/16/63, sectors = 40021632, start = 0
3- Miremos y anotemos los parámetros de performance de nuestro disco antes de hacer cuqlquier cambio:
hdparm -tT /dev/hda
aqui están los resultados de mi disco antes de optimizarlo:
Timing buffer-cache reads: 128 MB in 0.36 seconds =357.54 MB/sec
Timing buffered disk reads: 64 MB in 14.33 seconds = 4.47 MB/sec
Estos son los resultados después de optimizado (ejecutando hdparm -tT nuevamente):
Timing buffer-cache reads: 128 MB in 0.33 seconds =390.24 MB/sec
Timing buffered disk reads: 64 MB in 4.63 seconds = 13.82 MB/sec
Si ven, los parámetros que el hdparm mide, se han incrementado, en algunos caso unas 3 veces. (buffered disks reads)
Yo siempre me centro en varios parámetros de estos, por ejemplo el IO support está en el valor por defecto de 16 bits.. cuando los discos mayormente soportan 32bits, PIOs, etc. Esto hay que cambiarlo.
using DMA, direct memory access. Si compramos discos con soporte para DMA cómo no activarlo?
multicount: cuántos sectores se leen con un acceso del cabezal, normalmente aumenta el performance en un 30%-50%
Ahora comencemos poquito a poco, si el disco deja de responder, lamentablemente hay que apretar ese botoncito que dice reset:
hdparm -c3 -m16 /dev/hda
Aquí hemos activado 32bits (-c3) así como multicount (-m) a 16.. el multicount lo podemos llevar hasta 32 a veces.
Procedamos a probar de nuvo nuestro disco:
hdparm -tT /dev/hda
Supongo que hayan anotado previamente los datos del -tT anterior. Comparen y vean si ha aumentado o no, si no ha aumentado, es que algún parámetro en vez de ayudar al disco de ustedes, lo afectó.
En mi caso, esto casi dobló los accesos a discos.
Sigamos:
/dev/hda:
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
setting xfermode to 34 (multiword DMA mode2)
unmaskirq = 1 (on)
using_dma = 0 (off)
En mi caso, no pude activar el DMA, posiblemente porque no lo tengo activado en el BIOS, es de asegurarse que lo esté, el DMA sí ayuda muchísimo en los accesos. En mi caso no puedo reiniciar la máquina pues es en la que todos compilamos los paquetes pero por lo demás, activé unmaskirq y el modo de transferencia lo puse a multiword DMA modo 2. Este comando -X se puede poner más descriptivo, algo así como: -X udma2 (tal y como sale en hdparm -i /dev/hda)
A mí personalmente no me mejoró, pero supongo que haya sido porque no pude activar el DMA, pero si a ustedes le trabaja, mejor, mode2 es PIO2, si el disco de ustedes es PIOotronúmero entonces busquen el parámetro adecuado para mejorar los accesos.
A propósito, posiblemente los discos de muchos hayan dejado de funcionar, porque no soporta X34 , prueben con:
[code]hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda
Al final de las pruebas, ya muchos tendrán idea de qué parámetros les sirven y cuáles no, los que les sirvan, los pueden unir en una sola llamada al hdparm y ponerlo en /etc/rc.d/rc.local para que se ejecute cada vez que linux comience.
Espero les ayude a mejorar un poquito los accesos a discos. Recuerden, el mayor cuello de botella ahora, son los accesos por el bus de datos a los dispositivos mecánicos, discos por ejemplo, por lo tanto no hacemos nada con tener una super máquina con 5Ghz de velocidad, 10 procesadores y un disco mal optimizado