Re: [PATCH] DTrace probes patch.
> 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.
Re: [PATCH] DTrace probes patch.
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/
Re: [PATCH] DTrace probes patch.
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
Re: [PATCH] DTrace probes patch.
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.
Re: [PATCH] DTrace probes patch.
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
Index: Makefile.in
===
--- Makefile.in (revision 653681)
+++ Makefile.in (working copy)
@@ -16,7 +16,7 @@
TARGETS = $(PROGRAMS) $(shared_build) $(other_targets)
INSTALL_TARGETS = install-conf install-htdocs install-error install-icons \
install-other install-cgi install-include install-suexec install-build \
- install-man
+ install-man install-dtrace
DISTCLEAN_TARGETS = include/ap_config_auto.h include/ap_config_layout.h \
modules.c config.cache config.log config.status build/config_vars.mk \
@@ -28,6 +28,12 @@
include $(top_builddir)/build/rules.mk
include $(top_srcdir)/build/program.mk
+install-dtrace:
+ @echo Installing DTrace library
+ @$(MKINSTALLDIRS) $(DESTDIR)/usr/lib/dtrace
+ @cp $(top_srcdir)/ap.d $(DESTDIR)/usr/lib/dtrace
+ @chmod 0644 $(DESTDIR)/usr/lib/dtrace/ap.d
+
install-conf:
@echo Installing configuration files
@$(MKINSTALLDIRS) $(DESTDIR)$(sysconfdir) $(DESTDIR)$(sysconfdir)/extra
Index: server/Makefile.in
===
--- server/Makefile.in (revision 653681)
+++ server/Makefile.in (working copy)
@@ -61,7 +61,7 @@
for dir in $(EXPORT_DIRS_APR); do \
(ls $$dir/ap[ru].h $$dir/ap[ru]_*.h >> $$tmp 2>/dev/null); \
done; \
- sort -u $$tmp > $@; \
+ sort -u $$tmp | grep -v apache_probes.h > $@; \
rm -f $$tmp
exports.c: export_files
Index: server/protocol.c
===
--- server/protocol.c (revision 653681)
+++ server/protocol.c (working copy)
@@ -842,9 +842,11 @@
apr_socket_t *csd;
apr_interval_time_t cur_timeout;
+
apr_pool_create(&p, conn->pool);
apr_pool_tag(p, "request");
r = apr_pcalloc(p, sizeof(request_rec));
+AP_READ_REQUEST_ENTRY((intptr_t)r, (uintptr_t)conn);
r->pool= p;
r->connection = conn;
r->server = conn->base_server;
@@ -894,11 +896,12 @@
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
apr_brigade_destroy(tmp_bb);
-return r;
+goto traceout;
}
apr_brigade_destroy(tmp_bb);
-return NULL;
+r = NULL;
+goto traceout;
}
/* We may have been in keep_alive_timeout mode, so toggle back
@@ -921,7 +924,7 @@
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
[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/ apache-2.2.x-probes-p1.patch Description: Binary data apr-util-hook-probes.patch Description: Binary data
