Performance

Performance

Status

OpenZFS on OS X is under active development, with priority currently given to stability and integration improvements ahead of performance work.

Performance Tuning

Memory Utilization

ZFS uses memory caching to improve performance. Filesystem metadata, file data, and de-duplication tables (DDT) are stored in the ARC, allowing frequently accessed data to be served much faster than from disk.

The performance you experience with ZFS is closely tied to how much memory is available to the ARC.

O3X uses wired, non-pageable memory for the ARC. Activity Monitor and top can show the total amount of wired memory in use. O3X is not the only consumer of wired memory, so to examine the amount allocated specifically by O3X, use:

sysctl kstat.spl.misc.spl_misc.os_mem_alloc

This value is often higher than the configured maximum ARC size because it includes allocator overhead.

For example, on a 32 GB iMac with the ARC set to 8 GB:

sysctl kstat | grep arc.max
kstat.zfs.darwin.tunable.zfs_arc.max: 8589934592

sysctl kstat.spl.misc.spl_misc.os_mem_alloc
kstat.spl.misc.spl_misc.os_mem_alloc: 11866734592

Over several releases, O3X evolved the SPL memory allocator to more closely match the OpenSolaris allocator. This was driven by limitations in the OS X kernel allocator when handling the demands of a full ZFS implementation.

From O3X 1.3.1 onward, the ARC can by default occupy most of the machine’s physical memory. In parallel, O3X includes a mechanism to detect memory pressure and return memory to the OS when needed. This has been extensively tested, though it may not suit every workload.

You can temporarily limit the ARC size with:

sudo sysctl -w kstat.zfs.darwin.tunable.zfs_arc.max=<size_of_arc_in_bytes>

For O3X 1.3.0, use:

sudo sysctl -w zfs.arc_max=<size_of_arc_in_bytes>

With the final release of O3X 1.3.1, a persistent configuration mechanism was added. Adding the following line to /etc/zfs/zsysctl.conf causes the change to be applied whenever the O3X kexts are loaded:

kstat.zfs.darwin.tunable.zfs_arc_max=<size_in_bytes>

To monitor ARC size and performance, use the provided arcstat.pl script:

arcstat.pl 1

If you want to reduce O3X memory usage immediately, there are two steps.

First, reduce the maximum ARC size:

sudo sysctl -w kstat.zfs.darwin.tunable.zfs_arc_max=<size_of_arc_in_bytes>

Then force the SPL allocator to return memory to the OS:

sudo sysctl -w kstat.spl.misc.spl_misc.simulate_pressure=<amount_of_ram_to_release_in_bytes>

This forces the SPL allocator to reap internal caches and release memory back to the OS. It is a coarse mechanism and may need to be repeated several times.

You can monitor Activity Monitor, top, or arcstat.pl to see whether enough memory has been released. Keep in mind that doing this will likely put additional pressure on the ARC and evict cached data from main memory.

The ARC implementation is kept aligned with the Illumos codebase. Performance tuning changes made upstream in Illumos are expected to flow through into future O3X releases.

Current Benchmarks

To establish a baseline for current performance, measurements were made using the [iozone](http://www.iozone.org/)
 benchmarking tool.

The benchmark setup was:

VMware 6.0.2 VM
2011 iMac host
8 GB RAM per VM
one OS boot drive
one 5 GB secondary HDD containing a ZFS dataset
virtual disks stored as standard VMware .vmx files

The test zpool was created with:

zpool create -o ashift=12 -f tank <disk_device_name>

The benchmark procedure was:

Start the VM
Import the tank dataset
Run mkdir /tank/tmp && cd /tank/tmp
Run time iozone -a
Record time 1
Run time iozone -a again
Record time 2
Shut down the VM and VMware before moving to the next ZFS implementation or OS combination

The original page included a benchmark image comparing ZFS implementations. You can add that back in GitHub wiki form if you want, for example:

![Comparison of ZFS implementations](images/ZFS_iozone_time.png)