Tomando como base el artículo de Peter Zaitsev sobre MySQL Performance Bottlenecks , quiero hablar un poco sobre PostgreSQL.
Los marcos ORM se utilizan a menudo para trabajar con PostgreSQL en estos días. Por lo general, funcionan bien, pero con el tiempo la carga aumenta y es necesario ajustar el servidor de la base de datos. Tan confiable como es PostgreSQL, puede ralentizarse a medida que aumenta el tráfico.
Hay muchas formas de eliminar los cuellos de botella de rendimiento, pero en este artículo nos centraremos en lo siguiente:
- Parámetros del servidor
- Gestión de conexiones
- Ajuste de autovacío
- Configuración adicional de autovacío
- Hinchazón de mesas (hinchazón)
- Puntos calientes en los datos
- Servidores de aplicaciones
- Replicación
- Entorno del servidor
Acerca de las "categorías" y el "impacto potencial"
"Complejidad" se refiere a lo fácil que es implementar la solución propuesta. Y el "impacto potencial" da una indicación del grado de mejora en el rendimiento del sistema. Sin embargo, debido a la antigüedad del sistema, su tipo, deuda técnica, etc. describir con precisión la complejidad y el impacto puede resultar problemático. Después de todo, en situaciones difíciles, la elección final es siempre suya.
Categorías:
- Complejidad
- Bajo
- Promedio
- Alto
- Bajo medio alto
- Impacto potencial
- Bajo
- La media
- Alto
- Bajo medio alto
Parámetros del servidor
Dificultad: baja.
Impacto potencial: alto.
No hace mucho tiempo, hubo momentos en que las versiones actuales de postgres podían ejecutarse en i386. Desde entonces, la configuración predeterminada ha cambiado, pero aún está configurada para usar la menor cantidad de recursos.
Estas configuraciones son muy fáciles de cambiar y generalmente se configuran durante la instalación inicial. Los valores incorrectos de estos parámetros pueden provocar una alta utilización de CPU y E / S:
- Parámetro tamaño_caché_efectivo ~ 50 a 75%
- Parámetro shared_buffers ~ 1/4 - 1/3 de la cantidad de RAM
- Parámetro work_mem ~ 10MB
El valor recomendado para Effective_cache_size, aunque típico, se puede calcular con mayor precisión si nos referimos a “top” - free + cached .
Calcular el valor de shared_buffers es un acertijo interesante. Puede verlo desde dos lados: si tiene una base de datos pequeña, puede establecer el valor de shared_buffers lo suficientemente grande como para que quepa toda la base de datos en la RAM. Por otro lado, puede configurar la carga en la memoria solo de tablas e índices de uso frecuente (recuerde el 80/20). Anteriormente, se recomendaba establecer el valor en 1/3 de la cantidad de RAM, pero con el tiempo, a medida que aumentaba la cantidad de memoria, se reducía a 1/4. Si se asigna poca memoria, aumentará la carga del procesador y la E / S. Se indicará demasiada asignación de memoria al alcanzar la meseta del procesador y la carga de E / S.
Otro factor a considerar es la caché del sistema operativo . Con suficiente RAM, Linux almacenará en caché las tablas y los índices en la memoria y, dependiendo de cómo esté configurado, podría hacer que PostgreSQL crea que está leyendo datos del disco en lugar de la RAM. La misma página está tanto en el búfer de postgres como en la caché del sistema operativo, y esta es una razón para no hacer que los shared_buffers sean muy grandes. Usando la extensión pg_buffercachepuedes ver el uso de la caché en tiempo real.
El parámetro work_mem especifica la cantidad de memoria utilizada para las operaciones de clasificación. Establecer este valor demasiado bajo garantiza un rendimiento deficiente, ya que la clasificación se realizará utilizando archivos temporales en el disco. Por otro lado, aunque establecer un valor alto no afecta el rendimiento, con un gran número de conexiones existe el riesgo de quedarse sin RAM. Al analizar la memoria utilizada por todas las solicitudes y sesiones, puede calcular el valor requerido.
Con EXPLAIN ANALYZE puede ver cómo se realizan las operaciones de clasificación y, al cambiar el valor de la sesión, determinar cuándo comienza la descarga en el disco.
También puede utilizar puntos de referencia sistemas.
Gestión de conexiones
Dificultad: baja.
Impacto potencial: bajo-medio-alto
La carga alta generalmente se asocia con un aumento de sesiones de clientes por unidad de tiempo. Demasiados de ellos pueden bloquear procesos, causar retrasos o incluso dar lugar a errores.
La solución simple es aumentar el número máximo de conexiones simultáneas:
# postgresql.conf: default is set to 100<br />max_connections
Pero un enfoque más eficiente es la agrupación de conexiones . Hay muchas soluciones, pero la más popular es pgbouncer . PgBouncer puede administrar conexiones usando uno de tres modos:
- (session pooling). . , . , . .
- (transaction pooling). . PgBouncer , , .
- (statement pooling). . . , .
También debe prestar atención a Secure Socket Layer (SSL). Cuando está habilitado, las conexiones utilizarán SSL de forma predeterminada, lo que aumentará la carga en el procesador en comparación con las conexiones no cifradas. Para los clientes habituales, puede configurar la autenticación basada en host sin SSL (
pg_hba.conf) y utilizar SSL para tareas administrativas o para la replicación de transmisión.
Ajuste de autovacío
Dificultad: media.
Impacto potencial: bajo-medio.
El control de concurrencia de múltiples versiones es uno de los principios fundamentales que hacen de PostgreSQL una solución de base de datos tan popular. Sin embargo, uno de los problemas más molestos es que por cada registro modificado o eliminado, se crean copias no utilizadas, que eventualmente deben eliminarse. Un proceso de autovacío configurado incorrectamente puede degradar el rendimiento. Además, cuanto más cargado está el servidor, más se manifiesta el problema.
Los siguientes parámetros se utilizan para controlar el daemon de autovacuum:
- autovacuum_max_workers. ( ). , . . . .
- maintenance_work_mem. , . , . , .
- autovacuum_freeze_max_age TXID WRAPAROUND. , , . , , , . , txid, . / txid pg_stat_activity WRAPAROUND.
Tenga cuidado con la sobrecarga de RAM y CPU. Cuanto mayor sea el valor establecido inicialmente, mayor será el riesgo de agotamiento de los recursos cuando aumenta la carga en el sistema. Si se configura demasiado alto, el rendimiento puede caer drásticamente cuando se excede un cierto nivel de carga.
De manera similar al cálculo de work_mem , este valor se puede calcular aritméticamente o compararlo para obtener valores óptimos .
Configuración adicional de autovacío
Dificultad: alta.
Impacto potencial: alto.
Este método, debido a su complejidad, solo debe usarse cuando el rendimiento del sistema ya está al borde de los límites físicos del host y esto realmente se ha convertido en un problema.
Las opciones de tiempo de ejecución de autovacío se configuran en
postgresql.conf. Desafortunadamente, no existe una solución única para todos que funcione en cualquier sistema de alta carga.
Opciones de almacenamiento para mesas . A menudo, en una base de datos, una parte importante de la carga recae solo en unas pocas tablas. Personalizar la configuración de autovacío para una mesa es una excelente manera de evitar tener que iniciar manualmente VACUUM, que puede afectar significativamente el sistema.
Puede personalizar tablas usando el comando :
ALTER TABLE .. SET STORAGE_PARAMETERHinchazón de mesas (hinchazón)
Dificultad: baja.
Impacto potencial: Medio-alto.
Con el tiempo, el rendimiento del sistema puede verse degradado por políticas de limpieza inadecuadas debido a un exceso de tablas. Así que incluso configurar el demonio de autovacío e iniciar manualmente VACUUM no resuelve el problema. En estos casos, la extensión pg_repack viene al rescate .
Con la extensión pg_repack , puede reconstruir y reorganizar tablas e índices en producción
Puntos calientes en los datos
Dificultad: alta.
Impacto potencial: bajo-medio-alto.
Al igual que con MySQL , PostgreSQL se basa en sus flujos de datos para deshacerse de los puntos de acceso e incluso puede cambiar la arquitectura de su sistema.
En primer lugar, debe prestar atención a lo siguiente:
- Índices . Asegúrese de que haya índices en las columnas que se buscan. Puede usar catálogos y vistas del sistema para monitorear y verificar que las consultas estén usando índices. Utilice las extensiones pg_stat_statement y pgbadger para analizar el rendimiento de las consultas.
- Heap Only Tuples (HOT) . Puede que haya demasiados índices. Puede reducir la hinchazón potencial y reducir el tamaño de la tabla eliminando los índices no utilizados.
- . , , . , , , . , . , , .
- . postgres. , .
- . , . . , !
Dificultad: baja.
Impacto potencial: alto.
Evite ejecutar aplicaciones (PHP, Java y Python) y postgres en el mismo host. Tenga cuidado con las aplicaciones en estos lenguajes, ya que pueden consumir grandes cantidades de RAM, especialmente el recolector de basura, lo que puede generar una competencia con los sistemas de bases de datos por los recursos y disminuir el rendimiento general.
Replicación
Dificultad: baja.
Impacto potencial: alto.
Replicación sincrónica y asincrónica. Las versiones recientes de postgres admiten la replicación lógica y de transmisión en modo síncrono y asincrónico. Si bien el modo de replicación predeterminado es asincrónico, debe considerar las implicaciones de usar la replicación sincrónica, especialmente en redes con latencia significativa.
Entorno del servidor
Por último, pero no menos importante, es un simple aumento en la capacidad del host. Echemos un vistazo a lo que afecta cada uno de los recursos en términos de rendimiento de PostgreSQL:
- . , . . , , -.
- . , , . .
- . .
- -, ,
- .
- . , .
- .
- . .
- WAL-, , , . , (log shipping) , , .
: