#dtrace — Public Fediverse posts

If you are using #DTrace on #FreeBSD, then I've got good news for you.

I've added a new manual to FreeBSD. It's called d(7) and it is a short reference of the #D scripting language. Currently, it covers only a subset of all variables and functions, but we'll add more iteratively.

Here are some previews for you:

HTML: https://people.freebsd.org/~0mp/d.7.html

MDOC (view with man(1)): https://people.freebsd.org/~0mp/d.7

Have fun tracing your systems!

#osdev #tracing #foss #mdoc

@mhoye
#SystemTap or #DTrace might offer what you are looking for
https://sourceware.org/systemtap/wiki
https://www.brendangregg.com/dtrace.html

@mhoye
#SystemTap or #DTrace might offer what you are looking for
https://sourceware.org/systemtap/wiki
https://www.brendangregg.com/dtrace.html

@mhoye
#SystemTap or #DTrace might offer what you are looking for
https://sourceware.org/systemtap/wiki
https://www.brendangregg.com/dtrace.html

@mhoye
#SystemTap or #DTrace might offer what you are looking for
https://sourceware.org/systemtap/wiki
https://www.brendangregg.com/dtrace.html

@mhoye
#SystemTap or #DTrace might offer what you are looking for
https://sourceware.org/systemtap/wiki
https://www.brendangregg.com/dtrace.html

While we could add a bunch of CHECK_PORTABILITY_SKIP entries to skip these files, I prefer to fix things properly, and so have committed a general fix for this which should speed up most packages.

https://github.com/TritonDataCenter/pkgsrc/commit/df1af49c2953c235c8af501a53f13cdfa5bbf91c

Nice reduction in runtime from 86 seconds down to just 1!

If anyone has access to really old systems and are able to tell me if they do not have "read -n" then that'd be hugely appreciated, though it's likely we'd bootstrap #mksh on them anyway.

#pkgsrc #dtrace

Ready for #FOSDEM #illumos #pkgsrc #dtrace #omniosce #tribblix

It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.

I use it all the time, and struggle when working on other systems that do not have it. Only yesterday I wrote a quick script to verify a code path that lead to this fix: https://github.com/NetBSD/pkgsrc/commit/def71d1c1f988e3a2cf3bb86716a2937ce6f48fc.

It has found significant performance wins in #pkgsrc and #pkgin, fixed numerous bugs, and helped me understand systems.

Thanks @bcantrill and @ahl!

As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.

http://mail-index.netbsd.org/tech-pkg/2023/08/07/msg027952.html

This is in addition to the 13x speedup I committed a few years ago:

https://gist.github.com/jperkin/98550d5bd07f4179ebfeea825fc3ec20

Reviews appreciated. #pkgsrc #netbsd

#FreeBSD30 timeline - a few things that happened during these 30 #FreeBSD years:

#UNIX #BSD #MULTICS #1BSD #2BSD #42BSD #43BSD #386BSD #ipfw #FreeBSDCon #BSDCON #ports #jails #FreeBSDFoundation #kqueue #EuroBSDCon #CoreTeam #AsiaBSDCon #BSDCAN #pf #OpenBSD #ZFS #DTrace #VNET #Capsicum #Cheri #Poudriere #clang #llvm #subversion #OpenZFS #git

#FreeBSDDay

https://freebsdfoundation.org/freebsd/timeline/

After some more #DTrace analysis and code reading, found another easy optimisation win in the pattern matching code, for a further 2x speedup.

Next up some database optimisations which will hopefully get us to around 8x combined speedup, as well as helping with future development work.

#pkgsrc #pkgin

After maintaining #pkgin for a few years, there's still a bunch of low-hanging fruit for cleanup and optimisation.

While working on SUPERSEDES support, I was curious as to why the dependency calculation takes so long.

Re-ran it with #DTrace, saw break_depends() taking up 55% of the runtime. What does it do?

Turns out, nothing. Various changes over the years, notably refresh support, have made its calculations obsolete.

Nice easy 2x performance win and much easier-to-understand code path.

@sjmulder The answer is #DTrace, start with something like execsnoop but keep a track of parent/child relationships and how long the processes ran for, then use the tools in the #FlameGraph repository to convert the text output to an SVG.

So things are getting bad, and #cloud is being considered more complex to manage and more costly.
I have to admit that while I really believed in the cloud, the problems that my customers were facing started to break my beliefs.
Ops costs increased, because they still hired the IT guy, but now a #SiteReliabilityEngineer costs way more than a traditional #SystemAdministrator, and often he has an #infra knowledge way inferior, since everything is not in house anymore. Everything is hosted and you don't access to the technology internals anymore.
Also, they are dealing with a level of complexity unheard of.
Before the cloud there were only physical and virtualized layers of complexity.
Now we also have then #containerorchestration and #servicemesh layers.
We moved from putting a stupid #Java class in classpath to run #JBoss with the #APM profiling to running #Prometheus, #Grafana, #Jaeger and #Kiali to obtain the same level of informations.

The only good thing is that now in Linux engineers are using #eBPF to profiling network and software execution.
But this is NOT innovation at all. You could do that already with #DTrace in #Solaris and #FreeBSD with way less complexity, and the same level of profiling since #Java, #Ruby and lot of frameworks included its probes to support advanced tracing.
Apple's #macOS used to provide a good #DTrace frontend called #Instruments that was really cool to work with.

https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0