On 05/23/2013 03:47 PM, Merlin Moncure wrote: [cut]
<quote> [..] There are two components to the Swingbench test we're running here: the database itself, and the redo log. The redo log stores all changes that are made to the database, which allows the database to be reconstructed in the event of a failure. In good DB design, these two would exist on separate storage systems, but in order to increase IO we combined them both for this test. Accesses to the DB end up being 8KB and random in nature, a definite strong suit of the S3700 as we've already shown. The redo log however consists of a bunch of 1KB - 1.5KB, QD1, sequential accesses. The S3700, like many of the newer controllers we've tested, isn't optimized for low queue depth, sub-4KB, sequential workloads like this. [..] </quote> Does this kind of scenario apply to postgresql wal files repo ?huh -- I don't think so. wal file segments are 8kb aligned, ditto clog, etc. In XLogWrite(): /* OK to write the page(s) */ from = XLogCtl->pages + startidx * (Size) XLOG_BLCKSZ; nbytes = npages * (Size) XLOG_BLCKSZ; <-- errno = 0; if (write(openLogFile, from, nbytes) != nbytes) { AFICT, that's the only way you write out xlog. One thing I would definitely advise though is to disable partial page writes if it's enabled. s3700 is algined on 8kb blocks internally -- hm.
many thanks merlin for both the explanation and the good advice :) andrea -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
