![]() If the interactive latency of these commands is important, consider how long it would take to flush zfs_dirty_data_max bytes to disk. This is relevant for certain OpenZFS administrative operations (sync tasks) that occur when a transaction group is committed to stable storage such as creating or cloning a new dataset. Weigh this tuning against other uses of memory on the system (a larger value means that there's less memory for applications or the OpenZFS ARC for example).Ī larger buffer also means that flushing a transaction group will take longer. If the metric stays low, you may reduce zfs_dirty_data_max. If the the amount of dirty data fluctuates above and below that threshold, it might be possible to avoid throttling by increasing the size of the buffer. ![]() The write throttle kicks in once the amount of dirty data exceeds zfs_delay_min_dirty_percent of the limit (60% by default). Track the amount of outstanding dirty data within your storage pool to know which way to adjust zfs_dirty_data_max: A buffer of only 200MB would cause OpenZFS to start to throttle writes - inserting artificial delays - after less than 2 seconds during which the LUNs could flush 200MB of dirty data while the client tried to generate 400MB. If instead the workload oscillates between 200MB/s and 0MB/s for 10 seconds each, then a small buffer would limit performance.Ī buffer of 800MB would be large enough to absorb the full 20 second cycle over which the average is 100MB/s. If a workload consistently writes at 100MB/s then only a very small buffer would be required. Let's say the LUNs assigned to your OpenZFS storage pool are able to sustain 100MB/s in aggregate. Think of the dirty data as a buffer for that variability. ![]() Lower Higher Less memory reserved for use by OpenZFS More memory reserved for use by OpenZFS Able to absorb less workload variation before throttling Able to absorb more workload variation before throttling Less data in each transaction group More data in each transaction group Less time spent syncing out each transaction group More time spent syncing out each transaction group More metadata written due to less amortization Less metadata written due to more amortization. It's default value is 10% of memory up to 4GB. OpenZFS limits the amount of dirty data on the system according to the tunable zfs_dirty_data_max. These details are intended for those using OpenZFS and trying to optimize performance - if you have only a casual interest in ZFS consider yourself warned! Buffering dirty data In this post I'll cover performance analysis and tuning - using DTrace of course. In addition to solving several problems in ZFS, the new approach was designed to be easy to reason about, measure, and adjust. I then presented the new OpenZFS write throttle and I/O scheduler that Matt Ahrens and I designed. In previous posts I discussed the problems with the legacy ZFS write throttle that cause degraded performance and wildly variable latencies.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |