Packages for performance - Linux Tutorial

- [Instructor] Let's talk about packages of software that have performance-related tools. When we talk about packages for Linux we got to realize that different Linux systems can have different kinds of packaging. There's two most common package systems, package formats for Linux; that's the RPM format and the Debian format. Debian packages are used on Ubuntu and Debian derived systems, and RPM is used on RedHat and RedHat related systems. My few examples here will use RPM packages. There are similar commands for Debian packages. You have commands like apt-get and dpkg for Debian packages, and you have commands like yum, rpm, for RPM packages. So there is a package called gnome-system-monitor, and it might have a name like gnome-system-monitor-3.14.1-4.el7.x86_64. So one of the things to keep in mind is packages are made for versions of Linux. So it's safest if you get the one that matches the distro. So each time there's a new distribution release of RedHat or Ubuntu or CentOS or whatever, they have all new packages that might have new versions of the software. So you generally want to get those matched, and you got to get the architecture matched, too. like this is x86_64. And typically, the bigger the number, the better, because it's a newer version of the package. The gnome-system-monitor, we'll see a screenshot here, is a cool little GUI tool that shows you a refreshed display of some activity on your system. So sometimes just that simple stuff gives you an idea of what's going on. And you could do that on a remote system to see if their CPUs are busy, say. Another important package related to performance tools is called sysstat. And it's got a variety of utilities, the cifsiostat. Cifs is the remote file system that you use to mount remote folders for Microsoft Windows systems. Iostat is generally general io stuff. Mpstat, for multi-processor. Nfsiostat from the sysstat. Nfs is the Unix way of doing remote folders. And then we got stat on pid, and we've got the system activity reporter, sar. So sar, in particular, is very complicated with lots of options and you can get lots of information. So these sorts of tools are really valuable when you're trying to improve performance so that you can get data on what's going on. And then there's another package, the procps next generation package, that has the ps command, for example, that most people are familiar with. And another simple command, free, to give you information about free memory. And some other utilities that you might want to look into. And we'll look at a couple of those. And then we have the command perf, which will tell you information about what subroutines have consumed the most time in the system when you ran something. And that could be subroutines in the kernel, in a library or in a program. So sometimes that's a really good way of finding bottlenecks. It can be pretty arcane, but still might be a good hint. So for example, here we ran the command find / and we said stay in the same file system, don't go to another disk or whatever, looking for all files named core. So that's going to generate a lot of disk activity. And we're going to redirect the output of that find command into dev/null, and then that other syntax, two greater than ampersand one, says send standard error, error messages, to the same place as standard output, which is dev/null. So that's a little bash trick there. So we run that command with perf, and we want to be root with that, so we do a sudo. And then when we're done, perf report had created a data file, we generate a report and that's what we see in that screenshot. Let's just try that live, just so you can see it again. So let's go to slash, and let's try a perf command. So we're going to say sudo perf record. And then we're going to run a command, and perf is going to be gathering time information spent in functions while this command runs. And find is a pretty good one, because it calls a fair number of things, including in the kernel. And again, we're going to tell find to start at slash and stay in the same file system. This time let's look for something else. We'll look for ls, and we'll just let the output show up in the terminal window here. And because I did a sudo, it wants my password. There we go. So we got a little bit of information that ran pretty quick. And now let's get the report. And there we got it. Nothing really dominated. The top function took 4.29% of the time, and kernel.kallsyms meant it was in the kernel and it was a function called filldir. Toward the bottom of the screen we see malloc, which is a well-known function, and that took a little over 1%. That's a pretty common one to show up and to keep in mind, because often times dynamic memory allocation is a bottleneck is programs. And I got out of that with q to quit.