Re: slow query - will CLUSTER help?
| От | Shaun Thomas |
|---|---|
| Тема | Re: slow query - will CLUSTER help? |
| Дата | |
| Msg-id | 52B46C3B.20902@optionshouse.com обсуждение исходный текст |
| Ответ на | slow query - will CLUSTER help? (Sev Zaslavsky <sevzas@gmail.com>) |
| Ответы |
Re: slow query - will CLUSTER help?
|
| Список | pgsql-performance |
On 12/20/2013 09:57 AM, Sev Zaslavsky wrote: > There is a separate RAID-1 for WAL, another for tablespace and another > for operating system. I tend to stick to DB-size / 10 as a minimum, but I also have an OLTP system. For a more OLAP-type, the ratio is negotiable. The easiest way to tell is to monitor your disk IO stats. If you're seeing a READ-based utilization percentage over 50% consistently, you need more RAM. On our system, we average 10% through the day except for maintenance and loading phases. Of course, that's only for the current DB size. A good trick is to monitor your DB size changes on a daily basis, plot the growth percentage for a week, and apply compounding growth to estimate the size in three years. Most companies I've seen are on a 3-year replacement cycle, so that gives you how much you'll have to buy in order to avoid another spend until the next iteration. For example, say you have a 800GB database, and it grows at 10GB per week, so that's 40GB per month. In three years, you could need up to: 800 * (1 + 40/800)^36 = 4632GB of space, which translates to roughly 480-512 GB of RAM. You can probably find a comfortable middle ground with 240GB. Of course, don't forget to buy modules in multiples of four, otherwise you're not taking advantage of all the CPU's memory channels. :) -- 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 по дате отправления: