Re: seperate swap drive, was Re: [ADMIN] Speed problem - Mailing list pgsql-admin

From G. Anthony Reina
Subject Re: seperate swap drive, was Re: [ADMIN] Speed problem
Date
Msg-id 3641E168.F8FC1CBE@nsi.edu
Whole thread Raw
In response to Re: seperate swap drive, was Re: [ADMIN] Speed problem  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: seperate swap drive, was Re: [ADMIN] Speed problem  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-admin
Marc,


    I'm running PostgreSQL v. 6.3.2. No I don't want to disable fsync just
in case someone stops a process midstream (which has happened before-- I
figure it could screw up the db). So maybe it is those "memory leaks"
that you've suggested. I'll try closing and re-connecting to see if
there are any differences. However, I would be interested in downloading
v. 6.4. Do you know where to get it? (I think it is a beta version but I
couldn't find it on the www site).

    Thanks.
-Tony Reina

p.s. Does 6.4 have page-level locking?

The Hermit Hacker wrote:

>
>         Are you running with fsync() disabled?
>
>         What version of PostgreSQL are you running?  v6.4 has several
> memory leak fixes in it, which may or may not help...on long term
> connections, memory leak *may* be attributing to your problem.  If you run
> top while doing the 'update/inserts', does the process size just continue
> to rise?
>
>         Something else to try...close and reconnect your insert/update
> process(es).  Not a long term solution, just curious if that shows an
> overall speed improvement.  Similar to the 'memory leak' problem, at least
> this will let go of the process, clean out the memory, and start over
> again....
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

pgsql-admin by date:

Previous
From: "David Ben-Yaacov"
Date:
Subject: Re: seperate swap drive, was Re: [ADMIN] Speed problem
Next
From: "John E. Garrott"
Date:
Subject: 6.4 installation