PostgreSQL escalado verticalmente

PostgreSQL puede escalar bastante bien verticalmente. Cuantos más recursos (CPU, memoria, disco) pueda poner a disposición de su servidor PostgreSQL, mejor podrá funcionar. Sin embargo, mientras que algunas partes de Postgres pueden hacer uso automáticamente de los recursos aumentados, otras partes necesitan cambios de configuración antes de que se puedan notar las mejoras.

Siga leyendo para obtener más información sobre cómo asegurarse de que PostgreSQL haga un uso completo del sistema en el que lo está ejecutando.

CPU

Qué escala automáticamente

PostgreSQL tiene una arquitectura de proceso tradicional, que consta de un proceso maestro (llamado postmaster ) que genera un nuevo proceso (llamado backend ) para cada nueva conexión de cliente. Esto significa que si hay más núcleos de CPU disponibles, más procesos pueden ejecutarse simultáneamente y, por lo tanto, los backends no tienen que competir tanto por la disponibilidad de la CPU. Las consultas vinculadas a la CPU se completarán más rápido.

Es posible que desee ajustar el máximo de conexiones simultáneas permitidas a nivel de todo el sistema, por base de datos o por usuario:

-- system level
ALTER SYSTEM SET max_connections = 200;

-- database level
ALTER DATABASE dbname CONNECTION LIMIT 200;

-- user level
ALTER ROLE username CONNECTION LIMIT 20;

para que las aplicaciones no autorizadas no terminen acaparando demasiadas conexiones.

Lo que necesita ajustes

El servidor PostgreSQL puede generar procesos para encargarse de las tareas de mantenimiento, como la limpieza, la replicación, las suscripciones (para la replicación lógica), etc.

La opción de configuración de nivel superior para el número de procesos de trabajo es:

# typically specified in postgresql.conf
max_worker_processes = 16

Aumentar este valor puede dan como resultado la aceleración de los trabajos de mantenimiento, las consultas paralelas y la creación de índices.

Consultas paralelas

A partir de la versión 9.6, Postgres puede ejecutar consultas en paralelo si el planificador de consultas decide que ayudará. Las consultas paralelas implican generar trabajadores, distribuir el trabajo entre ellos y luego recopilar (reunir) los resultados. Sujeto al límite general de max_worker_processes establecido anteriormente, Postgres determinará cuántos trabajadores se pueden generar para consultas paralelas según el valor de dos opciones de configuración:

# the maximum number of workers that the system can
# support for parallel operations
max_parallel_workers = 8

# the maximum number of workers that can be started
# by a single Gather or Gather Merge node
max_parallel_workers_per_gather = 8

Si tiene CPU inactivas y consultas paralelizables, aumentar estos valores puede acelerar dichas consultas.

Creación de índices paralelos

En Postgres 11, se agregó soporte para la creación paralela de índices B-Tree. Si crea índices B-Tree con regularidad o los REINDEXA, aumentar este valor puede ayudar:

# the maximum number of parallel workers that can be
# started by a single utility command
max_parallel_maintenance_workers = 8

Esto permitirá que Postgres genere tantos trabajadores (sujeto al límite general de max_worker_processes ) para acelerar la creación de índices B-Tree.

Replicación lógica

La replicación lógica (disponible en Postgres 10 y superior), se basa en procesos de trabajo en el lado de la suscripción para obtener cambios del editor. Al solicitar a Postgres que genere más trabajadores de replicación lógicos, los cambios se pueden obtener y aplicar en paralelo, especialmente si hay más tablas. Esta opción de configuración aumenta el número total de trabajadores de replicación:

# maximum number of logical replication workers
max_logical_replication_workers = 8

En la replicación de transmisión, puede iniciar una sincronización con una copia de seguridad base. Sin embargo, para la replicación lógica, los cambios deben introducirse a través del propio protocolo de replicación, a través de la red. Esto puede llevar mucho tiempo. Permitir más trabajadores durante la fase de sincronización puede acelerar este proceso:

# basically the number of tables that are synced in
# parallel during initialization of subscription
max_sync_workers_per_subscription = 8

Vacío automático

Periódicamente, en función de una serie de ajustes de configuración, Postgres generará una serie de trabajadores que VACÍARÁN las tablas de la base de datos. Por supuesto, esto se llama autovacuum, y la cantidad de trabajadores que genera el iniciador de autovacuum cada vez se puede establecer a través de la configuración:

# the maximum number of autovacuum processes
autovacuum_max_workers = 8

Compresión WAL

Si tiene CPU de sobra, puede intercambiar CPU por ancho de banda de disco comprimiendo las páginas que están escritas en los archivos WAL. Esto reduce la cantidad de datos que deben escribirse en el disco, a expensas de más ciclos de CPU para comprimir los datos. También reduce el tamaño de los datos que deben enviarse a través del cable para la replicación de transmisión.

En la práctica, los beneficios de la compresión WAL bien valen los gastos generales muy razonables. Para activarlo, utilice:

# compresses full page images written to WAL
wal_compression = on

Memoria

Qué escala automáticamente

El sistema operativo administra y utiliza automáticamente la memoria que no utiliza ninguna aplicación para almacenar en caché los datos leídos y escritos en el disco recientemente. Esto acelera enormemente las aplicaciones que hacen un uso intensivo del disco y, sin duda, PostgreSQL.

En Linux, el host más popular para Postgres, el usuario no puede establecer el tamaño de la memoria caché del disco del sistema operativo. Su gestión es interna a Linux. Bajo la presión de la memoria, proporcionará memoria caché de disco a las aplicaciones.

Lo que necesita ajustes

Planificador de consultas

