HPUX性能调优手册(3)

                                                                               File systems - VxFS
如果要用文件系统(不用裸设备),那你就用VxFS (JFS) 并使用8K的块大小。我知道我们说过不讨论Oracle之类，但是，例外是对于存放redo日志和archive日志的文件系统，设成1K的块大小。而且，这几样东西应该用Direct IO(黄按:后面mincache=direct部分应该就是说的这个Direct IO)。可以看下Mark Ray关于JFS优化和常见配置错误的文档。
       想要最好的性能，就安装最新的OnlineJFS. 有了它，你可以通过设置不同的挂载(mount)选项来调整性能(参见fsadm_vxfs和mount_vxfs的man page). 下面说的有些选项只能在OnlineJFS下才可以用。而且，有些选项是可以在线改的，不用把文件系统umount下来。
       总得来说，对VxFS文件系统有下面的挂载选项
delaylog, nodatainlog
对VxFS文件系统主要处理随机读操作，就像典型的oracle应用，使用这个参数:
mincache=direct, convosync=direct
“虾米???” 简而言之，当主要是随机读操作时，文件系统缓冲这样的’预读’操作就没什么用：一个逻辑读请求会在缓存里找一遍，然后呢，没找着。所以性能会有所下降，因为几乎每个读操作都这么整一遍。当设置了mincache=direct以后，就会跳过文件系统的缓存，直接从硬盘上读数据返回给应用程序，跳过把数据写到缓存里、再从缓存里返回给应用程序这个过程。如果你设了这个参数，但是读操作有很多是顺序的，那你在性能上要吃大亏了，因为通过预读后面的数据到缓存中，很多读请求就可以直接从缓存中返回了，对性能提升有很大帮助。相似地，大多数写操作频繁的应用得益于文件系统缓存。Doug有一天不小心对一个写操作多的Postgres数据库设了这个参数，性能下降了50倍(不是50%). 但是，等等：我们也遇到过经常进行大量读操作的应用通过Direct IO获得了性能提升(刚好是个备份操作). 简单地说，JFS做的最大的一个实际上的IO读写块大小是64K. 如果一个进程一直要求1MB的数据块，JFS会把它分解成多个64K大小的实际IO操作. 在这个case中，使用了mincache=direct参数，使得实际发生的IO减少了很多. (黄按:从但是，等等开始逻辑上好像有点乱，最少我是got a tiny little bit confused)
再聊聊datainlog 和nodatainlog. 如果你看看HP
VERITAS File System Administrator’s Guide 的Performance and Tuning 章节里讨论 nodatainlog部分,会发现这样的描述”对同步写操作，设置成nodatainlog的文件系统大约比标准模式的文件系统慢50%左右，其他操作不受影响”. 我们对这一点完全不同意（现在你应该知道我们确实看这些东西，以不同的方式）.设置datainlog时大体上模拟同步写的方式，它可以允许8K或更小的写操作先写到intent log中,其数据和inode更晚一点被写入(异步)。只有系统crash时你才需要intent log.使用datainlog事实上产生了更多的IO操作。大的同步IO是不受影响的，读操作是不受影响的，异步IO是不受影响的。只有小的、同步的写IO才被存放到intent log中。Intent log中的内容仍然需要以异步的方式被更新到硬盘上…有一种观点这样会比将数据和inode异步写入要快些。这不是真的。所谓的同步IO,不像理论上的同步IO那样能保证数据的完整性。
   考虑一下这样的情形:将数据写入intent log成功了，write()函数返回。然后，当数据真正要被写入的时候，一个IO错误发生了。因为对应用程序来说写操作已经完成了，这个错误就不会被发现。在系统日志syslog中记录了’ vx_dataioerr’,但是应用程序并不知道没写成功。存在这样的可能性后面对同样的数据做读操作获得了成功，但是返回了过时的数据。我们还是觉得nodatainlog 比 datainlog强多了。(黄按：我觉得这个例子未必能说明Stephen的观点，数据写入intent log以后，后续的更新就应该是从intent log往磁盘上数据真正存储位置写。OS也应该是先成功地完成更新磁盘操作然后再从intent log里把这条记录删掉。如果更新数据时按假设得那样发生了IO错误，那intent log里相关的数据就还存在，应该还是可以判断出相关的数据是没有成功刷新的，后续的读操作OS是可以报错的。纯猜测)
