Какая польза от snapshot.db?

После установки Mavericks я обнаружил snapshot.db(1,5 ГБ) файл в:

/var/db/systemstats/snapshots.db

Какая польза от этого файла? Это безопасно удалить?

На высоком уровне указанный вами файл является двоичным файлом базы данных, который используется ОС для отслеживания энергопотребления, производительности и данных сна / пробуждения с течением времени. Несмотря на общее указание не удалять что-либо из / var / db, это, по-видимому, не причинит чрезмерного вреда, если вы случайно удалите этот файл.

Это обеспечивает новые представления об использовании энергии и, возможно, может помочь с диагностикой, если у вас возникнут проблемы в будущем, и попросите Apple помочь в диагностике системы.

Программа, которая записывает в этот файл (а также связанные файлы в / var / db / systemstats), является systemstatsd .

Вы можете использовать команду systemstats --help, чтобы получить больше подробностей и прочитать из этого файла, если вам интересно. Страница руководства, на которую я ссылаюсь, является оболочкой страницы руководства, и код в основном не документирован Apple, кроме документации, встроенной в инструмент и доступной по вызову с помощью опции справки.

Как правило, небезопасно удалять что-либо в / var / db, поскольку система может зависеть от согласованности файлов, но я протестировал удаление всего содержимого этого каталога, загрузившись в однопользовательском режиме, и система, похоже, воссоздает вещи правильно и обрабатывает любые попытки вручную очистить эти файлы.

Я бы не рекомендовал удалять что-либо из sytemstats на Mac, который вы не готовы стереть и переустановить, и вы также можете получить странную информацию из Activity Monitor, если вам удастся получить базу данных и файлы журналов в несогласованном состоянии. Тем не менее, похоже, что система была запрограммирована на защиту, чтобы обрабатывать пропавшие вещи из этого каталога и не вызывать ошибочные операции в целом, если вы все равно это сделаете.

Я подал отчет об ошибке в Apple по той же проблеме. Они ответили, что snapshots.db предназначен для хранения данных за последние 3 дня и составляет 70-150 МБ на большинстве систем. Однако на моем (OS X 10.9, iMac 27-дюймовый 2.8 ГГц i7, 8 ГБ оперативной памяти) текущий файл snapshots.db достиг 2.12 ГБ и продолжает расти. До сих пор нет никакой помощи от яблок - они, очевидно, не могут воспроизвести поведение.

Можно вручную удалить файл, что я и сделал после того, как мой первый достиг 1,76 ГБ. Вы также можете заменить его пустым системным неизменяемым файлом snapshots.db, который не позволяет системе выполнять запись в него, хотя вы затем получаете консольные сообщения «сбой утверждения» каждые несколько минут.

У меня нет никакого реального использования для этого файла; 70-150 МБ было бы хорошо, но дисковое пространство, которое он потребляет в моей системе, недопустимо.

Я рекомендую вам также сообщить об ошибке в Apple.

Кроме того, вы можете отключить launchdaemon, который порождает эти снимки и записывает в этот файл. Я сделал это на моем rMBP под управлением Mavericks, так как консоль была залита журналами «powerstats». После того, как я запустил следующую команду, отчеты о журнале консоли и рост файла, на который вы ссылаетесь, прекратились.

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

В systemstatsdдемоных собирают выбор системы статистических данных об использовании системы питания и обычно проходит незаметно в фоновом режиме. Так что, в общем, не о чем беспокоиться.

Если файл базы данных становится слишком большим ( snapshots.db), его можно очистить при остановке / выгрузке службы согласно этому сообщению :

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

затем очистите файл:

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

Я могу подтвердить, что работает

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

сожмет базу данных вниз. Мой размер увеличился с 530 МБ до 74 МБ, что соответствует другим публикациям здесь. Таким образом, сборщик мусора или повреждение записи в этой базе данных, вероятно, является виновником. Я бы рискнул предположить, что более вероятное предположение о плохой записи, так как мой CCC не мог переписать его (и при этом я не мог скопировать это в другой каталог)