Title: Troubleshot Performance Issues
Course: CIS 208: Linux/UNIX III: Intermediate System Administration, Networking, and Security ~ For IGNITE Review > Section: Learning Modules

Troubleshot Performance Issues

When users complain that a system is slow, try to find out exactly what they are doing and when they first noticed the slowness.  It is common for users to wait before reporting a problem, and it is possible that intermittent problems may occur.

First check on the servers involved for an indication that resources are overtaxed.  The atop command gives a visual cue by using blue text for borderline and red text for overtaxed resources.  Another advantage to atop is that it checks network and disk usage in addition to cpu, memory and swapping.  If possible, find what processes are causing the slowness.  It may be necessary to restart specific services or to kill specific processes.  If working with a supported application such as Oracle or WebSphere, involve their tech support.

If there are no apparent problems on the server, ask the users to show you what they are experiencing.  It is possible that the problem is on the client side.  Check what software is being used and how it is configured.  Also check permissions and verify that any server authentication works properly.  If needed, check network connections as well.

If the problem is intermittent or if it occurs on a regular schedule, check the output of sar.  For example, if an office worker complains of slowness from a server on Monday mornings, check the sar output from several of the preceding Mondays.  Start with the cpu usage and look for patterns, such as cpu usage averaging about 10% prior to 4:00 am, climbing to 90% after 4:00 am, then dropping to around 20% after 10:00 am.  Next check for swapping and I/O operations, since either of these would affect the cpu usage.  It should be possible to determine if it is a cpu, a memory or an I/O issue.  In addition, it will be possible to determine within 10 minutes when the problem started.  Look for jobs running on this server or another server which would have started at about 4:00 am.  In this example, a likely cause would be a filesystem backup operation which originally completed in less than 2 hours, but over time took significantly longer to complete.

Some problems may be less easy to identify.  For example java applications may become unresponsive during the garbage collection phase.  If you notice issues with supported programs, contact the support personnel.  If support is not available, consider gathering key statistics such as the output of ps at very short intervals.  This will usually be able to identify the problem process, which will be the first step.  Next check the documentation and the logs for the application running the process.  It may be necessary to temporarily increase the logging level for the application.  If so, remember to restore the original logging level once the problem has been diagnosed.