HPUX性能调优手册(5)

Context Switching Bottlenecks(上下文切换瓶颈)
现象:
- 如上所述的CPU瓶颈现象，并且
- 大量CPU时间消耗在切换 (GBL_CPU_CSWITCH_UTIL > 30%).
发生上下文切换可能有两种原因中的一种:正在运行的程序把自己的状态置为sleep(因为访问非常驻的虚拟内存，或是系统调用中的等待时间)，另一种情况是正在运行的进程序被调度调整，不在CPU上运行，因为OS决定需要运行一个优先级更高的进程了。当系统频繁地做上下文切换时，因为切换操作不可避免地带来一些开销，有用的进程可能会被拖慢。
发生过度的上下文切换的一个常见原因是非常多的fork操作(创建子进程的操作)。换个讲法，非常频繁地有新的进程序产生(可以假定也有大量的进程结束). 频繁的登录操作是fork操作的一个主要源头，因为shell的登录profile经常运行一些生命周期很短的进程。保持用户shell的rc文件比较简洁可以避免大部分类似的情况。我们也遇到过一些不安装代理程序的系统监控程序不停地远程登录运行一些命令。因为更快的系统可以处理更多的fork操作，很难给一个经验值，但是你可以通过间中监控metrics GBL_STARTED_PROC_RATE 看是不是有大于 50的情况，或是存在周期性的尖峰。用xglance来跟踪是哪些进程在做很多的fork操作不难。在process list报告界面选择
PROC_FORK  metric并排序。另一个有用的metric是PROC_CPU_CSWITCH_UTIL.
要是进程生成的速度并不是太高，那上下文切换太高可能是应用程序的问题。信号量(Semaphore)竞争是一个常见原因，因为进程总是总是受阻于信号量等待。通常你对应用程序本身很难做些什么，但有些外部控制可以让事情变得更有效率些。通常通过增加每个进程可以占用CPU的时间段，可以降低任务调度的超负荷。确认核心中时间片的参数(timeslice parameter)设置至少是默认的10（10个毫秒级的tick是0.1秒）,可以考虑把这个值加倍如果你不能通过调整负载来降低上下文切换率。
 
Memory Bottlenecks （内存瓶颈）
现象:
- 高的内存使用率 (GBL_MEM_UTIL > 95%), 并且
- 明显的pageout (GBL_MEM_PAGEOUT_RATE > 10), 或是
- 任何‘真正的’去激活操作 (GBL_MEM_SWAPOUT_RATE > 0),或是
- vhand进程持续工作 (vhand’s PROC_CPU_TOTAL_UTIL > 10%
or GBL_MEM_PG_SCAN_RATE > 1000).
- 进程受阻于虚拟内存 (GBL_MEM_QUEUE > 0 or PROC_STOP_REASON = VM).
当程序访问虚拟内存中的一个页面，而这个页面不在物理内存中时，这时会做一‘page in’操作。当HPUX需要在物理内存中整理出一些空间，或是当一个内存映射文件(memory-mapped file)被posted,结果是一个’page out’操作，过去被称做交换操作(swap),把物理内存中一整套相关的信息写到交换磁盘上，现在叫去激活(deactivations),所有属于相关进程的内存页都被标记，交换出去。这个可怜的进程被从运行队列中移除，放到去激活队列中，然后它没有CPU运行时间，也不能访问它的内存页，然后很快地它被交换出去。但这不是说它必须被交换出去!我们可以就这个专题讲很多，但不是在这里对你讲。
你需要了解的是:不要管’pagein’，这是正常的。当内存利用率高时，关注pageout,因为能常这时内存瓶颈的指示(也不总是，尤其在11.31版本!)。内存利用率不高时的pageout不用担心，适度的pageout是可以接受的。如果内存利用率小于95%,有一些pageout发生，通常是因为内存映射文件的写操作。在11.31中因为UFC（Unified File Cache）这变得更常见。UFC在本文后面单独成一章。如果内存利用率>95%,并且你发现pageout伴随着去激活的操作，那可能就真的有问题了。如果内存利用率<90%,那没事偷着乐吧。
可能你发现内存利用率高，pageout或是页面扫描(page scan rate)增高，也可能情况越来越严重直到系统重起以后(这是经典的”我们每周重起一下系统因为…”)一个通常的造成内存瓶颈的原因是内存泄露，这发生在程序申请了虚拟内存又忘了释放它。
如果你的PA parm文件组织得好，间中比较一下虚拟内存的使用(APP_MEM_VIRT) 对检查是否存在内存泄露是很有帮助的。用Performance Manager,你可以就APP_MEM_VIRT metric 用图形方式显示出来。如果你的应用程序没能较好地通过parm文件组织起来，可以用Glance然后以PROC_MEM_VIRT 排序，看使用最多内存的进程。在Glance中，选中一个使用虚拟内存多的（with a large virtual set size）进程，在Process Memory Regions 报告部分可以看到进程在每一region使用内存的详细信息。内存泄露的现象通常是DATA region随着时间的推移缓慢增长，但是也可能通过未做unmap操作的内存映射文件(MEMMAP/Priv region持续增长).
总得来说，如果有内存泄露，你会发现GBL_SWAP_SPACE_UTIL 增长。重起应用程序或是重起系统是一个暂时的解决办法。当然，修正问题程序是更好的解决方案。o
在11.23中，一个常见的造成内存瓶颈的原因是文件系统计缓存设得过大。11.31中，过大的UFC也类似。如果有内存瓶颈，你的buffer Cache（11.23）或是UFC（11.31）大于1GB,可以考虑缩小点。
注意(在2009版更新), 内存相关的metrics是‘懂了’的雷区。不进行非常深入的研究，就可以信任的metric是总的内存利用率(GBL_MEM_UTIL and GBL_MEM_FREE), 最不可信的部分是用户、系统、UFC部分的利用率(GBL_MEM_USER, GBL_MEM_SYS, GBL_MEM_FILE_PAGE_CACHE), 还有虚拟内存(GBL_MEM_VIRT). 这是因为底层的一些复杂结构，在包括HPUX的所有操作系统都做得不太好。想得到相对最好用的metrics，找Glance/PA的最新的补丁和相关的核心补丁。还需要注意的是，file page cache是否被统计为使用的内存。有人可能说，UFC保留‘旧’的页面满足再次访问的需要，这部分内存当然是free的。另一些人可能认为UFC里的内容都是准备回写到硬盘上的数据，所以是使用的，而不是free的。在统计数据中也面临相似的疑惑，所以有时被报告为free的，有时被报告为已用的。总之，对照以前用老式的buffer cache的情况，现在的情况不是太明确，提醒一下。
 
