On Thu, Apr 5, 2012 at 10:49 AM, Tomas Vondra <tv@xxxxxxxx> wrote: > On 5.4.2012 17:17, Cesar Martin wrote: >> Well, I have installed megacli on server and attach the results in file >> megacli.txt. Also we have "Dell Open Manage" install in server, that can >> generate a log of H800. I attach to mail with name lsi_0403. >> >> About dirty limits, I have default values: >> vm.dirty_background_ratio = 10 >> vm.dirty_ratio = 20 >> >> I have compared with other server and values are the same, except in >> centos 5.4 database production server that have vm.dirty_ratio = 40 > > Do the other machines have the same amount of RAM? The point is that the > values that work with less memory don't work that well with large > amounts of memory (and the amount of RAM did grow a lot recently). > > For example a few years ago the average amount of RAM was ~8GB. In that > case the > > vm.dirty_background_ratio = 10 => 800MB > vm.dirty_ratio = 20 => 1600MB > > which is all peachy if you have a decent controller with a write cache. > But turn that to 64GB and suddenly > > vm.dirty_background_ratio = 10 => 6.4GB > vm.dirty_ratio = 20 => 12.8GB > > The problem is that there'll be a lot of data waiting (for 30 seconds by > default), and then suddenly it starts writing all of them to the > controller. Such systems behave just as your system - short strokes of > writes interleaved with 'no activity'. > > Greg Smith wrote a nice howto about this - it's from 2007 but all the > recommendations are still valid: > > http://www.westnet.com/~gsmith/content/linux-pdflush.htm > > TL;DR: > > - decrease the dirty_background_ratio/dirty_ratio (or use *_bytes) > > - consider decreasing the dirty_expire_centiseconds The original problem is read based performance issue though and this will not have any affect on that whatsoever (although it's still excellent advice). Also dd should bypass the o/s buffer cache. I still pretty much convinced that there is a fundamental performance issue with the raid card dell needs to explain. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
