Re: How to analyze a slowdown in 9.3.5?

From: Melvin Davidson <melvin6925(at)gmail(dot)com>
To: Michael Nolan <htfoot(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to analyze a slowdown in 9.3.5?
Date: 2015-01-11 17:01:23
Message-ID: CANu8FiwzpJL5PYrNRzngWFsxzRbqRSZ6bGDT2Ev_MuA4akio2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

OK, you might also want to look at the current values of shared_buffers,
temp_buffers & work_mem in postgresql.conf.

If they seem correct/appropritate for your total shmmax memory
(kernel.shmmax parameter), then if the slowdown occurs again, monitor top
and see if it's really PostgreSQL that is slowing down, or perhaps some
other process grabbing CPU time.

On Sun, Jan 11, 2015 at 11:07 AM, Michael Nolan <htfoot(at)gmail(dot)com> wrote:

>
>
> On Sat, Jan 10, 2015 at 8:54 PM, Melvin Davidson <melvin6925(at)gmail(dot)com>
> wrote:
>
>> Just curious. Have you checked that the tables are being vacuum/analyzed
>> periodically and that the statistics are up to date? Try running the
>> following query to verify:
>>
>>
> A vacuum analyze runs every night and there would not have been many
> inserts or updates to the tables used by the lookup function since the
> latest vacuum analyze. I think I may have even done a vacuum analyze on
> the two largest tables after the first DB shutdown.
> --
> Mike Nolan
>

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G Johnston 2015-01-11 17:40:12 Re: Hash Function
Previous Message Michael Nolan 2015-01-11 16:07:38 Re: How to analyze a slowdown in 9.3.5?