Re: Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Hi Luca,
Am 10.10.2016 um 16:48 schrieb Luca Toscano:
> Hi Stefan,
> 
> 2016-10-07 10:11 GMT+02:00 Stefan Priebe - Profihost AG
> >:
> 
> Am 05.10.2016  um 12:50 schrieb Luca Toscano:
> > Hi Stefan,
> >
> > 2016-09-26 14:26 GMT+02:00 Stefan Priebe - Profihost AG
> > 
> >>:
> >
> > currently no deadlocks since V5 also no old httpd processes anymore.
> >
> >
> > if you still have patience and time, I'd like to ask you a question:
> > have you noticed any performance improvement after applying the patch?
> > For example (Yann correct me if I am wrong) I'd expect some reduction in
> > system CPU utilization since the number of wake ups / context switches
> > has been reduced dramatically. Moreover, it would be great to know some
> > info about the status of the worker threads over time from the
> > scoreboard, since it would be great not to introduce weird regressions
> > with this patch :)
> 
> Dear Luca,
> 
> sure what can i exactly provide?
> 
> 
> I would be interested in scoreboard related metrics over time, namely if
> the number of busy/idle/graceful/etc.. worker statuses change from a
> "regular" 2.4.23 httpd. I don't expect a bit difference, but I'd really
> like to make sure that no big regression is introduced (like let's say,
> an increase over time of worker threads stuck in a certain status like G
> or more busy workers at request peak load time). 
> 
> Related to the above: have you noticed any improvement in
> latency/throughput metrics? For example, an improvement in total amount
> of requests handled in the same period of time o more generally in the
> responsiveness of the websites served?

It seems i cannot provide any of the requested data ;-(

This is an example output of a server running with the patch:
   Current Time: Monday, 10-Oct-2016 21:57:49 CEST
   Restart Time: Wednesday, 05-Oct-2016 06:30:31 CEST
   Parent Server Config. Generation: 12
   Parent Server MPM Generation: 11
   Server uptime: 5 days 15 hours 27 minutes 17 seconds
   Server load: 4.01 4.22 4.10
   Total accesses: 6485371 - Total Traffic: 139.0 GB
   CPU Usage: u2686.2 s1651.82 cu0 cs0 - .89% CPU load
   13.3 requests/sec - 298.9 kB/second - 22.5 kB/request
   10 requests currently being processed, 115 idle workers

   Slot  PID  Stopping   ConnectionsThreads  Async connections
   total accepting busy idle writing keep-alive closing
   06044  no   8 yes   223   0   1  4
   115254 no   3 yes   223   0   0  2
   215189 no   5 yes   322   0   0  2
   315081 no   5 yes   025   0   0  4
   415082 no   1 yes   322   0   0  0
   Sum  5 022  10   115  0   1  12

L__W__W__W_W__W_
__W_W__L_W___...







Stefan

Re: 2.4.24 soon?

[William A Rowe Jr]

On Mon, Sep 19, 2016 at 10:36 AM, Jim Jagielski  wrote:

>
> > On Aug 2, 2016, at 2:59 PM, Jacob Champion  wrote:
> >
> > On 08/02/2016 11:12 AM, William A Rowe Jr wrote:
> >> One additional thought... On 2.2 and 2.4 I see this change as entirely
> >> opt-in, no disruption to a user performing a subversion upgrade. On
> >> 2.6/3.0 I'd want us to seriously consider changing the out-of-the-box
> >> default to strict parsing.
> >
> > +1.
> >
> > (I have no strong opinions on whether or not this should go into the
> next release, though.)
>
> Any more thoughts related to this? I know that it is
> still being worked here and there, but knowing whether or
> not it will be folded in 2.4.24 might be incentive to
> finish polishing as it were.
>

I have a strong opinion that the strict request message parsing should be
included in 2.4.24/2.2.32. That includes disallowing all unexpected CTL
chars. This can easily be ready on your proposed timeframe.

I no longer believe we should address URI formatting until 2.4.25, it's
obviously a much larger hornets nest in terms of many incompatibilites
that are well-known. So I've tweaked some API calls and should have
a patch in by tomorrow for this change, to take out the StrictURI option
and replace the scan valid uri chars with the efficient scan vchar/obstext
that halts on any CTL or space.

Will start a fresh thread for the post-mortem and backport discusssions.

Re: Frequent wake-ups for mpm_event

[Luca Toscano]

Hi Stefan,

2016-10-07 10:11 GMT+02:00 Stefan Priebe - Profihost AG <
s.pri...@profihost.ag>:

> Am 05.10.2016 um 12:50 schrieb Luca Toscano:
> > Hi Stefan,
> >
> > 2016-09-26 14:26 GMT+02:00 Stefan Priebe - Profihost AG
> > >:
> >
> > currently no deadlocks since V5 also no old httpd processes anymore.
> >
> >
> > if you still have patience and time, I'd like to ask you a question:
> > have you noticed any performance improvement after applying the patch?
> > For example (Yann correct me if I am wrong) I'd expect some reduction in
> > system CPU utilization since the number of wake ups / context switches
> > has been reduced dramatically. Moreover, it would be great to know some
> > info about the status of the worker threads over time from the
> > scoreboard, since it would be great not to introduce weird regressions
> > with this patch :)
>
> Dear Luca,
>
> sure what can i exactly provide?
>

