

Linux Ftrace TCP Retransmit Tracing - akerl_
http://www.brendangregg.com/blog/2014-09-06/linux-ftrace-tcp-retransmit-tracing.html

======
suprjami
> I really should be using a programmable tracer like SystemTap

I was gonna say, I have done exactly this using SystemTap.

Looking at your script, stap has a lot more "batteries included" so such a
script ends up being a lot shorter.

Even with a custom guru-mode function to pull more data out the skb, such as
window size or retransmission timer, it's easy to do this in under 30 lines
using SystemTap.

SystemTap also has the advantage of being able to modify data in the running
kernel, not just read it. I haven't used this a great deal, but some other
guys at work have used it to reproduce corruption bugs which would otherwise
take months to re-appear.

~~~
brendangregg
It's borderline. While this is a hack, ftrace and kprobes are built-in to the
kernel, and are immediately available on all our production Ubuntu and CentOS
instances. And /proc/net/tcp is usually still valid for long-running sessions
with retransmits. I'll install and use SystemTap when there's no other
practical way.

I wrote some other TCP scripts using ftrace, and the caching of /proc/net/tcp
approach didn't cut it (due to short-lived sessions, which were too often
missing by the time /proc/net/tcp could be read), and I'll need to rewrite
them in SystemTap (or something else). Those make much better examples of why
SystemTap. I'll publish them when I get a chance.

~~~
suprjami
I do like your method in that it doesn't require anything additional
installed, that's a big advantage.

Sometimes SystemTap isn't an option because of various restrictions, such as
long-winded change control or simply not allowing compilers on production
systems. Plus debuginfo packages just seem to confuse people.

------
molixiaoge
get it

