Thanks Rob. 1) Cassandra version is 2.0.12.
2) Interesting. Looking at JMX org.apache.cassandra.db -> ColumnFamilies -> trackcontent -> track_content -> Attributes, I get: LiveDiskSpaceUsed: 17788740448, i.e. ~17GB LiveSSTableCount: 3 TotalDiskSpaceUsed: 55714084629, i.e. ~55GB So it obviously knows about the extra disk space even though the "live" space looks correct. I couldn't find anything to identify the actual files though. 3) So that was even more interesting. After restarting the cassandra daemon, the sstables were not deleted and now the same JMX attributes are: LiveDiskSpaceUsed: 55681040579, i.e. ~55GB LiveSSTableCount: 8 TotalDiskSpaceUsed: 55681040579, i.e. ~55GB So some of my non-live tables are back live again, and obviously some of the big ones!! Jef On 6 July 2015 at 20:26, Robert Coli <rc...@eventbrite.com> wrote: > On Mon, Jul 6, 2015 at 7:25 AM, Jeff Williams <je...@wherethebitsroam.com> > wrote: > >> So it appears that the 10 sstables that were compacted >> to >> /var/lib/cassandra/data/trackcontent/track_content/trackcontent-track_content-jb-57372 >> are still sitting around, with a couple of them being very large! >> Any ideas for what I can check? Can I just delete the old sstables? (I'm >> guessing not). >> > > 1) What version of Cassandra? > > 2) There are JMX methods in some versions to identify which files are live > in the data dir, you could try to use those to see if those files are live. > Does "load" seem to show that they are live from the perspective of > Cassandra? > > 3) If they are not live, restarting the Cassandra daemon on the node will > likely result in them being deleted. > > =Rob > >
