Re: Stats collector constant I/O

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Stats collector constant I/O
Дата
Msg-id 53754D59.3060800@fuzzy.cz
обсуждение исходный текст
Ответ на Stats collector constant I/O  (Craig James <cjames@emolecules.com>)
Список pgsql-performance
On 15.5.2014 06:18, Craig James wrote:
> Day and night, the postgres stats collector process runs at about 20
> MB/sec output.  vmstat shows this:
>
> $ vmstat 2
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
>  0  0  55864 135740 123804 10712928    4    6   445  2642    0    0  5
> 1 92  2
>  1  0  55864 134820 123804 10713012    0    0     0 34880  540  338  1
> 1 98  0
>  0  0  55864 135820 123812 10712896    0    0     0 20980  545  422  1
> 1 98  0
>
> iotop(1) shows that it's the stats collector, running at 20 MB/sec.

Which PostgreSQL version are you running? And how many databases /
objects (tables, indexes) are there?

With versions up to 9.1, and large number of objects this is quite
normal. The file size is proportional to the number of objects, and may
get written quite frequently.

The newer versions (since 9.2) have per-database file, which usually
significantly decreases the load - both CPU and I/O. But if you have all
the objects are in a single database, this is not going to help.

I'd recommend moving the stat directory to tmpfs (i.e. memory-based
filesystem) - this improves the I/O load, but it may still consume
nontrivial amount of CPU time to read/write it.

Tomas


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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Query plan good in 8.4, bad in 9.2 and better in 9.3
Следующее
От: "Huang, Suya"
Дата:
Сообщение: same query different execution plan (hash join vs. semi-hash join)