Re: shared_buffers/effective_cache_size on 96GB server

On 10/10/2012 09:35 AM, Strahinja Kustudić wrote:

> #sysctl vm.dirty_ratio
> vm.dirty_ratio = 40
> # sysctl vm.dirty_background_ratio
> vm.dirty_background_ratio = 10

Ouuuuch. That looks a lot like an old RHEL or CentOS system. Change
those ASAP. Currently your system won't start writing dirty buffers
until it hits 9.6GB. :(

> shows that these values are even higher by default. When you said
> RAID buffer size, you meant the controllers cache memory size?

Yeah, that. :)

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

From pgsql-performance-owner(at)postgresql(dot)org Wed Oct 10 14:46:24 2012
Received: from makus.postgresql.org ([98.129.198.125])
by malur.postgresql.org with esmtp (Exim 4.72)
(envelope-from <klaussfreire(at)gmail(dot)com>)
id 1TLxWm-0006xB-IO
for pgsql-performance(at)postgresql(dot)org; Wed, 10 Oct 2012 14:44:52 +0000
Received: from mail-bk0-f46.google.com ([209.85.214.46])
by makus.postgresql.org with esmtp (Exim 4.72)
(envelope-from <klaussfreire(at)gmail(dot)com>)
id 1TLxWl-0007A4-Ae
for pgsql-performance(at)postgresql(dot)org; Wed, 10 Oct 2012 14:44:51 +0000
Received: by mail-bk0-f46.google.com with SMTP id jk13so366104bkc.19
for <pgsql-performance(at)postgresql(dot)org>; Wed, 10 Oct 2012 07:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s 120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=NoXZoiRbuvJfhh3PAckEqx7tmQzO/VH5SU8AkqeYbrc=;
b=NURUoE+NE7EV70kaY37p5RZv6ZJsfjdBxr6br8PZqaIhBAxDoEnUyldOUqCnoqu4gi
Xt0dW+hoFmtX9FFUFzVq2HSgG0Esz1EioDaYbKEERKqtzyGDqWDdUFHJiXuLfwSq4TEh
LQEJAHdBtK1+em0fjz2eM1JECElz3e5cSQFDNasFKFrmnSf0FKKUFfjipjUpQdHsLgvq
0Z//56sSRm1XLhfrbnsg3c1iNTfPTawT02HnB6oWaULJrXdtGXaBsmHRYi45CHnySqv5
47MeDH3k8hnZo7K4/rt0heDwYfk7gY2uJQKrczvZ9U0qL57cG+ZmECjG3E7mEmxkUtpp
vhog=
MIME-Version: 1.0
Received: by 10.204.9.4 with SMTP id j4mr5510578bkj.22.1349880290186; Wed, 10
Oct 2012 07:44:50 -0700 (PDT)
Received: by 10.204.156.196 with HTTP; Wed, 10 Oct 2012 07:44:50 -0700 (PDT)
In-Reply-To: <50756F95(dot)7040006(at)optionshouse(dot)com>
References: <CAFwQ8revW5Ez6uCUqPeUFVHh0pdy0OZKv8_nM0SvxHgTM055EQ(at)mail(dot)gmail(dot)com>
<CAFwQ8re9O2Nvao3UsUxDxFZZUsoSqNJSC4jaKGB9cJ7_YyjoBA(at)mail(dot)gmail(dot)com>
<50756F95(dot)7040006(at)optionshouse(dot)com>
Date: Wed, 10 Oct 2012 11:44:50 -0300
Message-ID: <CAGTBQpY8Fb5Un7w2LjP0i1qfvP3Qiqu=weyGkXmehExfXAbL7g(at)mail(dot)gmail(dot)com>
Subject: Re: Hyperthreading (was: Two identical systems, radically
different performance)
From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: sthomas(at)optionshouse(dot)com
Cc: Craig James <cjames(at)emolecules(dot)com>, pgsql-performance(at)postgresql(dot)org
Content-Type: text/plain; charset=ISO-8859-1
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201210/113
X-Sequence-Number: 48072

On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas(at)optionshouse(dot)com> wrote:
> On 10/09/2012 06:30 PM, Craig James wrote:
>
>> ra:8192 walb:1M ra:256 walb:1M ra:256 walb:256kB
>> ---------------- ---------------- -----------------
>> -c -t Run1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9
>> 40 2500 4261 3722 4243 9286 9240 5712 9310 8530 8872
>> 50 2000 4138 4399 3865 9213 9351 9578 8011 7651 8362
>
>
> I think I speak for more than a few people here when I say: wat.
>
> About the only thing I can ask, is: did you make these tests fair? And by
> fair, I mean:
>
> echo 3 > /proc/sys/vm/drop_caches
> pg_ctl -D /your/pg/dir restart

Yes, I was thinking the same. Especially if you check the tendency to
perform better in higher-numbered runs. But, as you said, that doesn't
explain that jump to twice the TPS. I was thinking, and I'm not
pgbench expert, could it be that the database grows from run to run,
changing performance characteristics?

> My head hurts.

I'm just confused. No headache yet.

But really interesting numbers in any case. It these results are on
the level, then maybe the kernel's read-ahead algorithm isn't as
fool-proof as we thought? Gotta read the source. BRB