MonetDB e as 'Dirty Pages': Como uma Query Read-Only Escreveu Terabytes e a Solução para o Gargalo de Performance

A recente investigação sobre o MonetDB escancara um ponto crítico na otimização de sistemas de banco de dados: a interação entre a camada de aplicação (o próprio banco de dados) e o sistema operacional. O MonetDB, conhecido por sua arquitetura colunar e uso intensivo de memória, mapeia arquivos de dados diretamente para o espaço de endereçamento da memória virtual (via mmap). Ele confia no page cache do kernel Linux para gerenciar seu conjunto de trabalho. O problema surgiu quando uma query aparentemente inofensiva de count-distinct, que deveria ser apenas de leitura, gerou terabytes de escrita para o disco NVMe.

O cerne da questão estava na política de escrita do kernel para as dirty pages. O MonetDB cria arquivos temporários (scratch files) que também são mapeados em memória para lidar com estruturas grandes como tabelas hash. Mesmo que esses dados sejam descartáveis após a query, o kernel, por padrão, força a escrita dessas páginas sujas para o disco após um tempo determinado (vm.dirty_expire_centisecs, 30 segundos) e com base em limites de tamanho (vm.dirty_background_ratio e vm.dirty_ratio). Essa escrita contínua ocorria mesmo com muita RAM livre, pois o kernel não sabe que os dados são temporários. A solução inicial de mover esses arquivos para tmpfs (um sistema de arquivos baseado em RAM) resolveu, mas apresentou trade-offs, como reserva estática de memória e risco de OOM. A abordagem mais robusta foi ajustar os parâmetros sysctl do kernel, como vm.dirty_bytes e vm.dirty_expire_centisecs, permitindo que as páginas sujas permaneçam em RAM por mais tempo, sendo descartadas sem escrita para disco ao final da query, aproveitando a natureza disposable dos dados.

Este caso é um lembrete forte de que o desempenho de um banco de dados de alta performance não depende apenas da sua arquitetura interna ou da otimização das queries, mas também da sintonia fina com o sistema operacional. A falsa premissa de que “memória RAM livre significa que tudo ficará na memória” custou mais de uma hora de execução de query. Entender como o kernel gerencia I/O e memória, especialmente as políticas de writeback de páginas sujas, é fundamental para qualquer engenheiro que lida com dados em escala.

O que se viu no MonetDB, onde uma query de leitura gera escritas massivas, ecoa cenários complexos de I/O que abordamos anteriormente, como na matéria de 26 de março de 2026,