[Cascavel-pm] Gerenciando conexoes

Marco A P D'Andrade mdacwb em gmail.com
Segunda Janeiro 22 21:27:15 PST 2007


Cristiano,

Eu tenho uma situação similar em um ambiente de webmail, onde alguns
processos do apache perdem o sincronismo, e somente com um kill direto
para liberar os recursos...

Iniciei alguns testes verificando informações no ExtendedStatus, e
decidindo quais seriam os processos a ser derrubados, ainda nada
conclusivo, mas tomei a pratica de:

  Status =~ /KRW/
  SS > 10000 (Seconds Since Last Request)

Já pensei em utilizar Acc, e eliminar a partir de determinado numero,
equivalente a MaxRequests, mas nem tive tempo de avaliar isto...

Se julgar relevante esta abordagem, posso lhe enviar a parte que
esbocei para o parser do html gerado.

Caso não tenha o server-status ativo, segue um exemplo do resultado:

  http://httpd.apache.org/server-status


Claro, que vc também deve considerar se o numero de processos
indicados no MaxClient "cabe" em memória...



Sds,
Marco Antonio

2007/1/22, Cristiano Torres <listas.perl em gmail.com>:
> Boa tarde Lorn... omiti algumas coisas no primeiro e-mail e mesmo assim
> ficou grande.
>
> Além dos fatos que apresentei, em
> http://mail.pm.org/pipermail/cascavel-pm/2007-January/007952.html
>
> Um agravante é que, devido a má gerencia de processos da aplicação o
> "Apache" fica com muitos processos filhos presos
> que não conseguem ser gerenciados pelo processo pai. Portanto as diretivas
> MaxSpareServer, MaxRequest,MaxClients etc
> não tinham efeito para os processos de conexão com o banco, entao depois que
> o modulo desenvolvido conectava com o
> banco, o servidor web "perdia" controle sobre o processo ( porém continuavam
> no scoreboard do apache).
>
> Entao acontecia a situacao N processos do apache na porta 80 e N+X conexoes
> com o banco oracle, onde X crescia a medida
> que os processos do apache eram reciclados. Isso gerou uma situacao em que
> varios processos concorriam com conexoes ao
> banco e ficavam disputando memoria e cpu timing, então para eles era normal
> dar um "top" e ver o "load avarage" em 150,
> coisas do tipo. Depois que vi esse estupro no servidor, escandalizei.
>
>  Passei para o pessoal quais as chamadas de sistema que o apache mandava
> para o processos filhos, mostrei como ele fazia forks,
> etc etc ( gracas a documentacao do apache e do proprio codigo), mostrei o
> porque estava gerando tantos locks no banco, as
> concorrencias de conexao com o banco etc...
>
> Tudo bem, analisar o problema e falar para o pessoal que está errado foi a
> parte facil, porém fiquei meio
> infeliz com minha incapacidade de resolver o problema por completo. Entao
> resolvi aprofundar meus conhecimentos
> em perl ( ou melhor, tentar desenvolver alguma coisa de qualiade) ... e acá
> estou :)
>
> E ja aprendi muito .
>
>
> Desculpe a demora e a possivel falta de coerencia, faltam algumas horas de
> sono no meu Portugues.
>
> Obrigado.
>
>
> Em 21/01/07, Lorn <lorn.br em gmail.com> escreveu:
> > Explique melhor seu problema para que possamos ajuda-lo :)
> >
> > On 1/20/07, Cristiano Torres < listas.perl em gmail.com> wrote:
> >
> >
> > >
> > > Caros mestres, bom dia.
> > >
> > > Uma breve introdução desse humilde aprendiz, e claro uma solicitação de
> ajuda ou referência.
> > >
> > > Onde trabalho sou um dos responsáveis pela área de TI e configuração de
> servidores WEB. Basicamente configuro e
> > > monitoro servicos WEB para que a aplicacao desenvolvida pela empresa
> rode sem problemas. Porém recentemente
> > > começaram a desenvolver um modulo para apache ( desenvolveram em Kylix
> para versao 1.3.37 do Apache) que
> > > recebe as conexoes via http, processa a requisicao, abre conexao com
> oracle e retorna o resultado para o cliente.
> > >
> > >
> > > O que acontece é que esse modulo esta abrindo mais conexoes com o banco
> do que devia, e os malditos
> > > desenvolvedores em delphi disseram que a culpa é do servico web.
> > >
> > > Já mostrei para o pessoal que o apache só gerencia as requisicoes com a
> porta na qual o processo "escuta" (80),
> > > e que as outras conexoes deveriam ser gerenciadas pelo modulo/driver que
> eles utilizam. Fiz isso usando
> > > um modulo do CPAN "Apache::Scoreboard" (entao tive uma breve nocao do
> poder do perl)
> > Bom, podem ficar tranquilos que não vim pedir ajuda em kylix ou em delphi,
> meu intuito é elaborar um programa
> > >
> > >
> > > que faça o seguinte, pegue o PID do processo do apache, se esse PID não
> tiver simultaneamente conexoes abertas
> > > na porta 80 e 1521 (porta do banco), que gere uma lista.
> > >
> > >
> > > Nao pretendo corrigir a falha do modulo do desenvolvimento, queria
> aprender como linguagens de
> > > programacao mais apropriadas lidam com isso, por isso peço uma
> referencia. Acho que
> > > para corrigir isso o ideal seria que trocassem o pessoal do
> desenvolvimento
> > >
> > >
> > > Comprei o Learning Perl, mas ainda estou apanhando um pouco.
> > >
> > > Se alguem poder dar uam dica para esse pequeno gafanhoto, agradeço.
> > >
> > > E desculpem pelo tamanho do e-mail
> > >
> > >
> > > Cristiano Torres
> > > _______________________________________________
> > > Cascavel-pm mailing list
> > > Cascavel-pm em pm.org
> > > http://mail.pm.org/mailman/listinfo/cascavel-pm
> > >
> > >
> >
> >
> >
> > --
> > Lindolfo "Lorn" Rodrigues
> > - www.slackwarezine.com.br
> > - http://lornlab.org
> > - http://sao-paulo.pm.org
> > use Catalyst;
> > _______________________________________________
> > Cascavel-pm mailing list
> > Cascavel-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/cascavel-pm
> >
> >
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>


Mais detalhes sobre a lista de discussão Cascavel-pm