From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | "'Jeff Janes'" <jeff(dot)janes(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP PATCH] for Performance Improvement in Buffer Management |
Date: | 2012-11-23 13:14:19 |
Message-ID: | 004701cdc97c$72e54c50$58afe4f0$@kapila@huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>Shouldn't that data be in the shared buffers if not the OS cache and hence
approximately same IO will be required?
>I don't think so as the data in OS cache or PG Shared buffers doesn't have
any direct relation, >OS can flush its buffers based on its scheduler
algorithm.
>Let us try to see by example:
>Total RAM - 22G
>Database size - 16G
>Case -1 (Shared Buffers - 5G)
>a. Load all the files in OS buffers. Chances are good that all 16G data
will be there in OS >buffers as OS has still 17G of memory available.
>b. Try to load all in Shared buffers. Last 5G will be there in shared
buffers.
>c. Chances are high that remaining 11G buffers access will not lead to IO
as they will be in OS >buffers.
>Case -2 (Shared Buffers - 10G)
>a. Load all the files in OS buffers. In best case OS buffers can
contain10-12G data as OS has >12G of memory available.
>b. Try to load all in Shared buffers. Last 10G will be there in shared
buffers.
>c. Now as there is no direct correlation of data between Shared Buffers and
OS buffers, so >whenever PG has to access any data
> which is not there in Shared Buffers, good chances are there that it can
lead to IO.
>> Again, the drop in the performance is so severe that it seems worth
investigating that further, especially because you can reproduce it
reliably.
> Yes, I agree that it is worth investigating, but IMO this is a different
problem which might >not be addressed with the Patch in discussion.
> The 2 reasons I can think for dip in performance when Shared Buffers
increase beyond certain > threshhold percentage of RAM are,
> a. either the algorithm of Buffer Management has some bottleneck
> b. due to the way data is managed in Shared Buffers and OS buffer cache
The point I want to tell is explained at below link as well.
http://blog.kimiensoftware.com/2011/05/postgresql-vs-oracle-differences-4-sh
ared-memory-usage-257
So if above is true, I think the performance will regain if in the test
Shared Buffers are set to 16G. I shall once try that setting for test run.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-11-23 13:33:07 | Plugging fd leaks (was Re: Switching timeline over streaming replication) |
Previous Message | Magnus Hagander | 2012-11-23 12:05:45 | Re: PQconninfo function for libpq |