CentOS: Como melhorar o desempenho de listagem do NFS

Question

O NFS tem funcionado muito bem para mim nos últimos anos, mas agora sou confrontado com um problema de desempenho para o qual não consigo encontrar uma solução.

Meu problema é que, no servidor NFS, tenho cerca de 5Gb de arquivos pequenos e quando, de um cliente, faço um "ls" ou um "du" no diretório montado, pode levar mais de 2 minutos para listar todos os arquivos.

Acho que o problema está vindo do fato de que, para cada arquivo, o NFS envia uma consulta para as estatísticas do arquivo, aguarda a resposta e, em seguida, envia uma nova consulta para o arquivo a seguir. Se esse for o caso, tenho certeza de que isso é o que está causando meu problema de desempenho ruim.

Agora, tentei encontrar uma solução para isso, mas não consegui encontrar uma, por isso decidi abrir este tópico.

Algum de vocês tem alguma ideia de como eu poderia consertar meu problema de desempenho?

Muito obrigado por um linux sys-admin padawan.

    

Answer 1

Meu sentimento é que esse problema não é específico do NFS. Historicamente, os sistemas de arquivos UNIX em geral têm problemas com diretórios planos contendo grandes números de arquivos. Certamente, a regra geral que muitos anos atrás me disseram foi que o desempenho degrada com o quadrado do tamanho do arquivo de diretório. Como você aponta, fazer um ls -la significa stat ing cada inode, e isso leva muito tempo uma vez que o arquivo de diretório começa a crescer; a latência adicionada pelo NFS irá exacerbar isso, mas é apenas trazer um problema subjacente à sua atenção, não causando isso.

A solução, como eu digo constantemente aos meus desenvolvedores, não é armazenar um grande número de arquivos em estruturas rasas e largas, mas em estruturas estreitas e profundas.

Veja como os utilitários existentes armazenam arquivos quando eles têm muitos para armazenar: yum cria muitos arquivos em /var/lib/yum/yumdb , então os armazena em subdiretórios por inicial:

drwxr-xr-x.   4 root root  4096 Sep  9  2011 C
drwxr-xr-x.   3 root root  4096 Sep  9  2011 M
drwxr-xr-x.   3 root root  4096 Jul 13 10:05 S
drwxr-xr-x.  24 root root  4096 Jul 13 10:05 a
drwxr-xr-x.  18 root root  4096 Nov  7 11:10 b
[c through y omitted to save space]
drwxr-xr-x.   5 root root  4096 Dec 28  2011 z

O cache do Squid, quando inicializado com squid -z , gera /var/spool/squid/0[0-F] e, sob cada um deles, os subdiretórios são ./[0-F][0-F] . innd obtém um truque semelhante, se a memória for exibida, quando não estiver usando uma estrutura de arquivos do tipo buffer de anel. Todos esses daemons, e muitos outros semelhantes, sabem que, se precisarem armazenar muitos arquivos pequenos, ter um conjunto de subdiretórios profundos para armazená-los é essencial para uma operação eficiente.

Editar : 1s é um tempo muito longo para executar um ls em um único diretório local. Como eu disse, acho que a latência do NFS está exacerbando seu problema; mas não é responsável pelo problema, apenas por torná-lo grande o suficiente para causar-lhe dor.