Unlike with Windows, in Linux having a desktop is optional. I would not suggest you try to get end users to work without a desktop. That would be problematic on several levels. To begin with, it would require all end users to be proficient in the shell commands, as well as shell-based editors. But beyond that, there are a number of open source products available for the desktop that are very useful for end users—things like Open Office. Personally, I would not want to do without my favorite browser or desktop-based email client; however, these things are not needed on most servers. It is usually a good idea to install your server (Web server, DNS server, and so on) without even installing a desktop at all. This alone will free up a great deal of RAM and CPU time. The various desktops all consume a lot of system resources, and they often are not necessary on a server.

Anything that is running consumes resources. So any daemons running in the background that you don’t need are still consuming CPU time and RAM. Turn them off, or uninstall them altogether. On a special purpose server, you only need those daemons required by that server.

In addition to the performance bonus you will get from doing this, you get a security benefit. Any daemon that is running has the potential (even if it is remote) of being exploited by an attacker. Put another way, every door or window on a building is a potential way into the building. The same is true of daemons on your server. If you do not need them, turn them off.

In past chapters, you have already seen a few monitoring shell utilities, such as top and uptime. In this section, we will look in depth at a few more advanced tools. Some of these may not be installed on your particular Linux distribution. If they aren’t, then you can simply install them. Note that in some distributions, these various shell utilities come in a common package. For example, in Debian, you install sysstat, like this:

apt-get install sysstat

And that will install many of the shell utilities we are about to discuss, including vmstat and iostat.

vmstat

The command vmstat will report statistics regarding your system’s use of virtual memory (see Figure 19.1). The name is an abbreviation for virtual machine status.

Figure 19.1. Using vmstat.

This command will report what processes are currently accessing virtual memory, CPU activity, and related data. It will, by default, display data averages since the last reboot. However, like all shell commands, there are flags you can use to alter how this command behaves. Let’s take a look at some of these:

• -a: This flag will display active and inactive memory usage.

• -d: This flag reports disk statistics. This is rather detailed information showing usage down to the sector level.

• -f: This flag displays the number of forks since the last reboot. A fork is a command that creates a child process. Many programs create child processes in order to perform certain functions.

• -p: If this flag is followed by a specific partition name (such as /hdl), then it will display statistics for that partition.

• -s: This is actually my personal favorite flag. It displays information about total items swapped in and out of virtual memory, how much total memory is available, how much is used, and so on (see Figure 19.2).

  

  Figure 19.2. The -s flag for vmstat.

iostat

This command reports statistics about the loading and unloading of various devices (including drives) and CPU usage (see Figure 19.3).

Figure 19.3. Using iostat.

As with many of the other status commands, this one reports the data since the last reboot. There are several headings in the output that need to be explained:

• %user: This is the percentage of loading and unloading that was initiated from user space (as opposed to kernel space).

• %nice: The term nice, refers to priority level. This heading shows the percentage of loading and unloading that occurred from user space, using the nice priority.

• %system: This is the percentage of loading and unloading that was initiated from kernel space (for example, by the operating system itself).

• %iowait: This shows the amount of time that the system was idle but had input/output requests pending. In other words, how often did other system components have to wait?

• %idle: This is closely related to %iowait. It will tell you the percentage of time the CPU was idle with no requests pending.

As you can probably surmise, there are a number of options with this particular command. A few of the most common are:

• -d: This option causes the command to display only the device utilization report without CPU information.

• -c: This flag is just the opposite of -d. It causes the command to display only the CPU utilization and to omit the device utilization report.

• -t: This is a very useful option. It causes the command to display the time for each item.

• -k: This can be useful in many circumstances. It causes the iostat command to display kilobytes rather than blocks used.

mpstat

This command is an abbreviation of multiprocessor status. It was designed to give information on various processors in a multiprocessor server; however, even if you have a single processor, it will provide useful data (see Figure 19.4).

Figure 19.4. Using mpstat.

Like iostat, the display of mpstat requires some explanation. It may not be immediately obvious to you what the various headings are, although many are almost identical to the iostat headings:

• CPU: This is the processor number (in a multiple processor system). In a single processor system, all you will see under this heading is all.

• %user: This heading shows the % of CPU utilization that occurred in user memory space.

• %nice: This will show you the % of CPU utilization that occurred in user memory space and was at the nice priority.

• %sys: This shows you the % of CPU utilization that occurred in system or kernel memory space.

• %iowait: This shows the amount of time that the system was idle but had requests pending. In other words, how often did other system components have to wait?

• %idle: This is closely related to %iowait. It will tell you the percentage of time the CPU was idle with no requests pending.

• %irq: This heading shows the amount of time the CPU spent handling interrupt requests.

This command, like all the others you have studied in this book, has optional flags but only two:

• -P: This allows you to identify a specific CPU to get statistics for. This can be particularly useful in the case of multiprocessor systems when you are interested in statistics for a specific CPU.

