AIX 7.1性能优化指南

需积分: 5 163 浏览量更新于2024-07-18 1 收藏 4.31MB PDF 举报

"AIX Version 7.1性能管理文档提供了关于如何优化AIX操作系统性能的详细指导，适合有经验的用户参考。文档涵盖了系统性能的基础知识、新特性、工作负载分析、性能目标设定、程序执行模型、硬件和软件层次结构以及系统调优策略等内容。" 在AIX 7.1性能调整文档中，它首先介绍了文档的基本信息，包括版权和使用注意事项。文档适用于AIX 7.1及其后续的所有发布和修改，直至新的版本出现新的指示。性能管理是文档的核心部分，旨在帮助用户理解和改善AIX系统的整体性能。新的性能管理特性旨在提高系统效率和响应速度，这些特性可能包括新的监控工具、性能优化策略或系统资源管理的改进。文档深入讲解了性能管理的基础，包括系统的工作负载分析。工作负载是决定系统性能的关键因素，它涉及到系统上运行的各种任务和进程对CPU、内存、I/O等资源的需求。理解工作负载可以帮助管理员预测并应对性能瓶颈。性能目标是任何调优过程的出发点，这涉及到确定系统应达到的性能指标，如响应时间、吞吐量或其他特定业务需求。文档将指导用户如何设定和追踪这些目标。文档还阐述了程序执行模型，这涉及到代码如何在硬件上运行。了解这一模型有助于理解程序的性能特征，如CPU利用率、上下文切换和内存访问模式。硬件层次结构部分详细说明了AIX系统中的硬件组件，如处理器、内存、磁盘和网络设备，以及它们如何相互协作来处理工作负载。这对于识别硬件限制和优化硬件配置至关重要。软件层次结构则关注操作系统层面，包括内核、服务、库和应用程序，这些软件元素如何影响性能。这部分内容将帮助管理员理解软件设置和配置对系统性能的影响。最后，系统调优是文档的重点，它涵盖了各种策略和技术，用于调整AIX的内核参数、进程调度、内存管理等方面，以适应特定的工作负载和性能目标。这些调优实践可能涉及监控工具的使用，如topas、iostat和vmstat，以及根据收集的数据进行系统配置更改。这份AIX 7.1性能管理文档为有经验的AIX管理员提供了一个全面的指南，帮助他们有效地管理和优化他们的AIX环境，以确保系统的高效运行。通过理解和应用文档中的原则和方法，用户可以提升系统性能，降低延迟，提高服务质量，并优化资源利用率。

With multiuser workloads, the analyst must quantify both the typical and peak request rates. It is also

important to be realistic about the proportion of the time that a user is actually interacting with the

terminal.

An important element of this identification stage is determining whether the measurement and tuning

activity has to be done on the production system or can be accomplished on another system (or off-shift)

with a simulated version of the actual workload. The analyst must weigh the greater authenticity of

results from a production environment against the flexibility of the nonproduction environment, where

the analyst can perform experiments that risk performance degradation or worse.

Importance of setting objectives

Although you can set objectives in terms of measurable quantities, the actual desired result is often

subjective, such as satisfactory response time. Further, the analyst must resist the temptation to tune what

is measurable rather than what is important. If no system-provided measurement corresponds to the

desired improvement, that measurement must be devised.

The most valuable aspect of quantifying the objectives is not selecting numbers to be achieved, but

making a public decision about the relative importance of (usually) multiple objectives. Unless these

priorities are set in advance, and understood by everyone concerned, the analyst cannot make trade-off

decisions without incessant consultation. The analyst is also apt to be surprised by the reaction of users

or management to aspects of performance that have been ignored. If the support and use of the system

crosses organizational boundaries, you might need a written service-level agreement between the

providers and the users to ensure that there is a clear common understanding of the performance

objectives and priorities.

Identification of critical resources

In general, the performance of a given workload is determined by the availability and speed of one or

two critical system resources. The analyst must identify those resources correctly or risk falling into an

endless trial-and-error operation.

Systems have both real, logical, and possibly virtual resources. Critical real resources are generally easier

to identify, because more system performance tools are available to assess the utilization of real resources.

The real resources that most often affect performance are as follows:

v CPU cycles

v Memory

v I/O bus

v Various adapters

v Disk space

v Network access

Logical resources are less readily identified. Logical resources are generally programming abstractions

that partition real resources. The partitioning is done to share and manage the real resource.

You can use virtual resources on POWER5-based IBM System p systems, including Micro-Partitioning

virtual Serial Adapter, virtual SCSI and virtual Ethernet.

Some examples of real resources and the logical and virtual resources built on them are as follows:

CPU

v Processor time slice

v CPU entitlement or Micro-Partitioning

v Virtual Ethernet

8 AIX Version 7.1: Performance management

Memory

v Page frames

v Stacks

v Buffers

v Queues

v Tables

v Locks and semaphores

Disk space

v Logical volumes

v File systems

v Files

v Logical partitions

v Virtual SCSI

Network access

v Sessions

v Packets

v Channels

v Shared Ethernet

It is important to be aware of logical and virtual resources as well as real resources. Threads can be

blocked by a lack of logical resources just as for a lack of real resources, and expanding the underlying

real resource does not necessarily ensure that additional logical resources will be created. For example,

the NFS server daemon, or nfsd daemon on the server is required to handle each pending NFS remote

I/O request. The number of nfsd daemons therefore limits the number of NFS I/O operations that can be

in progress simultaneously. When a shortage of nfsd daemons exists, system instrumentation might

indicate that various real resources, like the CPU, are used only slightly. You might have the false

impression that your system is under-used and slow, when in fact you have a shortage of nfsd daemons

which constrains the rest of the resources. A nfsd daemon uses processor cycles and memory, but you

cannot fix this problem simply by adding real memory or upgrading to a faster CPU. The solution is to

create more of the logical resource, the nfsd daemons.

Logical resources and bottlenecks can be created inadvertently during application development. A

method of passing data or controlling a device may, in effect, create a logical resource. When such

resources are created by accident, there are generally no tools to monitor their use and no interface to

control their allocation. Their existence may not be appreciated until a specific performance problem

highlights their importance.

Minimizing critical-resource requirements

Consider minimizing the workload's critical-resource requirements at three levels.

Using the appropriate resource:

The decision to use one resource over another should be done consciously and with specific goals in

mind.

An example of a resource choice during application development would be a trade-off of increased

memory consumption for reduced CPU consumption. A common system configuration decision that

demonstrates resource choice is whether to place files locally on an individual workstation or remotely on

a server.

Performance management 9

Reducing the requirement for the critical resource:

For locally developed applications, the programs can be reviewed for ways to perform the same function

more efficiently or to remove unnecessary function.

At a system-management level, low-priority workloads that are contending for the critical resource can be

moved to other systems, run at other times, or controlled with the Workload Manager.

Structuring for parallel use of resources:

Because workloads require multiple system resources to run, take advantage of the fact that the resources

are separate and can be consumed in parallel.

For example, the operating system read-ahead algorithm detects the fact that a program is accessing a file

sequentially and schedules additional sequential reads to be done in parallel with the application's

processing of the previous data. Parallelism applies to system management as well. For example, if an

application accesses two or more files at the same time, adding an additional disk drive might improve

the disk-I/O rate if the files that are accessed at the same time are placed on different drives.

Resource allocation priorities

The operating system provides a number of ways to prioritize activities.

Some, such as disk pacing, are set at the system level. Others, such as process priority, can be set by

individual users to reflect the importance they attach to a specific task.

Repeating the tuning steps

A truism of performance analysis is that there is always a next bottleneck. Reducing the use of one

resource means that another resource limits throughput or response time.

Suppose, for example, we have a system in which the utilization levels are as follows:

CPU: 90% Disk: 70% Memory 60%

This workload is CPU-bound. If we successfully tune the workload so that the CPU load is reduced from

90 to 45 percent, we might expect a two-fold improvement in performance. Unfortunately, the workload

is now I/O-limited, with utilizations of approximately the following:

CPU: 45% Disk: 90% Memory 60%

The improved CPU utilization allows the programs to submit disk requests sooner, but then we hit the

limit imposed by the disk drive's capacity. The performance improvement is perhaps 30 percent instead

of the 100 percent we had envisioned.

There is always a new critical resource. The important question is whether we have met the performance

objectives with the resources at hand.

Attention: Improper system tuning with the vmo, ioo, schedo, no, and nfso tuning commands might

result in unexpected system behavior like degraded system or application performance, or a system hang.

Changes should only be applied when a bottleneck has been identified by performance analysis.

Note: There is no such thing as a general recommendation for performance dependent tuning settings.

Applying additional resources

If, after all of the preceding approaches have been exhausted, the performance of the system still does not

meet its objectives, the critical resource must be enhanced or expanded.

10 AIX Version 7.1: Performance management

If the critical resource is logical and the underlying real resource is adequate, the logical resource can be

expanded at no additional cost. If the critical resource is real, the analyst must investigate some

additional questions:

v How much must the critical resource be enhanced or expanded so that it ceases to be a bottleneck?

v Will the performance of the system then meet its objectives, or will another resource become saturated

first?

v If there will be a succession of critical resources, is it more cost-effective to enhance or expand all of

them, or to divide the current workload with another system?

Performance benchmarking

When we attempt to compare the performance of a given piece of software in different environments, we

are subject to a number of possible errors, some technical, some conceptual. This section contains mostly

cautionary information. Other sections of this topic collection discuss the various ways in which elapsed

and process-specific times can be measured.

When we measure the elapsed (wall-clock) time required to process a system call, we get a number that

consists of the following:

v The actual time during which the instructions to perform the service were executing

v Varying amounts of time during which the processor was stalled while waiting for instructions or data

from memory (that is, the cost of cache and TLB misses)

v The time required to access the clock at the beginning and end of the call

v Time consumed by periodic events, such as system timer interrupts

v Time consumed by more or less random events, such as I/O interrupts

To avoid reporting an inaccurate number, we normally measure the workload a number of times. Because

all of the extraneous factors add to the actual processing time, the typical set of measurements has a

curve of the form shown in the following illustration.

The extreme low end may represent a low-probability optimum caching situation or may be a rounding

effect.

A regularly recurring extraneous event might give the curve a bimodal form (two maxima), as shown in

the following illustration.

Figure 3. Curve for Typical Set of Measurement.

Performance management 11

剩余463页未读，继续阅读

jet-chang

粉丝: 0
资源: 1

AIX 7.1性能优化指南

AIX性能调整文档

aix 文档 aix 文档

aix双机帮助文档

AIX ppt培训文档

AIX7.1系统文档

AIX原文官方文档（aix5.3）

AIX_性能调整及维护案例2011.pdf

AIX培训教程，AIX，AIX学习文档

IBM服务器AIX中文安装文档

Unix-AIX操作系统文档

最新资源