Re: synchronous_commit=off doesn't always return immediately

Поиск
Список
Период
Сортировка
Искать
От
Merlin Moncure
Тема
Re: synchronous_commit=off doesn't always return immediately
Дата
Msg-id
b42b73150908030725s770d9b15q8703bbbca63c880c@mail.gmail.com
Ответ на
Re: synchronous_commit=off doesn't always return immediately (tomrevam)
Список
Дерево обсуждения
synchronous_commit=off doesn't always return immediately tomrevam <tomer@fabrix.tv>
Re: synchronous_commit=off doesn't always return immediately Tom Lane <tgl@sss.pgh.pa.us>
Re: synchronous_commit=off doesn't always return immediately tomrevam <tomer@fabrix.tv>
Re: synchronous_commit=off doesn't always return immediately Merlin Moncure <mmoncure@gmail.com>
Partition tables Michael Gould <mgould@intermodalsoftwaresolutions.net>
Re: Partition tables Vick Khera <vivek@khera.org>
LDAP using Active Directory Michael Gould <mgould@intermodalsoftwaresolutions.net>
Re: LDAP using Active Directory Magnus Hagander <magnus@hagander.net>
Re: Partition tables Wojtek <foo@twine.pl>
using generate_series to iterate through months "Bill Reynolds" <Bill.Reynolds@ateb.com>
Re: using generate_series to iterate through months Tom Lane <tgl@sss.pgh.pa.us>
Re: using generate_series to iterate through months "Bill Reynolds" <Bill.Reynolds@ateb.com>
Re: using generate_series to iterate through months Andreas Kretschmer <akretschmer@spamfence.net>
Re: using generate_series to iterate through months Sam Mason <sam@samason.me.uk>
Re: synchronous_commit=off doesn't always return immediately Greg Smith <gsmith@gregsmith.com>
Re: synchronous_commit=off doesn't always return immediately tomrevam <tomer@fabrix.tv>
Re: synchronous_commit=off doesn't always return immediately Alvaro Herrera <alvherre@commandprompt.com>
Re: synchronous_commit=off doesn't always return immediately tomrevam <tomer@fabrix.tv>
Re: synchronous_commit=off doesn't always return immediately tomrevam <tomer@fabrix.tv> 
On Mon, Aug 3, 2009 at 2:14 AM, tomrevam wrote:
>
>
>
> Tom Lane-2 wrote:
>>
>> tomrevam  writes:
>> It might help to increase wal_buffers.
>>
>
> Hi,
>
> I increased the wal_buffers to 2 MB. Initially this improved the performance
> very much, but after 4 days of continuous operation the system is back to
> very long inserts and updates (at least as bad as it was before).
> Is there a way to know what resource the DB is running out of?


I can almost guarantee you that you are i/o bound.  synchronous commit
helps, but is not magic: your single sata disk can only deliver about
100-200 iops and you are expecting more than that.  I think you have
only two options: add more/faster disks (and consider separating wal
from the data volume) or disable sync completely with fsync=off (which
is of course quite dangerous).

This can be confirmed with an iostat, noting the tps on each volume
and the iowait.

merlin
В списке pgsql-general по дате отправления
Предыдущее
От: Tom Lane
Дата:
Следующее
От: Martijn van Oosterhout
Дата:
FAQ