The following bug has been logged online:

Bug reference: 1660
Logged by: Bogdan Matei
Email address: bogdan@in-consulting.net
PostgreSQL version: 7.3.2
Operating system: Red Hat 9.0 (everything standard distribution)
Description: Growing used memory and critical performance loss
Details:

Hello dear PostgreSQL community,

As short presentation about me: my name is Bogdan Matei,a software engineer
at INGC - a small company from Lausanne and from about 6 months i'm facing a
very interesting, but weird problem.

We have a standard Red Hat 9.0 Linux operating system, installed on Dell
Power Edge 1600 SC - an Intel Xeon 2.8 GHz, RAID 1 with 7200 RPM hard disks
speed,2 x 512MB dual channel memory and even all this server is dedicated to
be used by a single application, some king of chat by SMS from time to time
it delivers inacceptable performance. This is shown in simple queries that
last very long time (sometimes more then 3 minutes) and a permanent growing
used physical memory, until Postgresql reaches the linux swap when the speed
fails almost to nothing and a large number of "postmaster" proceses are
running in the same time.
These are the efects. First of all we thought that is our application that
consumes all the performance of Postgresql, with a predilection in the peak
time of traffic, we improved it very well but even so there is no change.
What is weird is that the only solution that we found is to reconfigure and
recreate the database at every 2-3 days. When is imediately created the
memory used is about 180MB then it constantly grows. When it comes to risc
to enter the swap we give a reboot to the pc and the memory is now 400+MB,
depending on the uptime. Even with these reboots (which we thought are
cleaning the memory leaks) in about 3 days the memory used is about
800-1000MB and then we have to start over with a dump of the database (it is
quite small, a few table of about 6000 records) and recreation of pg_data
and database. Then is working good again, but with the same weird scenario.
We studied lot of documentation, optimised the database, tried lots of
configuration options and setups, make lots of analyzis but we reached
nothing.
Now i'm asking you if you have some ideas... For every information you need
or/and even for access on our server you may contact me anytime and i hope
you'll do:-(...

I thank you very much and seek your opinions about this case,

Bogdan

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Wed, May 11, 2005 at 04:56:28PM +0100, Bogdan Matei wrote:

> These are the efects. First of all we thought that is our application that
> consumes all the performance of Postgresql, with a predilection in the peak
> time of traffic, we improved it very well but even so there is no change.
> What is weird is that the only solution that we found is to reconfigure and
> recreate the database at every 2-3 days. When is imediately created the
> memory used is about 180MB then it constantly grows.

The question that jumps at me is, what is your vacuum strategy?

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"World domination is proceeding according to plan" (Andrew Morton)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org