Next area to investigate is CPU performance.
So what can you do to monitor CPU performance?
Well, of course, apart from the obvious thing like top command, which is revealing a lot
of information about CPUs, there is proc CPU info, which gives detailed information about
the CPUs, like flags that are supported.
If, for instance, you want to use hardware virtualization, you need to make sure that
either the SVM or the VMX flag is available, and proc CPU info will tell you about it.
Uptime is showing how long the system has been up, and it also shows load averages.
All the uptime output is also integrated in the top command output.
And SAR is a very convenient command that can be used to gather a long-time usage statistics.
The nice thing about SAR is that it gathers performance data every x minutes, and once
performance data has been gathered, you can analyze it using the SAR command, but you
need to enable it because by default it won't do anything.
And finally, there are CCTL interface parameters in slash proc to tune different CPU-related
settings.
Let me show you.
So to start it, I'm going to show you systemd timers.
Let me use systemctl list unit files minus t timer.
And what I'm looking for is the sysstat collect timer.
So what is in the sysstat collect timer?
Well, let's use systemctl get on sysstat collect dot timer.
And there we can see that this is a job that is running every 10 minutes to collect information
that the SAR utility is using.
Now, the critical question here is what time is it?
It's 1.33.
Good.
Now, I installed the SAR utility earlier when I've shown you the iostat command output.
And that means that I'm expecting this sysstat utility to have collected some data.
If you go in the var log directory, then you can find an SA subdirectory.
And this SA subdirectory is a directory that is normally filled by the sysstat collect
utility.
And oh, boy, I can see no files in there.
What does that mean?
It means that SAR minus uppercase A, which is a good start.
Well, as you can see, it's telling me it cannot open var log SA SA11 no switch file or directory.
It's looking for a file, but the file does not exist.
So apparently, data collection has not been happening yet.
If I want to know more about it, then I can use systemctl status on sysstat collect dot
timer.
And there we can see that it is, oh, it is enabled, enabled, and active.
It is inactive and triggers sysstat collect service.
Well, apparently, it just hasn't started yet.
But you know what?
We can also start sysstat collect service manually.
So systemctl start on sysstat collect dot service is going to run the process for me
manually.
So now that the sysstat information is starting to gather, we need to give it a little bit
of time.
So let's have a look at the proc parameters.
In slash proc slash sys, you find information about tunables.
And these kernel tunables, well, there's a couple of tunables for CPU as well.
You find them in proc sys kernel, because in the end, the Linux kernel determines what
the CPU is doing.
And here you can find a couple of these options, which are the scheduler options.
The scheduler determines how much time every process gets that wants to do something on
the CPU.
So how does it work?
Well, let's say that you want to change the amount of time for your SCAD RT runtime microseconds.
Now first, let's investigate what is in there.
So we have SCAD RT, which is for real-time processes.
And every real-time process is getting this amount of microseconds as its runtime, meaning
that the remaining amount of microseconds on a second is for all the other processes.
And if you think this is too much or not enough, you echo the new value into the file.
So echo 900,000 greater than SCAD RT runtime US.
And that will set the setting right now.
And if you're happy with it, you can make it persistent using sysctl, as we have discussed
before.
So how does that work?
Well, I would suggest you do the following.
You copy the SCAD RT runtime US, because that's a difficult parameter name, isn't it?
Well, here we have it copied.
Now I'm going into etc.sysctl.d.
And there we have the 99.sysctl.conf.
And you can just add it to this.
So what am I going to edit?
Well, I am going to edit kernel.parameter that I want to change equals the value that
I want to give to the parameter.
And that makes sure that next time your system is started, the sysctl service is picking
up the value.
And in case you forgot the exact naming of this parameter, well, this here is a relative
file name.
It's a relative file name where the dot is used as a separator.
And it is relative to the slash proc slash sys directory.
So this will make it persistent.
Now let's get back to SAR.
SAR minus minus help is showing all the different SAR utilities.
And as you can see, many, many command line options are available.
Here we can see the minus U option.
After all, we're talking about CPU utilization.
So SAR minus U all should show information that has been gathered about all of my CPUs.
So a little bit of troubleshooting about this service collection.
If you do a sysctl cat on sysstat collect.service, you can see what it is actually doing.
And here you can see that this is one shot.
So it will run it once.
And what it runs is uselib64sa1, et cetera.
So if you just copy this command and you run it manually, then the result is that it is
going to gather some system information for you.
Now the timer is doing this every 10 minutes.
But if you're impatient and if you don't want to work, this allows you to get started.
And next, you can use your SAR command.
So SAR minus minus help is giving all these different options.
Maybe a good way to get started is by using CPU information only.
That will be minus U all.
So try SAR minus U all.
And here you see the statistics over time that have been gathered for your CPU utilization.
So what do we see?
Well, we see the user and the nice and the system space.
And it is capturing this information every 10 minutes.
And that is useful because if every day you want to know which are your peak moments and
your low moments, well, you can clearly figure out if there are moments when your CPUs are
hit harder than at other moments.
And that is how SAR can be an absolutely very useful utility.