Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.9.2. Ajuste de Desempenho com GFS2

É possível alterar a maneira em que um aplicativo problemático armazena seus dados para ganhar uma vantagem de desempenho considerável.
Um exemplo típico de aplicativo problemático é um servidor de emails. Estes são frequentemente definidos com um diretório de spool contendo arquivos para cada usuário (mbox), ou com um diretório para cada usuário contendo um arquivo para cada mensagem (maldir). Quando os pedidos chegam via IMAP, a preparação ideal é dar cada usuário uma afinidade a um nó particular. Desta maneira, seus pedidos para vizualizar e deletar mensagens de email tenderão a ser servidos a partir do cache nesse nó. Obviamente se esse nó falhar, a sessão então pode ser reiniciada em um nó diferente.
Quando um email chega via SMTP, então novamente os nós individuais podem ser configurados para passar um email de determinado usuário para um nó em particular por padrão. Se o nó padrão não estiver ativo, então a mensagem pode ser salva diretamente no spool de mail do usuário através no nó de recepção. Novamente esta estrutura pretende manter um conjunto determinado de cache de arquivos em somente um nó em situações normais, mas permitir acesso direto no caso de uma falha do nó.
Esta configuração permite o melhor uso da página de cache do GFS2 and também tornar falhas mais transparentes à aplicação, seja imap ou smtp.
O backup é muitas vezes uma área complicada. Novamente, se possível é recomendado fazer um backup do conjunto de execução de cada nó diretamente do nó que está fazendo cache desses conjuntos de inodes em particular, e isso parece coincidir com um aumento em tempo de resposta de uma aplicação rodando em GFS2, pois há uma boa chance que o cluster pode não estar fazendo o uso mais eficiente da página de cache.
Obviamente, se você possui permissão para parar a aplicação para realizar um backup, então isto não será um problema. De outra maneira, se um backup é executado a partir de um único nó, então depois dele ter completado uma grande parte do sistema de arquivos, ele cache nesse nó, com uma penalidade no desempenho pelo motivo de ter subsequente acessos dos outros nós. Isso pode ser aliviado a um certo ponto removendo o cache de página VFS no nó de backup depois do backup ter completado com o seguinte comando:
echo -n 3 >/proc/sys/vm/drop_caches
Entretanto, esta não é uma solução tão boa quanto certificar que o conjunto de execução em cada nó é tanto compartilhado, podendo ser lido somente pelo cluster ou acessado intensamente de um nó único.