ZFS Tunables for Lustre Object Storage Servers (OSS): Difference between revisions
Jump to navigation
Jump to search
(Created page with "{| class="wikitable" style="text-align:left;" !Parameter !Notes !Default !Suggested |- |metaslab_debug_unload |Prevent ZFS from unloading the spacemaps from a metaslab once it...") |
No edit summary |
||
Line 63: | Line 63: | ||
[[Category:ZFS OSD Tuning]] | [[Category:ZFS OSD Tuning]] | ||
[[Category:Lustre Systems Administration]] |
Revision as of 22:53, 30 August 2017
Parameter | Notes | Default | Suggested |
---|---|---|---|
metaslab_debug_unload | Prevent ZFS from unloading the spacemaps from a metaslab once it is read in | 0 | 1 |
zfs_vdev_scheduler | VDEV Scheduler | noop | deadline |
zfs_arc_max | Maximum size of ARC | 50% RAM | 75% RAM |
zfs_dirty_data_max | Amount of dirty data on the system; able to absorb more workload variation before throttling | 10% RAM | 1 - 4GB |
zfs_vdev_async_write_active_min_dirty_percent | Threshold below which IO scheduler will limit concurrent operations to the minimum. Above this value, concurrent operations increases linearly until the maximum. | 30 | 20 |
zfs_vdev_async_write_min_active | Minimum asynchronous write I/Os active to each device | 1 | 5 |
zfs_vdev_async_write_max_active | Maximum asynchronous write I/Os active to each device | 10 | 10 |
zfs_vdev_sync_read_min_active | Minimum synchronous read I/Os active to each device | 16 | |
zfs_vdev_sync_read_max_active | Maximum synchronous read I/Os active to each device | 16 | |
spl_kmem_cache_slab_limit | Objects of spl_kmem_cache_slab_limit or smaller will be allocated using the Linux slab allocator, large objects use the SPL allocator. A cut-off of 16K was determined to be optimal for architectures using 4K pages. | 16384 | 16384 |
When dirty data is less than 30% of zfs_dirty_data_max
, ZFS keeps one outstanding write per VDEV. Dirty data will build up very quickly, and because there is only one outstanding write per disk, ZFS will start to delay or even halt writes.
The zfs_dirty_data_max
parameter should ideally match the backend storage capability. The code simply uses 10% of system memory as the default.
For a comprehensive description of all available ZFS and SPL module parameters, refer to the zfs-module-parameters(5) and spl-module-parameters(5) man pages.