New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bootstrap.mlockall
for Windows (VirtualLock)
#10887
Conversation
// By default, Windows limits the number of pages that can be locked. | ||
// Thus, we need to first increase the working set size of the JVM by | ||
// the amount of memory we wish to lock (Xmx), plus a small overhead (1MB). | ||
SizeT size = new SizeT(JvmInfo.jvmInfo().getMem().getHeapInit().getBytes() + (1024 * 1024)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to use Xmx
here? getHeapInit
is Xms
, I mean, typically, this will be the same, but by default, they are different in our config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they are different then mlockall will not really work on unix either. That is because it may map additional stuff later!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the comment is wrong...using Xms
/getHeapInit
here is intentional. The assumption is that they're the same if mlockall
is enabled. I think I chose Xms
to be on the safe side in case they aren't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the comment" as being the one in code, not yours @kimchy :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its fine if we only lock HeapInit, thats why I was confused, either by the comment in the code, or the code :). We should assume that HeapInit==HeapMax in prod deployment since we ask people to set the heap which automatically set both of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just add max(HeapInit, HeapMax) feels like a quick win here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Mpdreamz That feels a little wrong to me since it implies that it's okay for them to be different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left one comment, hard to tell if it works on my end :), I assume we tested it on windows, so I am good |
@@ -20,12 +20,14 @@ | |||
package org.elasticsearch.common.jna; | |||
|
|||
import com.google.common.collect.ImmutableList; | |||
import com.sun.jna.Native; | |||
import com.sun.glass.ui.Size; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
com.sun.glass.ui.Size
appears to be unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed, thanks @pickypg
Really minor stuff. Excited to see this get in! LGTM |
I'm being bit by the following:
Both whether mlockall is enabled or not and whether I run as Admin or not. |
@Mpdreamz that's the security manager, if you are running from an IDE you will need to add |
@Mpdreamz can you confirm whether this happens when you run bin/elasticsearch? Our policy file grants access to java.io.tmpdir (which it looks like is where you hit the issue), so if it happens then we need to open an issue, something is not right on windows maybe. |
It happens on the command line (bin/elasticsearch) not tested inside IntelliJ
|
I suspect its caused by this issue, because @rjernst tested security manager changes on a windows VM before they went in. So we need to do some investigation. |
Yeah current |
It makes some sense: as described in that commit, mlockall tests don't run with security manager enabled, so that is why we mlockall first (so we know it works, since we dont test it). What is maybe not explained is why you dont have access to what appears to be a temp dir. To satisfy curiosity, can you run ES with an additional VM argument, the windows equivalent of this?:
This guarantees full stacktrace on failure, which we don't have above. |
Output listed here: https://gist.github.com/anonymous/be30448ed6b0e0fa58e8 |
Thank you, so its as i feared, something is wrong with temporary directory permissions in your case. Can you run the same way with current |
https://gist.github.com/Mpdreamz/9da3e21ab98bb413a54d Does go into started state:
But still getting an access error:
|
@gmarz is this ready to go in? |
@clintongormley Yes :) Merging shortly. |
mlockall for Windows (VirtualLock)
bootstrap.mlockall
for Windows (VirtualLock)
This PR supersedes #9186. The original PR became a bit stale and was also working off my master branch.
I've incorporated all the feedback from #9186 as best as I could. The biggest difference from the original PR are the changes that had to be made in order to work properly with the refactoring that was done in #9923.
I believe this is now good to go, but would love to get some final eyes/testing before merging it in.
/cc @clintongormley @pickypg @ppf2 @Mpdreamz @tlrx @kimchy
Closes #8480