Memnemonics fike’s Rotating Header Image

3000 conexões simultâneas no PostgreSQL, como assim?

     Não, não vou comentar sobre o filme 300, apesar de estar ansioso para assitir. :)
   
     Essa semana tive que configurar um servidor com PostgreSQL 8.2 para 3000 conexões e algo deste  tipo é necessário mexer na memória compartilhada (inglês é shared memory)do kernel linux e também na quantidade de semáforos que podem ser abertos. Cada conexão tem um custo de 400 bytes da memória compartilhada, no caso das  3 mil conexões o cálculo é "3000 X 400 = ~ 1Mbyte ".  Ao calcular o uso total de memória compartilhada no kernel você precisa somar o consumo dos processos do PostgreSQL que é configurado pelo parâmetro shared_buffers do arquivo postgresql.conf. Sobre memória compartilhada vale pena o texto do Dicas-L sobre semáforos e kernel.

      Geralmente alterar a memória compartilhada é senso comum para um DBA PostgreSQL mas alterar os semáforos não.  Um outro post eu comento sobre isso. ;)
 
      Supondo que esteja configurado para 128Mbytes o shared_buffers, deve se acrescentar mais 1Mbyte para as 3 mil conexões. Para o kernel linux aceitar essas configurações do PostgreSQL é necessário mexer no diretório /proc para alterar a memória compartilhada e a quantidade de semáforos.  No meu caso tive que alterar e usei a linha abaixo.

#echo "250 32000 100 256" > /proc/sys/kernel/sem

     Na documentação do PostgreSQL tem uma parte específica sobre tuning em kernel. :)

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google

5 Comments on “3000 conexões simultâneas no PostgreSQL, como assim?”

  1. #1 Cesar Cardoso
    on Apr 1st, 2007 at 21:24

    Opa, acho que essa história de tuning de PostgreSQL merece mais carinho, atenção e artigos :) Tuning é uma coisa que todo DBA deveria fazer, mas acaba que poucos fazem, e daí vem boa parte dos problemas de aplicação lenta.

  2. #2 fernando.ike
    on Apr 1st, 2007 at 22:08

    Tem quase toda razão, geralmente os maiores problemas de lentidão em banco estão na aplicação. Principalmente em pool (persistência) de conexão e problemas nas consultas SQL, na média uns 10% estão relacionados a tuning no banco de dados. ;)

  3. #3 jalexandre
    on Apr 2nd, 2007 at 14:10

    Uia… vou ler esse negócio, apesar de não ser DBA…
    Sempre é bom saber um poquinho mais sobre kernel =D

    [ ] ’s

  4. #4 Leonardo F. Fontenelle
    on May 13th, 2007 at 14:24

    Se você curte histórias em quadrinhos, sugiro o livro!

    A propósito: leia a história real na Wikipédia.

  5. #5 fernando.ike
    on May 13th, 2007 at 19:53

    Leo,

    tá na lista de aquisições para próximo mês. =)

Leave a Comment

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Click to hear an audio file of the anti-spam word