O PostgreSQL requer que o sistema operacional forneça recursos de comunicação entre processos (IPC), especificamente memória compartilhada e semáforos. Os sistemas operacionais derivados do Unix fornecem normalmente o IPC do System V, do POSIX, ou ambos. O Windows possui sua própria implementação dessa funcionalidade, que não é discutida aqui.

Por padrão, o PostgreSQL aloca uma quantidade muito pequena de memória compartilhada do System V, bem como uma quantidade muito maior de memória compartilhada anônima mmap. Como alternativa, pode ser usada uma única região grande de memória compartilhada do System V (veja shared_memory_type). Além disso, um número significativo de semáforos, que podem ser do estilo System V ou POSIX, são criados na ativação do servidor. No momento são usados semáforos POSIX em sistemas Linux e FreeBSD, enquanto as outras plataformas usam semáforos System V.

Os recursos de IPC do System V são normalmente restritos por limites de alocação de todo o sistema. Quando o PostgreSQL excede um desses limites, o servidor se recusa a iniciar, devendo deixar uma mensagem de erro instrutiva descrevendo o problema, e o que se de deve fazer a respeito. (Veja também Falhas na ativação do servidor.) Os parâmetros relevantes do núcleo têm nomes consistentes em diferentes sistemas; Parâmetros de IPC do System V dá uma visão geral. Os métodos para defini-los, no entanto, variam, sendo dadas abaixo sugestões para algumas plataformas.

O PostgreSQL requer uns poucos bytes de memória compartilhada do System V (normalmente 48 bytes, nas plataformas de 64 bits) para cada instância do servidor. Na maioria dos sistemas operacionais modernos, este valor pode ser facilmente alocado. Entretanto, se estiverem sendo executadas muitas instâncias do servidor, ou o servidor tiver sido configurado explicitamente para usar uma grande quantidade de memória compartilhada do System V (veja shared_memory_type e dynamic_shared_memory_type), pode ser necessário aumentar SHMALL, que é a quantidade total de memória compartilhada do System V para todo o sistema. Deve-se observar que SHMALL é medido em páginas, ao invés de bytes, em muitos sistemas.

Menos provável de causar problemas é o tamanho mínimo para segmentos de memória compartilhada (SHMMIN), que deve ser no máximo aproximadamente 32 bytes para o PostgreSQL (é geralmente apenas 1). É improvável que o número máximo de segmentos para todo o sistema (SHMMNI), ou por processo (SHMSEG), cause um problema, a menos que estejam definidos como zero.

Ao usar semáforos System V, o PostgreSQL usa um semáforo por conexão permitida. (max_connections), processo de trabalho de auto-limpeza autorizado (autovacuum_worker_slots), processo de envio de WAL permitido (max_wal_senders), processo em segundo plano permitido (max_worker_processes), etc., em conjuntos de 16. O parâmetro calculado em tempo de execução num_os_semaphores relata o número de semáforos necessários. Este parâmetro pode ser visto antes de iniciar o servidor com um comando postgres, como:

$ postgres -D $PGDATA -C num_os_semaphores

Cada conjunto de 16 semáforos também irá conter um 17º semáforo contendo um “número mágico”, para detectar colisões com conjuntos de semáforos usados ​​por outras aplicações. O número máximo de semáforos no sistema é definido por SEMMNS, que, consequentemente, deve ser pelo menos igual a num_os_semaphores mais um extra para cada conjunto de 16 semáforos necessários. (veja a fórmula em Parâmetros de IPC do System V). O parâmetro SEMMNI determina o limite do número de conjuntos de semáforos que podem existir no sistema simultaneamente. Portanto, este parâmetro deve ser pelo menos ceil(num_os_semaphores / 16). Reduzir o número de conexões permitidas é uma solução temporária para falhas, que geralmente são mostradas de maneira confusa como “Não há espaço disponível no dispositivo” pela função semget.

Em alguns casos, também pode ser necessário aumentar SEMMAP, para pelo menos na ordem de SEMMNS. Se o sistema possui este parâmetro (muitos não possuem), ele define o tamanho do mapa de recursos do semáforo, no qual cada bloco contíguo de semáforos disponíveis precisa de uma entrada. Quando um conjunto de semáforos é liberado, ele é adicionado a uma entrada existente adjacente ao bloco liberado, ou é registrado em uma nova entrada de mapa. Se o mapa estiver cheio, os semáforos liberados serão perdidos (até o reinício do sistema operacional). A fragmentação do espaço do semáforo pode, com o tempo, levar a menos semáforos disponíveis do que deveria existir.

