[jira] [Commented] (CASSANDRA-6596) Split out outgoing stream throughput within a DC and inter-DC
[ https://issues.apache.org/jira/browse/CASSANDRA-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044558#comment-14044558 ] Thomas Vachon commented on CASSANDRA-6596: -- I second this. It's a huge win for us but we can't go to 2.1 yet Split out outgoing stream throughput within a DC and inter-DC - Key: CASSANDRA-6596 URL: https://issues.apache.org/jira/browse/CASSANDRA-6596 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jeremy Hanna Assignee: Vijay Priority: Minor Fix For: 2.1 beta1 Attachments: 0001-CASSANDRA-6596.patch Currently the outgoing stream throughput setting doesn't differentiate between when it goes to another node in the same DC and when it goes to another DC across a potentially bandwidth limited link. It would be nice to have that split out so that it could be tuned for each type of link. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-4492) HintsColumnFamily compactions hang when using multithreaded compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534973#comment-13534973
]
Thomas Vachon commented on CASSANDRA-4492:
--
{quote}Looking at the code it seems there are two places where
HintedHandoffManager calls a user defined compact() for all sstable{quote}
Well that would explain why everytime I start and I get hints, I get every
sstable compacted
HintsColumnFamily compactions hang when using multithreaded compaction
--
Key: CASSANDRA-4492
URL: https://issues.apache.org/jira/browse/CASSANDRA-4492
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.11
Reporter: Jason Harvey
Priority: Minor
Attachments: jstack.txt
Running into an issue on a 6 node ring running 1.0.11 where HintsColumnFamily
compactions often hang indefinitely when using multithreaded compaction.
Nothing of note in the logs. In some cases, the compaction hangs before a tmp
sstable is even created.
I've wiped out every hints sstable and restarted several times. The issue
always comes back rather quickly and predictably. The compactions sometimes
complete if the hint sstables are very small. Disabling multithreaded
compaction stops this issue from occurring.
Compactions of all other CFs seem to work just fine.
This ring was upgraded from 1.0.7. I didn't keep any hints from the upgrade.
I should note that the ring gets a huge amount of writes, and as a result the
HintedHandoff rows get be quite wide. I didn't see any large-row compaction
notices when the compaction was hanging (perhaps the bug was triggered by
incremental compaction?). After disabling multithreaded compaction, several
of the rows that were successfully compacted were over 1GB.
Here is the output I see from compactionstats where a compaction has hung.
The 'bytes compacted' column never changes.
{code}
pending tasks: 1
compaction typekeyspace column family bytes compacted
bytes total progress
Compaction systemHintsColumnFamily 268082
464784758 0.06%
{code}
The hung thread stack is as follows: (full jstack attached, as well)
{code}
CompactionExecutor:37 daemon prio=10 tid=0x063df800 nid=0x49d9
waiting on condition [0x7eb8c6ffa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x00050f2e0e58 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:329)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:281)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:147)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:126)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:101)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:141)
at
org.apache.cassandra.db.compaction.CompactionManager$7.call(CompactionManager.java:395)
at
[jira] [Comment Edited] (CASSANDRA-4492) HintsColumnFamily compactions hang when using multithreaded compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534973#comment-13534973
]
Thomas Vachon edited comment on CASSANDRA-4492 at 12/18/12 3:35 PM:
{quote}Looking at the code it seems there are two places where
HintedHandoffManager calls a user defined compact() for all sstable{quote}
Well that would explain why everytime I restart and I get hints, I get every
sstable compacted
was (Author: tvachon):
{quote}Looking at the code it seems there are two places where
HintedHandoffManager calls a user defined compact() for all sstable{quote}
Well that would explain why everytime I start and I get hints, I get every
sstable compacted
HintsColumnFamily compactions hang when using multithreaded compaction
--
Key: CASSANDRA-4492
URL: https://issues.apache.org/jira/browse/CASSANDRA-4492
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.11
Reporter: Jason Harvey
Priority: Minor
Attachments: jstack.txt
Running into an issue on a 6 node ring running 1.0.11 where HintsColumnFamily
compactions often hang indefinitely when using multithreaded compaction.
Nothing of note in the logs. In some cases, the compaction hangs before a tmp
sstable is even created.
I've wiped out every hints sstable and restarted several times. The issue
always comes back rather quickly and predictably. The compactions sometimes
complete if the hint sstables are very small. Disabling multithreaded
compaction stops this issue from occurring.
Compactions of all other CFs seem to work just fine.
This ring was upgraded from 1.0.7. I didn't keep any hints from the upgrade.
I should note that the ring gets a huge amount of writes, and as a result the
HintedHandoff rows get be quite wide. I didn't see any large-row compaction
notices when the compaction was hanging (perhaps the bug was triggered by
incremental compaction?). After disabling multithreaded compaction, several
of the rows that were successfully compacted were over 1GB.
Here is the output I see from compactionstats where a compaction has hung.
The 'bytes compacted' column never changes.
{code}
pending tasks: 1
compaction typekeyspace column family bytes compacted
bytes total progress
Compaction systemHintsColumnFamily 268082
464784758 0.06%
{code}
The hung thread stack is as follows: (full jstack attached, as well)
{code}
CompactionExecutor:37 daemon prio=10 tid=0x063df800 nid=0x49d9
waiting on condition [0x7eb8c6ffa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x00050f2e0e58 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:329)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:281)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:147)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:126)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:101)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
at
[jira] [Commented] (CASSANDRA-4492) HintsColumnFamily compactions hang when using multithreaded compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529251#comment-13529251
]
Thomas Vachon commented on CASSANDRA-4492:
--
[~jbellis] no I can't. We turned off MT compaction and they have been
compacted away.
HintsColumnFamily compactions hang when using multithreaded compaction
--
Key: CASSANDRA-4492
URL: https://issues.apache.org/jira/browse/CASSANDRA-4492
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.11
Reporter: Jason Harvey
Priority: Minor
Attachments: jstack.txt
Running into an issue on a 6 node ring running 1.0.11 where HintsColumnFamily
compactions often hang indefinitely when using multithreaded compaction.
Nothing of note in the logs. In some cases, the compaction hangs before a tmp
sstable is even created.
I've wiped out every hints sstable and restarted several times. The issue
always comes back rather quickly and predictably. The compactions sometimes
complete if the hint sstables are very small. Disabling multithreaded
compaction stops this issue from occurring.
Compactions of all other CFs seem to work just fine.
This ring was upgraded from 1.0.7. I didn't keep any hints from the upgrade.
I should note that the ring gets a huge amount of writes, and as a result the
HintedHandoff rows get be quite wide. I didn't see any large-row compaction
notices when the compaction was hanging (perhaps the bug was triggered by
incremental compaction?). After disabling multithreaded compaction, several
of the rows that were successfully compacted were over 1GB.
Here is the output I see from compactionstats where a compaction has hung.
The 'bytes compacted' column never changes.
{code}
pending tasks: 1
compaction typekeyspace column family bytes compacted
bytes total progress
Compaction systemHintsColumnFamily 268082
464784758 0.06%
{code}
The hung thread stack is as follows: (full jstack attached, as well)
{code}
CompactionExecutor:37 daemon prio=10 tid=0x063df800 nid=0x49d9
waiting on condition [0x7eb8c6ffa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x00050f2e0e58 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:329)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:281)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:147)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:126)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:101)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:141)
at
org.apache.cassandra.db.compaction.CompactionManager$7.call(CompactionManager.java:395)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
[jira] [Commented] (CASSANDRA-4492) HintsColumnFamily compactions hang when using multithreaded compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529284#comment-13529284
]
Thomas Vachon commented on CASSANDRA-4492:
--
No, update heavy though
HintsColumnFamily compactions hang when using multithreaded compaction
--
Key: CASSANDRA-4492
URL: https://issues.apache.org/jira/browse/CASSANDRA-4492
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.11
Reporter: Jason Harvey
Priority: Minor
Attachments: jstack.txt
Running into an issue on a 6 node ring running 1.0.11 where HintsColumnFamily
compactions often hang indefinitely when using multithreaded compaction.
Nothing of note in the logs. In some cases, the compaction hangs before a tmp
sstable is even created.
I've wiped out every hints sstable and restarted several times. The issue
always comes back rather quickly and predictably. The compactions sometimes
complete if the hint sstables are very small. Disabling multithreaded
compaction stops this issue from occurring.
Compactions of all other CFs seem to work just fine.
This ring was upgraded from 1.0.7. I didn't keep any hints from the upgrade.
I should note that the ring gets a huge amount of writes, and as a result the
HintedHandoff rows get be quite wide. I didn't see any large-row compaction
notices when the compaction was hanging (perhaps the bug was triggered by
incremental compaction?). After disabling multithreaded compaction, several
of the rows that were successfully compacted were over 1GB.
Here is the output I see from compactionstats where a compaction has hung.
The 'bytes compacted' column never changes.
{code}
pending tasks: 1
compaction typekeyspace column family bytes compacted
bytes total progress
Compaction systemHintsColumnFamily 268082
464784758 0.06%
{code}
The hung thread stack is as follows: (full jstack attached, as well)
{code}
CompactionExecutor:37 daemon prio=10 tid=0x063df800 nid=0x49d9
waiting on condition [0x7eb8c6ffa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x00050f2e0e58 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:329)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:281)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:147)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:126)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:101)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:141)
at
org.apache.cassandra.db.compaction.CompactionManager$7.call(CompactionManager.java:395)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
[jira] [Commented] (CASSANDRA-4492) HintsColumnFamily compactions hang when using multithreaded compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506806#comment-13506806
]
Thomas Vachon commented on CASSANDRA-4492:
--
This actually is severe. Since they hang, it blocks all schema changes.
HintsColumnFamily compactions hang when using multithreaded compaction
--
Key: CASSANDRA-4492
URL: https://issues.apache.org/jira/browse/CASSANDRA-4492
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.11
Reporter: Jason Harvey
Priority: Minor
Attachments: jstack.txt
Running into an issue on a 6 node ring running 1.0.11 where HintsColumnFamily
compactions often hang indefinitely when using multithreaded compaction.
Nothing of note in the logs. In some cases, the compaction hangs before a tmp
sstable is even created.
I've wiped out every hints sstable and restarted several times. The issue
always comes back rather quickly and predictably. The compactions sometimes
complete if the hint sstables are very small. Disabling multithreaded
compaction stops this issue from occurring.
Compactions of all other CFs seem to work just fine.
This ring was upgraded from 1.0.7. I didn't keep any hints from the upgrade.
I should note that the ring gets a huge amount of writes, and as a result the
HintedHandoff rows get be quite wide. I didn't see any large-row compaction
notices when the compaction was hanging (perhaps the bug was triggered by
incremental compaction?). After disabling multithreaded compaction, several
of the rows that were successfully compacted were over 1GB.
Here is the output I see from compactionstats where a compaction has hung.
The 'bytes compacted' column never changes.
{code}
pending tasks: 1
compaction typekeyspace column family bytes compacted
bytes total progress
Compaction systemHintsColumnFamily 268082
464784758 0.06%
{code}
The hung thread stack is as follows: (full jstack attached, as well)
{code}
CompactionExecutor:37 daemon prio=10 tid=0x063df800 nid=0x49d9
waiting on condition [0x7eb8c6ffa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x00050f2e0e58 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:329)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Deserializer.computeNext(ParallelCompactionIterable.java:281)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:147)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:126)
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:101)
at
org.apache.cassandra.db.compaction.ParallelCompactionIterable$Unwrapper.computeNext(ParallelCompactionIterable.java:88)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
com.google.common.collect.Iterators$7.computeNext(Iterators.java:614)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.db.compaction.CompactionTask.execute(CompactionTask.java:141)
at
org.apache.cassandra.db.compaction.CompactionManager$7.call(CompactionManager.java:395)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
