Re: Scaling further up

Поиск
Список
Период
Сортировка
От William Yu
Тема Re: Scaling further up
Дата
Msg-id c2i7o0$2urj$1@news.hub.org
обсуждение исходный текст
Ответ на Re: Scaling further up  ("Anjan Dave" <adave@vantage.com>)
Ответы Re: Scaling further up  (Robert Treat <xzilla@users.sourceforge.net>)
Список pgsql-performance
Anjan Dave wrote:
> Great response, Thanks.
>
> Regarding 12GB memory and 13G db, and almost no I/O, one thing I don't
> understand is that even though the OS caches most of the memory and PG
> can use it if it needs it, why would the system swap (not much, only
> during peak times)? The SHMMAX is set to 512MB, shared_buffers is 150MB,
> effective cache size is 2GB, sort mem is 2MB, rest is default values. It
> also happens that a large query (reporting type) can hold up the other
> queries, and the load averages shoot up during peak times.

In regards to your system going to swap, the only item I see is sort_mem
at 2MB. How many simultaneous transactions do you get? If you get
hundreds or thousands like your first message stated, every select sort
would take up 2MB of memory regardless of whether it needed it or not.
That could cause your swap activity during peak traffic.

The only other item to bump up is the effective cache size -- I'd set it
to 12GB.


В списке pgsql-performance по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Using bigint needs explicit cast to use the index
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature request: smarter use of conditional indexes