On Wed, 7 Jan 2009, Dmitry Koterov wrote:
The question is: will physical writes be performed later in the sequence of physical SECTOR position on the disc (minimizing head seeking)? Or Linux background writer knows nothing about physical on-disc placement and flushes data in order it is saved in the RAM?
The part of Linux that does this is called the elevator algorithm, and even the simplest I/O scheduler (the no-op one) does a merge+sort to schedule physical writes. The classic intro paper on this subject is http://www.linuxinsight.com/files/ols2004/pratt-reprint.pdf
What I am trying to understand - why does the system fall to a writing bottleneck (e.g. 10MB/s) much before it achieves the maximum disk throughput (e.g. 50MB/s). How could it happen if the Linux IO scheduler reorders write operations, so time for seeking is minimal?
I think you're underestimating how much impact even a minimal amount of seeking has. If the disk head has to move at all beyond a single track seek, you won't get anywhere close to the rated sequential speed on the drive even if elevator sorting is helping out. And the minute a checkpoint is involved, with its requisite fsync at the end, all the blocks related to that are going to be forced out of the write cache without any chance for merge+sort to lower the average disk I/O--unless you spread that checkpoint write over a long period so pdflush can trickle to blocks out to disk.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
