Como o número de subdiretórios afeta o desempenho de leitura / gravação do drive no Linux?

Question

Eu tenho uma unidade formatada EXT3 em um servidor Linux CentOS. Esta é uma unidade de dados do aplicativo da Web e contém um diretório para cada conta de usuário (há 25.000 usuários). Cada pasta contém arquivos que esse usuário carregou. No geral, essa unidade tem cerca de 250 GB de dados.

A estruturação da unidade com todos esses diretórios afeta o desempenho de leitura / gravação da unidade? Isso afeta algum outro aspecto de desempenho que eu não conheço?

Existe alguma coisa inerentemente errada ou ruim em estruturar as coisas dessa maneira? Talvez apenas a escolha errada do sistema de arquivos?

Eu recentemente tentei fundir duas unidades de dados e percebi que EXT3 está limitado a 32.000 subdiretórios. Isso me fez pensar porque. Parece bobagem que eu construa dessa maneira, considerando que cada arquivo tem um id único que corresponde a um id no banco de dados. Infelizmente ...

    

Answer 1

É fácil testar as opções para você mesmo, em seu ambiente e comparar os resultados. Sim, há um impacto negativo no desempenho conforme o número de diretórios aumenta. Sim, outros sistemas de arquivos podem ajudar a contornar essas barreiras ou reduzir o impacto.

O sistema de arquivos XFS é melhor para esse tipo de estrutura de diretórios. O ext4 provavelmente está bem hoje em dia. O acesso e as operações no diretório serão simplesmente reduzidos à medida que o número de subdiretórios e arquivos aumentar. Isso é muito pronunciado sob o ext3 e não tanto no XFS.

    

Answer 2

A resposta não é tão simples quanto a escolha do sistema de arquivos. Os sistemas de arquivos da Sane pararam de usar listas lineares para diretórios há muito tempo, o que significa que o número de entradas em um diretório não afeta o tempo de acesso ao arquivo ...

exceto quando isso acontece.

Na verdade, cada operação permanece rápida e eficiente, não importa o número de entradas, mas algumas tarefas envolvem um número crescente de operações. Obviamente, fazer um simples ls leva muito tempo, e você não vê nada até que todos os inodes tenham sido lidos e ordenados. Fazer ls -U (não classificado) ajuda um pouco porque você pode ver que não está morto, mas não reduz o tempo de forma perceptiva. Menos óbvio é que qualquer expansão de caractere curinga tem que verificar cada nome de arquivo, e parece que na maioria dos casos o inode inteiro deve ser lido também.

Resumindo: se você pode ter certeza absoluta de que nenhum aplicativo (incluindo acesso ao shell) usará qualquer wildard, então você pode obter diretórios enormes sem nenhum remorso. Mas se houver alguns curingas ocultos no código, é melhor manter os diretórios abaixo de mil entradas cada.

editar :

Todos os sistemas de arquivos modernos usam boas estruturas de dados para diretórios grandes, portanto, uma única operação que tenha que encontrar o inode de um arquivo específico será bastante rápida mesmo em diretórios gigantescos.

Mas a maioria dos aplicativos não faz apenas operações únicas. A maioria deles fará um diretório completo ou uma correspondência de caractere curinga. Essas são lentas, não importa o quê, porque envolvem a leitura de todas as entradas.

Por exemplo: digamos que você tenha um diretório com um milhão de arquivos chamado 'foo-000000.txt' através de 'foo-999999.txt' e um único 'natalieportman.jpeg'. Estes serão rápidos:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

estes falharão, mas também falharão rapidamente:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

estes serão lentos, mesmo que retornem poucos resultados; mesmo aqueles que falham, falham após verificar todas as entradas:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Answer 3

Primeiro, verifique se a partição ext3 tem o sinalizador dir_index definido.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Se estiver faltando, você poderá ativá-lo. Você precisa desmontar o sistema de arquivos e, em seguida, executar:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Depois monte o sistema de arquivos.

    

Answer 4

Não faz diferença até você atingir o limite de 32.000 nomes por diretório. A atualização para o ext4 pode contornar isso, assim como os outros benefícios do ext4.

    

Answer 5

Quanto mais entradas (arquivos e dirs) você tiver dentro de um único diretório, mais lento será o acesso. Isso é verdade para todos os sistemas de arquivos, embora alguns sejam piores que outros.

Uma solução melhor é criar uma hierarquia de diretórios, como esta:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

E se você ainda precisar de um melhor desempenho, é possível estender vários níveis:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

A maioria dos sistemas de email usa esse truque com seus arquivos de fila de mensagens.

Além disso, descobri que, com alguns sistemas de arquivos, apenas no passado, muitas entradas em um diretório tornariam o acesso ao diretório lento. Faça um ls -ld no diretório para ver o tamanho da própria entrada de diretório. Se houver vários MB ou mais e o diretório estiver relativamente vazio, talvez você esteja obtendo um desempenho ruim. Renomeie o diretório fora do caminho, crie um novo com o mesmo nome e permissões e propriedade e, em seguida, mova o conteúdo do diretório antigo para o novo. Eu usei esse truque muitas vezes para acelerar significativamente os servidores de e-mail que haviam sido atrasados pelo sistema de arquivos.

    

