O rendemento óptimo de PostgreSQL depende de que os parámetros do sistema operativo estean configurados correctamente. Uns parámetros do kernel mal configurados poden provocar unha degradación do rendemento do servidor de bases de datos. Polo tanto, é esencial configurar estes parámetros axeitadamente para o servidor de bases de datos e a súa carga de traballo. Nesta publicación, analizaremos algúns parámetros importantes do kernel. Linux, que poden afectar o rendemento do servidor de bases de datos e a forma de configuralos.
SHMMAX / SHMALL
SHMMAX — é un parámetro do núcleo que se emprega para determinar o tamaño máximo dun único segmento de memoria compartida que un proceso pode asignar. LinuxAntes da versión 9.2, PostgreSQL usaba System V (SysV), que require a configuración SHMMAX. Despois da versión 9.2, PostgreSQL cambiou á memoria compartida POSIX. Isto significa que agora se requiren 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).
CONSELLO: Este erro adoita significar que a solicitude de PostgreSQL para un segmento de memoria compartida superou o parámetro SHMMAX do kernel.
Podes reducir o tamaño da solicitude ou reconfigurar o kernel cun SHMMAX máis grande. Para reducir o tamaño da solicitude (actualmente 2072576 bytes),
reducir o uso de memoria compartida de PostgreSQL, quizais reducindo shared_buffers ou max_connections.
Se o tamaño da solicitude xa é pequeno, é posible que sexa menor que o parámetro SHMMIN do teu kernel.
nese caso, requírese aumentar o tamaño da solicitude ou reconfigurar SHMMIN.
A documentación de PostgreSQL contén máis información sobre a configuración da memoria compartida. O proceso fillo rematou co código de saída 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).
CONSELLO: Este erro adoita significar que a solicitude de PostgreSQL para un segmento de memoria compartida superou o parámetro SHMMAX do kernel.
Podes reducir o tamaño da solicitude ou reconfigurar o kernel cun SHMMAX máis grande. Para reducir o tamaño da solicitude (actualmente 14385152 bytes), reduza o uso de memoria compartida de PostgreSQL, quizais reducindo shared_buffers ou max_connections.
Se o tamaño da solicitude xa é pequeno, é posible que sexa menor que o parámetro SHMMIN do teu kernel.
nese caso, requírese aumentar o tamaño da solicitude ou reconfigurar SHMMIN.
A documentación de PostgreSQL contén máis información sobre a configuración da memoria compartida.
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 -> 16777216Cambiar 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 Por defecto, en BSD úsanse páxinas de memoria de 4 KB - Super páxinas, e dentro 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 usa 4 KB de páxinas de memoria, polo que nos casos nos que hai moitas operacións de memoria, é necesario configurar páxinas máis grandes. Obsérvanse melloras de rendemento ao usar páxinas grandes de 2 MB e ata 1 GB. O tamaño da páxina grande pódese configurar no momento do arranque. Podes comprobar facilmente a configuración da páxina grande e o seu uso no teu Linux-ordenador usando o comando cat /proc/meminfo | grep -i enorme.
Obter información sobre páxinas grandes (só en 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 script sinxelo devolve o número necesario de páxinas grandes. Executa o script no teu servidor. Linuxmentres PostgreSQL está en execución. Asegúrate de que 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).
Máis información sobre páxinas grandes (só en 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.
E de novo información sobre páxinas grandes (só en 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.
Unha vez máis información sobre páxinas grandes (só en 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. Este parámetro úsase para controlar o comportamento de intercambio (intercambio de páxinas dentro e fóra da memoria) en LinuxO valor varía de 0 a 100. Determina canta memoria se intercambiará ou se intercambiará. Cero significa que non se realizará ningún intercambio e 100 significa un intercambio agresivo.
Podes obter un bo rendemento establecendo valores máis baixos.
Definir o valor en 0 nos núcleos máis novos pode causar o OOM Killer (proceso de limpeza de memoria en Linux) rematará o proceso. Polo tanto, é seguro definir o valor en 1 se queres minimizar o intercambio. O valor predeterminado é 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 — Esta é a porcentaxe de memoria chea de páxinas sucias que cómpre baleirar no disco. Esta descarga ocorre en segundo plano. O valor deste parámetro varía de 0 a 100; non obstante, un valor inferior a 5 pode ser ineficaz e algúns núcleos non o admiten. 10 é o valor predeterminado na maioría dos sistemas. LinuxPodes mellorar o rendemento das operacións de escritura intensiva cunha proporción menor, o que significará que Linux eliminará as páxinas sucias do fondo.
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
