OK, não tão grande, mas preciso usar algo em que cerca de 60.000 arquivos com tamanho médio de 30kb estão armazenados em um único diretório (esse é um requisito, portanto, não é possível dividir em subdiretórios com um número menor de arquivos) .
Os arquivos serão acessados aleatoriamente, mas uma vez criados, não haverá gravações no mesmo sistema de arquivos. Atualmente estou usando o Ext3, mas achei muito lento. Alguma sugestão?
Você deve considerar o XFS. Ele suporta um grande número de arquivos no sistema de arquivos e no nível do diretório, e o desempenho permanece relativamente consistente, mesmo com um grande número de entradas devido às estruturas de dados da árvore B +.
Há uma página em seu wiki para um grande número de artigos e publicações que detalham o design. Eu recomendo que você experimente e faça uma comparação com sua solução atual.
Um bilhão de arquivos no Linux
O autor deste artigo aborda alguns dos problemas de desempenho em sistemas de arquivos com grandes contagens de arquivos e faz algumas comparações interessantes do desempenho de vários sistemas de arquivos ext3, ext4 e XFS. Isso é disponibilizado como uma apresentação de slides. link
Muitos arquivos em um diretório no ext3 foram discutidos em extensão no site irmão stackoverflow.com
Na minha opinião, 60.000 arquivos em um diretório no ext3 estão longe do ideal, mas dependendo de seus outros requisitos, ele pode ser bom o suficiente.
OK. Fiz alguns testes preliminares usando ReiserFS, XFS, JFS, Ext3 (dir_hash ativado) e Ext4dev (kernel 2.6.26). Minha primeira impressão foi de que todos eram rápidos o suficiente (na minha estação de trabalho) - a máquina de produção remota tem um processador bastante lento.
Eu senti alguma estranheza com o ReiserFS mesmo nos testes iniciais, então descartei isso. Parece que o JFS tem 33% menos necessidade de CPU do que todos os outros e assim testará isso no servidor remoto. Se tiver um bom desempenho, eu usarei isso.
Estou escrevendo um aplicativo que também armazena muitos e muitos arquivos, embora os meus sejam maiores e eu tenha 10 milhões deles que dividirei em vários diretórios.
O ext3 é lento principalmente devido à implementação padrão da "lista vinculada". Portanto, se você tiver muitos arquivos em um diretório, isso significa que abrir ou criar outro será mais lento e lento. Existe algo chamado um índice de htree que está disponível para o ext3 que supostamente melhora muito as coisas. Mas só está disponível na criação do sistema de arquivos. Veja aqui: link
Como você terá que reconstruir o sistema de arquivos de qualquer maneira e devido às limitações do ext3, minha recomendação é que você olhe para o uso do ext4 (ou XFS). Eu acho que ext4 é um pouco mais rápido com arquivos menores e tem recriações mais rápidas. O índice Htree é o padrão no ext4, tanto quanto eu sei. Eu realmente não tenho nenhuma experiência com o JFS ou o Reiser, mas ouvi pessoas recomendarem isso antes.
Na realidade, provavelmente testaria vários sistemas de arquivos. Por que não tentar ext4, xfs & jfs e ver qual deles dá o melhor desempenho geral?
Algo que um desenvolvedor me disse que pode acelerar as coisas no código do aplicativo não é fazer uma chamada "stat + open", mas sim "open + fstat". O primeiro é significativamente mais lento que o segundo. Não tenho certeza se você tem algum controle ou influência sobre isso.
Veja meu post aqui em stackoverflow. Armazenando & acessando até 10 milhões de arquivos no Linux existem algumas respostas e links muito úteis.
Usar o tune2fs para ativar o dir_index pode ajudar. Para ver se está ativado:
sudo tune2fs -l /dev/sda1 | grep dir_index
Se não estiver ativado:
sudo umount /dev/sda1
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1
Mas tenho a sensação de que você pode estar indo pelo caminho errado ... por que não gerar um índice simples e usar algum código para selecionar aleatoriamente com base nisso. Você pode usar subdiretórios para uma estrutura de árvore mais otimizada.
Você pode armazenar inodes de arquivos em vez de nomes de arquivos: acessar números de inodes deve ser muito mais rápido do que resolver nomes de arquivos
ext3 e abaixo suportam até 32768 arquivos por diretório. O ext4 suporta até 65536 na contagem real de arquivos, mas permitirá que você tenha mais (apenas não os armazenará no diretório, o que não importa para a maioria dos propósitos do usuário).
Além disso, a maneira como os diretórios são armazenados em sistemas de arquivos ext * é essencialmente uma grande lista. Nos sistemas de arquivos mais modernos (Reiser, XFS, JFS) eles são armazenados como árvores B, que são muito mais eficientes para conjuntos grandes.
Você não quer empinar tantos arquivos em um diretório, você quer algum tipo de estrutura. Mesmo que seja algo tão simples quanto ter subdiretórios que começam com o primeiro caractere do arquivo podem melhorar seus tempos de acesso. Outro truque bobo que eu gosto de usar, é forçar o sistema para atualizar seu cache com metainformation é executar o updatedb regularmente. Em uma janela executar slabtop, e em outra corrida updatedb e você verá muita memória vai ser alocada para o cache. É muito mais rápido assim.
Você não especificou o tipo de dados nesses arquivos. Mas pelos sons, você deveria estar usando algum tipo de banco de dados com indexação para buscas rápidas.
O sistema de arquivos provavelmente não é o armazenamento ideal para tal requisito. Algum tipo de armazenamento de banco de dados é melhor. Ainda assim, se você não puder ajudar, tente dividir os arquivos em vários diretórios e use unionfs para montar (ligar) esses diretórios em um único diretório onde deseja que todos os arquivos apareçam. Eu não usei essa técnica para acelerar, mas vale a pena tentar.