From: | "Nick Fankhauser" <nickf(at)ontko(dot)com> |
---|---|
To: | "pgsql-admin" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Database is slow, vacuum hangs |
Date: | 2002-03-01 20:44:39 |
Message-ID: | NEBBLAAHGLEEPCGOBHDGCEIIEHAA.nickf@ontko.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi-
This morning, my database suddenly got very slow. I had been testing an
import process, so I had loaded, deleted, and reloaded about 140MB of data
several times. After the last reload, I noticed that the database was very
slow. Queries that normally executed in seconds didn't return after several
minutes. I don't know if they ever would have returned results, as I
cancelled after about 5 minutes, so the database might have been completely
locked.
I decided to delete all of the data, do a vacuum, and then reload one more
time.
The deletes were slow, but worked, so the tables are all empty now. I
started the vacuum and let it run for 4 hours while I did other work & it
never came back. During this time, I noticed that two postmaster processes
were constantly running- each taking up almost exactly half of the CPU time.
There was no disk activity. After I canceled the vacuum, the two postmaster
processes remained and continued to use all of the CPU time. (they're still
there.)
postgres.log doesn't contain any new messages.
I guess the obvious next step is to restart postgres, but I don't want to
blow away any evidence.
Can anyone suggest tests I should do to learn what happened before trying a
restart?
I'm running PGSQL 7.1.3 on Debian Linux 2.4.14
Thanks-
-Nick
--------------------------------------------------------------------------
Nick Fankhauser nickf(at)ontko(dot)com Phone 1.765.935.4283 Fax 1.765.962.9788
Ray Ontko & Co. Software Consulting Services http://www.ontko.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-01 21:16:00 | Re: Database is slow, vacuum hangs |
Previous Message | Tom Lane | 2002-03-01 20:09:24 | Re: Pg_dump very large database |