aix 查看硬件_

2024-08-26 20:35:26

1.AIX问题，高手告诉一下！

2.帮忙解释AIX中的init？谢谢！

3.Oracle大型数据库系统在AIX/UNIX上的实战详解的本书目录

4.如何查看aix主机操作系统版本

5.AIX是一个什么样的系统麻烦给点详细的资料

aix 查看硬件_

oslevel ? 查看操作系统版本。

oslevel -r 查看操作系统补丁版本。

lslpp ?-l|grep soft_name ? 查看安装的软件版本。

AIX?（Advanced Interactive eXecutive）是IBM基于AT&T Unix System V开发的一套类UNIX操作系统，运行在IBM专有的Power系列芯片设计的小型机硬件系统之上。

AIX问题，高手告诉一下！

as/400是一类计算机产品线名称，现在产品线已经更换为 IBM iSeries Systems，操作系统以前叫 OS/400 现在更换为 i OS。 IBM自己研发的，跟其他操作系统没有任何关系。

AIX 是另一个硬件产品线。IBM PSeries Systems的操作系统。是基于UNIX的。

两个操作系统完全不同，直观上说OS/400 或者i OS 像小霸王学习机，先插卡再选菜单要干什么。 AIX 则像DOS，输入命令控制要干什么。 DOS就是基于硬盘的文件数据全都在硬盘里，想做什么输入命令调用。而小霸王是插卡的，想玩什么插什么卡，想玩坦克大战，插魂斗罗的卡是绝对不可能的。所以你操作系统干什么之前先管理数据。库管理在操作系统之上还是下，这是两者根本的区别。

帮忙解释AIX中的init？谢谢！

看情况你问的是一个AIX启动过程的问题吧？

blv是包含aix启动映像的位置，包含aix内核，精简版本的ODM，还有rc.boot文件，还有启动过程中所必须的命令。bosboot命令就是用来创建系统的引导映像的

在AIX的启动过程中：

1、AIX系统存储在BLV的kernel在内存中创建/(root),/usr/和/var文件系统。要注意，这里所说的文件系统，包括kernel在启动过程中都是存储在RAM（内存）中的。他们没有权限访问BLV之外的任何内容。 2、文件系统被装载到RAM之后，kernel开始执行init进程，这个时候init进程开始接管系统启动进程。 3、AIX kernel把init进程的PID设为1，这个进程是作为parent,root进程存在的，是AIX系统中运行的其他所有进程的父进程.当init进程被装载并在启动过程运行,init调用rc.boot. 4、rc.boot文件在AIX系统启动过程中有三个重要的作用。（1）、第一部分是rc.boot初始化了系统的硬件，使其为系统的启动做好准备。通过系统设置命令cfgmgr，一小部分系统启动需要的驱动被配置。（2）、第二部分是文件系统/,/usr，/var和页面空间被装载。在这些文件系统被装载以后，init被硬盘上的PID为1的init进程所替代，同时RAM被清空。（3）、第三部分和最后部分，rc.boot,实际的init进程是从硬盘上运行的。当init被执行后，/etc/inittab文件被堵去，同时里面的每一条都被执行。在这个过程中，/tmp文件系统正被装载到硬盘上。现在，系统正在启动的最后过程中，cfgmgr命令再一次运行把剩下的在第一部分没有被rc.boot运行的驱动运行起来。 5、init进程被执行以后，下一步就是init会打开/etc/inittab，并且执行里面的内容。

可以百度搜索一下AIX启动过程，有更详细的讲解。

Oracle大型数据库系统在AIX/UNIX上的实战详解的本书目录

AIX（Advanced Interactive eXecutive）是IBM开发的一套UNIX操作系统。它符合Open group的UNIX 98行业标准（The Open Group UNIX 98 Base Brand），通过全面集成对32-位和64-位应用的并行运行支持，为这些应用提供了全面的可扩展性。它可以在所有的IBM ~ p系列和IBM RS/6000工作站、服务器和大型并行超级计算机上运行。

在系统启动过程中，在预初始化过程中装入根文件系统之后，将发生下面这些：

作为启动过程中的最后一个步骤，运行 init 命令。

init 命令尝试读取 /etc/inittab 文件。

如果 /etc/inittab 文件存在，那么 init 命令将尝试在 /etc/inittab 文件中查找 initdefault 条目。

如果 initdefault 条目存在，那么 init 命令使用指定的运行级别作为初始的系统运行级别。

如果 initdefault 条目不存在，那么 init 命令将请求用户从系统控制台 (/dev/console) 输入一个运行级别。

如果用户输入 S、s、M、或者 m 运行级别，那么 init 命令将进入维护运行级别。只有这些运行级别不需要经过正确格式化的 /etc/inittab 文件。

如果 /etc/inittab 文件不存在，那么 init 命令在缺省情况下将使系统进入维护运行级别。

init 命令每隔 60 秒将再次读取 /etc/inittab 文件。如果在 init 命令上一次读取 /etc/inittab 文件之后，其中的内容发生了更改，那么将执行 /etc/inittab 文件中的新命令。

/etc/inittab 文件

/etc/inittab 文件用于控制初始化过程。

/etc/inittab 文件提供了相应的脚本，以使得 init 命令的角色成为通用的进程调度器。init 命令的进程调度活动中的主要进程是 /etc/getty 线路进程，它将启动单独终端线路。通常由 init 命令进行调度的其他进程包括守护进程和 Shell。

/etc/inittab 文件由一些与位置无关的条目组成，它们的格式如下所示：

Identifier:RunLevel:Action:Command

每个条目之间由一个换行符进行分隔。换行符前面加上一个反斜杠 (\) 表示继续该条目。在 /etc/inittab 文件中，对于条目的数目没有任何限制（但不能超过最大的条目大小）。最大的条目大小为个字符。

条目字段包括：

Identifier，由一到十四个字符组成的字段，唯一地标识一个对象。

RunLevel，可以对该条目进行处理的运行级别。

运行级别具有下面的属性：

运行级别有效地对应于系统中的进程配置。

可以为每个由 init 命令启动的进程分配一个或者多个运行级别（该进程可以存在于其中）。

运行级别使用数字 0 到 9 进行表示。例如，如果系统处于运行级别 1，那么只有那些在运行级别字段中包含 1 的条目才会启动。

当您请求 init 命令更改运行级别时，在运行级别字段中不包含匹配条目（对于目标运行级别）的所有进程都将接收到一个警告信号 (SIGTERM)。在使用删除信号 (SIGKILL) 强行结束这些进程之前，有 20 秒钟的过渡期。

通过使用从 0 到 9 的任意组合，可以选择多个运行级别，从而在运行级别字段中为一个进程定义多个运行级别。如果没有指定运行级别，那么就定该进程在所有的运行级别中都是有效的。

在运行级别字段中，还可能出现其他四种取值，即使它们并不是真正的运行级别：a、b、c 和 h。仅当使用 telinit 命令请求它们运行时（无论系统当前运行级别如何），才会处理那些运行级别字段中包含这些字符的条目。它们与运行级别的不同之处在于，init 命令不可能进入到运行级别 a、b、c 或者 h。另外，任何这些进程的执行请求都不会更改当前运行级别。而且，在 init 命令更改级别时，不会终止以 a、b 或者 c 命令开头的进程。只有在下面三种情况下才会终止它们：在 /etc/inittab 文件中，它们所在行的操作字段被标记为 off，从 /etc/inittab 中完全删除它们所在的行，或者 init 命令进入到单用户模式。

Action，用于告诉 init 命令如何处理在进程字段中指定的进程。init 命令能识别下列的操作：

respawn：如果进程不存在，则启动该进程。不需要等待它的结束（继续扫描 /etc/inittab 文件）。当进程中止时，重新启动该进程。如果该进程已经存在，则什么也不做，继续扫描 /etc/inittab 文件。

wait：当 init 命令进入到与该条目的运行级别相匹配的运行级别时，启动该进程，并等待它的结束。当 init 命令处于相同的运行级别时，所有后续对 /etc/inittab 文件的读取操作都将导致 init 命令忽略这个条目。

once：当 init 命令进入到与该条目的运行级别相匹配的运行级别时，启动该进程，并且不需要等待它的结束。当它中止时，不重新启动该进程。当系统进入一个新的运行级别，并且该进程的运行来自前一个运行级别更改时，不重新启动该程序。

boot：仅在系统启动时（即在系统启动的过程中当 init 命令读取 /etc/inittab 文件的时候）处理该条目。启动该进程，不需要等待它的结束，并且当它中止时，不重新启动该进程。为了使得该指令有意义，运行级别应该为缺省值，或者它必须与启动时 init 命令的运行级别相匹配。对于系统硬件重新启动之后的初始化功能来说，这种操作是非常有价值的。

bootwait：在系统启动之后，当 init 命令第一次从单用户进入到多用户状态时，处理该条目。启动该进程，等待它的结束；并且当它中止时，不重新启动该进程。如果 initdefault 为 2，那么在启动之后运行该进程。

powerfail：仅当 init 命令接收到电源故障信号 (SIGPWR) 时，才执行与这个条目相关联的进程。

powerwait：仅当 init 命令接收到电源故障信号 (SIGPWR) 时，才执行与这个条目相关联的进程，并且在继续处理 /etc/inittab 文件之前，必须等待它结束。

off：如果与这个条目相关联的进程目前正在运行，那么发送警告信号 (SIGTERM)，等待 20 秒钟，然后使用删除信号 (SIGKILL) 终止该进程。如果该进程没有运行，则忽略这个条目。

ondemand：从功能上看，与 respawn 是相同的，但是这个操作适用于 a、b 或者 c 值，而不是运行级别。

initdefault：仅在 init 命令最初被调用时，才扫描包含这个操作的条目。init 命令使用这个条目（如果它存在的话）来确定最初要进入的运行级别。通过使用运行级别字段中所指定的最高运行级别，就可以实现这一点，并使用它作为其初始状态。如果运行级别字段为空，那么将其解释为“0123456789”：因此，init 命令将进入运行级别 9。另外，如果 init 命令在 /etc/inittab 文件中没有找到 initdefault 条目，那么将要求用户在启动时指定一个最初的运行级别。

sysinit：当 init 命令在登录之前尝试访问控制台时，将执行这种类型的条目。在正常情况下，这个条目仅用于初始化设备（init 命令可能会对这些设备询问有关运行级别的问题）。执行这些条目，并等待它们结束，然后再继续。

