Re: Configuration Recommendations
От | Shaun Thomas |
---|---|
Тема | Re: Configuration Recommendations |
Дата | |
Msg-id | 0683F5F5A5C7FE419A752A034B4A0B971B0EDA25@sswchi5pmbx2.peak6.net обсуждение исходный текст |
Ответ на | Re: Configuration Recommendations (Jan Nielsen <jan.sture.nielsen@gmail.com>) |
Список | 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 по дате отправления: