O rendemento óptimo de PostgreSQL depende dos parámetros do sistema operativo definidos correctamente. A configuración do núcleo do sistema operativo mal configurada pode producir un rendemento deficiente do servidor de base de datos. Polo tanto, é imprescindible que estes axustes se configuren segundo o servidor de base de datos e a súa carga de traballo. Nesta publicación, discutiremos algúns parámetros importantes do núcleo de Linux que poden afectar o rendemento do servidor de bases de datos e como configuralos.
SHMMAX / SHMALL
SHMMAX é un parámetro do núcleo usado para determinar o tamaño máximo dun único segmento de memoria compartida que un proceso Linux pode asignar. Antes da versión 9.2, PostgreSQL utilizaba System V (SysV), que require a configuración SHMMAX. Despois da 9.2, PostgreSQL pasou á memoria compartida POSIX. Polo tanto, agora son necesarios menos bytes de memoria compartida de System V.
Antes da versión 9.3, SHMMAX era o parámetro máis importante do núcleo. O valor SHMMAX especifícase en bytes.
Do mesmo xeito, SHMALL é outro parámetro do núcleo usado para determinar
volume de páxinas de memoria compartida en todo o sistema. Para ver os valores actuais de SHMMAX, SHMALL ou SHMMIN, use o comando ipcs.
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)
Usa PostgreSQL Sistema V IPC para asignar memoria compartida. Este parámetro é un dos parámetros máis importantes do núcleo. Sempre que recibas as seguintes mensaxes de erro, significa que tes unha versión antiga de PostgreSQL e que o teu valor SHMMAX é moi baixo. Espérase que os usuarios axusten e aumenten o valor segundo a memoria compartida que pretenden utilizar.
Posibles erros de configuración incorrecta
Se SHMMAX non está configurado correctamente, pode recibir un erro ao tentar inicializar un clúster PostgreSQL usando o comando initdb.
initdb Fallo
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
Do mesmo xeito, pode recibir un erro ao iniciar o servidor PostgreSQL mediante o 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 as diferenzas nas definicións
A definición dos parámetros SHMMAX/SHMALL é lixeiramente diferente en Linux e MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Equipo sysctl pódese usar para cambiar temporalmente o valor. Para establecer valores constantes, engade unha entrada a /etc/sysctl.conf. Os detalles están a continuación.
Cambiando a configuración do núcleo 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 -> 16777216Cambiando os parámetros do núcleo 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 -> 16777216Non esquezas: Para facer os cambios permanentes, engade estes valores a /etc/sysctl.conf
Páxinas enormes
Linux usa páxinas de memoria de 4 KB por defecto, BSD usa páxinas de memoria de XNUMX KB. Super páxinas, e en Windows - Páxinas grandes. Unha páxina é unha peza de memoria RAM asignada a un proceso. Un proceso pode ter varias páxinas dependendo dos requisitos de memoria. Canto máis memoria necesite un proceso, máis páxinas ten asignadas. O SO mantén unha táboa de asignación de páxinas para os procesos. Canto menor sexa o tamaño da páxina, canto maior sexa a táboa, máis tempo tardará en atopar unha páxina nesa táboa de páxinas. Polo tanto, as páxinas grandes permiten utilizar grandes cantidades de memoria cunha sobrecarga reducida; menos páxinas vistas, menos fallos de páxina, operacións de lectura/escritura máis rápidas en búfers máis grandes. O resultado é un rendemento mellorado.
PostgreSQL só admite páxinas grandes en Linux. Por defecto, Linux utiliza páxinas de memoria de 4 KB, polo que nos casos en que hai demasiadas operacións de memoria, é necesario configurar páxinas máis grandes. Obsérvanse aumentos de rendemento cando se usan páxinas grandes de 2 MB e ata 1 GB. O tamaño grande da páxina pódese configurar no momento do inicio. Podes comprobar facilmente os parámetros da páxina grande e o seu uso na túa máquina Linux usando o comando cat /proc/meminfo | grep -i enorme.
Obtención de información sobre páxinas grandes (só 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 kBNeste exemplo, aínda que o tamaño da páxina grande está definido en 2048 (2 MB), o número total de páxinas grandes está definido en 0. Isto significa que as páxinas grandes están desactivadas.
Script para determinar o número de páxinas grandes
Este sinxelo script devolve o número necesario de páxinas grandes. Executa o script no teu servidor Linux mentres PostgreSQL está en execución. Asegúrese de que para a variable de ambiente $PGDATA Especificouse o directorio de datos de PostgreSQL.
Obtendo o número de páxinas grandes necesarias
#!/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: $hpA saída do script ten o seguinte aspecto:
Saída do script
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88O valor recomendado para páxinas grandes é 88, polo que debes configuralo en 88.
Instalación de páxinas grandes
sysctl -w vm.nr_hugepages=88Comproba as páxinas grandes agora, verás que non se usan páxinas grandes (HugePages_Free = HugePages_Total).
Páxinas grandes revisitadas (só 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 kBAgora configure o parámetro huge_pages en "on" en $PGDATA/postgresql.conf e reinicie o servidor.
Unha vez máis, información sobre páxinas grandes (só 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 kBAgora podes ver que se están a usar moi poucas páxinas grandes. Imos agora tentar engadir algúns datos á base de datos.
Algunhas operacións de base de datos para reciclar páxinas grandes
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000A ver se agora estamos a usar páxinas máis grandes que antes.
Máis información en páxinas grandes (só 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 kBAgora podes ver que se están a usar a maioría das páxinas grandes.
Nota: O valor estimado de HugePages que se usa aquí é moi baixo, o que non é un valor normal para unha máquina que executa un ambiente de produto. Estima o número necesario de páxinas para o teu sistema e configúraas en función da carga e dos recursos.
vm.permuta
vm.permuta é outro parámetro do núcleo que pode afectar o rendemento da base de datos. Esta opción úsase para controlar o comportamento do intercambio (intercambiar páxinas dentro e fóra da memoria) en Linux. O valor varía de 0 a 100. Determina a cantidade de memoria que se paginará ou eliminará. Cero significa ningún intercambio e 100 significa intercambio agresivo.
Podes obter un bo rendemento establecendo valores máis baixos.
Establecer isto en 0 nos núcleos máis novos pode provocar que OOM Killer (o proceso de limpeza da memoria de Linux) elimine o proceso. Polo tanto, é seguro configuralo en 1 se queres minimizar o intercambio. O valor predeterminado en Linux é 60. Un valor máis alto fai que a MMU (unidade de xestión de memoria) use máis espazo de intercambio que a RAM, mentres que un valor máis baixo mantén máis datos/código na memoria.
Un valor máis baixo é unha boa aposta para mellorar o rendemento en PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
As aplicacións adquiren memoria e liberana cando xa non é necesaria. Pero nalgúns casos, a aplicación obtén demasiada memoria e non a libera. Isto pode provocar un asasino OOM. Aquí están os posibles valores dos parámetros vm.overcommit_memory cunha descrición para cada un:
- Sobrecommit heurístico (predeterminado); heurística baseada no núcleo
- Permitir o overcommit de todos os xeitos
- Non esaxere, non exceda a proporción de sobrecommit.
Referencia:
vm.overcommit_ratio — porcentaxe de RAM dispoñible para sobrecarga. Un valor do 50% nun sistema con 2 GB de RAM pode asignar ata 3 GB de RAM.
Un valor de 2 para vm.overcommit_memory proporciona un mellor rendemento para PostgreSQL. Este valor maximiza o uso da memoria RAM do proceso do servidor sen ningún risco significativo de ser eliminado polo proceso asasino OOM. A aplicación poderá recargarse, pero só dentro dos límites de superación, o que reduce o risco de que un asasino de OOM mate o proceso. Polo tanto, un valor de 2 dá un mellor rendemento que o valor predeterminado de 0. Non obstante, a fiabilidade pódese mellorar garantindo que a memoria fóra de rango non se sobrecargue. Isto elimina o risco de que o proceso sexa asasinado por un asasino OOM.
Nos sistemas sen intercambio, pode ocorrer un problema con vm.overcommit_memory igual a 2.
relación_de_fondo_vm.dirty_bytes / vm.dirty_background_bytes
vm.proporción_de_fondo_sucio é a porcentaxe de memoria chea de páxinas sucias que se deben escribir no disco. A descarga no disco prodúcese en segundo plano. O valor deste parámetro varía de 0 a 100; porén, un valor inferior a 5 pode ser ineficaz e algúns núcleos non o admiten. 10 é o predeterminado na maioría dos sistemas Linux. Pode mellorar o rendemento para operacións de escritura intensiva nun factor menor, o que significará que Linux eliminará as páxinas sucias en segundo plano.
Debe establecer o valor vm.bytes_de_fondo_sucio dependendo da velocidade da súa unidade.
Non hai valores "bos" para estes dous parámetros xa que ambos dependen do hardware. Non obstante, establecer vm.dirty_background_ratio en 5 e vm.dirty_background_bytes no 25 % da velocidade do disco mellora o rendemento a ~25 % na maioría dos casos.
vm.dirty_ratio/dirty_bytes
É o mesmo que vm.proporción_de_fondo_sucio/bytes_de_fondo_sucio, agás que o reinicio realízase nunha sesión de traballador, bloqueando a aplicación. Polo tanto, vm.dirty_ratio debería ser maior que vm.proporción_de_fondo_sucio. Isto garante que os procesos en segundo plano comezan antes para evitar o bloqueo da aplicación na medida do posible. Podes axustar a diferenza entre estas dúas relacións dependendo da carga de E/S do disco.
Total
Podes modificar outras opcións para mellorar o rendemento, pero as melloras serán mínimas e non verás moito beneficio. Debemos lembrar que non todas as opcións se aplican a todo tipo de aplicacións. Algunhas aplicacións funcionan mellor cando axustamos algunhas opcións de configuración e outras non. Debes atopar o equilibrio correcto entre a configuración destas opcións para a túa carga de traballo esperada e o tipo de aplicación, e tamén debes ter en conta o comportamento do SO ao axustar. Configurar os parámetros do núcleo non é tan sinxelo coma configurar os parámetros da base de datos; é máis difícil facer recomendacións.
Fonte: www.habr.com