[Cascavel-pm] Gerenciando conexoes
Cristiano Torres
listas.perl em gmail.com
Terça Janeiro 23 07:30:10 PST 2007
Boa tarde Marco, tudo bem?
Eu consegui amostragens muito boas usando o Apache::Scoreboard , ele
consegue pegar esses parametros
todos do mod-status.
Um outro parametro que acho interessante é o
kill -USR1 `cat path/httpd.pid` , não sei se no caso seria util.
http://httpd.apache.org/docs/1.3/stopping.html
Os calculos sobre os parametros do apache eu estudei com muito cuidado, por
isso fiquei indignado
do pessoal ter falado que o problema era do web service.
Uma documentacao que achei bem bacana foi essa, indicada pelo amigo Hamilton
( que por
algum motivo sombrio apenas lê a lista, mas me deu uma forca danada no
quesito apache e linux).
http://modperlbook.org/html/ch11_01.html
Continuarei na luta, obrigado mais uma vez Marco
2007/1/23, Marco A P D'Andrade <mdacwb em gmail.com>:
>
> 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
> >
> >
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/cascavel-pm/attachments/20070123/633bb347/attachment-0001.html
Mais detalhes sobre a lista de discussão Cascavel-pm