HPUX性能调优手册(2)

                                                                                            OS 版本

对于一个新安装，你会装上11.23和最新的补丁，更可能是11.31. 11.31现在很稳定了，我们建议安装，也装上最新的补丁。 11.23文件系统缓存在11.31中被替换为更有效的统一文件缓存（UFC, Unified File Cache）,文档的后面有一部分专门讲UFC.

       11.31通过对存储栈(mass storage stack improvements)的优化对很多特别是强IO访问的程序提供了显著的性能提升. 其中一些改进包括:在各个IO访问路径(lun path)上自动的负载均衡,不同的负载均衡算法，并行IO扫描来显著地减少扫描时间（包括启动时间），CPU耦合算法来提高缓存命中率，最大的IO 访问大小增加到2MB，IO最大队列深度（MAX_queue_depth）更灵活-可以按设备、设备类型、Vendor ID、Prduct ID等来设置。

 

总得来说，11.31比11.23每秒能够完成更多的IO操作，每个IO操作的时间减少。LVM可以支持更新版本的VXFS,也可以支持更大的页面大小。大部分的原生多路径支持，负载均衡和IO性能的提升是得益于cell部分的改善。11.31采取了措施减少缓存不命中，将IO安排在与发起IO请求的同一个cell单元中。

       11.31的核心支持基于线程的锁(以前是基于进程的锁). 对自旋锁(spinlocks)、信号量（semaphores ）、互斥锁(mutexes)有更新的架构，应该会更灵活。

在2007年，HP出了一个官方文档说”HPUX 11i v3在相同硬件平台平均比11i v2提升了30%的性能,依应用情况各有不同云云”,我们被保证过这是在真实的应用环境取得的，而不仅仅是Benchmark，这当然很棒。我们真正能完全确定的是“不同的用户得到不同的结果”

有些用户可能暂时没法升级，因为你的应用程序还没有在新版OS下认证过。很遗憾。11.23，经过了过去几年的进化，是非常稳定的。现在，11.31提供了更多性能与扩展性的增强。 看看你有什么办法升级应用，来享受新版本OS的更好性能。

Memory Setup

人们总是说”内存这么便宜咱多买点吧”,是的,这是硬件供应商的观点。应用软件供应商通常会建议你需要多少内存，尽管事实上挺难预测内存使用率。你不会愿意遇到内存瓶颈，你希望有足够空间来容纳应用程序常驻部分和系统核心，还有文件缓存。如果要运行数据库，或是其他得益于大量缓存的程序，充足的内存就更重要了。以Oracle为例，配置超大的SGA区（缓存池，共享表缓存）对性能就很有好处。

常驻内存和虚拟内存有点棘手. OS给应用程序以假象有比事实上更多的内存，这个花样就叫虚拟内存。它实际上包括了应用程序为它所有数据申请的内存空间，包括共享内存、堆空间、程序文本、共享库和内存映射文件等。为所有进程申请的虚拟内存加起来大致就相当于需要保留的交换区大小（不包含程序文本program text）。虚拟内存实际上和多少物理内存被分配了没多大关系，因为不是所有被映射到虚拟内存中的数据都是激活的状态(也就是驻留在物理内存里). 如果你的程序得到“out of memory”的错，通常是表明你没有可供保留的交换区空间(虚拟内存),而不是物理内存用完了。

对于Superdome和其他所有基于cell结构的主机，还有更复杂的问题像cell local memory/NUMA（Non-Uniform Memory Access非一致内存访问）。我们通常的建议是: 如果你的应用程序不是专门针对它优化的，那就别动这块儿，这玩意儿超复杂。我们知道Oracle 10gR2 专门对CLM（黄按:就是Cell local memory,cell本地内存）进行了优化。但是，通常来说CLM不是我们说的可以操作的东西，通常方式的优化可以用5%的复杂度解决95%的问题. CLM和指定中断到特定CPU还有其他一些内容通常是我们所避免的太涉及‘内部’的东西。我们不是说研究这些不好如果这个确实符合你的实际情况，就是别用力过度。在文档的最后，我们有一个章节专门针对基于cell的性能问题，简要讨论了Oracle、多重SGA和PSETS之类的。但是不会太深入，只是足够让你有所了解，决定是不是还想深入钻研特定的问题。

弄糊涂了？内存这么便宜咱多买点吧。

Disk Setup

你可能已经准备了足够的磁盘空间，但你也想研究一下如何分布数据。通常来说，较多的小硬盘比较少的大硬盘性能要好。你应该把IO最重的逻辑卷分布在不同的IO通道、不同的硬盘上。当然，大型的磁盘阵列可以虚拟化并以自己的方式管理。管理大型的存储局域网是一门艺术，我们在这个手册中不涉及。

一个老的UNIX小窍门：程序的路径到根目录的级数越少越好。极深的目录层级会因为更多的查询操作影响性能经。相反地，如果在一个目录里有太多的文件（几千个），也会造成速度下降。

Swap Devices

