I am using ElasticSearch + XPack 5.2.2 in production, for some performance issue with database side we are thinking of changing jvm parameter to:
Is this setting ok for ElasticSearch or
java.security: file:/dev/random -> This should be used for ES.
You could change it to
/dev/urandom if you feel that using
/dev/random is affecting the JVM's startup time. But keep in mind that
/dev/random is more secure that
/dev/urandom and since this only affects JVM startup time then it might not be worth to change it.
It is a myth that
/dev/urandom is insecure,
/dev/urandom is cryptographically secure. The difference between
/dev/random has no practical impact whatsoever on the security of the cryptographic protocols used within Elasticsearch (via X-Pack) (random numbers seeded by
/dev/urandom are generated elsewhere within Elasticsearch (e.g., for generating UUIDs) but these have no intention of being secure).
Also, I'm not sure what this has to do with startup, there are not issues here like JRuby startup (that impacts Logstash).
Can you explain what performance problem you are seeing and why you think it has something to do with blocking on reads from
Thank you, There is no Start Issue with elastic search with dev/random.
We have common jvm configuration, one jvm instance used by Database and other jvm instance used by Elastic Search.
We have not encountered any Issue with Elastic search due to dev/random. But oracle ojdbc jar performance was not good with dev/random, as we were experiencing , Slow JDBC Connections.
So we modified this to use dev/urandom and we could see good performance on jdbc side.
I raised this query to know If dev/urandom is okay for Elastic Search.
From your comment, its okay. So this gives answer to me. Thank You.
It would be best to not run Elasticsearch and a database application on the same server, they will contend for the same resources. Also, I want to point out that you can change the source with the Java option
-Djava.security.egd=file:/dev/urandom which will apply to a single JVM without having to change the security policy for the whole system.
Thank you for your Input, We are planning for separate jvm in future. Right now will go for -Djava.security.egd. I also agree we should not change standard jvm security policy.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.