Re: Questions regarding contrib/tsearch

Поиск
Список
Период
Сортировка
От Markus Wollny
Тема Re: Questions regarding contrib/tsearch
Дата
Msg-id 2266D0630E43BB4290742247C8910575014CE331@dozer.computec.de
обсуждение исходный текст
Ответ на Questions regarding contrib/tsearch  ("Markus Wollny" <Markus.Wollny@computec.de>)
Список pgsql-general
Hi!

> > If so, what can I do to have all of the database in memory?
>
> Buy enough RAM to hold it ;-)
>
> If the database is being accessed heavily then it will tend to remain
> swapped in; you don't have to (and really can't) do anything to tweak
> the kernel-level and Postgres-level algorithms that determine this.
> What you want is to ensure there's enough RAM to hold not only all the
> database hotspots, but also all the other programs and working data
> that the server machine will be running.
>
> Check the actual size-on-disk of the tables and indexes you would like
> to be resident.  (Do a vacuum, then look at pg_class.relpages
> for these
> items.  See
> http://developer.postgresql.org/docs/postgres/diskusage.html
> for more info.)
>
> I would allow about 10MB of RAM per server process, plus a
> healthy chunk
> for the kernel and other programs.

Is that 10MB per process on top of total database size + shared_buffers?

In my case that would be roughly 1024MB database size + 2560 MB for
processes (256 max.) + 256 MB for shared_buffers, I think. Or did I
misunderstand you? Because in real life operation, RAM doesn't seem to
be a problem, as there's hardly any swap-activity and most of the
available RAM is used by system cache.

Regards,

    Markus

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

Предыдущее
От: "Johnson, Shaunn"
Дата:
Сообщение: reloading really big tables
Следующее
От: Bruce Momjian
Дата:
Сообщение: O'Reilly Open Source Convention Report