Received: from maia.hub.org (unknown [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id E39B91337B7A for ; Fri, 22 Oct 2010 12:11:04 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 59709-02 for ; Fri, 22 Oct 2010 15:10:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from aoskar.kilobug.org (kilobug.org [62.212.118.231]) by mail.postgresql.org (Postfix) with ESMTP id DBF7B133740B for ; Fri, 22 Oct 2010 12:10:56 -0300 (ADT) Received: from kilobug by aoskar.kilobug.org with local (Exim 4.72) (envelope-from ) id 1P9JGe-0006JS-S5 for pgsql-performance@postgresql.org; Fri, 22 Oct 2010 17:10:52 +0200 From: Gael Le Mignot To: pgsql-performance@postgresql.org Subject: Re: Periodically slow inserts Organization: Pilot Systems References: Mail-Copies-To: nobody X-Revolutionnary-Date: 1 Brumaire an 219 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Fingerprint: 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA Date: Fri, 22 Oct 2010 17:10:52 +0200 In-Reply-To: (Gael Le Mignot's message of "Thu, 21 Oct 2010 14:25:44 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/379 X-Sequence-Number: 40797 Hello, Thanks to everyone who gave me hints and feedbacks. I managed to solve the problem. My understanding of what was happening is the following : - The gin index (as explained on [1]), stores temporary list, and when they grow big enough, those are dispatched into the real index. Vacuum also does this index flush, in background. - This index flush, on a table with 500k rows, means making changes to a lot of disk pages, filling the WAL in one big burst, forcing an immediate checkpoint, and blocking the INSERT that triggered it. I managed to solve the problem by adjusting two set of parameters : - The work_mem variable, which sepcify the maximal size of the temporary list before the gin index is "flushed". - The autovacuum parameters. The main idea was to increase the size of temporary lists (through work_mem) and increase the frequency of autovacuums, to ensure that under real life load (even heavy real life load), the "index flush" is always done by the autovacuum, and never by the "list is full" trigger. With this setup, I managed to handle indexing 10 000 objects in 2 hours without any stall, which is much more than we'll have to handle under real life load. Regards, [1] http://www.postgresql.org/docs/8.4/static/gin-implementation.html -- Gaël Le Mignot - gael@pilotsystems.net Pilot Systems - 9, rue Desargues - 75011 Paris Tel : +33 1 44 53 05 55 - www.pilotsystems.net Gérez vos contacts et vos newsletters : www.cockpit-mailing.com