Nosso aplicativo grava dados em disco como um enorme buffer de anel (30 a 150 TB); escrevendo novos arquivos ao excluir arquivos antigos. Como tal, por definição, o disco está sempre "quase cheio".
O processo escritor cria vários arquivos em uma velocidade de entrada de cerca de 100-150 Mbits / s. Os arquivos de dados são uma mistura de arquivos de dados de 1 GB e vários arquivos de metadados menores. (A velocidade de entrada é constante, mas note que novos conjuntos de arquivos são criados apenas uma vez por dois minutos).
Existe um processo separado deleter que exclui os arquivos "mais antigos" a cada 30s. Ele continua apagando até chegar a 15GB de espaço livre no espaço do disco.
Portanto, na operação estável, todas as partições de dados têm apenas 15 GB de espaço livre.
Em este SO pergunta relacionada à lentidão do sistema de arquivos, DepressedDaniel comentou:
Sync hanging just means the filesystem is working hard to save the latest operations consistently. It is most certainly trying to shuffle data around on the disk in that time. I don't know the details, but I'm pretty sure if your filesystem is heavily fragmented, ext4 will try to do something about that. And that can't be good if the filesystem is nearly 100% full. The only reasonable way to utilize a filesystem at near 100% of capacity is to statically initialize it with some files and then overwrite those same files in place (to avoid fragmenting). Probably works best with ext2/3.
O ext4 é uma má escolha para esta aplicação? Já que estamos rodando ao vivo, qual ajuste pode ser feito para ext4 para evitar fragmentação, lentidão ou outras limitações de desempenho? Mudar de ext4 seria bem difícil ...
(e reescrever arquivos estaticamente criados significa reescrever todo o aplicativo)
Obrigado!
Tags ext4 ext3 filesystems