Configuración de un entorno óptimo para PostgreSQL

Bienvenido a PostgreSQL, un poderoso sistema de base de datos de código abierto que puede alojar desde unos pocos megabytes de datos de clientes para una pequeña empresa hasta cientos de terabytes de "big data" para corporaciones multinacionales. Independientemente de la aplicación, es probable que se necesite ayuda con la instalación y la configuración para preparar la base de datos para la acción.

Cuando se instala un nuevo servidor, la configuración de PostgreSQL es mínima, ya que está diseñada para ejecutarse en la menor cantidad de hardware posible. Sin embargo, muy rara vez son óptimos. Aquí, repasaremos una configuración básica para nuevos proyectos y cómo configurar PostgreSQL para que se ejecute de la manera más óptima en nuevos proyectos.

Alojamiento

Alojamiento local

Con una base de datos local, la mejor opción es un host completo, ya que las máquinas virtuales generalmente funcionan más lentamente, a menos que estemos hablando de máquinas virtuales de nivel empresarial de alto nivel. Esto también permite un control más estricto sobre las configuraciones de CPU, memoria y disco. Sin embargo, esto viene con la necesidad de tener un experto disponible (o contratado) para realizar el mantenimiento del servidor.

Nube

Alojar una base de datos en la nube puede ser maravilloso en algunos aspectos o una pesadilla en otros. A menos que la plataforma en la nube elegida esté altamente optimizada (lo que generalmente significa un precio más alto), puede tener problemas con entornos de mayor carga. Esté atento a si el servidor en la nube es o no compartido o dedicado (dedicado que permite un rendimiento completo del servidor para la aplicación), así como el nivel de IOPS (operaciones de entrada/salida por segundo) proporcionado por un servidor en la nube. Cuando (o si) la aplicación crece hasta el punto de que la mayoría de los datos no se pueden almacenar en la memoria, la velocidad de acceso al disco es crucial.

Configuración general del anfitrión

Los pilares principales necesarios para configurar PostgreSQL de manera confiable se basan en las capacidades de CPU, memoria y disco del host. Dependiendo de las necesidades de las aplicaciones, un host suficiente y una configuración de PostgreSQL bien ajustada tendrán un impacto sorprendente en el rendimiento del sistema de base de datos.

Elegir un sistema operativo

PostgreSQL se puede compilar en la mayoría de los sistemas operativos similares a Unix, así como en Windows. Sin embargo, el rendimiento en Windows ni siquiera es comparable con un sistema similar a Unix, por lo que, a menos que sea para un pequeño proyecto desechable, apegarse a un sistema similar a Unix establecido será el camino a seguir. Para esta discusión, nos ceñiremos a los sistemas basados ​​en Linux.

La distribución de Linux aparentemente más utilizada para hospedar PostgreSQL es un sistema basado en Red Hat, como CentOS o Scientific Linux, o incluso el propio Red Hat. Dado que Red Hat y CentOS se centran en la estabilidad y el rendimiento, la comunidad detrás de estos proyectos trabaja arduamente para garantizar que las aplicaciones importantes, como las bases de datos, estén en la versión de Linux más segura y confiable posible.

NOTA:Linux tiene una gama de versiones de kernel que no son óptimas para ejecutar PostgreSQL, por lo que se recomienda evitarlas en la medida de lo posible (especialmente en aplicaciones donde el máximo rendimiento es de suma importancia). Los puntos de referencia han demostrado que la cantidad de transacciones por segundo cae desde la versión del kernel 3.4 a la 3.10, pero se recupera y mejora significativamente en el kernel 3.12. Desafortunadamente, esto descarta el uso de CentOS 7 si se va por la ruta de CentOS. CentOS 6 sigue siendo una versión válida y compatible del sistema operativo, y se espera que CentOS 8 se lance antes de que 6 deje de ser compatible.

Instalación

La instalación se puede realizar por fuente o utilizando repositorios mantenidos por la distribución de Linux elegida, o mejor aún, el Grupo de desarrollo global de PostgreSQL (PGDG), que mantiene repositorios para sistemas basados ​​en Red Hat (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux y Fedora), así como paquetes para Debian y Ubuntu. El uso de los paquetes PGDG garantizará que las actualizaciones de PostgreSQL estén disponibles para su actualización en el momento del lanzamiento, en lugar de esperar a que los repositorios integrados de la distribución de Linux las aprueben y las proporcionen.