Command：要执行的 Shell 命令。整个命令字段以 exec 作为前缀，然后以 sh -c exec command 的形式传递给一个使用 fork 系统调用生成的 sh。任何合法的 sh 命令语法都可以出现在这个字段中。可以使用 # comment 语法插入注释。

getty 命令将覆盖 /etc/inittab 文件中出现在它之前的任何命令的输出。要将这些命令的输出记录到启动日志，可以使用管道将它们的输出传递给 alog -tboot 命令。

在 init 命令处理 inittab 条目时，stdin、stdout 和 stderr 文件描述符可能是不可用的。向 stdout 或者 stderr 进行写入操作的任何条目都可能无法按照预期的方式工作，除非它们将自己的输出重定向到一个文件或者 /dev/console。

对于修改 /etc/inittab 文件中的记录，仅支持下列的命令：

mkitab：将记录添加到 /etc/inittab 文件。

lsitab：列出 /etc/inittab 文件中的记录。

chitab：更改 /etc/inittab 文件中的记录。

rmitab：删除 /etc/inittab 文件中的记录。

例如，您希望向 /etc/inittab 文件添加一条记录，以便在运行级别 2 中运行 find 命令，并且在它结束后再次启动它：

1. 运行 ps 命令，并显示那些仅包含单词 find 的进程：

# ps -ef

grep find

root 150 13964 0 10:47:23 pts/0 0:00 grep find

2. 使用 mkitab 命令向 /etc/inittab 添加一条名为 xcmd 的记录：

# mkitab "xcmd:2:respawn:find / -type f > /dev/null 2>&1"

3. 使用 lsitab 命令显示新的记录：

# lsitab xcmd

xcmd:2:respawn:find / -type f > /dev/null 2>&1

4. 显示进程：

# ps -ef

grep find

root 282 13964 0 11:07:33 pts/0 0:00 grep find

5. 结束 find 进程：

# kill 25462

6. 显示进程：

# ps -ef

grep find

root 23538 13964 0 10:58:24 pts/0 0:00 grep find

root 28966 1 4 10:58:21 - 0:00 find / -type f

由于 action 项被设置成为了 respawn，所以一个新的 find 进程（上面显示的 28966）在前一个进程结束后又被系统启动了。

这个进程会被不断的重新启动，除非把 action 项的设置修改，如：

1. 把 xcmd 这条记录的 action 项的值从 respawn 修改为 once：

# chitab "xcmd:2:once:find / -type f > /dev/null 2>&1"

2. 显示进程：

# ps -ef

grep find

root 20378 13964 0 11:07:20 pts/0 0:00 grep find

root 280 1 4 11:05:46 - 0:03 find / -type f

3. 结束 find 进程：

# kill 280

4. 显示进程：

# ps -ef

grep find

root 282 13964 0 11:07:33 pts/0 0:00 grep find

可以看到 find 进程没有再被系统启动。

要从 /etc/inittab 文件中删除这条记录，您可以使用 rmitab 命令。例如：

# rmitab xcmd

# lsitab xcmd

/etc/inittab 条目的顺序

在 /etc/inittab 文件中，基本条目按照如下所示的方式进行排序：

initdefault

sysinit

Powerfailure Detection (powerfail)

Multiuser check (rc)

/etc/firstboot (fbcheck)

System Resource Controller (srcmstr)

Start TCP/IP daemons (rctcpip)

Start NFS daemons (rcnfs)

cron

pb cleanup (piobe)

getty for the console (cons)

必须在 etc/inittab 文件的开始处附近启动系统控制器（System Resource Controller，SRC），因为需要 SRC 守护进程来启动其他进程。因为 NFS 需要 TCP/IP 守护进程正确地运行，所以应该在启动 NFS 守护进程之前启动 TCP/IP 守护进程。/etc/inittab 文件中的条目根据依赖关系进行排序，这意味着，如果一个进程 (process2) 的正常运行需要另一个进程 (process1) 的存在，那么在 /etc/inittab 文件中，process1 的条目应该出现在 process2 的条目之前。

如何查看aix主机操作系统版本

第一篇构架篇.

第1章了解服务器运行环境

1.1 AIX：一种成熟的UNIX

1.2 Oracle与AIX的角色

第2章管理和维护服务器设备和服务

2.1 管理AIX中的设备

2.2 管理AIX中的服务

2.3 AIX系统错误处理

2.4 AIX系统硬件诊断

2.5 AIX系统日志查看

第3章管理服务器存储

3.1 AIX存储基本框架

3.2 AIX的存储概念要素

3.3 系统存储结构的管理

3.4 文件系统管理

3.5 Oracle系统需要的存储结构

第4章构建Oracle环境

4.1 一般安装过程

4.2 准备操作系统

.4.3 准备安装环境

4.4 安装Oracle数据库系统

4.5 数据库配置助手DBCA

4.6 升级Oracle数据库

4.7 创建裸设备数据库

4.8 使用数据库控制器

4.9 重构数据库控制器

4.10 通过控制台管理数据库

4.11 使用SQL*Plus管理数据库

4.12 使用iSQL*PIus管理数据库

4.13 AIX中Oracle的自动启动

第二篇管理篇

第5章在AIX中Oracle数据库管理

5.1 数据库参数文件和参数

5.2 相关服务的管理

5.3 使用数据库控制器

5.4 数据库的脚本化创建

