Re: BUG #12071: Stat collector went crasy (50MB/s constant writes)

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #12071: Stat collector went crasy (50MB/s constant writes)
Date: 2014-11-26 22:26:34
Message-ID: 5476539A.6090506@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 26.11.2014 23:06, Maxim Boguk wrote:
>
>
> I'm not sure I understand what you mean.
>
> The timestamp *IS* updated on every write - see this:
>
> https://github.com/postgres/postgres/blob/REL9_2_STABLE/src/backend/postmaster/pgstat.c#L3469
>
>
> I mean that usually 99.9% writes goes through mmap, which update the
> pgstat.tmp file timestamp (but not update last_statwrite value).

I don't follow. Can you explain what you mean by the mmap? I don't see
any mmap stuff in pgstat.c, nor I remember dealing with mmap in my
patches in this area ...

You mentioned the snippet:

if (last_statwrite < last_statrequest)
pgstat_write_statsfile(false);

and essentially what pgstat_write_statsfile() does is this:

1) open pgstat.tmp file
2) update globalStats.stats_timestamp to GetCurrentTimestamp();
3) write globalStats to the new file
4) ...

so it *does* update the timestamp on each write.

> But that enough to make backend_read_statsfile happy around
> https://github.com/postgres/postgres/blob/REL9_2_STABLE/src/backend/postmaster/pgstat.c#L3972
> without kicking poor statistic collector (and forcing full file rewrite) at
> https://github.com/postgres/postgres/blob/REL9_2_STABLE/src/backend/postmaster/pgstat.c#L3978

Well, the thing is that with 10 databases and 1s naptime, the launcher
starts a new autovacuum process every 100 ms. The first thing every
worker does is pgstat_read_statsfile() and this checks whether the stats
are older than 10 ms (which it is, because the last worker started
~100ms ago), and sends a new inquiry.

Regular backends use 640ms threshold, which is less than 100ms.

> PS: 1second autovacuum_naptime could be useful if you have small but
> very very actively updated tables, over 1 minute they could growth
> 100-500x size without autovacuum.
> 1minute naptime will have the same issue with 500 small idle databases :).

True. That's why I have reworked this in 9.3.

Anyway, this is not a bug - it works as designed/expected. It may be
imperfect, but that's how it is. The only thing you can do in 9.2 is
moving the pgstat.tmp to a tmpfs filesystem

Tomas

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Maxim Boguk 2014-11-26 23:01:32 Re: BUG #12071: Stat collector went crasy (50MB/s constant writes)
Previous Message Maxim Boguk 2014-11-26 22:06:19 Re: BUG #12071: Stat collector went crasy (50MB/s constant writes)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-11-26 22:40:52 Re: memory explosion on planning complex query
Previous Message Peter Geoghegan 2014-11-26 22:26:01 Re: memory explosion on planning complex query