Re: [WIP PATCH] for Performance Improvement in Buffer Management
| От | Amit Kapila |
|---|---|
| Тема | Re: [WIP PATCH] for Performance Improvement in Buffer Management |
| Дата | |
| Msg-id | 004701cdc97c$72e54c50$58afe4f0$@kapila@huawei.com обсуждение исходный текст |
| Ответ на | [WIP PATCH] for Performance Improvement in Buffer Management (Amit kapila <amit.kapila@huawei.com>) |
| Список | 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-shared-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.
В списке pgsql-hackers по дате отправления: