At any given moment at least half of those threads are in the following state; what does it represent?
Name: ROW-READ-STAGE:6 State: WAITING on java.util.concurrent.locks.abstractqueuedsynchronizer$conditionobj...@fea6030 Total blocked: 44 Total waited: 479 Stack trace: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) java.lang.Thread.run(Thread.java:619) On Mon, May 17, 2010 at 12:53 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > On Sun, May 16, 2010 at 2:52 PM, Joost Ouwerkerk <jo...@openplaces.org> > wrote: > > Meanwhile. I'm still getting TimedOutException errors when mapping this > > 30-million row table, even when retrieving no data at all. It looks like > it > > is related to disk activity on "hot" nodes (when the same cassandra node > has > > to handle many concurrent requests for adjacent range slices). Using 0.7 > > trunk branch doesn't appear to alleviate it. CPU load is at about 25% > when > > this happens. Is there some kind of synchronization that might prevent > the > > same file from being scanned by multiple threads? > > No, but there's only `concurrent_reads` threads serving reads and if > you have a lot of ops in the queue ahead of you then that would do it. > (pending tasks in row stage under cassandra.concurrent jmx.) > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
