Re: Return of the Solaris vacuum polling problem -- anyone remember this?

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Return of the Solaris vacuum polling problem -- anyone remember this?
Дата
Msg-id 4C6C431B.9010406@agliodbs.com
обсуждение исходный текст
Ответ на Re: Return of the Solaris vacuum polling problem -- anyone remember this?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Return of the Solaris vacuum polling problem -- anyone remember this?  (Josh Berkus <josh@agliodbs.com>)
Re: Return of the Solaris vacuum polling problem -- anyone remember this?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> That would explain all the writes, but it doesn't seem to explain why
> your two servers aren't behaving similarly.

Well, that's why I said "ostensibly identical".  There may in fact be
differences, not just in the databases but in some OS libs as well.
These servers have been in production for quite a while, and the owner
has a messy deployment process.

> Most likely that's the libc implementation of the select()-based sleeps
> for vacuum_cost_delay.  I'm still suspicious that the writes are eating
> more cost_delay points than you think.

Tested that.  It does look like if I increase vacuum_cost_limit to 10000
and lower vacuum_cost_page_dirty to 10, it reads 5-7 pages and writes
2-3 before each pollsys.  The math seems completely wrong on that,
though -- it should be 50 and 30 pages, or similar.  If I can, I'll test
a vacuum without cost_delay and make sure the pollsys() are connected to
the cost delay and not something else.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: patch: utf8_to_unicode (trivial)
Следующее
От: Robert Haas
Дата:
Сообщение: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!