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/5563732d-bbf2-422b-9519-a8d7959a9b09%40googlegroups.com.
