再发一篇吐血原创：AIX主机性能评估

tereal

“   如果系统在向调页空间调出页面，可能使因为内存中的文件页数低于maxperm，从而也调出了部分的计算页面以达到maxperm的要求。在这种情况下，可以考虑把maxperm降低到低于numperm的某个值，从而阻止计算页面的调出。”

仅仅调整maxperm和minperm是早期的方法，不过，跟numperm之间的关系，没有变化，参考下面的解释：

The way it worked in the past was actually quite simple: If your file pages (numperm%) were greater than the actual maxperm%, then the page replacement would only steal file pages. When it falls below minperm, it could steal both file and computational pages. If it was between both, then it would only steal file pages unless the number of file repages was greater then the amount of computational pages. Another way of looking at this is if your numperm is greater than the maxperm, then you would start to steal from persistent storage. Based on this methodology, the old approach to tuning your minperm and maxperm parameters was to bring maxperm to a low amount (for example, <20) and minperm to <=10. This is how you would have normally tuned your database server.

tereal

现在都建议调整 lru_file_repage ，配合maxperm和minperm，参考下面：

That has all changed. The new approach sets maxperm to a high value (for example, >80) and makes sure the lru_file_repage parameter is set to 0. lru_file_repage was first introduced in AIX Version 5.2 with ML4 and on ML1 of AIX Version 5.3. This parameter indicates whether or not the VMM re-page counts should be considered and what type of memory it should steal. The default setting is 1, so you need to change it. When you set the parameter to 0, it tells VMM that you prefer that it steal only file pages rather than computational pages. This can change if your numperm is less than the minperm or greater than the maxperm, which is why you would now want maxperm to be high and minperm to be low. Let's not lose sight of the fact that the primary reason you need this value tuned is because you want to protect the computational memory. Getting back to the example, Oracle uses its own cache, and using AIX file caching for this purpose only causes confusion, so you want to stop it. If you were to reduce the maxperm in this scenario, then you would now make the mistake of stopping the application caching programs that are running.

tereal

btw：“偷页”，“窃取”都是直译的steal吧，觉得有点……，翻译成换页或者调页更好

tereal

最初由 BTxigua 发布
[B]三、磁盘的I/O性能评估
对磁盘IO的性能考虑：
1)        将频繁访问的文件系统和裸设备应尽可能放置在不同的磁盘上。
2)        在建立逻辑卷时尽可能使用mklv的命令开关给不同的文件系统和裸设备赋予不同的内策略。
3)        使用磁盘设备驱动适配器的功能属性构建合适的RAID方式,以获得更高的数据安全性和存取性能。一般考虑采用RAID5或者RAID10方式，对于写要求比较高的系统，一般建议采用RAID10方式;关于RAID10 与RAID 5的比较，可以见piner的文章，作为补充我会在后面贴出。
4)        尽可能利用内存读写带宽远比直接磁盘I/O操作性能优越的特点,使频繁访问的文件或数据置于内存中进行操作处理;

在这里，顺带提一下裸设备以及文件系统的对比。
裸设备的优点：
1)        由于旁路了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意味着取消了硬盘与文件系统的同步需求。这一点对于纯OLTP系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。除了OLTP，raw设备还能够从以下几个方面改善DSS应用程序的性能：
排序：对于DSS环境中大量存在的排序需求，raw设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。
序列化访问：raw设备非常适合于序列化I/O动作。同样地，DSS中常见的序列化I/O（表/索引的完全扫描）使得raw设备更加适用于这种应用程序。
2)        直接读写，不需要经过OS级的缓存。节约了内存资源，在一定程度上避免了内存的争用。
3)        避免了操作系统的cache预读功能，减少了I/O。
4)        采用裸设备避免了文件系统的开销。比如维护I-node，空闲块等。
5)        在裸设备上可以更方便的应用磁盘内策略。
裸设备的缺点：
1、裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。
2、很多备份工具软件对裸设备的支持不足，导致备份等的操作和方法比较原始、麻烦。 [/B]

裸设备的选择，我觉得是有争议的，优势也不是很明显，metalink上有篇文章，专门介绍了何时选择裸设备，并不推崇裸设备，文档编号Doc ID:  Note:29676.1 。
“3) 避免了操作系统的cache预读功能，减少了I/O。”
这个不是裸设备的优势，缓存本来是好的，只是oracle有了自己的SGA和PGA，fs的缓存显得多余，而且多了缓存之间的copy操作。对于IO来说，有没有fs的缓存，都是一样，看需要哪些数据块了。

“5) 在裸设备上可以更方便的应用磁盘内策略。”
如果你不嫌裸设备管理麻烦，fs上一样能够方便使用intra-disk策略，毕竟fs和裸设备都是建立在lv基础上。

“raw设备非常适合于序列化I/O动作”
这句话的结论怎么得出来的？

