De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Semáforos, Kernel, Memória Compartilhada e Cia

Colaboração: Jairo Willian Pereira

Data de Publicação: 21 de Setembro de 2005

Há ocasiões onde é extremamente necessário que dois ou mais processos/threads acessem um único recurso comum. Caso esse tipo de paralelismo não ocorra de forma controlada, podemos fazer com que um processo "sequestre/atropele" a operação de outro.

É ai que entram nossos sinalizadores, vulgo semáforos. Com eles, é possível acesso controlado a processos, de forma que só haverá disponibilidade quando a operação em andamento for finalizada.

Processos, memória compartilhada e filas de mensagens é a principal tríade de recursos compartilhados necessários em ambientes *NIX para a perfeita comunicação entre processos (System V IPC ou também conhecida em outros ambientes com IPC ou Inter-Process Communication).

Esse semáforos funcionam como indicadores (flags) que sinalizam para o ambiente se o mesmo está ou não em utilização (os métodos de sinalização não são pertinentes ao artigo, mas podemos didaticamente imaginar que pode ser 0 e 1, respectivamente 0 para indisponível e 1 para disponível). Assim, o processo de sinalização requer colaboração e troca de informações entre processos.

Dependendo da quantidade de aplicações que existem no ambiente, a quantidade inicial de semáforos pode não ser suficientes para um perfeito controle de todo o sistema. Na verdade, a maioria dos sistemas operacinais modernos oferecem essas funcionalidades, porém os padrões das diversas distribuições são tão baixos que não é necessário um super-servidor para saturar esses recursos (principalmente o legado BSD). Por exemplo:

Uma instalação considerável do PostGreSQL pode "extirpar" rapidamente vários limites de recursos do sistema operacional, comumente usando 1 semáforo para cada instância/requisição concorrente. Uma instalação comum de Oracle consome aproximadamente 70 semáforos.

Quando esses recursos são saturados, sua falta manifesta um erro conhecido como "Chamada de Sistema Ilegal". Nesse caso, não há nada a ser feito, a não ser remover recursos "gulosos" que na maioria das vezes não é possível ou recompilar o núcleo do kernel. Para os escovadoresde bits e curiosos de plantão, os arquivos fontes são:

  /usr/src/linux/include/asm/shmparam.h
  /usr/src/linux/include/asm/semaphore.h
  /usr/src/linux/include/asm/semaphore-helper.h
  /usr/src/linux/include/linux/shm.h
  /usr/src/linux/include/linux/sem.h

Nessa dica, além de darmos uma explanação sobre "semáforos", iremos demonstrar como corrigir esses problemas sem desinstalar aplicações e/ou recompilar seu kernel. Como pré-requisito, esperamos que você esteja com sorte e seu kernel já esteja compilado com o CONFIG_SYSCTL ativo.

Sem essa opção, não há como fazer mudanças "inline/on the fly" para parâmetros do kernel. A boa noticia é que ele já vem ligado por padrão em um kernel 2.4 normal (como pode esbarrar em questões de segurança, provavelmente algumas distribuições mais conservadoras ou ditas seguras podem ter como padrão disable).

O sistema de arquivos proc

Muitos parâmetros de kernel podem ser alterados através do sistema de arquivos /proc ou usando sysctl. Você pode consultar esses valores consultando:

  [root@gianlucca root]# more /proc/sys/kernel/sem   # Semáforos
  [root@gianlucca root]# more /proc/mdstat   # RAID status
  [root@gianlucca root]# more /proc/cpuinfo   # Processador
  [root@gianlucca root]# more /proc/version   # Versão Kernel

Ou ainda, uma variedade de informações de todo o sistema via:

  [root@gianlucca root]# procinfo
  [root@gianlucca root]# sysctl -a

Como estamos falando de semáforos e recursos do sistema, vamos dar uma olhada nesses valores:

  [root@gianlucca root]# ipcs -la
  ----- Limites da memória compartilhada ----------
  número máximo de segmentos: 4096
  tamanho máximo do segmento (Kb): 2097152
  memória compartilhada total máxima (Kb): 8388608
  tamanho mínimo do segmento (bytes): 1
  
  ------ Limites de semáforo ----------------------
  número máximo de arrays: 100
  máximo de semáforos por array: 100
  máximo geral de semáforos do sistema: 32000
  máximo de ops por chamada semop: 100
  valor máximo de semáforo: 32767
  
  ------ Mensagens: limites -----------------------
  número máximo geral de filas no sistema: 16
  tamanho máximo da mensagem (bytes): 8192
  tamanho máximo padrão da fila (bytes): 16384

