forked from openzfs/zfs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
= Motivation At Delphix we've seen a lot of customer systems where fragmentation is over 75% and random writes take a performance hit because a lot of time is spend on I/Os that update on-disk space accounting metadata. Specifically, we seen cases where 20% to 40% of sync time is spend after sync pass 1 and ~30% of the I/Os on the system is spent updating spacemaps. The problem is that these pools have existed long enough that we've touched almost every metaslab at least once, and random writes scatter frees across all metaslabs every TXG, thus appending to their spacemaps and resulting in many I/Os. To give an example, assuming that every VDEV has 200 metaslabs and our writes fit within a single spacemap block (generally 4K) we have 200 I/Os. Then if we assume 2 levels of indirection, we need 400 additional I/Os and since we are talking about metadata for which we keep 2 extra copies for redundancy we need to triple that number, leading to a total of 1800 I/Os per VDEV every TXG. We could try and decrease the number of metaslabs so we have less I/Os per TXG but then each metaslab would cover a wider range on disk and thus would take more time to be loaded in memory from disk. In addition, after it's loaded, it's range tree would consume more memory. Another idea would be to just increase the spacemap block size which would allow us to fit more entries within an I/O block resulting in fewer I/Os per metaslab and a speedup in loading time. The problem is still that we don't deal with the number of I/Os going up as the number of metaslabs is increasing and the fact is that we generally write a lot to a few metaslabs and a little to the rest of them. Thus, just increasing the block size would actually waste bandwidth because we won't be utilizing our bigger block size. = About this patch This patch introduces the Log Spacemap project which provides the solution to the above problem while taking into account all the aforementioned tradeoffs. The details on how it achieves that can be found in the references sections below and in the code (see Big Theory Statement in spa_log_spacemap.c). Even though the change is fairly constraint within the metaslab and lower-level SPA codepaths, there is a side-change that is user-facing. The change is that VDEV IDs from VDEV holes will no longer be reused. To give some background and reasoning for this, when a log device is removed and its VDEV structure was replaced with a hole (or was compacted; if at the end of the vdev array), its vdev_id could be reused by devices added after that. Now with the pool-wide space maps recording the vdev ID, this behavior can cause problems (e.g. is this entry referring to a segment in the new vdev or the removed log?). Thus, to simplify things the ID reuse behavior is gone and now vdev IDs for top-level vdevs are truly unique within a pool. = Testing The illumos implementation of this feature has been used internally for a year and has been in production for ~6 months. For this patch specifically there don't seem to be any regressions introduced to ZTS and I have been running zloop for a week without any related problems. = Performance Analysis (Linux Specific) All performance results and analysis for illumos can be found in the links of the references. Redoing the same experiments in Linux gave similar results. Below are the specifics of the Linux run. After the pool reached stable state the percentage of the time spent in pass 1 per TXG was 64% on average for the stock bits while the log spacemap bits stayed at 95% during the experiment (graph: sdimitro.github.io/img/linux-lsm/PercOfSyncInPassOne.png). Sync times per TXG were 37.6 seconds on average for the stock bits and 22.7 seconds for the log spacemap bits (related graph: sdimitro.github.io/img/linux-lsm/SyncTimePerTXG.png). As a result the log spacemap bits were able to push more TXGs, which is also the reason why all graphs quantified per TXG have more entries for the log spacemap bits. Another interesting aspect in terms of txg syncs is that the stock bits had 22% of their TXGs reach sync pass 7, 55% reach sync pass 8, and 20% reach 9. The log space map bits reached sync pass 4 in 79% of their TXGs, sync pass 7 in 19%, and sync pass 8 at 1%. This emphasizes the fact that not only we spend less time on metadata but we also iterate less times to convergence in spa_sync() dirtying objects. [related graphs: stock- sdimitro.github.io/img/linux-lsm/NumberOfPassesPerTXGStock.png lsm- sdimitro.github.io/img/linux-lsm/NumberOfPassesPerTXGLSM.png] Finally, the improvement in IOPs that the userland gains from the change is approximately 40%. There is a consistent win in IOPS as you can see from the graphs below but the absolute amount of improvement that the log spacemap gives varies within each minute interval. sdimitro.github.io/img/linux-lsm/StockVsLog3Days.png sdimitro.github.io/img/linux-lsm/StockVsLog10Hours.png = Porting to Other Platforms For people that want to port this commit to other platforms below is a list of ZoL commits that this patch depends on: Make zdb results for checkpoint tests consistent db58794 Update vdev_is_spacemap_addressable() for new spacemap encoding 419ba59 Simplify spa_sync by breaking it up to smaller functions 8dc2197 Factor metaslab_load_wait() in metaslab_load() b194fab Rename range_tree_verify to range_tree_verify_not_present df72b8b Change target size of metaslabs from 256GB to 16GB c853f38 zdb -L should skip leak detection altogether 21e7cf5 vs_alloc can underflow in L2ARC vdevs 7558997 Simplify log vdev removal code 6c926f4 Get rid of space_map_update() for ms_synced_length 425d323 Introduce auxiliary metaslab histograms 928e8ad Error path in metaslab_load_impl() forgets to drop ms_sync_lock 8eef997 = References Background, Motivation, and Internals of the Feature - OpenZFS 2017 Presentation: youtu.be/jj2IxRkl5bQ - Slides: slideshare.net/SerapheimNikolaosDim/zfs-log-spacemaps-project Flushing Algorithm Internals & Performance Results (Illumos Specific) - Blogpost: sdimitro.github.io/post/zfs-lsm-flushing/ - OpenZFS 2018 Presentation: youtu.be/x6D2dHRjkxw - Slides: slideshare.net/SerapheimNikolaosDim/zfs-log-spacemap-flushing-algorithm Upstream Delphix Issues: DLPX-51539, DLPX-59659, DLPX-57783, DLPX-61438, DLPX-41227, DLPX-59320 DLPX-63385 Reviewed-by: Sean Eric Fagan <sef@ixsystems.com> Reviewed-by: Matt Ahrens <matt@delphix.com> Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Serapheim Dimitropoulos <serapheim@delphix.com> Closes openzfs#8442
- Loading branch information
Showing
41 changed files
with
3,194 additions
and
331 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,79 @@ | ||
| /* | ||
| * CDDL HEADER START | ||
| * | ||
| * The contents of this file are subject to the terms of the | ||
| * Common Development and Distribution License (the "License"). | ||
| * You may not use this file except in compliance with the License. | ||
| * | ||
| * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE | ||
| * or http://www.opensolaris.org/os/licensing. | ||
| * See the License for the specific language governing permissions | ||
| * and limitations under the License. | ||
| * | ||
| * When distributing Covered Code, include this CDDL HEADER in each | ||
| * file and include the License file at usr/src/OPENSOLARIS.LICENSE. | ||
| * If applicable, add the following below this CDDL HEADER, with the | ||
| * fields enclosed by brackets "[]" replaced with your own identifying | ||
| * information: Portions Copyright [yyyy] [name of copyright owner] | ||
| * | ||
| * CDDL HEADER END | ||
| */ | ||
|
|
||
| /* | ||
| * Copyright (c) 2018, 2019 by Delphix. All rights reserved. | ||
| */ | ||
|
|
||
| #ifndef _SYS_SPA_LOG_SPACEMAP_H | ||
| #define _SYS_SPA_LOG_SPACEMAP_H | ||
|
|
||
| #include <sys/avl.h> | ||
|
|
||
| typedef struct log_summary_entry { | ||
| uint64_t lse_start; /* start TXG */ | ||
| uint64_t lse_mscount; /* # of metaslabs needed to be flushed */ | ||
| uint64_t lse_blkcount; /* blocks held by this entry */ | ||
| list_node_t lse_node; | ||
| } log_summary_entry_t; | ||
|
|
||
| typedef struct spa_unflushed_stats { | ||
| /* used for memory heuristic */ | ||
| uint64_t sus_memused; /* current memory used for unflushed trees */ | ||
|
|
||
| /* used for block heuristic */ | ||
| uint64_t sus_blocklimit; /* max # of log blocks allowed */ | ||
| uint64_t sus_nblocks; /* # of blocks in log space maps currently */ | ||
| } spa_unflushed_stats_t; | ||
|
|
||
| typedef struct spa_log_sm { | ||
| uint64_t sls_sm_obj; /* space map object ID */ | ||
| uint64_t sls_txg; /* txg logged on the space map */ | ||
| uint64_t sls_nblocks; /* number of blocks in this log */ | ||
| uint64_t sls_mscount; /* # of metaslabs flushed in the log's txg */ | ||
| avl_node_t sls_node; /* node in spa_sm_logs_by_txg */ | ||
| } spa_log_sm_t; | ||
|
|
||
| int spa_ld_log_spacemaps(spa_t *); | ||
|
|
||
| void spa_generate_syncing_log_sm(spa_t *, dmu_tx_t *); | ||
| void spa_flush_metaslabs(spa_t *, dmu_tx_t *); | ||
| void spa_sync_close_syncing_log_sm(spa_t *); | ||
|
|
||
| void spa_cleanup_old_sm_logs(spa_t *, dmu_tx_t *); | ||
|
|
||
| uint64_t spa_log_sm_blocklimit(spa_t *); | ||
| void spa_log_sm_set_blocklimit(spa_t *); | ||
| uint64_t spa_log_sm_nblocks(spa_t *); | ||
| uint64_t spa_log_sm_memused(spa_t *); | ||
|
|
||
| void spa_log_sm_decrement_mscount(spa_t *, uint64_t); | ||
| void spa_log_sm_increment_current_mscount(spa_t *); | ||
|
|
||
| void spa_log_summary_add_flushed_metaslab(spa_t *); | ||
| void spa_log_summary_decrement_mscount(spa_t *, uint64_t); | ||
| void spa_log_summary_decrement_blkcount(spa_t *, uint64_t); | ||
|
|
||
| boolean_t spa_flush_all_logs_requested(spa_t *); | ||
|
|
||
| extern int zfs_keep_log_spacemaps_at_export; | ||
|
|
||
| #endif /* _SYS_SPA_LOG_SPACEMAP_H */ |
Oops, something went wrong.