我们已经在 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 (c-p)
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
r b w 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
答案1
它可能不是 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 尝试通过设置内存块来提高缓存效率，从而加快内存访问速度。当您拥有大量内存和 Oracle 时，这会导致奇怪的情况 - 就像您描述的那样。在正常运行一个月左右后，CPU 用户使用率不高，系统 CPU 时间很多，系统就会陷入停顿。长期来看，将内核参数 pg_contig_disable 设置为 1。
短期修复方法是重新启动。如果重新启动有帮助，则需要设置内核参数。这是 Solaris 10 中具有大量可用内存的系统上的一个已知问题。
答案2
感谢 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 进行一些测试，以防万一。