为什么在Linux的ZFS上不遵守arc_max设置？

我正在Ubuntu 12.04上从他们的PPA运行ZoL 0.6.2 。它位于具有16GB内存的主机上，旨在使用KVM / Libvirt运行某些VM。一段时间后，ZoL使用了疯狂的内存，在某些VM运行的情况下达到了98％的RAM使用率。这导致新进程拒绝启动“无法分配内存”。我什至无法启动我的所有VM，而在使用ZFS之前，该VM使用了大约40-50％的RAM。

据我了解，在不进行调整的情况下，一旦系统内存不足，ZoL应该立即释放内存。好吧，事实并非如此。因此，我决定将设置设为arc_max1GB。

# echo 1073741824 >> /sys/module/zfs/parameters/zfs_arc_max

尽管如此，它不会释放任何内存。

从下面的ARC统计数据可以看出，它使用的内存比配置的要多（比较c= 7572030912与c_max= 1073741824）。

我在这里做错了什么？

# cat /proc/spl/kstat/zfs/arcstats
4 1 0x01 84 4032 43757119584 392054268420115
name                            type data
hits                            4    28057644
misses                          4    13975282
demand_data_hits                4    19632274
demand_data_misses              4    571809
demand_metadata_hits            4    6333604
demand_metadata_misses          4    289110
prefetch_data_hits              4    1903379
prefetch_data_misses            4    12884520
prefetch_metadata_hits          4    188387
prefetch_metadata_misses        4    229843
mru_hits                        4    15390332
mru_ghost_hits                  4    1088944
mfu_hits                        4    10586761
mfu_ghost_hits                  4    169152
deleted                         4    35432344
recycle_miss                    4    701686
mutex_miss                      4    35304
evict_skip                      4    60416647
evict_l2_cached                 4    0
evict_l2_eligible               4    3022396862976
evict_l2_ineligible             4    1602907651584
hash_elements                   4    212777
hash_elements_max               4    256438
hash_collisions                 4    17163377
hash_chains                     4    51485
hash_chain_max                  4    10
p                               4    1527347963
c                               4    7572030912
c_min                           4    1038188800
c_max                           4    1073741824
size                            4    7572198224
hdr_size                        4    66873056
data_size                       4    7496095744
other_size                      4    9229424
anon_size                       4    169150464
anon_evict_data                 4    0
anon_evict_metadata             4    0
mru_size                        4    1358216192
mru_evict_data                  4    1352400896
mru_evict_metadata              4    508928
mru_ghost_size                  4    6305992192
mru_ghost_evict_data            4    4919159808
mru_ghost_evict_metadata        4    1386832384
mfu_size                        4    5968729088
mfu_evict_data                  4    5627991552
mfu_evict_metadata              4    336846336
mfu_ghost_size                  4    1330455552
mfu_ghost_evict_data            4    1287782400
mfu_ghost_evict_metadata        4    42673152
l2_hits                         4    0
l2_misses                       4    0
l2_feeds                        4    0
l2_rw_clash                     4    0
l2_read_bytes                   4    0
l2_write_bytes                  4    0
l2_writes_sent                  4    0
l2_writes_done                  4    0
l2_writes_error                 4    0
l2_writes_hdr_miss              4    0
l2_evict_lock_retry             4    0
l2_evict_reading                4    0
l2_free_on_write                4    0
l2_abort_lowmem                 4    0
l2_cksum_bad                    4    0
l2_io_error                     4    0
l2_size                         4    0
l2_asize                        4    0
l2_hdr_size                     4    0
l2_compress_successes           4    0
l2_compress_zeros               4    0
l2_compress_failures            4    0
memory_throttle_count           4    0
duplicate_buffers               4    0
duplicate_buffers_size          4    0
duplicate_reads                 4    0
memory_direct_count             4    66583
memory_indirect_count           4    7657293
arc_no_grow                     4    0
arc_tempreserve                 4    0
arc_loaned_bytes                4    0
arc_prune                       4    0
arc_meta_used                   4    427048272
arc_meta_limit                  4    2076377600
arc_meta_max                    4    498721632

# free -m
             total       used       free     shared    buffers     cached
Mem:         15841      15385        456          0         75         74
-/+ buffers/cache:      15235        606
Swap:            0          0          0

恕我直言，/ sys / module / zfs / parameters中的参数只能设置为0/ 1- disabled/ enabled。“ 更正：取决于参数

我在同一条船上想要限制zfs的内存使用，似乎必须创建一个/etc/modprobe.d/zfs.conf文件，然后在其中输入参数和所需的值。此更改将在重新启动后生效。

echo "options zfs zfs_arc_max=34359738368" >> /etc/modprobe.d/zfs.conf

要影响正在运行的模块，可以更改zfs_arc_max参数。

echo "34359738368" > /sys/module/zfs/parameters/zfs_arc_max

请注意，使用>代替将文件内容替换为的方式>>。

来源：https : //stackoverflow.com/a/18808311

http://fibrevillage.com/storage/169-zfs-arc-on-linux-how-to-set-and-monitor-on-linux

这篇文章很好

从ZoL 0.6.2版本开始，您可以在运行时设置c_max，但是不会自动释放ARC大小。要强制释放RAM，需要导出zpool。

修改圆弧大小后，需要删除缓存。

echo 3 > /proc/sys/vm/drop_caches

然后等待（您的提示不会立即返回，但是其他进程将继续运行）。它将缓慢地卸载缓存（在装有64GB盒子的2Ghz 4岁CPU上的2对RAID 1'd 2TB WD黑色对上，我的24GB缓存需要2.5分钟）-当心，您将突然没有缓存，并且任何读取数据的进程将从原始磁盘中拉出，因此您可能会看到IO等待在重新填充缓存之前会跳一会儿。

您可能会遇到的一个问题是ZFS缓存虚拟机文件（虚拟磁盘）。为避免这种情况，我总是在包含虚拟磁盘的文件系统上将primarycache属性设置为“元数据”。

逻辑是，客户机OS可以更好地提示要缓存其磁盘的哪些区域。

AFAIK必须满足以下条件之一才能调整参数。

1. 在正在运行的系统上：导出所有zpool，删除zfs模块，重新启用zfs模块（根据定义，如果/在zfs上，则无法执行此操作）。
2. 更改参数时，请重新生成initramfs映像，以便在重新启动后可以使用。这是必需的，因为引导过程中当时尚未挂载zfs.conf文件位置。

您有一个额外的“ >”。

该命令应该是

echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_max

不是“ >>”

>>表示“添加到”（现有列表）。
>表示“覆盖”（值）。

这就是为什么您的问题中的命令代码不起作用的原因。