Várias outras configurações relacionadas a “desfazer semáforo” (semaphore undo), tais como SEMMNU e SEMUME, não afetam o PostgreSQL.

Ao usar semáforos POSIX, o número de semáforos necessários é o mesmo do System V, ou seja, um semáforo por conexão permitida (max_connections), processo trabalhador de auto-limpeza permitido (autovacuum_worker_slots), processo de envio de WAL permitido (max_wal_senders), processo em segundo plano permitido (max_worker_processes), etc. Nas plataformas em que esta opção é preferida, não há limite específico do núcleo para o número de semáforos POSIX.

Se o systemd estiver em uso, devem ser tomados alguns cuidados para que os recursos do IPC (incluindo memória compartilhada), não sejam removidos prematuramente pelo sistema operacional. Esta situação é notadamente preocupante ao instalar o PostgreSQL a partir do código-fonte. Os usuários de pacotes distribuídos do PostgreSQL são menos propensos a serem afetados, porque o usuário postgres é normalmente criado como um usuário do sistema.

O parâmetro RemoveIPC no arquivo logind.conf controla se os objetos do IPC são removidos quando um usuário efetua uma desconexão completa. Não se aplica aos usuários do sistema. Este parâmetro está ativo (yes) por padrão na versão original do systemd, mas em algumas distribuições de sistema operacional o padrão é inativo (no).

Um efeito típico observado quando esta configuração está ativa, é que os objetos de memória compartilhada usados para execução de consultas paralelas são removidos em momentos aparentemente aleatórios, levando a erros e avisos ao tentar abri-los e removê-los, como

WARNING:  could not remove shared memory segment "/PostgreSQL.1450751626": ↵
          No such file or directory

Tipos diferentes de objetos do IPC (memória compartilhada versus semáforos, System V versus POSIX) são tratados de forma ligeiramente diferente pelo systemd, portanto, pode-se observar que alguns recursos do IPC não são removidos da mesma forma que outros. Mas não se aconselha a confiar nessas diferenças sutis.

Um “logout de usuário” pode acontecer como parte de um trabalho de manutenção, ou manualmente quando o administrador se conecta como o usuário postgres, ou algo semelhante, então é difícil evitar que isto aconteça em geral.

O que é um “usuário do sistema” é determinado no tempo de compilação do systemd, a partir da configuração SYS_UID_MAX no arquivo /etc/login.defs.

Os scripts de criação de pacotes e implantação devem ter o cuidado de criar o usuário postgres como um usuário do sistema, usando useradd -r, adduser --system, ou equivalente.

Como alternativa, se a conta de usuário foi criada incorretamente, ou não pode ser alterada, é recomendável definir

RemoveIPC=no

no arquivo /etc/systemd/logind.conf, ou em outro arquivo de configuração apropriado.

Os sistemas operacionais do tipo Unix impõem vários tipos de limites de recursos que podem interferir na operação do servidor PostgreSQL. De particular importância são os limites do número de processos por usuário, o número de arquivos abertos por processo, e a quantidade de memória disponível para cada processo. Cada um deles possui um limite “rígido” e um limite “flexível”. O limite flexível é o que realmente conta, mas pode ser alterado pelo usuário até o limite rígido. O limite rígido só pode ser alterado pelo usuário root. A chamada de sistema setrlimit é responsável por definir estes parâmetros. O comando interno do interpretador de comandos ulimit (shells Bourne), ou limit (csh), é usado para controlar os limites de recursos a partir da linha de comando. Em sistemas derivados do BSD, o arquivo /etc/login.conf controla os vários limites de recursos definidos durante o login. Consulte a documentação do sistema operacional para obter detalhes. Os parâmetros relevantes são maxproc, openfiles e datasize. Por exemplo:

default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...

(-cur é o limite flexível. Deve ser anexado -max para definir o limite rígido.)

Os núcleos também podem ter limites para todo sistema para alguns recursos.

