[jira] [Commented] (OAK-7860) Make PermissionEntryCache more resilient against OOME

["Alex Deparvu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662054#comment-16662054 ] 

Alex Deparvu commented on OAK-7860:
-----------------------------------

WIP branch is [0]. the changes are pretty straight-forward, but instrumenting the benchmark to compare was a bit more work.
Results are very encouraging, the OOME doesn't happen anymore (at the cost of a small perf drop).
{noformat}
[trunk]
# CanReadNonExisting               C     min     10%     50%     90%     max       N 
Oak-Segment-Tar                    1     992    1060    1199    1322    1391      51
Oak-Segment-Tar                    5    1999    2165    2800    3393    4072     110
Oak-Segment-Tar                   10    2394    4194    5168    6639    6739     115
{noformat}

{noformat}
[patch]
Oak-Segment-Tar                    1     942     956    1104    1160    1249      56
Oak-Segment-Tar                    5    1899    1944    2137    2290    2479     145
Oak-Segment-Tar                   10    2196    4708    4965    5393    5570     123
Oak-Segment-Tar                   50   30233   31458   35693   40658   41242     100
Oak-Segment-Tar                  100   63166   64998   65880   66479   66608     100
{noformat}

Trunk crashes at 50 concurrent threads: {{java.lang.OutOfMemoryError: Java heap space}}, while the patched version is very robust (see also the heap screenshots).


[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:oome-permissionentrycache

> Make PermissionEntryCache more resilient against OOME
> -----------------------------------------------------
>
>                 Key: OAK-7860
>                 URL: https://issues.apache.org/jira/browse/OAK-7860
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Alex Deparvu
>            Assignee: Alex Deparvu
>            Priority: Major
>             Fix For: 1.10, 1.9.10
>
>
> The PermissionEntryProviderImpl (one instance per session) is responsible for serving the permission entries. It can be backed by 2 different types of caches:
> * the {{PathEntryMapCache}} which is simply a map that eagerly loads all existing permissions for a session (aka. set of principals). Used only if there are less than 250 total entries per session (all principals combined).
> * The {{DefaultPermissionCache}} backed by the {{PermissionEntryCache}}. this is the fallback for the cases where the above is too expensive to use.
> In some cases, even if the number of permission entries per principal is not too large, a session that accumulates large numbers of group principals (I've seen over 700 in one internal case), will always fallback to use the {{PermissionEntryCache}}.
> The {{PermissionEntryCache}} is a cache that is using the principal as a key and the permission entries as values. It is aggregating 2 different types of data:
> * Existing policies: maps principals to paths with (their) existing policies (regular cache stuff)
> * but it also retains paths without any relevant policies for the current session, as empty sets [0]. being a cache keyed on the 'principal', this placeholder for empty policies will be set for each principal.
> I believe this second part can be responsible for a large memory footprint, which can also be amplified by the very large number of principals in the session.
> I would like to propose separating the 2 sets contained in the cache, putting the non-relevant paths in a dedicated map with a fixed size.
> [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/permission/PermissionEntryCache.java#L74



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)