From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Dearman <tom(dot)dearman(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Waiting on ExclusiveLock on extension 9.3, 9.4 and 9.5 |
Date: | 2015-11-02 21:17:04 |
Message-ID: | CAMkU=1zVE8O-dDrWK4hagDJp80a=iDpM2rAmYdfbzccpe5418g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Nov 2, 2015 at 7:32 AM, Tom Dearman <tom(dot)dearman(at)gmail(dot)com> wrote:
> Thanks for the prompt replies so far, I have done some more investigation to
> be able to clearly answer some of the question.
>
> The original shared-buffers was 8G and I have done another run on Friday
> using this old value instead of my more recent 1G limit. There was no
> noticeable improvement. I also installed the extension pg_buffercache and
> following some articles such as:
>
> http://www.keithf4.com/a-large-database-does-not-mean-large-shared_buffers/
>
> using:
>
> SELECT pg_size_pretty(count(*) * 8192) as ideal_shared_buffers
> FROM pg_class c
> INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode
> INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname =
> current_database())
> WHERE usagecount >= 3;
>
>
> My system under load is using just over 500M of the shared_buffer at usage
> count >= 3. Our system is very write heavy, with all of the big tables
> written to but not read from (at least during the load test run). Although
> our db will grow (under load) to 100G in a few hours and keep growing, the
> data in shared_buffers - according to my observations above - seems low. We
> have the WAL on a different disk from the main tables.
What fraction of that is dirty?
Is your data loading done by INSERT statements in a loop? Or by COPY?
INSERT in a loop will insert rows into a chosen buffer one by one,
increasing the usage_count each time. As soon as the buffer is full,
it becomes completely cold in reality, but it is still very hot
according to the usage count.
> We have the
> following representative TPS for the disks (from SAR) when under our load
> test:
>
> 06:34:01 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
> await svctm %util
> 06:35:01 PM dev8-0 176.15 25.89 8773.98 49.96 0.83
> 4.73 3.79 66.85
> 06:35:01 PM dev8-1 174.74 0.13 8746.49 50.06 0.81
> 4.64 3.82 66.81
> 06:35:01 PM dev8-2 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 0.00
> 06:35:01 PM dev8-5 1.41 25.76 27.49 37.74 0.02
> 14.96 2.31 0.33
> 06:35:01 PM dev8-16 15.02 0.00 3994.82 265.95 1.27
> 84.88 2.76 4.14
> 06:35:01 PM dev8-17 15.02 0.00 3994.82 265.95 1.27
> 84.88 2.76 4.14
I'm no expert in `sar -d`, but isn't 84.88 pretty high for await?
> As far as the checkpoint goes, it does happen every 5 minutes and takes
> about 4.5 mins which corresponds to the 0.9 checkpoint_completion_target we
> have set.
So, any idea what is happening at 20 minute intervals?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2015-11-02 21:41:01 | Re: Is there bigintarray? |
Previous Message | Sami Pietilä | 2015-11-02 21:09:58 | How to search a string inside a json structure |