[
https://issues.apache.org/jira/browse/OAK-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620405#comment-14620405
]
Thomas Mueller commented on OAK-3007:
-------------------------------------
For future reference, a benchmark I ran was:
{noformat}
java -Dwarmup=5 -Druntime=2 -Dprofile=true -jar target/oak-run-1.4-SNAPSHOT.jar
benchmark ReadPropertyTest Oak-Tar | grep "Segment.read"
{noformat}
This does not show readString, but many readTemplate calls. Possibly the
following tests could be run as well:
ReadDeepTreeTest
ConcurrentReadDeepTreeTest
ConcurrentReadRandomNodeAndItsPropertiesTest
ConcurrentReadTest
ConcurrentTraversalTest
DescendantSearchTest
GetDeepNodeTest
GetNodeWithAdmin
ReadPropertyTest
SQL2DescendantSearchTest
SQL2SearchTest
SimpleSearchTest
> SegmentStore cache does not take "string" map into account
> ----------------------------------------------------------
>
> Key: OAK-3007
> URL: https://issues.apache.org/jira/browse/OAK-3007
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Reporter: Thomas Mueller
> Fix For: 1.3.3
>
> Attachments: OAK-3007-2.patch, OAK-3007-3.patch, OAK-3007.patch
>
>
> The SegmentStore cache size calculation ignores the size of the field
> Segment.string (a concurrent hash map). It looks like a regular segment in a
> memory mapped file has the size 1024, no matter how many strings are loaded
> in memory. This can lead to out of memory. There seems to be no way to limit
> (configure) the amount of memory used by strings. In one example, 100'000
> segments are loaded in memory, and 5 GB are used for Strings in that map.
> We need a way to configure the amount of memory used for that. This seems to
> be basically a cache. OAK-2688 does this, but it would be better to have one
> cache with a configurable size limit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
