Обсуждение: BUG #1186: Broken Index?
The following bug has been logged online: Bug reference: 1186 Logged by: Gosen, Hitoshi Email address: mic-gosen@ns.inter-mic.co.jp PostgreSQL version: 7.4 Operating system: linux 2.4.18 Description: Broken Index? Details: Hello All, We are using PostgreSQL 7.4.2 for our website that handles over 200,000 transactions a day. About a month ago, the responses from the SELECT queries on the database became terribly slow. We tried to anaylze the cause of the problem, searching throught the system logs and all, but nothing appeared to be out of the ordinary. What we did to resolve this was to dump the database, delete the database, recreate the database, and finally restore it. After that, things were back to normal. From the above experience, we were able to hypothesize that the fault of the slow responses was not from a broken data or hardware failures, but from a broken index, since we were able to recover 100% of the data on the same machine. Today, the same problem occured, and the same actions are going to be taken to temporary resolve it. Final note: we will also experiment with the 'vacuum full' command to see if it counters this problem.
On Fri, Jul 02, 2004 at 04:50:07 -0300, PostgreSQL Bugs List <pgsql-bugs@postgresql.org> wrote: > > The following bug has been logged online: This doesn't appear to be a bug at this point. It sounds like you have a self induced performance problem, so I am moving the discussion to pgsql-performance. > > Bug reference: 1186 > Logged by: Gosen, Hitoshi > > Email address: mic-gosen@ns.inter-mic.co.jp > > PostgreSQL version: 7.4 > > Operating system: linux 2.4.18 > > Description: Broken Index? > > Details: > > Hello All, > We are using PostgreSQL 7.4.2 for our website that handles over 200,000 > transactions a day. > About a month ago, the responses from the SELECT queries on the database > became terribly slow. > We tried to anaylze the cause of the problem, searching throught the system > logs and all, but nothing appeared to be out of the ordinary. > > What we did to resolve this was to dump the database, delete the database, > recreate the database, and finally restore it. After that, things were back > to normal. > > From the above experience, we were able to hypothesize that the fault of the > slow responses was not from a broken data or hardware failures, but from a > broken index, since we were able to recover 100% of the data on the same > machine. > > Today, the same problem occured, and the same actions are going to be taken > to temporary resolve it. > > Final note: we will also experiment with the 'vacuum full' command to see > if it counters this problem. It sounds like you aren't properly vacuuming your database. It is possible that you need a higher FSM setting or to vacuum more frequently.
PostgreSQL Bugs List wrote: > Hello All, > We are using PostgreSQL 7.4.2 for our website that handles over 200,000 > transactions a day. > About a month ago, the responses from the SELECT queries on the database > became terribly slow. > We tried to anaylze the cause of the problem, searching throught the system > logs and all, but nothing appeared to be out of the ordinary. > > What we did to resolve this was to dump the database, delete the database, > recreate the database, and finally restore it. After that, things were back > to normal. > > From the above experience, we were able to hypothesize that the fault of the > slow responses was not from a broken data or hardware failures, but from a > broken index, since we were able to recover 100% of the data on the same > machine. > > Today, the same problem occured, and the same actions are going to be taken > to temporary resolve it. > > Final note: we will also experiment with the 'vacuum full' command to see > if it counters this problem. This is not for sure a bug, but a known behaviour if you don't vacuum at all your db. I bet you don't use the vacuum daemon; use it or schedule a simple vacuum on the eavily updated table each 10 minutes. I strongly suggest you to use the autovacuum daemon. Do not esitate to ask how use it. Regards Gaetano Mendola