Re: 12 hour table vacuums

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Ron St-Pierre <ron(dot)pgsql(at)shaw(dot)ca>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: 12 hour table vacuums
Date: 2007-10-23 16:07:50
Message-ID: 20071023120750.ad8a1f54.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

In response to Ron St-Pierre <ron(dot)pgsql(at)shaw(dot)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(at)collaborativefusion(dot)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.
****************************************************************

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-10-23 16:11:51 Re: 12 hour table vacuums
Previous Message Ron St-Pierre 2007-10-23 15:53:17 12 hour table vacuums