10 pontos por xguru 2021-11-15 | 1 comentários | Compartilhar no WhatsApp
  • A Heap opera um Postgres analítico de vários petabytes

  • Com o crescimento acelerado, a utilização dos nós passou de 80% e começaram a surgir problemas de desempenho no pipeline de ingestão

  • A causa do problema era que SSDs tendem a perder desempenho quando a utilização se aproxima de 100%

  • O problema foi agravado pelo uso do ZFS, que é CoW (Copy-on-Write)

→ sempre que um bloco é atualizado, uma nova cópia é gravada

  • Claro, o CoW também tem várias vantagens

→ a compressão no nível do sistema de arquivos é mais prática do que em outros sistemas de arquivos, permitindo compressão de 4-5x e economia de espaço

→ oferece maior durabilidade, permitindo desativar full_page_writes do Postgres, o que também melhora o desempenho e reduz o IO total

→ snapshots point-in-time que garantem consistência — como as páginas não podem ser realmente modificadas, as páginas antigas são mantidas mesmo durante o snapshot

  • Mas sistemas de arquivos CoW como o ZFS perdem desempenho à medida que enchem

→ como o alocador de blocos precisa encontrar blocos vazios a cada atualização de página, a degradação fica séria quando a utilização é alta

→ também é preciso remover blocos desvinculados anteriormente e misturá-los com os blocos existentes

→ para obter uma taxa de compressão maior, o tamanho de bloco foi configurado para 64kb, o que piorou ainda mais a situação

→ por esses motivos, é melhor não deixar a utilização do ZFS passar de 80%

  • Tentaram atualizar para o ZFS 2.x e trocar a compressão lz4 por Zstandard

lz4 é extremamente rápido e mostrava uma taxa de compressão de cerca de 4,4x

Zstandard chegava a cerca de 5,5x, uma melhora de 20%

→ porém, muitos benchmarks mostravam que o Zstandard era mais lento que o lz4

→ então decidiram fazer testes rigorosos no ambiente real

→ nos testes, o desempenho das queries não mudou, o uso de storage caiu cerca de 20% e o tempo das queries de escrita caiu pela metade

  • O cluster de banco de dados da Heap é dividido em 5 nós, cada um pertencente ao seu próprio ASG

→ para trocar um nó, basta removê-lo do ASG; o ASG cria um novo nó, restaura o backup final e entra em modo warm standby

→ criaram uma AMI com a nova configuração e aplicaram a mudança em cada nó, um por um

→ no total, o uso caiu cerca de 21%, o tempo de escrita diminuiu 50% e o desempenho das queries praticamente não mudou

1 comentários

 
xguru 2021-11-15

O texto não fala sobre uso de CPU, mas vendo um comentário do autor original no HN, parece que aumentou de ~40% para ~50%. (Ou seja, o Zstd usa mais CPU)