Re: SSD performance
От | david@lang.hm |
---|---|
Тема | Re: SSD performance |
Дата | |
Msg-id | alpine.DEB.1.10.0902040640040.28633@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: SSD performance (Scott Carey <scott@richrelevance.com>) |
Список | 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 по дате отправления: