| « | October 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | |
|
公告 |
|
数据仓库&数据挖掘
对某一件事需要坚持方能真正完成这件事
薛 峰
2009.02.03 |
| Blog信息 |
|
blog名称:数据仓库与数据挖掘
日志总数:85
评论数量:14
留言数量:0
访问次数:724351
建立时间:2005年3月17日 |
| |
|
 当我们认为优化器没有正常工作时
网上资源
薛 峰 发表于 2005/7/29 15:15:07 |
简介
IBM®DB2® Universal Database™ 附带了一个非常智能化的优化器，但是有时它的选择也许看来有些不称职。无论优化器多复杂，它也只不过是一个用来处理输入数据（如物理数据库结构和统计信息）并生成执行计划的程序。如果我们认为优化器没有正常工作，我们可以尝试向它提供一些更好的输入，看看会发生什么。也许优化器的选择最终是正确的（它通常是正确的）。本文提供了一些示例，在这些示例中收集了当前和完整的统计信息、添加了适当的约束并设置了适当的优化级别导致更好的执行计划。
为什么两个几乎相同的查询的运行方式却大相径庭
让我们考虑一个非常典型的方案：查询 SELECT * FROM CUSTOMER WHERE STATE = 'IN' 的运行速度非常慢。一个非常相似的查询 SELECT * FROM CUSTOMER WHERE STATE = 'MI' 反复运行的速度却要快 10 多倍。我们首先检查显而易见的情况：STATE 列上是否有索引？有的。下一步，我们检查每个州的客户数量是否差别很大。以下查询显示了每个州的客户数量看上去相差不多：
SELECT STATE, COUNT(*) AS NUM_CUST FROM CUSTOMER GROUP BY STATE WHERE STATE IN('IN', 'MI')
STATE NUM_CUST
----- ----------
IN 19071
MI 18554
SELECT COUNT(*) AS NUM_CUST FROM CUSTOMER
NUM_CUST
---------
2007931
当我们研究执行计划时，我们发现较慢的查询是作为表空间扫描来执行的，而较快的查询使用了索引。两者的区别在哪里呢？优化器为什么不为这两个查询选择同一个有效的计划呢？
让我们仔细研究与该表相关的统计信息。在 DB2 中，通过 SYSCAT 和 SYSSTAT 模式中的系统视图可以披露统计信息。（有关统计信息的更多详细信息，请参考 DB2 Administration Guide 中关于性能（Performance）的章节。）在我们的示例中，统计信息并不是最新的（在以下的清单中，请参阅 STATS_TIME，它是两个月之前的）。此外，自上次收集统计信息（在下面的清单中，请参阅 CARD）之后，记录的总数（现在是 2007931）已经大大增加了：
SELECT STATS_TIME, CARD FROM SYSCAT.TABLES WHERE TABNAME = 'CUSTOMER'
STATS_TIME CARD
-------------------------- ------
2002-10-01-08.49.49.117405 59616
虽然表已经超过了两百万行，但是优化器查找统计信息并且估计表中的记录仍然少于 60000 条。另外，STATE 列中值的分布也已经有很大的改变（TYPE = 'F' 代表最频繁出现的值）：
SELECT TYPE,SEQNO, VALCOUNT, CAST(COLVALUE AS CHAR(30))
AS COLVALUE FROM SYSSTAT.COLDIST WHERE TABSCHEMA='DB2INST1'
AND TABNAME='CUSTOMER_DATA' AND COLNAME='STATE' AND TYPE = 'F'
TYPE SEQNO VALCOUNT COLVALUE
---- ------ -------------------- --------------------------
F 1 19071 'IN'
F 2 18554 'SC'
F 3 11061 'CA'
F 4 5857 'TN'
F 5 2741 'KY'
F 6 1065 'MO'
F 7 220 'IL'
F 8 90 'WI'
F 9 26 'MI'
F 10 4 'FL'
（该查询检索该列中最频繁出现的 10 个值。）注：上一次收集统计信息时，印地安那州的客户（STATE='IN'）在所有客户中超过了 30％，而密歇根州的客户（STATE='MI'）只占 0.05％。让我们刷新该统计信息，包括分布：
RUNSTATS ON TABLE MYSCHEMA.CUSTOMER WITH DISTRIBUTION AND DETAILED INDEXES ALL
在刷新之后，优化器使用索引访问来执行原来比较慢的查询，现在该查询的运行速度快多了。（有关 RUNSTATS 命令的完整语法，请参考 Command Reference。）正如我们所见，使统计信息保持最新是必要的。
但我们不要认为：如果存在某种适当的索引，使用索引始终是较好的选择。
为什么有时表空间扫描比索引扫描更可取
考虑相同的查询 SELECT * FROM CUSTOMER WHERE STATE = ?。不管您是否相信，有时执行表空间扫描比通过索引访问记录更有效。听起来让人吃惊吧？是的，也许要进行一些分析来得出这个结论。让我们从一些基准测试开始；然后加以说明。
CUSTOMER 表中约 18％ 的记录与条件 WHERE STATE='IL' 匹配。通过对查询 SELECT * FROM CUSTOMER WHERE STATE = 'IL' 进行分析，优化器选择表空间扫描来执行它。让我们将该查询保存到名为 select.sql 的文件中，使用基准测试工具（db2batch）来测量执行该查询的实际代价。
db2batch -d MY_DB -f select.sql -r benchmark.txt -o p3
Number of rows retrieved is: 19998
Number of rows sent to output is: 19998
Elapsed Time is: 5.540 seconds
Locks held currently = 0
Lock escalations = 0
Total sorts = 0
Total sort time (ms) = 0
Sort overflows = 0
Buffer pool data logical reads = 2721
Buffer pool data physical reads = 2580
Buffer pool data writes = 0
Buffer pool index logical reads = 0
Buffer pool index physical reads = 0
（有关 db2batch 的更多详细信息，请参阅［Command Reference］。）
现在，让我们欺骗优化器，让它选择索引扫描来执行相同的查询。让我们使统计信息看上去象有一个虚构的州（STATE='IM'），而且在这个州里有许多客户，再让我们使伊利诺斯州的客户数量（如果有的话）变得很小。因为 SYSSTAT 模式中的视图是可更新的，让我们更新其中一个：
UPDATE SYSSTAT.COLDIST SET COLVALUE='IM' WHERE
TABSCHEMA='DB2INST1' AND TABNAME='CUSTOMER_DATA' AND COLNAME='STATE'
--AND TYPE = 'F'
AND COLVALUE='''IL'''
提示：在 WHERE 子句中，必须用引号括起列值（COLVALUE='''IL'''）。
现在，根据这些统计信息，优化器推断出只有很少的记录可能拥有 STATE='IL'。因此，它选择使用 STATE 上的索引的存取方案（请参阅较小的估计基数）：
SQL Statement:
SELECT *
FROM CUSTOMER_DATA
WHERE STATE='IL'
Estimated Cost = 50
Estimated Cardinality = 1
Access Table Name = DB2INST1.CUSTOMER_DATA ID = 2,5
| #Columns = 13
| Index Scan: Name = DB2INST1.CUST_STATE ID = 5
| | Index Columns:
| | | 1: STATE (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 'IL'
| | | Stop Key: Inclusive Value
| | | | 1: 'IL'
| | Data Prefetch: None
| | Index Prefetch: None
现在，让我们使用 db2batch 来执行第二个基准测试：
Number of rows retrieved is: 19998
Number of rows sent to output is: 19998
Elapsed Time is: 5.976 seconds
Locks held currently = 0
Lock escalations = 1
Total sorts = 0
Total sort time (ms) = 0
Sort overflows = 0
Buffer pool data logical reads = 19998
Buffer pool data physical reads = 2614
Buffer pool data writes = 0
Buffer pool index logical reads = 138
Buffer pool index physical reads = 28
显然，欺骗并没有给我们带来任何好处。在这种情况下，使用表空间扫描所耗费的时间实际上比使用索引扫描更少。
重要事项：我们已经手工更新了统计信息来对测试数据库执行一些“假定方案（what if）”分析。这对 SYSSTAT 模式的可更新视图是完全合理的用法。但是，在生产数据库中，我们绝对不应在正常的情况下更新统计信息。
现在，让我们解释发生了什么。我曾经听一个 5 岁的男孩说：“在监狱里待一秒钟不会有什么不良影响，所以在监狱里待两秒钟也不会有什么不良影响，那么在监狱里待三秒钟也不会有什么不良影响……”同样，通过索引读取一条记录会快一点，通过索引读取两条记录也会快一点，依此类推，但最多只能到某个数量，不能再多了。
根据统计信息，优化器估计 18％ 的记录将匹配条件 STATE='IL'。它还预期这些记录在整个表中差不多是均匀分布的，因为 STATE 上索引的群集比率是非常低的，小于 0.1。（有关群集比率的更多信息，请参考 DB2 Administration Guide 中关于性能的章节。）这意味着：无论如何，几乎表中的每一页都至少有一条匹配的记录。表空间扫描使用预取，这意味着数据库引擎在一次有效的读操作中会读取几个相邻的页面。表空间扫描是读取表中所有页面的最有效的方法。无论索引扫描可能会多么有效，仍然存在扫描索引的额外工作。
有关预取的更多信息，请参考：
SQL Reference 中 CREATE TABLESPACE 语句的语法及其 PREFETCHSIZE 选项。
DB2 Administration Guide 中关于性能的章节中缺省预取大小（DFT_PREFETCH_SZ）配置参数。
因此，无论看起来有多令人吃惊，优化器选择表空间扫描最终是正确的。我们已经了解了在这种情况下，索引访问肯定效率比较低。
为什么有时计算 MIN 比计算 MAX 快很多
查询 SELECT MIN(TOTAL_AMOUNT) FROM CUSTOMER 查找 TOTAL_AMOUNT 上的现有索引中的值，并立即返回答案。但是，一个非常相似的查询 SELECT MAX(TOTAL_AMOUNT) FROM CUSTOMER 却需要耗费多得多的时间。执行计划指出优化器选择了扫描整个索引来计算 MAX。为什么？
在这种特殊情况下，没有更好的选择。TOTAL_AMOUNT 上的索引不允许反向扫描：
SELECT REVERSE_SCANS FROM SYSCAT.INDEXES WHERE
INDNAME = 'CUSTOMER_AMT'
REVERSE_SCANS
-------------
N
在删除索引并用选项 ALLOW REVERSE SCANS 重新创建它之后，这两个查询开始运行得一样快了。
CREATE INDEX CUSTOMER_AMT ON CUSTOMER(TOTAL_AMOUNT) ALLOW REVERSE SCANS
RUNSTATS ON TABLE MYSCHEMA.CUSTOMER FOR INDEX MYSCHEMA. CUSTOMER_AMT
缺省情况下，DB2 索引不允许反向扫描。
提示：每当您在 CREATE TABLE 语句中创建 PRIMARY KEY、FOREIGN KEY 或 UNIQUE 约束时，就会隐式地创建一个索引。该索引不允许反向扫描。
您可以覆盖缺省行为：
创建一个没有约束的表（或删除现有约束）。
创建适当的索引。
使用 ALTER TABLE SQL 语句创建约束。
例如：
ALTER TABLE CUSTOMER DROP PRIMARY KEY;
--or create a table not defining a primary key
CREATE UNIQUE INDEX CUSTOMER_ID ON CUSTOMER(ID) ALLOW REVERSE SCANS;
ALTER TABLE CUSTOMER ADD PRIMARY KEY(ID);
DB2 会给出一条警告，并重用第 2 步中创建的索引。
正如我们所见，在一些十分常见的情况下，允许反向扫描的索引是必要的。
消除不必要的连接
让我们考虑以下视图：
CREATE VIEW CUSTOMER_ORDER_LIST
AS
SELECT
CUSTOMER_ORDER.CUSTOMER_ID
CUSTOMER.LAST_NAME
CUSTOMER.FIRST_NAME
CUSTOMER.PHONE
CUSTOMER.EMAIL
CUSTOMER_ORDER.ORDER_DT
CUSTOMER_ORDER.AMOUNT
CUSTOMER_ORDER.STATUS
FROM CUSTOMER JOIN CUSTOMER_ORDER
ON CUSTOMER.ID = CUSTOMER_ORDER.CUSTOMER_ID
CUSTOMER_ORDER 表中的所有记录在 CUSTOMER 表中都有父记录。该业务规则是由触发器维护的，而不是由外键约束维护的。（不要问我为什么。我能说的就是我在生产数据库中已经很多次看到它了。）
考虑查询：
SELECT CUSTOMER_ID, ORDER_DT, AMOUNT, STATUS FROM CUSTOMER_ORDER_LIST
您可能会认为根本不需要访问 CUSTOMER 表，因为所有必需的信息都在 CUSTOMER_ORDER 表的视图中，对吗？
事实并非这样。出于某些原因，优化器选择访问 CUSTOMER 表上的索引：
Estimated Cost = 25693
Access Table Name = DB2INST1.CUSTOMER ID = 2,5
| #Columns = 1
| Index Scan: Name = SYSIBM.SQL021126111001110 ID = 3
| | Index Columns:
| | | 1: ID (Ascending)
| | #Key Columns = 0
| | | Start Key: Beginning of Index
| | | Stop Key: End of Index
| | Index-Only Access
| | Index Prefetch: Eligible 199
| Lock Intents
| | Table: Intent Share
| | Row : Next Key Share
Merge Join
| Access Table Name = DB2INST1.CUSTOMER_ORDER ID = 2,6
（这只是部分输出。）
究竟为什么要访问 CUSTOMER 表呢？优化器的选择实际上非常有道理：您可能轻易地删除了触发器，将一条违反引用完整性的记录插入 CUSTOMER_ORDER 表中，并重新创建了触发器。记录将保留在 CUSTOMER_ORDER 表中，这意味着存在这种情况：触发器不保证引用完整性。这就意味着优化器必须假设 CUSTOMER_ORDER 表中可能有一些记录在 CUSTOMER 表中没有匹配的记录，因此查找 CUSTOMER 表上的记录是必要的。
现在，让我们创建适当的约束，看看会发生什么：
ALTER TABLE CUSTOMER_ORDER ADD FOREIGN KEY(CUSTOMER_ID) REFERENCES CUSTOMER(ID)
如果有任何记录违反了该约束，那么这条语句就会失败。现在，优化器能消除不必要的连接，而且查询可以运行得更快：
Estimated Cost = 18067
Access Table Name = DB2INST1.CUSTOMER_ORDER ID = 2,6
| #Columns = 1
| Relation Scan
| | Prefetch: Eligible
| Lock Intents
| | Table: Intent Share
| | Row : Next Key Share
| Return Data to Application
| | #Columns = 1
Return Data Completion
正如我们所见，添加外键约束向优化器提供了一些非常有用的数据。优化器则向我们提供更有效的执行计划作为报答。
什么时候好的决策比快速的决策更好
以前当我在寻找新工作时，我曾无意中看到两个空缺职位，它们是同一家公司提供的，而且是针对同一个项目的。对于该项目，他们需要一个项目经理和一个技术负责人。在众多要求中，他们列出了：
◆ 对于项目经理：“能够做出快速的决策。”
◆对于技术负责人：“能够做出好的决策。”
◆确有其事！
对于低的优化级别，优化器必须动作迅速。无论我们打算提供什么样的最新和详细的统计信息，优化器也许没有足够的时间对它进行分析。前面几章中的所有示例都是在缺省优化级别 5 下运行的。如果我们在低优化级别 1 下重新考虑前面的示例，添加引用完整性约束将不会产生更好的计划。
如果您想要好的决策，而不是快速的决策，请相应地设置优化级别。
有关优化级别的更多信息，请参考 DB2 Administration Guide 中关于性能和实现（Implementation）的章节。
结束语
DB2 优化器是非常智能化的。但是，根据不正确的信息，它也许会得出优化程度较低的结论。我们已经知道了如何：
检测不正确或不完整的统计信息。
向优化器提供正确且完整的统计信息。
在测试环境中更新 SYSSTAT 模式的视图，并执行“假定方案”实验。
性能调优从来就不容易。在查询优化中没有一成不变的规则。只要有可能，就应检查优化级别，使统计信息保持最新，并确保业务规则作为约束实现。我希望本文在数据库开发人员处理许多问题时有所帮助。
祝您好运！
感谢
作者衷心感谢 Mike Pittinger 的帮助。
相关信息
Command Reference 下载地址：
ftp://ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2n0e80.pdf
Administration Guide: Implementation 下载地址：
ftp://ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2d2e80.pdf
Administration Guide: Performance 下载地址：
ftp://ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/db2d3e80.pdf
页面顶部
关于作者
Alexander Kuznetsov 在软件设计、开发和数据库管理方面已有 15 年的经验。目前，他正在设计 DB2 UDB EEE 中多 TB 级群集数据库。Alexander 是 IBM 认证高级技术专家（DB2 群集）（IBM Certified Advanced Technical Expert (DB2 Cluster)）和 IBM 认证解决方案专家（数据库管理和应用程序开发）（IBM Certified Solutions Expert (Database Administration and Application Development)）。可以通过 alkuzo@mindspring.com 和 comp.databases.ibm-db2 新闻组与他联系。
当我们认为优化器没有正常工作时
|
|
|
[数据仓库]DB2优化
文章收藏, 网上资源
薛 峰 发表于 2005/7/27 16:25:18 |
| 预备—monitors ON
db2 update monitor switches using
lock ON sort ON bufferpool ON uow ON
table ON statement ON
打开监视开关,获取需要的性能信息
最简单而最见成效的—Bufferpool
缓冲池是内存中的一块存储区域,用于临时读入和更改数据库页(包含表行或索引项)。缓冲池的用途是为了提高数据库系统的性能。从内存访问数据要比从磁盘访问数据快得多。因此,数据库管理器需要从磁盘读取或写入磁盘的次数越少,性能就越好。对一个或多个缓冲池进行配置之所以是调优的最重要方面,是因为连接至数据库的应用程序的大多数数据(不包括大对象和长字段数据)操作都在缓冲池中进行。
缺省情况下,应用程序使用缓冲池 IBMDEFAULTBP,它是在创建数据库时创建的。当 SYSCAT.BUFFERPOOLS 目录表中该缓冲池的 NPAGES 值为 -1 时,DB2 数据库配置参数 BUFFPAGE 控制着缓冲池的大小。否则会忽略 BUFFPAGE 参数,并且用 NPAGES 参数所指定的页数创建缓冲池。
建议对于仅使用一个缓冲池的应用程序,将 NPAGES 更改成 -1,这样 BUFFPAGE 就可以控制该缓冲池的大小。这使得更新和报告缓冲池大小以及其它 DB2 数据库配置参数变得更加方便。
确保可以使用数据库配置中的 BUFFPAGE 参数来控制缓冲池大小之后,将该参数设置成合适的值。根据数据库的大小和应用程序的性质将该参数设置成一个合理的大值,这种做法很安全。通常,该参数的缺省值非常小,可能满足不了要求。
db2 get snapshot for all bufferpools
在数据库快照或缓冲池快照的快照输出中,查找下列logical reads和physical reads,这样就可以计算出缓冲池命中率,它可以帮助调优缓冲池:
缓冲池命中率表明数据库管理器不需要从磁盘装入页(即该页已经在缓冲池中)就能处理页请求的时间百分比。缓冲池的命中率越高,使用磁盘 I/O 的频率就越低。按如下计算缓冲池命中率:
(1 - ((buffer pool data physical reads + buffer pool index physical reads) /
(buffer pool data logical reads + pool index logical reads))
) * 100%
这个计算考虑了缓冲池高速缓存的所有页(索引和数据)。理想情况下,该比率应当超过 95%,并尽可能接近 100%。要提高缓冲池命中率,请尝试下面这些方法:
增加缓冲池大小。
考虑分配多个缓冲池,如果可能的话,为每个经常被访问的大表所属的表空间分配一个缓冲池,为一组小表分配一个缓冲池,然后尝试一下使用不同大小的缓冲池以查看哪种组合会提供最佳性能。
如果已分配的内存不能帮助提高性能,那么请避免给缓冲池分配过多的内存。应当根据取自测试环境的快照信息来决定缓冲池的大小。
太小的缓冲池会产生过多的、不必要的物理 I/O。太大的缓冲池使系统处在操作系统页面调度的风险中并消耗不必要的 CPU 周期来管理过度分配的内存。正好合适的缓冲池大小就在太小和太大之间的某个平衡点上。适当的大小存在于回报将要开始减少的点上。
获得最佳性能的—SQL
一条糟糕的 SQL 语句会彻底破坏一切。一个相对简单的 SQL 语句也能够搞糟一个调整得很好的数据库和机器。对于很多这些语句,天底下(或在文件中)没有 DB2 UDB 配置参数能够纠正因错误的 SQL 语句导致的高成本的情况。
更糟糕的是,DBA 常常受到种种束缚:不能更改 SQL(可能是因为它是应用程序供应商提供的)。这给 DBA 只留下三条路可走:
1. 更改或添加索引
2. 更改群集
3. 更改目录统计信息
健壮的应用程序由成千上万条不同的 SQL 语句组成。这些语句执行的频率随应用程序的功能和日常的业务需要的不同而不同。SQL 语句的实际成本是它执行一次的成本乘以它执行的次数。
每个 DBA 所面临的重大的任务是,识别具有最高实际成本的语句的挑战,并且减少这些语句的成本。
通过本机 DB2 Explain 实用程序、一些第三方供应商提供的工具或 DB2 UDB SQL Event Monitor 数据,可以计算出执行一次 SQL 语句所用的资源成本。但是语句执行频率只能通过仔细和耗时地分析 DB2 UDB SQL Event Monitor 的数据来了解。
最佳性能不仅需要排除高成本 SQL 语句,而且需要确保相应的物理基础结构是适当的。当所有的调节旋钮都设置得恰到好处、内存被有效地分配到池和堆而且 I/O 均匀地分配到各个磁盘时,才可得到最佳性能。
不可遗漏的—Lock
这些与锁相关的控制都是数据库配置参数:
LOCKLIST 表明分配给锁列表的存储容量。每个数据库都有一个锁列表,锁列表包含了并发连接到该数据库的所有应用程序所持有的锁。锁定是数据库管理器用来控制多个应用程序并发访问数据库中数据的机制。行和表都可以被锁定。根据对象是否还持有其它锁,每把锁需要 32 个或 64 个字节的锁列表:
需要 64 个字节来持有某个对象上的锁,在这个对象上,没有持有其它锁。
需要 32 个字节来记录某个对象上的锁,在这个对象上,已经持有一个锁。
MAXLOCKS 定义了应用程序持有的锁列表的百分比,在数据库管理器执行锁升级之前必须填充该锁列表。当一个应用程序所使用的锁列表百分比达到 MAXLOCKS 时,数据库管理器会升级这些锁,这意味着用表锁代替行锁,从而减少列表中锁的数量。当任何一个应用程序所持有的锁数量达到整个锁列表大小的这个百分比时,对该应用程序所持有的锁进行锁升级。如果锁列表用完了空间,那么也会发生锁升级。数据库管理器通过查看应用程序的锁列表并查找行锁最多的表,来决定对哪些锁进行升级。如果用一个表锁替换这些行锁,将不再会超出 MAXLOCKS 值,那么锁升级就会停止。否则,锁升级就会一直进行,直到所持有的锁列表百分比低于 MAXLOCKS。MAXLOCKS 参数乘以 MAXAPPLS 参数不能小于 100。
虽然升级过程本身并不用花很多时间,但是锁定整个表(相对于锁定个别行)降低了并发性,而且数据库的整体性能可能会由于对受锁升级影响的表的后续访问而降低。
LOCKTIMEOUT 的缺省值是 -1,这意味着将没有锁超时(对 OLTP 应用程序,这种情况可能会是灾难性的)。许多 DB2 用户用 LOCKTIMEOUT = -1。将 LOCKTIMEOUT 设置为很短的时间值,例如 10 或 15 秒。在锁上等待过长时间会在锁上产生雪崩效应。
首先,用以下命令检查 LOCKTIMEOUT 的值:
db2 get db cfg for DBNAME
并查找包含以下文本的行:
Lock timeout (sec) (LOCKTIMEOUT) = -1
如果值是 -1,考虑使用以下命令将它更改为 15 秒(一定要首先询问应用程序开发者或供应商以确保应用程序能够处理锁超时):
db2 update db cfg for DBNAME using LOCKTIMEOUT 15
同时应该监视锁等待的数量、锁等待时间和正在使用锁列表内存(lock list memory)的量。请发出以下命令:
db2 get snapshot for database on DBNAME
如果 Lock list memory in use (Bytes) 超过所定义 LOCKLIST 大小的 50%,那么在 LOCKLIST 数据库配置中增加 4k 页的数量。
掩盖问题的—SORTHEAP
SORTHEAP 是一个数据库配置参数,它定义了私有排序所使用的私有内存页的最大数目,或共享排序所使用的共享内存页的最大数目。如果排序是私有排序,那么该参数影响代理程序私有内存。如果排序是共享排序,那么该参数影响数据库的共享内存。每个排序都有单独的由数据库管理器按需分配的排序堆。在排序堆中对数据进行排序。如果由优化器来指导排序堆大小的分配,那么用优化器提供的信息来分配的排序堆的大小要小于由该参数所指定的排序堆大小。
SHEAPTHRES 是一个数据库管理器配置参数。私有和共享排序所使用内存的来源不一样。共享排序内存区的大小是在第一次连接到数据库时根据 SHEAPTHRES 值以静态方式预先确定的。私有排序内存区的大小是不受限制的。对于私有排序和共享排序,应用 SHEAPTHRES 参数的方式不同:
对于私有排序,SHEAPTHRES 是对私有排序在任何给定的时间可以消耗的全部内存的实例级软限制。当实例的总私有排序内存消耗量达到这一限制时,为其它进入的私有排序请求而分配的内存会大大减少。
对于共享排序,SHEAPTHRES 是对共享排序在任何给定的时间可以消耗的全部内存的数据库级硬限制。当达到这一限制时,不允许有其它共享排序内存请求,直到总的共享内存消耗量回落到 SHEAPTHRES 所指定的限制以下。
使用排序堆的操作示例包括内存中表的散列连接和操作。阈值的显式定义防止数据库管理器将过多数量的内存用于大量排序。
建议
使用数据库系统监视器来跟踪排序活动。
使用合适的索引使排序堆的使用降到最低。
当需要频繁进行大型排序时,增加 SORTHEAP 的值。
如果增加 SORTHEAP,请确定是否还需要调整数据库管理器配置文件中的 SHEAPTHRES 参数。
优化器用排序堆大小来确定存取路径。在更改该参数后请考虑重新绑定应用程序(使用 REBIND PACKAGE 命令)。
理想情况下,应当将排序堆阈值(SHEAPTHRES)参数合理地设置为在数据库管理器实例中设置的 SORTHEAP 参数最大值的倍数。该参数至少应当是实例中任何数据库所定义的最大 SORTHEAP 的两倍。
如何更改这些参数
要更改 SORTHEAP 和 SHEAPTHRES 的值,请运行以下命令:
-- SORTHEAP should be changed for individual database --
db2 update db cfg for DB_NAME using SORTHEAP a_value
-- SHEAPTHRES is a database manager parameter --
db2 update dbm cfg using SHEAPTHRES b_value
研究步骤
OLTP 应用程序不应该执行大型排序。大型排序在 CPU 和 I/O 资源方面的成本太高了。通常,SORTHEAP 大小的缺省值(256 个 4KB 页)就足够了。事实上,对于高并发性 OLTP,可能希望降低这个缺省值。当需要进一步研究时,可以发出下面这条命令:
db2 update monitor switches using sort on
然后,让应用程序运行一会,然后输入:
db2 get snapshot for database on DBNAME
根据该输出,可以计算每个事务的排序数目,并可以计算溢出了可用于排序的内存的那部分排序的百分比。
SortsPerTransaction
= (Total Sorts) / (Commit statements attempted + Rollback statements attempted)
PercentSortOverflow
= (Sort overflows * 100 ) / (Total sorts)
经验:如果 SortsPerTransaction 大于 5,它可能表明每个事务的排序太多。如果 PercentSortOverflow 大于 3%,那么可能发生了严重的、未曾预料到的大型排序。发生这种情况时,增加 SORTHEAP 只会隐藏性能问题 - 却无法修正它。这个问题的正确解决方案是通过添加正确的索引改进有问题的 SQL 语句的存取方案。 |
|
|
[综合]AIX 性能调优－内存、CPU篇
文章收藏, 网上资源
薛 峰 发表于 2005/7/25 11:09:42 |
sar -P ALL cpu使用情况
sar -a 文件访问情况
dirblk/s 定位文件时被目录访问守护进程读取的快（512b）的个数
iget/s i节点查找系统进程被调用次数
lookuppn/s 目录查找进程找到v节点，并获取路径名的次数
sar -b buffer的活动情况，包括传输、访问、和命中率
bread/s、bwrit/s 块IO操作的数量
lread/s、lwrit/s 逻辑 IO请求的个数
pread/s、pwrit/s 裸设备IO操作数量
%rcache、%rwrit cache命中率，计算共式为：((lreads-breads)/lreads)*100
sar -c 系统调用情况
exec/s、fork/s 调用和执行系统调用总数
sread/s、swrit/s read/writ 系统调用次数
rchar/s、wchar/s 被read/writ系统调用的字符数量
scall/s 系统调用总数
sar -k 内核进程活动情况
kexit/s 中断的内核进程数
kproc-ov/s 由于进程数的限制无法创建内核进程的次数
ksched/s 被作业分派的内核进程数
sar -m 消息队列和信号灯活动情况
msg/s IPC消息队列活动情况
sema/s 信号灯活动情况
sar -d 磁盘读写情况
sar -q 队列统计信息
run-sz 内核线程处于运行队列的平均数
%runocc 最近时间段运行队列占用百分比
swpq-sz 内核线程等待 页面调度的平均数
%swpocc 交换队列最近活动情况
sar -r 页面调度信息
cycle/s 每秒中页面置换次数
fault/s 每秒中page fault次数
slots 在页空间中空闲页数量
odio/s 每秒中不使用页面空间的磁盘io数
sar -v 进程、内核线程、i节点、和文件表 的状态
sar-w 上下文切换次数
sar -y tty设备活动情况
canch/s tty输入队列中规范的字符数
mdmin/s tty modem 中断
outch/s 输出队列字符数
rawch/s 输入队列字符数
revin/s tty接收中断
xmtin/s tty传输中断
如果CPU的使用率接近100％（usr＋system），可以视为是CPU瓶颈。而如果相当大的时间都花费在IO等待上，那就意味着cpu执行受到了磁盘IO的限制，
而IO瓶颈可能来自于文件访问或者没有足够的内存来分配页面。
注意：系统花费在等待远程文件访问的时间不会记入io 等待时间，如果CPU和IO等待的时间都相当的低，但是响应时间又不是很满意，那应该确认系统
花费多少时间在等待远程io，一直一来aix下没有命令对远程io进行分析，只能通过跟踪数据来观察。
vmstat
vmstat命令报告内核线程，虚拟内存、磁盘、陷阱、和CPU活动情况。
Kthr 线程活动情况
r 运行队列
b 等待队列
memory 虚拟和实际内存使用情况
avm 活动的虚拟页面
fre 空闲的页面，当系统内存大于64MB时，最小值MINFREE为120frames，当内存小于64MB时，最小值为内存以MB计的两倍
MINFREE和MAXFREE值可以通过vmtune命令来查看
page page fault和page活动情况，当在内存里分配一个页面时（非NFS或者永久文件页面），其被视为工作页面，工作页面通常包括应用堆栈、
数据和其他的共享内存段。因此当一个程序栈或者数据区域需要增长时，内存会被被访问，vvm会从ram和页面空间所在设备分配空间。这就意味着
在内存耗尽之前，页面空间会被使用。
re 页面输入输出列表，每秒中内存回收数量，当页面处于空闲列表且没有被再利用，它就会被回收应为没有新的IO会初始化它，也包括那些没有完成的IO操作但又被VMM使用
预先读取算法调入内存的页面。
pi 从页面空间page in的页面
po 从页面空间page out的页面
fr 页面空闲（页面重置）
sr 页面被页面调度算法扫描次数
cy 页面调度算法进行调度的时钟周期
faults 陷阱和系统中断率
in 设备中断
sy 系统调用
cs 内核线程上下文切换
CPU cpu使用情况
usr 用户进程
sys 系统进程
id cpu空闲时间
wa 等待磁盘IO时间
准则：
r<5，b≈0，
如果fre<MINFREE，将会出现连续不断的页面调度，将导致系统性能问题。
对于page列，re，pi，po，cy维持于比较稳定的状态，PI率不超过5，如果有pagin发生，那么关联页面必须先进行pageout
在内存相对紧张的环境下pagein会强制对不同的页面进行steal操作。如果系统正在读一个大批的永久页面，你也许可以看到po和pi列
会出现不一致的增长，这种情景并不一定表明系统负载过重，但是有必要对应用程序的数据访问模式进行见检查。在稳定的情况下，扫描率和重置率几乎相等，在
多个进程处理使用不同的页面的情况下，页面会更加不稳定和杂乱，这时扫描率可能会比重置率高出。
faults列，in，sy，cs会不断跳跃，这里没有明确的限制，唯一的就是这些值最少大于100
cpu列，us，sys，id和wa也是不确定的，最理想的状态是使cpu处于100%工作状态，单这只适合单用户的情况下。
如果在多用户环境中us＋sys》80，进程就会在运行队列中花费等待时间，响应时间和吞吐量就会下降。wa>40表明磁盘io没有也许存在不合理的平衡，或者对磁盘操作比较频繁，
|
|
|
AIX资源监控与调制工具
文章收藏, 网上资源
薛 峰 发表于 2005/7/25 11:08:44 |
|
性能优化以及确定系统中的性能瓶颈是系统管理员的主要任务之一。在一个计算机系统中，CPU、内存、硬盘和网络是影响系统性能的主要因素，因此系统性能调整也主要在于如何在这些资源中获得某种平衡，以满足人们对系统性能的期望。性能调制需要很多技巧，知识以及经验，不能仅靠分析统计数字，图表就可取得，性能调制有时是一件复杂甚至是非常困难的任务。
如同其它UNIX系统一样，AIX也给系统管理员剪裁系统提供了非常丰富的手段。这里我们简单介绍RS/6000 AIX系统中几个用于监控和调制多项系统资源的工具，每个工具的功能都很强，如想更透彻地了解这些命令的用法，请参考有关技术资料或手册。这里讲述的命令将不仅仅局限于CPU、硬盘、内存或网络资源的某个方面，它们可用于其中的一项或多项资源。
AIX监控工具
1、iostat
iostat命令主要通过观察物理磁盘的活跃时间以及他们的平均传输速度，监控系统输入/输出设备负载。根据iostat命令产生的报告，用户可确定一个系统配置是否平衡，并据此在物理磁盘与适配器之间更好地平衡输入/输出负载。
iostat工具的主要目的是通过监控磁盘的利用率（tm_act字段），而探测到系统中的I/O瓶颈。iostat还可用于确定CPU问题，辅助容量规划，并可以为最终解决I/O问题提供相关材料。vmstat和iostat联合使用，可捕获到确定与CPU，内存和I/O子系统有关的性能问题的必需数据。
iostat命令可产生下面四种类型的报告：
· tty和CPU利用情况
· 磁盘的利用情况
· 系统吞吐率
· 适配器吞吐率
2、netpmon
netpmon命令可以监控关于网络行为的系统事件和性能以及网络行为对CPU的消耗。netpmon命令在指定的监控周期报告网络行为。
netpmon启动后直至发布trcstop命令终止它之前，一直在后台运行。如果使用缺省设置，trace命令将会在netpmon命令之后立即自动启动。另外，netpmon中还可用trcon命令选择在后面的某个时间跟踪。当这种跟踪用trcstop命令终止后，netpmon命令就会输出它的报告并退出。缺省时报告会输出到标准输出，需要时也可以重定向到某个文件。
netpmon命令还可以在一次先前产生的跟踪中以脱机模式使用。在这样的情况下，需要用gennames命令产生一个文件。该文件必须在trace终止后立即产生。
所产生的报告中包括CPU使用情况、网络设备驱动器I/O情况、互联网络套接字调用，以及网络文件系统（NFS）I/O信息：
· CPU use：netpmon命令报告线程和中断处理器对CPU的使用情况。该命令将网络相关行为的CPU使用情况与其它行为的CPU使用情况区分开。
· Network Device Driver I/O：netpmon命令监控网络适配器上所通过的I/O统计。
· Internet Socket Calls：netpmon命令在互联网络套接字上监控read，recv，recvfrom，write，send以及sendto子程序。ICMP，TCP，UDP这几个协议的每个进程都会予以报告。
· NFS I/O：netpmon命令监控客户NFS文件上的read和write子程序，NFS客户上的RPC请求以及NFS服务器的read和write请求。
3、PDT（性能诊断工具）
PDT通过收集和集中各种性能、配置和可用数据自动找出性能问题。PDT评估系统的当前状态并跟踪系统在工作量和性能上的变化。PDT数据收集和报告很容易起用，不需要更多的管理行为。
虽然许多常见的系统性能问题都有特定性，但PDT还试图用一些被认为性能好的系统中的通用概念来帮助它查找问题。这些概念包括：
· 资源的平衡使用
· 在限定范围操作
· 确定的工作量趋势
· 无错误操作
· 系统参数得到适当设置。
4、ps
ps命令是UNIX系统中最常见的命令，它主要显示系统中关于进程的统计和状态信息，如进程ID，I/O行为以及CPU利用率等。利用ps命令提供的信息，可决定一个进程运行了多长时间，进程使用了多少CPU时间，以及进程是否受系统的惩罚。还可用ps命令确定进程使用了多少内存，完成多少I/O，进程的优先级以及是谁创建了进程。
下面这几个命令组合对于管理RS/6000 AIX系统有帮助：
（1）显示10个消耗CPU最多的进程：
# ps aux |head -1 ;ps aux |sort -rn +2 |head –10
（2）显示10个消耗存储空间最多的进程：
# ps aux |head -1 ;ps aux |sort -rn +3 |head -10
（3）按顺序显示系统中受罚的进程：
#ps -eakl |head -1 ;ps -eakl |sort -rn +5
（4）按优先级顺序显示系统中的进程：
#ps -eakl |sort -n +6 |head
（5）按处理时间为顺序显示系统中的前十个进程：
#ps vx |head -1 ;ps vx |grep -v PID |sort -rn +3 |head –10
（6）按实际内存使用的多少顺序显示系统中的前十个进程：
#ps vx |head -1 ;ps vx |grep -v PID |sort -rn +6 |head –10
（7）按换入页面的多少顺序显示系统中的前10个进程：
#ps vx |head -1 ;ps vx |grep -v PID |sort -rn +4 |head -10
5、vmstat
vmstat命令报告关于核心线程，虚拟内存，自陷（trap），磁盘以及CPU行为的统计。而且每种行为报告都被更细致地用百分比分别表示用户态、核态、空闲以及等待磁盘I/O等情况。
内核维持了对核心线程，换页以及中断行为的统计数据，而vmstat命令则通过使用knlist子程序和/dev/kmen伪设备驱动器访问这些数据。磁盘的输入/输出统计是通过设备驱动器维持的。对于磁盘，平均传输速度是通过使用活跃时间核传输信息数目决定的。而活跃时间百分比则是从报告期间驱动器忙的时间量计算出来的。
vmstat命令产生五种类型的报告：
· 虚存行为报告
· fork子进程情况报告
· 每个设备产生的中断情况报告
· 汇总报告
· 输入/输出行为报告
6、sar
sar命令报告CPU的使用情况，I/O以及其它系统行为。sar命令可以收集，报告以及保存系统行为信息。如果没有指定输入文件，则sar调用sarc命令访问系统数据。
用户可用让cron命令运行两个shell脚本（/usr/lib/sa/sa1和/usr/lib/sa2）以提供日统计和报表。在crontab文件/var/spool/cron/crontabs/adm中包括了一些样本节，用于示范cron要在何时运行这些shell脚本。以这种方式收集到的数据对于确定系统的时间周期特征和决定峰值使用时间是有用的。
但要注意的是，sar命令自己运行时会产生相当数量的读写。因此最好在没有工作量的情况下运行sar统计，看看sar对总的统计数字有多大的影响。
7、topas
topas命令用于监控各种系统资源，如CPU的使用情况，CPU事件和队列，内存和换页空间的使用，磁盘性能，网络性能以及NFS统计等。它还会报告指派给不同WLM类的进程对系统资源的消耗情况。它还能报告系统中最热门的进程和工作量管理器（WLM）的热门类。有关WLM类信息只有在WLM激活时才会显示。topas命令将热门进程定义为那些使用大量CPU时间的进程。topas命令没有作日志的选项，所有信息都是实时的。
topas命令利用System Performance Measurement Interface（SPMI）API获得有关信息。正是因为通过SPMI API，使系统开销保持在最小程度。topas命令使用perfstat库调用访问perfstat内核扩展。
8、truss
truss命令跟踪一个进程的系统调用、所接收的信号以及招致的机器错。要检查的应用程序可在truss命令的命令行中指定，也可将truss命令挂在一个或多个已经在运行的进程上。
AIX调制工具
1、fdpr
fdpr命令改进用户级程序和库的执行时间和对实际内存的使用。fdr命令可以通过不同的操作，如删除不必要的指令和重组代码和数据，而实现这样的目标。fdr命令安装在目录/usr/bin下。
fdpr命令在三个不同阶段上，对原有的执行代码应用先进的优化技术从而为其构筑一个优化的可执行代码。这三个阶段分别是：
· 在阶段1，fdpr创建一个增加了某些装置（instrumented）的可执行程序。原有的可执行程序被保存为__ProgramFile.save，而新版本被命名为__ProgramFile.instr。
· 在阶段2，fdpr运行该增加了某些装置的可执行程序，并收集摘要（profiling）数据。该摘要数据被保存在一个叫__ProgramFile.prof的文件中。运行执行程序时需要为它提供典型的输入数据，以使fdpr命令能够找出代码中可优化的部分。
· 在阶段3，fdpr命令使用阶段2中收集到的重要信息对可执行代码重新排序。这些重新排序涉及到这样一些任务：
（1）将那些高频度执行代码序列包装在一起。
（2）对条件分之重新排序，以改进硬件对分之条件的预测。
（3）将较少使用的代码部分移出来。
（4）内嵌一些热门函数。
（5）从重排序后的代码中删除掉NOP（空操作）指令。
另外，编译器中还提供了一个-qfdpr标志，用它可使编译器在执行代码中增加一些额外的信息，以辅助fdpr对该执行代码重新排序。但是，如果使用这个-qfdpr标志，则fdpr也只对那些用-qfdpr标志编译的模块重新排序。
2、schedtune
schedtune命令可以给抖动、进程挂起、时间片以及线程在锁上所能轮询的时间长度等设置准则。
用schedtune，可调整AIX中所设立的一组影响其内存负载控制机制的参数。Schedtune命令用于显示和修改那些用于检测系统内存是否在过度使用以致造成抖动的参数。Schedtune命令还能用于修改运行在系统上的进程的惩罚和衰减因子。在root用户下，用schedtune命令可做下面的事情：
· 决定用于确定抖动的准则。
· 决定哪个准则用于挂起进程。
· 决定在抖动终止后要等待多长时间才重新激活那些先前被挂起的进程。
· 决定被挂起的进程的最小数目。
· 调制调度优先级公式。
· 更改时间片数值。
· 决定在一把锁上轮询多长时间。
· 将schedtune值复位到它的缺省值。
需要注意的是，所有用schedtune作的修改在系统重启后都将丢失。为了确保所需的schedtune值在引导时能够置上，可在/etc/inittab文件中插入适当的schedtune命令。如：schedt:2:once:/usr/samples/kernel/schedtune -s 65536
3、vmtune
vmtune命令负责显示和调整虚存管理器（VMM）和其它AIX部件使用的参数。系统中的根用户可动态修改包括下面这些参数：
· VMM页替换
· 永久文件读写
· 文件系统缓冲区结构（bufstructs）
· LVM缓冲区
· 裸输入/输出
· 换页空间参数
· 页删除
· 内存固定参数 |
|
|
[综合]AIX学习笔记
网上资源
薛 峰 发表于 2005/7/22 13:22:47 |
AIX学习笔记
AIX学习笔记
http://blog.chinaunix.net/article.php?articleId=14542&blogId=2284
AIX学习笔记
一、系统安装完成后,手工安装以下fileset ：
1、将AIX作系统的第一张CD插入CD-ROM 驱动器，在系统提示处输入快速路径smitty install_all。在Input device / directory for software 选项中按F4 选择/dev/cd0。在SOFTWARE to install选项中键入：
bos.acct
bos.data
bos.rte.control
perfagent.tools
bos.dosutil
bos.perf
bos.net
bos.sysmgt
bos.adt
2、在安装完上述软件包后，需要给系统打补丁。使用随AIX系统盘所带的Update CD或从IBM得到的最新的补丁盘。插入CD-ROM 驱动器，在系统提示处输入快速路径smitty update_all，在 Input device / directory for software 选项中按F4 选择/dev/cd0，将COMMIT software updates?选择 no ，将SAVE replaced files? 选择 yes 。服务更新完毕后按F10 退出。这可以保证在新的补丁出现问题时，可以退回以前的版本。当此补丁稳定运行了一段时间后，可以commit它。
3、可用如下命令检查当前系统所打的补丁：
# instfix -i | grep ML
二、磁带机清洁的检查命令：#/usr/lpp/diagnostics/bin/utape -cd rmt0 –n
显示结果为磁带机使用的小时数，若大于72小时，则不论磁带机黄灯是否亮都应用清洁带清洗。
三、AIX内核属于动态内核，核心参数基本上可以自动调整，因此当系统安装完毕后,应考虑修改的参数一般如下:
A、单机环境
1、系统用户的最大登录数maxlogin
maxlogin的具体大小可根据用户数设定，可以通过smitty chlicense命令修改，该参数记录于/etc/security/login.cfg文件，修改在系统重新启动后生效。
2、系统用户的limits参数
这些参数位于/etc/security/limits文件中，可以把这些参数设为-1,即无限制，可以用vi 修改/etc/security/limits文件，所有修改在用户重新登录后生效。
default:
fsize = 2097151 ----》改为-1
core = 2097151
cpu = -1
data = 262144 ----》改为-1
rss = 65536
stack = 65536
nofiles = 2000
3、Paging Space
检查paging space的大小，在物理内存<2G时，应至少设定为物理内存的1.5倍，若物理内存>2G，可作适当调整。同时在创建paging space时, 应尽量分配在不同的硬盘上，提高其性能。利用smitty chps修改原有paging space的大小或smitty mkps增加一块paging space。
4、系统核心参数配置
利用lsattr -Elsys0 检查maxuproc, minpout, maxpout等参数的大小。maxuproc为每个用户的最大进程数,通常如果系统运行DB2或ORACLE是应将maxuproc调整，Default：128、调整到500，maxuproc增加可以马上起作用，降低需要AIX重起。当应用涉及大量的顺序读写而影响前台程序响应时间时，可考虑将maxpout设为33, minpout设为16，利用smitty chgsys来设置。
5、文件系统空间的设定
一般来说，系统的文件系统/、/usr、/var、/tmp的使用率不要超过80%，/tmp建议至少为300M，文件系统满可导致系统不能正常工作，尤其是AIX的基本文件系统，如/ (根文件系统)满则会导致用户不能登录。用df 查看。
# df -k (查看AIX的基本文件系统)
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 24576 1452 95% 2599 22% /
/dev/hd2 614400 28068 96% 22967 15% /usr
/dev/hd9var 8192 4540 45% 649 32% /var
/dev/hd3 167936 157968 6% 89 1% /tmp
/dev/hd1 16384 5332 68% 1402 35% /home
利用smitty chfs扩展文件系统的空间。
6、激活SSA Fast-Write Cache
利用smitty ssafastw来激活每一个逻辑盘hdiskn的Fast-Write Cache：选择硬盘后，把Enable Fast-Write一项改为Yes后回车即可。
7、激活AIO
AIO通常只对文件系统起作用，对裸设备没有作用。最大为10X并行磁盘数<80,最小为最大的一半。
a、定义系统中的AIO设备
smit aio -> Configure Defined Asynchronous I/O 然后回车执行；
b、激活系统中的AIO设备
smit aio -> Change / Show Characteristics of Asynchronous I/O回车出现AIO配置对话框，将对话框中〔STATE to be configured at system restart〕域选择为“available”，然后回车执行；
注：系统会提示只有在重起后才能生效。
8、rootvg镜像
因为rootvg损坏系统将无法运行，即使通过备份磁带恢复，也会造成系统停机，因此在磁盘空间充裕的情况下，可考虑对rootvg作镜像，同时在建立rootvg镜像时应尽量使用连接在不同SCSI 上的硬盘以做到负载均衡。利用smitty mirrorvg修改。
B、双机环境
在双机环境中，除了考虑上述参数设置外，还需考虑：
1、 High water mark for pending write I/Os per file(maxpout) 和Low water mark for pending write I/Os per file
它们缺省值为0，在双机环境中一般应设High water mark为33,Low water mark为24，这两个参数可用smitty chgsys来设置。
2、 syncd daemon的数据刷新频率
该值表示刷新内存数据到硬盘的频率，缺省为60，一般可改为20，也可根据实际情况更改。该参数通过vi /sbin/rc.boot更改，其中一行如下：
nohup /usr/sbin/syncd 60 >/dev/null 2>&1 &
改为：
nohup /usr/sbin/syncd 20 >/dev/null 2>&1 &
四、IBM RS/6000巡检内容及操作指导
1． IBM RS6000小型机机房要求：
a． 机房的卫生状况，要求清洁，键盘、显示器、机柜上没有灰尘。
b． 温度（摄氏 ℃）：10 ℃－40℃ ，湿度（%）：8% －80%
2． 设备故障灯分类：主机故障灯
面板上不能有数字显示，如果有的话，说明系统有故障。
7133磁盘阵列故障灯
告警灯为黄色表示有故障
磁带机故障灯
告警灯为黄色说明有故障或磁带机太脏，须清洗。
3． 系统错误报告(Error Log)的检查：
硬件故障检测命令：# errpt -d H -T PERM
若有故障执行命令# errpt -a -d H -T PERM>/tmp/harderror.log保存，分析结果报告给客户
软件故障检测命令：# errpt -d S -T PERM
若有故障执行命令# errpt -a -d S -T PERM>/tmp/softerror.log保存，分析结果报告给客户
4． 有否发给root用户的错误报告(mail):#mail
a． 观察所有未读消息，注意有关diagela的消息。
b． 常用命令：
h [] Display headings of group containing message
t [] Display messages in or current message.
n Display next message.
q Quit
c． 对发现的问题详细分析，结果报告给客户
5． 件系统的检查：命令：# df –k
%Used为文件系统的使用率。所有文件系统的使用率不能大于80%
6．磁带机清洁的检查：命令：
#/usr/lpp/diagnostics/bin/utape -cd rmt0 –n
显示结果为磁带机使用的小时数，若大于72小时，则不论磁带机黄灯是否亮都应用清洁带清洗。
7． 信系统的检测：
a． 网卡的状态：命令：
#ifconfig –a
输出判断：
en0: flags=e080863
inet 192.9.200.2 netmask 0xffffff00 broadcast 192.9.200.255
en1: flags=e080863
(下面还有411字) |
|
|