16.5. Gerência dos recursos do núcleo

16.5.1. Memória compartilhada e semáforos

A memória compartilhada e os semáforos são referenciados coletivamente como "System V IPC" [1] (junto com as filas de mensagens, que não são relevantes para o PostgreSQL). Quase todo sistema operacional moderno fornece estas funcionalidades, mas nem todos as têm ativas ou com tamanho suficiente por padrão, especialmente os sistemas herdados do BSD (Para os ports para o QNX e para o BeOS, o PostgreSQL fornece sua própria implementação de substituição destas funcionalidades).

A completa falta destas funcionalidades é geralmente manifestada por um erro de "Chamada de sistema ilegal" na inicialização do servidor. Neste caso, não existe nada a ser feito além de reconfigurar o núcleo. O PostgreSQL não funciona sem estas funcionalidades.

Quando o PostgreSQL excede um dos vários limites rígidos de IPC, o servidor se recusa a inicializar, e deve deixar uma mensagem de erro instrutiva descrevendo o problema encontrado e o que fazer sobre o mesmo (Também deve ser vista a Seção 16.3.1 .) Os parâmetros relevantes do núcleo possuem nomes consistentes entre sistemas diferentes; A Tabela 16-2 mostra uma visão geral. Entretanto, os métodos para defini-los variam. Abaixo são fornecidas sugestões para algumas plataformas. Não se deve esquecer que geralmente é necessário reinicializar o computador e até, possivelmente, recompilar o núcleo para alterar estas definições.

O parâmetro de memória compartilhada mais importante é SHMMAX, o tamanho máximo, em bytes, de um segmento de memória compartilhada. Se for recebida uma mensagem de erro da função shmget como "Argumento inválido", é provável que este limite tenha sido excedido. O tamanho do segmento de memória compartilhada requerido varia tanto com o número de buffers requisitados (opção -B) quanto com o número de conexões permitidas (opção -N), embora esta última seja mais significativa (É possível, como uma solução temporária, diminuir estas definições para eliminar o problema). Como uma aproximação grosseira, o tamanho de segmento requerido pode ser estimado conforme sugerido em Tabela 16-2 . Toda mensagem de erro que vier a ser recebida conterá o tamanho da alocação requerida que falhou.

Alguns sistemas também possuem um limite para a quantidade total de memória compartilhada do sistema (SHMALL). Deve-se ter certeza que é grande o suficiente para o PostgreSQL mais as outras aplicações que utilizam segmentos de memória compartilhada. (Cuidado: em muitos sistemas SHMALL é medido em páginas, e não em bytes).

Menos provável de causar problema é o tamanho mínimo para os segmentos de memória compartilhada (SHMMIN), que deve ser no máximo aproximadamente 256 kB para o PostgreSQL (geralmente é apenas 1). O número máximo de segmentos para todo o sistema (SHMMNI) ou por processo (SHMSEG) não devem causar problema a menos que o sistema os tenha definido como zero.

O PostgreSQL utiliza um semáforo por conexão permitida (opção -N), em conjuntos de 16. Cada um destes conjuntos também contém um 17º semáforo contendo um "número mágico", para detectar colisões com conjuntos de semáforos utilizados por outras aplicações. O número máximo de semáforos no sistema é definido por SEMMNS que, conseqüentemente, deve ser pelo menos tão alto quanto max_connections mais um adicional para cada 16 conexões permitidas (veja a fórmula na Tabela 16-2 ). O parâmetro SEMMNI determina o limite do número de conjuntos de semáforos que podem existir no sistema de uma vez. Portanto, este parâmetro deve ser pelo menos igual a ceil(max_connections / 16). Diminuir o número de conexões permitidas é um recurso temporário para evitar falhas, geralmente informadas pela mensagem "Nenhum espaço disponível na unidade" emitida pela função semget, que confunde.

Em alguns casos também pode haver necessidade de aumentar SEMMAP para que fique pelo menos na ordem de grandeza de SEMMNS. Este parâmetro define o tamanho do mapa de recursos de semáforos, no qual cada bloco contíguo de semáforos disponíveis precisa de uma entrada. Quando um conjunto de semáforos é liberado, este conjunto é adicionado a uma entrada existente adjacente ao bloco liberado, ou é registrado sob uma nova entrada no mapa. Se o mapa estiver cheio, os semáforos liberados serão perdidos (até a reinicialização do servidor). A fragmentação do espaço de semáforos pode, ao longo do tempo, fazer com que haja menos semáforos disponíveis do que deveria haver.

O parâmetro SEMMSL, que determina quantos semáforos podem existir em um conjunto, deve ser pelo menos igual a 17 para o PostgreSQL.

Várias outras definições relacionadas com "desfazer semáforo", como SEMMNU e SEMUME, não são de interesse do PostgreSQL.

