Re: Linux I/O tuning: CFQ vs. deadline
От | Kevin Grittner |
---|---|
Тема | Re: Linux I/O tuning: CFQ vs. deadline |
Дата | |
Msg-id | 4B6FD868020000250002F084@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Linux I/O tuning: CFQ vs. deadline ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Linux I/O tuning: CFQ vs. deadline
|
Список | pgsql-performance |
"Albe Laurenz" <laurenz.albe@wien.gv.at> wrote: > Greg Smith wrote: >> http://insights.oetiker.ch/linux/fsopbench/ > > That is interesting; particularly since I have made one quite > different experience in which deadline outperformed CFQ by a > factor of approximately 4. I haven't benchmarked it per se, but when we started using PostgreSQL on Linux, the benchmarks and posts I could find recommended deadline=elevator, so we went with that, and when the setting was missed on a machine it was generally found fairly quickly because people complained that the machine wasn't performing to expectations; changing this to deadline corrected the problem. > So I tried to look for differences, and I found two possible > places: > - My test case was read-only, our production system is > read-mostly. Yeah, our reads are typically several times our writes -- up to maybe 10 to 1. > - We did not have a RAID array, but a SAN box (with RAID inside). No SAN here, but if I recall correctly, this was mostly an issue on our larger arrays -- RAID 5 with dozens of spindles on a BBU hardware controller. Other differences between our environment and that of the benchmarks cited above: - We use SuSE Linux Enterprise Server, so we've been on *much* earlier kernel versions that this benchmark. - We've been using xfs, with noatime,nobarrier. I'll keep this in mind as something to try if we have problem performance in line with what that page describes, though.... -Kevin
В списке pgsql-performance по дате отправления: