<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 02/28/2018 11:33 PM, Peter Booth wrote:<br>
<blockquote type="cite"
cite="mid:3EA526B9-EA09-4304-86BD-1A341CBBD5B8@me.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
This discussion is interesting, educational, and thought
provoking. Web architects
<div class="">only learn “the right way” by first doing things
“the wrong way” and seeing what happens.</div>
<div class="">Attila and Valery asked questions that sound
logical, and I think there's value in exploring </div>
<div class="">what would happen if their suggestions were
implemented.</div>
<div class=""><br class="">
</div>
<div class="">First caveat - nginx is deployed in all manner
different scenarios on different hardware</div>
<div class="">and operating systems. Physical servers and VMs
behave very differently, as do local</div>
<div class="">and remote storage. When an application writes to
NFS mounted storage there's no guarantee </div>
<div class="">that even and synch will correctly enforce a write
barrier. Still, if we consider real numbers:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="">
<li class="">On current model quad socket hosts, nginx can
support well over 1 million requests per second (see
TechEmpower benchmarks)</li>
<li class="">On the same hardware, a web app that writes to a
Postgresql DB can do at least a few thousand writes per
second.</li>
<li class="">A SATA drive might support 300 write IOPS,
whilst an SSD will support 100x that.</li>
</ul>
</div>
<div class="">What this means that doing fully synchronous writes
can reduce your potential throughput </div>
<div class="">by a factor of 100 or more. So it’s not a great way
to ensure consistency.</div>
<div class=""><br class="">
</div>
<div class="">But there are cheaper ways to achieve the same
consistency and reliability characteristics:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="">
<li class="">If you are using Linux then your reads and write
swill occur through the page cache - so the actual disk
itself really doesn’t matter (whilst your host is up).</li>
<li class="">If you want to protect against loss of physical
disk then use RAID.</li>
<li class="">If you want to protect against a random power
failure then use drives with battery backed caches, so
writes will get persisted when a server restarts after a
power failure</li>
</ul>
</div>
</blockquote>
Sorry, but this point shows that you don't understand the problem. A
BBWC won't save you from random power failure. Because the data is
still in RAM!<br>
BBWC will save you when you do an fsync and the end of the write
(and that fsync will still write RAM, but it will be the
controller's RAM which is protected by battery).<br>
But nginx doesn't do this today. And that's what this discussion is
all about...<br>
<br>
<blockquote type="cite"
cite="mid:3EA526B9-EA09-4304-86BD-1A341CBBD5B8@me.com">
<div class="">
<ul class="">
<li class="">If you want to protect against a crazy person
hitting your server with an axe then write to two servers
...</li>
</ul>
</div>
</blockquote>
And still you won't have it reliably on your disks.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:3EA526B9-EA09-4304-86BD-1A341CBBD5B8@me.com">
<div class=""><b class="">But the bottom line is separation of
concerns.</b> Nginx should not use fsync because it isn’t
nginx's business.</div>
<br>
</blockquote>
Please suggest at least working solution, which is compatible with
nginx's asynchronous architecture and it ensures that a successful
HTTP PUT will mean the data written to a reliable store.<br>
<br>
There are several filesystems which can be turned "fsync by
default", but that will fail miserably because nginx does the writes
in the same process in the same thread. That's what could be solved
by doing at least the fsyncs in different threads, so they wouldn't
block the main thread.<br>
<br>
BTW, I'm not proposing this to be the default. It should be an
optional setting, so if somebody want to maintain the current
situation, they could do that.<br>
</body>
</html>