[
https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240872#comment-17240872
]
ASF subversion and git services commented on GEODE-8537:
--------------------------------------------------------
Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ]
GEODE-8537: Solve memory increase when LRU eviction is enabled (#687)
* GEODE-8537: Refactor LRUList
- LRUEntryProperties has been put into a separate file.
- LRUList has been entirely refactored. It now uses STL's deque as base
implementation. Implements the following methods:
* push
* pop
* remove
* move_to_end
* size
* clear
- LRUList has been renamed to LRUQueue.
* GEODE-8537: Integrate LRUQueue into LRU entries map
- Refactored LRUEntriesMap to integrate with the new implementation of
LRUQueue.
* GEODE-8537: Fix compilation
- After the changes made to both LRUQueue and LRUEntryProperties, compilation
was broken.
- This commit solves that.
* GEODE-8537: Add UTs for LRUQueue
- Added UTs for LRUQueue.
- Added a mock for MapEntryImpl.
- Removed testLRUList from old integration tests as has been replaced by the UT
TS.
* GEODE-8537: Solve EvictionController malfunction
- EvictionController and EvictionThread was causing an inter-lock and also
there was a race-condition which made LRU eviction not to be accurate.
- In order to solve EvictionController malfunction the following things have
been changed:
* Now evictions are made by the EvictionController and the EvictionThread has
been removed as in addition to the inter-lock, it was causing some
unnecessary overhead.
* EvictionController queue has been replaced by the heap size itself as an
atomic variable. So now, eviction happens directly whenever heap size
overflows the established limit, without having to sum up the deltas on the
queue.
- Additionally heap size counter in the LRUEntriesMap has been replaced by an
atomic counter, getting rid therefore of the mutex.
* GEODE-8537: Add LRU eviction integration tests
- Added a new integrations TS to verify LRU eviction functionality.
* GEODE-8537: Remove wrong test from old ITs
- After implementing the new LRUQueue I noticed that
testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was
wrongly implemented.
- Having set LRU entries limit to 10 and getting key "15" you could not expect
that after putting keys [20, 35], key "15" would be still there.
- Also the test has been replaced by one new integration test called
LRUEvictionTest.verifyLruOrderGet
* GEODE-8537: Revision 2
- Used mixed case in the EvictionController.
- Removed debugging trace which was left during development.
* GEODE-8537: Revision 3
- After discussing about the nature of LRUQueue, it seems that
std::mutex is a better alternative to make LRUQueue thread-safe, so
it's now the mutex used.
* GEODE-8537: Re-trigger CI
> Memory increases whenever LRU eviction is enabled
> -------------------------------------------------
>
> Key: GEODE-8537
> URL: https://issues.apache.org/jira/browse/GEODE-8537
> Project: Geode
> Issue Type: Bug
> Components: native client
> Affects Versions: 1.13.0
> Reporter: Mario Salazar de Torres
> Assignee: Mario Salazar de Torres
> Priority: Major
> Labels: pull-request-available
> Attachments: massif-8419.png, massif.out.8419
>
>
> *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml
> for a region
> *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region
> region
> *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region
> region
> *HAVING* configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications
> *THEN* memory increases continously over time, even going over the LRU limit.
> Find massif tool report as massif.out.8419 showing the memory increase.
> Also this is a capture of massif-visualizer for the report:
> !massif-8419.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
