¿Cuál es el uso de snapshot.db?

En un nivel alto, el archivo que enumeró es un archivo de base de datos binario utilizado por el sistema operativo para rastrear el uso de energía, el rendimiento y los datos de suspensión / activación a lo largo del tiempo. A pesar de la guía general para no eliminar nada de / var / db, esto parece no causar un daño indebido si tuviera que eliminar ese archivo en alguna ocasión.

Esto alimenta las nuevas vistas del uso de energía y quizás pueda ayudar con los diagnósticos si tiene problemas en el futuro y le pide a Apple que lo ayude a diagnosticar el sistema.

El programa que escribe en ese archivo (así como los archivos asociados en / var / db / systemstats) es systemstatsd .

Puede usar systemstats --help para obtener más detalles y leer ese archivo si tiene curiosidad. La página de manual a la que me vinculé es la cáscara de una página de manual y el código no está documentado en su mayoría por Apple, aparte de la documentación incorporada en la herramienta y accesible mediante su opción de ayuda.

Por lo general, no es seguro eliminar nada en / var / db ya que el sistema podría depender de que los archivos sean coherentes, pero he probado eliminar todo el contenido de ese directorio iniciando el modo de Usuario Único y el sistema parece recrear las cosas. correctamente y manejar cualquier intento de limpiar manualmente estos archivos.

No recomendaría eliminar nada de sytemstats en una Mac que no esté listo para borrar y reinstalar, y también podría obtener información extraña del Monitor de actividad si logra obtener la base de datos y los archivos de registro en un estado incoherente. Dicho esto, parece que el sistema fue programado a la defensiva para manejar las cosas que faltan en ese directorio y no causar una operación errática en general, si lo hace de todos modos.

Presenté un informe de error con Apple por el mismo problema. Respondieron que snapshots.db está destinado a almacenar datos durante los últimos 3 días y alcanzar 70-150 MB en la mayoría de los sistemas. Sin embargo, en la mía (OS X 10.9, iMac 27 pulgadas 2.8 GHz i7, 8 GB de RAM), el archivo snapshots.db actual ha alcanzado los 2.12 GB y sigue creciendo. No hay más ayuda de Apple hasta el momento, ya que aparentemente no pueden reproducir el comportamiento.

Es posible eliminar manualmente el archivo, lo que hice después de que mi primer archivo alcanzó 1,76 GB. También puede reemplazarlo con un archivo de sistema inmutable snapshots.db, que evita que el sistema escriba en él, aunque luego recibe mensajes de la consola de 'error de aserción' cada pocos minutos.

No tengo uso real para este archivo; 70-150 MB estaría bien, pero el espacio en disco que consume en mi sistema es inaceptable.

También le recomiendo que presente un informe de error con Apple.

Alternativamente, puedes deshabilitar el daemon de inicio que genera estas instantáneas y escribe en ese archivo. Hice esto en mi rMBP ejecutando Mavericks desde que la consola se inundó con los registros de "powerstats". Después de ejecutar el siguiente comando, cesaron los informes de registro de la consola y el crecimiento del archivo al que se refiere.

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

El daemon systemstatsd recopila una selección de estadísticas del sistema sobre el uso de energía del sistema y generalmente se pasa desapercibido en segundo plano. Entonces, en general, no hay nada que preocuparse.

Si el archivo de la base de datos se vuelve demasiado grande ( snapshots.db ), se puede vaciar cuando detiene / descarga el servicio según esto post :

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

luego descarga el archivo con:

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

Puedo confirmar que se está ejecutando

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

comprimirá la base de datos hacia abajo. El mío pasó de 530MB a 74MB, conformando otras publicaciones aquí. Por lo tanto, la recolección de basura o el daño de escritura en esta base de datos es probablemente un culpable. Me atrevería a decir que la suposición más probable es una mala escritura, ya que mi CCC no pudo escribirla (ni podría copiarla en otro directorio)