CPU

En estos días, no es difícil tener varios núcleos disponibles para un host de base de datos. PostgreSQL en sí mismo recientemente comenzó a agregar capacidades de subprocesos múltiples en el nivel de consulta, y mejorará mucho en los próximos años. Pero incluso sin estas mejoras nuevas y futuras, PostgreSQL en sí mismo genera nuevos subprocesos para cada conexión a la base de datos por parte de un cliente. Estos subprocesos utilizarán esencialmente un núcleo cuando estén activos, por lo que la cantidad de núcleos necesarios dependerá del nivel de conexiones simultáneas necesarias y consultas simultáneas.

Una buena línea de base para comenzar es un sistema de 4 núcleos para una aplicación pequeña. Suponiendo que las aplicaciones bailan entre ejecutar consultas y dormir, un sistema de 4 núcleos puede manejar un par de docenas de conexiones antes de sobrecargarse. Agregar más núcleos ayudará a escalar con una carga de trabajo cada vez mayor. No es raro que las bases de datos de PostgreSQL muy grandes tengan más de 48 núcleos para atender cientos de conexiones.

Consejos de ajuste: Incluso si Hyper-Threading está disponible, las transacciones por segundo generalmente son más altas cuando Hyper-Threading está deshabilitado. Para consultas de bases de datos que no son demasiado complejas, pero que tienen una frecuencia más alta, más núcleos son más importantes que núcleos más rápidos.

Memoria

La memoria es un aspecto extremadamente importante para el rendimiento general de PostgreSQL. La configuración principal de PostgreSQL en términos de memoria es shared_buffers, que es una porción de memoria asignada directamente al servidor de PostgreSQL para el almacenamiento en caché de datos. Cuanto mayor sea la probabilidad de que los datos necesarios vivan en la memoria, más rápidas serán las consultas, y las consultas más rápidas significan una configuración central de CPU más eficiente, como se explicó en la sección anterior.

Las consultas también, a veces, necesitan memoria para realizar operaciones de clasificación en los datos antes de devolverlos al cliente. Esto usa memoria ad-hoc adicional (separada de shared_buffers) o archivos temporales en el disco, que es mucho más lento.

Consejos de ajuste: Un punto de partida básico para configurar shared_buffers es establecerlo en 1/4 del valor de la RAM disponible del sistema. Esto permite que el sistema operativo también realice su propio almacenamiento en caché de datos, así como cualquier proceso en ejecución que no sea la propia base de datos.

Aumentar work_mem puede acelerar las operaciones de clasificación, sin embargo, aumentarlo demasiado puede obligar al host a quedarse sin memoria, ya que el conjunto de valores puede emitirse parcial o totalmente varias veces por consulta. Si varias consultas solicitan varios bloques de memoria para ordenar, puede agregar rápidamente más memoria de la que está disponible en el host. Manténgalo bajo y levántelo lentamente hasta que el rendimiento sea el deseado.

Usando el comando 'libre' (como 'libre -h'), establezca el tamaño_caché_efectivo en la suma de la memoria que está libre y almacenada en caché. Esto le permite al planificador de consultas saber el nivel de almacenamiento en caché del sistema operativo que puede estar disponible y ejecutar mejores planes de consulta.

Disco

El rendimiento del disco puede ser una de las cosas más importantes a considerar al configurar un sistema. Las velocidades de entrada/salida son importantes para grandes cargas de datos o para obtener grandes cantidades de datos para procesar. También determina qué tan rápido PostgreSQL puede sincronizar la memoria con el disco para mantener el grupo de memoria óptimo.

Un poco de preparación en los discos puede ayudar a mejorar instantáneamente el rendimiento potencial, así como preparar el sistema de base de datos para el futuro para el crecimiento.

• Discos separados

  Una instalación nueva de PostgreSQL creará el directorio de datos del clúster en algún lugar de la unidad principal (y posiblemente la única) disponible en el sistema.

  Una configuración básica con más unidades sería agregar una unidad separada (o un conjunto de unidades a través de RAID). Tiene la ventaja de tener toda la transferencia de datos relacionada con la base de datos operando en un canal de E/S diferente del sistema operativo principal. También permite que la base de datos crezca sin temor a que el espacio sea insuficiente y cause problemas y errores en otras partes del sistema operativo.

  Para las bases de datos con una cantidad extrema de actividad, el directorio de registro de transacciones de PostgreSQL (xlog) se puede colocar en otra unidad más, separando las E/S más pesadas a otro canal lejos del sistema operativo principal, así como del directorio de datos principal. Esta es una medida avanzada que ayuda a obtener más rendimiento de un sistema, que de otro modo podría estar cerca de sus límites.

