On Wed, Dec 10, 2014 at 2:30 AM, Strahinja Kustudić
<strahinjak@nordeus.com> wrote:
> On Wed, Dec 10, 2014 at 4:55 AM, Mark Kirkwood
> <mark.kirkwood@catalyst.net.nz> wrote:
>>
>> That is interesting: I've done some testing on this type of card with 16
>> (slightly faster Hitachi) SSD attached. Setting WT and NORA should enable
>> the so-called 'fastpath' mode for the card [1]. We saw performance improve
>> markedly (300MB/s random write go to 1300MB/s).
>>
>> This *might* be related to the fact that 16 SSD can put out more IOPS than
>> the card can actually handle - whereas your 8 S3500 is probably the perfect
>> number (e.g 8*11000 = 88000 which the card can handle ok).
>>
>>
>> [1] If you make the change while there are no outstanding background
>> operations (array rebuild etc) in progress (see
>> http://www.flagshiptech.com/eBay/Dell/poweredgeh310h710h810UsersGuide.pdf).
>
>
> I read that guide too, which is the reason why I tried with WT/NORA, but the
> document also states: "NOTE: RAID 10, RAID 50, and RAID 60 virtual disks
> cannot use FastPath." Which is a little odd, since usually if you want
> performance with reliability, you go RAID10.
>
> Do you have any suggestions what I could try to tweak to get more
> performance?
Definitely crank effective_io_concurrency. It will not help stock
pgbench test since it doesn't involve bitmap heap scans but when it
kicks in it's much faster.
http://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azsTdQ@mail.gmail.com
As it pertains to random read performance, I think you'll find that
you're getting pretty close to maxing out what the computer is
basically capable of -- I highly doubt you'll be read bound on storage
for any application; the classic techniques of optimizing queries,
indexes and tables is where focus your energy. Sequential write will
also be no problem.
The only area where the s3500 falls short is random writes. If your
random write i/o requirements are extreme, you've bought the wrong
drive, I'd have shelled out for the S3700 (but it's never too late;
you can stack one on and move high write activity tables to the s3700
driven tablespace).
merlni
