Hi, Robert,
I think I found the cause of the too many compactions. I used jmap to dump
the heap and used Eclipse memory analyzer plugin to extract the heap.
In previous reply, It shows the there are too many pending jobs in the
Blocking queue. I checked the cf of the compaction task object. There
Interesting, maybe it worths filing a JIRA. Empty tables should not slow
down compaction of other tables
On Sat, Jan 16, 2016 at 10:33 AM, Shuo Chen wrote:
> Hi, Robert,
>
> I think I found the cause of the too many compactions. I used jmap to dump
> the heap and used Eclipse memory analyzer plu
Hi,
Recently I saw some strange behavior on one of the nodes of a 3-node
cluster. A while ago I created a table and put some data (about 150M) in it
for testing. A few days ago I started to import full data into that table
using normal cql INSERT statements. As soon as inserting started, one node
"As soon as inserting started, one node started non-stop full GC. The other
two nodes were totally fine"
Just a guest, how did you insert data ? Did you use Batch statements ?
On Sat, Jan 16, 2016 at 10:12 PM, Kai Wang wrote:
> Hi,
>
> Recently I saw some strange behavior on one of the nodes of
DuyHai,
Nothing wrong on the logs either.
> nodetool tpstats
> Pool NameActive Pending Completed Blocked All
> time blocked
> MutationStage 0 0 11464 0
> 0
> ViewMutationStage 0
Hi
We are on 2.0.14,RF=3 in a 3 node cluster. We use repair -pr . Recently, we
observed that repair -pr for all nodes fails if a node is down. Then I found
the JIRA
https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-2290
where an intentional decision was taken to abort the re
