Dear William,
As Luciano mentioned previously, could you check the snapshot folder?
To know where the data is stored, check the value of data_file_directories in
the cassandra.yaml file.
By default, it is located in the $CASSANDRA_HOME/data/data directory.
You can then browse all snapshots with the command: find . -iname snapshots
-exec du -h {} \;
Best regards,
Fabien
De : William Crowell via user
Envoyé : vendredi, 14 mars 2025 10:51
À : user@cassandra.apache.org
Cc : William Crowell
Objet : Re: Increased Disk Usage After Upgrading From Cassandra 3.x.x to 4.1.3
PRUDENCE. Ce message provient d'un expéditeur externe à l'Etat. Ne cliquez sur
les liens ou n'ouvrez les pièces jointes que si vous faites entière confiance à
cet expéditeur.
Stéphane
We do not do any repairs and maybe that is the issue. We do a once weekly
compaction.
Regards,
William Crowell
From: crystallo...@gmail.com
mailto:crystallo...@gmail.com>>
Date: Friday, March 14, 2025 at 5:35 AM
To: user@cassandra.apache.org
mailto:user@cassandra.apache.org>>
Subject: Re: Increased Disk Usage After Upgrading From Cassandra 3.x.x to 4.1.3
You don't often get email from
crystallo...@gmail.com. Learn why this is
important
Hi
Have you some use of incremental repair ?
Kind regards
Stéphane
Le 14/03/2025 à 03:37, Luciano Greiner a écrit :
As much as sstable files are immutable, there are operations that can delete
them, such as compactions (merges) and upgrades (upgradesstables - you possibly
ran this in your upgrade).
Even though snapshots are hardlinks, when the original sstable file get
deleted, it will actually behave like a copy of the old file as it will keep
pointing to the old inodes.
Luciano Greiner
On Thu, Mar 13, 2025 at 11:23 PM William Crowell
mailto:wcrow...@perforce.com>> wrote:
Luciano,
That is very possible. Any reasons why the increased disk space from version 3
to 4? Did anything in particular change that would affect disk space?
Thank you for your reply,
William Crowell
From: Luciano Greiner
mailto:luciano.grei...@gmail.com>>
Date: Thursday, March 13, 2025 at 10:21 PM
To: user@cassandra.apache.org
mailto:user@cassandra.apache.org>>
Cc: William Crowell mailto:wcrow...@perforce.com>>
Subject: Re: Increased Disk Usage After Upgrading From Cassandra 3.x.x to 4.1.3
You don't often get email from
luciano.grei...@gmail.com. Learn why this is
important
Haven't you forgot to clean some snapshots ?
Luciano Greiner
On Thu, Mar 13, 2025 at 11:18 PM William Crowell via user
mailto:user@cassandra.apache.org>> wrote:
Hi,
Is this mailing list still active?
Thanks.
From: William Crowell via user
mailto:user@cassandra.apache.org>>
Date: Wednesday, March 12, 2025 at 4:42 PM
To: user@cassandra.apache.org
mailto:user@cassandra.apache.org>>
Cc: William Crowell mailto:wcrow...@perforce.com>>
Subject: Re: Increased Disk Usage After Upgrading From Cassandra 3.x.x to 4.1.3
I also forgot to include we do compaction once a week.
Hi. A few months ago, I upgraded a single node Cassandra instance from version
3 to 4.1.3. This instance is not very large with about 15 to 20 gigabytes of
data on version 3, but after the update it has went substantially up to over
100gb. I do a compaction once a week and take a snapshot, but with the
increase in data it makes the compaction a much lengthier process. I also did
a sstableupate as part of the upgrade. Any reason for the increased size of
the database on the file system?
I am using the default STCS compaction strategy. My “nodetool cfstats” on a
heavily used table looks like this:
Keyspace :
Read Count: 48089
Read Latency: 12.52872569610514 ms
Write Count: 1616682825
Write Latency: 0.0067135265490310386 ms
Pending Flushes: 0
Table: sometable
SSTable count: 13
Old SSTable count: 0
Space used (live): 104005524836
Space used (total): 104005524836
Space used by snapshots (total): 0
Off heap memory used (total): 116836824
SSTable Compression Ratio: 0.566085855123187
Number of partitions (estimate): 14277177
Memtable cell count: 81033
Memtable data size: 13899174
Memtable off heap memory used: 0
Memtable switch count: 13171
Local read count: 48089
Local read latency: NaN ms
Local write count: 1615681213
Local write latency: 0.005 ms
Pending flushes: 0
Percent repaired: 0.0
Bytes repaired: 0.000KiB