第6章使用ASM跳过AIX卷空间管理

6.1 ASM的基本概念

6.2 ASM环境的实现

6.3 迁移到ASM环境

6.4 ASM环境的管理

6.5 RAC下管理ASM环境

第7章管理AIX下Oracle的空间使用

7.1 表空间和数据文件管理

7.2 还原表空间管理

7.3 重做日志管理

7.4 控制文件管理

第三篇灾备篇

第8章设计和实施AIX系统备份

8.1 AIX系统备份设计

8.2 AIX系统备份的实施

8.3 Oracle系统备份

8.4 数据库的冷备份

8.5 制定系统备份策略

第9章设计Oracle系统备份

9.1 数据库的可恢复性设置

9.2 数据库备份恢复的技术实现

9.3 Oracle备份恢复工作环境

第10章实施Oracle系统备份

10.1 RMAN解决的工程问题

10.2 RMAN运行环境与典型结构

10.3 RMAN的使用和操作实践

10.4 使用RMAN开始备份

10.5 执行数据库的备份

10.6 进行更为安全的备份

10.7 构建数据库系统的例行备份体系..

第11章恢复崩溃的系统

11.1 失败下的恢复方法选择

11.2 AIX中失败下的恢复

11.3 恢复操作中使用磁带

11.4 Oracle系统的数据恢复

11.5 涉及存储的数据库迁移

第四篇集群篇

第12章构建AIX下的Oracle集群环境

12.1 Oracle集群服务

12.2 针对CRS的操作系统配置

12.3 安装CRS前的准备

12.4 安装CRS和集群数据库

第13章在AIX中管理Oracle集群环境

13.1 管理集群数据库

13.2 集群数据库的特定管理

第五篇优化篇

第14章在AIX上综合设置Oracle环境

14.1 AIX系统可用性优化设置

14.2 Oracle应用综合优化设置

14.3 集群RAC下的设置建议

第15章 AIX上Oracle系统的运行优化

15.1 在系统构架时考虑性能要素

15.2 在系统运行时调整性能状态

15.3 系统配置的优化

15.4 内存配置的优化

15.5 I/O配置的优化

15.6 操作系统的使用

第六篇扩展篇

第16章 AIX上Oracle与Sybase的比较

16.1 AIX支持的数据库

16.2 运行机制的差异

16.3 工具使用的不同

16.4 数据库物理存储

16.5 数据库逻辑对象

16.6 数据库存储结构

16.7 数据库锁模型

16.8 数据库索引结构

16.9 数据库事务处理

16.10 数据库日志

16.11 数据库数据字典

16.12 临时数据的处理

16.13 备份和恢复

16.14 数据库一致性检查

16.15 数据库性能报告

16.16 数据类型的差异

16.17 数据库对象的差异

16.18 结束语...

AIX是一个什么样的系统麻烦给点详细的资料

AIX系统版本命名分为四个字段：AAAA-BB-CC-DDEE，例如：5300-08-06-0919。

（1）AAAA：代表AIX的发行版本。

（2）BB：代表技术级别，即TL。

（3）CC：代表服务包，即SP。

（4）DDEE：代表发行编号，DD代表发行的年份的末两位，EE代表发行时的星期。

例如：AIX 6.1TL6 SP3版本在2010年的第48个星期发布，所以其版本名称为：6100-06-03-1048。

扩展资料

华为SAN存储查询当前系统版本的命令：

（1）bash-3.00# oslevel-s（oslevel-s表示显示当前系统版本）；

（2）6100-05-01-1016；

（3）bash-3.00#。

华为-华为SAN存储在AIX系统下的主机连通性指南

AIX 全名为（Advanced Interactive Executive），它是IBM 公司的Unix操作系统，

整个系统的设计从网络、主机硬件系统，到操作系统完全遵守开放系统的原则。

下面对AIX 作以介绍。

RS/6000 用IBM 的UNIX操作系统-AIX作为其操作系统。这是一

个目前操作系统界最成功，应用领域最广，最开放的第二代的UNIX系

统。它特别适合于做关键数据处理（CRITICAL）。

AIX 包含了许多IBM 大型机传统受欢迎的特征，如系统完整性，系统可管理

性和系统可用性。

在 AIX 操作系统上，有许多的数据库和开发工具，用户除了选用已有的应用

软件外，还可以根据各自的需要进行开发。

此外，在AIX 之上，有一组功能强，使用方便的系统管理工具。对于异种平台

互存，互操作有很成熟的解决方案。

由于该 UNIX 的先进的内核技术和最好的开放性，因此，虽然RS/6000

从宣布到今天只有短短的5 年多的时间，它已在各行各业有了广泛的运用，

并在1993和1994年连续二年在MIDRANGE商用 UNIX 领域处于第一位。

RISC SYSTEM/6000的操作系统是AIX ，它是性能卓越的、开放的

UNIX，汇集了多年来计算机界在UNIX上的研究成果，以IBM 在计算机

体系结构、操作系统方面40多年极其丰富的经验。最大限度的使用RISC

技术，安装了象AIX 这样的具备工业界实力的UNIX操作系统。

它既可连接SAA 体系结构，又能与非IBM 系统的网络相连，因此，可以

和多数专业银行现有的系统实现互连，这对今后业务系统拓展将带来极大的

灵活性，并降低投资。

AIX 遵循一系列的国际标准：

* IEEE POSIX1004.1－1990

* X/OPEN 移植指南ISSUE3的基本级（XPG3）

* AES/OS REVISION A （O/1 LEVEL 2 资格）

* FIPS 151－1

* AIX的编译器： XLC、C++(可选)、FORTRAN(可选)、PASCAL(可选)、COBOL(可选)

* ADA 的编译器已达到XPG3“成员”级的认可。

* AIX 支持多用户、多任务。

AIX有一些其它特性包括：

AIX 提供了3 种SHELL ：SYSTEM V的KORN、BOURNE SHELL和4.3BSDC

SHELL作为可选择的UNIX系统界面；

安全设施满足TCB （Trusted Computing Base）的C2级；

实时处理能力，这对于“面向交易”的应用至关重要（如零售业

和银行等），它使RS/6000 获得极高的响应和吞吐量；

虚拟存储管理，当需要时，可将一些不常用的模块转送至外存，

提高内存的可利用性。

先进的文件系统，使得系统管理更加有效，并提高了数据可靠性

以及完整性。

能兼容Dos 应用程序和数据。

InfoExplorer，快速信息超文本索引系统- 不仅包括文字，而且

对包含声音、图像的索引系统，这是个联机的文件接口。包括全部的

超文本的索引和查找，以及面向任务和坐标的多重导引和索引系统。

这个文字及图形索引系统以一个灵活的、基于任务的方式去使用详细

资料及培训资料。

高级系统管理工具（SMIT，System Management Interface Tool）。

提供一级菜单驱动程序，诸如完成软件的安装与设置、设备的设置及

管理、问题的测定、存贮管理等。可以自动地进行I/O 设备设置，

ASCII 终端也可充当系统控制台。在LAN 上可以进行远程系统的安装。

系统工作负载

系统工作负载的完整准确的定义对于预测或理解它的性能是很关键的。在衡量系统性能时，工作负载的不同可能会比 CPU 时钟速度或随机访问存储器（RAM）大小不同带来更多的变化。工作负载的定义不仅必须包含向系统发送的请求的类型和速率，还要包含将要执行的确切软件包和内部应用程序。

包括系统将在后台处理的工作也很重要。例如，如果一个系统包含通过 NFS 加载且由其它系统频繁访问的文件系统，那么处理那些访问很可能是总体工作负载中非常重要的一部分，即使该系统不是正式的服务器也是如此。

已进行标准化从而允许在不同系统之间进行比较的工作负载称为基准程序。但是，很少有实际的工作负载能完全符合基准程序的精确算法和环境。即使是那些最初从实际的应用程序发展而来的行业标准基准程序也已经过简化和均匀化，从而使它们可移植到大量的硬件平台上。使用行业标准基准程序唯一有效的方法是减小将接受严肃评估的候选系统的范围。因此，在尝试理解系统的工作负载和性能时不应该只依赖基准测试结果。

可以将工作负载分为以下类别：

多用户

由多个用户通过各自的终端提交的工作组成的工作负载。通常，这种工作负载的性能目标有两种可能，即在保留指定的最坏情况响应时间条件下最大化系统吞吐量，或者对于固定不变的工作负载获得尽可能快的响应时间。

服务器

由来源于其它系统的请求组成的工作负载。例如，文件服务器的工作负载主要是磁盘读写请求。它是多用户工作负载（加上 NFS 或其它 I/O 活动）的磁盘 I/O 部分，所以适用同样的目标，即在给定的相应时间限制下最大化吞吐量。其它的服务器工作负载由诸如数学计算密集的程序、数据库事务、打印机作业之类的项组成。

工作站

由单独的用户通过键盘提交工作和在该系统的显示器上接收结果组成的工作负载。通常这种工作负载的最高优先级性能目标是使用户请求的响应时间最短。

性能目标

在定义了系统必须处理的工作负载后，可以选择性能标准并根据这些标准设定性能目标。计算机系统的总体性能标准是响应时间和吞吐量。

响应时间是提交请求和返回该请求的响应之间使用的时间。示例包括：

数据库查询花费的时间

将字符回显到终端上花费的时间

访问 Web 页面花费的时间

吞吐量是对单位时间内完成的工作量的量度。示例包括：

每分钟的数据库事务

每秒传送的文件千字节数

每秒读或写的文件千字节数

每分钟的 Web 服务器命中数

这些度量之间的关系很复杂。有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。在其它情况下，一个单独的更改可能对两者都有提高。可接受的性能基于合理的吞吐量与合理的响应时间相结合。

在规划或调谐任何系统中，当处理特定的工作负载时一定要保证对响应时间和吞吐量都有明确的目标。否则，有可能存在一种风险，那就是您花费了分析时间和物力改善的仅仅是系统性能中一个次要的方面。

程序执行模型

为了清楚地检查工作负载的性能特征，需要有一个动态而非静态的程序执行模型，如下图所示。

图 1. 程序执行层次结构. 该图形以一个三角形为基础。左边代表和右边适当的操作系统实体匹配的硬件实体。程序必须从存储在磁盘上的最低级别开始，到最高级别的处理器运行程序指令。例如，从底部到顶部，磁盘硬件实体容纳可执行程序；实内存容纳等待的操作系统线程和中断处理程序；转换后备缓冲区容纳可分派的结程；高速缓存中包含当前分派的线程和处理器流水线；而寄存器中包含当前的指令。

程序为了运行必须沿着硬件和操作系统层次结构并行向上前进。硬件层次结构中的每个元素都比它下面的元素稀少和昂贵。不仅程序不得不为了每个和其它程序竞争，而且从一个级别过渡到下一级别也要花时间。为了理解程序执行动态，需要对层次结构中每一级别有个基本的了解。

硬件层次结构

通常，从一个硬件级别移动到另一级别所需要的时间主要由较低级别的等待时间（从发出请求到接受到第一批数据的时间）组成。

固定磁盘

对于一个在单机系统中运行的程序而言，最慢的操作是从磁盘上取得代码或数据，这是因为有下列原因：

必须引导磁盘控制器直接访问指定的块（排队延迟）。

磁盘臂必须寻道以找到正确的柱面（寻道等待时间）。

读／写磁头必须等候直到正确的块旋转到它们下面（旋转等待时间）。

数据必须传送到控制器（传送时间）然后传递到应用程序中（中断处理时间）。

除了程序中显式的读或写请求以外，还有许多原因导致磁盘操作缓慢。频繁的系统调谐活动证明是不必要地跟踪了磁盘 I/O。

实内存

实内存通常称为随机存取存储器或 RAM，它比磁盘速度快，但每个字节的开销非常昂贵。操作系统尽量只把当前使用的代码和数据保存在 RAM 中，而把任何额外的内容存储在磁盘上，或者决不首先把它们带入 RAM 中。

然而，RAM 的速度不一定比处理器快。通常在硬件意识到 RAM 访问需求与处理器可使用数据或指令的时间之间，会出现许多处理器周期的 RAM 等待时间。

如果要访问存储到磁盘上（或者尚未调进）的某一虚拟内存页，则会产生一个缺页故障，并且程序的执行暂挂直到该页从磁盘读取。

转换后备缓冲区（TLB）

使程序员不会受限于系统的物理局限性的方法是实现虚拟内存。程序员在设计和编写程序时认为内存非常大，系统将负责将程序中指令和数据的虚拟地址转换成需要用来从 RAM 取得的指令和数据的实际地址。因为这个地址转换过程可能很费时，系统将最近访问过的虚拟内存页的实际地址保存在一个叫转换后备缓冲区（TLB）的高速缓存中。

只要运行中的程序继续访问程序和数据页中的一小部分，则完整的从虚拟到实际页地址的转换过程就不需要在每次 RAM 访问的时候都重做一次。当程序试图访问的虚拟内存页没有 TLB 入口（即 TLB 未命中）时，则需要大量的处理器周期（即 TLB 未命中等待时间）来进行地址转换。

高速缓存

为了将程序必须经历的 RAM 等待时间减到最小，系统为指令和数据组织了高速缓存。如果所需的指令和数据已在高速缓存中，则产生高速缓存命中，处理器就可在下一个周期立刻使用该指令或数据。否则产生高速缓存未命中，伴随有 RAM 等待时间。

在某些系统中，有两到高速缓存，通常称它们为 L1、L2 和 L3。如果一个特殊的存储器引用导致 L1 未命中，则检查 L2。如果 L2 产生未命中，则引用转至下一个级别，要么是 L3（如果存在），要么是 RAM。

高速缓存的大小和结构根据型号的不同而有不同，但是有效使用它们的原理是相同的。

流水线和寄存器

流水线型超标量体系结构使得在某些情况下可以同时处理多个指令。大批的通用寄存器和浮点寄存器使得可以将相当多的程序数据保存在寄存器中，而不需要频繁存储和重新装入。

可以设计优化编译器最大限度地利用这些能力。当生成产品程序时，无论程序有多小编译器的优化函数都应该能使用。Optimization and Tuning Guide for XL Fortran, XL C and XL C++ 中描述了如何将程序调谐到最大性能。

软件层次结构

程序为了运行还必须逐步执行软件层次结构中的一系列步骤。

可执行程序

当请求运行某个程序时，操作系统执行一些操作以将磁盘上的可执行程序转换成运行中的程序。首先，必须扫描当前 PATH 环境变量中的目录以查找程序的正确副本。然后，系统装入程序（不要和 ld 命令混淆，该命令是个绑定程序）必须解析出从程序到共享库的任何外部引用。

为了表示用户的请求，操作系统将创建一个进程或一组（例如专用虚拟地址段），任何运行中的程序都需要该进程或。

操作系统也会在该进程中自动创建一个单独的线程。线程是一个单独程序实例的当前执行状态。在 AIX 中，对处理器和其它的访问是根据线程来分配而不是根据进程分配的。应用程序可在一个进程中创建多个线程。这些线程共享由运行它们的进程所拥有的。

最后，系统转移到程序的入口点。如果包含入口点的程序页还不在内存中（可能因为程序最近才编译、执行和复制），则由它引起的缺页故障中断将该页从它的后备存储器中读取出来。

中断处理程序

通知操作系统发生了外部的机制是中断当前运行线程并将控制转移到中断处理程序。在中断处理程序可以运行之前，必须保存足够的硬件状态以保证在中断处理完成后系统能恢复线程的上下文。新调用的中断处理程序将经历在硬件层次结构中上移带来的所有延迟（除了页面故障）。如果该中断处理程序最近没有运行过（或者中间程序很节约时间），那么它的任何代码或数据不太可能保留在 TLB 或高速缓存中。

