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.
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@xxxxxxxxx> wrote:
On Sat, Jan 10, 2015 at 8:54 PM, Melvin Davidson <melvin6925@xxxxxxxxx> 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.![]()
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
