Como configurar shmall, shmmax, shmmin, etc… em geral e para o postgresql

11

Eu usei a documentação do PostgreSQL para defini-la, por exemplo, esta configuração:

>>> cat /proc/meminfo 
MemTotal:       16345480 kB
MemFree:         1770128 kB
Buffers:          382184 kB
Cached:         10432632 kB
SwapCached:            0 kB
Active:          9228324 kB
Inactive:        4621264 kB
Active(anon):    7019996 kB
Inactive(anon):   548528 kB
Active(file):    2208328 kB
Inactive(file):  4072736 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              3432 kB
Writeback:             0 kB
AnonPages:       3034588 kB
Mapped:          4243720 kB
Shmem:           4533752 kB
Slab:             481728 kB
SReclaimable:     440712 kB
SUnreclaim:        41016 kB
KernelStack:        1776 kB
PageTables:        39208 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8172740 kB
Committed_AS:   14935216 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      399340 kB
VmallocChunk:   34359334908 kB
HardwareCorrupted:     0 kB
AnonHugePages:    456704 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       12288 kB
DirectMap2M:    16680960 kB

>>> ipcs -l          

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4316816
max total shared memory (kbytes) = 4316816
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages Limits --------
max queues system wide = 31918
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

extrato do sysctl.conf , calculado por mim:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

Não padrões do postgresql.conf , calculados por mim:

max_connections = 60            # (change requires restart)
shared_buffers = 4GB            # min 128kB
work_mem = 4MB              # min 64kB
wal_sync_method = open_sync     # the default is the first option
checkpoint_segments = 16        # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.9  # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 6GB

Isso é apropriado? Se não (ou não necessariamente), em que caso seria apropriado?

Observamos boas melhorias de desempenho com esta configuração, como você a aprimoraria?

Como calcular os parâmetros de gerenciamento de memória do kernel?

Alguém pode explicar como realmente configurá-los do zero?

jpic
fonte
São muitas perguntas e você não nos disse qual é o seu problema atual (se houver) ou qual é o seu padrão de uso. Pode valer a pena adquirir um livro sobre o desempenho do PostgreSQL.
hmallett
Meu problema é que não estou convencido de ter feito as configurações corretas. Eu acho que as opções de gerenciamento de memória do kernel não são específicas do PostgreSQL e também não tenho certeza de que o PostgreSQL seja o melhor colocado para falar sobre essas opções. Claro, eles são mencionados em qualquer artigo sobre o desempenho do PostgreSQL, mas são as opções do Linux e estou ansioso para realmente entender como ajustá-las em geral.
JPIC

Respostas:

11

Eu respondi isso para outra pergunta aqui:

Git falha ao enviar com erro 'falta de memória'

Não estou respondendo todas as suas perguntas aqui, mas a pergunta em seu título:

Como definir shmall, shmmax, shmmni, etc ... em geral e para o postgresql

Com algumas distribuições de kernel, há configurações que impedem o kernel de alocar memória máxima para um único processo:

Definir parâmetros do kernel

Modifique o /etc/sysctl.confarquivo para incluir as linhas apropriadas ao seu sistema operacional:

# Red Hat Enterprise Linux 3.0 and CentOS 3.x 
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmin = 1
kernel.shmseg = 10

# semaphores: 
semmsl, semmns, semopm, semmni kernel.sem = 250 32000 100 128
fs.file-max = 65536

# Red Hat Enterprise Linux 4.0 and CentOS 4.x 
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.shmall = 2097152

Se o seu processo exceder os limites, o kernel eliminará o processo, apesar da memória máxima relatada estar disponível no seu sistema.

Nota: tenha cuidado com essas configurações. Você provavelmente não deseja usar as configurações desse exemplo, porque eu as extraí de um servidor em nosso ambiente.

Algumas notas extras para mencionar:

Para atualizar e testar as configurações do kernel com sysctl, use os seguintes comandos:

Listar as configurações atuais:

sysctl -A | grep shm
sysctl -w kernel.shmmax=<value> to write in sysctl.conf
sysctl -p /etc/sysctl.conf to read/reload the values from sysctl.conf

Desative o linux seguro editando o /etc/selinux/configarquivo, certificando-se de que o sinalizador SELINUX esteja definido da seguinte maneira.

SELINUX=disabled

Isso é apropriado? Se não (ou não necessariamente), em que caso seria apropriado?

As configurações do kernel geralmente são definidas com mais rigor nos ambientes do datacenter quando os provedores de ISP não desejam um único processo do cliente que consome todos os recursos em um servidor compartilhado.