再说convosync=direct,我见过一些用户的系统在使用这个选项时遇到问题。它确实会造成更多的Direct IO（物理IO比逻辑IO多）。把这个选项去掉后性能得到了提升。然后，可以观察到发生的物理IO减少了。这样做的副作用是读缓存命中率可能会下降。
convosync=direct选项就像VX_DIRECT缓存选项生效(参看vsfsio(7))而缓存没有被使用。去掉这个选项后你更多地使用缓存，也就更有可能遇到更低的缓存命中率。记住：有不少用户…大多数用户使用这个选项没有造成性能下降。
这个例子是描述特例：我们遇到一个特殊的case,一个大的32位的Oracle应用，因为share memory的大小限制了SGA的大小，从而限制了buffer pool的大小;更重要的是，它有68%的时间在做串行读操作。把convosync=direct去掉以后，buffer cache也增大了，物理IO被显著减少从而使性能得到了提升。
记住：这只是一个特例;
 
对于/tmp这样的数据完整性不那么重要的文件系统，本来系统crash也不常见，使用这个选项
tmplog 或是 nolog, mincache=tmpcache, convosync=delay
Nolog 运行起来就像tmplog，要是你给我买瓶啤酒再花一小时时间我可以给你解释。要是买两瓶啤酒，你就需要两个小时。
通常来讲，用日志记录越多信息、有更强大的恢复能力的选项，就会带来更差的性能。对比丢数据的损失和加硬件提高性能的开销，你应该有一个良好的数据备份和恢复策略，和UPS来防止断电。
重要提醒: JFS隔三差五就会有最新的补丁需要更新，安装最新版本的JFS软件和补丁保障好性能。有很多更新，仔细读读，Mark Ray的文档很有用，看看。
好吧没啥其他的好讲了…在unix下面可以把/tmp或是其他不需要保存的文件系统常驻在内存里。在HPUX里这个叫“Memory File Sytem”，在docs.hp.com可以找到些文档(memfs). 在11.23版本要安装个补丁才能用，11.31里更好使一些。我们没在用户环境里见到过实际应用，也不推荐使用。要是你内存够用想试试，把结果给咱说一声。
Network Setup
每一个网络环境都是独一无二的，尽管在现在的分布式应用架构下网络可以是影响性能的最重要因素，在系统级别几乎没有什么工具来优化网络性能，至少在SAM里。一个网络工程师曾经说过他通常建议用户准备一份netperf/ttcp工具（诊断传输层）或是iozone工具（诊断NFS），运行这些工具检查链路的传输性能，如果反映出性能问题就再通过其他工具例如lanadmin、trace、网络交换机统计数据等等进一步分析。你可以研究一下HP docs网站相关的工具和网络设置，或是在文档后面介绍的HP networking tools contrib包的’briefs’目录下面的东西
一些通常的经验是:
- 确保服务器至少与客户端有一样快的网络，并且正确地配置。
-  定期记录和检查网络拓扑和性能，因为随着时间的推移，网络性能通常会下降。 可以采购Network None Manager或是其他的网管工具
- 在一个NFS应用环境，采用NFS v3/v4,看下Dave Olker的“Optimizing NFS Performance”。这本书已经不出版了，但你应该还找得到。或是在docs.hp.com找“Managing NFS Performance”相关的内容。
- 服务器和客户端上，都打上最新的关于NFS,网络和性能相关的补丁。
Kernel Tunables
对Stephen来说，一个经常提起的case是有些SAM的模板(现在已经被替换掉了)对timeslice参数的设置是错误的。核心思想是不要盲目地相信任何人对核心参数的建议(有时候甚至是HP的，靠，我们是给谁打工的??!?) Stephen通常对想着‘一套参数打天下’的人不爽。如果你管理着很多业务相近的主机，那找一套用得不错地配置方案，然后推广到所有主机。但是如果你有时间一台一台调核心优化的话，Stephen建议你还是这么做。
还要注意到有些应用程序供应商会对核心参数有配置建议，最好听他们的，关键是你不这么干他们就不对应用程序提供支持！尽管你觉得他们的建议狗屁不通,他们也强制你按他们的要求去做。
下面是简要说明一些对11.23和11.31最重要的参数,包括它们的定义、范围和其他信息，可以查看SAM的在线帮助。比起早些时候，11.23和11.31的默认参数还行。随着时间的推移，可调参数控制的部分变小了，更多的核心表变成可以动态调整。因为’11.31’和一个似是而非的词充斥各个文档，我们在这里对11.23和11.31都还是用这个词，就是’ DEPRECATED-不建议使用该特性’ ，为嘛就不能干脆说我们不准备再用这个参数了呢？不管怎么说，下面是我们还关心的几个:
bufpages
在11.31版本，这个参数和nbuf都被“不建议使用了”,换句话说，不用管它们。 Glance仍然会显示有一点缓冲区缓存(buffer cache),但是这个没什么实际意义。现在，要关注的是文件缓存(file cache). 在11.23里，你可以用这个参数为固定大小的文件系统缓存设置一个页数(黄按：意为buffer cache的大小是静态的、固定的)，如果你设了bufpages（黄按:bufpages不为0）,那就保证nbuf为0. 如果两个参数都不为0,那么参数dbc_min_pct和dbc_max_pct的设置就会被忽略。对于一个物理内存大于4GB的11.23的系统，我们建议将buffer cache设为1GB大小，可以通过将bufpages设为262144来实现。对于安装11.0或11.11的内存更小些的系统，我们建议的buffer cache是400MB（bufpages设为102400）. 对大型的文件服务器如NFS/FTP/Web server,你应该在可能的情况下尽量增大buffer cache. 如果你更喜欢用dbc_min_pct and dbc_max_pct而不是bufpages,那就将dbc_max_pct设成相当于1GB的值。我们在下面会与磁盘瓶颈一起讨论buffer cache.
dbc_max_pct
这是另一个只和11.23相关的参数(11.31里没用),它决定动态的文件系统buffer cache最多可以增长到物理内存的百分之多少(如果nbuf,bufpages都设为0的话).默认是50%,绝大多数情况这个值设备太大了。Buffer cache设备太大，你更可能面临空闲内存太低，然后被迫做page out操作再缩小buffer cache来保障其他程序的正常工作，你不会希望遇到这种情况。如果你想用动态的buffer cache, 先将dbc_max_pct 按上面的建议设一个相当的值(比如说，对一个有20GB内存的11.23服务器，设成5,就是20*5%=1GB). 把dbc_min_pct设成相同的，或是更小一点的值(不会影响性能，只要你别弄得内存紧张到需要pageout) 我们在下面还有一个章节对Buffer Cache深入挖掘。
在11.31里，文件系统的数据已经不有buffer cache了，你就不用关心buffer cache的大小，而是下面讲的Unified File Cache - UFC的设置.
NOTE: 使用大buffer cache造成性能下降的可能性现在基本不存在了(每一个版本都更好一些). 如果你有充足的内存想设一个大Buffer cache,来吧！整吧! Stephen见过不少客户(11.23)设置越大的buffer cache,应用性能就越好。刚好数据库要做两样事情:从文件系统做大量的串行读，然后写(也读)到裸设备里. 这是一个正面典型。现在高达几个GB的buffer cache已经很常见了。
default_disk_ir
这个设置让磁盘驱动器不等到磁盘IO结束就报告(IO完成),和对每一个硬盘执行This scsictl –m ir=1 的效果一样。对XP这样的有自己的缓存的大型阵列来说，这样做没有效果，但是对传统的硬盘有。默认值是0，但建议你就设为1. 你可能说这是放TM臭屁！（黄按: 这个不是太肯定，sphincter 意为括约肌，Stephen原文为This recommendation may be a ‘9.5 on your sphincter scale,’ 专门google了一哈，有一篇小文把放屁分为十种境界，气体通过括约肌释放出来的过程即为放屁. 起码字面上是一致的，sphincter scale 9/10的场景还真有些销魂，而且我觉得Stephen说得出这种话来。 Scale&defid=2034503），但这是从系统频繁crash、数据恢复机制也不完善的年代遗留下来的观点。据我们所知设成1没什么坏处，不会影响数据的完整性。
filecache_max and filecache_min
只与11.31及以后的版本相关,它们是配置动态Unified File Cache的范围，基本上完本替代了Buffer Cache的功能。 目标还是一样，不要造成内存紧张。你绝对要读一下长气的man page：man 5 filecache_max ，也瞄一眼这篇文档后面的UFC章节。底线是:UFC默认设置到物理内存的5%-50%。如果你觉得内存紧张，通常就把filecache_max调小点。就像前面11.23里的例子那样，内存多就配个大的UFC,没问题。
max_thread_proc, maxuprc, maxfiles, maxfiles_lim, maxdsiz, maxssiz,
maxdsiz_64, and friends
有一堆参数是调整一些什么东东的最大值。过去这些参数比较重要，因为有比较多的弱智程序做些蠢事。现在，更可能是一些值比预期的workload所需要的低了。所以你觉得默认值太低就调高一点，或者按软件供应商的建议调。如果你确信没有谁会运行一些流氓程序，例如不停地申请内存直到溢出，把maxdsiz设到最大值。
Maxusers被删掉了，太好了。Doug听Stephen说过计算核心参数的公式通常都比较弱智。(黄按，以前的版本很大参数是根据Maxusers值计算出来的)
nfile
同时能打开的最大文件数(不是最大能打开多少文件，是通过Open()函数同时能打开多少文件).默认值是够用的，如果你在Glance里发现File Table利用率>80%(System Table Report部分),或者见到“File table overflow”错误，就调大nfile. 方法和nflocks (max file locks)一样. 要是配置一个大型文件服务器，你比较可能需要调大这些参数。我们发现大多数用户不知道同一个文件可以有多个文件锁定—通过一个进程或多少进程。
ninode
设置HFS文件系统的inode缓存大小。VxFS cache 通过vx_ninode调整。
nkthread
最大的核心线程数。大多数情况默认值够用。如果你使用多线程的应用，就适当调高点。
nproc
和你期望的负载高度相关，但是大多数系统默认值是够用的。如果你了解得足够深入，就设高点。对一个只有400个进程的系统，不要盲目地设到30000这么高。因为这个有些副作用，比如说增加了midaemon的共享内存段(用于Glance工具来追踪进程信息) Glance的System Tables Report 有process table的利用率统计，如果正常运行时利用率超过了80%,就可以考虑调高些。
shmmax
我们发现过64位的Oracle因为这个参数设得太小，不得不将SGA共享内存分散(ipcs –ma). 这样会降低性能。如果你有足够的物理内存，就让数据库申请尽量大块的内存. 将这个参数设到最大值(除非你担心流氓程序把共享内存占光，这种事儿也不是没有). 默认值是1GB,对大型服务器来说有点低。
swapmem_on
伪交换（Pseudo swap）是用来增加可预留的虚拟内存的，它只有你没办法配置足够的swap时才有用，在11.31里它总是打开的。例如,你的swap空间比物理内存要小的话，在11.23里如果不把伪交换打开你就没法使用到全部的内存。伪交换对性能是没有影响的，除非是系统想申请比device swap(黄按:应该是指硬盘swap空间)更多的预留交换空间。当你要申请的全部预留交换空间超过device swap空间时，如果没有开启伪交换，程序就会出错”out of memory”,否则系统核心就开始在物理内存中锁定页面。如果这种现象发生，在Glance里看’Used memory swap’就会快速增长。这是个麻烦。简单的原则是：如果有足够的device swap空间，你不用管这个参数的设置。如果你的device swap空间不够，那就设置这个参数。11.23以上的版本可以使用100%的内存做伪交换(黄按:解释了前面的疑问，11.11以前是75%,11.23以后是100%了)，在11.31里这个参数总是打开的，不能改。建议根据你的负载配置足够的硬盘交换空间。
timeslice
让这个值设为10. 如果设成1,通常会造成太多的上下文切换(context swithing), 系统要处理比通常多10倍的时间片中断，还有可能会种造成锁竞争(lock contention)。我们从来没见过哪个生产系统能过把timeslice设得小于10获得了什么好处。对它忘掉“看情况而定”这个原则吧，设为10别改! Stephen现在还见到有机器错误地设成1的。
vx_ninode
JFS inode cache可能是一大块内存。如果你的内存超过1GB,表的默认值很高(例如，8GB内存最多可以对应25万个VxFS inode) 但是，表默认是动态的，所以没有持续的文件访问是不会占用内存的。你可以用vxfsstat命令来查看。如果vsfsd系统进程用了太多的CPU,那它可能是在浪费资源来尝试缩小cache.如果这种情况发生了，可以考虑给cache指定一个静态的值。注意你不能把vx_ninode设得比nfile还小。更详细的信息，可以在“Commonly Misconfigured HP-UX Resources”白皮书里查阅JFS Inode Cache部分内容。
通常的原则是，别去动它。如果你使用一台文件服务器同时访问大量的文件，并且有这样的出错信息vx_iget - inode table overflow,那就把这个参数加大。
   有人会说”这是动态的，我管它干嘛呢?”.你见过有人在根目录下面做find操作吧，你知道多长时间就会把这个表撑满吗？如果你的OS比11.23还早，就把这个参数设到20000.