Answer 6

Eu desenvolvi recentemente um servidor de armazenamento que precisava criar dezenas de milhões de arquivos e centenas de milhares de diretórios. Eu comparei o XFS com ext4 e reiserfs. Eu descobri que no meu caso o ext4 era um pouco mais rápido que o XFS. Reiser era interessante, mas tinha limitações, de modo que foi descartado. Eu também achei que o ext4 foi significativamente mais rápido que o ext3.

Quando você obtém muitos arquivos por diretório, o tempo de abertura do arquivo começa a sofrer. E / S de arquivo não. O tempo de eliminação de arquivos também sofre. No entanto, não é muito lento no ext4. É bastante perceptível sob ext3 embora. XFS e ext4 são bem rápidos nisso.

Quando olhei pela última vez para o XFS e estava avaliando as vantagens e desvantagens de usar o XFS sobre o ext4, encontrei relatos de perda de dados com o XFS. Eu não tenho certeza se isso ainda é um problema ou se já foi, mas isso me deixou nervoso o suficiente para ficar longe. Como o ext4 é o fs padrão no Ubuntu, ele ganhou facilmente com o XFS.

Então, além da sugestão de tylerl, que ajudará a partir da perspectiva da gestão, Eu sugiro que você possa atualizar para o ext4. O limite por diretório é 64.000 entradas com ext4

Outro benefício é que o tempo fsck é substancialmente mais rápido. Eu nunca tive problemas com corrupção.

O interessante sobre o ext4 é que você pode montar um volume ext3 no ext4 para testá-lo. Veja: Migrando um sistema live de ext3 para ext4 filesystem

Uma citação desse link:

If you are not affected by the limitations of ext3, and not willing to take risks, it may not be worth it. On the other hand, on successful completion of the migration procedure your system may perform faster, experience shortened file system checks, and have increased reliability with no ill effects.

Então, vá em frente e tente. Sugiro que você faça o backup primeiro.

    

Answer 7

Haverá DEFINITIVAMENTE algumas conseqüências de se fazer isso. O principal será IO read / writes. Além disso, é apenas uma maneira muito assustadora de lidar com esse tipo de dados (nessa escala).

    

Answer 8

No passado eu usei o XFS para superar os limites do Ext3 com sucesso.

A primeira listagem do conteúdo dos sistemas de arquivos levará algum tempo até que o sistema tenha lido todas as informações do diretório / arquivo. As operações suplementares serão mais rápidas porque o kernel agora tem as informações armazenadas em cache.

Eu vi administradores executarem 'find / somepath 2 > 1 > / dev / null' no cron regularmente para manter o cache ativo, resultando em um melhor desempenho.

    

Answer 9

Eu tenho algumas perguntas e algumas possíveis descobertas de gargalos.

Primeiro, este é um sistema CentOS 5 ou 6? Porque em 6, temos uma ferramenta incrível chamada blktrace, que é ideal para medir o impacto neste tipo de situações.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Podemos, então, analisar a saída com btt e chegar onde o gargalo é, aplicativo, sistema de arquivos, agendador, armazenamento - em qual componente o IO está gastando a maior parte do tempo.

Agora, teoricamente chegando à sua pergunta, obviamente aumentará o número de inodes e conforme você continuar criando ou acessando arquivos novos ou existentes ou diretórios dentro dos diretórios, o tempo de acesso aumentará. O kernel tem que percorrer uma hierarquia de sistema de arquivos mais vasta e, portanto, sem dúvida, é uma sobrecarga.

Outro ponto a ser observado é que, conforme você aumenta o número de diretórios, o uso do cache inode e dentry aumentará o consumo de mais memória RAM. Isto vem sob a memória slab, por isso, se o seu servidor está com pouca memória, esse é outro ponto de pensamento.

Por falar em um exemplo do mundo real, vi recentemente que em um ext3 fs altamente aninhado, criar um subdir pela primeira vez leva cerca de 20 segundos, enquanto que no ext4 ele leva cerca de 4 segundos. Isso ocorre porque a alocação de blocos é estruturada em diferentes sistemas de arquivos. Se você usa XFS ou ext4, é desnecessário dizer que você obterá algum aumento de desempenho, por mínimo que seja.

Então, se você está apenas perguntando qual é a escolha certa do sistema de arquivos, o ext3 está um pouco desatualizado. É tudo o que posso oferecer sem mais dados e benchmark.

    

Answer 10

Não é uma opção no CentOS 5, e não tenho certeza de quanto é uma opção no CentOS 6, mas tenho a impressão de que uma solução B ou árvore B *, ou seja, BTRFS forneceria desempenho consistente, se não significativamente melhor em seu cenário particular, se apenas um pudesse confiar seus dados preciosos com uma consciência limpa (eu ainda não o fariam).

Mas se você puder, você pode testá-lo.