Re: Configuring PostgreSQL to minimize impact of checkpoints
От | jao@geophile.com |
---|---|
Тема | Re: Configuring PostgreSQL to minimize impact of checkpoints |
Дата | |
Msg-id | 1084389767.40a27987437da@geophile.com обсуждение исходный текст |
Ответ на | Re: Configuring PostgreSQL to minimize impact of checkpoints (Vivek Khera <khera@kcilink.com>) |
Ответы |
Re: Configuring PostgreSQL to minimize impact of checkpoints
|
Список | pgsql-performance |
Quoting Vivek Khera <khera@kcilink.com>: > >>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > TL> Jack Orenstein <jao@geophile.com> writes: > >> I'm looking at one case in which two successive transactions, each > >> updating a handful of records, take 26 and 18 *seconds* (not msec) to > >> complete. These transactions normally complete in under 30 msec. > > TL> I've seen installations in which it seemed that the "normal" query load > TL> was close to saturating the available disk bandwidth, and the extra load > TL> imposed by a background VACUUM just pushed the entire system's response > TL> time over a cliff. In an installation that has I/O capacity to spare, > ... > TL> I suspect that the same observations hold true for checkpoints, though > TL> I haven't specifically seen an installation suffering from that effect. > > I don't see that. But I also set checkpoint segments to about 50 on > my big server. But wouldn't that affect checkpoint frequency, not checkpoint cost? Jack Orenstein ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
В списке pgsql-performance по дате отправления: