Cloud Server for Elasticsearch in Europe: EU Search Hosting

Cloud Server for Elasticsearch in Europe: EU Search Hosting

Elasticsearch is the backbone of full-text search, log analytics, and observability stacks in modern applications. For businesses handling data about European users, where that search index lives - and who controls the infrastructure - has direct implications for GDPR compliance and query response times.

This guide covers the hardware Elasticsearch needs, how to tune the JVM heap and shards, and what search throughput to expect on an EU cloud server.

Why EU Data Residency Matters for Elasticsearch

Elasticsearch indexes commonly contain user-generated content, behavioral logs, and document data tied to individual identities - all personal data under GDPR. Hosting on an EU server operated by an EU company means your search index never leaves EU jurisdiction, satisfying data residency requirements without supplementary legal instruments.

Network proximity also matters for search. An Elasticsearch cluster in Central Europe responds to query requests from a Berlin application in 2-5ms. The same cluster in a US data center adds 80-120ms per query - enough to make autocomplete and real-time search feel sluggish to European users.

Minimum Specs for Elasticsearch

Elasticsearch is memory- and CPU-intensive. The JVM heap should be set to 50% of available RAM, and the OS must retain the other 50% for the filesystem cache (Lucene reads segment files through the OS page cache):

• Small (dev/logging, under 50 GB index) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
• Medium (production search, 50-500 GB index) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
• Large (analytics, multi-TB index or high ingest) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD

NVMe storage is particularly important for Elasticsearch because segment merges are I/O-intensive background operations. Slow disk makes merges fall behind during ingest spikes, causing search latency to spike.

Recommended DCXV Configuration

DCXV cloud servers provide NVMe-backed storage with consistent IOPS, which keeps Elasticsearch segment merges on schedule. Recommended configurations:

• 8 vCPU, 32 GB RAM, 1 TB NVMe - production search cluster node for a content or e-commerce platform
• 16 vCPU, 64 GB RAM, 2 TB NVMe - log analytics or observability stack (ELK/OpenSearch compatible)

For a production cluster, deploy 3 nodes on DCXV private networking. This gives you shard redundancy and allows rolling restarts without downtime. Contact sales@dcxv.com to discuss cluster topology and private network configuration.

Quick Setup Commands

# Install Elasticsearch 8.x on Ubuntu 22.04
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt update && sudo apt install -y elasticsearch

# Start and enable the service
sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

# Key elasticsearch.yml settings for a 32 GB RAM node
# Edit /etc/elasticsearch/elasticsearch.yml

cluster.name: my-eu-cluster
node.name: node-1
network.host: 10.0.0.5         # private IP of this server
http.port: 9200
discovery.seed_hosts: ["10.0.0.5", "10.0.0.6", "10.0.0.7"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

# Paths
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

# JVM heap sizing - set to 50% of RAM, never exceed 31 GB
# Edit /etc/elasticsearch/jvm.options.d/heap.options
-Xms16g
-Xmx16g

# OS-level tuning for Elasticsearch
# Disable swap (critical for JVM performance)
sudo swapoff -a
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf

# Increase file descriptor and mmap limits
echo 'elasticsearch soft nofile 65535' | sudo tee -a /etc/security/limits.conf
echo 'elasticsearch hard nofile 65535' | sudo tee -a /etc/security/limits.conf
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

sudo systemctl restart elasticsearch

# Verify cluster health and create an index
curl -X GET "http://10.0.0.5:9200/_cluster/health?pretty"

# Create an index with explicit shard/replica settings
curl -X PUT "http://10.0.0.5:9200/my-index" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "refresh_interval": "30s"
  }
}'

# Index a document
curl -X POST "http://10.0.0.5:9200/my-index/_doc" -H 'Content-Type: application/json' -d'
{
  "title": "EU cloud server guide",
  "content": "Elasticsearch running on DCXV infrastructure"
}'

# Run a search query
curl -X GET "http://10.0.0.5:9200/my-index/_search?q=cloud&pretty"

Expected Performance Benchmarks

On a DCXV 8 vCPU / 32 GB RAM / NVMe node with Elasticsearch 8.x and 16 GB JVM heap:

• Indexing throughput (bulk API, batch 1000) - 15,000-30,000 docs/s
• Search queries per second (simple term query) - 500-1,500 QPS
• Search queries per second (complex aggregation) - 50-200 QPS
• P99 query latency (cached warm query) - under 10ms
• Segment merge throughput - 200-500 MB/s on NVMe

Shard count is the biggest tuning lever. Aim for shards of 20-50 GB each. Too many small shards waste overhead; too few large shards limit parallelism.

Bottom Line

Elasticsearch on an EU cloud server keeps your search index and user data in EU jurisdiction while delivering the low-latency, high-throughput search your application needs. Set JVM heap to 50% of RAM, disable swap, and deploy a 3-node cluster for production resilience. DCXV cloud servers provide the NVMe storage and EU data residency your Elasticsearch cluster requires.