Re: Postgres low end processing.

Поиск
Список
Период
Сортировка
От Stef
Тема Re: Postgres low end processing.
Дата
Msg-id 20031006095551.1d7bfeb8.svb@ucs.co.za
обсуждение исходный текст
Ответ на Re: Postgres low end processing.  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Postgres low end processing.  (Bruno Wolff III <bruno@wolff.to>)
Re: Postgres low end processing.  (Josh Berkus <josh@agliodbs.com>)
Re: Postgres low end processing.  (Stef <svb@ucs.co.za>)
Список pgsql-performance
Thanks for the replies,

On Fri, 3 Oct 2003 11:08:48 -0700
Josh Berkus <josh@agliodbs.com> wrote:
=> 1. Make sure that the WAL files (pg_xlog) are on a seperate disk from the
=> database files, either through mounting or symlinking.

I'm not sure I understand how this helps?

=> 2. Tweak the .conf file for low vacuum_mem (1024?), but vacuum very
=> frequently, like every 1-5 minutes.  Spend some time tuning your
=> fsm_max_pages to the ideal level so that you're not allocating any extra
=> memory to the FSM.
=>
=> 3. If your concern is *average* CPU/RAM consumption, and not peak load
=> activity, increase wal_files and checkpoint_segments to do more efficient
=> batch processing of pending updates as the cost of some disk space.  If peak
=> load activity is a problem, don't do this.
=>
=> 4. Tune all of your queries carefully to avoid anything requiring a
=> RAM-intensive merge join or CPU-eating calculated expression hash join, or
=> similar computation-or-RAM-intensive operations.

Thanks, I'll try some of these, and post the results.
The actual machines seem to be Pentium I machines,
with 32M RAM. I've gathered that it is theoretically
possible, so no to go try it.

Regards
Stef

Вложения

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

Предыдущее
От: Shridhar Daithankar
Дата:
Сообщение: Re: Postgres low end processing.
Следующее
От: Jeff
Дата:
Сообщение: Re: reindex/vacuum locking/performance?