HPUX性能调优手册(6)

Disk Bottlenecks （磁盘瓶颈）
现象:
- 至少一个以上硬盘持续高使用率(GBL_DISK_UTIL_PEAK
> 50 or highest BYDSK_UTIL > 50%).
- 明显的队列深度(GBL_DISK_SUBSYSTEM_QUEUE > 3 or any
BYDSK_REQUEST_QUEUE > 1).
- 繁忙硬盘上的响应时间长 (BYDSK_SERVICE_TIME > 30 and
BYDSK_UTIL > 30)
- 进程或线程受阻于IO等待 (PROC_STOP_REASON =
CACHE, DISK, IO).
磁盘瓶颈是容易解决的:重新编写你的程序，保证所有的数据一直保持在内存里!内存老便宜了。可悲的是，这不总是(其实是从来不是)可能的。次好的方案是优化你的磁盘解决IO热点。理想的情况是把磁盘IO分布在尽可能多的IO卡、LUN和物理硬盘上来避免任一特定IO路径上的瓶颈。可悲的是，这也不总是可能的，因为程序的设计、重新布署所需的停机时间等等。
要找出热点，通过性能分析工具显示不同磁盘设备的利用率。sar和iostat都有独立磁盘的信息，Glance和PA就更不用说了。 Glance和sar在11.31中都包含了更详细的信息，可以以IO卡(HBA)为单位分析。分析通常这样开始，查看历史数据，重点在性能问题发生时间段中最繁忙的硬盘。通过BYDSK_UTIL metric过滤数据，观察利用率发展的趋势，然后通过BYDSK_REQUEST_QUEUE观察队列情况。如果你不是观察性能问题发生时的数据，那你优化的对象可能会搞错!如果一个硬盘在50%以上的时间繁忙，并且对应有等待队列，就有可能需要优化。注意PA的metric GBL_DISK_UTIL_PEAK不是一个平均值，也不是只针对一个硬盘。它是反映在一个时间段内最繁忙的那些硬盘的利用率，不同时间段内最繁忙的硬盘完全有可能是不同的。另一个有用的全局metric是GBL_DISK_SUBSYSTEM_QUEUE,显示平均有多少个进程受阻于IO等待。
 
很多旧时的性能砖家喜欢用磁盘的平均响应时间(Average Service Time)来做瓶颈的指标。比正常值偏高的响应时间的确可能指示瓶颈的出现，但是，注意你需要只衡量繁忙硬盘的响应时间! 我们要说”硬盘繁忙度低于10%的时候Service time metric根本就是狗屎”. 我们的粗略原则是这样的:如果硬盘比较忙(BYDSK_UTIL > 30)并且响应时间比较差(BYDSK_SERVICE_TIME > 30,也就是多少毫秒响应一个IO请求), 这样才需要注意。 注意:你会经常看到特定的地址平均响应时间(average service time)的值非常高，但是跟踪下去你发现，这些设备在做极少甚至没有IO! 在做海量IO操作的设备可能有着非常漂亮的响应时间数据。
如果你最忙的硬盘是一个交换区，那你的问题是内存瓶颈，先研究这个问题。也可以看看上面讨论交换区设置的部分。
在磁盘瓶颈出现时Glance可以提供非常有用的信息，因为它能够分别以硬盘、文件系统、逻辑卷、IO卡(11.31)为单位提供报告。你还可以看到逻辑IO与物理IO的对照，物理IO还可以细分为文件系统、裸设备、虚拟内存(paging)和系统级(inode操作)等等。可以在Process List中通过PROC_DISK_PHYS_IO_RATE 排序，找到IO操作最多的进程，进一步调出它打开的文件描述符和位移，这有助于找到具体的问题相关的文件。对于所有性能分析工具都存在的问题是磁盘内部的硬件对它们是不透明的。磁盘阵列可以显示为一个单独的硬盘，对阵列内部的分析要用到专门的工具。你可能需要从磁盘阵列的供应商得到这样的工具。
一些通常可以提升磁盘性能的原则是:
- 将IO分散到尽可能多的硬盘上，10个硬盘各自10%繁忙比一个硬盘100%繁忙要好。尝试着把忙的文件系统或是逻辑卷分布到不同的IO卡与磁盘上来获取最大的吞吐量。
- 避免过多的日志。不同的应用程序有不同的控制方式。对于VxFS,控制intent log是很重要的。vxtunefs可能会有帮助，对于建议的VxFS参数设置，参考上面的系统设置章节。
- 如果你足够细心，可心尝试通过scsictl命令调整特定scsi硬盘的最大队列深度。通常来说增大队列深度可能会提升并行处理能力，代价是有可能使硬件超负荷。如果你见到QUEUE FULL错误信息然后性能出现下降，你就需要把最大队列深度(max queue depth,scsi_queue_depth)降低。
 
有几条与磁盘相关的规律:
-  IO越小，响应时间越短，反之亦然。
- 串行IO的响应时间比随机IO的短(因为减少了磁头的移动)
- 要获得最大的吞吐量，对串行IO使用大的IO块大小
- 最大的缓冲的IO大小是64KB
- 最大的直接IO大小是256KB (在11.23中安装了相关的VxFS,VxVM补丁可以到1MB)
-  如果出现跨越边界的情况会造成一个IO被分成几个更小的IO，这些情况有:文件系统计块大小，缓冲链(buffer chain)，文件块(file extent)和LVM LTG边界。
大多数情况下，系统中大多数IO是由很有很的几个进程造成的。注意’滥用’IO的程序 – 产生海量的文件或是做大量的打开、关闭文件操作。可以根据’System’类型的IO来判定是不是这种问题（BYDSK_SYSTEM_IO_RATE ）。要深入分析，可以找做大量IO操作，并且用很多System CPU的程序。 如果在问题发生时使用Glance,看看Process System Call,调用是哪些系统调用。不幸的是，如果你没有源代码，那你对编程方面的问题也没什么好的处理办法。
Stephen还发现很多人不清楚一样东东叫”写前读”,这不仅发生在11.31，你需要了解它。无论是通过buffer cache,file cache还是直接访问都有可能发生，它有可能会造成性能下降。我们不讨论大小、数字这些其他文档也可以找到的东西，我们来讲一个简短的Stephen法则。如果你对buffer或是file cache做个小的写操作，而且buffer或是page还没有在cache里，或是做裸设备IO。如果写操作比8K的buffer或是4K的page还小(或是存在跨界问题),就会读这个buffer或是page的内容，做相应的修改后再做写操作。这绝对会降低小的写操作、随机写操作和直接IO的速度。
 
Buffer Cache Bottlenecks
现象:
- 在至少一个硬盘上有中等的使用率 (GBL_DISK_UTIL_PEAK or
highest BYDSK_UTIL > 25), 并且
- 持续较低的Buffer Cache读命中率 (GBL_MEM_CACHE_HIT_PCT
< 90%).
- 进程或线程受阻于Cache (PROC_STOP_REASON = CACHE).
如果你在11.23中看到这样的现象，如果有足够内存，你可以考虑把file system的buffer cache调大，尤其是处理NFS,ftp,Web,或其他文件服务的情况，前提是不要因为内存压力。 有些强IO应用可能从大的buffer cache获益，但最重要的是避免pageout发生。在实际环境中，我们见到更多的情况是buffer cache设得太大了。
另外，如果你使用一个数据库主要以裸设备的方式访问数据，那系统的buffer cache也不会发生作用，在11.31中也是如此。
在11.23中调整buffer cache,参考上面的核心参数部分关于bufpages和dbc_max_pct的内容。因为dbc_max_pct可以在系统不重起的情况下更改，可以尝试通过它来做些测试。就是要记住你如果增加了物理内存，buffer cache的大小也会跟着增加。我们坚决反对在HPUX 11.0和11.11中配置太大的buffer cache，在11.23或以后的版本中如果你内存够用问题不大。
如果根据上面的的现象，你怀疑buffer cache可能太大了，而且你经常看到内存利用率超过90%,而且你的Buffer Cache比1GB还大，那就把它改小点，改成比它现在的一半多点或是1GB. 改完了以后，再观察一下命中率。如此反复。最主要的目标是降低内存的使用率避免Paging out.
如果你的应用程序可以从很大的cache获益，你也有足够的空闲内存，那就配大些。有见过一个用户配过387GB!