Hello!
On Mon, Jul 14, 2014 at 5:40 AM, Stefan Parvu wrote:
> The very first signs of DTrace on FreeBSD are since 2005 or 2006, if Im not
> wrong.
> Currently there are some providers missing comparing to Solaris.
There were 2 major limitations in dtrace (including dtrace on Solaris)
the last time I checked:
1. Lack of automatic dwarf debuginfo inspection for userland tracing
(it seems that latest dtrace has CTF debuginfo, but you need to get
your compiler to emit CTF. See
http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace/).
2. Lack of looping control flow in the D language. Quite some of my
existing tracing tools have walk through C-land data structures of
varying depth.
>
> But things are improving and for example node.js has nice support for it.
> https://blog.indutny.com/7.freebsd-dtrace
It patches the FreeBSD kernel and is just for USDT. I won't consider
it "nice support" according to my own definition :)
> - I havent looked over your work
> on
> USDT probes - but I will.
The C-land USDT in openresty's nginx should work with both systemtap
and dtrace on FreeBSD, Mac OS X, and Solaris (all tested on my side
for long).
But static probes defined are almost always insufficient and that's
why most of my existing tools in nginx systemtap toolkit and stap++ do
not make use of USDT at all.
>
> DTrace is a nice and powerful language found on many systems by default.
> Systemtap is not.
systemtap has been specific to Linux from day #1. But it does not mean
it does not provide a nice and powerful language :)
My focus has been on Linux because the production systems at $work
have been Linux only. In retrospect, I also feel lucky because the
recent Linux kernels and systemtap fits my advanced requirements
pretty well while I did not have much success with dtrace in other
systems. I might be biased here given that I am also a systemtap
contributor.
I'd love to port my tools over to dtrace if dtrace solve those two big
limitations mentioned earlier. They're quite a showstopper for me.
> but I stopped using systemtap on Linux because: system
> hungs,
That's interesting. We've been frequently using systemtap in our
global network for almost 2 years now and we've never seen such
horrible things :)
Did you report your problems to the systemtap team? The systemtap
developers are very responsive and helpful according to my experiences
:)
> long
> time to get it installed
No longer true for recent Linux kernels (3.5+). Right now in most
Linux distributions it is as simple as a single command installing the
prebuilt systemtap package. Even building systemtap from source is
easy (you only need one dependency, elfutils):
http://openresty.org/#BuildSystemtap
> So now we are off Linux (debian 7) to FreeBSD 10. Super performance and
> stability vs
> Debian systems. OpenResty comes very handy and I need to find time to
> enhance the
> troubleshooting part for it and DTrace on FreeBSD.
Contributions on this part is very welcome :)
> It depends. If you plan to observe and measure your system under a certain
> load then you
> are in troubles. You will be troubled by the OS performance metrics between
> Linux vs FreeBSD
> for example being different.
Sure. Ideally we always trace the same operating system. I was just
talking about a practical work-around that can help find many userland
bottlenecks. Theoretically we may always run into some stupid slow
primitives in certain specific operating system. Most of the time the
userland computation performance is more related to your CPU model and
C compiler/C runtime implementations anyway. (If you're focusing on
scheduler or syscall performance, then it is another story.)
Regards,
-agentzh
