El rendimiento óptimo de PostgreSQL depende de los parámetros del sistema operativo definidos correctamente. Los parámetros del kernel del sistema operativo mal ajustados pueden degradar el rendimiento del servidor de la base de datos. Por lo tanto, es imprescindible que estos parámetros se configuren de acuerdo con el servidor de la base de datos y su carga de trabajo. En esta publicación, analizaremos algunos parámetros importantes del kernel de Linux que pueden afectar el rendimiento del servidor de la base de datos y cómo ajustarlos.
SHMMAX / SHMALL
SHMMAX es un parámetro del núcleo utilizado para determinar el tamaño máximo de un único segmento de memoria compartida que un proceso de Linux puede asignar. Antes de la versión 9.2, PostgreSQL usaba el Sistema V (SysV), que requiere la configuración SHMMAX. Después de 9.2, PostgreSQL cambió a la memoria compartida POSIX. Entonces, ahora se requieren menos bytes de memoria compartida del Sistema V.
Antes de la versión 9.3, SHMMAX era el parámetro de kernel más importante. El valor SHMMAX se especifica en bytes.
Del mismo modo,
SHMALL es otro parámetro del núcleo utilizado para determinar
páginas de memoria compartida en todo el sistema. Use el comando
ipcs para ver los valores actuales de SHMMAX, SHMALL o SHMMIN.
Detalles de SHM * - Linux$ ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 1073741824 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1
Detalles de SHM * - MacOS X $ ipcs -M IPC status from as of Thu Aug 16 22:20:35 PKT 2018 shminfo: shmmax: 16777216 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 32 (max number of shared memory identifiers) shmseg: 8 (max shared memory segments per process) shmall: 1024 (max amount of shared memory in pages)
PostgreSQL usa
System V IPC para asignar memoria compartida. Este parámetro es uno de los parámetros del núcleo más importantes. Cada vez que recibe los siguientes mensajes de error, significa que tiene una versión anterior de PostgreSQL y un valor SHMMAX muy bajo. Se espera que los usuarios ajusten y aumenten el valor de acuerdo con la memoria compartida que van a usar.
Posibles errores de configuración incorrecta
Si SHMMAX no está configurado correctamente, puede recibir un error al intentar inicializar un clúster PostgreSQL utilizando el comando
initdb .
fallo initdbDETAIL: Failed system call was shmget(key=1, size=2072576, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1Del mismo modo, puede recibir un error al iniciar el servidor PostgreSQL utilizando el comando
pg_ctl .
falla pg_ctlDETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.Comprender las diferencias en las definiciones
La definición de los parámetros SHMMAX / SHMALL es ligeramente diferente en Linux y MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
El comando
sysctl se puede usar para cambiar temporalmente un valor. Para establecer valores constantes, agregue una entrada en
/etc/sysctl.conf . Los detalles se dan a continuación.
Cambiar la configuración del kernel en MacOS X # Get the value of SHMMAX sudo sysctl kern.sysv.shmmax kern.sysv.shmmax: 4096 # Get the value of SHMALL sudo sysctl kern.sysv.shmall kern.sysv.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kern.sysv.shmmax=16777216 kern.sysv.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kern.sysv.shmall=16777216 kern.sysv.shmall: 4096 -> 16777216
Cambiar los parámetros del kernel de Linux # Get the value of SHMMAX sudo sysctl kernel.shmmax kernel.shmmax: 4096 # Get the value of SHMALL sudo sysctl kernel.shmall kernel.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kernel.shmmax=16777216 kernel.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kernel.shmall=16777216 kernel.shmall: 4096 -> 16777216
Recuerde : para hacer cambios permanentes, agregue estos valores a /etc/sysctl.confPáginas grandes (páginas enormes)
El valor predeterminado de Linux es páginas 4K, BSD usa
páginas Super y Windows usa
páginas grandes . Una página es una porción de RAM asignada a un proceso. Un proceso puede tener varias páginas, según los requisitos de memoria. Cuanta más memoria necesita un proceso, más páginas se le ha asignado. El sistema operativo admite una tabla de asignación de páginas para procesos. Cuanto más pequeño es el tamaño de la página, más grande es la tabla, más se tarda en encontrar una página en esta tabla de páginas. Por lo tanto, las páginas grandes le permiten usar una gran cantidad de memoria con una sobrecarga reducida; menos visitas a la página, menos errores de página, operaciones de lectura / escritura más rápidas a través de grandes memorias intermedias El resultado es un rendimiento mejorado.
PostgreSQL solo admite páginas grandes en Linux. De manera predeterminada, Linux usa 4 KB de páginas de memoria, por lo que si tiene demasiadas operaciones de memoria, debe instalar páginas más grandes. Hay una ganancia de rendimiento cuando se usan páginas grandes de 2 MB y hasta 1 GB. El tamaño de página grande se puede establecer en el momento del arranque. Puede verificar fácilmente los parámetros de la página grande y su uso en su computadora Linux usando el comando
cat / proc / meminfo | grep -i enorme .
Obtención de información sobre páginas grandes (solo Linux) Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
En este ejemplo, aunque el tamaño de página grande se establece en 2048 (2 MB), el número total de páginas grandes es 0. Esto significa que las páginas grandes están deshabilitadas.
Script para determinar el número de páginas grandes
Este script simple devuelve el número requerido de páginas grandes. Ejecute el script en su servidor Linux mientras se ejecuta PostgreSQL. Verifique que el directorio de datos PostgreSQL esté configurado para la variable de entorno
$ PGDATA .
Obtener el número de páginas grandes requeridas
El resultado del script es el siguiente:
Salida de script Pid: 12737 VmPeak: 180932 kB Hugepagesize: 2048 kB Set Huge Pages: 88
El valor recomendado para páginas grandes es 88, por lo que debe establecerlo en 88.
Instalar páginas grandes sysctl -w vm.nr_hugepages=88
Verifique las páginas grandes ahora, verá que las páginas grandes no se usan (HugePages_Free = HugePages_Total).
Información sobre páginas grandes nuevamente (solo Linux) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 88 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Ahora configure huge_pages "on" en $ PGDATA / postgresql.conf y reinicie el servidor.
Y nuevamente, información sobre páginas grandes (solo Linux) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 81 HugePages_Rsvd: 64 HugePages_Surp: 0 Hugepagesize: 2048 kB
Ahora puede ver que se utilizan muy pocas páginas grandes. Ahora intentemos agregar algunos datos a la base de datos.
Algunas operaciones de bases de datos para reciclar páginas grandes postgres=
Veamos si usamos páginas más grandes ahora que antes.
Una vez más información en páginas grandes (solo Linux) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 18 HugePages_Rsvd: 1 HugePages_Surp: 0 Hugepagesize: 2048 kB
Ahora puede ver que la mayoría de las páginas grandes están en uso.
Nota: el valor aproximado para HugePages utilizado aquí es muy bajo, lo que no es un valor normal para una máquina en un entorno alimentario. Evalúe el número requerido de páginas para su sistema y configúrelas en función de la carga y los recursos.vm.swappiness
vm.swappiness es otro parámetro del núcleo que puede afectar el rendimiento de la base de datos. Este parámetro se usa para controlar el comportamiento de intercambio (intercambio de páginas hacia y desde la memoria) en Linux. El valor varía de 0 a 100. Determina cuánta memoria se descargará o descargará. Cero significa deshabilitar el intercambio, y 100 significa intercambio agresivo.
Puede obtener un buen rendimiento estableciendo valores más bajos.
Establecer el valor en 0 en los núcleos más nuevos puede hacer que OOM Killer (proceso de limpieza de memoria de Linux) mate el proceso. Por lo tanto, puede establecer de forma segura el valor en 1 si desea minimizar el intercambio. El valor predeterminado en Linux es 60. Un valor más alto hace que la MMU (unidad de administración de memoria) use más espacio de paginación que la RAM, mientras que un valor más bajo guarda más datos / código en la memoria.
Un valor más bajo es una buena apuesta para mejorar el rendimiento en PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Las aplicaciones reciben memoria y la liberan cuando ya no la necesitan. Pero en algunos casos, la aplicación obtiene demasiada memoria y no la libera. Esto puede causar un asesino OOM. Estos son los valores posibles para el parámetro
vm.overcommit_memory con una descripción para cada uno:
- Sobrecompromiso heurístico (predeterminado); heurística basada en el núcleo
- Permitir sobrecompromiso de todos modos
- No exagere, no exceda la relación de sobrecompromiso.
Enlace: https://www.kernel.org/doc/Documentation/vm/overcommit-accountingvm.overcommit_ratio : porcentaje de RAM disponible para sobrecarga. Un valor del 50% en un sistema con 2 GB de RAM puede asignar hasta 3 GB de RAM.
Un valor de 2 para vm.overcommit_memory proporciona un mejor rendimiento para PostgreSQL. Este valor maximiza el uso de RAM por el proceso del servidor sin ningún riesgo significativo de ser asesinado por el proceso asesino OOM. La aplicación podrá reiniciarse, pero solo dentro del gasto excesivo, lo que reduce el riesgo de que el asesino de OOM mate el proceso. Por lo tanto, un valor de 2 ofrece un mejor rendimiento que el valor predeterminado de 0. Sin embargo, la confiabilidad se puede mejorar asegurando que la memoria fuera del rango aceptable no se sobrecargue. Esto elimina el riesgo de que el proceso sea asesinado por el asesino de OOM.
En sistemas sin paginación, puede ocurrir un problema con vm.overcommit_memory igual a 2.
https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMITvm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio es el porcentaje de memoria llena de páginas sucias que deben escribirse en el disco. Restablecer a disco en segundo plano. El valor de este parámetro varía de 0 a 100; sin embargo, un valor por debajo de 5 puede ser ineficiente y algunos núcleos no lo admiten. 10 es el valor predeterminado en la mayoría de los sistemas Linux. Puede mejorar el rendimiento de las operaciones de grabación intensiva a una velocidad menor, lo que significa que Linux volcará las páginas sucias en segundo plano.
Debe establecer el valor de
vm.dirty_background_bytes según la velocidad de su disco.
No hay valores "buenos" para estos dos parámetros, ya que ambos dependen del hardware. Sin embargo, establecer vm.dirty_background_ratio en 5 y vm.dirty_background_bytes al 25% de la velocidad del disco aumentará el rendimiento a ~ 25% en la mayoría de los casos.
vm.dirty_ratio / dirty_bytes
Esto es lo mismo que
vm.dirty_background_ratio / dirty_background_bytes , excepto que el restablecimiento se realiza en una sesión de trabajo, bloqueando la aplicación. Por lo tanto, vm.dirty_ratio debería ser superior a
vm.dirty_background_ratio . Esto garantiza que los procesos en segundo plano comenzarán antes para evitar el bloqueo de la aplicación tanto como sea posible. Puede ajustar la diferencia entre estas dos relaciones según la carga de E / S del disco.
Resumen
Puede configurar otros parámetros para aumentar la productividad, pero las mejoras serán mínimas y no obtendrá muchos beneficios. Debemos recordar que no todos los parámetros se aplican a todos los tipos de aplicaciones. Algunas aplicaciones funcionan mejor cuando configuramos algunos ajustes, y otras no. Debe encontrar el equilibrio adecuado entre las configuraciones de estos parámetros para la carga de trabajo esperada y el tipo de aplicación, y también al configurar, debe tener en cuenta el comportamiento del sistema operativo. Configurar los parámetros del kernel no es tan fácil como ajustar los parámetros de la base de datos: es más difícil dar sus recomendaciones aquí.