Re: How to align shm in an neat way?
On Mon, Aug 13, 2012 at 10:19:47PM +0200, Rainer Jung wrote: I went the choose right alignment way now: http://people.apache.org/~rjung/patches/mod_socache_shmcb-alignment.patch It actually wasn't that complicated. Alignment problems never die with that code! +1, that looks good, might be simpler using some #defines for the APR_ALIGN_DEFAULT(blah) values rather than inlining? Regards, Joe
mod_fcgid concurrency bottleneck, issue#53693
Ahoy!
With mod_fcgid I've observed a performance bottleneck in which concurrent
requests to a virtualhost where the number of concurrent requests exceed
the number of available fcgid-spawned processes result in a significant
delay in responding to requests.
Details of this situation, how to reproduce, various scenarios tried, etc
are detailed in the issue submission [1].
In file modules/fcgid/fcgid_bridge.c, there is this section of code:
if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
apr_sleep(apr_time_from_sec(1));
If I change the sleep time from 1 second to 0 seconds (or, comment out
this section of code entirely), the bottleneck goes away. It seems like
the more appropriate action here would be to turn the sleep time into a
configurable value, with the current 1s value as the default.
I presume this code is meant to be a way to help defer spawn requests so
that a server is not over-whelmed with spin-up related I/O.
My questions are:
- Is this intended to be a throttling mechanism and if so, is there a more
efficient way to handle this throttling?
- If I outright reduce that sleep delay to 0 (or comment out this code),
what potential or expected problems am I introducing to mod_fcgid?
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53693
---
Mike M
You can't learn in school what the world is going to do next year.
Re: Proposed TR for this Friday
With my Mom's hospitalization and stuff, this kinda slipped... I propose this Friday: Aug 17th. Any conflicts?? On Aug 7, 2012, at 9:38 AM, Jim Jagielski j...@jagunet.com wrote: I'm proposing a TR of 2.4.3 for this Friday (the 10th)... I'll be RMing.
Re: How to align shm in an neat way?
slotmem handles this well, afaict ;) On Aug 13, 2012, at 12:32 PM, Jeff Trawick traw...@gmail.com wrote: On Mon, Aug 13, 2012 at 12:30 PM, Rainer Jung rainer.j...@kippdata.de wrote: Hi, PR 53040 reveals, that mod_socache_shmcb has an alignment problem. One of the three structs mapped into shm contains an apr_time_t member, which at least on Sparc is 8 Bytes, whereas for 32 bit builds long is only 4 Bytes. Currently everything is aligned for 4 Bytes, so we get bus errors/crashes when trying to assign the apr_time_t to an address that is only divisible by 4 instead of 8. I can easily reproduce the problem. A possible solution is to pad the three structures SHMCBHeader, SHMCBSubcache and SHMCBIndex to a multiple of 8 Bytes length. For Subcache and Index this is already true by coincidence, SHMCBHeader needs another 4 Bytes. I wonder what the right solution is. In the patch http://people.apache.org/~rjung/patches/mod_socache_shmcb-padding.patch I hard coded the padding, but I don't really like it, because it breaks if members are added to the struct. I could add a sizeof() test during startup or probably even compilation to warn or err, if the padding is wrong. I see several recipes for alignment using pragmas and attribute, but all of them are compiler specific. One could also wrap the struct in a wrapped struct, so that one could use the sizeof() of the inner struct to determine the padding of the outer struct. That would make the code convoluted. I checked other parts of the code, but couldn't find a simple solution. Any hints how to do this nicely? APR_ALIGN_DEFAULT? Regards, Rainer -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: svn commit: r1373121 - /httpd/httpd/trunk/CHANGES
On Tue, Aug 14, 2012 at 5:21 PM, traw...@apache.org wrote: Author: trawick Date: Tue Aug 14 21:21:02 2012 New Revision: 1373121 URL: http://svn.apache.org/viewvc?rev=1373121view=rev Log: add back the DefaultRuntimeDir/DEFAULT_REL_RUNTIMEDIR stuff that is not in 2.4.x The trunk patches for these all have some configuration breakage as 2.4.x interprets the individual directive or API parameter as relative to ServerRoot whereas trunk interprets everything relative to DefaultRuntimeDir. I thought this was an accidental CHANGES slip-up, but I subsequently noticed r1373105 :( (I'm getting commit messages slowly.) rjung added a bunch of trunk revisions to my concept vote, but those revisions did not contain the 2.4.x modifications for compatibility with 2.4.prev that were the point of the vote. Now they're committed to 2.4.x. I'll revert r1373105 when I get a chance later today. I'm sorry that the point of that vote was confusing. Modified: httpd/httpd/trunk/CHANGES Modified: httpd/httpd/trunk/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1373121r1=1373120r2=1373121view=diff == --- httpd/httpd/trunk/CHANGES [utf-8] (original) +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Aug 14 21:21:02 2012 @@ -25,6 +25,15 @@ Changes with Apache 2.5.0 *) mod_lua: Add new directive LuaCodeCache for controlling in-memory caching of lua scripts. [Daniel Gruno] + *) The following now respect DefaultRuntimeDir/DEFAULT_REL_RUNTIMEDIR: + - APIs: ap_log_pid(), ap_remove_pid, ap_read_pid() + - core: the scoreboard (ScoreBoardFile), pid file (PidFile), and + mutexes (Mutex) + - mod_lbmethod_heartbeat, mod_heartmonitor: heartbeat storage file + - mod_ldap: shared memory cache + - mod_socache_shmcb, mod_socache_dbm: shared memory or dbm for cache + [Jeff Trawick] + *) mod_ssl: Add RFC 5878 support. [Ben Laurie] *) mod_lua: Add new directive LuaAuthzProvider to allow implementing an -- Born in Roswell... married an alien... http://emptyhammock.com/
回复: mod_fcgid concurrency bottleneck, issue#53693
Hi， Mike
It's really a problem...I will take a look and find a solution for it
2012-08-15
pqf
发件人：Mike M
发送时间：2012-08-15 04:29
主题：mod_fcgid concurrency bottleneck, issue#53693
收件人：devdev@httpd.apache.org
抄送：
Ahoy!
With mod_fcgid I've observed a performance bottleneck in which concurrent
requests to a virtualhost where the number of concurrent requests exceed
the number of available fcgid-spawned processes result in a significant
delay in responding to requests.
Details of this situation, how to reproduce, various scenarios tried, etc
are detailed in the issue submission [1].
In file modules/fcgid/fcgid_bridge.c, there is this section of code:
if (i 0 || j 0 || count_busy_processes(r, fcgi_request)) {
apr_sleep(apr_time_from_sec(1));
If I change the sleep time from 1 second to 0 seconds (or, comment out
this section of code entirely), the bottleneck goes away. It seems like
the more appropriate action here would be to turn the sleep time into a
configurable value, with the current 1s value as the default.
I presume this code is meant to be a way to help defer spawn requests so
that a server is not over-whelmed with spin-up related I/O.
My questions are:
- Is this intended to be a throttling mechanism and if so, is there a more
efficient way to handle this throttling?
- If I outright reduce that sleep delay to 0 (or comment out this code),
what potential or expected problems am I introducing to mod_fcgid?
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53693
---
Mike M
You can't learn in school what the world is going to do next year.
Re: Proposed TR for this Friday
On 8/14/2012 4:17 PM, Jim Jagielski wrote: With my Mom's hospitalization and stuff, this kinda slipped... Sorry to hear, hope she is recovering :( I propose this Friday: Aug 17th. +1 - I'll address anything wrong for mak/dep files. Jeff's brilliant catch of that regression in core.c to the windows accept logic should put that whole issue to bed, 2.4 is looking much improved. It's also been a bit over 6 mos since we released 2.2.22, and there are obviously some who can't yet upgrade waiting for binary modules. So I'm proposing to TR 2.2.23 at the same point this Friday. It will close the one security issue that has been sitting around a while, and also gives me an excuse to bundle a more up to date openssl. It seems like any and all interest by dev@ in 2.0 has died out and we should declare it dead. 2.2 is well over 5 yrs old now. So I'd propose in the next 2.4 announce, we would mention the availability of a refreshed legacy 2.2 release, as well as that httpd 2.0 is no longer supported and will not be refreshed, encouraging all users to move on to 2.4. WDYT?
Re: Proposed TR for this Friday
On 8/14/2012 10:56 PM, William A. Rowe Jr. wrote: It's also been a bit over 6 mos since we released 2.2.22, and there are obviously some who can't yet upgrade waiting for binary modules. So I'm proposing to TR 2.2.23 at the same point this Friday. It will close the one security issue that has been sitting around a while, and also gives me an excuse to bundle a more up to date openssl. Along the same lines... Sorry to be a pain, but I'd *really* like to get SSLProxyMachineCertificateChainFile (proposed in STATUS) added or at least reviewed by then. I'm hoping someone has a few moments to spare and could take a look? FWIW, I use the patch with engine and non-engine implementations on Linux, AIX and Solaris. -- Daniel Ruggeri
