Como posso evitar gravações do sistema de arquivos de alto volume a partir de uma impressionante memória no meu sistema Linux?

Question

Em vários contextos, vi um comportamento nos sistemas Linux em que grandes volumes de operações de gravação do sistema de arquivos (por exemplo, muitos gigabytes de gravações, muito rapidamente) sobrecarregarão a memória, aparentemente aguardando a conclusão das operações de E / S. dados (que foram gravados) sejam liberados para o disco para liberar memória para gravações subseqüentes. Quando esta circunstância ocorre, se eu olhar para "vmstat -s", eu posso ver a quantidade de memória livre se tornando cada vez menor, até chegar a zero. Eu frequentemente vejo esse problema ao gravar em discos muito lentos (como unidades externas conectadas a USB que possuem um sistema de arquivos), mas também o vi com discos SATA "regulares" quando grandes volumes de dados são gravados muito rapidamente. Na melhor das hipóteses, isso parece fazer com que as operações de gravação acabem bloqueando, esperando que a memória fique disponível. Na pior das hipóteses, se um grande volume de gravações continuar a ocorrer quando o sistema estiver nesse estado, a pressão na memória se torna tão grande que o OOM Killer é executado e elimina aleatoriamente os processos para liberar memória. Ele aparentemente nem precisa ser vários usuários fazendo gravações para que isso aconteça, já que eu mesmo criei essa situação (sem que ninguém mais use o sistema) ao tentar gravar volumes muito altos de dados em um sistema de arquivos muito rapidamente.

Meu palpite (e eu enfatizo, é apenas um palpite) é que o sistema não é particularmente agressivo ao liberar a saída em buffer para o disco e liberar a memória associada. Mas não tenho certeza do que posso sintonizar, nem mesmo analisar, para determinar se esse é realmente o caso, e talvez tornar o fluxo de buffers de gravação mais agressivo.

Estou no caminho certo aqui, no que se refere ao que está acontecendo? Em caso afirmativo, há algo que eu possa sintonizar para tentar fazer com que o sistema libere mais E / S pendente para o disco e libere a memória do buffer?

    

Answer 1

Isso soa como um tópico bem conhecido (por exemplo, veja O problema pernicioso da paralisação da memória USB e Para escrever o writeback de fundo menos irritante no LWN), mas infelizmente você não nos contou sobre as versões do software no seu sistema (por exemplo, a versão do kernel) por isso é Vai ser difícil dizer algo muito específico para a sua situação. Eu nunca soube que o write-back excessivo causava OOMs (ao contrário, resultou em pouca capacidade de resposta para mim). Para verificar se era realmente todo o write-back relacionado (ao contrário da memória cache que poderia ser facilmente descartada em uma situação OOM), você precisaria monitorar as linhas Dirty e Writeback em /proc/meminfo e observar atentamente o estado da memória mostrada no Splat OOM.

Geralmente, isso deve ser um problema menor nos novos (no momento em que escrevo) os kernels porque as medidas foram introduzidas para executar o write-back dinâmico afogamento em 4.10 (mas observe que write-back a limitação é desabilitada por padrão se você estiver usando o agendador de E / S CFQ em 4.12+ ).

No fim manual do espectro, Chris Siebenmann descobriu que sintoniza o dirty_background_bytes e dirty_bytes manteve sua máquina responsiva ao gravar em unidades USB . Esses valores residem em /proc/sys/vm e são mencionados junto com outros no artigo de suspensão do USB-stick do LWN vinculado anteriormente (veja também as respostas em Limite Linux background flush (páginas sujas) para discussão sobre esta técnica). Esteja avisado: configurar esses valores incorretamente pode prejudicar a taxa de transferência.