Garbage Collection in ES


(Brad Lhotsky) #1

Hello,

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

This is a CentOS 5 box, and I've set the /proc/sys/vm/swappiness to 0.
On one box I have completely disabled swap, but as a System
Administrator, this makes me really nervous. Disabling virtual memory
is not a production solution and doesn't appear to have fixed the
issue anyways.

I hacked together a Perl script to pull data from the ElasticSearch
nodes and output it to graphite or cacti. It's attached as
perf_elastic_search.pl.

I'm seeing some interesting behavior from the garbage collection at
the point this timeout occurs. The Graphlot-2h.png shows the garbage
collection time_ms spiking as the heap.used_bytes drops significantly.
This seems to be a pattern, see Graphlot-24h.png.

It seems once the node has more than 8gb in heap.used_bytes, it
garbage collects itself down to 2gb. However, the GC between these
points is relatively unconcerned by the expanding heap.

Is there a way to force the garbage collection to favor smaller, more
frequent GC than to simply do it all at once every 2-3 hours? This
Garbage collection results in nodes timing out their connections for 6
seconds every 2-3 hours.

I'm not a Java guy, so any nudges in the right direction would be appreciated.

Thanks,

--
Brad Lhotsky


(Clinton Gormley) #2

Hi Brad

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

One question - are you sure that you have "ulimit -l unlimited" set for
the user running elasticsearch? If not, then the mlockall will be
ignored.

eg I have this in my /etc/security/limits.conf:

elasticsearch - nofile 32000
elasticsearch - memlock unlimited

but I know that, at least on ubuntu, this file is ignored by default.
Don't know what the situation is on Centos.

clint


(Brad Lhotsky) #3

Sorry, forgot to include that, yes, I have this in /etc/security/limits.conf:
elasticsearch - memlock unlimited

Have you graphed the jvm stats? Do you see the same massive GC
Sessions every few hours?

On Fri, Feb 17, 2012 at 11:27 AM, Clinton Gormley clint@traveljury.com wrote:

Hi Brad

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

One question - are you sure that you have "ulimit -l unlimited" set for
the user running elasticsearch? If not, then the mlockall will be
ignored.

eg I have this in my /etc/security/limits.conf:

elasticsearch - nofile 32000
elasticsearch - memlock unlimited

but I know that, at least on ubuntu, this file is ignored by default.
Don't know what the situation is on Centos.

clint

--
Brad Lhotsky


(Danil ŢORIN) #4

Try to reduce the memory.

If after GC your memory usage is ~2GB, set your limits to 3Gb.

On Fri, Feb 17, 2012 at 12:41, Brad Lhotsky brad.lhotsky@gmail.com wrote:

Sorry, forgot to include that, yes, I have this in /etc/security/limits.conf:
elasticsearch - memlock unlimited

Have you graphed the jvm stats? Do you see the same massive GC
Sessions every few hours?

On Fri, Feb 17, 2012 at 11:27 AM, Clinton Gormley clint@traveljury.com wrote:

Hi Brad

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

One question - are you sure that you have "ulimit -l unlimited" set for
the user running elasticsearch? If not, then the mlockall will be
ignored.

eg I have this in my /etc/security/limits.conf:

elasticsearch - nofile 32000
elasticsearch - memlock unlimited

but I know that, at least on ubuntu, this file is ignored by default.
Don't know what the situation is on Centos.

clint

--
Brad Lhotsky


(Clinton Gormley) #5

Hi Brad

On Fri, 2012-02-17 at 11:41 +0100, Brad Lhotsky wrote:

Sorry, forgot to include that, yes, I have this in /etc/security/limits.conf:
elasticsearch - memlock unlimited

Sorry, just to repeat: are you sure that it is being applied? When you
start ES, does it immediately take up the full amount specified in
ES_MAX_MEM?

Have you graphed the jvm stats? Do you see the same massive GC
Sessions every few hours?

I haven't done so for a long time, but yes, I used to see those big GCs,
but they are fast enough so that they don't cause a problem. We're
currently running 0.17.9 in production, so if you're on a more recent
version, behaviour might have changed.

