Cache cleaner in hot threads

Elastic Stack Elasticsearch
1

I'm still doing performance work and I keep seeing the CacheCleaner pop up
[1]. I don't know how much of an effect its actually having, but I imagine
its something.

It looks like entries in the cache get queued for deletion both by cache
clear commands and by readers closing. Would it make sense to forgo
removing entries when the readers close and let the LRU policy clean it up?

Nik

[1]:
100.4% (502.1ms out of 500ms) cpu usage by thread
'elasticsearch[elastic1001][generic][T#73]'
2/10 snapshots sharing following 5 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.remove(LocalCache.java:4353)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:186)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
4/10 snapshots sharing following 8 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.nextInTable(LocalCache.java:4306)

org.elasticsearch.common.cache.LocalCache$HashIterator.advance(LocalCache.java:4271)

org.elasticsearch.common.cache.LocalCache$HashIterator.nextEntry(LocalCache.java:4346)

org.elasticsearch.common.cache.LocalCache$KeyIterator.next(LocalCache.java:4362)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:183)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
4/10 snapshots sharing following 7 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.advance(LocalCache.java:4271)

org.elasticsearch.common.cache.LocalCache$HashIterator.nextEntry(LocalCache.java:4346)

org.elasticsearch.common.cache.LocalCache$KeyIterator.next(LocalCache.java:4362)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:183)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd0p8QT5LadzeoinXJdQTyDzNrcaua95UON8zjVaY%3D1cMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

2

I have the same issue. The configuration is : Two nodes, we sent them some
data (1m) and now they are running at 200%/400% around

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:183)
for hours. (ES version 1.0.1)

Le vendredi 18 avril 2014 20:26:09 UTC+2, Nikolas Everett a écrit :

I'm still doing performance work and I keep seeing the CacheCleaner pop up
[1]. I don't know how much of an effect its actually having, but I imagine
its something.

It looks like entries in the cache get queued for deletion both by cache
clear commands and by readers closing. Would it make sense to forgo
removing entries when the readers close and let the LRU policy clean it up?

Nik

[1]:
100.4% (502.1ms out of 500ms) cpu usage by thread
'elasticsearch[elastic1001][generic][T#73]'
2/10 snapshots sharing following 5 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.remove(LocalCache.java:4353)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:186)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
4/10 snapshots sharing following 8 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.nextInTable(LocalCache.java:4306)

org.elasticsearch.common.cache.LocalCache$HashIterator.advance(LocalCache.java:4271)

org.elasticsearch.common.cache.LocalCache$HashIterator.nextEntry(LocalCache.java:4346)

org.elasticsearch.common.cache.LocalCache$KeyIterator.next(LocalCache.java:4362)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:183)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)
4/10 snapshots sharing following 7 elements

org.elasticsearch.common.cache.LocalCache$HashIterator.advance(LocalCache.java:4271)

org.elasticsearch.common.cache.LocalCache$HashIterator.nextEntry(LocalCache.java:4346)

org.elasticsearch.common.cache.LocalCache$KeyIterator.next(LocalCache.java:4362)

org.elasticsearch.indices.cache.filter.IndicesFilterCache$ReaderCleaner$1.run(IndicesFilterCache.java:183)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:724)

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/76076d38-e928-4eae-aa04-aff92e5c8983%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.