On 02/28/2018 11:33 PM, Peter Booth wrote:
This discussion is interesting, educational, and thought provoking.
Web architects
only learn “the right way” by first doing things “the wrong way” and
seeing what happens.
Attila and Valery asked questions that sound logical, and I think
there's value in exploring
what would happen if their suggestions were implemented.
First caveat - nginx is deployed in all manner different scenarios on
different hardware
and operating systems. Physical servers and VMs behave very
differently, as do local
and remote storage. When an application writes to NFS mounted storage
there's no guarantee
that even and synch will correctly enforce a write barrier. Still, if
we consider real numbers:
* On current model quad socket hosts, nginx can support well over 1
million requests per second (see TechEmpower benchmarks)
* On the same hardware, a web app that writes to a Postgresql DB can
do at least a few thousand writes per second.
* A SATA drive might support 300 write IOPS, whilst an SSD will
support 100x that.
What this means that doing fully synchronous writes can reduce your
potential throughput
by a factor of 100 or more. So it’s not a great way to ensure consistency.
But there are cheaper ways to achieve the same consistency and
reliability characteristics:
* 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).
* If you want to protect against loss of physical disk then use RAID.
* 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
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!
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).
But nginx doesn't do this today. And that's what this discussion is all
about...
* If you want to protect against a crazy person hitting your server
with an axe then write to two servers ...
And still you won't have it reliably on your disks.
*But the bottom line is separation of concerns.* Nginx should not use
fsync because it isn’t nginx's business.
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.
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.
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.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