O servidor PostgreSQL usa um processo por conexão, então a configuração deve permitir pelo menos tantos processos quantas forem as conexões autorizadas, além do necessário para o resto do sistema. Geralmente este limite não é um problema, mas se forem executados vários servidores na mesma máquina, poderá ficar apertado.

O limite padrão para arquivos abertos é geralmente definido como um valor “socialmente amigável”, permitindo que muitos usuários coexistam na mesma máquina, sem usar uma fração excessiva dos recursos do sistema. Se vários servidores estiverem sendo executados na mesma máquina, talvez este valor seja adequado, mas em servidores dedicados, este limite pode ser aumentado.

Do outro lado da moeda, alguns sistemas permitem que processos individuais abram muitos arquivos; se mais que uns poucos processos fizerem isto, o limite para todo o sistema poderá ser facilmente excedido. Se desconfiar que isto está acontecendo, e não quiser alterar o limite para todo o sistema, pode ser definido o parâmetro de configuração max_files_per_process do PostgreSQL, limitando o consumo de arquivos abertos.

Outro limite do núcleo que pode ser preocupante ao oferecer suporte para muitas conexões de clientes é o comprimento máximo da fila de conexões de soquete. Se chegar mais do que este número de solicitações de conexão em um período muito curto, algumas solicitações poderão ser rejeitadas antes que o servidor PostgreSQL possa atendê-las, com estes clientes recebendo erros de falha de conexão pouco úteis, como “Recurso temporariamente indisponível” ou “Conexão recusada”. O limite padrão para o tamanho da fila é 128 em muitas plataformas. Para aumentar, deve-se ajustar o parâmetro do núcleo apropriado através do sysctl, e depois reiniciar o servidor PostgreSQL. O parâmetro recebe vários nomes diferentes net.core.somaxconn no Linux, kern.ipc.soacceptqueue em versões mais recentes do FreeBSD, e kern.ipc.somaxconn no macOS e em outras variantes do BSD.

O comportamento padrão para memória virtual no Linux não é o ideal para o PostgreSQL. Devido à maneira como o núcleo implementa a sobrecarga (overcommit) de memória, o núcleo poderá fechar o processo postmaster do PostgreSQL (o processo supervisor do servidor), se a memória exigida pelo PostgreSQL, ou por outro processo, fizer com que o sistema fique sem memória virtual.

Se isto acontecer, será vista uma mensagem do núcleo parecida com a mostrada a seguir (consulte na documentação e configuração do sistema onde procurar por esta mensagem):

Out of Memory: Killed process 12345 (postgres).

Esta mensagem indica que o processo postgres foi encerrado devido à falta de memória. Embora as conexões de banco de dados existentes continuem a funcionar normalmente, nenhuma nova conexão será aceita. Para recuperar, o PostgreSQL precisa ser reiniciado.

Uma maneira de evitar este problema é executar o PostgreSQL em uma máquina onde se tenha certeza de que outros processos não deixarão a máquina sem memória. Se a memória for pouca, aumentar o espaço de troca (swap) do sistema operacional pode ajudar a evitar o problema, porque o terminador por falta de memória (out-of-memory killer, ou OOM killer) é chamado somente quando a memória física e o espaço de troca estão esgotados.

Se o próprio PostgreSQL for o causador da falta de memória do sistema, este problema poderá ser evitado mudando sua configuração. Em alguns casos, a diminuição dos valores dos parâmetros de configuração relacionados à memória pode ajudar, principalmente shared_buffers, work_mem e hash_mem_multiplier. Em outros casos, o problema pode ser causado por permitir muitas conexões com o servidor de banco de dados. Em muitos casos, pode ser melhor reduzir max_connections e, em vez conectar diretamente, usar um software de pool de conexões (connection-pooling) externo.

É possível modificar o comportamento do núcleo para que não “sobrecarregue” a memória. Embora a configuração a seguir não impeça completamente que o OOM killer seja chamado, diminui muito as chances, portanto, levando a um comportamento mais robusto do sistema. Isto é feito selecionando o modo de overcommit estrito via sysctl

sysctl -w vm.overcommit_memory=2

ou colocando uma entrada equivalente no arquivo /etc/sysctl.conf. Pode-se, também, querer modificar a configuração relacionada vm.overcommit_ratio. Para obter detalhes veja a documentação do núcleo em overcommit handling modes.

