Postgres Pro
Downloads
Home   >   mailing lists

Thread: Postmaster is getting bigger

Postmaster is getting bigger

From
"S.F. Lee"
Date:
Hi everyone, 
 I posted this mail few days ago, but it
seemed that every one focused in about
ECPG problem.  I think it might be concerned 
if I would change another subject.
 I am revamping a computer system by Red Hat 6.0 +
PostgreSQL 6.5.3 + ecpg 2.7 + C. The user interface is
perl Pg + Apache. Everything seems fine, but when I
use "top" to display long term CPU processes, I find
the postmaster is getting bigger in step of 4 kb and
performance is getting worse GRADUALLY (It seems that
perl + Pg would make the size expansion more quickly
than ECPG). Here are some data display in "top": 
PID    SIZE    RSS     TIME    COMMAND
2526    1260   1260      0:00    postmaster  ---- when
postmaster started
2526   28384    20M     4:41    postmaster  ---- 2
days later
 I didn't find any error in tracing my program, and
the child postmaster is terminated correctly. I really
can't figure out the reason. Please give me advise. 
 I have installed the latest version 7.0RC5, but
Postmaster is getting bigger also (perl + Pg)

  Thanks              S.F.Lee

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Postmaster is getting bigger

From
Tom Lane
Date:
"S.F. Lee" <sflee_tw@yahoo.com> writes:
>   I am revamping a computer system by Red Hat 6.0 +
> PostgreSQL 6.5.3 + ecpg 2.7 + C. The user interface is
> perl Pg + Apache. Everything seems fine, but when I
> use "top" to display long term CPU processes, I find
> the postmaster is getting bigger in step of 4 kb and
> performance is getting worse GRADUALLY (It seems that
> perl + Pg would make the size expansion more quickly
> than ECPG). Here are some data display in "top": 

Are your clients connecting via TCP/IP, or via Unix sockets?

We recently discovered that the getprotobyname() library function
leaks memory in RH6.0 (at least with libc.so.6).  Since the postmaster
was calling that for each connection accepted via TCP, you'd see
steady growth of the postmaster over time on platforms with this bug.
Tim Brookes reported the leakage rate to be about 300 bytes per
connection cycle.

While this problem doesn't directly affect performance, it could slow
things down indirectly --- for example by making fork() take longer to
launch a new backend.

This is fixed for 7.0.1 by not calling getprotobyname().  If you are
in a hurry see the nightly snapshot tarballs...
        regards, tom lane

Re: Postmaster is getting bigger

From
"S.F. Lee"
Date:
--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 
> Are your clients connecting via TCP/IP, or via Unix
> sockets?

TCP/IP

> This is fixed for 7.0.1 by not calling
> getprotobyname().  If you are
> in a hurry see the nightly snapshot tarballs...
> 
>             regards, tom lane

I can wait, thanks. Can you explain "nightly snapshot
tarballs" more detail, since my English is too bad to
understand.             S.F. Lee


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Re: Postmaster is getting bigger

From
Tom Lane
Date:
"S.F. Lee" <sflee_tw@yahoo.com> writes:
> --- Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This is fixed for 7.0.1 by not calling
>> getprotobyname().  If you are
>> in a hurry see the nightly snapshot tarballs...

> I can wait, thanks. Can you explain "nightly snapshot
> tarballs" more detail, since my English is too bad to
> understand. 

If you look on the postgresql ftp site you will see a tar.gz
distribution file that's been generated today from currently
checked-in source files.  There's a script that runs each night
to update this snapshot.

At most times in the development cycle, the snapshot is
development-grade code and very possibly broken.  Right now,
however, we are in strict post-release-bugfix mode and so the
snapshot represents what will shortly become 7.0.1.
        regards, tom lane