A cosa serve snapshot.db?

Ad un livello elevato, il file che hai elencato è un file di database binario utilizzato dal sistema operativo per tenere traccia del consumo energetico, delle prestazioni e dei dati di sleep / wake nel tempo. Nonostante la guida generale per non eliminare nulla da / var / db, questo sembra non causare danni ingiustificati se si dovesse cancellare quel file in qualche occasione.

Questo alimenta i nuovi punti di vista sull'uso dell'energia e forse potrebbe aiutare con la diagnostica in caso di problemi e chiedere ad Apple di diagnosticare il sistema.

Il programma che scrive su quel file (così come i file associati in / var / db / systemstats) è systemstatsd .

Puoi usare systemstats --help comando per ottenere maggiori dettagli e leggere da quel file se siete curiosi. La pagina di manuale che ho collegato è la shell di una pagina di manuale e il codice è per lo più non documentato da Apple diverso dalla documentazione che è incorporata nello strumento e accessibile dal chiamarla con l'opzione di aiuto.

In genere non è sicuro cancellare qualcosa in / var / db dato che il sistema potrebbe dipendere dal fatto che i file siano coerenti, ma ho provato a rimuovere tutti i contenuti di tale directory avviando in modalità Utente singolo e il sistema sembra ricreare cose correttamente e gestisci qualsiasi tentativo di ripulire manualmente questi file.

Non consiglierei di cancellare nulla dai sytemstats su un Mac che non sei pronto per cancellare e reinstallare e potresti anche ottenere informazioni strane da Activity Monitor se riesci a ottenere il database e i file di registro in uno stato incoerente. Detto questo, sembra che il sistema sia stato programmato in modo difensivo per gestire le cose che mancano da quella directory e non causare operazioni irregolari in generale se lo si fa comunque.

Ho presentato una segnalazione di bug con Apple per lo stesso problema. Hanno risposto che snapshots.db ha lo scopo di conservare i dati per gli ultimi 3 giorni e raggiungere 70-150 MB sulla maggior parte dei sistemi. Tuttavia, sul mio (OS X 10.9, iMac 27 pollici 2,8 GHz i7, 8 GB RAM) il file snapshots.db corrente ha ora raggiunto 2,12 GB ed è ancora in crescita. Nessun ulteriore aiuto da Apple fino ad ora - apparentemente non è possibile riprodurre il comportamento.

È possibile cancellare manualmente il file, cosa che ho fatto dopo che il mio primo ha raggiunto 1,76 GB. Puoi anche sostituirlo con un file snapshots.db immutabile del sistema vuoto, che impedisce al sistema di scrivere su di esso, anche se i messaggi della console "assertion failed" vengono visualizzati ogni pochi minuti.

Non ho alcun reale utilizzo per questo file; 70-150 MB andrebbero bene, ma lo spazio su disco che consuma sul mio sistema non è accettabile.

Ti consiglio di presentare una segnalazione di bug anche con apple.

In alternativa, puoi disabilitare il launchdaemon che genera queste istantanee e scrive su quel file. L'ho fatto sul mio rMBP con Mavericks in quanto la console era piena di log "powerstats". Dopo che ho eseguito il seguente comando, sia i rapporti del registro della console sia la crescita del file a cui si fa riferimento.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.daily.plist 

Il daemon systemstatsd raccoglie una selezione di statistiche di sistema sull'utilizzo dell'energia del sistema e di solito viene eseguito inosservato in background. Quindi, in generale, non c'è niente da preoccuparsi.

Se il file del database diventa troppo grande ( snapshots.db ), può essere svuotato quando si interrompe / scarica il servizio come da questo posta :

sudo launchctl stop com.apple.systemstatsd
sudo launchctl stop com.apple.systemstatsd.analysis

quindi svuota il file di:

sudo sh -c ">/private/var/db/systemstats/snapshots.db"

Posso confermare che è in esecuzione

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

comprime il database. Il mio è passato da 530 MB a 74 MB, adattando altri messaggi qui. Pertanto, la raccolta di dati inutili o il danno da scrittura su questo database è probabilmente un colpevole. Mi azzarderei a credere che la supposizione più probabile sia su una cattiva scrittura, in quanto il mio CCC non può scriverlo (né potrei copiarlo in un'altra directory)