你需要配置足够的交换区空间，最少要和物理内存的大小一样。理想的办法是配置很多交换空间保证它足够，但事实上避免用到它(换句话说，你要配置它但是尽量避免paging操作真正发生). 可以通过安装足够的物理内存来避免交换(paging)的发生，这样你就不会遇到内存的瓶颈。

 

对于指定为交换区的磁盘分区，最好的配置是将交换区平约分配给多个性能相同的硬盘(最好在不同的IO卡上). 例如，你需要16GB交换区，你可以通过在4块IO卡上相同的硬件型号的硬盘上各划出4GB空间来实现，那是最好的。如果你只有不同大小的空间来配置swap,最少找两块同样大小和性能的空间（在不同硬盘上），并把它们配置为最高优先级(就是最小的数，0). 主交换区被设为优先级1而且不能改，这是你为什么要设为优先级0的原因。这样就允许了交错的内存交换，paging操作可以依次在这几个设备个进行。你不期望page out发生，但是一旦需要，你就希望尽快完成。

       你还可以其他低优先级的交换设备。最高优先级的设备是page操作最先访问的，大多数情况下低优先级的设备是保证其空间被预留了，但是不会真正有数据被交换到上面。这样的话它的性能就不是一个问题了。低优先级的空间可以是慢的、不交错的。我们将在磁盘和内存瓶颈部分再讨论交换的问题。

       伪交换(Pseudo swap)是默认就开启的,这个没什么负面影响。如果你没有足够的磁盘空间用来做交换区，那么开启伪交换是必须的。如果你的应用程序要求预留的交换空间超过了磁盘交换区的大小，就会造成伪交换区的空间更多的被使用(黄按:伪交换区实际上是在内存中留一块空间，使用伪交换区就是这块伪交换区中某几页内存被锁定了)。如果你有足够的磁盘交换空间，那开启伪交换没什么优势…那些磁盘交换空间比物理空间小的主机只有利用这个功能才能使用到所有的内存。(黄按:程序运行前OS要为它预留交换空间，以防需要的时候没法把它交换出来。内存12GB,交换空间为4GB的话，如果未开启伪交换，那所有程序可用的空间就是4GB. 开启伪交换后，物理内存的75%可以通过锁定来实现交换区的功能，所有可用空间就是12*75% +４＝13GB  可以确认早期版本里一定是75%，新版本有没有调整不清楚)　

Logical Volumes

通常，应用程序与中间件厂商会有如何最好地对他们的产品进行磁盘空间分配的优化。数据库厂商一般会建议跳过文件系统(用裸逻辑卷)。随着更新的软、硬件技术的发展，‘处理过’的卷的性能是相当的。不管怎样，把不同的应用程序分配给各自的卷组(不同的物理硬盘)是好主意,这样可以避免它们影响。

LVM有很多功能是用来维护高可用性的，在多数情况下像LVM镜像(同一份数据写多份拷贝)和LVM Mirror Write Cache（黄按：对于镜像这样的多份拷贝，要保持其数据一致性有不同的方案，通常来讲两份拷贝的数据是一致的。在系统突然crash的情况下，可能一份拷贝更新了，另一份没有，那就造成了不一致。MWC就是只对两份拷贝不一致的数据块更新，NOMWC就是如果发现数据不一致时复制整个逻辑卷。选用MWC会地日常性能有影响，但是同步速度快。NOMWC日常影响小，但是同步大的逻辑卷可能会用很长时间，详细信息请参阅LVM Mirror相关内容）这样的特性对性能的影响是负面的。对某些读操作多的应用来讲，镜像可以提高性能，因为读操作可以从反应最快的硬盘上得到结果。多数情况下你需要把LVM视为一种空间管理工具，它设计出来不是为了提高性能。我经常对用户讲“总有时候你要决定要高可用性还是高性能,没可能两样都要，但是你可以使你的高可用环境性能好些”。

LVM parallel scheduling policy（黄按:

?          同时向两份拷贝写数据

?          从反应最快的拷贝读数据

?          优点：性能好

?          缺点: 系统down了，两份拷贝的数据可能都是不完整的)

比Serial/Sequential要好。

（黄按: Sequential schedule policy concept:

?          写一份数据,这份写完了再写下一份

?          只从一份拷贝读数据，不管哪一份拷贝更忙

?          优点:比较不容易丢数据

?          缺点: 性能下降 ）

 

LVM条带化(Striping)对强IO访问的应用有帮助。你应该在相似大小与速度的磁盘上建立条带。如果你使用LVM条带，就将条带的块大小设置得与底层的文件系统的块大一致。根据我们多年的经验块大小不要小于64K。事实上，最好比64K大不少。很多大型的应用涉及到在XP或是EMC这样的大阵列上配置LVM条带。简单的原则是:先利用磁盘阵列内部的条带功能，如果有需要，例如说性能原因或空间原因，再使用软件的条带化。要注意的是：要理解软、硬件条带化组合在一起的后果。例如，通过LVM在阵列上做多重的条带化，并且用小于1MB的块大小，可能会使阵列的串行访问预测算法失灵。

优化磁盘IO介事儿学问深了去了，用专用的分析工具、动态多路径等等不在本文讨论范围。