Networking Bottlenecks
现象:
- 高的网络传输数据量 (与配置相关) 或是高的利用率
(BYNETIF_IN_BYTE_RATE or BYNETIF_OUT_BYTE_RATE or BYNETIF_UTIL
> 2*average).
- 任何的输出等待队列 (GBL_NET_OUTQUEUE > 0).
- 比正常时更多的进程受阻于网络 (PROC_STOP_REASON = NFS, LAN, RPC, Socket (if not idle), or
GBL_NETWORK_SUBSYSTEM_QUEUE > average).
- 一个CPU有高的系统模式或是中断类型的利用率，而其他的CPU大部分空闲 (BYCPU_CPU_INTERRUPT_UTIL > 30).
- 由lanadmin的输出，经常看到下列信息增加 “Outbound Discards” or “Excessive
Collisions”.
网络瓶颈可能很难分析，系统级别的工具没有提供足够的信息用来分析。Glance 和PA有以网卡为单位针对包、冲突、出错率和利用率(BYNETIF_UTIL)的指标。冲突(Collisions)通常来讲不是一个好的性能指标，在网络中发生冲突是难免的，但有时候它指示双工模式不匹配或是网络超出了标称值。过度的冲突确实意味着瓶颈。在系统级，观察比正常时传输量大或是网络占用率高的时候（GBL_NET_UTIL_PEAK）,再看这个时间段里是否有输出队列(GBL_NET_OUTQUEUE). 要小心，我们曾遇到过这个metric卡在某一个非0的数值上，而这时网络上并没有负载。所以你要看网络传输的上升，看这个时间段内又没有重复的规律。观察到比正常值高的网络等待状态也可以说明网络瓶颈(从 PA’s network subsystem queue metric而来).。netstat和lanadmin命令可以有详细的输出，但是它们提供的信息可能比较难理解。ndd命令可以显示并且更改网络相关的参数。看参考材料HP Networking tools contrib archive中Briefs目录下有ndd和网络优化的一些资料。Network Node Manager这样的工具可以用来从非系统的角度来监控网络。
高的冲突率(High Collision Rates)曾经被发现在双工模式(Duplex)或是速度设置有问题的网络上，纠正了配置后，问题就得到了改善。
如果大量使用NFS,那nfsstat命令和Glance里的NFS报告可以用来监控相关流量，尤其是在Server端。如果System report报告很多的某个客户端做很多的NFS操作，在那个客户端上运行Glance,看哪个进程引起了这个现象。
Other Bottlenecks
现象:
- 没有明显资源瓶颈现象
- 进程是活跃的，但是有明显的时间受阻于其他资源
(PROC_CPU_TOTAL_UTIL > 0 and PROC_STOP_REASON = IPC,
MSG, SEM, PIPE, GRAPH).
要是你一路找下来直到这最后一个部分，那你面临的境地确实有趣。性能不好但是没有明显的瓶颈。你最好的资源就是专注在现象方面。比如说，不同时间段性能不一定都是一样坏。具体在哪个时间点差？做记录，回溯历史数据，比较性能好与不好时Glance窗口上显示的信息。有没有哪里个全局的指标看起来不一样？特别要关注进程受阻状态(除了Priority还有哪些原因?)。信号量和其他进程间通讯的子系统经常有些内部的瓶颈。在PA中，找GBL_IPC_SUBSYSTEM_QUEUE比正常值高的值。
等你知道问题什么时候问题发生，想办法确定哪些进程与问题相关。所有应用程序受到的影响是一致的、平均的吗？如果只有一个应用程序受影响，进程最经常等待的资源是什么？是否是只有其他某个程序运行时间题才出现（可能有些内部关联影响）？可以在Glance里看进程的等待原因与系统调用，看它正在做什么操作。在PA中，要注意
e PROC_*_WAIT_PCT metrics ，它们实际上是表示进程整相生命周期以来的数据，而不是最近的数据采样周期。一个试验的但是不好的方法是在你不确定的情况下把一些用户或是程序从系统中移走看会不会好些。还有个方案，call Stephen做个咨询服务。
要是你已经竭尽全力优化系统了，你可能会想“什么情况下我才可以说这就是程序开发得太烂了”，其实任何时候都可以，尤其是如果这样能让你爽的话。
11.31’s Unified File Cache
下面这一段稍稍深入一点介绍11.31中一个性能相关的大变化:UFC,(Unified File Cache),也叫文件页缓存(file page cache)。
我们已经讨论过什么控制UFC的大小(filecache_max and filecache_min). 我们不讨论内部机制之类的东东。因为旧的概念buffer cache在11.31里基本上不用了，只是让你了解一点UFC.
Buffer Cache在11.31中依然存在，只是不再显眼了因为它不再对通常的文件IO做缓冲。我们参考材料中的另一个文档有内部参数r discovered_direct_iosize 的介绍(还有很多其他的JFS/VxFS 文件系统参数，所有这些在参数在vxtunefs的man page里都是没有的)。 你需要知道，file cache在小于discovered_direct_iosize的读写操作时被使用，而且预读与异步写也是被允许的。Buffer Cache可能有不同大小的buffer,file cache以4KB的页为单位。另一个区别是JFS不再进行’Flush Behind’. 现在，被改变的页面被告vhand进程和vxfsd进行flush操作，所以在11.31里你会发现这些进程更活跃。
在11.31以前，HPUX使用buffer cache进行读、写和sendfile的访问。另外有个独立的Page Cache处理内存映射文件[mmap()]访问。因为它们是不同的，在这两种方式之前发生数据交换会造成严重的性能问题。如果一个文件在同一时间被通过两种方式访问(buffer cache和memory mapped),你没办法确认文件里的数据到底是什么样子的，这样限制了将某些应用移植到HPUX平台。在11.31中，UFC使移值更容易些。
好的，记住，我们不会在这里讨论太深入的东西。核心通过虚拟内存子系统来管理UFC的映射，与它管理其他的像共享内存、共享库、共享文本段与’process structure’很像。在11.23中，File Cache表现为User memory. 如果你上过HP Internal的培训或是读过Chris Cooper的HPUX Internal的书，又或者参加过Stephen的有关于系统内部与性能的研讨会，那你已经了解什么是Pregions,regions,virtual frame descriptors（vfd）和disk block descriptors（dbd）. Vfd 用来在内存中定位一个页面，dbd用来在硬盘上定位一个页面。UFC在file cache中通过vfd与dbd的btree来定位4KB大小的页面。这样能过btree定位cache中页面可提供更高的访问。OH YEAH:UFC也支持ccNUMA架构，支持大页面。
UFC and bufcache differences
Buffer Cache是基于buffer的，通常使用8KB的buffer大小，采用最近使用算法（Least Recently Used algorithm）。 UFC使用4KB的页大小,采用最近未使用算法(Not Recently
Used algorithm.)。 UFC通过vhand管理(虚拟内存子系统). File cache页通过其自己的资源组(File Cache Memory Resource Group)申请，所以也通过自已的模式释放。在11.31中，可以预料到vhand会更加活跃，因为现在它负责判断File Cache中页面的过期与更新。现在，内存压力出现时，vhand可能没办法保证腾出空闲页的操作的速度。所有在11.31中出现了inline paging – 一个进程或线程需要占请内存的话可以在其自己的上下文中执行vhand paging代码（如果它得不到申请的内存，就会出错一个’fault’）.
在性能工具中，buffer Cache与UFC有很大区别。对于11.31版本，Glance增加了GBL_MEM_FILE_PAGE_CACHE,应该是用来指示UFC的大小，但是Doug的测试表明这不一定是准确的!这涉及到这个领域内的几个问题，有些有核心数据结构本身的问题，所以也会影响包括Glance在内的所有工具，使这些metric和用户/系统内存metric都发生了偏差。问题将来可能会得到解决，最近的版本已经好些了，不要认为哪些数字是绝对可信的。如果你想自己测试，可以在一个非生产系统上测试。在一个空闲的系统上增加最小filecache,同时监视内存的统计数据（比如说Glance的Memory report）. 一般人可能会推测你将观察到Free Memory下降同时File Cache增加，下降与增加的幅度与你调整的大小相当。你实际观察到的现象可能会不太一样。这是因为(在Glance4.7版本)，非活跃的UFC部分被隐藏起来，显示为用户或系统内存。FileCache Metric可能显示的值和这个命令的输出一样(kcusage filecache_max),这个事实上比你设定的FileCache_min要小！
你看了以后开始摇头了吗？现在，我们确认事情正在改善，但是了解现状是好事。底线中在11.31中，用户内存(在更轻一些的程度上说,系统内存也是)的指标是值得怀疑的。在工具中显示的FileCache大小不一定是其真正的大小。幸运的是，空闲内存与全部已用内存和其他一些我们用来判断内存瓶颈的指标是准确的，可信的.
最后，是几个除filecache_max/filecache_min之外的我们不准备详细解释的参数和选项，如果你想多了解一些就自己去查查：
? fcache_seqlimit_system/fcache_seqlimit_file – 系统中串行访问的极限值与每个文件串行访问的极限值，都表现为最大file cache大小的百分比，默认值都是100.
? fcache_fb_policy – 可以用来找开flush behind. 在11.31 (不像 11.23)中因为性能的考虑默认是关闭的。
? fadvise()/fcntl() – 编程用到的东东.可以用来设置ccNUMA的策略与大页面设置，文件同步周期等。
Cells, Cell Local Memory, Locality Domains, NUMA Latencies
and Processor Sets
下面讨论的是关于Superdome这类基于cell结构的服务器。这只是一个选读内容。针对Cell/ldoms相当复杂，在这块我们要叫你觉得难受了，但是…这个确实对性能有些正面的或负面的影响，这篇文档不就是讨论性能的么？看起来我们像是讨论过一些底层的东西了，但我们确实没有！如果这还不够让你发懵，我们确信可以给你这样的受虐狂指个地儿，走着…
The NUMA Hierarchy (NUMA架构)
我们要跟你讲讲不是NUMA架构的东西做为背景知识，然后我们聊下进一步的性能相关的东西。
NUMA的物理层级结构，由一个可能是多线程的CPU,到一个可能支持多核心的插座，到前端总线，到cell板，再到一或两级交叉开关。从操作系统的角度来看，一个物理上的cell板，抽象为一个本地域Locality Domain (LDOM).
在这样的架构中延时根据源与目的地而不同。最少延时的情况是同一前端总线的核心之间的Cache对Cache的数据拷贝(85ns). 其次是同一个cell板中，核心访问内存(cache miss,185ns)。一个不在同一个前端总线的cache to cache miss是开销最大的，即使是在同一个cell板中(277ns, 466ns)。在一个大的系统中Cache-to-cache misses的开销还要大(最大 677ns). 经过一跳的memory miss开销386ns,两跳需要460ns. 可以通过几种方式降低Cache miss造成的延时。选择正确的系统:1) 小型的总线型的主机会提供更好的单数据流性能 2)如果负载较大，Cell based主机可以提供更大的吞吐量。在一个NUMA架构的主机，你要考虑把共享可变数据的部件尽量安排得近一些。最后，如果应用程序能用Cell Local Memory最好。
Cell-local memory
我们试着描述这个概念.Cell Local Memory (CLM)是一个cell板中的内存块，显示为一部分地址空间。CLM与其他Cell板中的内存不会交错访问(Interleave). 在同一个Cell板中的CPU访问这部分地址效率最高. CLM的大小在启动时可以设置。
在11.31中，核心大量使用CLM, Oracle 10gR2使用CLM. 不是专门为NUMA架构设计的程序也可能从CLM获益。 Private Data（希望你知道Private Data和其他Stack之类指的是什么）由CLM中申请。共享数据(Shared data,由交错访问的内存中申请，现在你应该知道Private data是啥了).
过去，CLM并不真的一定起好作用。每个线程申请本地的资源-它生成时的本地。CLM由本地申请，然后不幸的是，线程好像很快就被迁移到其他的Cell了。结果是之后的访问变成了一个远程的CLM!
配置CLM有几样东西要考虑:如果你的系统有6个Cell会怎么样？其中5个是Remote的！如果你的程序可以使用CLM,你获得的结果可能是一个大幅提升或是一个小幅的下降。
一些偷来的(借来的?)建议初始值如下:
? Any O/S with Oracle 10gR2 87%
? 11.31 with earlier version of Oracle 37.5%
? 11.31 with non-NUMA aware apps 37.5%
? 11.23 with non-NUMA aware apps 25%
Controlling placement
下面的一个启动策略的简洁，你可以看到在一个Cell/ldom-based系统中如何影响进程在’哪里’运行.
?一个新的进程在负载最轻的locality中生成(黄按，我的理解是指在负载最轻的cell中生成)。?
新的线程在同一个locality（cell）中生成，每个CPU对应一个（线程）
? 它会向下一个负载最轻的cell迁移。
? 进程和线程可以随意迁移(在不同cell间) – 没有绑定
? 所谓的‘home locality’是被选定的…Cell Local Memory在这里被申请
线程通常会HPUX的任务调度依据繁忙程度等’移动’.
为了让CLM 发挥作用，我们需要把每个线程绑在它的home locality上。最简单的实现方式是不使用默认的启用策略(launch policies)。简单的办法是用命令
mpsched –p
, 来使用一个非默认的启用策略。Mpsched命令控制特定的进程或线程在哪个CPU或是cell上运行。后续的线程应该被指定到它们产生的LDOM.这样就把线程与它们的LDOM绑在一起了。参考mpsched(1) 研究相应的策略: RR, RR_TREE,LL, FILL, FILL_TREE, PACKED, NONE. 我们不在这里具体解释，只是提一下。
你可以用mpsched来检查localities 和 CPU,将一个进程绑定在一个特定的CPU,在一个特定的LDOM中执行命令，在同一个LDOM中运行进程的所有线程。
另一个控制的方式是用Processor Sets…又叫 PSETS.基本上你跟几乎任何人提起PSETS,他们都立马晕菜了。
你可以用PSETS:
? 对特定的工作指定专用的CPU
? 通过分隔工作量提高cache 和 TLB 效果
? 虚拟移除一些CPU
? 隔离有很高中断处理负载的CPU
? 对实时性要求搞得的工作提供一个接近实时的环境…通过 Real Time PSET
使用PSETS也有缺点，要是不熟悉设置的过程灰常痛苦。重起以后 PSETS设置就失效了，而且用PSETS时任务调度系统一点灵活性都没有。
对想用PSETS的人，绝对要读懂psrset(1). 通过 psrset你可以生成一个新的PSETS,指定CPU,把进程绑定到CPU组，在一个PSETS中执行命令，指定某一用户的进程到一个PSETS. 还可以显示PSETS的属性，指定给它的进程等。
最后我们提下 RTE PSETS (Real Time Extensions).这也是通过 Psrset命令来为实时任务预留CPU. 这是一个这样的PSETS, 不处理外部IO中断，不调用其他进程也没有核心的守护进程。
我们说过会讲一点Oracle和CLM还有一些性能提升的问题，来吧…
在Oracle 10g中默认就打开了 NUMA的优化。在以前的版本在，这是可选的，但是默关闭的。现在看来各个版本的Oracle都打开优化了。我这么讲是根据去年我遇到的情况。以前，你必须了解它并且打开它。在参数文件里的相关参数是
_enable_NUMA_optimization=true. 我们之前提过如果有人看到多个Oracle的相同大小的SGA指向同一进程号,这通常是因为shmmax比数据库管理员要求的SGA要小，所以它被分成了几个shmmax这么大的段。最近，你比较可能看到几个相同大小的共享内存段但是和shmmax的大小并不一致！这就是因为上面我们提到的这个参数被设为True了。我们还是以Oracle 10g为例，因为它默认就是这样。还是要记住，在任一Oracle版本，你可以把这个参数设为False. 这样使用几个SGA是基于性能考虑的正常结果。
在一篇Oracle的文档中他们说Oracle对每一个进程组和在多个组间做条带化的段生成一个共享内存段,有多个段的情况下性能会更好。他们还说内部对NUMA做了优化，降低了大型系统计中远程访问cache不命中的情况。
Stephen在实际情况中看到的是这样:在几个Cell构成的系统中，就会有几个相同大小的共享内存段，和一个更小一些的共享内存段(条带化的). 还有一个很小的bootstrap段。每一个段都会指向同样多的进程(对那个Oracle实例)。就是说在同一台机器上有多个Oracle的实例…和Cell的数量一样多。
重要说明: 这个参数设为true只有确保下述条件时才能使性能获得很大提升: 在系统中设置了CLM. . 问题: 如果CLM没有配，这个参数设为True,Oracle还是会把SGA分成几段并使用CLM…,它假设CLM是设置了的! 最好的情况下，你获得的性能与一个大的共享内存段一样。我的观点是，当进程与线程开始迁移时性能一定会下降。如果没有配置CLM,Stephen建议设置_enable_NUMA_optimization=false.
现在: 一年过去了我们告诉你…Oracle发布了一件补丁 (documented as 8199533 as of 5/15/09)来 disables NUMA优化(_enable_NUMA_optimization=false)，并且设置 _db_block_numa=1.
如果你看完这些并且活下来了，你还很想了解更多(或者你酷爱受虐),那就到
docs.hp.com搜索LORA. 意为 Locality-Optimized Resource Alignment，这地儿有不少东西看，可能和你的系统相关。在参考部分我们也放了一个Oracle-安腾的白皮书。
结论
对于好的性能来说没有结论：冒险永不停止。收集有用的信息，增强你对正常运行状况的了解,一次只改变一样东西，不要把时间花在不是问题的地方。
下面是Stephen最常遇到的情况，从最常见的到最不常见的:
1. 根本没有瓶颈. 很多系统配置过高，利用率很低。这是为什么虚拟化与合并这么流行。如果你的系统是这样，那么恭喜，现在你大概知道正常的状态是怎样，等不正常的时候怎么查找了。
2. 内存瓶颈。 大约一般的情况只要把过大的Buffer Cache调小就解决了。另外一般的情况，系统确实需要更多内存.
3. 磁盘瓶颈. 当磁盘不是因为内存压力造成的时候，解决通常是通过某种负载均衡(比如说把数据库迁移到条带化的卷). IO瓶颈越来越常见了。
4. 用户CPU瓶颈.设计得缺乏效率的进程经常是原因。你可以重新编程或是用更快更多的CPU.
5. 系统CPU瓶颈. 相当少见，通常是编程的问题。
6. Buffer cache 瓶颈:配置得太小的buffer cache会让IO性能很差，通常配小的原因是配错了。
7. Networking 或其他瓶颈.
要记住的最重要的事情是:性能调优是一个将快要没用的学科，因为不远的将来所有的系统可以自动地优化… 是的！市场宣传这样讲已经很多年了，但我们认为这不可能！性能优化不是一门科学，它更像是集合了艺术、魔法、一些烟雾和一点点运气。
References参考信息
HP Developer & Solution Partner portal:
HP Documentation Archives:
The Oracle database on HP Integrity Servers whitepaper:
Customer Performance Team’s Common Misconfigured HP-UX Resources whitepaper:
/en/5992-0732/5992-0732.pdf
Mark Ray’s JFS Tuning paper:
/en/5576/JFS_Tuning.pdf
HP Software system performance products:
http://h21007.www2.hp.com/portal/download/files/unprot/devresource/Docs/TechPapers/PakPerform.pdf
HP Networking tools contrib archive:
ftp://ftp.cup.hp.com/dist/networking/
