Блог

Главная - Вопросы по программированию - Почему один из моих потоков Cassandra занимает 100% моего процессора?

Почему один из моих потоков Cassandra занимает 100% моего процессора?

#cassandra #jvm #datastax #datastax-enterprise #datastax-startup

#кассандра #jvm #datastax #datastax-enterprise #datastax-запуск

Вопрос:

Один из моих потоков Cassandra занимает 100% моего процессора. Я не знаю, что делает этот поток, а также почему он работает на полную мощность? Должен ли я предоставить ему больше ресурсов или уменьшить размер данных и т. Д.? Вы можете увидеть это в идентификаторе потока 14809.

Я подключил свой вывод Htop.

Спасибо за вашу помощь.

введите описание изображения здесь

Редактировать:

Я перезапустил сервер, поэтому, возможно, указанный выше идентификатор потока не совпадает с указанным ниже стеком потоков, но поток тот же. Это мой связанный стек потоков:

 Attaching to process ID 6364, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.102-b14
Deadlock Detection:

No deadlocks found.

Thread 9955: (state = IN_JAVA)
 - java.util.HashMap$HashIterator.nextNode() @bci=95, line=1441 (Compiled frame; information may be imprecise)
 - java.util.HashMap$KeyIterator.next() @bci=1, line=1461 (Compiled frame)
 - com.google.common.collect.Iterators$3.next() @bci=4, line=163 (Compiled frame)
 - java.util.AbstractCollection.contains(java.lang.Object) @bci=40, line=106 (Compiled frame)
 - com.google.common.base.Predicates$InPredicate.apply(java.lang.Object) @bci=5, line=497 (Compiled frame)
 - com.google.common.base.Predicates$NotPredicate.apply(java.lang.Object) @bci=5, line=312 (Compiled frame)
 - com.google.common.base.Predicates$CompositionPredicate.apply(java.lang.Object) @bci=14, line=536 (Compiled frame)
 - com.google.common.collect.Iterators$7.computeNext() @bci=27, line=647 (Compiled frame)
 - com.google.common.collect.AbstractIterator.tryToComputeNext() @bci=9, line=143 (Compiled frame)
 - com.google.common.collect.AbstractIterator.hasNext() @bci=61, line=138 (Compiled frame)
 - com.google.common.collect.TransformedIterator.hasNext() @bci=4, line=43 (Compiled frame)
 - java.util.AbstractCollection.addAll(java.util.Collection) @bci=10, line=343 (Compiled frame)
 - java.util.HashSet.<init>(java.util.Collection) @bci=10, line=118 (Compiled frame)
 - com.google.common.collect.Sets.newHashSet(java.lang.Iterable) @bci=15, line=218 (Interpreted frame)
 - com.datastax.bdp.hadoop.cfs.compaction.CFSCompactionStrategy.removeKeys(java.lang.Iterable) @bci=116, line=337 (Interpreted frame)
 - com.datastax.bdp.hadoop.cfs.compaction.CFSCompactionStrategy.add(org.apache.cassandra.io.sstable.SSTableReader, boolean) @bci=81, line=293 (Compiled frame)
 - com.datastax.bdp.hadoop.cfs.compaction.CFSCompactionStrategy.handleNotification(org.apache.cassandra.notifications.INotification, java.lang.Object) @bci=18, line=227 (Interpreted frame)
 - org.apache.cassandra.db.DataTracker.notifyAdded(org.apache.cassandra.io.sstable.SSTableReader) @bci=43, line=531 (Interpreted frame)
 - org.apache.cassandra.db.DataTracker.replaceFlushed(org.apache.cassandra.db.Memtable, org.apache.cassandra.io.sstable.SSTableReader) @bci=130, line=179 (Interpreted frame)
 - org.apache.cassandra.db.compaction.AbstractCompactionStrategy.replaceFlushed(org.apache.cassandra.db.Memtable, org.apache.cassandra.io.sstable.SSTableReader) @bci=9, line=234 (Interpreted frame)
 - org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(org.apache.cassandra.db.Memtable, org.apache.cassandra.io.sstable.SSTableReader) @bci=6, line=1540 (Interpreted frame)
 - org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow() @bci=73, line=336 (Interpreted frame)
 - org.apache.cassandra.utils.WrappedRunnable.run() @bci=1, line=28 (Interpreted frame)
 - com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(java.lang.Runnable) @bci=5, line=297 (Interpreted frame)
 - org.apache.cassandra.db.ColumnFamilyStore$Flush.run() @bci=163, line=1134 (Interpreted frame)
 - java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 (Compiled frame)
 - java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame)
 - java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 (Compiled frame)
 - java.util.concurrent.FutureTask.run() @bci=42, line=266 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1142 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 (Compiled frame)
 - java.lang.Thread.run() @bci=11, line=745 (Compiled frame)

Комментарии:

1. Я бы предложил взять дамп потока jstack PID >> mydumps.tdump и начать анализ оттуда.

2. @xmas79 Я уже подключил стек потоков, не могли бы вы взглянуть? Я не знаю, как это решить. Спасибо

3. Потому что он выполняет код, который был тщательно написан, чтобы не тратить ресурсы впустую, часто блокируя на длительные периоды? Что заставляет вас думать, что это проблема?

4. предположение, если он застрял в этом и нескольких смежных методах: не потокобезопасная структура данных, повреждаемая параллельным доступом и образующая цикл внутри

5. Я говорю, что HashMap не является потокобезопасным. Если вы (или код cassandra) используете его небезопасным образом, он может быть поврежден таким образом, что его итератор никогда не завершается. Но это всего лишь предположение, потому что для проверки потребуется больше, чем один стек потоков.