Sobre el rendimiento plógico

Hace unos días lanzamos pglogical, una solución de replicación lógica de código abierto para PostgreSQL, que esperamos se incluya en el árbol de PostgreSQL en un futuro no muy lejano. No voy a hablar sobre todas las cosas habilitadas por la replicación lógica:el anuncio de lanzamiento de pglogical presenta una descripción general bastante buena, y Simon también explicó brevemente las ventajas de la replicación lógica en otra publicación hace unos días.

En su lugar, me gustaría hablar sobre un aspecto particular mencionado en el anuncio:la comparación del rendimiento con las soluciones existentes. La página plógica menciona

Valor de referencia

Esta publicación explica los detalles de los puntos de referencia que realizamos para encontrar el rendimiento máximo "sostenible" (transacciones por segundo) que cada una de las soluciones puede manejar sin retrasos. Para hacer eso, realicé una serie de pruebas de pgbench en un par de instancias de AWS i2.4xlarge con una cantidad variable de clientes, y midí el rendimiento en el maestro y cuánto tardó el modo de espera en ponerse al día (si estaba retrasado) . Luego, los resultados se usaron para calcular una estimación del rendimiento máximo en el nodo en espera.

Por ejemplo, supongamos que hemos estado ejecutando pgbench con 16 clientes durante 30 minutos y hemos medido 10000 tps en el maestro, pero el modo de espera estaba retrasado y tomó otros 15 minutos para ponerse al día. Entonces, la estimación de rendimiento máximo sostenible es

tps =(transacciones ejecutadas) / (tiempo de ejecución total hasta que el modo de espera se puso al día)

es decir,

tps =(30 60 10.000) / (45 * 60) =18.000.000 / 2.700 =6.666

Entonces, en ese caso, el rendimiento máximo sostenible en el modo de espera es de 6,666 tps, es decir, solo ~66 % de la tasa de transacción medida en el maestro.

Sistema

El punto de referencia se realizó en un par de instancias de AWS i2.4xlarge, configuradas en el mismo grupo de ubicación (por lo tanto, con una conexión de red de ~2 Gbit entre ellas) y unidades SSD 4x configuradas en RAID-0 (por lo que es poco probable que la E/S sea una problema aquí). Las instancias tienen ~122 GB de RAM, por lo que el conjunto de datos (pgbench con escala 5000) cabe en la RAM. Todas las pruebas se realizaron en PostgreSQL 9.5.0 con exactamente la misma configuración:

checkpoint_timeout = 15min
effective_io_concurrency = 32
maintenance_work_mem = 1GB
max_wal_size = 8GB
min_wal_size = 2GB
shared_buffers = 16GB

Para todos los sistemas de replicación se utilizó la versión disponible más reciente, en particular

• slony1 2.2.4
• SkyTools 3.2

y se configuró una replicación simple como se describe en los tutoriales (ambos usan el ejemplo de pgbench usado para el punto de referencia).

Resultados

Los resultados presentados a continuación también incluyen replicación de transmisión (modo asíncrono) para darle una mejor idea de la sobrecarga asociada con la replicación lógica. Las tasas de transacción no son los números "en bruto" medidos por pgbench, sino las tasas "sostenibles" calculadas usando la fórmula presentada al comienzo de esta publicación.