Lembram da ganância por recursos do Oracle? Observem agora esses limites (100). Levando em consideração que o próprio SO já está utilizando parte deles, nossa cota está proxima de estouro. Vamos conhecer um pouco mais sobre esses indicadores.

Parâmetros IPC (System V)

SEMMNI

Número máximo de identificadores de semáforos (conjuntos).

SEMMNS

Número máximo de semáforos para todo o sistema.

SEMMSL

Número máximo de semáforos por conjunto.

SEMMAP

Número de entradas no mapa de semáforos. Deve ser definido como o produto de SEMMNI e SEMMSL (SEMMAP = SEMMNI * SEMMSL).

SEMVMX

Valor máximo de um semáforo. Pelo menos 1000, onde o padrão é geralmente 32767. Não mude a não ser quando solicitado!

Onde, quando e como alterar corretamente os valores

Esses valores podem ser modificados via arquivo de sistema proc sem necessidade de reinicialização. A operação abaixo ilustra essa mudança:

  [root@gianlucca root]# sysctl -w kernel.sem="250 32000 100 128"

Como esses valores são perdidos numa unicialização do sistema, os mesmos podem ser colocados em um script executado durante a inicialização, como erroneamente utilizado em gateways/firewall para habilitar roteamento de pacotes.

  /bin/echo "1" > /proc/sys/net/ipv4/ip_forward && echo Ok || echo Erro!

Como alternativa correta para ambos os exemplos mostrados, pode ser utilizado sysctl (se disponível), para controlar estes parâmetros. Como esse arquivo é processado durante a inicialiação, as mudanças devem ser inseridas em /etc/sysctl.conf conforme o exemplo:

  kernel.shmall = 134217728
  kernel.shmmax = 134217728
  net.ipv4.ip_forward = 1

A sintaxe para o /etc/sysctl.conf é bem simples. Remova /proc/sys/ dos caminhos mencionados anteriormente e substitua a / pelo . utilizando a mesma estrutura. Assim,

  /proc/sys/net/ipv4/ip_forward = net.ipv4.ip_forward

Overview sobre opções de memória compartilhada

Embora o foco seja semáforos, caso a memória compartilhada sofra sobre-utilização pelo kernel (overcommit), problemas podem ocorrer especificamente com o ambiente do PostGreSQL. Um erro comum desse SGBD é:

  Out of Memory: Killed process 12345 (postmaster).

A partir do kernel 2.6, opadrão é que não haja "sobre-utilização". Caso esteja desativado, pode ser implementado selecionando um modo restrito de sobre-utilização através do sysctl:

  [root@gianlucca root]# sysctl -w vm.overcommit_memory=2

Aproveitando o espaço, e como estava com as definições em mãos, segue descritivo referencia para facilitar a configuração (quando necessário) desses parâmetros:

SHMMAX

Tamanho máximo de um segmento de memória compartilhada (bytes). 250 kB + 8.2 kB * shared_buffers + 14.2 kB * max_connections até o infinito.

SHMMIN

Tamanho mínimo de um segmento de memória compartilhada (bytes). Padrão 1.

SHMALL

Quantidade total de memória compartilhada disponível (bytes ou páginas)

SHMSEG

Número máximo de segmentos de memória compartilhada por processo. Somente 1 segmento é necessário, mas o padrão é muito maior.

SHMMNI

Número máximo de segmentos de memória compartilhada para todo o sistema.

Finalizando...

Embora seja um canto obscuro do sistema, muito do conteúdo armazenado embaixo da estrutura de /proc pode ser consultado e manipulado para um melhor tunning do sistema. A maioria das aplicações e ferramentas de controle/gerência do sistema buscam por suas informações neste local, e não injustamente as informações ali armazenadas são extremamente vitais e importantes para um perfeito funcionando do conjunto.Conhecer esses arquivos ao invés de apenas colecioná-los pode fazer toda diferença. Muito tempo pode ser economizado e sistema de missão-crítica poupados de um possível reboot, principalmente quando você está próximo de bater seu novo recorde de uptime. Enfim, hack & enjoy-it!

Referências

Com esse pequeno start-up e suas respectivas ferramentas, com a ajuda de quaisquer mecanismos de busca o interessado poderá coletar novas informações sobre o assunto, além claro, da forte recomendação de leitura de suas manpages (sysctl, ipcs, procinfo, proc...).