Elasticsearch Tuning

Elasticsearch (search & analytics engine basé Apache Lucene) requires careful tuning pour production. Cluster mal configuré = slow queries, OOM, data loss, split brains. Best practices Elastic + community.

Memory configuration :
(1) **Heap size = 50% RAM, max 31 GB** — JVM compressed OOPs jusqu'à ~32 GB, above wastes memory and slows GC. Reste RAM = OS file cache (critical pour Lucene segment caching).
(2) **bootstrap.memory_lock = true** — prevent swap (kills perf).
(3) `/etc/security/limits.conf` : `elasticsearch soft memlock unlimited`.
(4) **vm.max_map_count = 262144** (sysctl) — Lucene mmap many segments.

Cluster topology :
(1) **Dedicated master nodes** — 3 master-eligible nodes (avoid split-brain via discovery.zen.minimum_master_nodes = 2 en legacy, ou nouveau quorum logic 7.x+).
(2) **Hot-warm-cold tiers** — index récents sur SSD hot, anciens HDD warm/cold, archive frozen (searchable snapshots).
(3) **Coordinating-only nodes** pour large queries.
(4) **Ingest nodes** dédiés si pipelines lourds.
(5) **Shard count** — viser 20-50 GB par shard, 600+ shards par node = problème.

Index tuning :
(1) **refresh_interval = 30s** (default 1s) si near-real-time pas critical — drastically reduces indexing pressure.
(2) **number_of_shards** — fixed at creation, plan ahead. Default 1 (était 5 avant 7.x).
(3) **number_of_replicas** — 1+ (HA), increase on read-heavy.
(4) **index.codec = best_compression** pour cold tier (slower search, smaller disk).
(5) **ILM** (Index Lifecycle Management) — automate rollover, force merge, shrink, freeze, delete.
(6) **Mapping** — disable _source if not needed, use keyword vs text appropriately, doc_values false on fields jamais aggregated.

Monitoring : (1) Elastic Stack monitoring (Metricbeat) — cluster health, JVM heap, GC, search latency, indexing rate, queue rejections ; (2) **Cluster yellow/red** alerts ; (3) **Thread pool rejections** (search, write, bulk) signalent saturation. Compétences DEA-C01, ESS (Elastic Certified Engineer).