David, Thank you for taking the time to expand this. Your argumented perspective is something i was looking for. The internet has a lot of info about disros but was very hard to converge on one.
On Friday, July 12, 2019 at 2:40:29 AM UTC-4, David wrote: > > I can't speak for Java work (which this group seems largely based around), > but for systems work in C there is very little to look out for: > > 1) a distro you can also use in production > 2) a kernel release you can use in production > 3) a matching build of the 'perf' binary for the kernel you can use in > production > 4) debug symbols for every component you might happen to touch > 5) matching development headers for your kernel and every component you > might happen to touch. > > In order: > > 1) is important because there is little point in profiling if you're > profiling the wrong code, and most probably reduces your choice to one of > RHEL, CentOS, Debian, Ubuntu or SuSE, especially if you are working as part > of an organization and someone is making this choice for you, or it has > already been made long ago. > > 2) unless you really, really know what you are doing, and have a double > digit percentage of time available to manage it, you almost certainly want > to stick with the distro-provided kernel to start with. There are many > reasons to consider managing your own kernel config, but a stock kernel is > probably good enough, and significant flexibility (like isolcpus=) is > possible already through command line parameters without ever needing a > custom build. > > 3) Linux has a huge variety of profilers available, but it seems since the > introduction of perf the desire to use any other tooling basically > disappears. Perf is annoying because its version really wants to be exactly > matched to the kernel version you are running, and so whoever ships that > kernel must also provide perf. Any reasonable Linux distro will ship a > matching perf, but many smaller distros might goof this up. At least it > used to be true that Debian's perf (in the linux-tools package) was not > always matched. > > 4) Perf is vastly more useful when it can print symbols. I only know of 2 > distro families with mostly-complete to fully complete symbol repositories: > RHEL/CentOS and Debian/Ubuntu. In Debian land most packages have a > corresponding "-dbg" package after activating the repository, in Red Hat > these are spelled "-dbginfo". Most smaller distros completely punt on > providing comprehensive debug symbols, making it much harder to profile any > app that inherits any libraries from the base system > > 5) Some fancier new tooling like bpftrace is so fresh that it requires > building stuff from source against matching kernel headers, and in other > cases (projects like SystemTap), may want to build kernel modules where you > might need the full kernel source tree in use. I think most distros ship > this kind of stuff, but it's worth ensuring you know where to find it and > how it is installed > > > On Friday, July 12, 2019 at 2:53:24 AM UTC+1, Ruslan Rusu wrote: >> >> Hi here, >> >> I'm a beginner in this space. As I read and learn was curious what is the >> most friendly linux distribution >> which is a good if you want to learn about how to track and observe >> resource utilization. I searched this >> list and did not find anything on this topic. >> >> Googling around found a couple of commercial distributions RedHat, Suse >> which have developer licenses >> programs. The binaries under this program are the same as what runs in >> enterprise license. >> >> As professional what would you recommend if you had to start again ? >> >> Appreciate it >> > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/7263efa2-47f6-49b6-a271-3cbead58d347%40googlegroups.com.
