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... ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
