El rendimiento óptimo de PostgreSQL depende de los parámetros del sistema operativo definidos correctamente. Los ajustes del kernel del sistema operativo mal configurados pueden provocar un rendimiento deficiente del servidor de la base de datos. Por lo tanto, es imperativo que estas configuraciones se configuren de acuerdo con el servidor de 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 bases de datos y cómo configurarlos.
SHMMAX / SHMALL
SHMMAX es un parámetro del kernel que se utiliza 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 System V (SysV), que requiere la configuración SHMMAX. Después de la versión 9.2, PostgreSQL cambió a la memoria compartida POSIX. Por lo tanto, ahora se requieren menos bytes de memoria compartida del System V.
Antes de la versión 9.3, SHMMAX era el parámetro del kernel más importante. El valor SHMMAX se especifica en bytes.
Del mismo modo, PEQUEÑO es otro parámetro del kernel utilizado para determinar
Volumen de páginas de memoria compartida en todo el sistema. Para ver los valores actuales SHMMAX, SHMALL o SHMMIN, use el comando ips.
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) = 1Detalles 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)
Usos de PostgreSQL Sistema V IPC para asignar memoria compartida. Este parámetro es uno de los parámetros del kernel más importantes. Cada vez que recibe los siguientes mensajes de error, significa que tiene una versión anterior de PostgreSQL y su valor SHMMAX es muy bajo. Se espera que los usuarios ajusten y aumenten el valor de acuerdo con la memoria compartida que pretenden utilizar.
Posibles errores de configuración
Si SHMMAX no está configurado correctamente, puede recibir un error al intentar inicializar un clúster de PostgreSQL usando el comando initdb.
Fallo de initdb
DETAIL: 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 1
Asimismo, puede recibir un error al iniciar el servidor PostgreSQL usando el comando pg_ctl.
pg_ctl Fallo
DETAIL: 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
Equipo sysctl se puede utilizar para cambiar temporalmente el valor. Para establecer valores constantes, agregue una entrada a /etc/sysctl.conf. Los detalles están 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 -> 16777216Cambiar los parámetros del kernel en 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 -> 16777216No te olvides: Para que los cambios sean permanentes, agregue estos valores a /etc/sysctl.conf
Paginas enormes
Linux usa páginas de memoria de 4 KB de forma predeterminada, BSD usa páginas de memoria de XNUMX KB. Super páginas, y en Windows - Páginas grandes. Una página es una parte de RAM asignada a un proceso. Un proceso puede tener varias páginas según los requisitos de memoria. Cuanta más memoria requiere un proceso, más páginas se le asignan. El sistema operativo mantiene una tabla de asignación de páginas para los procesos. Cuanto menor sea el tamaño de la página, mayor será la tabla y más tiempo llevará encontrar una página en esa tabla de páginas. Por lo tanto, las páginas grandes permiten utilizar grandes cantidades de memoria con una sobrecarga reducida; menos páginas vistas, menos errores de página, operaciones de lectura/escritura más rápidas en buffers más grandes. El resultado es un rendimiento mejorado.
PostgreSQL sólo admite páginas grandes en Linux. De forma predeterminada, Linux usa páginas de memoria de 4 KB, por lo que en los casos en que hay demasiadas operaciones de memoria, es necesario configurar páginas más grandes. Se observan mejoras de rendimiento cuando se utilizan páginas grandes de 2 MB y hasta 1 GB. El tamaño de página grande se puede configurar en el momento del arranque. Puede verificar fácilmente los parámetros de la página grande y su uso en su máquina Linux usando el comando gato /proc/meminfo | grep -yo enorme.
Obtener 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 kBEn este ejemplo, aunque el tamaño de página grande se establece en 2048 (2 MB), el número total de páginas grandes se establece en 0. Esto significa que las páginas grandes están deshabilitadas.
Script para determinar el número de páginas grandes.
Este sencillo script devuelve el número requerido de páginas grandes. Ejecute el script en su servidor Linux mientras se ejecuta PostgreSQL. Asegúrese de que para la variable de entorno $PGDATA Se especifica el directorio de datos de PostgreSQL.
Obtener la cantidad de páginas grandes requeridas
#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid: $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak: $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize: $hps kB"
hp=$((peak/hps))
echo Set Huge Pages: $hpLa salida del script se ve así:
Salida del guión
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88El valor recomendado para páginas grandes es 88, por lo que debes establecerlo en 88.
Instalación de páginas grandes
sysctl -w vm.nr_hugepages=88Verifique las páginas grandes ahora, verá que no se utilizan páginas grandes (HugePages_Free = HugePages_Total).
Páginas grandes revisadas (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 kBAhora establezca el parámetro Huge_pages en "on" en $PGDATA/postgresql.conf y reinicie el servidor.
Una vez más, 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 kBAhora puede ver que se utilizan muy pocas páginas grandes. Intentemos ahora agregar algunos datos a la base de datos.
Algunas operaciones de bases de datos para reciclar páginas grandes
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Veamos si ahora utilizamos páginas más grandes que antes.
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 kBAhora puede ver que se están utilizando la mayoría de las páginas grandes.
Nota: El valor estimado para HugePages utilizado aquí es muy bajo, lo cual no es un valor normal para una máquina que ejecuta un entorno de producto. Calcule la cantidad requerida de páginas para su sistema y configúrelas en consecuencia según la carga y los recursos.
vm.intercambio
vm.intercambio es otro parámetro del kernel que puede afectar el rendimiento de la base de datos. Esta opción se utiliza para controlar el comportamiento del intercambio (intercambiar páginas dentro y fuera de la memoria) en Linux. El valor oscila entre 0 y 100. Determina cuánta memoria se paginará o paginará. Cero significa que no hay intercambio y 100 significa intercambio agresivo.
Puede obtener un buen rendimiento estableciendo valores más bajos.
Establecer esto en 0 en kernels más nuevos puede hacer que OOM Killer (el proceso de limpieza de memoria de Linux) finalice el proceso. Por lo tanto, es seguro establecerlo 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 intercambio que la RAM, mientras que un valor más bajo mantiene 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 adquieren 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. Aquí están los posibles valores de los parámetros. vm.overcommit_memory con una descripción para cada uno:
- Sobrecompromiso heurístico (predeterminado); heurística basada en el kernel
- Permitir compromiso excesivo de todos modos
- No se exceda, no exceda la proporción de compromiso excesivo.
Enlace:
vm.overcommit_ratio — porcentaje de RAM disponible para sobrecarga. Un valor del 50% en un sistema con 2 GB de RAM permite 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 del proceso del servidor sin ningún riesgo significativo de ser eliminado por el proceso asesino de OOM. La aplicación podrá recargarse, pero sólo dentro de los límites de desbordamiento, lo que reduce el riesgo de que un asesino de OOM acabe con el proceso. Por lo tanto, un valor de 2 proporciona un mejor rendimiento que el valor predeterminado de 0. Sin embargo, la confiabilidad se puede mejorar asegurando que la memoria fuera de rango no esté sobrecargada. Esto elimina el riesgo de que un asesino OOM elimine el proceso.
En sistemas sin intercambio, puede ocurrir un problema con vm.overcommit_memory igual a 2.
vm.dirty_antecedentes_ratio / vm.dirty_antecedentes_bytes
vm.dirty_background_ratio es el porcentaje de memoria llena de páginas sucias que deben escribirse en el disco. La descarga al disco se produce en segundo plano. El valor de este parámetro oscila entre 0 y 100; sin embargo, un valor inferior a 5 puede resultar ineficaz 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 escritura intensiva en un factor menor, lo que significará que Linux eliminará las páginas sucias en segundo plano.
Necesitas establecer el valor vm.dirty_background_bytes dependiendo de la velocidad de su unidad.
No existen valores "buenos" para estos dos parámetros ya que ambos dependen del hardware. Sin embargo, configurar vm.dirty_background_ratio en 5 y vm.dirty_background_bytes en 25 % de la velocidad del disco mejora el rendimiento a ~25 % en la mayoría de los casos.
vm.dirty_ratio/dirty_bytes
Esto es lo mismo que vm.dirty_antecedentes_ratio/dirty_antecedentes_bytes, excepto que el reinicio se realiza en una sesión de trabajador, bloqueando la aplicación. Por lo tanto, vm.dirty_ratio debería ser mayor que vm.dirty_background_ratio. Esto asegura que los procesos en segundo plano comiencen antes para evitar bloquear la aplicación tanto como sea posible. Puede ajustar la diferencia entre estas dos proporciones dependiendo de la carga de E/S del disco.
Total
Puedes modificar otras configuraciones para mejorar el rendimiento, pero las mejoras serán mínimas y no verás muchos beneficios. Debemos recordar que no todas las opciones sirven para todo tipo de aplicaciones. Algunas aplicaciones funcionan mejor cuando ajustamos algunas configuraciones y otras no. Debe encontrar el equilibrio adecuado entre la configuración de estos ajustes para la carga de trabajo esperada y el tipo de aplicación, y también debe considerar el comportamiento del sistema operativo al realizar el ajuste. Configurar los parámetros del kernel no es tan fácil como configurar los parámetros de la base de datos; es más difícil hacer recomendaciones.
Fuente: habr.com