☰

自从升级到 Solaris 11 以来，尽管 RAM 为 30GB，我的 ARC 大小始终为 119MB。什么原因？

tag-icon • tag-icon zfs solaris-11
自从升级到 Solaris 11 以来，尽管 RAM 为 30GB，我的 ARC 大小始终为 119MB。什么原因？

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

一切顺利，我得到了如下所示的 ZFS 内存使用情况图表：

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

然而，当 Solaris 11 发布后，我升级到了 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，根据 是 119M - 认为差异只是 1024/1000 舍入问题）。看起来内核没有做出任何努力来将目标大小改变为其他任何大小。当前大小随着系统（大型）需求与目标大小冲突而波动，似乎平衡点在 700 到 1000MB 之间。

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

我已经将输出粘贴kstat -n arcstats到http://pastebin.com/WHPimhfg

编辑3

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

上周四，盒子崩溃了。也就是说，完全停止了对一切的响应。当我重新启动它时，它又恢复正常了，但现在我的图表是这样的。

看来问题已经解决了。

这才是真正的梦幻乐园。我根本不知道发生了什么。:(

答案1

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

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

  • 至少有 3 个人也遇到了同样的问题，具体讨论内容如下http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html

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

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

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

即使你可能不会过分依赖 ARC/L2ARC，你也可能能够通过多次读取大文件（通常可以放入你的 RAM）来重现它日。您可能会注意到，第一次读取文件实际上会比对同一文件的任何连续读取都更快（由于 ARC 大小惊人且有无数的缓存驱逐）。

编辑：我现在已经设法从 Oracle 收到一个 IDR 补丁，该补丁解决了此问题。如果您的系统正在接受支持，您应该请求 CR 7111576 的 IDR 补丁。该补丁适用于带有 SRU3 的 Solaris 11 11/11。

答案2

他们改变了 kstats。

Oracle Solaris 11 从 zfs:0:arcstats 中删除了以下统计信息：

  • 逐出l2_cached
  • 逐出l2_eligible
  • evict_l2_ineligible
  • 逐出跳过
  • hdr_size
  • l2_写入时释放
  • l2_size 回收站

并将以下内容添加到 zfs:0:arcstats：

  • 缓冲区大小
  • meta_limit
  • meta_max
  • meta_used

所以这基本上可能只是你的脚本的一个问题。

相关内容