snapshots.db

Update: the file grew to 1.62 GB overnight. I found a way to exclude the contents of the /private/var/db/systemstats/ folder in a SuperDuper clone. The cloned drive starts fine and begins repopulating the systemstats folder with files like

current_build

current_boot_uuid

E9FEFFF3-6F56-4FFD-82CB-0FB294678874.boot.events.HIiYCX.stats

E9FEFFF3-6F56-4FFD-82CB-0FB294678874.powerd.events.T812iB.stats

E9FEFFF3-6F56-4FFD-82CB-0FB294678874.system_events.events.3otafr.stats

E9FEFFF3-6F56-4FFD-82CB-0FB294678874.system_events.periodic.Z0dED4.stats

...

And, of course:

snapshots.db

snapshots.db-shm

snapshots.db-wal

Then the snapshots.db file grows progressively. It persists with shutdown or restart. I see no reason to have what appears to be a large and infinitely growing system statistics database file eating up disk space...

Any ideas?

Thanks

Update:

After snapshots.db reached 1.74 GB I deleted the contents of /private/var/db/systemstats/ while booted from a cloned drive. The main drive then booted normally with an empty systemstats folder and began repopulating that folder as above. After only one day, it has grown to 370 MB, almost all due to the progressively expanding snapshots.db file. Before doing this I had noticed that the various .stats files in the folder are automatically trimmed to the last four days, but the snapshots.db file seems to just keep growing. I do not know if the system would eventually limit its size, but 300 MB is already too large for such an unneccessary system-generated file. Perhaps some users would be interested in having this file to examine historical power usage or other statistics, but I am not. Maybe this should be optional? It could become a critical issue for users who install OS X on a small partition.

Short of intermittently deleting the systemstats folder contents, is there anyway to prevent this progressive disk space consuming behaviour?

Thanks

This was not my original issue per se. TimeMacine and cloning worked fine. SMART status is OK. There may be something else wrong with your system.

My only problem was that snapshots.db grew excessively large. After deleting it along with all other contents of /private/var/db/systemstats as well as all folders named com.apple.launchd.peruser.* in /private/var/log/ while booted from an external drive and then rebooting the main drive, the involved files.folders were automatically recreated and the problem has not yet reappeared. My current snapshots.db file has reached 190 MB, but does not seem to be growing further.

Regards,

Update: After restoring my system from a Time Machine backup, which resets the systemstats folder contents and snapsots.db file to zero, my snapshots.db file is again growing out of control - currently 2.12 GB!

Have filed a bug report with apple.

Here is how I solved my large snapshots.db problem. First, I tracked it to an excessive number of ‘freelist pages’. The snapshots.db file is an sqlite database. It accumulates ‘pages’ of system statistics for several days and then begins deleting old entries, but those pages are not actually deleted and returned to free disk space. Instead, they are kept in the file as freelist pages to be filled with subsequent data. Thus, the file doesn’t shrink as old entries are deleted. In my case, the file grew to over 2 GB. At some equlibrium point it stops growing because there are always enough freelist pages to accomodate new entries.

You can find out the number of freelist pages by typing this command in the terminal from an administrator account (you’ll have to enter your password when prompted):

sudo sqlite3 /private/var/db/systemstats/snapshots.db "PRAGMA freelist_count;"

This returned > 400000 in my case. If the same is true for your situation, then the following procedures might help:

A temporary solution to ‘vacuum’ the freelist pages was contributed by Linc Davis (https://discussions.apple.com/thread/5735772):

sudo sqlite3 /private/var/db/systemstats/snapshots.db "vacuum;"

This works, but the file then just resumes growing. The command can be repeated when the file seems too big, but I grew tired of monitoring it.

A permanent solution is to set the snapsjots.db file to ‘auto_vacuum’ mode, in which freelist pages are automatically returned to free disk space as old data is deleted. To do this, you vaccum the file, then set auto_vacuum=1 and then immediately vaccum it again. Once this is done, you no longer have to manually vaccum. My snapshots.db file now varies between 0 - 300 MB, depending on recent computer use. The procedure I used follows:

In the terminal, type

sudo sqlite3 /private/var/db/systemstats/snapshots.db

This opens the sqlite3 command line interface. You should see something like:

SQLite version 3.7.13 2012-07-17 17:46:21

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite>

Now, at the sqlite> prompt, type:

VACUUM; PRAGMA auto_vacuum=1; VACUUM;

The process may take a while to complete and will end by returning the sqlite> prompt. You can then check the freelist page count and auto_vacuum status by typing:

PRAGMA freelist_count; PRAGMA auto_vacuum;

This should return:

0

1

sqlite>

You can then exit the sqlite command line interface with ctl-D. You can learn more about sqlite commands at: https://sqlite.org and https://www.sqlite.org/sqlite.html

Good Luck!

Snapshots are different than the snapshots.db file, which is a new implementation in Mavericks for tracking system statistics.

Regards

Yes, the system statistics it tracks have to do with energy. Since I have zero interest in that, I dislike having > 2 GB disk space commitment to it. According to Apple its supposed to be 70 - 150 MB. Simply turning the auto_vacuum mode keeps it in its intended size range automatically and otherwise lets it do its stuff normally, so that was the solution that appealed to me.

Regards

I'm pleased to report that this problem appears to have been resolved in Yosemite, at least on my system - the snapshots.db file now stays a manageable size (around 200-300 MB, occasionally more or leas, depending on computer activity) automatically and I no longer have to set 'auto_vacuum'.