<p>- Heap opera un Postgres de múltiples petabytes para análisis<br />
- Con su rápido crecimiento, el uso de los nodos superó el 80% y empezaron a aparecer problemas de rendimiento en el pipeline de ingesta <br />
- La causa del problema era que los SSD tienden a degradar su rendimiento cuando su uso se acerca al 100%<br />
- El problema se agravaba por usar ZFS, que es CoW (Copy-on-Write) <br />
→ cada vez que se actualiza un bloque, se escribe una nueva copia <br />
- Por supuesto, CoW también tiene varias ventajas<br />
→ la compresión a nivel de sistema de archivos es más sencilla que en otros sistemas de archivos, lo que permite comprimir 4-5x y ahorrar espacio <br />
→ ofrece mayor durabilidad, por lo que se puede desactivar `full_page_writes` de Postgres; con eso también mejora el rendimiento y se reduce el IO total <br />
→ snapshots point-in-time que garantizan consistencia: como las páginas no pueden modificarse realmente, se conservan las páginas anteriores incluso durante el snapshot<br />
- Pero los sistemas de archivos CoW como ZFS pierden rendimiento a medida que se llenan<br />
→ cada vez que se actualiza una página, el asignador de bloques tiene que buscar bloques libres, así que cuando el nivel de uso sube, la degradación de rendimiento se vuelve severa <br />
→ hay que eliminar bloques previamente desvinculados y mezclarlos con los bloques existentes <br />
→ para lograr una mayor tasa de compresión, se configuró un tamaño de bloque grande de 64kb, lo que empeoró aún más la situación <br />
→ por estas razones, es mejor que el uso de ZFS no supere el 80% <br />
<br />
- Intentaron actualizar a ZFS 2.x y cambiar de compresión lz4 a compresión Zstandard <br />
→ lz4 es extremadamente rápido y muestra una tasa de compresión de ~4.4x <br />
→ Zstandard mostró una tasa de compresión de hasta ~5.5x, una mejora del 20% <br />
→ sin embargo, muchos benchmarks muestran que Zstandard es más lento que lz4<br />
→ por eso decidieron hacer pruebas estrictas en un entorno real <br />
→ como resultado de las pruebas, el rendimiento de las consultas no cambió, el uso de almacenamiento bajó ~20% y el tiempo de las consultas de escritura se redujo a la mitad <br />
<br />
- El clúster de base de datos de Heap está dividido en 5 nodos, cada uno dentro de su propio ASG <br />
→ cambiar un nodo es simple: basta con separarlo del ASG, entonces el ASG crea un nodo nuevo, lo restaura desde el respaldo final y entra en modo warm standby <br />
→ crearon una AMI con la nueva configuración y avanzaron nodo por nodo <br />
→ el uso total se redujo ~21%, el tiempo de escritura cayó 50% y el rendimiento de las consultas prácticamente no cambió </p>
1 comentarios