Disco Azure acima de 4 TiB desliga cache e engana quem otimiza Postgres

A Stormatics documentou um caso em que uma semana de ajuste em shared_buffers, work_mem e effective_cache_size não resolveu leituras lentas: o disco de dados tinha passado de 4 TiB, e o Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → desativa o cache de host nesse limiar sem avisar.

A Stormatics documentou um caso em que uma semana de ajuste em shared_buffers, work_mem e effective_cache_size não resolveu leituras lentas: o disco de dados tinha passado de 4 TiB, e o Azure desativa o cache de host nesse limiar sem avisar.

Em post publicado em 25 de setembro de 2026, Umair Shahid, da Stormatics, descreve um diagnóstico que deveria soar familiar a qualquer time que já brigou com Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → em nuvem: uma semana inteira revisando shared_buffers, effective_cache_size, work_mem e o resto do checklist clássico de tuning, tudo ajustado de forma sensata, e as leituras continuaram lentas. O motivo não estava em nenhum parâmetro do banco. O disco de dados do cliente havia crescido até 4 TiB, e no momento exato em que cruzou essa marca, o Azure desligou o cache de host que ficava na frente dele.

O caso ilustra bem o ângulo que interessa a quem constrói sobre Postgres, não só a quem administra o servidor: o banco confia cegamente na camada de armazenamento embaixo dele. Quando essa camada está limitada, throttled ou sem cache, o Postgres não tem como avisar. Ele só espera. E esperar por um disco lento, de dentro do banco, parece exatamente com um banco mal configurado, então é ali que o tempo de diagnóstico costuma ser gasto, mesmo quando o problema real está uma camada abaixo.

A armadilha dos 4 TiB

No Azure, o host caching é um recurso real de performance: a VM mantém um cache construído a partir da própria memória e de um SSD local, e serve boa parte das leituras a partir dele, sem que precisem viajar até o disco remoto. Para uma carga de leitura pesada, esse cache faz um trabalho silencioso e importante. O problema é que o Azure só suporta host caching em discos gerenciados menores que 4 TiB (até 4.095 GiB). Ao atingir 4 TiB ou mais, o cache desaparece e toda leitura passa a ir direto para o armazenamento remoto.

O detalhe traiçoeiro, segundo Shahid, é que o portal do Azure continua mostrando uma opção de cache disponível para escolher mesmo num disco desse tamanho, só que ela não tem efeito nenhum. É possível olhar a configuração, ver "ReadOnly cache" marcado, e assumir razoavelmente que o cache está ativo, enquanto cada leitura está na verdade indo direto para o disco remoto.

A correção que a Stormatics recomendou para esse cliente foi trocar um disco único gigante por vários discos menores, cada um abaixo de 4 TiB, unidos num volume lógico via LVM ou RAID por software. Cada disco individual mantém seu host cache, o volume combinado entrega a capacidade necessária, e as leituras voltam a ser servidas do cache. Mesmos dados, mesmo Postgres, layout diferente.

A VM também tem teto próprio

A segunda armadilha explica por que às vezes um disco maior e mais rápido não entrega ganho nenhum. O disco tem um limite de performance, mas a VM também tem o seu, e os dois são independentes. A máquina virtual limita quanto de IOPS e throughput ela deixa passar, não importa o que o disco embaixo seja capaz de entregar. Anexar um disco de ponta a uma VM pequena faz o teto da VM ser o teto real: o disco fica parcialmente ocioso enquanto a VM simplesmente não deixa passar mais tráfego.

Por isso, ao investigar um gargalo de I/O, é preciso checar os dois números: para quanto o disco está classificado e para quanto a VM está classificada. Se o throughput medido está encostado no limite não-cacheado da VM, um disco mais rápido não resolve nada. A correção passa por um tamanho de VM maior ou uma família voltada a cargas de armazenamento pesado, e Shahid aponta esse ponto como um dos lugares mais comuns onde dinheiro é gasto na direção errada: upgradar o disco quando a parede era a VM o tempo todo.

Capacidade e performance amarradas

