Hello Rasmus,
Thank you for the insight. I ran exactly what you said, on the very
same php-fpm process, once just after restarting it almost 2 days ago,
so having fast response time, and one just right now after the "slow
down" issue triggered during the night.
The output of the perf diff is quite poor I think, here's the mainline :
35.90% +44.94% php-fpm [.] 0x0000000000042412
10.72% -6.05% libc-2.19.so [.] 0x0000000000079030
9.71% -9.34% newrelic.so [.] 0x0000000000030980
3.81% -3.47% [kernel.kallsyms] [k] ipt_do_table
2.56% -2.02% [kernel.kallsyms] [k] nf_iterate
2.32% -1.99% opcache.so [.] 0x0000000000008cec
1.44% [kernel.kallsyms] [k] update_cfs_shares
1.42% [kernel.kallsyms] [k] __bpf_prog_run
1.28% [vdso] [.] __vdso_gettimeofday
How could I provide more info ?
Thanks,
Best regards,
Jérémie
On Fri, Oct 14, 2016 at 9:10 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On Fri, Oct 14, 2016 at 9:15 PM, Jérémie BORDIER <jeremie.bord...@gmail.com>
> wrote:
>>
>> I don't really know how to investigate further. If you have any
>> pointers on how to help figuring out what's wrong, I'd love to try.
>
>
> I would breakout the Linux perf command for something like this.
>
> Run it like this:
>
> perf record -p <pid_of_a_php-fpm_process> -g
>
> Let that run for some arbitrary amount of time. Start with 10 seconds, or
> so. Then:
>
> perf report -n
>
> That should give you a nice report of what your php-fpm process did for
> those 10 seconds. Now do the same thing when you see the problem and compare
> the reports.
>
> -Rasmus
--
Jérémie BORDIER
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
