Ya me voy acercando y una vez en el servidor, ¿qué más puede provocar cuellos de botella?. El acceso a los datos.

Ver también:

Sistema de archivos⌗

Tras años de jugar en cuanto sistema de archivo existente en Linux, más que benchmarks y anotaciones sagradas tengo experiencias, sesgadas probablemente, pero no menores. Manteniendo un servidor web, donde en promedio cada archivo servido no tiene mas de 100KB de tamaño en disco, es necesario un sistema de archivos que sea eficiente (y estable) con archivos pequeños.

Mi primera tendencia fue a utilizar XFS, pero pesar de su solidez y rapidez, su comportamiento cuando el sistema de archivos se hace cada vez mas granulado comienza a dar problemas, búsquedas en directorios demasiado grandes se hacen cada vez más lentos. ReiserFS entonces fue mi segunda intención, pero tras varios accidentes (si, ya dije que probablemente sesgados) en donde terminé con sistemas inconsistentes, no graves estadísticamente hablando, pero que se corrompa un httpd.conf con cientos de vhosts no es ninguna gracia (como alguna vez me ocurrió), finalmente descarté ReiserFS tal vez tan solo para tener la conciencia limpia, ya que continúo utilizandolo en mis desktop (al igual que los «filmservers» con XFS).

Me quedaba el viejo y confiable Ext3, sólido, relativo buen rendimiento en sistemas granulados. Era el turno de optimizar al máximo el desempeño de Ext3. Ojo que a continuación hay procesos riesgosos y que pueden provocar que tu perro se ponga verde y se tire por la ventana.

La primera decisión era el utilizar la opción «noatime» en los puntos de montaje donde residen los sitios web. La justificación tras esta decisión es que cada vez que un archivo es leído del fs, es actualizado el ínodo correspondiente al último acceso, por lo tanto esto implica que cada vez que leemos un archivo, tambien debemos escribir. Montando la partición con la opción «noatime» nos obviamos este proceso, claro que no tendremos la información en que fue accedido por última vez el archivo, arma de doble filo en caso de requerir forensics (no es que no se pueda realizar un fake, pero …).

<br /> /dev/hdXX /var/www ext3 rw,noatime 0 2<br />

Solo un problema, Ext3 también tiene problemas realizando búsquedas transversales, pero puede ser mejorado sustancialmente mediante la opción «dir_index», que fuerza el uso de hashed b-trees. Lamentablemente durante la instalación no estaba conciente de esto, por lo que se debió convertir posteriormente mediante tune2fs y luego convertir los directorios con e2fsck.

El primer paso es revisar si ya se encuentra habilitado este comportamiento (en Fedora por ejemplo es el comportamiento por omisión) mediante lo siguiente:

<br /> tune2fs -l /dev/hdXX | grep dir_index<br />

O revisar la salida de tune2fs -l por «Filesystem features». De no encontrarse disponible puedes proceder a convertirla. El proceso de alterar sistemas de archivos ya montados es altamente riesgoso, por lo que utilicé un LiveCD de Ubuntu Breezy que tenía a mano para realizar la operación.

<br /> tune2fs -O dir_index /dev/hdXX<br />

Con esto se habilita la opción en el sistema de archivos, que luego necesitará reconvertir los directorios existentes a los hashed b-tree mediante:

<br /> e2fsck -D /dev/hdXX<br />

Con esto puede ser considerablente mejorada el desempeño de estructuras complejas de directorios como los utilizados por mod_disk_cache.

Existen bastantes otros factores en el sistema de archivos que influyen en el desempeño, pero solo pueden ser modificados al momento de crearse el sistema de archivos, por lo que no aplican en mi caso que ya tenía un sistema andando.

IO Scheduler⌗

A más bajo nivel, quien me puede provocar atochamientos y pisadas de cola es scheduler de acceso a disco. El trabajo del IO scheduler es organizar los requerimientos pendientes de acceso de forma de minimizar los movimientos del cabezal del disco, logrando así tiempos óptimos de acceso y maximizando el ancho de banda logrado.

Actualmente existen tres algoritmos de orden de acceso: anticipatory (as), deadline y cfq, siendo el primero el cual ha sido históricamente utilizado por omisión. Tras cambiar el algoritmo elevador (llamado asi ya que apunta a un problema similar a utilizar óptimamente los elevadores de un edificio como el Empire State) y utilizar cfq (que ha sido cambiado a partir del kernel 2.6.15 como elevador por omisión) el desempeño de los discos se ha incrementado considerablemente elevando el tiempo de respuesta y notoriamente disminuyendo la carga del sistema bajando de unas variaciones de Load Average de entre 10 y 30 a unos míseros 1 a 5 durante el día.

Luego más con los pasos seguidos en apache y mysql.