I'll use bigdesk to capture some data today, and come back to you

clint


(Aurélien-2) #6

Hello.

this is a quite huge heap size for a JVM.

Gil Tene as explained the problem quite well: http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection Ok, he's Azul co-founder so it's a kind of advertising for Azul, but the presentation is still very interesting.

So, I think Danil is right: reduce the heap size. Or give a try to Azul :slight_smile:

regards.
----- Mail original -----

De: "Brad Lhotsky" brad.lhotsky@gmail.com
À: elasticsearch@googlegroups.com
Envoyé: Vendredi 17 Février 2012 11:20:54
Objet: Garbage Collection in ES

Hello,

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

This is a CentOS 5 box, and I've set the /proc/sys/vm/swappiness to
0.
On one box I have completely disabled swap, but as a System
Administrator, this makes me really nervous. Disabling virtual memory
is not a production solution and doesn't appear to have fixed the
issue anyways.

I hacked together a Perl script to pull data from the ElasticSearch
nodes and output it to graphite or cacti. It's attached as
perf_elastic_search.pl.

I'm seeing some interesting behavior from the garbage collection at
the point this timeout occurs. The Graphlot-2h.png shows the garbage
collection time_ms spiking as the heap.used_bytes drops
significantly.
This seems to be a pattern, see Graphlot-24h.png.

It seems once the node has more than 8gb in heap.used_bytes, it
garbage collects itself down to 2gb. However, the GC between these
points is relatively unconcerned by the expanding heap.

Is there a way to force the garbage collection to favor smaller, more
frequent GC than to simply do it all at once every 2-3 hours? This
Garbage collection results in nodes timing out their connections for
6
seconds every 2-3 hours.

I'm not a Java guy, so any nudges in the right direction would be
appreciated.

Thanks,

--
Brad Lhotsky


(Clinton Gormley) #7

Hi Brad

I'll use bigdesk to capture some data today, and come back to you

Attached is a screenshot of bigdesk from the past hour or so

(again, version 0.17.9)

clint


(Shay Banon) #8

First, there is no problem with this size of heap (as mentioned by someone on this thread), people are running ES with 30gb happily. You mentioned you store the index in memory? Whats the config that you use?

On Friday, February 17, 2012 at 12:20 PM, Brad Lhotsky wrote:

Hello,

We're seeing some issues with timeouts lasting 6 seconds in
ElasticSearch during what appear to be massive Garbage Collection
sessions. We have 4 nodes, and 7 shards, the index is only 4.3G
loaded into memory. We've allocated 10gigs of memory on each server
to ES and have followed the recommendations to:

elasticsearch.yml:
bootstrap.mlockall: true

ENV:
ES_MIN_MEM=10g
ES_MAX_MEM=10g

This is a CentOS 5 box, and I've set the /proc/sys/vm/swappiness to 0.
On one box I have completely disabled swap, but as a System
Administrator, this makes me really nervous. Disabling virtual memory
is not a production solution and doesn't appear to have fixed the
issue anyways.

I hacked together a Perl script to pull data from the ElasticSearch
nodes and output it to graphite or cacti. It's attached as
perf_elastic_search.pl (http://perf_elastic_search.pl).

I'm seeing some interesting behavior from the garbage collection at
the point this timeout occurs. The Graphlot-2h.png shows the garbage
collection time_ms spiking as the heap.used_bytes drops significantly.
This seems to be a pattern, see Graphlot-24h.png.

It seems once the node has more than 8gb in heap.used_bytes, it
garbage collects itself down to 2gb. However, the GC between these
points is relatively unconcerned by the expanding heap.

Is there a way to force the garbage collection to favor smaller, more
frequent GC than to simply do it all at once every 2-3 hours? This
Garbage collection results in nodes timing out their connections for 6
seconds every 2-3 hours.

I'm not a Java guy, so any nudges in the right direction would be appreciated.

Thanks,

--
Brad Lhotsky

Attachments:

  • perf_elastic_search.pl

  • Graphlot-2h.png

  • Graphlot-24h.png


(system) #9