Re: SSD performance

From: david(at)lang(dot)hm
To: Jeff <threshar(at)threshar(dot)is-a-geek(dot)com>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD performance
Date: 2009-02-04 14:45:01
Message-ID: alpine.DEB.1.10.0902040640040.28633@asgard.lang.hm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Rajesh Kumar Mallah 2009-02-04 18:45:43 suggestions for postgresql setup on Dell 2950 , PERC6i controller
Previous Message Robert Haas 2009-02-04 13:59:17 Re: Deleting millions of rows