Re: Configuration Recommendations - Mailing list pgsql-performance

From Shaun Thomas
Subject Re: Configuration Recommendations
Date
Msg-id 0683F5F5A5C7FE419A752A034B4A0B971B0EDA25@sswchi5pmbx2.peak6.net
Whole thread Raw
In response to Re: Configuration Recommendations  (Jan Nielsen <jan.sture.nielsen@gmail.com>)
List 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
memoryto 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
gargantuancash. We first noticed it after we upgraded from 32GB to 96GB. We have enough connections and other effects,
thatthe inode cache pool was only about 16GB. Take 40% of that (default CentOS 5.x) and you get 6GB. Not great, but
enoughyou might be able to get by without actually noticing the pauses. After tripling our memory, the database still
used16GB, but suddenly our inode cache jumped from 16GB to 80GB. 40% of that is 32GB, and there's no way our 512MB
controllercache 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@optionshouse.com


______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

pgsql-performance by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: Configuration Recommendations
Next
From: Eyal Wilde
Date:
Subject: Re: scale up (postgresql vs mssql)