Disaster preparedness Theory: a reliable off-site disaster preparedness

Introduction

The most important optimization part in the memory subsystem does not involve the actual optimization work. Before you optimize your system, you must understand the actual operation of the host system. To do this, AIX? An administrator must know what tools to use and how to analyze the data he or she will capture. Once again, as described in some of the other recent tuning articles (see Resources), you must first monitor the host, whether it is running on a logical partition (LPAR) or on its own physical server, before you can properly optimize your system. You can use a number of commands to capture and analyze data, so you need to understand the commands and which of these commands are most appropriate for the work that will be done. After capturing the relevant data, you need to analyze the results. Some problems may appear to be a central processing unit (CPU) problem that, after analysis, can be correctly diagnosed as memory or I/O problems, provided that you use the right tools to capture data and know how to do the profiling work. You can consider making actual changes to your system only after you have done the work correctly. If your doctor doesn't understand your medical history and current symptoms, you won't be able to diagnose the disease, and you will also need to troubleshoot the subsystem before tuning it. If the memory subsystem is optimized in the event of a CPU or I/O bottleneck, this will be unhelpful and may even affect the normal operation of the host.

This article will help you understand the importance of correctly implementing diagnostic work. As you will see, performance optimization is not just a practical optimization effort. Some of the tools you will be learning are common monitoring tools, all versions of UNIX provide these tools, and others are specifically written for AIX. Some tools have been optimized for AIX Version 5.3, and some new tools have been developed specifically for AIX 5.3 systems.

It is important to generate datum data, no matter how many times it is repeated. Don't wait for users to start complaining about bad performance before they start monitoring your system. The data should be captured as quickly as possible after the server has been put into the production environment. If you do this, you can be proactive in optimizing your work, with the goal of finding it before the user points out the problem. If you do not understand the data associated with the system's normal operation, you cannot determine whether the data being viewed represents a performance problem. All of these are part of the appropriate performance optimization approach to effectively capture data and correctly analyze its results and trends. Let's take a closer look.

UNIX-Common memory monitoring

In this section, I provide an overview of some common UNIX tools that can be used in all UNIX distributions, including PS, SAR, and Vmstat. Most of these tools allow you to quickly troubleshoot performance issues, but they are not appropriate for historical trend research and analysis.

Most administrators are not good at using the PS command to troubleshoot possible memory bottlenecks. In fact, many UNIX administrators don't even know why you can use PS to help determine the memory problem. The most common feature of PS is to view the processes running on the system (see Listing 1).

Listing 1. Use PS to view the processes running in the system

                
.
# PS GV | Head-n 1; PS GV | Egrep-v "RSS" | Sort +6b-7-n-r
  PID    TTY STAT time  pgin  SIZE   RSS   LIM  tsiz   TRS%cpu COMMAND
 15256      -A    64:15  755  2572  2888    xx  2356  316 0.9 0.0/usr/lpp/
 22752      -A     0:08  261  1960  1980 32768  465
 0.0 0.0 14654      -A     0:00  324  1932  1932    xx   198     0  0.0
 0.0/usr/sbin 20700      -A     0:07  271  1868  1896
 32768 0.0 20444      -A     0:03  203  1736  1824 32768   551  0.0  0.0 dtfile
 17602      -A     0:00  274   948 1644 32768 817 696 0.0 0.0  sendmail:
 13218      -A     0:00  1620  1620    xx   116     0  0.0  0.0/usr/sbin

Let's begin by explaining what these columns mean:

Memory Data:

avm--The amount of active virtual memory that you use (a page of 4k size), excluding file pages.

fre--the size of the memory idle list. In most cases, I'm not worried about when this value becomes very small, because AIX always makes the most of the memory and doesn't release it as early as you want. This setting is determined by the Minfree parameter of the VMO command. In the final analysis, paging information is more important.

pi--pages that are transferred from the paging space.

po--paged out to page space.

CPU and I/O:

r--The average number of kernel threads that can be run within the time interval that you specify.

b--The average number of kernel threads in the virtual memory wait queue at the time interval that you specify. If R is not more than B, it is usually a symptom of a CPU problem, which may be due to I/O or memory bottlenecks.

us--user Time.

sy--system time.

id--idle time.

wa--waiting for I/O.