[ https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Kocoloski updated COUCHDB-767: ----------------------------------- Attachment: 767-async-fsync.patch The patch. > 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 > > > 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.