Solaris 10 ZFS弧最大化，CPU过载

Question

我们已经在Oracle M5000企业服务器上的Solaris 10上运行ZFS已有几年了，有32个CPU内核和256 of内存。我们正在此服务器上运行一个数据库/应用程序，该数据库/应用程序似乎读取量很大。

我们在UFS上有I/O问题，通过切换到ZFS解决了这个问题。我们有一个NetApp存储单元，它通过光纤通道呈现磁盘，然后在单个LUN上使用ZFS在操作系统级别上格式化。起初，应用程序内存有问题，必须将ARC大小限制为128 we内存。

现在我们开始看到的问题是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的输出：

# 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

Answer 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试图通过设置内存块以提高缓存效率，从而促进更快的内存访问。当你拥有大量的记忆和甲骨文时，就会出现一种很复杂的情况--就像你描述的那样。经过一个月左右的正常运行时间，cpu用户使用不多，系统cpu时间多，系统陷入停顿。长期而言，将内核参数pg_contig_disable设置为1。

短期的解决办法是重新启动。如果重新启动有帮助，则需要设置内核parm。这是一个已知的Solaris 10问题，在有大量空闲内存的系统上。

Answer 2

感谢吉姆·麦克纳马拉为我指明了正确的方向。我没有看到与pg_contig_disable问题相一致的症状，但这确实导致了zfetch的问题。

我在以下网站上发现了同样的问题：http://solaristalk.blogspot.com/2014_05_01_archive.html

这导致了Oracle上的一篇调优文章，描述了为什么ZFS预取对我们来说是一个问题：http://docs.oracle.com/cd/E26502_01/html/E 29022/chapterzfs 4.html

在重载期间，我们看到dmu_zfetch_find在互斥锁列表的顶部使用了lockstat。我已经在我们的ZFS实现中禁用了预取。今晚我会重新启动，以确保一切都被清理干净，我们重新开始。

希望这是票。如果我们仍然有问题，我们可能会在稍后对pg_contig_disable进行一些测试，以防万一会有所帮助。