Add Elasticsearch memory_lock #382
Conversation
|
Notice, this is applicable to Elasticsearch 2.4.0 and newer. In previous ES versions the setting was called |
|
@lukas-vlcek Can you please also update the run.sh script to set min and max heap to be the same. This seems like a reasonable PR to append it too. |
|
@jcantrill My take on |
|
@jcantrill @ewolinetz @richm @portante As far as I know we should be able to rely on disabled swap on the host going forward (via IMO it does not hurt to bring this into master as long as we are on ES 2.x. However, once we migrate to ES 5.x we may need to revert this change due to bootstrap check. I do not know if that bootstrap check will fail in this case. |
|
[test] |
|
Evaluated for aggregated logging test up to 4744ec8 |
|
Does this change need for elasticsearch to be running in privileged mode? |
|
@richm, good catch. I would think so. @lukas-vlcek, did you try this out under openshift somewhere? |
|
Aggregated Logging Test Results: SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test-origin-aggregated-logging/1321/) (Base Commit: e231410) |
|
[merge] |
|
Evaluated for aggregated logging merge up to 4744ec8 |
|
@jcantrill, I don't think this should be merged. |
|
Aggregated Logging Merge Results: FAILURE (https://ci.openshift.redhat.com/jenkins/job/test-origin-aggregated-logging/1325/) (Base Commit: 47f52c2) |
|
@portante What is the reason we wish to hold off merging this change? |
|
@jcantrill Lukáš needs to do more testing to confirm that this actually works, and how to configure the machine (e.g. ulimit, etc.) in order to make it work. I think in ES 2.x it will silently fail if the machine is not set up correctly, and in ES 5.x it will hard fail. @lukas-vlcek |
|
@jcantrill Added "Do not merge" label for now. We really need to get to the bottom of this and deliver clear documentation (backed by testing) around this setting. When we started looking at this (#206) it was not known OCP would decide to disable swap at the OS level so we need to reflect new situation now. Even as for assumption that it will fail hard with ES 5.x - I am still not 100% sure about this. There is bootstrap check that will fail if mlockall is required and ES will not be able to lock the memory at startup. However, failed bootstrap checks should be ignored if ES runs in development mode - i.e. "if ES does not bind transport to an external interface" (so does it apply if we run ES in container and bind it to |
|
@jcantrill, I don't think this commit is necessary, given we should be running without swap for Elasticsearch, and we don't want to run a privileged container just so that ES can lock all memory. |
|
It makes sense to add/improve documentation around setup and use of memory lock setting for ES for users that have reason to use it. But there should be a different ticket opened for this. Closing for now. |
Closes #206