- CloudBees Jenkins Platform (CJP)
- CloudBees Jenkins Enterprise (CJE)
Always use a remote Elasticsearch server
Not use the embedded Elasticsearch which is included in CJP, since this one is just for testing purposes - not production ready and it will make your OC instance to be down in a few days due the high memory consumption after enabling this feature. This feature is deprecated since a long time ago.
You can read more information about the how to configure the remote Elasticsearch instance in CloudBees Analytics in our documentation.
Number of nodes
CloudBees documentation regarding analytics recommends:
- In production, at least 3 nodes Elasticsearch cluster of 32GB RAM each and ElasticSearch allocated 16GB of heap memory (Xmx) in order to not experience any slowness or degraded performance while running CloudBees Jenkins Analytics.
Elasticsearch Documentation suggests the following regarding Java heap size:
Ensure that the min (Xms) and max (Xmx) sizes are the same to prevent the heap from resizing at runtime, a very costly process.
Generally, setting the ES_HEAP_SIZE environment variable is preferred over setting explicit -Xmx and -Xms values.
The standard recommendation is to give 50% of the available memory to Elasticsearch heap, while leaving the other 50% free. Please note that the Java heap size should not exceed 32gb.
Do not change the default garbage collector!
The default GC for Elasticsearch is Concurrent-Mark and Sweep (CMS). This GC runs concurrently with the execution of the application so that it can minimize pauses. It does, however, have two stop-the-world phases. It also has trouble collecting large heaps.
Despite these downsides, it is currently the best GC for low-latency server software like Elasticsearch. The official recommendation is to use CMS.
Do not tweak threadpool settings.