You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Boicehuang (Jira)" <ji...@apache.org> on 2022/04/18 08:06:00 UTC
[jira] [Created] (LUCENE-10519) ThreadLocal.remove under G1GC takes 100% CPU
Boicehuang created LUCENE-10519:
-----------------------------------
Summary: ThreadLocal.remove under G1GC takes 100% CPU
Key: LUCENE-10519
URL: https://issues.apache.org/jira/browse/LUCENE-10519
Project: Lucene - Core
Issue Type: Bug
Components: core/other
Affects Versions: 8.11.1, 8.10.1, 8.9
Environment: Elasticsearch v7.16.0
OpenJDK v11
Reporter: Boicehuang
h2. Problem
----
There is a single ThreadLocalMap stored for each thread, which all ThreadLocals share, and that master map only periodically purges stale entries. When we close a CloseableThreadLocal, we only take care of the current thread right now, others will be
taken care of via the WeakReferences. Under G1GC, the WeakReferences of other threads may not be reclaimed even after several rounds of mix-GC. The ThreadLocalMap may grow very large, it can take an arbitrarily long amount of CPU and time to iterate the things you had stored in it.
Hot thread of elasticsearch:
{code:java}
::: {xxxxxxxxx}{lCj7LcVnT328KHcJRd57yg}{WPiNCbk0R0SIKxg4-w3wew}{xxxxxxxx}{xxxxxxxx}
Hot threads at 2020-04-12T05:25:10.224Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:
105.3% (526.5ms out of 500ms) cpu usage by thread 'elasticsearch[xxxxxxxx][bulk][T#31]'
10/10 snapshots sharing following 34 elements
java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntry(ThreadLocal.java:627)
java.lang.ThreadLocal$ThreadLocalMap.remove(ThreadLocal.java:509)
java.lang.ThreadLocal$ThreadLocalMap.access$200(ThreadLocal.java:308)
java.lang.ThreadLocal.remove(ThreadLocal.java:224)
java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:426)
java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1349)
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881)
org.elasticsearch.common.util.concurrent.ReleasableLock.close(ReleasableLock.java:49)
org.elasticsearch.index.engine.InternalEngine.$closeResource(InternalEngine.java:356)
org.elasticsearch.index.engine.InternalEngine.delete(InternalEngine.java:1272)
org.elasticsearch.index.shard.IndexShard.delete(IndexShard.java:812)
org.elasticsearch.index.shard.IndexShard.applyDeleteOperation(IndexShard.java:779)
org.elasticsearch.index.shard.IndexShard.applyDeleteOperationOnReplica(IndexShard.java:750)
org.elasticsearch.action.bulk.TransportShardBulkAction.performOpOnReplica(TransportShardBulkAction.java:623)
org.elasticsearch.action.bulk.TransportShardBulkAction.performOnReplica(TransportShardBulkAction.java:577) {code}
h2. Solution
----
This bug does not reproduce under CMS. It can be reproduced always.
In fact we don't need to store entry twice in the hardRefs And ThreadLocals. Remove ThreadLocal from CloseableThreadLocal so that we would not be affected by the serious flaw of Java's built-in ThreadLocal. I would like to provide a patch to fix it if needed.
h2. Related issues
----
[https://github.com/elastic/elasticsearch/issues/56766]
[https://discuss.elastic.co/t/indexing-performance-degrading-over-time/40229/44]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org