> 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. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