• -V: This will display version information.

pmap

This command, process map, gives information about a specific process. You must know the process id in order to use pmap, but that can easily be found with commands like ps (see Figure 19.5).

Figure 19.5. Using pmap.

This command has only a few flags that can be used with it:

• -x: This affects formatting, and it causes the display to be in extended format.

• -d: This affects formatting, and it causes the display to be in device format.

• -q: This is the quiet display, and it shows minimal data.

• -V: Like mpstat, this shows information about the version.

The pmap command is often used to determine exactly how much memory a given program is using and how it is using that memory. When you are running any type of server, it is very important to know what programs are your most significant memory users. This will be invaluable information when optimizing the system.

These are not the only shell commands that can be used to monitor your system, but they are among the most frequently used.

The GNOME system monitor is a handy tool if you are working from within the desktop. You find it under System → Administration → System Monitor (see Figure 19.6).

Figure 19.6. GNOME System Monitor.

The System tab (see Figure 19.7) gives you a general overview of the system.

Figure 19.7. GNOME System Monitor System tab.

Here you will see the processor information, free disk space, and information about the Linux kernel and the version of GNOME being used on this system.

The Processes tab provides process information. This is all the information you might get from ps, pstree, and top (see Figure 19.8).

Figure 19.8. GNOME System Monitor Processes tab.

You can sort by any of the headings (% CPU, Process Name, etc.), and you can end a process from this screen (essentially the same as the kill command in the shell).

The Resources tab shows general resources utilization (see Figure 19.9). This is a basic overview of the current state of the system: how much CPU is being utilized, how much RAM is currently being used, and so on.

Figure 19.9. GNOME System Monitor Resources tab.

The File Systems tab (see Figure 19.10) is the simplest. It simply shows you how much drive space is being used on each partition.

Figure 19.10. GNOME System Monitor File Systems tab.

This basic system monitor utility provides you with a good overview of resources and their utilization on your system. It would be interesting for you to note how much CPU time is being used by GNOME and related processes. This illustrates why I recommended that a special purpose server should not even have a desktop installed.

The KDE System Monitor is found under Applications → System → Monitor → System Monitor, and it has some significant differences from the GNOME System Monitor, although both purportedly have the same goal in mind. To begin with, the KDE System Monitor first has a process tab (Process Table) that is being updated in real time (see Figure 19.11). This means that as you are watching it, the list changes.

Figure 19.11. The KDE System Monitor.

You can sort by any of the headings simply by clicking on that heading. You may also notice the drop-down box to the upper right. By default it says All Processes. There are other options:

Each of these can be very informative in diagnosing bottlenecks in system performance and resource utilization. By right-clicking on any process, you will see a menu that allows you to set priority, view detailed memory usage information for that process, or even kill a specific process.

The second tab, the System Load tab, provides general information regarding current CPU, RAM, and network utilization (see Figure 19.12).

Figure 19.12. The KDE System Monitor System Load tab.

The KDE System Monitor is customizable. By selecting File → New Tab, you create a blank tab and are presented with options of what information you want to display there. That feature makes this a very powerful tool.

This shell utility is one of the fundamental ways you can improve disk access. This command works on individual partitions, so it is entirely possible to optimize one partition differently than you do another. If you need to see a list of your system’s partitions, then try the command sfdisk -s (see Figure 19.13).

Figure 19.13. sfdisk -s.

Once you have a list of partitions, you can run the hdparm command for any partition you choose (see Figure 19.14).

Figure 19.14. hdparm.

The hdparm command has a number of optional flags. Here is a brief description of the more commonly used options:

There are other optional flags you can use, some of which are potentially dangerous. Anytime you are altering the way a drive functions, you must be very careful.

This may be one of the most versatile configuration commands that Linux has. This command will let you modify various kernel parameters at runtime. It can be used to significantly alter system performance. You can enable or disable a variety of parameters. The general format is:

sysctl -w parameter=1

=1 will enable that particular parameter and =0 will disable it; however, this only works until the system is rebooted. If you want it to be permanent, then add it to /etc/sysctl.conf. On any given system, there will be a default sysctl.conf file that you simply modify or add to (see Figure 19.16).

Figure 19.16. openSUSE default sysctl.conf.

As with most shell commands, this one has a number of optional parameters:

The Linux kernel is very modular. This means that much of the functionality, including many drivers, is not in the kernel. This is important for general-purpose workstations. The Linux distribution vendor does not know how an end user will utilize the system or what drivers he will need, but for a server, this may not be best. Some administrators report significantly better performance by compiling the required drivers for their server in with the kernel.

Most distributions compile the kernel for a sort of “least common denominator.” In other words, they target the minimum system requirements. This ensures that the distribution will run on the widest range of systems possible. But what if you have a high-end machine, a very powerful processor, or your software requires the newest kernel? You can always recompile the kernel with the latest version available for download to ensure that you have all the features necessary for your system.