如果没有内存泄露问题，buffer cache或是UFC配得也合理。你还是面临内存紧张的压力，那唯一的解决办法就是再买些内存。大部分数据库都申请超大的共享内存段，你需要确保有足够的物理内存来避免它发生paging操作。要注意报告”out of memory”错误的程序，因为通常这可能是没有足够了的交换空间或是遇到配置的极限值了(查看上面关于系统设置核心参数部分的内容)
关于内存还有一个有意思的状况是使用很多共享内存的32位程序可以通过配置内存窗口（memory window）获益(对于需要运行几个实例的，比如说32位的Oracle,Informix,SAP等. 大的页面大小对某些程序很有效，保证内存的本地访问，避免TLB超负荷。Java以内存映射文件自己管理JVM中的虚拟内存，这个很复杂，关联到各种各样的Java参数。这个有点深了，只有你的应用程序供应商建议时才用。y
Oh yeah,如果这些还不够叫你头疼，Stephen有个很喜欢的话题是’假的去激活’(‘false deactivations’). 有时想HPUX会置于一个有趣的境地，当内存接近用完但是还没到引起pageout的时候你有时会看到去激活. 这很少见，但是你如果看到系统中没有paging操作但是有去激活发生，那就可能是这种情况了。这不是一个’真正的’内存瓶颈。被去激活的进程没有被交换出去就又被激活了。没有虚拟内存IO的产生，这只是OS在内存紧张时先发制人采取的一个措施。这情况只是有点讨厌而已，因为不能直接以去激活操作作为内存瓶颈的标志。
Swap sizing （交换区大小）
交换区的配置有两点很重要。你要确保至少有足够的可申请预留的空间。实际使用多少交换空间是完全不同的一件事，系统通常预留比实际会使用多得多的交换空间。交换区只有在swap发生时才被用到，只要虚拟内存申请发生，交换区就会被预留(reserved).
在磁盘setup部分提到的那样，你最少配置两个交换空间来保证交换真正发生时能比较快。确保它们的大小一致，在不同的物理硬盘上，有一样的交换优先级，比其他的交换区小些的一个数字。如果可能，将硬盘连接在不同的IO控制器上。Stephen的话是”保证瓶颈不在IO卡上” 。 用Glance的Swap Space报告或是swapinfo确认系统的大部分或是全部真正使用的交换区在这样的设备上。保证这一点以后，你可以通过几种方式来保证有足够的可预留的空间(watch GBL_SWAP_SPACE_UTIL) . 因为不实际使用的交换空间没有IO发生，你可以用些慢的空闲硬盘。如果硬盘交换空间不足，一定要的打开Pseudo Swap。我们不鼓励用文件系统交换区，但是你如果确认它不会被用到（优先级设成比其他交换区更高），那也成。