You really need to upgrade from 0.8.0 to fix that. Restarting won't help, much (you'll get exactly one compaction against a given sstable, before it stops working again).
On Mon, Aug 1, 2011 at 2:34 PM, myreasoner <myreaso...@gmail.com> wrote: > All compaction related settings in the yaml were untouched. The fingerprint > column family has been populated three days ago and the cpu/disk usage were > pretty low. I'd think Cassandra will silently start the compaction thread > on my behalf and try to preserve the min/max thresholds, rather than waiting > for a major compaction order from nodetool explicitly. > > Anyway, I did a major compaction on all 5 nodes almost at the same time. 4 > of them came back after a few hours, but one of the 5 nodes still has a lot > of pending ones: > > cassandra/bin/nodetool -h localhost compactionstats > pending tasks: 76 > > And the uptime is very light. > 14:31:44 up 30 days, 22:11, 4 users, load average: 0.29, 0.58, 0.58 > > Some reply suggested this is a broken compaction. I will wait for a few > hours and restart that node if nothing changes. > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Read-latency-is-over-1-minute-on-a-column-family-with-400-000-rows-tp6639649p6642279.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
