- #PXC-393: Optimized and accurate way to get mmap file gcache size using mincore syscall #100
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch implements a new information schema table ("WSREP_STATS"),
which contains the "wsrep_gcache_actual_pool_size" variable that reflects
the exact amount of memory, which is used by the "gcache" memory pool.
Using a separate information schema table for this variable avoids
deceleration of regular queries, such as SHOW STATUS.
To determine the actual amount of memory occupied by the gcache,
the mincore() syscall is used.
At the same time, I limited the size of additional vector, which used
by mincore() syscall, by dividing of large memory ranges into relatively
small 512MB chunks, which are passed to mincore() syscall. This introduces
slight performance loss due to additional syscalls, however, these costs
is less than 1%, while only the 128 kilobytes of additional memory is
allocated for mincore()-related vector.
I made sure that the state of gcache pages measured only up to the
currently achieved "watermark", but not around the entire allocated
pool - to accelerate scenarios such as
https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1462674
In addition, measurement of the actual amount of memory occupied
by the gcache avoids long-term locking of the other gcache operations,
except when mutex is aquired by the allocation or deallocation of
overflow pages (in the "Pages" storage). In this case mid-term
locking is possible – until the code that uses memcore() syscall
will stop working. However, while we do not create/free the overflow
pages, a global lock does not happen.
The related PXC patch is located here: percona/percona-xtradb-cluster#368