当再次调度已中断的线程时，它的执行上下文（如寄存器内容）逻辑上将得到恢复，以便它可以正确运行。然而，TLB 和高速缓存的内容必须根据程序的后继请求重新构造。因此，作为中断的结果，中断处理程序和被中断的线程都可能遇到大量的高速缓存未命中和 TLB 未命中延迟。

等待线程

无论何时只要执行的程序发出不能立刻满足的请求，例如同步 I/O 操作（显式的或缺页故障的结果），该线程就会处于等待状态，直到请求完成为止。除了请求本身所需的时间以外，通常这还会导致另外一些 TLB 和高速缓存的延迟时间。

可分派线程

当某个线程可分派但不在运行时，它不能完成任何有用的事情。更糟的是，正运行的其它线程可能导致重新使用该线程的高速缓存线路并将实内存页收回，从而引起最终分派时出现更多的延迟。

当前已分派的线程

调度程序选择对使用处理器有强烈要求的线程。在『CPU 调度程序性能概述』中讨论了影响该项选择需要考虑的事项。当分派线程后，处理器的逻辑状态恢复成线程中断时有效的状态。

当前的机器指令

如果未出现 TLB 或高速缓存未命中的情况，绝大多数机器指令都能在单个处理器周期内执行。相比之下，如果程序迅速转换到该程序的不同区域且访问大量不同区域中的数据，就会产生较高的 TLB 和高速缓存未命中率，执行每条指令使用的平均处理器周期数（CPI）可能大于 1。这种程序被认为有较差的局域性引用能力。它也许在使用必需的最少指令数来做这个工作，但是要消耗大量不必要的周期数。部分是因为指令数和周期数之间相关性较弱，检查程序列表来计算路径长度不会再直接产生一个时间值。由于较短的路径通常比较长的路径快，所以速率根据路径长度率的不同而明显不同。

编译器用完善的方法重新安排代码从而将程序执行所需的周期数降到最小。追求最佳性能的程序员必须首先致力于确保编译器具有有效优化代码所需的全部信息，而不是试图事后批评编译器的优化技术（请参阅『预处理器和编译器的有效使用』）。优化有效性的实际衡量标准是可信工作负载的性能。

系统调谐

在有效实现应用程序后，系统总体性能的进一步提高就成了系统调谐考虑的一个问题。系统级调谐包含的主要组件有：

通信 I/O

取决于工作负载的类型与通信链路的类型，可能需要调谐以下的一个或多个通信设备驱动程序：TCP/IP 或 NFS。

固定磁盘

逻辑卷管理器（LVM）控制文件系统的位置和磁盘上调页空间，这可能会极大地影响系统经历的寻道等待时间。磁盘设备驱动程序控制执行 I/O 请求所遵从的顺序。

实内存

虚拟内存管理器（VMM）控制空闲实内存帧的池，并决定何时从何处取用帧来补充该池。

运行线程

调度程序确定接下来由哪个可调度实体接收控制权。在 AIX 中，可调度实体是线程。请参阅『线程支持』。

性能调谐过程介绍

性能调谐主要是管理问题和正确的系统参数设置。调谐工作负载和系统以有效利用由下列步骤组成：

识别系统中的工作负载

设置目标：

确定如何评测结果

量化目标和区分目标的优先级

识别限制系统性能的关键

最小化工作负载的关键要求：

如果可选择的话，使用最适当的

减少个别程序或系统函数对关键的要求

结构化的并行使用

修改的分配以反映优先级

更改个别程序的优先级或限制

更改系统管理参数的设置

重复步骤 3 到步骤 5 直到满足目标（或者饱和）

如果必要的话，使用其它

在系统性能管理的每个阶段都有相应的工具（参阅附录 A 『监视和调谐命令和子例程』）。这些工具有些可从 IBM 得到；另一些是第三方产品。下图说明在一个简单的 LAN 环境中性能管理的各阶段。

图 2. 性能阶段. 该图用五个加权的圆圈说明对系统性能调谐的各步骤：规划、安装、监视、调谐和扩展。每个圆圈代表系统处于不同的性能状态：空闲、不均衡、均衡和过载。实质上就是扩展一个过载的系统、调谐系统直到它是均衡的、监视不均衡的系统并且在需要扩展时安装更多的。

识别工作负载

系统执行的所有工作都必须能够识别。特别是在 LAN 连接的系统中，通过系统的用户之间仅有的非正式协议，可以轻松地开发出一组复杂的交叉安装的文件系统。这些文件系统必须被识别出来并作为任何调谐活动的一部分进行考虑。

对于多用户工作负载，分析员必须量化一般情况和高峰期的请求率。确定用户实际与终端交互时间的实际比例也是很重要的。

该识别阶段中的一个要素是决定必须对生产系统进行评估和调谐活动，还是在另一系统上（或“切换”）用实际工作负载的模拟型式来完成评估和调谐活动。分析员必须针对非生产环境的灵活性权衡来自于生产环境结果的较大可靠性，分析员可在非生产环境中进行试验，当然试验所冒的风险是性能下降或更糟。

设置目标的重要性

