Thread: Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd

Zeev Suraski wrote:
>
> At 17:49 24/04/98 -0500, John Fieber wrote:
> >On Fri, 24 Apr 1998, Alex Belits wrote:
> >
> >> > Also, total memory usage is not simply usage of one invocation
> >> > times the number of invocations.  With a decent virtual memory
> >> > system, all invocations share memory for the text segment which
> >> > is over a megabyte for postgres. So, subtract (N-1) x 1MB from
> >> > your total.
> >>
> >>   Database servers have large amount of data in their processes, so they
> >> still will have to allocate it separately, even though they handle the
> >> same database.
> >
> >Certainly.  I was just pointing ou a potential memory use
> >miscalculation on the order of 1MB per process (the text size of
> >postgres), which is not exactly trivial.
>
> I might be missing something, but idle processes of an SQL server should
> take virtually no memory.  The code image is shared, the read-only data is
> shared, and the only memory that's not shared is the memory taken for
> process specific stuff, mainly memory needed during the processing of a
> query.  That memory will be freed as soon as the query is done, so it
> doesn't really matter.
> Again, I don't know if there might be some Postgres specific issues
> involved, but I've had a MySQL server with 150 threads taking all around
> 5MB (while processing some queries, too).

Is there a method of getting under Linux o.s. the *real* ammount of
memory that all postgres process use overall ?
I would inform you then how much memory will eat those processes and if
there is too big, I'll inform also PostgreSQL developers about it.

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

> Zeev Suraski wrote:
>> I might be missing something, but idle processes of an SQL server should
>> take virtually no memory.  The code image is shared, the read-only data is
>> shared, and the only memory that's not shared is the memory taken for
>> process specific stuff, mainly memory needed during the processing of a
>> query.  That memory will be freed as soon as the query is done, so it
>> doesn't really matter.

Well, not really.  On most versions of Unix, free() will never give
acquired memory back to the OS, so a process's data space never shrinks.
Therefore, each backend process will own an amount of memory
corresponding to the largest/most complex query it has processed to date.
An idle backend won't necessarily have a minimal amount of data space.

Of course, if the process is idle then its data space is likely to get
swapped out.  So you're right that the amount of real memory it is
using might be little or none.

            regards, tom lane