On 22.11.2010 02:55, Jeff Trawick wrote:: > 2010/11/21 Jeff Trawick <trawick@xxxxxxxxx>: >> 2010/11/21 Honza Lefty Škoda <lefty@xxxxxxxxxxxx>: >>> On 21.11.2010 16:57, Jeff Trawick wrote:: >>>> 2010/11/21 Honza Lefty Škoda <lefty@xxxxxxxxxxxx>: >>>>> I am running performance benchmarks with ab2 on my server and I >>>>> discovered that fcgid creates much more than FcgidMaxProcessesPerClass. >>>>> And if I make 15 concurrent requests fcgi starts 15 php processes at the >>>>> same time without worrying about FcgidSpawnScoreUpLimit! >>>>> >>>>> I use mod_fcgid with suexec for php execution (via php-wrapper bash >>>>> script, which does a lot of magic including execs, chroot and setuid). >>>>> >>>>> The configuration (for fcgid 2.3.6 on apache 2.2.15): >>>>> >>>>> /etc/apache2/modules.d/20_mod_fcgid.conf: >>>>> 25: FcgidMinProcessesPerClass 0 >>>>> 26: FcgidMaxProcessesPerClass 10 >>>>> >>>>> 33: FcgidSpawnScore 10 >>>>> 34: FcgidTerminationScore 20 >>>>> 35: FcgidTimeScore 1 >>>>> 36: FcgidSpawnScoreUpLimit 25 >>>> >>>> I did find/fix one related issue this a.m.: the first process created >>>> didn't adjust the score, so you could in effect create one more >>>> process than desired during ramp-up. I didn't see your exact issue >>>> though. >>>> >>>> Two things: >>>> >>>> Does your "magic" wrapper logic preserve the pid created by mod_fcgid >>>> (i.e., use exec instead of fork)? If not, the fcgid PM will be >>>> confused and you're probably getting requests successfully processed >>>> between the time fcgid forks a child and when it exits. (That >>>> probably isn't a workable explanation since an exiting child would add >>>> a huge number -- 20 -- to the score. But please confirm anyway :) ) >>> Yes, PID of php-cgi process matches the one in server-status worker list. >>> >>>> >>>> If you are preserving the pid (i.e., fcgid PM can track what it has >>>> created), turn on LogLevel info and see if you can get more insight >>>> into what is happening with spawn score manipulation/checking. Here's >>>> what I get using the directives you posted and hammering on one script >>>> with ab (>100 current clients): >>> >>> Good idea! >>> I tried to run the tests again with surprising results. Some >>> VirtualHosts break rules: >>> >>> Sun Nov 21 16:57:33 2010] [info] mod_fcgid: server >>> *:/opt/hostik/webbin/php-wrapper.fcgi(11473) started >>> [Sun Nov 21 16:57:33 2010] [info] mod_fcgid: server >>> *:/opt/hostik/webbin/php-wrapper.fcgi(11474) started >>> [Sun Nov 21 16:57:33 2010] [info] mod_fcgid: server >>> *:/opt/hostik/webbin/php-wrapper.fcgi(11475) started >> ... >>> >>> After several benchmarks I found out that it's caused by the >>> FcgidMinProcessesPerClass which is set to 1 for some vhosts. When I set >>> this, scores are completely ignored! >> >> Thanks for finding that; I've now duplicated it. Hopefully it will be >> easy to resolve. (It acts like a classic merging bug, but the score >> configurations are supposed to be taken from the main vhost so merging >> is supposed to be irrelevant.) >> > > this fixes it for me: > > Index: modules/fcgid/fcgid_spawn_ctl.c > =================================================================== > --- modules/fcgid/fcgid_spawn_ctl.c (revision 1037483) > +++ modules/fcgid/fcgid_spawn_ctl.c (working copy) > @@ -178,7 +178,7 @@ > if (current_node->inode == command->inode > && current_node->deviceid == command->deviceid > && !strcmp(current_node->cmdline, command->cmdline) > - && current_node->vhost_id == sconf->vhost_id > + && current_node->vhost_id == command->vhost_id > && current_node->uid == command->uid > && current_node->gid == command->gid) > break; > Works great! Now I am facing another score related issue - on gracefull reload, the scores are kept, but the processes are killed (which results in really high scores). After that, no fcgi processes are spawned for quite a long time. It would be wise to reset scores. And as I don't know any other (more official) way to submit bugs, I write it here again. :) > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|