Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers/effective_cache_size on 96GB server

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Strahinja Kustudić <strahinjak(at)nordeus(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Date: 2012-10-10 14:38:15
Message-ID: 50758857.6030008@optionshouse.com (view raw or flat)
Thread:
Lists: pgsql-performance
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


In response to

Responses

pgsql-performance by date

Next:From: Strahinja KustudićDate: 2012-10-10 14:49:47
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Previous:From: Shaun ThomasDate: 2012-10-10 13:09:56
Subject: Re: shared_buffers/effective_cache_size on 96GB server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group