Normalmente, você não precisa definir os parâmetros de memória do kernel, a menos que tenha um processo que está sendo morto pelo kernel devido à falta de recursos.

Em alguns casos, o postgres também pode alocar mais mem para tamanhos de página específicos do que o disponível na memória compartilhada:

* The PostgreSQL server failed to start. Please check the log output:
2011-11-04 05:06:26 UTC FATAL: could not create shared memory segment: Invalid
argument
2011-11-04 05:06:26 UTC DETAIL: Failed system call was shmget(key=5432001, size
=161849344, 03600).
2011-11-04 05:06:26 UTC HINT: This error usually means that PostgreSQL’s reques
t 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 161849344 bytes), reduce PostgreSQL’s shared
_buffers parameter (currently 19200) and/or its max_connections parameter (curre
ntly 53).
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 recon
figuring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memo
ry configuration.
…fail!

Erros como o exemplo acima, podem ser resolvidos ajustando as configurações de recursos do kernel. As configurações e métodos recomendados, para determinar as configurações de recursos, são descritos em detalhes aqui:

http://www.postgresql.org/docs/9.1/static/kernel-resources.html

No entanto, você realmente não precisa tocar nessas configurações, a menos que esteja enfrentando situações de falta de recursos relacionadas ao processo do postgres. Essas situações ocorrem, mais frequentemente, em ambientes compartilhados ou servidores com poucos recursos alocados a eles.

Alguém pode explicar como realmente configurá-los do zero?

Quanto ao ajuste do Postgres, você deve ler o seguinte:

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Jason Huntley
fonte
1
"Nota: tenha cuidado com essas configurações. Você provavelmente não deseja usar as configurações nesse exemplo, pois as extraí de um servidor em nosso ambiente." Como devo calculá-los para meus ambientes?
JPIC
1
Ei jpic, atualizei para fornecer mais detalhes sobre as configurações do kernel.
Jason Huntley #
2

Oh !! Eu encontro uma ferramenta maravilhosa para calcular a configuração do optimus mem do nosso servidor postgresql aqui.

http://pgtune.leopard.in.ua/

Pablo Luna
fonte
Esta ferramenta não serve para calcular a configuração optimus, pois fornece um ponto de partida para ajustar seu servidor, pois fornece uma resposta com base principalmente nas configurações de hardware. O tamanho do banco de dados, o número de consultas e os tamanhos também são importantes para ajustar os parâmetros de configuração.
EAmez 30/10/19
1

Essas configurações do kernel são globais, não específicas do processo; portanto, é apropriado defini-las sysctl.conf.

mgorven
fonte
A pergunta é sobre a determinação de valores para os parâmetros de gerenciamento de memória compartilhada do kernel, o "como", não o "onde" ... Obrigado pelo esforço colocado em sua resposta.
JPIC
Sim. lá onde é trivial. como está a carne disso.
Henley Chiu
0

Bem, depende do que mais estiver sendo executado no servidor, se este for um servidor PostgreSQL puro, o PostgreSQL é o local certo para procurar essas configurações.
Se você estiver executando outros aplicativos / serviços com necessidades específicas de memória, precisará encontrar uma configuração ideal entre esses aplicativos diferentes.

Se você estiver vendo um desempenho aprimorado no banco de dados e nenhuma perda de desempenho em outros aplicativos, não me preocuparia com isso.

Geralmente, os bancos de dados são os mais sensíveis às configurações de memória, pois também são provavelmente o gargalo no desempenho do aplicativo; faz sentido otimizar seu sistema para o banco de dados.

Sibster
fonte
Como "encontrar uma configuração ideal entre essas diferentes aplicações"? Não tenho um problema de desempenho, estou procurando a maneira canônica de definir as configurações do kernel de memória compartilhada, como um profissional real faria isso? Digamos que alguém lide com um servidor em execução com vários serviços e pague para definir apenas as configurações de gerenciamento de memória, o que você faria?
JPIC
Não há regra de ouro, basta olhar o que o fornecedor diz e testá-lo. Se você tiver vários aplicativos em execução na mesma máquina, tente otimizar para os aplicativos com maior consumo de memória, na maioria dos casos o banco de dados. Mas além de olhar para sugestões de fornecedores en testá-las não há uma solução única para a direita
Sibster
Eu sei que não há regra de ouro. Eu esperava que talvez a recompensa motivasse alguém que realmente entendesse isso a escrever algumas instruções. Mas acho que ninguém realmente entende isso afinal - já que ninguém é capaz de dar uma explicação simples.
JPIC