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"

The four numbers that decide whether it stays up

RAM and disk are the easy part. These are the settings that take a cluster down, and three of the four are counter-intuitive enough that more hardware makes them worse rather than better:

Setting	The rule	Why	What going wrong looks like
Heap size	Half of RAM, and never above 31 GB	Above ~32 GB the JVM loses compressed object pointers	A 64 GB heap addressing less than a 31 GB one
Shards per node	Under 20 per GB of heap	Each shard costs heap whether or not it is queried	Slow cluster state, then nodes dropping out
Shard size	10-50 GB each	Smaller wastes overhead, larger cannot rebalance	Recovery after a restart takes hours
Swap	Off, with memory locked	A swapped-out JVM heap stalls garbage collection	Random multi-second pauses under no real load

The one that catches people is the shard count, because the instinct after a slow cluster is to add nodes and split indices further. That spends more heap on bookkeeping and makes the problem worse. Count the shards you have first: an index per day for a year is 365 shards where a monthly index would have been 12.

Expected Performance Benchmarks

On an 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.

These are expectations for hardware of this class, not measurements from our own lab. Treat them as a starting point for sizing and measure your own workload: real numbers depend on your data, your queries and your tuning far more than on the provider.

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.