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

Reply via email to