O desempenho do EXT4 se tornou muito ruim no sistema com muitos arquivos pequenos

Eu tenho um pequeno dispositivo incorporado que possui apenas 128 MB de RAM

conectado a este dispositivo está um disco rígido de 2 TB USB2

Fiquei muito feliz com o desempenho do dispositivo até recentemente, quando o número de arquivos ultrapassou um limite da capacidade do disco ultrapassou um limite (não tenho certeza qual)

no disco existem muitos arquivos pequenos, devido à natureza dos aplicativos de gravação, os arquivos são organizados de maneira muito equilibrada - nenhum diretório de nó folha possui mais de 200 arquivos e existem pouco mais de 800.000 arquivos.

Espero obter uma pista sobre algo a investigar. O desempenho do disco caiu significativamente, o dispositivo estava se movendo muito bem e, de repente, o desempenho caiu como uma pedra.

Minha suposição é que a estrutura organizacional que eu escolhi no disco para meus arquivos prejudicou a capacidade dos caches de inode de permanecerem compactos.

como um experimento, desmontei o disco (liberando caches, verificados gratuitamente). Em um prompt de comando, naveguei profundamente na estrutura de diretórios. Ao todo, este diretório (e seus filhos) tinha apenas cerca de 3200 arquivos contidos abaixo dele e, nesse ponto, 'free' mostrava> 117MB de memória livre

neste ponto, digitei o comando 'find' seguido de 'free'

'find' mostrou cerca de 3000 arquivos, mas o uso de memória passou de ~ 117MB para ~ 2MB

Entendo o equilíbrio entre cache e memória livre e como o kernel considera uma página vazia uma página ruim - no entanto, 115 MB de conteúdo em cache de um diretório de 3000 arquivos apontam para uma lacuna séria no meu entendimento. Espero que alguém me ajude a entender o que está acontecendo

posso assumir que uma árvore equilibrada é o caminho a seguir para ter muitos arquivos?

Muito boa descrição do problema.

Com base no que você disse, acho que o que você está vendo é o uso de placas em alta. Uma boa experiência seria executar um cat /proc/meminfoe cat /proc/slabinfomais de um segundo de atraso 3, enquanto você ir fundo na hierarquia fs e descobrir os 3000 arquivos. O que está acontecendo basicamente é que o kernel percorre a estrutura fs e verifica os arquivos individuais e seus inodes e todos eles são armazenados na memória. Se você verificar /proc/slabinfo, verá um objeto chamado ext4_inode_cacheque informa a quantidade de memória que cada inode precisará. Multiplique isso pelo número de objetos (obj_size * no_obj) e você obterá a quantidade de memória usada pelo objeto. Quanto mais você entrar na hierarquia fs, mais memória será consumida até que o sistema atinja a marca d'água alta da zona de memória. Nesse ponto, o kernel começará a recuperar.

Se você digitar meminfo e slabinfo, obterá os detalhes que está procurando. Se você quer que eu olhe, cole-o;)