Re: 12 hour table vacuums - Mailing list pgsql-performance

From Bill Moran
Subject Re: 12 hour table vacuums
Date
Msg-id 20071023120750.ad8a1f54.wmoran@collaborativefusion.com
Whole thread Raw
In response to 12 hour table vacuums  (Ron St-Pierre <ron.pgsql@shaw.ca>)
Responses Re: 12 hour table vacuums
List pgsql-performance
In response to Ron St-Pierre <ron.pgsql@shaw.ca>:

> We vacuum only a few of our tables nightly, this one is the last one
> because it takes longer to run. I'll probably re-index it soon, but I
> would appreciate any advice on how to speed up the vacuum process (and
> the db in general).

I doubt anyone can provide meaningful advice without the output of
vacuum verbose.

>
> Okay, here's our system:
>    postgres 8.1.4
>    Linux version 2.4.21
>    Red Hat Linux 3.2.3
>    8 GB ram
>    Intel(R) Xeon(TM) CPU 3.20GHz
>    Raid 5
>    autovacuum=off
>    serves as the application server and database server
>    server is co-located in another city, hardware upgrade is not
> currently an option
>
> Here's the table information:
> The table has 140,000 rows, 130 columns (mostly NUMERIC), 60 indexes. It
> is probably our 'key' table in the database and gets called by almost
> every query (usually joined to others). The table gets updated only
> about 10 times a day. We were running autovacuum but it interfered with
> the updates to we shut it off. We vacuum this table nightly, and it
> currently takes about 12 hours to vacuum it. Not much else is running
> during this period, nothing that should affect the table.
>
> Here are the current non-default postgresql.conf settings:
> max_connections = 100
> shared_buffers = 50000
> work_mem = 9192
> maintenance_work_mem = 786432
> max_fsm_pages = 70000
> vacuum_cost_delay = 200
> vacuum_cost_limit = 100
> bgwriter_delay = 10000
> fsync = on
> checkpoint_segments = 64
> checkpoint_timeout = 1800
> effective_cache_size = 270000
> random_page_cost = 2
> log_destination = 'stderr'
> redirect_stderr = on
> client_min_messages = warning
> log_min_messages = warning
> stats_start_collector = off
> stats_command_string = on
> stats_block_level = on
> stats_row_level = on
> autovacuum = off
> autovacuum_vacuum_threshold = 2000
> deadlock_timeout = 10000
> max_locks_per_transaction = 640
> add_missing_from = on
>
> As I mentioned, any insights into changing the configuration to optimize
> performance are most welcome.
>
> Thanks
>
> Ron
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>
>
>
>
>


--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

pgsql-performance by date:

Previous
From: Ron St-Pierre
Date:
Subject: 12 hour table vacuums
Next
From: Tom Lane
Date:
Subject: Re: 12 hour table vacuums