Обсуждение: Effect of stopped status collector process

Hello,

    I have started to explore PG,
I have found pgstat.stat file taking too much write hits.
As my need to deploy on flash based storage. I don't want higher I/O's
To stop status collector process I have change postmaster.c by removing
calls of pgstat.c
Now every thing is working fine, Status collector process is not initiated ?

Any drawbacks for not writing pgstat.stat ?
Is there another way to achieve this or
Will this create any problem like If pgstat.c is initiating some data
structures
which is shared to postmaster.c or else part

- Siddharth.

Siddharth Shah <siddharth.shah@elitecore.com> writes:
> I have found pgstat.stat file taking too much write hits.
> As my need to deploy on flash based storage. I don't want higher I/O's
> To stop status collector process I have change postmaster.c by removing
> calls of pgstat.c
> Now every thing is working fine, Status collector process is not initiated ?

> Any drawbacks for not writing pgstat.stat ?

Autovacuum doesn't work ...

If you are willing to run a hand-hacked version then I'd suggest doing
your experimentation with CVS HEAD.  There are changes in place already
to reduce the stats file traffic.

            regards, tom lane

Tom Lane wrote:

> If you are willing to run a hand-hacked version then I'd suggest doing
> your experimentation with CVS HEAD.  There are changes in place already
> to reduce the stats file traffic.

Why do we _have_ to write the file to disk?  I wonder if it would work
to store the file in a mmaped memory region and have the readers get
data from there.  We could have more than one copy, reference-counted so
that they can be removed when the old readers are gone.

Are MAP_SHARED | MAP_ANONYMOUS mmapped regions portable?  Linux claims
to support them from 2.4.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Are MAP_SHARED | MAP_ANONYMOUS mmapped regions portable?

No.

            regards, tom lane

On Tue, Nov 25, 2008 at 9:03 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Tom Lane wrote:
>
>> If you are willing to run a hand-hacked version then I'd suggest doing
>> your experimentation with CVS HEAD.  There are changes in place already
>> to reduce the stats file traffic.
>
> Why do we _have_ to write the file to disk?  I wonder if it would work
> to store the file in a mmaped memory region and have the readers get
> data from there.  We could have more than one copy, reference-counted so
> that they can be removed when the old readers are gone.

what about fifo files...would they be appropriate for something like this?

merlin

Merlin Moncure escribió:
> On Tue, Nov 25, 2008 at 9:03 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:

> > Why do we _have_ to write the file to disk?  I wonder if it would work
> > to store the file in a mmaped memory region and have the readers get
> > data from there.  We could have more than one copy, reference-counted so
> > that they can be removed when the old readers are gone.
>
> what about fifo files...would they be appropriate for something like this?

Doubtful -- the collector would have to write the contents every time
someone wanted to read it, and nobody could open it while someone else
is reading (or they'd read from the middle of the contents).

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support