Re: SSD performance - Mailing list pgsql-performance

From david@lang.hm
Subject Re: SSD performance
Date
Msg-id alpine.DEB.1.10.0902040640040.28633@asgard.lang.hm
Whole thread Raw
In response to Re: SSD performance  (Scott Carey <scott@richrelevance.com>)
List pgsql-performance
On Wed, 4 Feb 2009, Jeff wrote:

> On Feb 3, 2009, at 1:43 PM, Scott Carey wrote:
>
>> I don?t think write caching on the disks is a risk to data integrity if you
>> are configured correctly.
>> Furthermore, these drives don?t use the RAM for write cache, they only use
>> a bit of SRAM on the controller chip for that (and respect fsync), so write
>> caching should be fine.
>>
>> Confirm that NCQ is on (a quick check in dmesg),  I have seen degraded
>> performance when the wrong SATA driver is in use on some linux configs, but
>> your results indicate its probably fine.
>>
>
> As it turns out, there's a bug/problem/something with the controller in the
> macpro vs the ubuntu drives where the controller goes into "works, but not as
> super as it could" mode, so NCQ is effectively disabled, haven't seen a
> workaround yet. Not sure if this problem exists on other distros (used ubuntu
> because I just wanted to try a live).  I read some stuff from Intel on the
> NCQ and in a lot of cases it won't make that much difference because the
> thing can respond so fast.

actually, what I've heard is that NCQ is a win on the intel drives becouse
it avoids having the drive wait while the OS prepares and sends the next
write.

>> Some suggested tests if you are looking for more things to try :D
>> -- What affect does the following tuning have:
>>
>> Turn the I/O scheduler to ?noop?  ( echo noop >
>> /sys/block/<devices>/queue/scheduler)  I?m assuming the current was cfq,
>> deadline may also be interesting, anticipatory would have comically
>> horrible results.
>
> I only tested noop, if you think about it, it is the most logical one as an
> SSD really does not need an elevator at all. There is no rotational latency
> or moving of the arm that the elevator was designed to cope with.

you would think so, but that isn't nessasarily the case. here's a post
where NOOP lost to CFQ by ~24% when there were multiple proceses competing
for the drive (not on intel drives)

http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/

David Lang

pgsql-performance by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Deleting millions of rows
Next
From: Robert Haas
Date:
Subject: Re: Deleting millions of rows