Re: Vacuum problem - Mailing list pgsql-general
| From | S H |
|---|---|
| Subject | Re: Vacuum problem |
| Date | |
| Msg-id | BAY155-W305588BEB23EECAAE5F045FDA00@phx.gbl Whole thread Raw |
| In response to | Re: Vacuum problem (Scott Marlowe <scott.marlowe@gmail.com>) |
| Responses |
Re: Vacuum problem
(Scott Marlowe <scott.marlowe@gmail.com>)
|
| List | pgsql-general |
> vacuum or vacuum full?
vacuum analyze.
> What is the db server doing when this happens? What does top, vmstat,
> iostat etc have to say about it?
> 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..
Stack trace of client is as follows:-
sendto(3, "p\0\0\0(md5de8bdf202e563b11a4384ba5"..., 41, 0, NULL, 0) = 41 <0.000012>
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000005>
poll([{fd=3, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <35.027745>
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.
>
> 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.
> Date: Mon, 13 May 2013 08:25:30 -0600
> Subject: Re: [GENERAL] Vacuum problem
> From: scott.marlowe@gmail.com
> To: msq001@live.com
> CC: pgsql-general@postgresql.org
>
> On Mon, May 13, 2013 at 8:05 AM, S H <msq001@live.com> wrote:
> > Hi,
> >
> > I have my database in which i am executing vacuuming running manually in one
> > hour.
>
> vacuum or vacuum full?
>
> > In my production database sometime when vacuuming is running it is taking
> > long time in opening connection.
>
> What is the db server doing when this happens? What does top, vmstat,
> iostat etc have to say about it?
>
> > My current version is version 8.1. Is there any known issue about open
> > connection problem with vacuuming.
>
> 8.1 is out of support and has been for some time.
>
> > I found something but i am not sure if it is applicable to V8.1 too?
>
> Tom wrote:
> > broken if we start the scan at a random place within the catalog, so
> > that
> > allowing syncscan is actually a big deoptimization if pg_attribute is
> > large
> SNIP
> > Back-patch to 8.3, where syncscan was introduced.
>
> It was added in 8.3 so no, it is likely not your issue.
>
> 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.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
> Subject: Re: [GENERAL] Vacuum problem
> From: scott.marlowe@gmail.com
> To: msq001@live.com
> CC: pgsql-general@postgresql.org
>
> On Mon, May 13, 2013 at 8:05 AM, S H <msq001@live.com> wrote:
> > Hi,
> >
> > I have my database in which i am executing vacuuming running manually in one
> > hour.
>
> vacuum or vacuum full?
>
> > In my production database sometime when vacuuming is running it is taking
> > long time in opening connection.
>
> What is the db server doing when this happens? What does top, vmstat,
> iostat etc have to say about it?
>
> > My current version is version 8.1. Is there any known issue about open
> > connection problem with vacuuming.
>
> 8.1 is out of support and has been for some time.
>
> > I found something but i am not sure if it is applicable to V8.1 too?
>
> Tom wrote:
> > broken if we start the scan at a random place within the catalog, so
> > that
> > allowing syncscan is actually a big deoptimization if pg_attribute is
> > large
> SNIP
> > Back-patch to 8.3, where syncscan was introduced.
>
> It was added in 8.3 so no, it is likely not your issue.
>
> 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.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
pgsql-general by date: