elasticsearch: Java memory error when building with Ubuntu

I’m getting a memory error when running against Ubuntu 16.04.1 LTS 4.4.0-45-generic

This is in my docker-compose.ml

image: elasticsearch
environment:
    - ES_JAVA_OPTS=-Xmx10g -Xms10g

It doesn’t matter what settings I add to ES_JAVA_OPTS as I always get the following error when running

OpenJDK 64-Bit Server VM warning: 
INFO: os::commit_memory(0x0000000545330000,10650189824, 0) 
failed; error='Cannot allocate memory' (errno=12)

There is insufficient memory for the Java Runtime Environment to continue.

Native memory allocation (mmap) failed to map 10650189824 bytes 
for committing reserved memory.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 25 (5 by maintainers)

Most upvoted comments

Add some space for swap area $ free -m $ sudo fallocate -l 1G /swapfile $ sudo chmod 600 /swapfile $ sudo mkswap /swapfile $ sudo swapon /swapfile

Had the same issued, but seems to be fixed with the following in docker-compose.yml:

  # docker-compose.yml
  elasticsearch:
    image: elasticsearch:5
    environment:
      ES_JAVA_OPTS: -Xms512m -Xmx512m
    volumes:
      - es_data:/usr/share/elasticsearch/data

(512m might be too small - I’m just starting with ES so testing different memory limits)

Can you try this sudo sysctl -w vm.max_map_count=262144?

This work for me in AMI AWS CentOs instance with only 1GB of memory. sudo nano /etc/elasticsearch/jvm.options -Xms512m -Xmx512m

I imagine something like -e ES_JAVA_OPTS='-Xms1g -Xmx1g' should work, right? (with higher or lower values depending on your available memory and how much you want to allocate to elasticsearch specifically)

Running a demo server on 512M machines, so I just removed the memory options / optimizations sudo nano /etc/elasticsearch/jvm.options as follows: (thanks @carlosival )

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

# -Xms2g
# -Xmx2g
... [scroll down]...
# explicitly set the stack size (reduce to 320k on 32-bit client JVMs)
#-Xss1m

With all memory options commented out, the JVM will simply do its thing and allocate memory as needed. I am guessing the reason the defaults are set is to optimize performance, and also to make memory use predictable (capped at 2g, so you can be sure it’s not going to just run around allocating all memory on your server). But for my demo purposes none of that is needed.

I fixed my issue by passing the ES_JAVA_OPTS with a smaller value, I think that by default it tries to allocate the whole memory of the machine to it (in my case 2GB) and it fails.