Marcos, Eu vou ser bem franco contigo: não estou entendendo mais do que tu está falando, não está fazendo o menor sentido...
Só espero que não se ofenda com o que eu vou escrever abaixo. Eu estou tentando ajudar, mas parece que o problema não está claro, só tem hipóteses que parecem vagas e é sobre estas hipóteses que eu vou falar: Vou começar pela questão da race condition. Race condition geralmente quer dizer que algo não aconteceu na ordem esperada quando uma parte de um sistema recebe como entrada dados que podem ter sido modificados por outra "no meio do caminho", só que sem garantias de que estas modificações aconteceram em uma ordem e/ou tempo determinado. Se isso realmente está acontecendo, é um problema da aplicação e tu tem que falar com os desenvolvedores para ver o que está acontecendo. Sobre o IO do disco... IO da rede eu até entenderia, mas eu não sei do que tu está falando quando fala do IO do disco. Se a aplicação é IO bound eu até entenderia, mas geralmente o gargalo do PHP fica na CPU. Como não sei o que tu roda neste servidor, vou assumir que tu conhece o que está rodando e que tem certeza que é IO bound. Mesmo assim, acho difícil de acreditar que alguém ofereça uma VM do VMWare com quatro CPUs virtuais e não tenha a infraestrutura mínima para provisionar as VMs à ponto de uma instância ser capaz de afetar tão drásticamente outras. Se tu mesmo gerencia o host das VMs, dá uma revisada na configuração do VMware, por que isso não deveria acontecer. E se tu não gerencia, fala com quem o faz por que isso é um problema um tanto grave... Ainda sobre o IO, no gráfico que tu mandou no último e-mail mostra uma quantia bem baixa de IO... Eu não vou entrar no mérito filosófico do pacote vs. não pacote (a minha posição é: eu mando o chef instalar e atualizar e não me interessa se veio de pacote, tarball ou se o binário surgiu miraculosamente) e da configuração das conexões do postgres por que os números que tu falou são ridiculamente baixos para este tipo de hardware. Por fim, e talvez mais importante, tu ainda não falou como que os workers do apache foram configurados. Esta, provavelmente, é a causa do teu problema: se o apache está configurado para iniciar um número excessivo de workers, obviamente todos vão acabar consumindo tudo que a máquina tem e vão demorar tanto à ponto de fazer com que o servidor deixe de responder. Tu já tentou simplesmente reduzir o número de workers e/ou threads e/ou processos do PHP-FPM para que seja iguál ou próximo do número de CPUs disponíveis? De novo, pode ter parecido bem ofensivo, mas não é a intenção, eu estou simplesmente sendo o mais direto e objetivo possível. -- Max 2013/12/27 Marcos Tadeu <[email protected]> > > Compartilhando as experiencias, já que php-5.4.22 + php-fpm + apache 2.4.7 > deve ser novidade para muitos. > Já funcionou, embora o problema inicial ainda não tenha sido completamente > domado. > > Estou recorrendo à lista do slackware, pois quero manter tudo pelo PKG do > slack e, em caso de compilar algo, ser feito com um Slackbuild. O objetivo é > fazer a documentação e futuros updates manterem o padrão. Gerenciar exceção é > complicado. > Mas certamente seria possível usar o pecl. > > No entanto, diferente do que disse antes, o suporte ao postgresql funcionou > sim, com a extensão instalada pelo pacote gerado com o php-pgsql.Slackbuild. > É interessante ter este pacote separado, no slackbuilds, pois o padrão do > slackware não tem suporte ao pgsql. Então, em prol da padronização, o tal > merge de Slackbuilds está descartado. > > Todo efeito tem uma causa... Os problemas se agravam quando erramos no > julgamento e pensamos ter achado a causa. > O que me fez pensar que estava sem suporte ao pgsql, foi ter como efeito a > tela da aplicação mostrando que estava sem acesso ao banco de dados. > Mas a causa real era o número de conexões simultâneas no postgresql, que foi > ultrapassada. > Como? Por que? > Minha impressão é que antes, as conexões persistentes não eram "tão > persistentes" ! Havia umas 15 ou 20, visto com > ps fax > Agora, realmente cada cliente está mantendo sua conexão permanente, e vejo as > 100 conexões, que era o limite. > Passado o limite para 200, tudo funciona. > Mas 150 conexões permanentes comem memória. Não justifica a relação > custo/benefício. Então, limitei o número de conexões persistentes no php.ini. > > Ainda tenho um problema de IO. Minha impressão é que depende de outras VMs > hospedadas, que podem estar carregando demais o IO em disco e falta para > minha máquina, aleatoriamente. > Mas, com processos de melhor desempenho comendo menos recursos, aliado aos > limites impostos quanto a threads em paralelo no php-fpm, a máquina não está > explodindo em um race condition, e se recupera de maneira mais graciosa. > > abcs, -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected] --- Você está recebendo esta mensagem porque se inscreveu no grupo "Slackware Users Group - Brazil" dos Grupos do Google. Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para [email protected]. Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
