> 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/xsoar-6-administrator-guide/6.14/onboard-cortex-xsoar/elasticsearch/elasticsearch-setup.md).
# Elasticsearch Setup
In this section you can do the following:
* View best practices
* System requirements
* Configurations
* Data Management
### Elasticsearch Best Practices
Elasticsearch comes with built-in support for data redundancy. Refer to the Elasticsearch documentation to ensure that you have configured your database properly for [high availability](https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability.html).
In addition, there are certain best practices and configurations that will enable you to work best with Cortex XSOAR.
**Performance**
* To achieve high availability, you will need to set up at least three nodes.
* It is important to utilize Elasticsearch versatile behavior using shards and replicas. If you are using more than one 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 two replicas for each shard for the incidents index:
**`"elasticsearch": { "shards": { "common-incident": 1 }, "replicas": { "common-incident": 2 } } }`**
Note
This configuration takes effect when the index is created.
Shards:
- common entry
- common-invplaybook
| 2 | 3 | 4 |
| Replicas:
- common entry
- common-invplaybook
| 1 | 1 | 1 |
* Cortex XSOAR uses an internal batch to Elasticsearch to avoid heavy requests and large indexing latency. There are two flags you can increase/decrease to improve performance.
| Flag | Description |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| elasticsearch.innerBatchSize | Number of docs in each batch. The default is 250. |
| elasticsearch.maxContentLength | If **`http.max_content_length`** is not defined in your Elasticsearch, you can set **`elasticsearch.maxContentLength`** in configurations instead. This is used to calculate batch size in MB. The default is 100 MB. |
* Due to Cortex XSOAR’s high usage of Elasticsearch, we recommend you configure the lowest latency possible between the XSOAR server and the Elasticsearch nodes. We also recommend to have low latency between nodes to avoid slow indexing or possible data loss on outages. Any latency between Cortex XSOAR and Elasticsearch will greatly impact performance.
* Elasticsearch uses an inner 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 we recommend you increase the heap size to 50% of data nodes memory and to 80% of master and coordinating nodes if the machine is dedicated to Elasticsearch.
* Elasticsearch uses a refreshing mechanism to flush updated documents to the disk every configured number of seconds. We recommend setting the configuration index to one 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 one second:
**`"elasticsearch": { "refreshIntervals": { "common-configuration": "1s" } }`**
Note
This configuration takes effect when the index is created.