I would be interested in scoreboard related metrics over time, namely if
the number of busy/idle/graceful/etc.. worker statuses change from a
"regular" 2.4.23 httpd. I don't expect a bit difference, but I'd really
like to make sure that no big regression is introduced (like let's say, an
increase over time of worker threads stuck in a certain status like G or
more busy workers at request peak load time).

Related to the above: have you noticed any improvement in
latency/throughput metrics? For example, an improvement in total amount of
requests handled in the same period of time o more generally in the
responsiveness of the websites served?

I don't expect big changes but I am curious :)

Thanks again!

Regards,

Luca

Re: 2.4.24 soon?

[Jim Jagielski]

I'm thinking of a T around the last week of Oct...

Re: Unbounded memory usage in mod_dav + mod_headers/mod_deflate/...

[Evgeny Kotkov]

Evgeny Kotkov  writes:

> However, the problem I described in this thread is different, and it just
> happens to have the same visible consequence.
>
> What is probably more important, the dav_send_one_response() function
> that has the flaw (see the proposed patch) *just* got promoted into a public
> API, and will become the part of the next 2.4.x release [2].  So I prepared
> the patch, assuming that it would be better to fix this before it becomes
> public.

I committed the fix for dav_send_one_response() function in r1764040 [1],
and proposed it for backport to 2.4.x.  Apart from this, I committed the
second patch that adds the note about the API issue in r1764043 [2].

[1] https://svn.apache.org/r1764040
[2] https://svn.apache.org/r1764043


Regards,
Evgeny Kotkov

Re: Segfault in ssl_scache_init on reload

[Niklas Edmundsson]

On Sun, 9 Oct 2016, Ruediger Pluem wrote:




On 10/08/2016 09:28 PM, Niklas Edmundsson wrote:


Hi all.

httpd 2.4.23, built from httpd-2.4.23.tar.bz2 and httpd-2.4.23-deps.tar.bz2 on 
Ubuntu 14.04.5 LTS (trusty).

While fiddling with enabling https on ftp.acc.umu.se I stumbled on the 
following coredump when reloading the server with
-k graceful after renewing/updating the certificate. Has anyone seen anything 
like it before? I'm at a loss figuring out
which end I should start prodding to make sense of this...

frame 0 of the coredump seems to be garbage, and I can't find any obvious NULL 
pointer or similar in frame 1...





What are the values of

mc->stapling_cache
mc->stapling_cache->init


(gdb) p mc->stapling_cache->init
$2 = (apr_status_t (*)(ap_socache_instance_t *, const char *,
const struct ap_socache_hints *, server_rec *, apr_pool_t *)) 0x0

Gaah. I was obviously too tired when I looked into this :/

Anyhow, I think I know what lead to this as well.

- I was testing the https httpd.conf file by copying it to an offlined
  frontend machine.
- Between me copying it there and cert-update/reload happening it got
  overwritten by the maintenance task syncing the configs of all
  frontends to our default config.
- As our old default config only loaded mod_ssl.so, and NOT
  mod_socache_shmcb.so, it makes sense to find a NULL pointer there.

So, the config was definitely broken on reload. Would have been nice 
if it had barfed in a more polite way than segfault though ;-)



/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
 "My pride has had terrible consequences for the galaxy." - Obi-Wan
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=