El planificador de consultas debe incluir la cantidad de caché de disco proporcionada por el sistema operativo como un factor en sus estimaciones. Si ha logrado aumentar significativamente la memoria caché del sistema operativo (aumentando la memoria disponible), aumentar esta configuración podría ayudar a mejorar las estimaciones del planificador:

# the planner's assumption about the effective size
# of the disk cache that is available to a single query.
effective_cache_size = 64GB

Memoria Compartida

PostgreSQL utiliza un conjunto de búferes que se comparten entre todos los trabajadores y los procesos de back-end. Estos se denominan búferes compartidos , y la cantidad de memoria asignada para los búferes compartidos se establece mediante la opción de configuración:

shared_buffers = 32GB

Búferes temporales

Cuando una consulta accede a las tablas temporales, los búferes se asignan para almacenar en caché los contenidos que se leen. El tamaño de este búfer se establece mediante la configuración:

# the maximum number of temporary buffers used
# by each database session
temp_buffers = 100MB

Si tiene memoria de sobra y consultas que usan mucho tablas temporales, aumentar este valor puede acelerar dichas consultas.

Memoria de Trabajo

Los backends asignan la memoria de trabajo de forma local y privada. Se utiliza para realizar clasificaciones y uniones sin tener que crear tablas temporales. Aumentar esto desde el valor predeterminado de 4 MB puede permitir que las consultas se completen más rápido durante la creación de la tabla temporal:

# the amount of memory to be used by internal sort
# operations and hash tables before writing to temporary disk files
work_mem = 16MB

Operaciones de mantenimiento

La memoria utilizada por VACUUM, la creación de índices y otros comandos de mantenimiento similares están controlados por la opción de configuración maintenance_work_mem . Aumentar esta cantidad puede acelerar estas operaciones, especialmente en índices o tablas que necesitan ser recreadas.

La memoria utilizada por los trabajadores de autovacuum se puede tomar de la memoria de trabajo de mantenimiento (configurando autovacuum_work_mem = -1 ) o configurado de forma independiente.

# the maximum amount of memory to be used by
# maintenance operations
maintenance_work_mem = 128MB

# maximum amount of memory to be used by each
# autovacuum worker process
autovacuum_work_mem = -1

Disco

Qué escala automáticamente

Los discos se pueden hacer más grandes, más rápidos o más simultáneos. El tamaño del disco es lo único sobre lo que no es necesario instruir a PostgreSQL. De manera predeterminada, PostgreSQL no se limitará a usar el espacio disponible en el disco. Por lo general, esto está bien.

Sin embargo, puede establecer un límite en el tamaño total de los archivos temporales creados para proporcionar cierta protección contra las consultas que intentan clasificar mil millones de filas y similares:

# the maximum amount of disk space that a process
# can use for temporary files
temp_file_limit = 500GB

Lo que necesita ajustes

Concurrencia

Los discos RAID y los sistemas de archivos como ZFS se pueden configurar para admitir más simultaneidad. Es decir, puede tener algunas lecturas/escrituras de disco atendidas simultáneamente por dichos sistemas de archivos debido a la forma en que almacenan o manejan los datos internamente.

Puede permitir que Postgres emita múltiples E/S de disco concurrentes, usando esta configuración:

# the number of concurrent disk I/O operations that
# PostgreSQL expects can be executed simultaneously
effective_io_concurrency = 4

Sin embargo, esto actualmente solo se usa en escaneos de montón de mapas de bits.

Coste de página aleatoria

El planificador de consultas de Postgres asume que las lecturas secuenciales son más rápidas que las lecturas aleatorias. Exactamente cuánto más rápido es un valor que puede modificar. De forma predeterminada, asume que las lecturas aleatorias son 4 veces más costosas.

Dependiendo de la configuración de su disco, la carga de trabajo y la evaluación comparativa, si está seguro de que las lecturas aleatorias son, digamos, solo el doble de costosas que las lecturas secuenciales, puede decírselo a Postgres:

# the planner's estimate of the cost of a disk page
# fetch that is part of a series of sequential fetches
seq_page_cost = 1

# the planner's estimate of the cost of a
# non-sequentially-fetched disk page
random_page_cost = 2

espacios de tabla

Para aprovechar los múltiples discos que no están montados como un gran sistema de archivos único, puede usar espacios de tablas. Con los espacios de tablas, puede colocar tablas o indexar diferentes sistemas de archivos. Esto puede mejorar la simultaneidad y proporciona una manera fácil de manejar el crecimiento de la tabla.

CREATE TABLESPACE disk2 LOCATION '/mnt/disk2/postgres';

Obtenga más información sobre los espacios de tabla aquí.

Red

La red suele ser el recurso menos utilizado en un servidor PostgreSQL y rara vez se satura. Si necesita escalar, es bastante fácil agregar más interfaces de red, cada una con su propia IP y hacer que PostreSQL las escuche todas:

listen_addresses = '10.1.0.10,10.1.0.11'

La carga de los clientes deberá equilibrarse en todas las direcciones IP en las que escucha Postgres.

Otro

Hay algunos otros ajustes de configuración que se pueden modificar, la mayoría de los cuales consumen más CPU y memoria.

Operaciones en particiones

Postgres 10 introdujo el particionamiento de tablas, que se mejoró en Postgres 11. Algunas optimizaciones de consultas en particiones no están activadas de forma predeterminada, ya que podrían generar un mayor consumo de CPU y memoria. Estos son:

# allow a join between partitioned tables to be
# performed by joining the matching partitions
enable_partitionwise_join = on

# allow grouping or aggregation on a partitioned
# tables performed separately for each partition
enable_partitionwise_aggregate = on