[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