Re:Scaling Linux Services: Before accepting connections
by bashook on Saturday July 04, 2020 @11:37AM
(#23732971)
Thanks Brendan for all your work on performance analysis and BPF. I cite your work often to team mates. Your work is an invaluable resource. Seeing responses on Hacker News like this is why I keep coming back here.
Re:Scaling Linux Services: Before accepting connections
by theojulienne on Saturday July 04, 2020 @01:19AM
(#23730318)
Thanks for the suggestion! I did come across the `tcpsynbl.bt` script as I was writing up this post, but wanted to add the additional information around namespaces and report additional information, which didn't seem as trivial in `bpftrace` as it was in Python, but that might be my lack of familiarity with the DSL :)
Re:Scaling Linux Services: Before accepting connections
by brendangregg on Saturday July 04, 2020 @02:30AM
(#23730563)
If it's a common use case it's trivial, and if it's not yet trivial we'll make it trivial. :) Niche functionality that doesn't fit well can be deferred to BCC.
Re:Scaling Linux Services: Before accepting connections
by easytiger on Saturday July 04, 2020 @02:07AM
(#23730484)
A lot of the world still have to use RHEL 6b etc and don't have these tools available
Re:Scaling Linux Services: Before accepting connections
by Twirrim on Saturday July 04, 2020 @05:43PM
(#23735109)
Just a general observation, if you're on RHEL6 you've got around 4 months left until End of Life. (I know, there are folks out there still running CentOS 4 and prior)
Re:Scaling Linux Services: Before accepting connections
by easytiger on Monday July 06, 2020 @06:06AM
(#23746264)
This is not quite accurate. Large institutions with very slow processes and onerous governance will be very much tied to RHEL 6 for some years. It indeed is a very important part of Redhat's business model. Enterprises will purchase extended support for RHEL 6 going up to 2024
Here's my bpftrace SYN backlog tool from BPF Performance Tools (2019 book, tools are online[1]):
The source: This bpftrace tool is only 24 lines. The BCC tools in this post are >200 lines (and complex: needing to worry about bpf_probe_read() etc). The bpftrace version can also be easily modified to include extra details. I'm summarizing backlog length as a histogram since our prod hosts can accept thousands of connections per second.[0] https://github.com/iovisor/bpftrace [1] https://github.com/brendangregg/bpf-perf-tools-book