diff options
author | Brian Behlendorf <[email protected]> | 2011-12-05 10:08:29 -0800 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2011-12-05 12:02:12 -0800 |
commit | 23bdb07d4e4c435205d25d3efdb5fef2d089ce5e (patch) | |
tree | facb9f4d82006075f55754c0a05e2d1712dd154e /module/zfs | |
parent | 660cbada0fca3b5504562adcf21a35f9195f46a0 (diff) |
Update default ARC memory limits
In the upstream OpenSolaris ZFS code the maximum ARC usage is
limited to 3/4 of memory or all but 1GB, whichever is larger.
Because of how Linux's VM subsystem is organized these defaults
have proven to be too large which can lead to stability issues.
To avoid making everyone manually tune the ARC the defaults are
being changed to 1/2 of memory or all but 4GB. The rational for
this is as follows:
* Desktop Systems (less than 8GB of memory)
Limiting the ARC to 1/2 of memory is desirable for desktop
systems which have highly dynamic memory requirements. For
example, launching your web browser can suddenly result in a
demand for several gigabytes of memory. This memory must be
reclaimed from the ARC cache which can take some time. The
user will experience this reclaim time as a sluggish system
with poor interactive performance. Thus in this case it is
preferable to leave the memory as free and available for
immediate use.
* Server Systems (more than 8GB of memory)
Using all but 4GB of memory for the ARC is preferable for
server systems. These systems often run with minimal user
interaction and have long running daemons with relatively
stable memory demands. These systems will benefit most by
having as much data cached in memory as possible.
These values should work well for most configurations. However,
if you have a desktop system with more than 8GB of memory you may
wish to further restrict the ARC. This can still be accomplished
by setting the 'zfs_arc_max' module option.
Additionally, keep in mind these aren't currently hard limits.
The ARC is based on a slab implementation which can suffer from
memory fragmentation. Because this fragmentation is not visible
from the ARC it may believe it is within the specified limits while
actually consuming slightly more memory. How much more memory get's
consumed will be determined by how badly fragmented the slabs are.
In the long term this can be mitigated by slab defragmentation code
which was OpenSolaris solution. Or preferably, using the page cache
to back the ARC under Linux would be even better. See issue #75
for the benefits of more tightly integrating with the page cache.
This change also fixes a issue where the default ARC max was being
set incorrectly for machines with less than 2GB of memory. The
constant in the arc_c_max comparison must be explicitly cast to
a uint64_t type to prevent overflow and the wrong conditional
branch being taken. This failure was typically observed in VMs
which are commonly created with less than 2GB of memory.
Signed-off-by: Brian Behlendorf <[email protected]>
Issue #75
Diffstat (limited to 'module/zfs')
-rw-r--r-- | module/zfs/arc.c | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/module/zfs/arc.c b/module/zfs/arc.c index ff631e61b..f71c24844 100644 --- a/module/zfs/arc.c +++ b/module/zfs/arc.c @@ -3559,12 +3559,12 @@ arc_init(void) /* set min cache to 1/32 of all memory, or 64MB, whichever is more */ arc_c_min = MAX(arc_c / 4, 64<<20); - /* set max to 3/4 of all memory, or all but 1GB, whichever is more */ - if (arc_c * 8 >= 1<<30) - arc_c_max = (arc_c * 8) - (1<<30); + /* set max to 1/2 of all memory, or all but 4GB, whichever is more */ + if (arc_c * 8 >= ((uint64_t)4<<30)) + arc_c_max = (arc_c * 8) - ((uint64_t)4<<30); else arc_c_max = arc_c_min; - arc_c_max = MAX(arc_c * 6, arc_c_max); + arc_c_max = MAX(arc_c * 4, arc_c_max); /* * Allow the tunables to override our calculations if they are |