Ditch Linux and port PgSQL to run on top of raw Xen interfaces. You get to control your own buffering, worker thread scheduling, and talk directly to the (virtual) disk driver. I believe it'd be a win.
Linux's fsync() woes are getting some attention
51–60 of 69 posts
Re: Linux's fsync() woes are getting some attention
#52here is a mail from mel gorman with many more details.
Re: Linux's fsync() woes are getting some attention
#53Earlier quoted context omitted.
> No, fsync is "Make sure the last write made it to disk. IN fact, force it out immediately. Also, all of the other pending writes as well, even if I'm not concerned about them. ..." POSIX 1003.1 (2004) doesn't go so far as to require unrelated data to be committed (emphasis mine): "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device…
True, and it's good of you to clarify. However, what if the "other pending writes" are to the same file descriptor? Just because I'm eager to know when one write happens doesn't mean I care about other writes I made elsewhere. sync() is basically a relic. Historically it only existed so that a UNIX userland process could roughly control the rate that dirty buffers went to disk. This was the "update" daemon historical…
Isn't sync() still useful for making sure all file-systems are sync'ed (as by the bin/sync utility -- which apparently basically calls sync())? For instance before shutdown?
Re: Linux's fsync() woes are getting some attention
#54It always amazes me that after all these years, Linux still hasn't fixed this. In my experience, any program that overloads I/O will make the system grind to a halt on Linux. Any notion of graceful degradation is gone and your system just thrashes for a while. My theory about this has always been that any I/O related to page faults is starved, which means that every process spends its time slice just trying to swap i…
Happens to Windows and Mac OS too. Every time I boot Dropbox thrashes my disk for 10 minutes while the system is almost completely unresponsive.
>Every time I boot Dropbox thrashes my disk for 10 minutes while the system is almost completely unresponsive.
I seriously doubt that any usermode program could overwhelm the OS scheduler like that. What are your use case parameters?
Re: Linux's fsync() woes are getting some attention
#55Earlier quoted context omitted.
Happens to Windows and Mac OS too. Every time I boot Dropbox thrashes my disk for 10 minutes while the system is almost completely unresponsive.
Yes, OS X isn't very advanced. In its heyday, Solaris was outstanding in terms of being responsive while simultaneously doing large amounts of I/O. (Or at least that's my perhaps clouded recollection, I haven't used Solaris in over 5 years).
Well, you'll have to be more specific than 'being responsive' and 'large amounts of I/O' for anyone to make sense out of your statement :)
Re: Linux's fsync() woes are getting some attention
#56Earlier quoted context omitted.
Happens to Windows and Mac OS too. Every time I boot Dropbox thrashes my disk for 10 minutes while the system is almost completely unresponsive.
>Every time I boot Dropbox thrashes my disk for 10 minutes while the system is almost completely unresponsive. I seriously doubt that any usermode program could overwhelm the OS scheduler like that. What are your use case parameters?
> I seriously doubt that any usermode program could overwhelm the OS scheduler like that. What are your use case parameters?
The OS IO scheduler is known to be shitty. That's not an exegeration. You can start swapping because the scheduler does not free unused caches fast enough.
Re: Linux's fsync() woes are getting some attention
#57Oh yes, that annoying problem (especially fro MongoDB) that data should eventually be committed to a disk.)
Informix (and PostgreSQL) allows DBA to choice "checkpoint/vacuum intervals".
The rule of thumb, unless you are a Mongo fan, is that checkpoints should be performed often enough to not take too long, which depends only on the actual insert/update data flow.
But any real DBA could tell the same - sync quickly, sync often, so server will run smoothly, but not "at web scale" and the pain of recovery will be less severe.)
Re: Linux's fsync() woes are getting some attention
#58So, what does Oracle Enterprise Linux do on an Exadata box running Linux?
ora uses O_DIRECT.
Re: Linux's fsync() woes are getting some attention
#59Earlier quoted context omitted.
Yes, a non-blocking fsync. I'd like to ask the kernel to write some data out, but I want to go on servicing other requests without blocking one OS thread entirely. And sometimes I really don't care when data is written out, just that it happens in the right order. I may be okay with losing a few seconds to a minute of work, but not okay with blocking all computation while I'm waiting for fsync.
jerf described a similar case where one is okay with losing some data, but not "too much". I'm not sure how to make that approach rigorous. (If rigor isn't important, and it's just best effort with no guarantees at all, then don't bother with fsync at all.) I'm also not sure in what higher-level use case it actually makes sense. Sorry if I'm being thick, but saying "the case where I want exactly that" doesn't help ex…
The kernel might wait for a very long time before writing any data to disk (especially in laptop mode with a spinning disk drive). Telling it to start writing now seems like a useful operation for an application that can handle the loss of recent writes, but would prefer to have data start going to disk anyway. Otherwise a power failure could mean losing 30 seconds of writes or more.
Re: Linux's fsync() woes are getting some attention
#60Re Mel Gorman's details in http://article.gmane.org/gmane.linux.kernel/1663694
I don't understand why PostgreSQL people don't want to write their own IO scheduler and buffer management. It's not that hard to implement (even a MT IO+BM is not really complicated), and there are major advantages:
- you become truly platform-independent instead of relying on particulars of some kernel [the only thing you need from the OS is some form of O_DIRECT; it exists also on Win32]
- you have total control over buffer memory allocation and IO scheduling
- whatever scheduling and buffer management policy you're using, you can more easily adapt it to SSDs and other storage types, which are still in their infancy (e.g., memristors) [thus not depending on the kernel developers' goodwill]
I mean, really: these pepole have implemented a RDBMS with a bunch of extensions to standard SQL, and IO+buffer management layer is suddenly complicated, or [quote from the link]: "While some database vendors have this option, the Postgres community do not have the resources to implement something of this magnitude."
This smells more like politics than a technical issue.