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
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 |