От: david@lang.hm
Тема: Re: SSD performance
Дата: ,
Msg-id: alpine.DEB.1.10.0902040640040.28633@asgard.lang.hm
(см: обсуждение, исходный текст)
Ответ на: Re: SSD performance  (Scott Carey)
Список: pgsql-performance

Скрыть дерево обсуждения

SSD performance  (, )
 Re: SSD performance  (Glyn Astill, )
  Re: SSD performance  (, )
 Re: SSD performance  (Luke Lonergan, )
  Re: SSD performance  (, )
   Re: SSD performance  ("M. Edward (Ed) Borasky", )
    Re: SSD performance  ("Joshua D. Drake", )
     Re: SSD performance  ("M. Edward (Ed) Borasky", )
    Re: SSD performance  (Matthew Wakeling, )
  Re: SSD performance  (Matthew Wakeling, )
  Re: SSD performance  (Craig Ringer, )
   Re: SSD performance  (Florian Weimer, )
   Re: SSD performance  (James Mansion, )
    Re: SSD performance  (, )
 Re: SSD performance  (Luke Lonergan, )
 Re: SSD performance  (Merlin Moncure, )
  Re: SSD performance  (, )
   Re: SSD performance  (Greg Smith, )
    Re: SSD performance  (, )
     Re: SSD performance  (Gregory Stark, )
      Re: SSD performance  (, )
 Re: SSD performance  (Scott Carey, )
  Re: SSD performance  (Jeff, )
   Re: SSD performance  (David Rees, )
   Re: SSD performance  (Scott Carey, )
    Re: SSD performance  (, )
    Re: SSD performance  (Jeff, )
   Re: SSD performance  (Scott Marlowe, )
  Re: SSD performance  (Matthew Wakeling, )

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 по дате сообщения:

От: Rajesh Kumar Mallah
Дата:
Сообщение: suggestions for postgresql setup on Dell 2950 , PERC6i controller
От: Scott Marlowe
Дата:
Сообщение: Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller