httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [users@httpd] mod_fcgid ignoring both scores and process count
Date Mon, 22 Nov 2010 01:55:45 GMT
2010/11/21 Jeff Trawick <trawick@gmail.com>:
> 2010/11/21 Honza Lefty Škoda <lefty@multihost.cz>:
>>
>>
>> On 21.11.2010 16:57, Jeff Trawick wrote::
>>> 2010/11/21 Honza Lefty Škoda <lefty@multihost.cz>:
>>>> 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;

---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message