• Uso de RAID

  La configuración de RAID para las unidades de la base de datos no solo protege contra la pérdida de datos, sino que también puede mejorar el rendimiento si se utiliza la configuración de RAID adecuada. En general, se considera que RAID 1 o 10 son los mejores, y 10 ofrece paridad y velocidad general. RAID 5, sin embargo, aunque tiene niveles más altos de redundancia, sufre una disminución significativa del rendimiento debido a la forma en que distribuye los datos en varios discos. Planifique la mejor opción disponible con mucho espacio para el crecimiento de los datos, y esta será una configuración que no necesitará cambiarse con frecuencia, si es que lo hace.

• Uso de SSD

  Las unidades de estado sólido son maravillosas para el rendimiento y, si se ajustan al presupuesto, las SSD empresariales pueden hacer que las cargas de trabajo pesadas de procesamiento de datos sean más rápidas día y noche. Las bases de datos de tamaño pequeño a mediano con cargas de trabajo de tamaño pequeño a mediano pueden ser excesivas, pero cuando se lucha por el aumento porcentual más pequeño en aplicaciones grandes, SSD puede ser la panacea.

Consejos de ajuste: Elija una configuración de unidad que sea mejor para la aplicación en cuestión y que tenga mucho espacio para crecer con el tiempo a medida que aumentan los datos.

Si usa un SSD, establecer random_page_cost en 1,5 o 2 (el valor predeterminado es 4) será beneficioso para el planificador de consultas, ya que la obtención aleatoria de datos es mucho más rápida que la que se ve en los discos giratorios.

Parámetros de configuración inicial

Al configurar PostgreSQL por primera vez, hay un puñado de ajustes de configuración que se pueden cambiar fácilmente en función de la potencia del host. A medida que la aplicación consulta la base de datos con el tiempo, se pueden realizar ajustes específicos según las necesidades de la aplicación. Sin embargo, ese será el tema de un blog de ajuste por separado.

Configuración de memoria

shared_buffers:establecido en 1/4 de la memoria del sistema. Si el sistema tiene menos de 1 GB de memoria total, establezca ~ 1/8 de la memoria total del sistema

work_mem:el valor predeterminado es 4 MB, e incluso puede ser suficiente para la aplicación en cuestión. Pero si los archivos temporales se crean con frecuencia y esos archivos son bastante pequeños (decenas de megabytes), podría valer la pena aumentar esta configuración. Una configuración de nivel de entrada conservadora puede ser (1/4 de memoria del sistema / max_connections). Esta configuración depende en gran medida del comportamiento real y la frecuencia de las consultas a la base de datos, por lo que solo debe aumentarse con precaución. Esté preparado para reducirlo a los niveles anteriores si ocurren problemas.

tamaño_caché_efectivo:Establecido en la suma de la memoria que está libre y almacenada en caché informada por el comando 'libre'.

Configuración del punto de control

Para PostgreSQL 9.4 y versiones anteriores:
checkpoint_segments:una cantidad de segmentos de punto de control (16 megabytes cada uno) para proporcionar el sistema de registro de escritura anticipada. El valor predeterminado es 3 y se puede aumentar de forma segura a 64 incluso para bases de datos pequeñas.

Para PostgreSQL 9.5 y superior:
max_wal_size:esto reemplazó a checkpoint_segments como configuración. El valor predeterminado es 1 GB y puede permanecer aquí hasta que necesite más cambios.

Seguridad

listen_address:esta configuración determina en qué direcciones IP personales / tarjetas de red escuchar las conexiones. En una configuración simple, es probable que solo haya una, mientras que las redes más avanzadas pueden tener varias tarjetas para conectarse a varias redes. * Significa escuchar todo. Sin embargo, si la aplicación que accede a la base de datos vivirá en el mismo host que la propia base de datos, bastará con mantenerla como "localhost".

Registro

Algunas configuraciones básicas de registro que no sobrecargarán los registros son las siguientes.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0