Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

[PATCH] DTrace probes patch.

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


jesus at omniti

May 5, 2008, 12:27 PM

Post #1 of 6 (204 views)
Permalink
[PATCH] DTrace probes patch.

Hello all,

The probes can really give a different perspective on production
environments.

The patch has some nastiness to it that I'm sure people would want to
strategize on cleaning up. The main issue being that Apache is
constructed from a bunch of static apr/libtool built libraries.
DTrace doesn't work on archives. So, I've got some bloody knuckles
from bending the build system to keep things as normal ELF objects.

I had a first good step... and then a red herring issue that I worked
through with the DTrace team led me to a much less-elegant way of
building. I could revert to the original process (ld -r -o the objects
into library-esque packages) as DTrace can work on those.

The probes are neatly defined and placed, but the patches to the build
system are gruesome.

The apr-util patch to the apr_hooks.h is simple and affords some nice
probability for future probe uses.

Docs on these probes are available here:

https://labs.omniti.com/trac/project-dtrace/wiki/
Applications#Apache2.2.x

I'm not on this list -- Cc me on pertinent responses please.

Best regards,

Theo

--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
Attachments: apache-2.2.x-probes-p1.patch (25.2 KB)
  apr-util-hook-probes.patch (3.63 KB)


chip at force-elite

May 5, 2008, 11:44 PM

Post #2 of 6 (195 views)
Permalink
Re: [PATCH] DTrace probes patch. [In reply to]

Theo Schlossnagle wrote:
> Hello all,
>
> The probes can really give a different perspective on production
> environments.
>
> The patch has some nastiness to it that I'm sure people would want to
> strategize on cleaning up. The main issue being that Apache is
> constructed from a bunch of static apr/libtool built libraries. DTrace
> doesn't work on archives. So, I've got some bloody knuckles from
> bending the build system to keep things as normal ELF objects.
>
> I had a first good step... and then a red herring issue that I worked
> through with the DTrace team led me to a much less-elegant way of
> building. I could revert to the original process (ld -r -o the objects
> into library-esque packages) as DTrace can work on those.
>
> The probes are neatly defined and placed, but the patches to the build
> system are gruesome.

Uhm. yah. libtool-dep-extract, doesn't work with jlibtool.[1]

So, to get this to compile on OSX, I found out dtrace on OSX doesn't
have -G, and Apple says headers only/-h is enough. [2] Not having to
muck with the prelink steps makes this whole thing much easier to deal with.

For trunk, I had to mess around with http_request.c, as it seems the
2.2.x version is quite out of sync with trunk. (All due to the async
request processing work that happened in trunk).

The install-dtrace target is also slightly... worrying. For example:
@chown -R root:bin $(DESTDIR)/usr/lib
Seems like a bad thing for non-solaris operating systems, like OSX :-)

Attached is a patch for todays trunk, which seems to compile on OSX 10.5.

To get this in, I think we should make include/apache_probes.h a target
in the makefile, and not build it in configure.in. I'll try to get
something workong on OSX tomorrow and then hopefully someone can help me
with Solaris later,

> The apr-util patch to the apr_hooks.h is simple and affords some nice
> probability for future probe uses.

I've committed this patch to ARP-Util in r653681. [3]

