Hi Alain, Thanks for your response :)
> A replication factor of 3 for a 3 node cluster does not balance the load: > since you ask for 3 copies of the data (rf=3) on 3 nodes cluster, > each node will have a copy of the data and you are overloading all nodes. > May be you should try with a rf = 2 or add nodes to your cluster ? > I agree that with a RF=3 and 3 nodes, all nodes should have almost the same load and i'm fine with that, this is what I want. My problem is that this isn't the case, one node get a lot of CPU usage compared to the others : node 1 : load average = 17 node 2 : load average = 3 node 3 : load average = 3 Funny fact : If I stop node 1, the two others nodes have the same load as before. So this seems not to be a problem of "load is big on node1 because all request goes to this node" : requests are now spread only amongst node 2 and 3 and they are not overwhelm as node 1 was.. Instead, I suspect hardware problem on node 1.. > "working" ? How can I list connections on a node ? >> >> For a 3.x (I think also 2.x) you can trace requests at the query level > with enableTracing() method. > something like : (uncomment the line with .enableTracing() ) > > session.execute( boundedInsertEventStatement.bind( aggregateId, > aggregateType, eventType, payload ) > .setConsistencyLevel(ConsistencyLevel.ONE) > //.enableTracing() > ); > see the doc for other classes and tracing or consistency options, > and have a look at nodetool settraceprobability if you cannot change the > code > > The queries and query plans appear in the system_traces.sessions and > system_traces.events tables. It can be very verbose for query plans (events > table), may be you should truncate the sessions and events tables before > running your load (on 3.x tables are truncated on startup) > > I'll take a look, this might be verbose because of the OPS rate (4k) but it can give me info Thanks again > Regards, >> Bastien >> >> > HTH, > -- > best, > Alain >
