[
https://issues.apache.org/jira/browse/LUCENE-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140089#comment-14140089
]
Uwe Schindler commented on LUCENE-5928:
---------------------------------------
Hi,
as I mentioned before, SHR is shared memory - used by multiple processes. In
the case of mmap, it is shared memory used by the kernel (FS cache) and at the
same time by the process (mmapped files currently in fs cache), so you cannot
count it 2 times. In fact, if you use mmap, the "real" resident memory by a
process is RES - SHR. The remaining SHR is just resident (because allocated)
because the kernel has actually done this allocation and frees it on request
(there must be something that allocates RAM for the disk cache...).
It is a little bit confusing, but correct :-) There is nothing wrong with Solr.
> WildcardQuery may has memory leak
> ---------------------------------
>
> Key: LUCENE-5928
> URL: https://issues.apache.org/jira/browse/LUCENE-5928
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
> Affects Versions: 4.9
> Environment: SSD 1.5T, RAM 256G, records 15*10000*10000
> Reporter: Littlestar
> Assignee: Uwe Schindler
> Attachments: idxb1-top-sorted-mem.png, top_java.jpg
>
>
> data 800G, records 15*10000*10000.
> one search thread.
> content:???
> content:*
> content:*1
> content:*2
> content:*3
> jvm heap=96G, but the jvm memusage over 130g?
> run more wildcard, use memory more....
> Does luence search/index use a lot of DirectMemory or Native Memory?
> I use -XX:MaxDirectMemorySize=4g, it does nothing better.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
