[ https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Randall Leeds updated COUCHDB-767: ---------------------------------- Attachment: async_fsync_v3.patch Thanks for the catches, Adam. All file:rename are now couch_file:rename. Fixed typo in rename handler. make check -- all tests pass futon -- all tests pass (except replication hangs for me too, as jchris mentioned on irc, but this is unrelated) > 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, > async_fsync_v3.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.