虽然可以根据可测数量设置目标，但实际希望的结果往往带有主观性，比如令人满意的响应时间。进一步讲，分析员必须抵挡住调谐可测量的东西而不是对他而言是重要东西的诱惑。如果没有系统提供的评估能符合所要求的改进，那么就必须对该评估进行设计。

量化目标最有价值的方面不是选择达到的数字，而是对（通常）多个目标的相对重要性进行公开判定。如果这些优先级没有事先设定且不是每个相关的人都理解的话，分析员在没有进行频繁咨询之前不能作出任何折衷的决定。分析员还容易对用户的反应或管理性能中一些已经被忽略的方面而感到吃惊。如果系统的支持和使用跨过了组织的边界，您可能需要供应商和用户之间的书面服务级协议，可确保对性能目标和优先级有一个清楚而共同的理解。

识别关键

通常，给定工作负载的性能可由一两种关键系统的可用性和速度决定。分析员必须正确识别出那些，否则会冒险陷入无休止的尝试出错操作。

系统具有物理和逻辑。关键的物理通常比较容易识别，因为较多的系统性能工具可用来评估物理的利用率。通常最影响性能的物理如下：

CPU 周期

内存

I/O 总线

不同的适配器

磁盘臂

磁盘空间

网络访问

逻辑不太容易识别。逻辑通常是对物理进行分区的编程抽象。进行分区的目的是共享和管理物理。

构建于其上的物理和逻辑的一些示例如下：

CPU

处理器时间片

内存

页面帧

堆栈

缓冲区

队列

表

锁和信号量

磁盘空间

逻辑卷

文件系统

文件

分区

网络访问

会话

信息包

通道

了解逻辑和物理是很重要的。因为缺少逻辑线程可能阻塞，就像因为缺少物理而阻塞一样，扩展下层物理未必能保证创建附加的逻辑。例如，考虑使用 NFS 块 I/O 守护程序 biod。客户机上的一个 biod 守护程序要求处理每个暂挂的 NFS 远程 I/O 请求。因此，biod 守护程序的数量限制了能同时运行的 NFS I/O 操作的数量。当缺少 biod 守护程序时，系统检测会指示 CPU 和通信链路只使用了很少一部分。您可能有系统未充分利用（并且很慢）的象，事实上这时是因为缺少 biod 守护程序从而限制了其余的。biod 守护程序使用处理器周期和内存，但您不能简单地通过添加实内存或将它转移到一个更快的 CPU 上来修正这个问题。解决方案是创建更多的逻辑（biod 守护程序）。

在应用程序开发过程中可能不经意间创建逻辑和瓶颈。传递数据或控制设备的方法可以有效地创建一个逻辑。当偶然创建这样的时，通常没有工具可监视它们的使用，也没有接口控制它们的分配。它们的存在可能不会引起重视，直到某个特定性能问题出现时就会突出它们的重要性。

最小化关键要示

下面讨论在三个级别上考虑最小化工作负载的关键要求。

使用适当的

决定在一个上使用另一个时应该理智地考虑并且头脑中要有明确的目标。在应用程序开发过程中有一个选择的示例，即通过增加内存消耗来减少 CPU 的消耗来达到一个平衡。用于演示选择的公共的系统配置决策为：是将文件放置在单独的本地工作站上，还是放置在远程服务器上。

减少关键的要求

对于本地开发的应用程序，可用多种方法检查程序以便其更有效地执行相同的功能或除去不需要的功能。在系统管理级别上，争用关键的低优先级工作负载可以移动到其它系统中、在其它时间运行或由“工作负载管理器”控制。

结构化的并行使用

因为工作负载需要运行多个系统，从而可以利用这样的事实，即是独立的且可以并行使用。例如，操作系统预读算法检测到程序在顺序访问文件的事实，因此它调度并行执行的其它顺序读取操作，同时应用程序还处理先前的数据。并行也用于系统管理。例如，如果某个应用程序同时访问两个或多个文件且如果同时访问的这些文件存放在不同的驱动器上，那么添加一个额外的磁盘驱动器可能会提高磁盘 I/O 的速率。

分配优先级

操作系统提供了一些方法来区分活动的优先级。有些在系统级别上设置，比如磁盘调步。其它的例如进程优先级可由单个用户设置以反映连接到特定任务上的重要性。

重复调谐步骤

性能分析的一个公认的真理是接下来总有瓶颈出现。减少某个的使用意味着另一限制了吞吐量或响应时间。例如，设我们的系统中有下列的利用率级别：

CPU：90% 磁盘：70% 内存：60%

这个工作负载是 CPU 受限的。如果成功的调谐工作负载使得 CPU 负载从 90% 降到 45%，则可望在性能上有两倍的改善。不幸的是现在的工作负载是 I/O 受限的，它有下列的近似利用率：

CPU：45% 磁盘：90% 内存：60%

改善后的 CPU 利用率允许程序立刻提交磁盘请求，但接下来我们会受到由磁盘驱动器的容量施加的限制。性能改善也许是 30% 而不是预期的 100%。

总是存在一个新的关键。重要的问题是使用手边的是否已经满足性能目标。

注意: 用 vmtune、schedtune 和其它调谐命令产生的不正当系统调谐可能导致意外的系统行为，例如降低系统或应用程序的性能或系统暂停。更改仅应在性能分析识别出瓶颈时才适用。

注:

对于性能相关的调谐设置，不存在什么一般建议。