2.9.2. Ajuste de rendimiento con GFS2

Usualmente es posible alterar la forma en que una aplicación problemática almacena sus datos para obtener una ventaja considerable en el rendimiento.

Un ejemplo típico de una aplicación problemática es un servidor de correo-e. A menudo se establece con un directorio de cola que contiene los archivos para cada usuario (mbox), o con un directorio para cada usuario que contenga un archivo para cada mensaje (maildir). Cuando llegan solicitudes sobre IMAP, el mecanismo ideal es dar a cada usuario una afinidad a un nodo particular. De este modo sus solicitudes para ver y eliminar mensajes de correo electrónico tenderán a ser servidas desde otra memoria cache en ese nodo único. Obviamente, si ese nodo falla, la sesión se reiniciará en un nodo diferente.

Cuando un correo llega a través de SMTP, los nodos individuales pueden configurarse como para pasar algún correo de usuario a un nodo particular predeterminado. Si el nodo predeterminado no está activado, entonces el mensaje puede ser guardado por el nodo que lo recibe. De nuevo, este diseño es para conjuntos de archivos particulares en memoria cache en solo un nodo en el caso normal, pero permite acceso directo en caso de fallar un nodo.

Esta configuración usa la memoria cache de página de GFS2 y también hace transparente las fallas a la aplicación ya sea imap o smtp.

Las copias de seguridad son otra área engañosa. Es posible y preferible hacer copias del conjunto de trabajo de cada nodo de forma directa desde el nodo en el que se está guardando en cache ese conjunto particular de inodos. Si tiene un script de respaldo que se ejecuta en un momento determinado y que parece coincidir con un punto máximo en tiempo de respuesta de una aplicación ejecutándose en GFS2, entonces es muy probable que el cluster no esté haciendo el uso más eficiente de la cache de página.

Obviamente, si está en la posición envidiable de poder detener la aplicación para realizar una copia de seguridad, entonces no habrá problema. Por otra parte, si la copia de seguridad se ejecuta solamente desde un nodo, entonces después de haber completado una gran porción del sistema de archivos será puesta en memoria en ese nodo, con una pena de rendimiento para accesos posteriores desde otros nodos. Esto se puede mitigar hasta cierto punto, colocando la cache de página VFS en el nodo de respaldo después de que la copia de seguridad haya completado con el siguiente comando:

echo -n 3 >/proc/sys/vm/drop_caches

Sin embargo, esa no es una buena solución, es mejor asegurarse de que el conjunto de trabajo en cada nodo sea compartido, principalmente leído solo a través del cluster o accedido ampliamente desde un nodo único.