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.
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).
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.
Número máximo de identificadores de semáforos (conjuntos).
Número máximo de semáforos para todo o sistema.
Número máximo de semáforos por conjunto.
Número de entradas no mapa de semáforos. Deve ser definido como o produto de SEMMNI e SEMMSL (SEMMAP = SEMMNI * SEMMSL).
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!
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
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:
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.
Tamanho mínimo de um segmento de memória compartilhada (bytes). Padrão 1.
Quantidade total de memória compartilhada disponível (bytes ou páginas)
Número máximo de segmentos de memória compartilhada por processo. Somente 1 segmento é necessário, mas o padrão é muito maior.
Número máximo de segmentos de memória compartilhada para todo o sistema.
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!
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...).
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários