Editar: manteremos minha resposta original abaixo, mas tentarei explicar o que está acontecendo aqui e fornecer uma solução geral para você.
Editar 2: Fornece outra opção.
O problema que você está atingindo aqui tem a ver com como o kernel gerencia a E / S. Quando você faz uma gravação em seu sistema de arquivos, essa gravação não é imediatamente confirmada no disco; isso seria incrivelmente ineficiente. Em vez disso, as gravações são armazenadas em cache em uma área de memória conhecida como cache de páginas e, periodicamente, gravadas em blocos no disco. A seção "suja" do seu log descreve o tamanho do cache desta página que ainda não foi gravado no disco:
dirty:123816kB
Então, o que esvazia esse cache sujo? Por que ele não está funcionando?
'Flush' no Linux é responsável por escrever páginas sujas no disco. É um daemon que acorda periodicamente para determinar se as gravações em disco são necessárias e, em caso afirmativo, as executa. Se você é do tipo C, comece por aqui . Flush é incrivelmente eficiente; Ele faz um ótimo trabalho de liberar o material para o disco quando necessário. E está funcionando exatamente como deveria.
O flush é executado fora do seu contêiner LXC, já que seu contêiner LXC não possui seu próprio kernel. Os contêineres LXC existem como um constructo em torno de cgroups , que é um recurso do kernel do Linux que permite melhores limitações e isolamento de grupos de processos , mas não seu próprio kernel ou daemon flush.
Como o seu LXC tem um limite de memória menor que a memória disponível no kernel, coisas estranhas acontecem. O Flush assume que tem a memória completa do host para gravar em cache. Um programa no seu LXC começa a gravar um arquivo grande, ele armazena buffers ... e, eventualmente, atinge seu limite máximo, e começa a chamar o gerenciador de OOM. Esta não é uma falha de nenhum componente em particular; é o comportamento esperado. Mais ou menos. Esse tipo de coisa deve ser tratado pelos cgroups, mas não parece ser assim.
Isso explica completamente o comportamento que você vê entre os tamanhos das instâncias. Você vai começar a flushing para o disco muito mais cedo na micro instância (com 512MB de RAM) vs em uma grande instância
Ok, isso faz sentido. Mas é inútil. Eu ainda preciso me escrever um arquivo big-ass.
Bem, o flush não está ciente do seu limite de LXC. Então, ao invés de corrigir o kernel, existem algumas opções aqui para coisas que você pode tentar ajustar:
/proc/sys/vm/dirty_expire_centiseconds
Isso controla por quanto tempo uma página pode ser mantida no cache sujo e gravada no disco. Por padrão, são 30 segundos; tente configurá-lo mais baixo para começar a empurrá-lo mais rápido.
/proc/sys/vm/dirty_background_ratio
Isso controla qual porcentagem do esvaziamento da memória ativa pode ser preenchida antes de começar a forçar gravações. Há um pouco de mexer na classificação do total exato aqui, mas o mais fácil A explicação é apenas olhar para a sua memória total. Por padrão, é 10% (em algumas distros é 5%). Defina isto mais baixo; forçará as gravações no disco mais cedo e poderá impedir que o seu LXC fique fora dos limites.
Não posso simplesmente estragar um pouco com o sistema de arquivos?
Bem, sim. Mas certifique-se de testar isso .. você pode afetar o desempenho. Nas suas montagens em / etc / fstab onde você vai escrever isso, adicione a opção de montagem ' sync ' .
Resposta original:
Try reducing the blocksize used by DD:
dd if=/dev/zero of=test2 bs=512 count=1024000You can only write one sector at a time (512 bytes on older HDDs, 4096 on newer). If DD is pushing writes to disk faster than the disk can accept them, it will start caching the writes in memory. That's why your file cache is growing.