在Oracle M5000 Enterprise服务器上的Solaris 10上，我们已经运行了几年的ZFS，这些服务器拥有32个CPU核心和256GB的内存。 我们正在这个服务器上运行一个数据库/应用程序，看起来很重。
我们在UFS上遇到了I / O问题，并通过切换到ZFS解决了这个问题。 我们有一个NetApp存储单元，通过光纤通道呈现磁盘，然后在单个LUN上使用操作系统级别的ZFS进行格式化。 起初，我们遇到了应用程序内存方面的问题，不得不将ARC大小限制在128GB内存。
现在我们开始看到的问题是ARC正在变得越来越困难。 在此期间，CPU有时超载0％的空闲时间。 应用程序进程停顿，自动化进程开始运行。
我一直在研究这个问题一段时间，并咨询了所有似乎相信我们只需要一个更大的机器或让供应商优化他们的代码的各种来源。 我们正在考虑购买M10-4，并且一直在与应用程序供应商合作，但是我想知道是否还有其他事情可以做。
任何帮助将不胜感激，让我知道是否需要更多的信息。
以下是arc_summary.pl的输出
System Memory: Physical RAM: 257614 MB Free Memory : 79033 MB LotsFree: 4022 MB ZFS Tunables (/etc/system): set zfs:zfs_arc_max = 137438953472 ARC Size: Current Size: 131043 MB (arcsize) Target Size (Adaptive): 131072 MB (c) Min Size (Hard Limit): 64 MB (zfs_arc_min) Max Size (Hard Limit): 131072 MB (zfs_arc_max) ARC Size Breakdown: Most Recently Used Cache Size: 6% 8190 MB (p) Most Frequently Used Cache Size: 93% 122881 MB (cp) ARC Efficency: Cache Access Total: 217693264863 Cache Hit Ratio: 99% 217640359356 [Defined State for buffer] Cache Miss Ratio: 0% 52905507 [Undefined State for Buffer] REAL Hit Ratio: 67% 146336547931 [MRU/MFU Hits Only] Data Demand Efficiency: 99% Data Prefetch Efficiency: 96% CACHE HITS BY CACHE LIST: Anon: 32% 71281340234 [ New Customer, First Cache Hit ] Most Recently Used: 0% 172508676 (mru) [ Return Customer ] Most Frequently Used: 67% 146164039255 (mfu) [ Frequent Customer ] Most Recently Used Ghost: 0% 3430197 (mru_ghost) [ Return Customer Evicted, Now Back ] Most Frequently Used Ghost: 0% 19040994 (mfu_ghost) [ Frequent Customer Evicted, Now Back ] CACHE HITS BY DATA TYPE: Demand Data: 62% 136382108166 Prefetch Data: 0% 1145425065 Demand Metadata: 4% 9980846285 Prefetch Metadata: 32% 70131979840 CACHE MISSES BY DATA TYPE: Demand Data: 19% 10410690 Prefetch Data: 72% 38324623 Demand Metadata: 1% 874219 Prefetch Metadata: 6% 3295975 以下是从vmstat输出：
# vmstat 5 kthr memory page disk faults cpu rbw swap free re mf pi po fr de sr m1 m1 m1 m1 in sy cs us sy id 0 0 0 40892888 93939912 256 1411 165 26 26 0 0 8 1 2 0 5651 274471 42913 2 5 93 0 0 0 22113320 81957648 118 1324 3 0 0 0 0 0 0 0 0 5631 313043 58903 2 35 63 0 0 0 22145624 81977312 353 459 0 746 746 0 0 145 0 0 0 5177 379709 58255 2 33 65 0 0 0 22150976 81982088 120 1329 0 0 0 0 0 1 0 0 0 5200 314711 59490 2 33 65 0 0 0 22147600 81981680 504 1834 0 8 5 0 0 5 0 0 0 5197 334201 58339 2 32 66 0 0 0 22146160 81982544 715 610 0 5 3 0 0 2 0 0 0 6296 364301 58900 2 35 63 0 0 0 22116584 81960496 678 1928 0 3 3 0 0 1 0 0 0 5178 351160 58947 2 34 64 1 0 0 22107080 81949528 95 1095 0 0 0 0 0 0 0 0 0 4531 309206 58450 2 35 63
以下是zpool iostat的输出：
# zpool iostat ntapdatatel 5 capacity operations bandwidth pool alloc free read write read write ----------- ----- ----- ----- ----- ----- ----- ntapdatatel 1.07T 437G 10 13 1.07M 1.01M ntapdatatel 1.07T 437G 0 0 51.2K 4.00K ntapdatatel 1.07T 437G 0 0 0 0 ntapdatatel 1.07T 437G 0 95 0 6.47M ntapdatatel 1.07T 437G 0 0 0 0 ntapdatatel 1.07T 437G 0 0 0 0 ntapdatatel 1.07T 437G 0 0 0 0 ntapdatatel 1.07T 437G 0 0 0 0 ntapdatatel 1.07T 437G 0 0 25.6K 0 ntapdatatel 1.07T 437G 0 87 0 5.16M
和文件系统属性：
NAME PROPERTY VALUE SOURCE ntapdatatel type filesystem - ntapdatatel creation Sun Oct 28 17:09 2012 - ntapdatatel used 1.07T - ntapdatatel available 413G - ntapdatatel referenced 432G - ntapdatatel compressratio 1.00x - ntapdatatel mounted yes - ntapdatatel quota none default ntapdatatel reservation none default ntapdatatel recordsize 128K default ntapdatatel mountpoint /ntapdatatel local ntapdatatel sharenfs off default ntapdatatel checksum on default ntapdatatel compression off default ntapdatatel atime on default ntapdatatel devices on default ntapdatatel exec on default ntapdatatel setuid on default ntapdatatel readonly off default ntapdatatel zoned off default ntapdatatel snapdir hidden default ntapdatatel aclmode discard default ntapdatatel aclinherit restricted default ntapdatatel canmount on default ntapdatatel shareiscsi off default ntapdatatel xattr on default ntapdatatel copies 1 default ntapdatatel version 5 - ntapdatatel utf8only off - ntapdatatel normalization none - ntapdatatel casesensitivity sensitive - ntapdatatel vscan off default ntapdatatel nbmand off default ntapdatatel sharesmb off default ntapdatatel refquota none default ntapdatatel refreservation none default ntapdatatel primarycache all default ntapdatatel secondarycache all default ntapdatatel usedbysnapshots 0 - ntapdatatel usedbydataset 432G - ntapdatatel usedbychildren 666G - ntapdatatel usedbyrefreservation 0 - ntapdatatel logbias latency default ntapdatatel sync standard default ntapdatatel rekeydate - default ntapdatatel rstchown on default
它可能不是zfs – 你有很多可用的内存，所以考虑这种可能性 –
echo 'pg_contig_disable/D' | mdb -k
如果输出是：
echo pg_contig_disable/D | mdb -k pg_contig_disable: pg_contig_disable: 0
您可能遇到某种NUMA问题。 Solaris 10通过设置内存块来提高caching效率，从而促进更快的内存访问。 当你有很多内存和oracle的时候，就会产生一个奇怪的情况 – 就像你所描述的那样。 正常运行一个月左右，CPU用户使用量不多，系统CPU时间多，系统停顿。 长期来看，将内核参数pg_contig_disable设置为1。
短期的修复是重启。 如果重新启动有帮助，则需要设置内核parm。 在有大量可用内存的系统上，这是一个已知的Solaris 10问题。
感谢jim mcnamara指引我正确的方向。 我没有看到与pg_contig_disable问题一致的症状，但它确实导致我与zfetch有关的问题。
我在以下网站上发现了同样的问题： http : //solaristalk.blogspot.com/2014_05_01_archive.html
这导致了Oracle网站上的一篇调整文章，描述了为什么ZFS预取对我们来说是一个问题： http : //docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-4.html
我们在重载时使用lockstat在互斥列表顶部看到了dmu_zfetch_find。 我在ZFS实现中禁用了预取。 今天晚上我会重新启动，以确保一切都被清除，我们开始新鲜。
希望这是票。 如果我们仍然有问题，以防万一，我们可能稍后会对pg_contig_disable做一些testing。