Skip site navigation (1) Skip section navigation (2)

Re: Configuration Recommendations

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Jan Nielsen <jan(dot)sture(dot)nielsen(at)gmail(dot)com>
Cc: Robert Klemme <shortcutter(at)googlemail(dot)com>,"pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, John Lister <john(dot)lister(at)kickstone(dot)co(dot)uk>
Subject: Re: Configuration Recommendations
Date: 2012-05-03 13:52:02
Message-ID: 0683F5F5A5C7FE419A752A034B4A0B971B0EDA25@sswchi5pmbx2.peak6.net (view raw or flat)
Thread:
Lists: pgsql-performance
> 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
sthomas(at)optionshouse(dot)com


______________________________________________

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 FreireDate: 2012-05-03 14:28:18
Subject: Re: Result Set over Network Question
Previous:From: Jan NielsenDate: 2012-05-03 13:42:14
Subject: Re: Configuration Recommendations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group