Como uma atualização do sistema de arquivos economizou milhões de dólares em custos com SSD
(heap.io)<p>- A Heap opera um Postgres analítico de vários petabytes<br />
- 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 <br />
- A causa do problema era que SSDs tendem a perder desempenho quando a utilização se aproxima de 100%<br />
- O problema foi agravado pelo uso do ZFS, que é CoW (Copy-on-Write) <br />
→ sempre que um bloco é atualizado, uma nova cópia é gravada <br />
- Claro, o CoW também tem várias vantagens<br />
→ 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 <br />
→ oferece maior durabilidade, permitindo desativar `full_page_writes` do Postgres, o que também melhora o desempenho e reduz o IO total <br />
→ 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<br />
- Mas sistemas de arquivos CoW como o ZFS perdem desempenho à medida que enchem<br />
→ 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 <br />
→ também é preciso remover blocos desvinculados anteriormente e misturá-los com os blocos existentes <br />
→ para obter uma taxa de compressão maior, o tamanho de bloco foi configurado para 64kb, o que piorou ainda mais a situação <br />
→ por esses motivos, é melhor não deixar a utilização do ZFS passar de 80% <br />
<br />
- Tentaram atualizar para o ZFS 2.x e trocar a compressão `lz4` por `Zstandard` <br />
→ `lz4` é extremamente rápido e mostrava uma taxa de compressão de cerca de 4,4x <br />
→ `Zstandard` chegava a cerca de 5,5x, uma melhora de 20% <br />
→ porém, muitos benchmarks mostravam que o `Zstandard` era mais lento que o `lz4`<br />
→ então decidiram fazer testes rigorosos no ambiente real <br />
→ 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 <br />
<br />
- O cluster de banco de dados da Heap é dividido em 5 nós, cada um pertencente ao seu próprio ASG <br />
→ 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 <br />
→ criaram uma AMI com a nova configuração e aplicaram a mudança em cada nó, um por um <br />
→ no total, o uso caiu cerca de 21%, o tempo de escrita diminuiu 50% e o desempenho das queries praticamente não mudou </p>
1 comentários