OK, não é tão grande, mas preciso usar algo em que cerca de 60.000 arquivos com tamanho médio de 30kb sejam armazenados em um único diretório (este é um requisito, portanto, não é possível simplesmente invadir 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 acho muito lento. Alguma sugestão?
Respostas:
Você deve considerar o XFS. Ele suporta um número muito grande de arquivos, tanto no sistema de arquivos quanto no 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ê tente e faça uma comparação com a sua solução atual.
fonte
Um bilhão de arquivos no Linux
O autor deste artigo analisa alguns dos problemas de desempenho em sistemas de arquivos com grandes contagens de arquivos e faz algumas boas comparações do desempenho de vários sistemas de arquivos ext3, ext4 e XFS. Isso é disponibilizado como uma apresentação de slides. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf
fonte
Muitos arquivos em um diretório no ext3 foram discutidos em detalhes 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 dos outros requisitos, pode ser bom o suficiente.
fonte
ESTÁ BEM. Fiz alguns testes preliminares usando ReiserFS, XFS, JFS, Ext3 (dir_hash ativado) e Ext4dev (kernel 2.6.26). Minha primeira impressão foi que todas eram rápidas o suficiente (na minha estação de trabalho robusta) - acontece que a máquina de produção remota tem um processador bastante lento.
Eu experimentei alguma estranheza com o ReiserFS, mesmo nos testes iniciais, o que descartou isso. Parece que o JFS possui 33% menos requisitos de CPU que todos os outros e, portanto, testará isso no servidor remoto. Se funcionar bem o suficiente, eu usarei isso.
fonte
Estou escrevendo um aplicativo que também armazena muitos arquivos, embora os meus sejam maiores e eu tenho 10 milhões deles que estarei dividindo em vários diretórios.
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 ficará cada vez mais lento. Existe algo chamado índice htree que está disponível para o ext3 que supostamente melhora bastante as coisas. Mas, está disponível apenas na criação do sistema de arquivos. Veja aqui: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/
Como você precisará reconstruir o sistema de arquivos de qualquer maneira e devido às limitações do ext3, minha recomendação é que você use o ext4 (ou XFS). Eu acho que o ext4 é um pouco mais rápido com arquivos menores e tem recriações mais rápidas. Índice Htree é padrão no ext4, tanto quanto eu sei. Eu realmente não tenho nenhuma experiência com JFS ou Reiser, mas já ouvi pessoas recomendando isso antes.
Na realidade, eu provavelmente testaria vários sistemas de arquivos. Por que não tentar ext4, xfs & jfs e ver qual deles oferece 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 no stackoverflow. Armazenando e acessando até 10 milhões de arquivos no Linux, existem algumas respostas e links úteis.
fonte
Usar o tune2fs para ativar o dir_index pode ajudar. Para ver se está ativado:
Se não estiver ativado:
Mas tenho a sensação de que você pode estar seguindo o caminho errado ... por que não gerar um índice plano e usar algum código para selecionar aleatoriamente com base nisso. Você pode usar subdiretórios para uma estrutura em árvore mais otimizada.
fonte
/dev/sad1
intencional para evitar erros de cópia / massa?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 (ele simplesmente não os armazenará no diretório, o que não importa para a maioria dos usuários).
Além disso, a maneira como os diretórios são armazenados nos sistemas de arquivos ext * é essencialmente uma grande lista. Nos sistemas de arquivos mais modernos (Reiser, XFS, JFS), eles são armazenados como árvores B, muito mais eficientes para conjuntos grandes.
fonte
Você pode armazenar inodes de arquivos em vez de nomes de arquivos: acessar números de inode deve ser muito mais rápido que resolver nomes de arquivos
fonte
Você não quer empinar tantos arquivos em um diretório, 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, pode melhorar o tempo de acesso. Outro truque bobo que eu gosto de usar é forçar o sistema a atualizar seu cache com metainformações e executar o updateb regularmente. Em uma janela, execute slabtop e, em outra, atualizeb, e você verá que muita memória será alocada para o cache. É muito mais rápido assim.
fonte
Você não especificou o tipo de dados nesses arquivos. Mas, pelo que parece, você deve usar algum tipo de banco de dados com indexação para pesquisas rápidas.
fonte
O sistema de arquivos provavelmente não é o armazenamento ideal para esse requisito. Algum tipo de armazenamento de banco de dados é melhor. Ainda assim, se você não puder ajudá-lo, tente dividir os arquivos em vários diretórios e use o unionfs para montar (ligar) esses diretórios no diretório único onde você deseja que todos os arquivos apareçam. Eu não usei essa técnica para acelerar, mas vale a pena tentar.
fonte