From: Shaun Thomas <sthomas@optionshouse.com>
To: Strahinja Kustudić <strahinjak@nordeus.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Date: Wed, 10 Oct 2012 08:09:56 -0500
Message-ID: <507573A4.1090605@optionshouse.com> (raw)
In-Reply-To: <CADKbJJUTr9ZWkbajR-7_6qaAsWH0=09=2AMo67C_Az-raKZE4w@mail.gmail.com>
References: <CADKbJJUTr9ZWkbajR-7_6qaAsWH0=09=2AMo67C_Az-raKZE4w@mail.gmail.com>
On 10/10/2012 02:12 AM, Strahinja Kustudić wrote:
> total used free shared buffers cached
> Mem: 96730 96418 311 0 71 93120
Wow, look at all that RAM. Something nobody has mentioned yet, you'll
want to set some additional kernel parameters for this, to avoid getting
occasional IO storms caused by dirty memory flushes.
vm.dirty_background_ratio = 1
vm.dirty_ratio = 5
Again, these would go in sysctl.conf, or /etc/sysctl.d/10-dbserver.conf
or something. If you have a newer kernel, look into
vm.dirty_background_bytes, and vm.dirty_bytes.
The why of this is brought up occasionally here, but it comes down to
your vast amount of memory. The defaults for even late Linux kernels is
5% for dirty_background_ratio, and 10% for dirty_ratio. So if you
multiply it out, the kernel will allow about 4.8GB of dirty memory
before attempting to flush it to disk. If that number reaches 9.6, the
system goes synchronous, and no other disk writes can take place until
*all 9.6GB* is flushed. Even with a fast disk subsystem, that's a pretty
big gulp.
The idea here is to keep it writing in the background by setting a low
limit, so it never reaches a critical mass that causes it to snowball
into the more dangerous upper limit. If you have a newer kernel, the
ability to set "bytes" is a much more granular knob that can be used to
match RAID buffer sizes. You'll probably want to experiment with this a
bit before committing to a setting.
> So it did a little swapping, but only minor, still I should probably
> decrease shared_buffers so there is no swapping at all.
Don't worry about that amount of swapping. As others have said here, you
can reduce that to 0, and even then, the OS will still swap something
occasionally. It's really just a hint to the kernel how much swapping
you want to go on, and it's free to ignore it in cases where it knows
some data won't be accessed after initialization or something, so it
swaps it out anyway.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sthomas@optionshouse.com, strahinjak@nordeus.com
Subject: Re: shared_buffers/effective_cache_size on 96GB server
In-Reply-To: <507573A4.1090605@optionshouse.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox