> That sounds interesting. How do you identify a page flush storm?
Maybe I used the wrong terminology. What effectively happens if you reach the amount of memory specified in dirty_ratio, is that the system goes from asynchronous disk access, to synchronous disk access, and starts flushing that memory to disk. Until that operation completes, all other actions requiring disk access are paused.
You really, really don't want that to happen during a busy day on an OLTP system unless you have an absolutely gargantuan cash. We first noticed it after we upgraded from 32GB to 96GB. We have enough connections and other effects, that the inode cache pool was only about 16GB. Take 40% of that (default CentOS 5.x) and you get 6GB. Not great, but enough you might be able to get by without actually noticing the pauses. After tripling our memory, the database still used 16GB, but suddenly our inode cache jumped from 16GB to 80GB. 40% of that is 32GB, and there's no way our 512MB controller cache could try to swallow that without us noticing.
Things got much better when we set dirty_background_ratio to 1, and dirty_ratio to 10. That might be a tad too aggressive, but it worked for us.
OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
In response to
pgsql-performance by date
|Next:||From: Claudio Freire||Date: 2012-05-03 14:28:18|
|Subject: Re: Result Set over Network Question|
|Previous:||From: Jan Nielsen||Date: 2012-05-03 13:42:14|
|Subject: Re: Configuration Recommendations|