A muchas personas les sucede, yo soy una de ellas, que al tener el disco una escritura “heavy”, como al crear un disco de virtualbox de 1GB o 10GB, eso no importa, el sistema no responde hasta que termine de crearlo, o responde por momento, es decir, si dan click en una aplicacion, esta no abre, o si abre, no se cierra, etc.
Esto ocurre porque Linux tiene un sistema de flusheo de caches asi como writeback muy bien logrado, claro, me dirán, pero… entonces porque pasa esto?.
Justamente, por eso, si miran bien, en Windows 7 esto no sucede con virtualbox, porque su sistema de escritura a disco es pobre, de hecho, tengo mayor transferencia de MB/s en Linux que en Windows, en todas mis PC.
Ahora bien, esto sucede porque existen 3 demonios en esta cuestion, llamados jbd2 y flush (antiguo pdflush).
Que son?
jbd2
Journaling Block Device. Es un block device generico, que se encarga de la capa de jornaling en Linux.
Esto se encarga de los journal, si usan ext3/4, usan esto.
El jornal es lo que hace que al reiniciar la PC de forma brusca, sin apagarla, no pierdan datos, asi como actualizar los datos de acceso, modificacion y creacion de archivos.
Si bien en /etc/fstab puede usarse noatime, yo no lo recomiendo, dado que, les doy un ejemplo:
Han sido hackeados, expliquenme como realizan un analisis forense sin poder ver quien accedio, cuando, a que hora a iptables?, chroot?, su, etc?, no pueden.
Asi que la opcion mas recomendada es relatime, que solo actualiza los accesos cuando estos son superiores a la fecha existente
flush
El proceso flush, ex pdflush, es un proceso que se encarga de copiar los datos antiguos de la pagecache a disco. Es el demonio que se encarga de volcar a disco lo que vimos en un post anterior, sobre el subsistema /vm.
Con el comando cat /proc/sys/vm/nr_pdflush_threads, pueden ver, como es obvio, los hilos actuales
# cat /proc/sys/vm/nr_pdflush_threads
– /proc/sys/vm/dirty_background_ratio: Indica que a partir de que porcentage de la memoria el daemon va a empezar a copiar datos. Por defecto es el 5%(aunque en algunas versiones es el 10%)
– /proc/sys/vm/dirty_writeback_centisecs: Indica el periodo que va a tardar a levantar cada vez para comprobar si hay datos que escribir a disco. Este valor se expresa en centésimas de segundo, por defecto es medio segundo.
– /proc/sys/vm/dirty_expire_centisecs: Indica que dato lo considera suficientemente “viejo” para pasarlo a disco la próxima vez que levante el daemon. Igual que el valor anterior se expresa en centésimas de segundo, siendo por defecto 2999
Ahora bien, que sucede con estas dos cosas que se pone el sistema un poco freezado cuando creamos una maquina virtual, o bien cuando no se, escribimos fuertemente unos 10GB de archivo?.
Basicamente, estos procesos, corren como se les indica, y por defecto, no se les indica nada, para eso existe un comando llamado ionice.
Tambien otro llamado iotop, que ahora veremos.
Los invito a crear un disco VDI en virtualbox, de unos 10GB, y cuando hayan pasado 30 segundos de que comenzo a crearse, miren, como root, iotop asi:
# iotop
Van a ver que flush y jbd2 estan al 99%, haciendo lo que virtualbox les pide, bien, esto es lo que produce que el sistema no responda.
Soluciones caras?, comprar un disco SSD rapido, un disco de 7200 RPM o mejor 10000 RPM, pero, si no queremos gastar, menos en Argentina, donde 1 dolar nos cuesta 6 pesos ARS, ademas no poder comprarse actualmente, podemos hacer un tuning con esto.
El comando ionice, asi como renice, o nice, determina la prioridad de I/O, por eso se llama IOnice (lo puse en mayuscula para que lo noten).
Ahora bien, de forma automatica, podemos indicarle a ionice, que los procesos flush y jbd2, esten en idle y no en real time, sobre todo en mi caso que uso un kernel real time, bueno… al no tener un disco SSD, esto es un problema.
Para dicha tarea, realice un script, que hace todo de forma automatica y es el siguiente, ahora explico como se usa, y demas, pero copien y pegen esto en un gedir, kwrite o lo que usen
#!/bin/sh
# Author: SynFlag
# Licence: GPLv2
# Name: high_io
# Description: Relieves the HDD I/O under high load
# For use: Replace “sda5” for the sdaX of your /home or where VirtualBox or other software, make a very high disk I/O load
# Wait 10 seconds for the initialization of the system and get the PID of the daemons
sleep 10
# Set the variables with the PID of _all_ jbd2 and flush
sdaX=`ps ax | egrep [j]bd2/sda5 | awk ‘{print $1}’`
flushX=`ps ax | egrep [f]lush | awk ‘{print $1}’`
# Put the jbd2 (writeback) on idle mode
ionice -c 3 -p “$sdaX”
# Put the flush (older pdflush) on idle mode
ionice -c 3 -p “$flushX”
# Clean variables
unset sdaX
unset flushX
Abren un nano, vim o lo que usen, y hacen
# nano /usr/local/bin/high_io
Pegan el contenido del script, que ya tienen en gedit o kwrite o algo, dentro de nano o vim, o lo que usen, guardan y salen. Luego:
# chmod +x /usr/local/bin/high_io
Ahora, editan esto:
# nano /etc/rc.local
Colocan alli
/usr/local/bin/high_io &
Salvan y salen.
Reinician la PC, y prueben nuevamente, de crear un disco de virtualbox, observen que las aplicaciones responden y que el iotop no esta mas al 99%, sino algo mas moderado.
Basicamente, lo que hacemos es tomar el PID de los procesos flush y jbd2, y darles prioridad idle.
Eso hace el script, que espera 10 segundos antes de tomar las variables, para que los procesos esten iniciados, por eso en rc.local ponemos &, para que se inicie en segundo plano y no detenga el inicio del sistema, ni en X ni en runlevel 3.
Asi mismo, ustedes deben colocar donde dice [j]bd2/sda5 en el script, con el /dev/sdaX que sea su /home, siempre recomiendo separarlos al momento de particionar.
Porque es esto?, porque virtualbox por defecto, realiza la carga enorme en /home, donde escribe el .vdi de 10Gb, y queremos que ese sea “idleado”, no / donde se alojan binarios de constante ejecucion.
Bueno, si tienen alguna duda o no entendieron algo, me dejan comentarios y los responderé, aunque no los vean posteados, yo los veo, los publico y respondo en en blog y por mail de ser necesario.
.
.
HACK THE SYSTEM 