tons of fpm_children_bury() in php-fpm.log PHP 5.2.13(PHP-FPM 0.5.13) + Nginx 0.7.65

My PHP with FastCGI has some unexpected logs, and works slowly.

In php-fpm.log, i find tons of NOTICE, as follows,

...
Mar 31 15:26:21.964563 [NOTICE] fpm_children_bury(), line 215: child 59658 (pool default) exited with code 0 after 568.697496 seconds from start
Mar 31 15:26:21.966770 [NOTICE] fpm_children_make(), line 352: child 59835 (pool default) started
Mar 3开发者_开发问答1 15:26:26.391416 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 31 15:26:26.391483 [NOTICE] fpm_children_bury(), line 215: child 59565 (pool default) exited with code 0 after 630.963131 seconds from start
Mar 31 15:26:26.393197 [NOTICE] fpm_children_make(), line 352: child 59840 (pool default) started
Mar 31 15:26:27.616496 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 31 15:26:27.616575 [NOTICE] fpm_children_bury(), line 215: child 59625 (pool default) exited with code 0 after 605.911775 seconds from start
Mar 31 15:26:27.618385 [NOTICE] fpm_children_make(), line 352: child 59843 (pool default) started
Mar 31 15:26:31.151889 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 31 15:26:31.152025 [NOTICE] fpm_children_bury(), line 215: child 59642 (pool default) exited with code 0 after 601.730927 seconds from start
Mar 31 15:26:31.153845 [NOTICE] fpm_children_make(), line 352: child 59844 (pool default) started
Mar 31 15:27:24.001541 [NOTICE] fpm_got_signal(), line 48: received SIGCHLD
Mar 31 15:27:24.001692 [NOTICE] fpm_children_bury(), line 215: child 59563 (pool default) exited with code 0 after 688.609874 seconds from start
Mar 31 15:27:24.003531 [NOTICE] fpm_children_make(), line 352: child 59853 (pool default) started
...

php pages are processing too slowly, what's the mattar?

V/R,

gavin

This is from: http://forum.nginx.org/read.php?3,11113,11120 " There's a setting which controls this. (Default = 500). So after serving n=500 requests, the child worker process will voluntarily exit itself. The manager above should re-fork a new child to replace the exited one. This is normal behaviour. The child will kill itself after n requests because to stop memory leaks building up."