自从升级到 Solaris 11 以来，我的 ARC 大小一直以 119MB 为目标，尽管有 30GB 的 RAM。什么？为什么？

Question

在 Solaris 11 发布之前，我在 Solaris 11 Express 上运行了一个 NAS/SAN 机器。包装盒是带有 D2700 的 HP X1600。总共 12 个 1TB 7200 SATA 磁盘，12 个 300GB 10k SAS 磁盘在单独的 zpool 中。总内存为 30GB。提供的服务包括 CIFS、NFS 和 iSCSI。

一切都很好，我有一个 ZFS 内存使用图，如下所示：

大约 23GB 的相当健康的 Arc 大小 - 利用可用内存进行缓存。

但是，当它出来时，我升级到了 Solaris 11。现在，我的图表如下所示：

的部分输出arc_summary.pl是：

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26719 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             915 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

它的目标是 119MB，而坐在 915MB。它有 30GB 可以玩。为什么？他们改变了什么吗？

编辑

澄清arc_summary.pl一下，是 Ben Rockwood 的，生成上述统计数据的相关行是：

my $mru_size = ${Kstat}->{zfs}->{0}->{arcstats}->{p};
my $target_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c};
my $arc_min_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_min};
my $arc_max_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_max};
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};

Kstat 条目在那里，我只是从它们中得到了奇怪的值。

编辑 2

我刚刚重新测量了弧线大小arc_summary.pl- 我已经用以下方法验证了这些数字kstat：

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26697 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             744 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

让我印象深刻的是目标大小是 119MB。从图表中可以看出，arc_summary.pl自安装 Solaris 11 以来，它的目标值完全相同（根据 cacti 为 124.91M，根据 cacti 为 119M - 认为差异只是 1024/1000 舍入问题）。看起来内核正在零努力地将目标大小转移到任何不同的地方。当前大小随着系统（大型）的需求与目标大小的斗争而波动，看起来平衡在 700 到 1000MB 之间。

所以问题现在更尖锐了 - 为什么 Solaris 11 将我的 ARC 目标大小硬设置为 119MB，我该如何更改它？我应该提高最小尺寸看看会发生什么吗？

我kstat -n arcstats在http://pastebin.com/WHPimhfg 上停留了over的输出

编辑 3

好的，现在很奇怪。我知道 flibflob 提到有一个补丁可以解决这个问题。我还没有应用这个补丁（仍在整理内部支持问题）并且我没有应用任何其他软件更新。

上周四，盒子坠毁了。如在，完全停止响应一切。当我重新启动它时，它恢复正常，但这是我的图表现在的样子。

似乎已经解决了这个问题。

这是正确的啦啦土地的东西。我真的不知道发生了什么。:(

Answer 1

不幸的是我无法解决你的问题，但这里有一些背景信息：

• ARC目标大小似乎不是一个固定值。我在 Solaris 11 计算机上遇到了同样的问题，每次重新启动后，在某个时刻目标大小似乎锁定在 ~100 和 ~500MB 之间的值。

• 至少还有另外 3 个人面临同样的问题，如http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html中所述

• “My Oracle Support”( https://support.oracle.com )上还有一个未解决的错误报告 (7111576) 。如果您的服务器签订了有效的支持合同，您应该提交服务请求并参考该错误。截至目前，任何错误修复似乎仍在进行中......

除此之外，你无能为力。如果您尚未升级 zpool/zfs 版本，您可以尝试引导至旧的 Solaris 11 Express 引导环境并运行该环境，直到 Oracle 最终决定发布可修复该问题的 SRU。

编辑：既然上面已经讨论了性能下降的问题：这一切都取决于你在做什么。自从升级到 Solaris 11 11/11 以来，我的 Solaris 11 NFS 共享出现了可怕的延迟。然而，与您的系统相比，我的主轴相对较少，并且严重依赖 ARC 和 L2ARC 缓存按预期工作（请注意，该问题还会导致 L2ARC 无法增长到任何合理的大小）。这当然不是一个误解统计数据的问题。

即使您可能不太依赖 ARC/L2ARC，您也可能能够通过使用 dd 多次读取大文件（通常适合您的 RAM）来重现它。您可能会注意到，第一次读取文件实际上比连续读取同一文件要快（由于荒谬的 ARC 大小和无数的缓存驱逐）。

编辑：我现在已成功从 Oracle 收到解决此问题的 IDR 补丁。如果您的系统受到支持，您应该索取 CR 7111576 的 IDR 补丁。该补丁适用于带有 SRU3 的 Solaris 11 11/11。