Nas camadas clássicas de Premium SSD, performance escala junto com capacidade: disco pequeno recebe um teto pequeno de IOPS e throughput, disco grande recebe um teto grande, em faixas fixas. A armadilha aqui é sutil: às vezes se provisiona um disco pelo espaço necessário e o resultado é falta de IOPS, porque o tamanho escolhido cai numa faixa de performance modesta. Em outros casos, se provisiona capacidade que nunca será usada só para comprar o IOPS que vem junto com uma faixa maior.

O Premium SSD v2 relaxa essa amarra ao permitir configurar capacidade, IOPS e throughput de forma independente, comprando exatamente a performance necessária sem inflar o tamanho do disco para isso. Shahid é claro que essa flexibilidade vem com trade-offs próprios em torno de cache e configuração, portanto não é um upgrade gratuito: é uma escolha deliberada.

WAL e dados pedem discos diferentes

O Postgres tem duas personalidades de I/O bem distintas convivendo no mesmo sistema. Os arquivos de dados são de leitura pesada e aleatória. O write-ahead log é de escrita pesada e sequencial. Tratar os dois da mesma forma na camada de armazenamento deixa performance na mesa: um cache de leitura é um presente para os arquivos de dados, mas não faz nada de útil pelo WAL, que é quase inteiramente escrita sequencial.

Um layout limpo separa os arquivos de dados, num disco com cache de leitura, do WAL, num disco próprio otimizado para escrita sustentada, sem cache de leitura no caminho. Isso também evita que um pico de atividade de WAL durante uma janela de escrita pesada compita pelo mesmo disco com o tráfego de leitura.

Como confirmar antes de tocar em parâmetro

Antes de mexer em qualquer configuração do Postgres, Shahid recomenda confirmar para onde o tempo está indo, o que leva poucos minutos e evita otimizar a camada errada. O primeiro passo é olhar dentro do próprio Postgres, em pg_stat_activity, observando os wait events: sessões empilhadas em esperas de I/O indicam que o banco está esperando por armazenamento, não por locks ou CPU. O segundo passo é sair do Postgres e ir ao sistema operacional, com uma ferramenta como iostat, para ver utilização de disco, tempo médio de espera por requisição e volume real de leituras e escritas. Utilização travada no topo com tempos de espera subindo indica disco saturado.

Depois disso, compara-se o que foi medido contra os limites nominais do disco e da VM: o throughput está perto do teto do disco ou da VM? O host caching está de fato ativo, ou o disco cruzou a marca de 4 TiB sem que ninguém percebesse? WAL e dados dividem o mesmo disco? Essas perguntas, segundo o autor, quase sempre apontam qual das quatro armadilhas está em jogo.

O que muda para quem constrói sobre Postgres

Para quem escreve aplicação e sobe infraestrutura no Azure, o ponto prático é este: um índice mal calibrado ou um plano de execução ruim ainda são as primeiras coisas a descartar quando uma query está lenta, e nada no post substitui esse trabalho. Mas depois de confirmar que o plano está correto e os índices existem, o próximo lugar a olhar não é mais um parâmetro do postgresql.conf, é o layout de disco por baixo dele. Isso muda a ordem de investigação de quem opera bancos em VM própria no Azure, com discos gerenciados e tamanho de VM configuráveis diretamente. O post trata especificamente desse cenário de infraestrutura sob gestão do próprio time, e não descreve como serviços totalmente gerenciados tratam a camada de disco.

O ponto que Shahid faz questão de deixar claro é que essas correções não custam licença, reescrita de código nem produto novo: são decisões de layout, de tamanho de VM e de configuração de cache. A alternativa cara é nunca encontrar o gargalo real e continuar escalando a instância, pagando mais todo mês por um problema que alguns discos menores, dispostos de outro jeito, resolveriam. O post não trata de bancos gerenciados fora do Azure nem estabelece números equivalentes para AWS ou GCP: cada nuvem impõe limites parecidos em disco e instância, mas os limiares exatos variam e não estão cobertos na fonte.

Fonte: Planet PostgreSQL