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
