Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 95FE69F9B96 for ; Tue, 16 Oct 2007 05:49:04 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 81117-08 for ; Tue, 16 Oct 2007 05:48:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from dalibo-free-72.custom.lost-oasis.net (unknown [212.85.154.72]) by postgresql.org (Postfix) with ESMTP id 0E8B69F9B76 for ; Tue, 16 Oct 2007 05:48:57 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by dalibo-free-72.custom.lost-oasis.net (Postfix) with ESMTP id B758A578074 for ; Tue, 16 Oct 2007 10:48:30 +0200 (CEST) Received: from dalibo-free-72.custom.lost-oasis.net ([127.0.0.1]) by localhost (pyrrha.dalibo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV-jzPaSVX+l for ; Tue, 16 Oct 2007 10:48:30 +0200 (CEST) Received: by dalibo-free-72.custom.lost-oasis.net (Postfix, from userid 1011) id 955CE57807B; Tue, 16 Oct 2007 10:48:30 +0200 (CEST) Received: from [192.168.1.100] (unknown [81.56.152.169]) by dalibo-free-72.custom.lost-oasis.net (Postfix) with ESMTP id B6F6C578074 for ; Tue, 16 Oct 2007 10:48:28 +0200 (CEST) Message-ID: <47147AD8.9010704@postgresqlfr.org> Date: Tue, 16 Oct 2007 10:48:24 +0200 From: =?ISO-8859-1?Q?St=E9phane_Schildknecht?= User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: Vacuum goes worse Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/166 X-Sequence-Number: 27188 Hi, For some times, we have a vacuuming process on a specific table that goes slower and slower. In fact, it took some 3 minutes a month ago, and now it take almost 20 minutes. But, if one day it take so many time, it is possible that on the day after it will only take 4 minutes... I know the table in concern had 450000 tuples two months ago and now has more than 700000 tuples in it. I wonder vacuum verbose would tell me if fsm parameters were not too badly configured, but I can't get the 4 last lines of the output... Is there another way to get these info ? Or is it a parameter badly configured ? For information, it's on AIX, PG8.1.9. Some configuration parameters : client_min_messages : notice log_error_verbosity : default log_min_error_statement : panic log_min_messages : notice. Whats's more, I wonder what we could monitor to get some explanation of the recent time increase, and then have a quite-sure way of configuring the server. I have to say the database is hosted, accessed in production on a 24/7 basis and then every change in configuration has to be scheduled. Some more information you may ask: chackpoint_segments : 32 checkpoint_timeout : 180 checkpoint_warning : 30 wal_buffers : 64 maintenance_work_mem : 65536 max_fsm_pages : 400000 max_fsm_relations : 1000 shared_buffers : 50000 temp_bufers : 1000 We also have 4Gb RAM. Isn't checkpoint_segments too low as all files in pg_xlogs seem to be recycled within a few minutes. (In fact among the 60 files, at least 30 have been modified during the few minutes of that particular vacuum). Thanks for any advice you could give me. Best regards, -- Stéphane SCHILDKNECHT Président de PostgreSQLFr http://www.postgresqlfr.org