How often is cassandra minor compaction running and what trigger it

There are two types of compactions in cassandra. The minor compaction and the major compaction. Today, we are going to look into minor compaction and to understand when is minor compaction kickstarted.

Following are description snippet when you create column family using cassandra-cli.

- max_compaction_threshold: The maximum number of SSTables allowed before a
  minor compaction is forced. Default is 32, setting to 0 disables minor
  compactions.

  Decreasing this will cause minor compactions to start more frequently and
  be less intensive. The min_compaction_threshold and max_compaction_threshold
  boundaries are the number of tables Cassandra attempts to merge together at
  once.

- min_compaction_threshold: The minimum number of SSTables needed
  to start a minor compaction. Default is 4, setting to 0 disables minor
  compactions.

  Increasing this will cause minor compactions to start less frequently and
  be more intensive. The min_compaction_threshold and max_compaction_threshold
  boundaries are the number of tables Cassandra attempts to merge together at
  once.

So minor compaction is trigger automatically by cassandra and major compaction is trigger manually via nodetool compact. But when and what exactly that trigger minor compaction? That's when we need to trace into the codebase.

Because compaction is performed on the column family, thus the minor compaction is trigger in the class ColumnFamilyStore. Two methods that will submit this object for compaction executor to perform the minor compaction, that is during

• method addSSTable() is called.


• method replaceFlushed() is called.

Depend on the compaction strategy chosen for the column family, the default SizeTieredCompactionStrategy which extends AbstractCompactionStrategy and in the super class, which started a single thread to perform this background compaction task. It seem that this optional single threaded task run every five minute.

When the mentioned two method trigger, the object ColumnFamilyStore will be submit to the background for the single thread to perform compaction.

/**
 * Call this whenever a compaction might be needed on the given columnfamily.
 * It's okay to over-call (within reason) since the compactions are single-threaded,
 * and if a call is unnecessary, it will just be no-oped in the bucketing phase.
 */
public Future<Integer> submitBackground(final ColumnFamilyStore cfs)
{
   Callable<Integer> callable = new Callable<Integer>()
   {
        public Integer call() throws IOException
        {
            compactionLock.readLock().lock();
            try
            {
                if (!cfs.isValid())
                    return 0;

                boolean taskExecuted = false;
                AbstractCompactionStrategy strategy = cfs.getCompactionStrategy();
                List<AbstractCompactionTask> tasks = strategy.getBackgroundTasks(getDefaultGcBefore(cfs));
                for (AbstractCompactionTask task : tasks)
                {
                    if (!task.markSSTablesForCompaction())
                         continue;

                    taskExecuted = true;
                    try
                    {
                        task.execute(executor);
                    }
                    finally
                    {
                        task.unmarkSSTables();
                    }
                }
                // newly created sstables might have made other compactions eligible
                if (taskExecuted)
                    submitBackground(cfs);
            }
            finally
            {
                compactionLock.readLock().unlock();
            }
            return 0;
        }
    };
    return executor.submit(callable);
}

Notice that when method getBackgroundTasks is called in submitBackground(), the min_compaction_threshold and max_compaction_threshold which you set in the column family is called here to determine if condition min_compaction_threshold is met and max_compaction_threshold.

From the experience, I don't know why datastax does not recommend major compaction via nodetool, maybe because the I/O and heap usage spike and may impair the node request and response but for me, when the node load goes beyond like 500GB, then there maybe be some stale data left in the big sstables, so it might not be a really such a bad idea to kickstart major compaction if the stale data can be removed and bring down the node load.

Last but not least, if you learn something and would like to contribute back, please go to our donation page.