[jira] [Resolved] (KUDU-1555) LogBlockManager FlushDataAsync() synchronously flushes metadata

["Todd Lipcon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Lipcon resolved KUDU-1555.
-------------------------------
       Resolution: Fixed
         Assignee: Todd Lipcon
    Fix Version/s: 0.10.0

Fixed in af5c0592ff654171eb4cd9305ab3626f9bd22e22

> LogBlockManager FlushDataAsync() synchronously flushes metadata
> ---------------------------------------------------------------
>
>                 Key: KUDU-1555
>                 URL: https://issues.apache.org/jira/browse/KUDU-1555
>             Project: Kudu
>          Issue Type: Bug
>          Components: fs, perf
>    Affects Versions: 0.10.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: 0.10.0
>
>
> I'm looking at the time spent by a flush in a YCSB workload, and most of the time is spent in stacks like:
> #0  0x0000003a1acdfd9a in sync_file_range () from /lib64/libc.so.6
> #1  0x00000000018a83e4 in ?? ()
> #2  0x00000000018ee741 in kudu::pb_util::WritablePBContainerFile::Flush() ()
> #3  0x000000000187ae56 in kudu::fs::internal::LogWritableBlock::FlushDataAsync() ()
> #4  0x00000000017b177e in kudu::cfile::CFileWriter::FinishAndReleaseBlock(kudu::fs::ScopedWritableBlockCloser*) ()
> #5  0x0000000000905206 in kudu::tablet::MultiColumnWriter::FinishAndReleaseBlocks(kudu::fs::ScopedWritableBlockCloser*) ()
> The purpose of doing the FlushDataAsync() is so that the disks work in parallel, but currently it appears that this is ended up blocked in synchronous _metadata_ flushes on each disk in turn. I think this should probably perform an _async_ metadata flush, since we later relay on a SyncMetadata() call to ensure it is complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)