Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
Date
Msg-id CAHyXU0w+tHLrmP0WvedWberukQ+ReYPAWwo3j-dJOyNrAGVSLQ@mail.gmail.com
Whole thread Raw
In response to Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average  (FattahRozzaq <ssoorruu@gmail.com>)
List pgsql-performance
On Wed, Oct 7, 2015 at 5:29 AM, FattahRozzaq <ssoorruu@gmail.com> wrote:
> Response from you all are very precious.
>
> @Merlin,
> I'm misunderstood the question.
> Yes, I didn't measure it. I only monitor RAM and CPU using htop (I also use

Can you be a little more specific.  What values did you look at and
how did you sum them up?  Assuming your measurement was correct, you
might be looking at simple prewarm issue in terms of getting shared
buffers stuffed up.  There are some tactics to warm up shared buffers
(like pg_prewarm), but it's not clear that would be useful in your
case.

One cause (especially with older kernels) of low memory utilization is
misconfigured NUMA.  Note this would only affect the backing o/s
cache, not pg's shared buffers.

Very first thing you need to figure out is if your measured issues are
coming from storage or not.  iowait % above single digits suggests
this. With fast SSD it's pretty difficult to max out storage,
especially when reading data, but it's always the first thing to look
at.   Context switch issues (as Scott notes) as another major
potential cause of performance variability, as is server internal
contention.   But rule out storage first.

merlin


pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: shared-buffers set to 24GB but the RAM only use 4-5 GB average
Next
From: "Carlo"
Date:
Subject: Re: One long transaction or multiple short transactions?