Looks like a CASSANDRA-6405 (replicate on write is the counter tp). Upgrade to the latest 2.1 version and let us know if he situation improves.
Major compactions are usually a bad idea by the way. Do you really want one huge sstable? On Jul 1, 2015 10:03 AM, "Jayapandian Ponraj" <pandian...@gmail.com> wrote: > HI I have a 6 node cluster and I ran a major compaction on node 1 but > I found that the load reached very high levels on node 2. Is this > explainable? > > Attaching tpstats and metrics: > > cassandra-2 ~]$ nodetool tpstats > Pool Name Active Pending Completed Blocked > All time blocked > MutationStage 0 0 185152938 0 > 0 > ReadStage 0 0 1111490 0 > 0 > RequestResponseStage 0 0 168660091 0 > 0 > ReadRepairStage 0 0 21247 0 > 0 > ReplicateOnWriteStage 32 6186 88699535 0 > 7163 > MiscStage 0 0 0 0 > 0 > HintedHandoff 0 1 1090 0 > 0 > FlushWriter 0 0 2059 0 > 13 > MemoryMeter 0 0 3922 0 > 0 > GossipStage 0 0 2246873 0 > 0 > CacheCleanupExecutor 0 0 0 0 > 0 > InternalResponseStage 0 0 0 0 > 0 > CompactionExecutor 0 0 12353 0 > 0 > ValidationExecutor 0 0 0 0 > 0 > MigrationStage 0 0 1 0 > 0 > commitlog_archiver 0 0 0 0 > 0 > AntiEntropyStage 0 0 0 0 > 0 > PendingRangeCalculator 0 0 16 0 > 0 > MemtablePostFlusher 0 0 10932 0 > 0 > > Message type Dropped > READ 49051 > RANGE_SLICE 0 > _TRACE 0 > MUTATION 269 > COUNTER_MUTATION 185 > BINARY 0 > REQUEST_RESPONSE 0 > PAGED_RANGE 0 > READ_REPAIR 0 > > > > Also I saw that the nativetransportreqests was 23 in active and 23 in > pending, I found this in opscenter. > > > Any settings i can make to keep the load under control? > Appreciate any help.. Thanks >
