> Even I set the pm.max_children=50, I still got lots of errors…...
> Oct 26 22:09:36.354159 [WARNING] [pool www] seems busy (you may need to
> increase start_servers, or min/max_spare_servers), spawning 8 children,
> there are 0 idle, and 12 total children

It's not an errror.
The process manager informs you that the innitial start_server (or
min_spare) is just too low and it will spawn new childs to satisfy all the
incomming requests..

The only Warning you should be worried about is something like this:
Sep 15 17:41:26.901870 [WARNING] [pool www] server reached max_children
setting (70), consider raising it

As that indicates there are no free children and no more will be spawned.


If you don't like such log messages you can increase the pm.start_servers (I
have 20 for example) or disable the Warning messages by setting the
log_level = error



> switch to static process management, dynamic "pm" is a great feature
> to share ressources between several sites hosted on one server. If you
> have only one site on your server, you should use static PM.

In case you have a php script <? sleep(60); ?> no process manager or
configuration will satisfy the wanted req/s if there are more clients (as
the proposed 50 child count) as you end up with each request taking 1 min to
finish. So switching the process manager while could lesser the warning log
entry amount it doesnt really solve the issue (if the cause is slow
application or backends).


As people stated if there are no FPMs slow logs provided the requests may be
as well hanging on a single DB connection and neither nginx nor php itself
(other than FPM killing long running scripts ('request_terminate_timeout'
setting)) can work arround and its hard to give any advices.

The dynamic process manager allows you to somewhat automatically adjust the
best child count (you can set static later if you really preffer that) and
detect the (disaster) events when suddenly something goes wrong (manager
spawns a lot of new childs) but in normal scenario it allows you to consume
as less system resources as possible.

rr


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx