Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 875619CF00F for ; Sun, 22 Jan 2012 19:17:31 -0400 (AST) Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rp6fD-0002UA-8x for pgsql-performance@postgresql.org; Sun, 22 Jan 2012 23:17:31 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 068EE4A20BE for ; Mon, 23 Jan 2012 00:17:19 +0100 (CET) Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id DOa3v+a4NOaV for ; Mon, 23 Jan 2012 00:17:18 +0100 (CET) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id D7EB24A209B for ; Mon, 23 Jan 2012 00:17:18 +0100 (CET) Message-ID: <4F1C98FE.1030307@fuzzy.cz> Date: Mon, 23 Jan 2012 00:17:18 +0100 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: spikes in pgbench read-only results Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: 0.3 (/) X-Archive-Number: 201201/53 X-Sequence-Number: 46066 Hi, I'm working on a benchmark that demonstrates the effects of moving tables or indexes to separate devices (SSD and HDD), and one thing that really caught my eye are spikes in the tps charts. See this: http://www.fuzzy.cz/tmp/data-indexes/indexes.html The first one is a database with data on an SSD and indexes on 7.2k HDD. Around 2:00, the performance significantly grows (over 4k tps) and then falls to about 500 tps (which is maintained for the remainder of the benchmark). I've seen similar spikes on HDD (both data and indexes on the same device) - that's the second chart. The difference is not that huge, but the spike at around 6:00 is noticeable. Interestingly, by separating the data and indexes to two 7.2k drives, the spike disappears - that's the third chart. Any ideas why this happens? Is this a pgbench-only anomaly that does not happen in real-world scenarios? My theory is that it's related to the strategy that chooses what to keep in shared_buffers (or page cache), and that somehow does not work too well in this case. regards Tomas