OOM Killer causado por E/S de disco durante a transferência de arquivos

Olá, sou um inútil.
Faz alguns dias que montei um servidor doméstico barato na minha nova casa. Um problema que me incomodava há algum tempo acabou acontecendo mesmo com muita memória.

O que aconteceu?

Meu ambiente atual é um pouco peculiar, ou melhor, a capacidade da memória é um tanto incompleta, 16GB + 8GB, mas por favor, entenda que foi feito com sobras.

Acontece que, com 24GB de RAM, o que pode ser comum hoje em dia, mas para mim é uma condição bastante rica, eu não esperava que um OOM acontecesse, mas um OOM semelhante a uma repreensão do kernel Linux ocorreu.

Aplicativos como Apache, php-fpm, Redis e outros não deveriam consumir tanta memória cada um, mas...

Quebrando a cabeça com a transferência de arquivos

Aconteceu quando eu estava tentando transferir arquivos via scp do meu servidor doméstico que ainda está na casa dos meus pais, ou quando estava salvando imagens em massa para um HDD de 2TB usando aria2c.
Agora, por que um OOM ocorre apenas com este processo de escrita? Isso ocorre porque os arquivos são primeiro recebidos na memória e depois gravados na área de armazenamento. Para otimizar a velocidade, é necessário que a memória os receba primeiro como cache.

Parece que arquivos de centenas de GB com scp -r, especialmente se houver processamento de E/S aleatório, realmente consomem muitos recursos.
Além disso, isso não se enquadra no uso de memória por processo, então não pode ser verificado como um único processo usando `top`, sendo uma questão do kernel Linux, o que torna a identificação bastante difícil.

Em suma, parece que isso acontece porque a quantidade de dados armazenados temporariamente na memória devido à espera de E/S não consegue acompanhar a escrita, levando a uma situação de esgotamento gradual.

Parâmetros do kernel que podem ser alterados

Como algo que o kernel pode fazer, tentei ajustar as configurações de quanto cache usar, mas não senti muito efeito.
2.2. Opções de ajuste do VFS: Pesquisa e Experimentação Documentação do Produto Red Hat
Notas sobre o ajuste de E/S de escrita alterando as configurações de cache de página do Linux - YOMON8.NET

Em termos de fenômeno, é semelhante a esta pessoa.
OOM Killer invoked due to slow disk I/O - #17 by Whis-key - troubleshooting - Storj Community Forum (official)
Faz tempo que não via a palavra Storj... embora meu plano gratuito tenha sido excluído sem permissão...

É surpreendente ter que quebrar a cabeça com a exaustão da memória apenas por escrever no HDD...
É também a parte onde se diz frequentemente sobre a memória: 'Linux é otimista com a RAM, Windows é pessimista'. No entanto, embora a intenção de utilizar totalmente a memória para um desempenho mais eficiente seja compreensível, eu realmente gostaria de encontrar uma maneira de lidar com este problema causado pela espera de E/S.