O que está acontecendo com o disco IO e o bloqueio? Presumivelmente, se o seu processo está ligado à CPU até um ponto em que isso muda, então algo mais está ocupado e é mais provável que seja o seu disco.
Você está atingindo limites de memória que poderiam fazer com que você iniciasse a troca? Quanta RAM seus processos PHP usam (RSS)? Quanta RAM você tem disponível? Você consegue um desempenho similarmente flutuante se você derrubar o número de processos PHP? Em que nível a flutuação aparece?
Note que pm.max_children = 100 é provavelmente muito alto. A menos que você esteja lidando com solicitações de longa duração, como grandes downloads, provavelmente é melhor reduzi-lo bastante. Hesito em especificar um número sem saber o que o sistema está fazendo, mas provavelmente algo na faixa 5-40 funcionará muito melhor. É provável que pm.max_requests seja alto demais. Você provavelmente descobrirá que obtém pouco benefício, e mais provavelmente degradação significativa se exceder 100 ou mais, e se o que está sendo executado pelo php é altamente variável e consome memória, ou se você tem vazamentos de memória, então você fará melhor reduzindo-o um pouco mais. Se você realmente não sabe o que funciona, comece com cada uma dessas configurações por volta de 30 e experimente.
O PHP está gerando sessões? Como eles são armazenados? Se eles estão em um sistema de arquivos, que tipo de sistema de arquivos é? Em alguns casos, você obtém um gargalo com o bloqueio no diretório em que eles estão. Usando uma estrutura de diretórios hash para eles ou usando, por exemplo, memcached pode ajudar com isso.
O que strace executa no relatório de processos do PHP está demorando? Você pode ver isso com um comando composto ao longo destas linhas:
(ps wwaux | grep '^www-data.*php' | awk '{print $2}' \
| xargs -n 1 -P 32 strace -r -p ) 2>&1
| perl -ne '($n) = /^ *(\d*\.\d*)/; print "$n\t$_" if ((defined $n) and ($n > 0.01))'
