[FUG-BR] Servidor com load altíssimo
nervoso
nervoso em unixarea.com.br
Sexta Julho 6 12:11:27 BRT 2012
Em Sex, 2012-07-06 às 08:57 -0300, Antônio Pessoa escreveu:
> Mas se essa mesma aplicação funcionava sem problema em outro servidor
> não justificaria, a não ser que o desenvolvedor tenha atualizado a
> aplicação justamente durante a migração do servidor, mascarando a real
> causa do problema.
Eu tinha um caso justamente com php e mysql
o php fazia loop no banco, o que "acabava" com a cpu,
pois ficava em loop ao adquirir mutex.
solucao foi colocar um sleep de uns 100ms no loop de aquisicao
de mutex, e tomar cuidado para se o mutex for em cima de I/O aberto,
quando der I/O error (close do socket, por exemplo) em uma thread,
o mutex (que estava associado ao socket...) entra em loop...
Mysql, sendo um "BANDO" de dados e multithread, se nao
for bem programado no php, ele realmente come toda a cpu ....
Parece que tem loop de php em cima do banco de dados mysql...
veja com o programador onde está o loop...
Compile o kernel com a opcao KTRACE....
execute a coisa... pegue uma task (PID) do apache que esta em loop,
consumindo tudo..
vai em um filesystem com BASTANTE ESPACO...
e dá o comando... ktrace -di -p PID
deixe rodar por uns 20 segundos....
comando: ktrace -c -p PID (pára o trace)...
comando: kdump > trace.log (cria o arquivo de log...)
depois use o vi para olhar o trace.log e veja se o sistema
nao esta em loop de socket ou mutex. (vai nas ultimas linhas e vai
voltando...).
No linux funciona???
Sim por que o sistema de threads do linux é diferente...
coisa com "recursive mutex" Nos BSDs (freebsd, netbsd, openbsd e até no
OSX!!!)
tem problema com isso... ele entra em loop quando nao configurado a
opcao de mutex no codigo do programa...
Mais detalhes sobre a lista de discussão freebsd