Todd Lipcon has posted comments on this change. Change subject: KUDU-1549: compact LBM container metadata files at startup ......................................................................
Patch Set 2: (1 comment) http://gerrit.cloudera.org:8080/#/c/6826/2/src/kudu/fs/log_block_manager.cc File src/kudu/fs/log_block_manager.cc: PS2, Line 87: DEFINE_double(log_container_live_metadata_before_compact_ratio, 0.10, : "Desired ratio of live block metadata in log containers. If a " : "container's live to total block ratio dips below this value, " : "the container's metadata file will be compacted at startup."); > I can't say I have a strong opinion on the tagging given how often I hem an looking at a data/ dir on a cluster that has been around for quite some time, most of the metadata files seem to be around 400KB. Assuming 100MB/sec sequential throughput and 10ms seek, it definitely seems like the startup time would be seek-dominated (10 or 20ms seek depending whether various internal metadata pages are hot in cache, plus only 4ms of sequential read time). Unfortunatley, if that's true, this might mean that this optimization won't yield much of an improvement in the case that the metadata files are cold after a full machine reboot. However, in a "warm reboot" where the metadata files are in cache, or in the case when the metadata is on SSD, it should be a good CPU savings. I did a quick test on the above node (2000 metadata files) by calling drop_caches=3 and then timing 'cat *.metadata > /dev/null'. It took 2m14s. Interestingly, though, 'head --bytes=4 *.metadata > /dev/null' took only 54s. Looking at 'filefrag *.metadata' it seems most of the metadata files have ~15 extents, so each file is probably doing way more than the expected number of seeks. If the above fragmentation is normal (seems quite plausible given the files are written slowly over time, old ones are appended to, etc) then it seems like rewriting them should have a nice perf boost for future startups just by virtue of defragmenting the underlying FS (regardless of any actual compaction). Going as far as to use FIEMAP is probably overkill, but being aggressive to compact probably isn't crazy. (Sorry for the long comment... curious your thoughts) -- To view, visit http://gerrit.cloudera.org:8080/6826 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I981f7d9e7eb96fb40cef30ad96c5960b72d07756 Gerrit-PatchSet: 2 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: David Ribeiro Alves <davidral...@gmail.com> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
