<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="+1">Don't fear the fsync<br>
<a class="moz-txt-link-freetext" href="http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync">http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync</a></font><br>
<br>
Why would running fsync in a loop be any different in performance
than running fsync in the thread waiting to hear back from astdb
put? The loop approach would also be beneficial in *reducing*
fsyncs, since you could batch say 10 writes at a time (assuming the
underlying storage supports it).. with a 60 second timeout where if
you didn't fill up the write bucket it would write them out anyway.
Otherwise the thread would be idle and waiting for put requests.<br>
<br>
<br>
On 09/06/10 09:37, Ron Arts wrote:
<blockquote cite="mid:4C84EEB1.9020909@netland.nl" type="cite">Op
06-09-10 15:10, Mark Murawski schreef:
<br>
<blockquote type="cite"> Here is one fix for the fsync problem.
<br>
<br>
Spawn an astdb put worker thread. (Same goes for using any
database
<br>
backend) Writers will dump their changes to a linked list and
return
<br>
immediately. The writer will write whenever it gets a chance.
if there
<br>
are big or small slowdowns in fsync it wont affect any running
threads.
<br>
And if you lose power, well... you would have lost the unwritten
data
<br>
anyway because you would have been waiting on it anyway.
<br>
<br>
</blockquote>
<br>
Please note: if any process or thread on a system is doing fsync()
<br>
in a loop, the entire system will slow to a crawl.
<br>
<br>
Ron
<br>
<br>
</blockquote>
</body>
</html>