I think we should add --enable-dtrace to APR{,-Util}'s configure.in, so
that we can wire up other things, and have a standard way of adding
things to the CPPFLAGS to enable it. (And to append those CPPFLAGS to
apr/apr-util's -config programs)

-Paul

[1] - http://svn.apache.org/repos/asf/apr/apr/trunk/build/jlibtool.c
[2] - http://archive.netbsd.se/?ml=dtrace-discuss&a=2007-10&m=5528648
[3] - https://svn.apache.org/viewvc?view=rev&revision=653681
Attachments: httpd-dtrace-trunk.patch (17.8 KB)


dirkx at webweaving

May 6, 2008, 5:21 AM

Post #3 of 6 (193 views)
Permalink
Re: [PATCH] DTrace probes patch. [In reply to]

On May 5, 2008, at 9:27 PM, Theo Schlossnagle wrote:

> The patch has some nastiness to it that I'm sure people would want
> to strategize on cleaning up. The main issue being that Apache is
> constructed from a bunch of static apr/libtool built libraries.
> DTrace doesn't work on archives. So, I've got some bloody knuckles
> from bending the build system to keep things as normal ELF objects.
>
> I had a first good step... and then a red herring issue that I
> worked through with the DTrace team led me to a much less-elegant
> way of building. I could revert to the original process (ld -r -o
> the objects into library-esque packages) as DTrace can work on those.
>
> The probes are neatly defined and placed, but the patches to the
> build system are gruesome.
>
> The apr-util patch to the apr_hooks.h is simple and affords some
> nice probability for future probe uses.
>
> Docs on these probes are available here:
>
> https://labs.omniti.com/trac/project-dtrace/wiki/
> Applications#Apache2.2.x
>
> I'm not on this list -- Cc me on pertinent responses please.

Works lovely on Solaris with the normal/real libtool - but not with
Justin's. On MacOSX I think there is something wrong with the linker.
Either MacOS does not need the extra -G or -h is enough on all
platforms.

What is the downside/penalty for making this a default ? Or should
this always be an optional thing - set at ./configure time ?

Dw.


mads at toftum

May 6, 2008, 6:04 AM

Post #4 of 6 (193 views)
Permalink
Re: [PATCH] DTrace probes patch. [In reply to]

On Tue, May 06, 2008 at 02:21:53PM +0200, Dirk-Willem van Gulik wrote:
> What is the downside/penalty for making this a default ? Or should this
> always be an optional thing - set at ./configure time ?
>
The whole point of dtrace is that there really shouldn't be a penalty
while no probes are being used. I'd prefer to see it on by default where
available, but still leaving an option to explicitly disable it.

vh

Mads Toftum
--
http://soulfood.dk


jesus at omniti

May 6, 2008, 7:10 AM

Post #5 of 6 (192 views)
Permalink
Re: [PATCH] DTrace probes patch. [In reply to]

On May 6, 2008, at 8:21 AM, Dirk-Willem van Gulik wrote:

>
> On May 5, 2008, at 9:27 PM, Theo Schlossnagle wrote:
>
>> The patch has some nastiness to it that I'm sure people would want
>> to strategize on cleaning up. The main issue being that Apache is
>> constructed from a bunch of static apr/libtool built libraries.
>> DTrace doesn't work on archives. So, I've got some bloody knuckles
>> from bending the build system to keep things as normal ELF objects.
>>
>> I had a first good step... and then a red herring issue that I
>> worked through with the DTrace team led me to a much less-elegant
>> way of building. I could revert to the original process (ld -r -o
>> the objects into library-esque packages) as DTrace can work on those.
>>
>> The probes are neatly defined and placed, but the patches to the
>> build system are gruesome.
>>
>> The apr-util patch to the apr_hooks.h is simple and affords some
>> nice probability for future probe uses.
>>
>> Docs on these probes are available here:
>>
>> https://labs.omniti.com/trac/project-dtrace/wiki/
>> Applications#Apache2.2.x
>>
>> I'm not on this list -- Cc me on pertinent responses please.
>
> Works lovely on Solaris with the normal/real libtool - but not with
> Justin's. On MacOSX I think there is something wrong with the
> linker. Either MacOS does not need the extra -G or -h is enough on
> all platforms.
>
> What is the downside/penalty for making this a default ? Or should
> this always be an optional thing - set at ./configure time ?


I see no issues with making this the default and having a --disable-
dtrace. I can see a reason that someone might wish to turn them off
-- thought that someone isn't me.

Note, that to get all the apr_hooks linked up (which allows timing
hook call-times and classifying system calls by hook name and phase)
we need to patch apr_hooks.h. The patch for that changes flow
slightly (but not outcome) and has no cost when disabled. Also, the
way I wrote that was to use another define to turn that on
"APR_DTRACE_PROVIDER". So, anyone using apr-util for hooks can enable
or disable probes on those hooks with that define.

--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/


Basant.Kukreja at Sun

May 13, 2008, 5:49 PM

Post #6 of 6 (140 views)
Permalink
Re: [PATCH] DTrace probes patch. [In reply to]

> I see no issues with making this the default and having a --disable-dtrace.
> I can see a reason that someone might wish to turn them off -- thought
> that someone isn't me.
+1
--disable-dtrace could be useful in certain scenarios e.g dtrace internal bugs.
IMHO, by default it should be enabled.

Regards,
Basant.

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.