关于DIO和CIO的问题，从oracle 6开始就支持DIO了，现在很多文档也都建议使用CIO，包括IBM和Oracle，至于bug和稳定性，我想当初jfs2、ext3、ocfs出来的时候，也有类似问题，到现在，用户也很多了，CIO在AIX5.2的时候就有了。

BTxigua

最初由 tereal 发布
[B]btw：“偷页”，“窃取”都是直译的steal吧，觉得有点……，翻译成换页或者调页更好 [/B]

偷页，调页，这个就无所谓了，呵呵。
根据你提供的，我作了如下修改：

显示minperm和maxperm和numperm的值。numperm值给出的是内存中文件页数。
系统调页的规则：
1)        如果numperm>maxperm，则只调出文件页面。
2)        如果numperm<minperm，则同时调出文件页面和计算页面。
3)        如果minperm<numperm<maxperm，则只调出文件页面，除非新调入的文件页面大于计算页面的总和。
    如果系统在向调页空间调出页面，可能使因为内存中的文件页数低于maxperm，从而也调出了部分的计算页面，以达到满足maxfree的要求。在这种情况下，可以考虑把maxperm降低到低于numperm的某个值，从而阻止计算页面的调出。在5.2 ML4以后的版本中，为了防止计算页面被调出，可以采用另外一个方法，就是设置参数lru_file_repage=0。将该参数设为0，则告诉vmm在进行页面替换的时候，优先替换文件页面。

anlinew

最初由 NinGoo 发布
[B]

这个题目很简单么？在不知道block size 和db_file_multiblock_count，以及index的统计信息是否准确情况下，你要能给出结果算你牛

题目简单，可是出题目是不简单的，很多东西，看起来和简单，动起手来还是不简单的，建议你如果对oracle很有见解，那么多写点东西，一来检验一下自己的成果，二来也给大家分享一下不是。三来嘛，我们正在寻觅一个数据库架构师，欢迎各路英雄前来入伙 [/B]

数据库架构师是干吗的？
给描述下
兄弟好找个发展方向

anlinew

最初由 zlc158 发布
[B]
真的不错,
首先很感谢楼主的原创精神,
并且也希望那些很挑剔的人,多多理解写原创的本身就是很难的,
人家费劲八力几天写出来的, 你看的时候可能几秒钟或者几分钟就看完了.
有错误可以提出来,但也不能那样"刁难"的说出来了.
由于自己也经常写原创,所以对这个感受很深.
别人很辛苦写出来自己东西,让你免费看,只有内容中有一点点对自己有用东西,
就应该心怀感激!

做人要厚道!挑毛病谁都会!!
尊重别人就是尊重自己! [/B]

原创不等于cope，估计这是那个puber不爽的原因吧

BTxigua

最初由 tereal 发布
[B]

裸设备的选择，我觉得是有争议的，优势也不是很明显，metalink上有篇文章，专门介绍了何时选择裸设备，并不推崇裸设备，文档编号Doc ID:  Note:29676.1 。
“3) 避免了操作系统的cache预读功能，减少了I/O。”
这个不是裸设备的优势，缓存本来是好的，只是oracle有了自己的SGA和PGA，fs的缓存显得多余，而且多了缓存之间的copy操作。对于IO来说，有没有fs的缓存，都是一样，看需要哪些数据块了。

“5) 在裸设备上可以更方便的应用磁盘内策略。”
如果你不嫌裸设备管理麻烦，fs上一样能够方便使用intra-disk策略，毕竟fs和裸设备都是建立在lv基础上。

“raw设备非常适合于序列化I/O动作”
这句话的结论怎么得出来的？

关于DIO和CIO的问题，从oracle 6开始就支持DIO了，现在很多文档也都建议使用CIO，包括IBM和Oracle，至于bug和稳定性，我想当初jfs2、ext3、ocfs出来的时候，也有类似问题，到现在，用户也很多了，CIO在AIX5.2的时候就有了。 [/B]

“3) 避免了操作系统的cache预读功能，减少了I/O。”
这点我在讲的时候，主要就是针对oracle环境的。在oracle的环境中，这可以成为裸设备的一点优势，可以减少I/O。

“5) 在裸设备上可以更方便的应用磁盘内策略。”
这个确实，在mklv的时候，谁都可以指定。我已经把这条去掉了。



“raw设备非常适合于序列化I/O动作”
这句话来自于《ORACLE_24.7技术与技巧---数据库高可用》。
我是这样理解的，裸设备直接对IO直接读写，所以所以序列化操作也将同时反映到物理磁盘上的序列化操作，而文件系统由于经过了操作系统的缓存，则不然。

anlinew

IBM有本红皮书：
Database PerformanceTuning on AIX

Covers DB2 UDB V8, Oracle 9i,and Informix DS on AIX 5L

建议有空扫一眼

BTxigua

还能提供你一下文档啊？呵呵