Resolvendo o iowait alto no servidor Samba

Question

Temos um cache de arquivos centralizado que um cluster de servidores da Web usa para armazenar páginas "pesadas". Cada servidor da Web usa o Samba para montar essa área compartilhada.

Estamos recebendo muito iowait no servidor e fiquei imaginando quais etapas poderíamos tomar para criar um cache centralizado mais eficiente. Já estamos usando memcache como cache de primeira linha para alguns objetos, e podemos simplesmente jogar mais memória nisso, mas eu estou interessado em descobrir que técnicas poderíamos usar para acelerar um cache baseado em arquivos. Todos os servidores executam o lançamento recente do Ubuntu.

O servidor usa um sistema de arquivos ext3 com o LVM. Talvez outros sistemas de arquivos tenham mais desempenho para esse tipo de atividade? Usamos o Samba por muitos anos simplesmente porque todos estão confortáveis com ele e tivemos dores de cabeça de manutenção com NFS (recusa de desmontar, por exemplo). Talvez existam melhores tecnologias ...

    

Answer 1

Verifique o io scheduler (chamado de io elevator na documentação do kernel) atribuído a esse volume.

$ cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq 

Para a maioria das distribuições RedHat e Fedora, o padrão é o escalonador CFQ. IMHO isso não é o melhor para um processo de servidor iobound. Eu recomendo o programador de prazos

$ echo "deadline" > /sys/block/sda/queue/scheduler

para alterar isso ou adicionar

elevator=deadline

para seus argumentos de inicialização para torná-lo permanente.

Altos tempos de iowait também podem ser causados por leitura antecipada agressiva, o que pode ser desnecessário para sua carga de trabalho. O padrão para os sistemas RedHat e Fedora é de 128k

$ cat /sys/block/sda/queue/read_ahead_kb 
128

Experimente fazer eco dos valores mais baixos para esse arquivo e veja se isso diminui seus tempos de espera.

Além disso, verifique o disco ou matriz subjacente. Se ele for degradado ou recriado, seus tempos de iowait aumentarão conforme o subsistema de disco subjacente rouba a largura de banda io enquanto se reconstrói

    

Answer 2

Um IOWait% alto no servidor significa que você precisa de um disco mais rápido / mais memória para o cache de disco.

Dê uma olhada nas estatísticas do seu 'iostat -x 5' - você está saturando o disco? Dependendo da semântica do seu aplicativo, talvez mais memória no servidor de arquivos seja o melhor.

Se houver um longo atraso entre o armazenamento & recuperação de páginas pelo servidor, então você precisa de um disco mais rápido.

Verifique a saída de livre para ver quanta memória você tem e para o que está sendo usado.

    

Answer 3

Sendo o Samba acessado pela rede, considero que sua rede é o primeiro gargalo. Os links são otimizados em torno dos tipos e tamanhos de arquivos / pacotes que vêm pela rede?

Você pode monitorar os links para ver como eles são utilizados?

Se a rede não parece ser o gargalo, você pode ver algumas dicas em este guia para otimizar sua configuração do Samba um pouco.

editar

Você menciona o LVM, que tipo de discos são eles? Unidades IDE 7200RPM de prateleira? Se for verdadeiramente IO esperar, então sim, você precisaria de disco mais rápido. Isso pode ser tão simples quanto uma unidade SATA 10k ou até mesmo uma invasão de alto desempenho.

    

Answer 4

Outra opção é usar uma solução de cache de proxy reverso, como o Squid ou o verniz, em vez de ter que passar por diferentes camadas para obter os mesmos dados. Apenas algo a considerar como tal solução seria otimizado para servir páginas da web (em oposição a uma solução de arquivo mais genérica).