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

Eu tenho uma unidade formatada EXT3 em um servidor Linux CentOS. Esta é uma unidade de dados de aplicativos da web e contém um diretório para cada conta de usuário (existem 25.000 usuários). Cada pasta contém arquivos que esse usuário enviou. No geral, esta unidade possui aproximadamente 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 do desempenho que não conheço?

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

Recentemente, tentei mesclar duas unidades de dados e percebi que o EXT3 está limitado a 32.000 subdiretórios. Isso me fez pensar no porquê. Parece bobagem que eu a criei dessa maneira, considerando que cada arquivo tem uma identificação única que corresponde a uma identificação no banco de dados. Infelizmente ...

É fácil testar as opções por si mesmo, em seu ambiente e comparar os resultados. Sim, há um impacto negativo no desempenho à medida que 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ório. O ext4 provavelmente está bem atualmente. O acesso e as operações no diretório simplesmente ficarão mais lentos à medida que o número de subdiretórios e arquivos aumentar. Isso é muito pronunciado no ext3 e não tanto no XFS.

A resposta não é tão simples quanto a escolha do sistema de arquivos. Os sistemas de arquivos sãos 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 acontecer.

De fato, cada operação permanece rápida e eficiente, independentemente do número de entradas, mas algumas tarefas envolvem um número crescente de operações. Obviamente, fazer um simples lsleva muito tempo e você não vê nada até que todos os inodes tenham sido lidos e classificados. Fazer ls -U(sem classificação) ajuda um pouco porque você pode ver que não está morto, mas não reduz o tempo de maneira perceptiva. Menos óbvio é que qualquer expansão de curinga precisa verificar todos os nomes de arquivos e parece que, na maioria dos casos, todo o inode também deve ser lido.

Em resumo: se você pode ter certeza absoluta de que nenhum aplicativo (incluindo acesso ao shell) jamais usará qualquer wildard, poderá obter diretórios enormes sem nenhum remorso. Mas se houver alguns curingas à espreita no código, mantenha os diretórios abaixo de mil entradas cada.

editar :

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

Porém, a maioria dos aplicativos não realiza apenas operações únicas. A maioria deles fará um diretório completo ou uma correspondência de curinga. Eles são lentos, 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' a '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 irão falhar, 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 muito poucos resultados; mesmo aqueles que falham, falham após a verificação de todas as entradas:

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

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

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

Se estiver faltando, você pode habilitá-lo. Você precisa desmontar o sistema de arquivos e execute:

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

Em seguida, monte o sistema de arquivos.

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

Quanto mais entradas (arquivos e diretórios) você tiver em um único diretório, mais lento será o acesso. Isso é verdade para todo sistema de arquivos, embora alguns sejam piores que outros.

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

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

E se você ainda precisar de melhor desempenho, poderá estender vários níveis:

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

A maioria dos sistemas de correio usa esse truque com seus arquivos da fila de correio.

Além disso, descobri que em alguns sistemas de arquivos, apenas ter tido no passado muitas entradas em um diretório tornará esse acesso lento. Faça um ls -ldno diretório para ver o tamanho da própria entrada do diretório. Se tiver vários MB ou mais e o diretório estiver relativamente vazio, você poderá ter um desempenho ruim. Renomeie o diretório imediatamente, crie um novo com o mesmo nome, permissões e propriedade e, em seguida, mova o conteúdo do diretório antigo para o novo. Eu usei esse truque várias vezes para acelerar significativamente os servidores de correio que ficaram mais lentos pelo sistema de arquivos.

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

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

Quando examinei o XFS pela última vez e pesava as vantagens e desvantagens do uso do XFS sobre o ext4, encontrei relatórios de perda de dados com o XFS. Não tenho certeza se isso ainda é um problema ou se foi, mas isso me deixou nervoso o suficiente para ficar claro. Como ext4 é o fs padrão no Ubuntu, ele venceu facilmente sobre o XFS.

Portanto, além da sugestão de Tylerl, que ajudará da perspectiva do gerenciamento, sugiro que você atualize para o ext4. O limite por diretório é de 64000 entradas com ext4

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

O bom do ext4 é que você pode montar um volume ext3 no ext4 para experimentar. Consulte: Migrando um Sistema Ativo do Sistema de Arquivos Ext3 para Ext4

Uma citação desse link:

Se você não for afetado pelas limitações do ext3 e não estiver disposto a correr riscos, pode não valer a pena. Por outro lado, após a conclusão bem-sucedida do procedimento de migração, seu sistema poderá executar mais rapidamente, sofrer verificações reduzidas do sistema de arquivos e aumentar a confiabilidade sem causar efeitos negativos.

Então, vá em frente e tente. Sugira o backup primeiro.

Definitivamente, haverá algumas conseqüências disso. O principal será leitura / gravação de E / S. Além disso, é apenas uma maneira muito assustadora de lidar com esse tipo de dados (nessa escala).

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

A primeira listagem do conteúdo do sistema de arquivos levará um tempo até que o sistema leia 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 em cache.

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

Tenho algumas perguntas e algumas conclusões possíveis sobre gargalos.

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

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 obter onde está o gargalo, aplicativo, sistema de arquivos, agendador, armazenamento - em qual componente a IO está gastando a maior parte do tempo.

Agora, teoricamente, chegando à sua pergunta, obviamente aumentará o número de inodes e, à medida que você cria ou acessa arquivos ou diretórios novos ou existentes nos diretórios, o tempo de acesso aumenta. O kernel precisa atravessar uma hierarquia de sistema de arquivos mais vasta e, portanto, isso sem dúvida é uma sobrecarga.

Outro ponto a ser observado é que, à medida que você aumenta o número de diretórios, o uso de cache de inode e dentry aumenta o consumo de mais RAM. Isso vem com pouca memória, portanto, se o servidor estiver com pouca memória, esse é outro ponto de pensamento.

Falando de um exemplo do mundo real, vi recentemente que em um ext3 fs altamente aninhado, a criação de um subdiretório pela primeira vez leva cerca de 20 segundos, enquanto no ext4 leva cerca de 4 segundos. Isso ocorre porque a estrutura de 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 mais mínimo que seja.

Portanto, 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 referências.

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

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