Armazenando milhares de arquivos em um diretório

Question

Eu tenho um site que estou verificando problemas de desempenho e bugs, e me deparei com um código de cache que armazena milhares de arquivos em um único diretório.

Eu entendo que isso não é bom e que o I / O irá degradar e eu também ouvi falar sobre o potencial problema do inode.

E eu sei como consertar o código do cache, mas a questão é que, nesse ponto, a correção seria muito cara.

A questão : Qual é o pior cenário se eu viver como é agora? O que vai acontecer com o site? (neste momento, este único diretório de cache tem 400K arquivos)

Eu sou novo no Ubuntu. E eu entendo que isso pode ser um tópico fora do comum. Mas eu acho que esta é uma questão de "sistema" e não pertence à parte de 'programação' do stackoverflow.

Obrigado!

UPDATE: O sistema de arquivos é o UFS

    

Answer 1

A situação é um pouco surpreendente. O UFS é um sistema de arquivos incomum para uma instalação Linux de produção. O acesso de gravação UFS no Linux normalmente precisa estar explicitamente habilitado no kernel, uma vez que ele foi considerado experimental por muitos anos:

CONFIG_UFS_FS_WRITE: UFS file system write support (DANGEROUS)

Say Y here if you want to try writing to UFS partitions. This is experimental, so you should back up your UFS partitions beforehand.

Como muitos sistemas de arquivos tradicionais, o UFS usa pesquisas de arquivos sequenciais nos diretórios. Isso de fato leva a problemas de desempenho para diretórios com muitos arquivos, já que o tempo de busca cresce linearmente com o número de arquivos. Nos BSDs, onde o UFS é frequentemente o sistema de arquivos padrão , esta questão levou diretamente à criação de Dirhash , uma pesquisa de tabela de hash para diretórios, que melhora significativamente o desempenho.

Até onde eu sei, o suporte a UFS no Linux não usa o Dirhash. Portanto, você pode esperar um aumento nos problemas de desempenho à medida que o número de arquivos em seu diretório aumenta. Em termos de acesso seqüencial, os arquivos de 400K são muito, e você pode esperar um impacto significativo no desempenho.

A divisão de arquivos entre subdiretórios gerencia efetivamente o problema de acesso sequencial. Alternativamente, você pode mudar para um sistema de arquivos que suporta uma estrutura de armazenamento de arquivos mais sofisticada. Por exemplo, o XFS implementa acesso rápido a arquivos para diretórios grandes através do uso de árvores B + .

Sua segunda preocupação foi com inodes. Geralmente, o número de inodes no seu sistema de arquivos é fixo, e isso geralmente é uma função da quantidade de espaço disponível no momento da criação do sistema de arquivos. Por exemplo, /etc/mke2fs.conf contém a taxa padrão de inode (número de inodes por x bytes) para sistemas de arquivos ext.

Normalmente, esse número é muito maior do que o número de arquivos que você provavelmente criará e não é motivo de preocupação. No entanto, você pode verificar seu uso do inode com df -i . Se as limitações do inode forem realmente um problema, mexer com diretórios não ajudará, já que os inodes são um conceito de todo o sistema de arquivos, independente do diretório. Nesse caso, você seria forçado a recriar o sistema de arquivos, configurando o parâmetro inode ( -i ) como mkfs apropriadamente.

    

Answer 2

Em um sistema de arquivos normal unix (baseado em inode), incluindo UFS, é uma aproximação razoável dizer que cada arquivo ou diretório que você cria usa um inode. Ter muitos arquivos em um diretório não altera isso.

Os problemas habituais com a abordagem que você descreve são:

• sistemas de arquivos usam hashes ou estruturas de dados do tipo árvore para pesquisas de diretório para acelerar a pesquisa e a criação, quanto mais arquivos você tiver em um único diretório, mais lento ele ficará. Com o hashing, esse abrandamento pode ser bastante pronunciado quando ocorrem colisões.
• comandos típicos do unix têm problemas (especificamente ls sorting e shell glob expansion), embora geralmente bem antes de uma lentidão no sistema de arquivos.
• à medida que o diretório ganha novos arquivos, mais blocos são alocados, ele se tornará cada vez mais fragmentado, exigindo mais IO do disco para acessar.

Sistemas de arquivos mais modernos (ext3 / 4) usam estruturas de dados como árvores-B para manter os diretórios classificados, como parte de seus dados no disco. Acredito que a implementação do UFS use hashing na memória (com base no uso e na documentação do FreeBSD, não tenho muita experiência direta com o UFS no Linux), pois o formato em disco não usa hashes.

Isso tem algumas boas informações e links de UFS: link

O pior caso provável é que, em algum momento, você experimentará lentidão perceptível e sempre piorando ao acessar esse diretório. Quando chegar a esse ponto, será tedioso consertar (com base na minha experiência com a explosão de filas de sendmail).

Recomendamos que você monitore (e represente graficamente) o tempo de iowait do sistema e conheça iotop e slabtop , se ainda não o fez.

Se possível, sugiro também que você experimente alguns experimentos simples para cronometrar a criação de 1000 arquivos em seu diretório de cache e compare com isso em um diretório vazio.