> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsoar-6-installation-guides/6.15/cortex-xsoar-installation-guide/single-server-installation/install-cortex-xsoar-with-elasticsearch/elasticsearch-best-practices.md).

# Elasticsearch Best Practices

Elasticsearch configuration best practices for Cortex XSOAR 6.15.

The following are the recommended best practices for installing Cortex XSOAR with Elasticsearch.

* It is important to utilize Elasticsearch's versatile behavior using shards and replicas. If you are using more than 1 node, we recommend that you set the `elasticsearch.defaultShardsPerIndex` and `elasticsearch.defaultReplicasPerIndex` to 1 and 2, respectively. You can also use `elasticsearch.shards` and `elasticsearch.replicas` to configure specific number of shards and replicas, respectively, on each index.

  For example, setting the following values in `demisto.conf` sets 2 replicas for each shard for the incidents index:

  `"elasticsearch": { "shards": { "common-incident": 1 }, "replicas": { "common-incident": 2 } } }`

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>This configuration takes effect when the index is created.</p></div>
* Suggested configuration based on the number of data nodes in the Elasticsearch cluster:

  | Configuration                                                    | 2 Data Nodes | 3 Data Nodes | 4 Data Nodes |
  | ---------------------------------------------------------------- | ------------ | ------------ | ------------ |
  | defaultShardsPerIndex                                            | 1            | 1            | 1            |
  | defaultReplicasPerIndex                                          | 1            | 2            | 3            |
  | <p>Shards:</p><p>- common entry</p><p>- common-invplaybook</p>   | 2            | 3            | 4            |
  | <p>Replicas:</p><p>- common entry</p><p>- common-invplaybook</p> | 1            | 1            | 1            |
* Cortex XSOAR uses an internal batch to Elasticsearch to avoid heavy requests and large indexing latency. You can increase the batch size using `elasticsearch.innerBatchSize` to increase performance and speed, or decrease the value if Elasticsearch is not optimized.
* Due to Cortex XSOAR’s high usage of Elasticsearch, we recommend having the lowest latency possible between the Cortex XSOAR server and the Elasticsearch nodes configured. We also recommend having low latency between nodes to avoid slow indexing or possible data loss during outages. Any latency between Cortex XSOAR and Elasticsearch will greatly impact performance.
* Elasticsearch uses an internal memory management implemented in JAVA that is called the [heap size](https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html#heap-size-settings). It defaults to 1GB, and Cortex XSOAR recommends you increase the heap size to 50% of the machine's memory, or more if the machine is dedicated to Elasticsearch.
* Elasticsearch uses a refresh mechanism to flush updated documents to the disk every configured seconds. We recommend setting the configuration index to 1 second. You can use the Cortex XSOAR `demisto.conf` file to set a specific refreshing interval in seconds for each index using `elasticsearch.refreshIntervals`.

  For example, the following sets the configuration index to 1 second:

  `"elasticsearch": { "refreshIntervals": { "common-configuration": 1s } }`

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>This configuration takes effect when the index is created.</p></div>
* We recommend using the most recent supported version of Elasticsearch to ensure you have the latest features and all security updates.
* Circuit breakers in Elasticsearch are enabled by default. Verify they are enabled and configured correctly, specifically the **request circuit breaker** and the **parent circuit breaker**. These circuit breakers will prevent data nodes from crashing on high memory consumption and will also drop certain requests that Cortex XSOAR will retry later.
* Elasticsearch requires a large number of open file descriptors. Verify that the [limit on the number of open file descriptors](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html) is sufficient to handle a high load of requests, to avoid possible data loss or service interruptions.

### **Scaling**

To optimize an Elasticsearch deployment for scaling, we recommend using a dedicated master node as well as coordinating nodes to handle requests, thus having all connections and requests go through the coordinating nodes. Using dedicated coordinating nodes improves Elasticsearch balancing when some data nodes might be unavailable or unresponsive due to high load. Dedicated master node(s) ease data nodes' responsibility around shard management, snapshots, and monitoring. Elasticsearch distributes the requests more efficiently through the use of master and coordinating nodes.

We also recommend using a load balancer or round-robin DNS server when configuring an elasticsearch.url that points to all/any coordinating nodes. A load balancer enables you to swap, add, or remove data nodes, master nodes, and coordinating nodes without having to update the Cortex XSOAR configuration file and restart the Cortex XSOAR service, thus significantly decreasing downtime for any changes.

### **Mapping**

Indexes with custom fields such as incidents, evidence, and indicators might exceed the max fields mapping limit in Elasticsearch. By default, Cortex XSOAR sets the limit to 2000. If you require more, you can increase the `elasticsearch.totalFields` field in the `demisto.conf` file.

For example, the following sets the incidents index maximum to 3000 mapped fields:

`"elasticsearch": { "totalFields": { "common-incident": 3000 } }`

{% hint style="info" %}
This configuration takes effect when the index is created.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsoar-6-installation-guides/6.15/cortex-xsoar-installation-guide/single-server-installation/install-cortex-xsoar-with-elasticsearch/elasticsearch-best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.