Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TGHld-0005kW-5l for pgsql-performance@postgresql.org; Mon, 24 Sep 2012 23:08:45 +0000 Received: from [2404:130:0:10::40:2] (helo=mail.catalyst.net.nz) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TGHla-0008Vl-7K for pgsql-performance@postgresql.org; Mon, 24 Sep 2012 23:08:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.catalyst.net.nz (Postfix) with ESMTP id 3AA1A32B53 for ; Tue, 25 Sep 2012 11:08:35 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz Received: from mail.catalyst.net.nz ([127.0.0.1]) by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9HqLrbIF1Ku for ; Tue, 25 Sep 2012 11:08:34 +1200 (NZST) Received: from [IPv6:2404:130:0:1000:8ccc:1e00:e014:4b81] (unknown [IPv6:2404:130:0:1000:8ccc:1e00:e014:4b81]) (Authenticated sender: mark.kirkwood) by mail.catalyst.net.nz (Postfix) with ESMTPSA id 880AA32425 for ; Tue, 25 Sep 2012 11:08:34 +1200 (NZST) Message-ID: <5060E7F2.3010903@catalyst.net.nz> Date: Tue, 25 Sep 2012 11:08:34 +1200 From: Mark Kirkwood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Postgres becoming slow, only full vacuum fixes it References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2404:130:0:10::40:2 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201209/114 X-Sequence-Number: 47860 On 24/09/12 22:33, Kiriakos Tsourapas wrote: > Hi, > > The problem : Postgres is becoming slow, day after day, and only a full vacuum fixes the problem. > > > > My postgresql.conf file : > ====================== > port = 5433 # (change requires restart) > max_connections = 100 # (change requires restart) > shared_buffers = 256MB # min 128kB. DoubleIP - Default was 32MB > synchronous_commit = off # immediate fsync at commit. DoubleIP - Default was on > effective_cache_size = 512MB # DoubleIP - Default was 128MB > log_destination = 'stderr' # Valid values are combinations of > logging_collector = on # Enable capturing of stderr and csvlog > silent_mode = on # Run server silently. > log_line_prefix = '%t %d %u ' # special values: > log_autovacuum_min_duration = 0 # -1 disables, 0 logs all actions and > autovacuum_naptime = 28800 # time between autovacuum runs. DoubleIP - default was 1min > autovacuum_vacuum_threshold = 100 # min number of row updates before > autovacuum_vacuum_scale_factor = 0.0 # fraction of table size before vacuum. DoubleIP - default was 0.2 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' # locale for system error message > lc_monetary = 'en_US.UTF-8' # locale for monetary formatting > lc_numeric = 'en_US.UTF-8' # locale for number formatting > lc_time = 'en_US.UTF-8' # locale for time formatting > default_text_search_config = 'pg_catalog.english' > Given that vacuum full fixes the issue I suspect you need to have autovacuum set wake up much sooner, not later. So autovacuum_naptime = 28800 or even = 60 (i.e the default) is possibly too long. We have several database here where I change this setting to 10 i.e: autovacuum_naptime = 10s in order to avoid massive database bloat and queries that get slower and slower... You might want to be a bit *less* aggressive with autovacuum_vacuum_scale_factor - I usually have this at 0.1, i.e: autovacuum_vacuum_scale_factor = 0.1 otherwise you will be vacuuming all the time - which is usually not what you want (not for all your tables anyway). regards Mark