database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-21 12:05:57 +03:00
Code

Increase maximum number of clog buffers.

Browse Source 
Benchmarking has shown that the current number of clog buffers limits
scalability. We've previously increased the number in 33aaa139, but
that's not sufficient with a large number of clients.

We've benchmarked the cost of increasing the limit by benchmarking worst
case scenarios; testing showed that 128 buffers don't cause a
regression, even in contrived scenarios, whereas 256 does

There are a number of more complex patches flying around to address
various clog scalability problems, but this is simple enough that we can
get it into 9.6; and is beneficial even after those patches have been
applied.

It is a bit unsatisfactory to increase this in small steps every few
releases, but a better solution seems to require a rewrite of slru.c;
not something done quickly.

Author: Amit Kapila and Andres Freund
Discussion: CAA4eK1+-=18HOrdqtLXqOMwZDbC_15WTyHiFruz7BvVArZPaAw@mail.gmail.com
This commit is contained in:
Andres Freund 2016-04-08 08:18:52 -07:00
parent 25fe8b5f1a
commit 5364b357fb
1 changed files with 11 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
src/backend/access/transam/clog.c
View File

@ -417,30 +417,23 @@ TransactionIdGetStatus(TransactionId xid, XLogRecPtr *lsn)
/* /*
* Number of shared CLOG buffers. * Number of shared CLOG buffers.
* *
* Testing during the PostgreSQL 9.2 development cycle revealed that on a * On larger multi-processor systems, it is possible to have many CLOG page
* large multi-processor system, it was possible to have more CLOG page * requests in flight at one time which could lead to disk access for CLOG
* requests in flight at one time than the number of CLOG buffers which existed * page if the required page is not found in memory. Testing revealed that we
* at that time, which was hardcoded to 8. Further testing revealed that * can get the best performance by having 128 CLOG buffers, more than that it
* performance dropped off with more than 32 CLOG buffers, possibly because * doesn't improve performance.
* the linear buffer search algorithm doesn't scale well.
* *
* Unconditionally increasing the number of CLOG buffers to 32 did not seem * Unconditionally keeping the number of CLOG buffers to 128 did not seem like
* like a good idea, because it would increase the minimum amount of shared * a good idea, because it would increase the minimum amount of shared memory
* memory required to start, which could be a problem for people running very * required to start, which could be a problem for people running very small
* small configurations. The following formula seems to represent a reasonable * configurations. The following formula seems to represent a reasonable
* compromise: people with very low values for shared_buffers will get fewer * compromise: people with very low values for shared_buffers will get fewer
* CLOG buffers as well, and everyone else will get 32. * CLOG buffers as well, and everyone else will get 128.
*
* It is likely that some further work will be needed here in future releases;
* for example, on a 64-core server, the maximum number of CLOG requests that
* can be simultaneously in flight will be even larger. But that will
* apparently require more than just changing the formula, so for now we take
* the easy way out.
*/ */
Size Size
CLOGShmemBuffers(void) CLOGShmemBuffers(void)
{ {
return Min(32, Max(4, NBuffers / 512)); return Min(128, Max(4, NBuffers / 512));
} }
/* /*