[
https://issues.apache.org/jira/browse/SOLR-15133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280063#comment-17280063
]
Shawn Heisey commented on SOLR-15133:
-------------------------------------
I wish I understood the benefits and disadvantages of huge pages. I did find
this in Oracle's database documentation:
[https://docs.oracle.com/database/121/UNXAR/appi_vlm.htm#UNXAR391]
It sounds huge pages are good for things that allocate lots of memory, like
Solr and database software in general ... but that they should not be used for
general memory allocation on the system, which is what I think the "transparent
huge pages" feature in Linux does (but do not know for sure). I have read
other advice from Oracle saying that the transparent feature should be
explicitly disabled.
Although I think we could leave leave the large pages flag enabled in all cases
on our GC tuning, because on most systems it will do absolutely nothing, I do
not know if that is the correct way forward. I suspect that it will be very
troublesome for bin/solr or bin\solr.cmd to detect whether the flag should be
enabled.
> Document how to eliminate Failed to reserve shared memory warning
> -----------------------------------------------------------------
>
> Key: SOLR-15133
> URL: https://issues.apache.org/jira/browse/SOLR-15133
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker, documentation
> Affects Versions: 8.7
> Reporter: David Eric Pugh
> Assignee: David Eric Pugh
> Priority: Minor
> Fix For: master (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> inspired by a conversation on
> [https://github.com/docker-solr/docker-solr/issues/273,] it would be good to
> document how to get rid of shared memory warning in Docker setups.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