Outra abordagem, que pode ser usada com ou sem alterar vm.overcommit_memory, é definir o valor de Ajuste de pontuação do OOM (OOM score adjustment) específico do processo, para o processo postmaster, como -1000, garantindo assim que não será alvo do OOM killer. A maneira mais simples de fazer isto é executar

echo -1000 > /proc/self/oom_score_adj

no script de inicialização do PostgreSQL, logo antes de executar o postgres. Note que esta ação deve ser realizada como usuário root, caso contrário não terá efeito; portanto, um script de inicialização pertencente ao usuário root é o local mais fácil para fazer isto. se isto for feito, também deverão ser definidas as seguintes variáveis ​​de ambiente no script de inicialização antes de executar o postgres:

export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
export PG_OOM_ADJUST_VALUE=0

Estas configurações farão com que os processos filhos do postmaster sejam executados com o ajuste de pontuação OOM normal de zero, para que o OOM killer ainda possa atingi-los quando for necessário. Pode ser usado algum outro valor para PG_OOM_ADJUST_VALUE se desejar que os processos filho sejam executados com algum outro ajuste de pontuação OOM. (PG_OOM_ADJUST_VALUE também pode ser omitido, caso em que o padrão é zero.) Se PG_OOM_ADJUST_FILE não for definida, os processos filho serão executados com o mesmo ajuste de pontuação OOM que o postmaster, o que não faz sentido, porque o objetivo principal é garantir que o postmaster tenha uma configuração preferencial.

O uso de páginas enormes reduz a sobrecarga ao usar grandes blocos contíguos de memória, o que PostgreSQL faz, principalmente quando são usados valores grandes para shared_buffers. Para usar este recurso no PostgreSQL, é necessário um núcleo com CONFIG_HUGETLBFS=y e CONFIG_HUGETLB_PAGE=y. Também é necessário configurar o sistema operacional para fornecer páginas enormes suficientes para o tamanho desejado. O parâmetro calculado em tempo de execução shared_memory_size_in_huge_pages indica o número de páginas enormes necessárias. Este parâmetro pode ser visto antes de iniciar o servidor com um comando postgres, como:

$ postgres -D $PGDATA -C shared_memory_size_in_huge_pages
3170
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB
$ ls /sys/kernel/mm/hugepages
hugepages-1048576kB  hugepages-2048kB

Neste exemplo, o padrão é 2 MB, mas também pode ser solicitado explicitamente 2 MB ou 1 GB configurando huge_page_size para adaptar o número de páginas calculado por shared_memory_size_in_huge_pages. Embora precisemos de pelo menos 3170 páginas enormes neste exemplo, uma configuração maior seria apropriada se outros programas na máquina também precisassem de páginas enormes. Pode-se configurar isto com:

# sysctl -w vm.nr_hugepages=3170

Não se deve esquecer de adicionar esta configuração ao arquivo /etc/sysctl.conf para que ela seja reaplicada após reinicializações. Para tamanhos de página muito grandes que não sejam o padrão, pode-se usar:

# echo 3170 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Também é possível fornecer estas configurações durante a inicialização usando parâmetros do núcleo como hugepagesz=2M hugepages=3170.

Às vezes, o núcleo não consegue alocar o número desejado de páginas enormes imediatamente devido à fragmentação, portanto, pode ser necessário repetir o comando ou reiniciar o sistema operacional. (Imediatamente após o reinício, a maior parte da memória da máquina deve estar disponível para ser convertida em páginas enormes.) Para verificar a situação de alocação de páginas enorme para um determinado tamanho, deve-se usar:

$ cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

Também pode ser necessário dar permissão ao usuário do sistema operacional do servidor de banco de dados para usar páginas enormes definindo vm.hugetlb_shm_group via sysctl, e/ou dar permissão para bloquear a memória com ulimit -l.

O comportamento padrão para páginas enormes no PostgreSQL é usá-las quando possível, com o tamanho de página enorme padrão do sistema, e retornar às páginas normais em caso de falha. Para forçar o uso de páginas enormes, pode ser definido huge_pages como on no arquivo postgresql.conf. Deve-se observar que com esta configuração, o PostgreSQL falha ao iniciar quando não há páginas enormes suficientes disponíveis.

Para uma descrição detalhada do recurso de páginas enormes no Linux, veja hugetlbpage.txt.