[ https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876573#action_12876573 ]
Randall Leeds commented on COUCHDB-767: --------------------------------------- I should also mention that Adam told me about a bug in the original patch on IRC: the couch_db gen_server process for the compacted file needs to be notified of the name change when compaction completes. This patch adds the necessary couch_file:rename/2, called from couch_db_updater/commit_data/2. > do a non-blocking file:sync > --------------------------- > > Key: COUCHDB-767 > URL: https://issues.apache.org/jira/browse/COUCHDB-767 > Project: CouchDB > Issue Type: Improvement > Components: Database Core > Affects Versions: 0.11 > Reporter: Adam Kocoloski > Fix For: 1.1 > > Attachments: 767-async-fsync.patch, async_fsync.patch > > > I've been taking a close look at couch_file performance in our production > systems. One of things I've noticed is that reads are occasionally blocked > for a long time by a slow call to file:sync. I think this is unnecessary. I > think we could do something like > handle_call(sync, From, #file{name=Name}=File) -> > spawn_link(fun() -> sync_file(Name, From) end), > {noreply, File}; > and then > sync_file(Name, From) -> > {ok, Fd} = file:open(Name, [read, raw]), > gen_server:reply(From, file:sync(Fd)), > file:close(Fd). > Does anyone see a downside to this? Individual clients of couch_file still > see exactly the same behavior as before, only readers are not blocked by > syncs initiated in the db_updater process. When data needs to be flushed > file:sync is _much_ slower than spawning a local process and opening the file > again -- in the neighborhood of 1000x slower even on Linux with its > less-than-durable use of vanilla fsync. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.