6.4. Sintonia de desempenho com GFS2

Geralmente é possível alterar a forma como uma aplicação problemática armazena seus dados a fim de obter uma vantagem considerável de desempenho.

Um exemplo típico de uma aplicação problemática é um servidor de e-mail. Estes são freqüentemente dispostos com um diretório spool contendo arquivos para cada usuário (mbox), ou com um diretório para cada usuário contendo um arquivo para cada mensagem (maildir). Quando os pedidos chegam por IMAP, a disposição ideal é dar a cada usuário uma afinidade com um nó em particular. Dessa forma, suas solicitações para visualizar e excluir mensagens de e-mail tenderão a ser servidas a partir do cache daquele nó. Obviamente, se esse nó falhar, então a sessão poderá ser reiniciada em um nó diferente.

Quando o correio chega por meio de SMTP, então novamente os nós individuais podem ser configurados de forma a passar um determinado correio do usuário para um determinado nó por padrão. Se o nó padrão não estiver ativo, então a mensagem pode ser salva diretamente no spool de correio do usuário pelo nó de recebimento. Mais uma vez, este projeto visa manter conjuntos particulares de arquivos em cache em apenas um nó no caso normal, mas para permitir acesso direto no caso de falha do nó.

Esta configuração permite o melhor uso do cache de páginas do GFS2 e também torna as falhas transparentes para a aplicação, seja imap ou smtp.

O Backup é muitas vezes outra área complicada. Novamente, se for possível, é muito preferível fazer o backup do conjunto de trabalho de cada nó diretamente do nó que está armazenando aquele conjunto particular de nós. Se você tem um script de backup que roda em um ponto regular no tempo, e isso parece coincidir com um pico no tempo de resposta de uma aplicação rodando no GFS2, então há uma boa chance de que o cluster possa não estar fazendo o uso mais eficiente do cache de páginas.

Obviamente, se você estiver na posição de poder interromper a aplicação para realizar um backup, então isto não será um problema. Por outro lado, se um backup for executado a partir de apenas um nó, então, depois de ter completado uma grande parte do sistema de arquivos será colocado em cache naquele nó, com uma penalidade de desempenho para acessos subseqüentes a partir de outros nós. Isto pode ser mitigado, até certo ponto, deixando cair o cache de páginas VFS no nó de backup depois que o backup for completado com o seguinte comando:

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

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

No entanto, esta não é uma solução tão boa quanto o cuidado de garantir que o conjunto de trabalho em cada nó seja compartilhado, em sua maioria somente de leitura, ou acessado em grande parte a partir de um único nó.