Re: Reliability with RAID 10 SSD and Streaming Replication
От | Andrea Suisani |
---|---|
Тема | Re: Reliability with RAID 10 SSD and Streaming Replication |
Дата | |
Msg-id | 519E1FBC.9020409@opinioni.net обсуждение исходный текст |
Ответ на | Re: Reliability with RAID 10 SSD and Streaming Replication (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: