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 T. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
