Thread: DB Getting Slower and Slower and Slower....
Hi,
I recently upgraded to V7.1 version of Postgres on Linux and have noticed
that as the DB is being used, it gets progressively slower and slower, until
very simple queries slow down to a crawl. The basic setup I have is a set of
JSPs and Servlets running on Tomcat, that use Java classes which connect to
Postgres through a JDBC driver and perform various DB operations. But, as I
said, the DB gets noticeably slower, as if it does not clean up behind
itself after performing operations and finally runs out of memory... Then,
the only thing that works is stopping the postmaster and rebooting the
machine.
If you have any ideas of what may cause this or what I can do to explore
the issue, I would be very grateful. I am fairly new to Postgres, so any
suggestions are welcome.
Thanks,
Othman
_____________________________
Othman Laraki
Epitrope Corporation
860 Hillview Court, Suite 200
Milpitas, CA 95035, USA
650-814-9580 (phone)
650-745-2449 (fax)
othman@epitrope.com
Do you VACUUM and VACUUM ANALYZE regularly? -Mitch ----- Original Message ----- From: "Othman Laraki" <othman@epitrope.com> To: <pgsql-general@postgresql.org> Sent: Thursday, May 03, 2001 11:59 PM Subject: DB Getting Slower and Slower and Slower.... > > > Hi, > I recently upgraded to V7.1 version of Postgres on Linux and have noticed > that as the DB is being used, it gets progressively slower and slower, until > very simple queries slow down to a crawl. The basic setup I have is a set of > JSPs and Servlets running on Tomcat, that use Java classes which connect to > Postgres through a JDBC driver and perform various DB operations. But, as I > said, the DB gets noticeably slower, as if it does not clean up behind > itself after performing operations and finally runs out of memory... Then, > the only thing that works is stopping the postmaster and rebooting the > machine. > > If you have any ideas of what may cause this or what I can do to explore > the issue, I would be very grateful. I am fairly new to Postgres, so any > suggestions are welcome. > > Thanks, > Othman > > > _____________________________ > Othman Laraki > Epitrope Corporation > 860 Hillview Court, Suite 200 > Milpitas, CA 95035, USA > 650-814-9580 (phone) > 650-745-2449 (fax) > othman@epitrope.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
Yup -----Original Message----- From: Mitch Vincent [mailto:mitch@venux.net] Sent: Thursday, May 03, 2001 8:59 PM To: Othman Laraki; pgsql-general@postgresql.org Subject: Re: DB Getting Slower and Slower and Slower.... Do you VACUUM and VACUUM ANALYZE regularly? -Mitch ----- Original Message ----- From: "Othman Laraki" <othman@epitrope.com> To: <pgsql-general@postgresql.org> Sent: Thursday, May 03, 2001 11:59 PM Subject: DB Getting Slower and Slower and Slower.... > > > Hi, > I recently upgraded to V7.1 version of Postgres on Linux and have noticed > that as the DB is being used, it gets progressively slower and slower, until > very simple queries slow down to a crawl. The basic setup I have is a set of > JSPs and Servlets running on Tomcat, that use Java classes which connect to > Postgres through a JDBC driver and perform various DB operations. But, as I > said, the DB gets noticeably slower, as if it does not clean up behind > itself after performing operations and finally runs out of memory... Then, > the only thing that works is stopping the postmaster and rebooting the > machine. > > If you have any ideas of what may cause this or what I can do to explore > the issue, I would be very grateful. I am fairly new to Postgres, so any > suggestions are welcome. > > Thanks, > Othman > > > _____________________________ > Othman Laraki > Epitrope Corporation > 860 Hillview Court, Suite 200 > Milpitas, CA 95035, USA > 650-814-9580 (phone) > 650-745-2449 (fax) > othman@epitrope.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
"Othman Laraki" <othman@epitrope.com> writes: > I recently upgraded to V7.1 version of Postgres on Linux and have > noticed that as the DB is being used, it gets progressively slower > and slower, until very simple queries slow down to a crawl. First question: are you VACUUMing enough? How active is the DB with respect to inserts/updates? You should be doing VACUUM ANALYZE at least nightly (some people with very busy databases do it every couple hours). > The > basic setup I have is a set of JSPs and Servlets running on Tomcat, > that use Java classes which connect to Postgres through a JDBC > driver and perform various DB operations. But, as I said, the DB > gets noticeably slower, as if it does not clean up behind itself > after performing operations and finally runs out of memory... Then, > the only thing that works is stopping the postmaster and rebooting > the machine. Very odd. You certainly shouldn't have to reboot to reclaim memory; restarting the postmaster should be enough. Are you sure the Java app or some other process isn't eating up all the memory? I was getting PG backend crashes due to lack of memory every few days for a while, and finally found that it was my webserver that was running away with itself... Also make sure you're using the latest JDBC driver (early 7.1 RPMs had one that was out of date). Are you doing connection pooling in your web app? Or does each servlet/JSP connect and disconnect on its own? -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan
Hi, We have an application running the same Java-tomcat on Apache running on Oracle DB. We have a max of 3 users per second connection on it and you now what, we have to restart the Apache daemon at 12 and 22 hours each days. For me the problem is not relative to the database but only to Java. Take a look at your memory you will see that it goes were we don't know. So now we don't use Java anymore. Perl and Mod_perl as the same perf and it's stable. Regards Gilles DAROLD Mitch Vincent wrote: > Do you VACUUM and VACUUM ANALYZE regularly? > > -Mitch > ----- Original Message ----- > From: "Othman Laraki" <othman@epitrope.com> > To: <pgsql-general@postgresql.org> > Sent: Thursday, May 03, 2001 11:59 PM > Subject: DB Getting Slower and Slower and Slower.... > > > > > > > Hi, > > I recently upgraded to V7.1 version of Postgres on Linux and have noticed > > that as the DB is being used, it gets progressively slower and slower, > until > > very simple queries slow down to a crawl. The basic setup I have is a set > of > > JSPs and Servlets running on Tomcat, that use Java classes which connect > to > > Postgres through a JDBC driver and perform various DB operations. But, as > I > > said, the DB gets noticeably slower, as if it does not clean up behind > > itself after performing operations and finally runs out of memory... Then, > > the only thing that works is stopping the postmaster and rebooting the > > machine. > > > > If you have any ideas of what may cause this or what I can do to explore > > the issue, I would be very grateful. I am fairly new to Postgres, so any > > suggestions are welcome. > > > > Thanks, > > Othman > > > > > > _____________________________ > > Othman Laraki > > Epitrope Corporation > > 860 Hillview Court, Suite 200 > > Milpitas, CA 95035, USA > > 650-814-9580 (phone) > > 650-745-2449 (fax) > > othman@epitrope.com > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html
Hi Guys,
I don't know if this has any bearing, but I remember someone recently
saying that Sun's JDK 1.3 has a memory leak bug in one of it's releases,
and our JDBC driver is affected by that.
Not sure of it's present status though.
Regards and best wishes,
Justin Clift
Doug McNaught wrote:
>
> "Othman Laraki" <othman@epitrope.com> writes:
>
> > I recently upgraded to V7.1 version of Postgres on Linux and have
> > noticed that as the DB is being used, it gets progressively slower
> > and slower, until very simple queries slow down to a crawl.
>
> First question: are you VACUUMing enough? How active is the DB with
> respect to inserts/updates? You should be doing VACUUM ANALYZE at
> least nightly (some people with very busy databases do it every couple
> hours).
>
> > The
> > basic setup I have is a set of JSPs and Servlets running on Tomcat,
> > that use Java classes which connect to Postgres through a JDBC
> > driver and perform various DB operations. But, as I said, the DB
> > gets noticeably slower, as if it does not clean up behind itself
> > after performing operations and finally runs out of memory... Then,
> > the only thing that works is stopping the postmaster and rebooting
> > the machine.
>
> Very odd. You certainly shouldn't have to reboot to reclaim memory;
> restarting the postmaster should be enough.
>
> Are you sure the Java app or some other process isn't eating up all
> the memory? I was getting PG backend crashes due to lack of memory
> every few days for a while, and finally found that it was my
> webserver that was running away with itself...
>
> Also make sure you're using the latest JDBC driver (early 7.1 RPMs had
> one that was out of date).
>
> Are you doing connection pooling in your web app? Or does each
> servlet/JSP connect and disconnect on its own?
>
> -Doug
> --
> The rain man gave me two cures; he said jump right in,
> The first was Texas medicine--the second was just railroad gin,
> And like a fool I mixed them, and it strangled up my mind,
> Now people just get uglier, and I got no sense of time... --Dylan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
On 04 May 2001 23:32:12 +1000, Justin Clift wrote: > I don't know if this has any bearing, but I remember someone recently > saying that Sun's JDK 1.3 has a memory leak bug in one of it's releases, > and our JDBC driver is affected by that. JDK1.3.0_2 fixed that for me. When I moved from 7.0.3 to 7.1RC4 I changed the JDK. Read the JDK changelogs they mention something Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html
Tony Grant wrote: > > On 04 May 2001 23:32:12 +1000, Justin Clift wrote: > > > I don't know if this has any bearing, but I remember someone recently > > saying that Sun's JDK 1.3 has a memory leak bug in one of it's releases, > > and our JDBC driver is affected by that. > > JDK1.3.0_2 fixed that for me. When I moved from 7.0.3 to 7.1RC4 I > changed the JDK. Read the JDK changelogs they mention something I haven't seen a problem since switching from jdk1.3.0 to jdk1.3.1rc2, either. -- Steve Wampler- SOLIS Project, National Solar Observatory swampler@noao.edu
Hi Doug,
Thanks for the suggestions.
With regards to vacuuming, yes, I do vacuum enough. I even tried vacuuming
right before each query, but it still slows down.
For the running out of memory part, there seem to be two aspects to it:
1) I tried running the application on a separate machine to make sure that
it was not my code that was eating up all the memory but that did not help.
However, I suspect that my code may be "losing" some connections (i.e.
leaves them dangling somewhere in the ether :-). Do you know of a way to as
Postgres how many open connections it currently has and the client IP's that
opened those connections?
2) Even though the DB gets faster after reboot, I have the impression (no
hard data to support this) that with usage, it gets slower in general. When
I had a clean machine, right after installation, it was lightening-fast.
However, even though the data that is loaded in the DB did not increase in
size all that much, after that it has been used for a while, the DB gets
progressively slower.
With regards to the JDBC driver that I am using, I am using one that I had
built with v7.0. The reason for this is that I had applied a patch to
correct the mutli-byte support that was not working. Has this problem been
fixed in the new version of the JDBC driver? If so, I would gladly switch.
Thanks,
Othman
-----Original Message-----
From: doug@belphigor.mcnaught.org [mailto:doug@belphigor.mcnaught.org]On
Behalf Of Doug McNaught
Sent: Thursday, May 03, 2001 9:19 PMs
To: Othman Laraki
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] DB Getting Slower and Slower and Slower....
"Othman Laraki" <othman@epitrope.com> writes:
> I recently upgraded to V7.1 version of Postgres on Linux and have
> noticed that as the DB is being used, it gets progressively slower
> and slower, until very simple queries slow down to a crawl.
First question: are you VACUUMing enough? How active is the DB with
respect to inserts/updates? You should be doing VACUUM ANALYZE at
least nightly (some people with very busy databases do it every couple
hours).
> The
> basic setup I have is a set of JSPs and Servlets running on Tomcat,
> that use Java classes which connect to Postgres through a JDBC
> driver and perform various DB operations. But, as I said, the DB
> gets noticeably slower, as if it does not clean up behind itself
> after performing operations and finally runs out of memory... Then,
> the only thing that works is stopping the postmaster and rebooting
> the machine.
Very odd. You certainly shouldn't have to reboot to reclaim memory;
restarting the postmaster should be enough.
Are you sure the Java app or some other process isn't eating up all
the memory? I was getting PG backend crashes due to lack of memory
every few days for a while, and finally found that it was my
webserver that was running away with itself...
Also make sure you're using the latest JDBC driver (early 7.1 RPMs had
one that was out of date).
Are you doing connection pooling in your web app? Or does each
servlet/JSP connect and disconnect on its own?
-Doug
--
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time... --Dylan
"Othman Laraki" <othman@epitrope.com> writes: > For the running out of memory part, there seem to be two aspects to it: > 1) I tried running the application on a separate machine to make sure that > it was not my code that was eating up all the memory but that did not help. > However, I suspect that my code may be "losing" some connections (i.e. > leaves them dangling somewhere in the ether :-). Do you know of a way to as > Postgres how many open connections it currently has and the client IP's that > opened those connections? I don't think PG has any direct way to find this out. What you can do is (1) count the number of "postgres" processes running (each client connection has a backend process) and (2) use "netstat" and "lsof" to find the IP addresses for the established socket connections. It would be possible to automate this procedure but somewhat tricky. ;) Bruce Momjian wrote a fairly simple PG monitor program that you night want to play with--I think it's in contrib/. > 2) Even though the DB gets faster after reboot, I have the impression (no > hard data to support this) that with usage, it gets slower in general. When > I had a clean machine, right after installation, it was lightening-fast. > However, even though the data that is loaded in the DB did not increase in > size all that much, after that it has been used for a while, the DB gets > progressively slower. This may be an effect of not VACUUMing often enough, if you are doing a lot of updates. Hard to say much without real numbers. If you are leaking memory/backends, the slowdown may result from your system starting to swap. You might consider running 'vmstat' and collecting the output, to see if swap i/o starts going up after a while. > With regards to the JDBC driver that I am using, I am using one that I had > built with v7.0. The reason for this is that I had applied a patch to > correct the mutli-byte support that was not working. Has this problem been > fixed in the new version of the JDBC driver? If so, I would gladly switch. I don't know; you'll have to look at the code or the Changelog to see. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan
> With regards to the JDBC driver that I am using, I am using one that I had > built with v7.0. The reason for this is that I had applied a patch to > correct the mutli-byte support that was not working. Has this problem been > fixed in the new version of the JDBC driver? If so, I would gladly switch. 7.1 JDBC driver seems much better than 7.0 with the regard of the multi-byte handling. It understands the database encoding and does automatic encoding convertion to/from Unicode. -- Tatsuo Ishii
hi,
try to use
vacuumdb dbname
to clean the database, you may set it as a cron job.
cheers
feng
Othman Laraki wrote:
> Hi,
> I recently upgraded to V7.1 version of Postgres on Linux and have noticed
> that as the DB is being used, it gets progressively slower and slower, until
> very simple queries slow down to a crawl. The basic setup I have is a set of
> JSPs and Servlets running on Tomcat, that use Java classes which connect to
> Postgres through a JDBC driver and perform various DB operations. But, as I
> said, the DB gets noticeably slower, as if it does not clean up behind
> itself after performing operations and finally runs out of memory... Then,
> the only thing that works is stopping the postmaster and rebooting the
> machine.
>
> If you have any ideas of what may cause this or what I can do to explore
> the issue, I would be very grateful. I am fairly new to Postgres, so any
> suggestions are welcome.
>
> Thanks,
> Othman
>
> _____________________________
> Othman Laraki
> Epitrope Corporation
> 860 Hillview Court, Suite 200
> Milpitas, CA 95035, USA
> 650-814-9580 (phone)
> 650-745-2449 (fax)
> othman@epitrope.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster