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: