OK, thank you.
Now - PostgreSQL-related question. If the system reorders writes to minimize seeking, I suppose that in heavy write-loaded PostgreSQL instalation dstat (or iostat) realtime write statistics should be close to the maximum possible value reported by bonnie++ (or simple dd) utility.
So, if, for example, I have in a heavy-loaded PostgreSQL installation:
- with a 50MB/s write speed limit reported by bonnie++ or dd (on a clean system),
- under a heavy PostgreSQL load the write throughput is only 10MB/s (synchronous_commit is off, checkpoint is executed every 10 minutes or even more),
- writeback buffer (accordingly to /proc/meminfo) is not fully filled,
- sometimes INSERTs or UPDATEs slow down in 10 second and more with no explicit correlation with checkpoints
then - something goes wrong?
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?
Or, better, I can reformulate the question. In which cases PostgreSQL may stall on INSERT/UPDATE operation if synchronous_commit is off and there are no locking between transactions? In which cases these operations lost their deterministic time (in theory) and may slowdown in 100-1000 times?
On Wed, Jan 7, 2009 at 10:54 PM,
<david@lang.hm> wrote:
On Wed, 7 Jan 2009, Dmitry Koterov wrote:
Hello.
Suppose I perform 1000 RANDOM writes into a file. These writes are saved
into Linux writeback buffer and are flushed to the disc asynchronously,
that's OK.
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?
E.g., if I write in the application:
a) block 835
b) block 136
c) block 956
d) block 549
e) block 942
dows the Linux background writer save flush them e.g. in physical order "136
- 549 - 835 - 942 - 956" or not?
they may end up being done 835-942-956-549-136 if the system thinks the head happens to be past 549 and moving up when the requests hit the IO system.
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