16.5.2. Limites de recursos

Os sistemas operacionais da família Unix obrigam respeitar vários tipos de limite de recursos que podem interferir com a operação do servidor PostgreSQL. São de particular importância os limites do número de processos por usuário, de número de arquivos abertos por processo, e a quantidade de memória disponível para cada processo. Cada um destes possui um limite "rígido" e um "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 somente pode ser alterado pelo usuário root. A chamada de sistema setrlimit é responsável pela definição destes parâmetros. São utilizados o comando interno do interpretador de comandos ulimit (interpretadores de comandos Bourne) ou limit (csh) para controlar os limites de recursos a partir da linha de comandos. Nos sistemas derivados do BSD o arquivo /etc/login.conf controla os limites dos vários recursos definidos durante a autenticação. Para obter detalhes deve ser vista a documentação do sistema operacional. 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 alguns recursos para todo o sistema.

• No Linux /proc/sys/fs/file-max determina o número máximo de arquivos abertos que o núcleo pode suportar. Pode ser mudado escrevendo um número diferente no arquivo, ou adicionando uma atribuição em /etc/sysctl.conf. O limite máximo de arquivos por processo é fixado quando o núcleo é compilado; para obter mais informações deve ser visto o arquivo /usr/src/linux/Documentation/proc.txt.

O servidor PostgreSQL utiliza um processo por conexão e, portanto, deve ser especificado pelo menos tantos processos quantas forem as conexões permitidas, em adição ao que for necessário para o restante do sistema. Normalmente não é um problema, mas se forem executados vários servidores na mesma máquina pode ficar apertado.

O limite padrão original para o número de arquivos abertos geralmente é definido como um valor "socialmente amigável", para permitir a coexistência de muitos usuários em uma mesma máquina sem utilizar uma fração não apropriada dos recursos do sistema. Se forem executados vários servidores na mesma máquina provavelmente é o que se deseja, mas para servidores dedicados pode ser necessário aumentar este limite.

Por outro lado, alguns sistemas podem permitir que cada processo abra um grande número de arquivos; se mais que uns poucos processos o fizerem, então o limite global para todo o sistema pode ser facilmente excedido. Se isto estiver acontecendo, e não for desejado alterar o limite para todo o sistema, pode ser definido o parâmetro de configuração max_files_per_process do PostgreSQL para limitar a quantidade de arquivos abertos.

16.5.3. Sobre-alocação de memória no Linux

No Linux 2.4 e posteriores, o comportamento padrão de memória virtual não é o ótimo para o PostgreSQL. Devido à maneira como o núcleo implementa a sobre-alocação (overcommit) de memória, o núcleo pode fechar o servidor PostgreSQL (o processo postmaster), se a demanda por memória de um outro processo fizer com que o sistema fique sem memória virtual. [2]

Caso aconteça, será recebida uma mensagem do núcleo parecida com esta (deve ser consultada a documentação e configuração do sistema para achar onde este tipo de mensagem pode ser vista):

Out of Memory: Killed process 12345 (postmaster).

Esta mensagem indica que o processo postmaster foi fechado devido à falta de memória. Embora as conexões com os bancos de dados existentes continuem funcionando normalmente, não é aceita nenhuma nova conexão. Para voltar ao normal é necessário reinicializar o PostgreSQL.

Uma forma de evitar este problema é executar o PostgreSQL em uma máquina onde se tenha certeza que outros processos não vão deixar a máquina sem memória.

No Linux 2.6 e posteriores, uma solução melhor é modificar o comportamento do núcleo para que não haja "sobre-alocação" de memória. Isto é feito selecionando um modo estrito de sobre-alocação através do comando sysctl:

sysctl -w vm.overcommit_memory=2

ou colocando uma entrada equivalente em /etc/sysctl.conf. Também pode-se querer modificar a definição relacionada vm.overcommit_ratio. Para obter detalhes deve ser visto o arquivo de documentação do núcleo Documentation/vm/overcommit-accounting.

É relatado que algumas distribuições do núcleo 2.4 do Linux possuem uma versão inicial do parâmetro overcommit do comando sysctl da versão 2.6. Entretanto, definir vm.overcommit_memory como 2 em um núcleo que não possui o código relevante torna as coisas piores, e não melhores. Recomenda-se a inspeção do código fonte do núcleo utilizado (deve ser vista a função vm_enough_memory no arquivo mm/mmap.c), para verificar o que é suportado na versão utilizada antes de tentar utilizar numa instalação 2.4. A presença do arquivo de documentação overcommit-accounting não deve ser assumida como um evidência que a funcionalidade está presente. Em caso de dúvida deve ser consultado um especialista no núcleo ou o distribuidor do núcleo utilizado.