Re: PostgreSQL performance problem -> tuning

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: PostgreSQL performance problem -> tuning
Дата
Msg-id 1060282754.12221.50.camel@haggis
обсуждение исходный текст
Ответ на Re: PostgreSQL performance problem -> tuning  (Yaroslav Mazurak <yamazurak@Lviv.Bank.Gov.UA>)
Список pgsql-performance
On Thu, 2003-08-07 at 12:04, Yaroslav Mazurak wrote:
> scott.marlowe wrote:
>
> > On Thu, 7 Aug 2003, Yaroslav Mazurak wrote:
>
> >>Shridhar Daithankar wrote:
>
[snip]
> > My guess is that this is exactly what's happening to you, you're using so
> > much memory that the machine is running out and slowing down.
>
> > Drop shared_buffers to 1000 to 4000, sort_mem to 8192 and start over from
> > there.  Then, increase them each one at a time until there's no increase
> > in speed, or stop if it starts getting slower and back off.
>
> > bigger is NOT always better.
>
>     Let I want to use all available RAM with PostgreSQL.
>     Without executing query (PostgreSQL is running) top say now:

You're missing the point.  PostgreSQL is not designed like Oracle,
Sybase, etc.

They say, "Give me all the RAM; I will cache everything myself."

PostgreSQL says "The kernel programmers have worked very hard on
disk caching.  Why should I duplicate their efforts?"

Thus, give PG only a "little" RAM, and let the OS' disk cache hold
the rest.

--
+---------------------------------------------------------------+
| Ron Johnson, Jr.        Home: ron.l.johnson@cox.net           |
| Jefferson, LA  USA                                            |
|                                                               |
| "Man, I'm pretty.  Hoo Hah!"                                  |
|    Johnny Bravo                                               |
+---------------------------------------------------------------+



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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: PostgreSQL performance problem -> tuning
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: PostgreSQL performance problem -> tuning