Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vogz6-0002Vi-KB for pgsql-performance@arkaria.postgresql.org; Thu, 05 Dec 2013 22:01:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Vogz6-0005Ox-3V for pgsql-performance@arkaria.postgresql.org; Thu, 05 Dec 2013 22:01:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vogz4-0005OV-VU for pgsql-performance@postgresql.org; Thu, 05 Dec 2013 22:01:23 +0000 Received: from [2404:130:0:10::40:2] (helo=mail.catalyst.net.nz) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Vogyw-0000dQ-4X for pgsql-performance@postgresql.org; Thu, 05 Dec 2013 22:01:19 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.catalyst.net.nz (Postfix) with ESMTP id 2B8B73257D; Fri, 6 Dec 2013 11:01:08 +1300 (NZDT) 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 YL+E1HnRuLAI; Fri, 6 Dec 2013 11:01:04 +1300 (NZDT) Received: from [IPv6:2404:130:0:1000:222:4dff:fe88:a586] (unknown [IPv6:2404:130:0:1000:222:4dff:fe88:a586]) (Authenticated sender: mark.kirkwood) by mail.catalyst.net.nz (Postfix) with ESMTPSA id 2757E67A84; Fri, 6 Dec 2013 11:01:01 +1300 (NZDT) Message-ID: <52A0F79C.3060200@catalyst.net.nz> Date: Fri, 06 Dec 2013 11:01:00 +1300 From: Mark Kirkwood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Skarsol , Scott Marlowe CC: desmodemone , "pgsql-performance@postgresql.org" Subject: Re: WAL + SSD = slow inserts? 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 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 06/12/13 05:13, Skarsol wrote: > On Thu, Dec 5, 2013 at 9:50 AM, Scott Marlowe wrote: > >> On Thu, Dec 5, 2013 at 8:16 AM, Skarsol wrote: >>> psql (PostgreSQL) 9.2.5 >>> Red Hat Enterprise Linux Server release 6.4 (Santiago) >>> Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Fri Mar 29 16:51:51 EDT 2013 >> x86_64 >>> x86_64 x86_64 GNU/Linux >>> All relevant filesystems are ext4 >>> >>> Changes from defaults: >>> max_connections = 500 >>> shared_buffers = 32000MB >>> temp_buffers = 24MB >>> work_mem = 1GB >>> maintenance_work_mem = 5GB >>> wal_level = archive >>> wal_buffers = 16MB >>> checkpoint_completion_target = 0.9 >>> archive_mode = on >>> archive_command = 'test ! -f /databases/pg_archive/db/%f && cp %p >>> /databases/pg_archive/db/%f' >>> effective_cache_size = 64000MB >>> default_statistics_target = 5000 >>> log_checkpoints = on >>> stats_temp_directory = '/tmp/pgstat' >> OK I'd make the following changes. >> 1: Drop shared_buffers to something like 1000MB >> 2: drop work_mem to 16MB or so. 1GB is pathological, as it can make >> the machine run out of memory quite fast. >> 3: drop max_connections to 100 or so. if you really need 500 conns, >> then work_mem of 1G is that much worse. >> >> Next, move pg_xlog OFF the SSDs and back onto spinning media and put >> your data/base dir on the SSDs. >> >> SSDs aren't much faster, if at all, for pg_xlog, but are much much >> faster for data/base files. >> >> Also changing the io schduler for the SSDs to noop: >> >> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/switching-sched.txt?id=HEAD >> > Changing the scheduler to noop seems to have had a decent effect. I've made > the other recommended changes other than the connections as we do need that > many currently. We're looking to implement pg_bouncer which should help > with that. > What model SSD are you using? Some can work better with deadline than noop (as their own scheduling firmware may be pretty poor). Also, check if there are updates for the SSD firmware. I have a couple of Crucial M4s that changed from being fairly average to very fast indeed after getting later firmware... Cheers Mark -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance