From: | Ericson Smith <eric(at)did-it(dot)com> |
---|---|
To: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Numerous postmaster processes after upgrading to 7.2.3 |
Date: | 2002-10-21 16:21:59 |
Message-ID: | 1035217319.32138.22.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ok, I found the problem.
Doing an analyze on the database solved it. Apparently the planner did
not have much to go on directly after the restore. Silly me.
- Ericson Smith
eric(at)did-it(dot)com
On Mon, 2002-10-21 at 12:11, Ericson Smith wrote:
> Hi all,
>
> Today we upgraded to ver 7.2.3 from 7.2.2.
> I also dumped and restored the data before doing so, just in case :-)
>
> I've noticed a few things...
>
> 1. The database server load is much higher ~ 2.00 instead of ~ 0.30
> 2. Many more postmasters are running ~ 20 instead of ~ 5
>
> Some changes I made were:
>
> 1. Moved the log directories pg_xlog and pg_clog over to their own
> drives (made symbolic links from there)
>
> 2. Changed the amount of shared memory from 350MB to 320MB
>
> What would account for the new load? Queries seem to be taking much
> longer. We have logs of RAM on the server 6GB and are running SCSI Raid
> on the system. This is also a Dual Xeon system (2.4GHz).
>
> Some more background...
> 1. The database locked up last night (each postgres process was in
> Uninterruptible Sleep)
> 2. We had to cycle the power on the server to get it going again.
>
> Any help/insights would be greatly appreciated.
>
> - Ericson Smith
> eric(at)did-it(dot)com
> http://www.did-it.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2002-10-21 16:27:20 | Re: [GENERAL] Security implications of (plpgsql) functions |
Previous Message | Joe Conway | 2002-10-21 16:20:36 | Re: [GENERAL] Security implications of (plpgsql) functions |