Для чого використовується snapshot.db?

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

/var/db/systemstats/snapshots.db

Яке використання цього файлу? Чи безпечно її видалити?

На високому рівні перерахований вами файл є двійковим файлом бази даних, який використовується ОС для відстеження витрат енергії, продуктивності та даних сну / пробудження з часом. Незважаючи на загальні вказівки нічого не видаляти з / var / db, схоже, це не заподіює надмірної шкоди, якщо ви видаляли цей файл при нагоді.

Це підживлює нові погляди на використання енергії та, можливо, може допомогти в діагностиці, якщо у вас виникнуть проблеми, і попросіть Apple допомогти діагностувати систему.

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

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

Як правило, видалити що-небудь в / var / db не можна, оскільки система може залежати від того, щоб файли були когерентними, але я перевірив видалення всього вмісту цього каталогу, завантажившись в режим Single User, і система, здається, відтворила речі належним чином і обробляє будь-які спроби очистити ці файли вручну.

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

Я подав звіт про помилку з яблуком за тим же номером. Вони відповіли, що 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 Мб було б добре, але дисковий простір, який він споживає в моїй системі, неприйнятний.

Я рекомендую також подати звіт про помилку з яблуком.

Крім того, ви можете відключити запускаючий демон, який породжує ці знімки і записує у цей файл. Я зробив це на моєму Mavericks, що працює на rMBP, оскільки консоль була заповнена журналами "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;"

буде стискати базу даних. Шахта пішла від 530MB до 74MB, відповідно до інших публікацій. Таким чином, вивіз сміття чи збиток у цій базі даних, ймовірно, є винуватцем. Я б ризикнув, що більш вірогідне припущення є помилковим записом, оскільки мій CCC не міг записати його (а також не міг скопіювати його в інший каталог)