Regardless of how you look at it, the question of memory usage remains critical to the life cycle of a system, and whether you are maintaining system health or troubleshooting a particular service or application, you will always need to remember that the use of memory is a critical resource to your system. For this reason, we will begin by calling the free command in the following way:

# free -m

The main elements of the preceding command will look similar to this:

         Total    used    free    shared    buffers    cached
Mem:      1837     274    1563         8          0       108
-/+ buffers/cache: 164    1673
Swap:     2063       0    2063

In the example shown, I have used the -m option to ensure that the output is formatted in megabytes. This makes it easier to read, but for the sake of troubleshooting, rather than trying to understand every numeric value shown, let's reduce the scope of the original output to highlight the...

A different aspect of memory management can be achieved by using the vmstat command. Considered to be a summary reporting feature associated with memory, processes, and paging, vmstat can be seen in action by typing:

# vmstat -a

Having used the -a option to call on all active and inactive memory, the most endearing columns shown under vmstat's output are best described as follows:

The display does look quite confusing to begin with, but for our purposes, we want to concentrate on the following columns contained under the swap column:

free           si   so
1645452          0    0

Where free shows the current allocation of free memory, si shows page...

The top command can be called at any time by typing:

# top

The top command is the standard command for checking system load (RAM/MEM and CPU). It contains a lot of information related to tasks associated with the kernel; the display is updated in real-time and the highest load factors are expressed as a percentage of CPU or MEM. However, it is important to realize that top may take these values above the expected percentile range. This is because all individual cores are expressed as a percentage and multiple instances of these cores are totaled. For example, a dual core system may have the first core at 70 percent and the second core at 60 percent, and in this instance, top may show a combined result of 130 percent, but you will not know the individual values.

You can use the M key to sort top by memory, but as you will see, rather than simply showing the amount of free memory (as seen with the free command), top will provide the swap details...

Every administrator knows that a system can begin to slow down as a result of heavy disk I/O activities. However, in the role of a troubleshooter you will probably want to know which processes or (in the case of multi-user systems) which users are the culprits that and it is for this reason, you will want to turn to iotop—a tool that shows a list of the most I/O intensive processes in real time in a top-like interface.

To begin with, you will need to install iotop by typing:

# yum install iotop

The download is only small, and to start a discovery session, simply use the following command:

# iotop

Running iotop without any arguments will result in a list of all existing processes regardless of their disk I/O activities, so if you want iotop to only report on processes that are committed to disk I/O activity, you should use the following instead:

# iotop –o

The output is verbose as it works in a way similar to the top command, so familiarity should make you feel...

For most troubleshooters who want a more complete picture of the processes running on their system, we can employ the ps command in the following way:

# ps aux | less

Alternatively, the information can be displayed in a user-friendly, tree-view mode like this:

# ps axjf | less

If you prefer a little less detail, try:

# ps auxf | less

Of course, there are always a lot more options that we can use with ps. For example, the command can be piped and applied with grep or tail, and you can use explicit statements such as ps -e (to show every process on the system). Alternatively, you can target a specific process by typing the following command:

# ps aux | grep <process_name>

Moreover, you can even extend its usage to show every process (except those running as root) with the following variation:

# ps -U root -u root -N

For a specific user, you can use:

# ps -u <username> u

Finally, you can then obtain additional security information and output...

Having already discovered how vmstat can be used to provide statistics related to memory management, when troubleshooting performance-related issues an overburdened CPU is yet another area of concern. For this purpose, we can use the iostat command like this:

# iostat

However, to display a more interactive CPU utilization report, you can use the –c option (and provide a numeric value measured in seconds, such as 5 seconds) like this:

# iostat –c 5

Most of the columns should be self-explanatory, but if the system is getting busy, you will see an increase in %iowait, which is used to report on an increase in waiting time for any I/O requests to be completed. Based on this, if the server is transferring or copying a large amount of files, you may also notice additional time being spent at the system level as files will be moved in and out of relevant disk partitions. A feature that is particularly useful when attempting to monitor storage devices in...

The system load is a measure of the amount of processing a computer system is currently performing. It is not the perfect way to measure computer performance, but it does provide the troubleshooter with the additional evidence they need to fix a system.

The expression most commonly associated with calculating load is:

Actual Load = Total Load (uptime) / Number of CPUs

As you probably know the number of CPUs, you can calculate the uptime by reviewing the results of the top command or by typing:

# uptime

The output of the preceding command may look like this:

09:59:41 up  2:36,  1 user,  load average: 0.01, 0.02, 0.05

The server load is expressed as a value based on 1 minute, 5 minute, and 15 minute read times. So, by looking at the final three values in the preceding output, we can see that, for this system, the average load was 0.01 (at 1 minute), 0.02 (at 5 minutes), and 0.05 (at 15 minutes).

At this current time, the example system shows no sign of fatigue, but...

Rather than using ps, another way of discovering a specific process ID is to use the pgrep command like this:

# pgrep <servicename>

In most cases, the use of this command will reveal the process ID or PID. However, by using this approach, it is also possible that the output will provide more than one value. So remember, if an application (such as httpd or ssh) provides one or more process IDs, you can safely assume that the lowest number (which represents the first PID generated by the system) is the most important. This value is known as the PPID or parent process ID.

On the other hand, a more succinct method could be based on taking advantage of systemd by using the following command:

# systemctl status <service_name>.service

The output of the preceding command will look similar to the following sample, and as we can see, the main PID for Apache is 2413:

httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd...