Re: [Again] Postgres performance problem

Поиск
Список
Период
Сортировка
От Gavin M. Roy
Тема Re: [Again] Postgres performance problem
Дата
Msg-id af1bce590709130831r679a8d63q7ad289804879f1f5@mail.gmail.com
обсуждение исходный текст
Ответ на [Again] Postgres performance problem  (Ruben Rubio <ruben@rentalia.com>)
Ответы Re: [Again] Postgres performance problem  (Ruben Rubio <ruben@rentalia.com>)
Список pgsql-performance
How many backends do you have at any given time?  Have you tried using
something like pgBouncer to lower backend usage?  How about your IO
situation?  Have you run something like sysstat to see what iowait is
at?

On 9/11/07, Ruben Rubio <ruben@rentalia.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi,
>
> I having the same problem I told here a few weeks before. Database is
> using too much resources again.
>
> I do a vacumm full each day, but seems it is not working. I am preparing
> an update to postgres 8.2.4 (actually I am using at 8.1.3, and tests for
> update will need several days)
>
> Last time I had this problem i solved it stopping website,  restarting
> database, vacuumm it, run again website. But I guess this is going to
> happen again.
>
> I would like to detect and solve the problem. Any ideas to detect it?
>
> Thanks in advance,
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG5jbLIo1XmbAXRboRArcpAJ0YvoCT6KWv2fafVAtapu6nwFmKoACcD0uA
> zFTx9Wq+2NSxijIf/R8E5f8=
> =u0k5
> -----END PGP SIGNATURE-----
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>
>
>

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Long Running Commits - Not Checkpoints
Следующее
От: Brad Nicholson
Дата:
Сообщение: Re: Long Running Commits - Not Checkpoints