On Mon, May 13, 2013 at 8:37 AM, S H <msq001@xxxxxxxx> wrote: >> What is the db server doing when this happens? What does top, vmstat, >> iostat etc have to say about it? > > It is high end server with 96 GB of RAM , 16 core server, but there are many > other application running, This db is used for monitoring the performance of > this server and inserting/updating data every one in 10-20 tables. > > I am able to reproduce this issue, in case i run vacuuming of my database > and in parallel try to open 30 connections, sometime db client takes time to > open connection .... Is there any workaround or there is some known issue > already existing. If there is any known issue it will be easy to persuade my > customers to upgrade.. I wonder if you've got a bloated pg catalog then. Certainly sounds like it's a possibility. So other than vacuuming when you recreate this, is the server working hard? What is vacuum vacuuming when this happens (pg_stat_activity should show that). >> Running 8.1 means you're asking about a system no one else on this >> list is likely to still be using much. The hackers aren't gonna be >> interested in fixing it either, since it's out of support. > > I am migrating to new version, for new customers , but for old existing > customer, it would require significant time. Is there any workaround for the > same. Like improving some DB parameters. Probably not. If the tables that make up the pg catalogs are bloated, you might have to go take some outage time to run a vacuum full / reindex on them. Some of them, I believe, require single user mode to do this, but not sure, and definitely not sure if it's na 8.1 thing or not. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
