Po zainstalowaniu Mavericks odkryłem snapshot.db
(1,5 GB) plik w:
/var/db/systemstats/snapshots.db
Jaki jest pożytek z tego pliku? Czy można to bezpiecznie usunąć?
Po zainstalowaniu Mavericks odkryłem snapshot.db
(1,5 GB) plik w:
/var/db/systemstats/snapshots.db
Jaki jest pożytek z tego pliku? Czy można to bezpiecznie usunąć?
Odpowiedzi:
Na wysokim poziomie wymieniony plik jest plikiem binarnej bazy danych używanym przez system operacyjny do śledzenia zużycia energii, wydajności oraz danych dotyczących trybu uśpienia / budzenia w czasie. Pomimo ogólnych wskazówek, aby nie usuwać niczego z / var / db, wydaje się, że nie spowoduje to nieuzasadnionej szkody, jeśli od czasu do czasu usuniesz ten plik.
Dostarcza to nowych poglądów na zużycie energii i być może może pomóc w diagnostyce, jeśli masz problemy w dalszej kolejności i poprosisz Apple o pomoc w zdiagnozowaniu systemu.
Program zapisujący do tego pliku (a także skojarzonych plików w / var / db / systemstats) to systemstatsd .
Możesz użyć polecenia systemstats --help, aby uzyskać więcej szczegółów i przeczytać z tego pliku, jeśli jesteś ciekawy. Strona podręcznika, do której odsyłam, jest powłoką strony podręcznika, a kod jest w większości nieudokumentowany przez Apple poza dokumentacją wbudowaną w narzędzie i dostępną po wywołaniu go za pomocą opcji pomocy.
Zasadniczo nie jest bezpieczne usuwanie czegokolwiek w / var / db, ponieważ system może zależeć od spójności plików, ale przetestowałem usunięcie całej zawartości tego katalogu, uruchamiając się w trybie pojedynczego użytkownika, a system wydaje się odtwarzać poprawnie i obsługiwać wszelkie próby ręcznego wyczyszczenia tych plików.
Nie polecam usuwania czegokolwiek z sytemstats na komputerze Mac, którego nie jesteś gotowy do wymazania i ponownej instalacji, a także możesz uzyskać dziwne informacje z Monitora aktywności, jeśli uda Ci się uzyskać bazę danych i pliki dziennika w niespójnym stanie. To powiedziawszy, wygląda na to, że system został zaprogramowany defensywnie do obsługi rzeczy zaginionych z tego katalogu i nie powoduje generalnie nieprawidłowego działania, jeśli tak zrobisz.
Złożyłem raport błędu w Apple dotyczący tego samego problemu. Odpowiedzieli, że snapshots.db ma przechowywać dane z ostatnich 3 dni i osiągnąć 70-150 MB w większości systemów. Jednak w moim (OS X 10.9, iMac 27-calowy 2.8 GHz i7, 8 GB RAM) aktualny plik snapshots.db osiągnął teraz 2,12 GB i wciąż rośnie. Jak dotąd żadna pomoc ze strony jabłka - najwyraźniej nie mogą odtworzyć zachowania.
Możliwe jest ręczne usunięcie pliku, co zrobiłem po tym, jak mój pierwszy osiągnął 1,76 GB. Możesz go również zastąpić pustym niezmiennym plikiem snapshots.db, co zapobiega zapisywaniu go przez system, chociaż co kilka minut pojawiają się komunikaty konsoli „asercja nie powiodła się”.
Nie mam rzeczywistego zastosowania dla tego pliku; 70-150 MB byłoby w porządku, ale miejsce na dysku, które zużywa w moim systemie, jest niedopuszczalne.
Polecam również zgłoszenie błędu w Apple.
Alternatywnie, możesz wyłączyć launchdaemon, który spawnuje te migawki i zapisuje do tego pliku. Zrobiłem to na moim rMBP z systemem Mavericks, ponieważ konsola została zalana dziennikami „powerstats”. Po uruchomieniu następującego polecenia zarówno raporty dziennika konsoli, jak i przyrost pliku, do którego się odwołujesz, przestał działać.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.daily.plist
The systemstatsd
Demon zbierać wybór systemu statystyk dotyczących zużycia energii systemu i zwykle przebiega niezauważalnie w tle. Ogólnie więc nie ma się czym martwić.
Jeśli plik bazy danych staje się zbyt duży ( snapshots.db
), można go opróżnić po zatrzymaniu / zwolnieniu usługi zgodnie z tym postem :
sudo launchctl stop com.apple.systemstatsd
sudo launchctl stop com.apple.systemstatsd.analysis
następnie opróżnij plik:
sudo sh -c ">/private/var/db/systemstats/snapshots.db"
Mogę potwierdzić, że działa
sudo sqlite3 /private/var/db/systemstats/snapshots.db "vacuum;"
skompresuje bazę danych. Mój zwiększył się z 530 MB do 74 MB, co odpowiada innym postom tutaj. Dlatego zbieranie śmieci lub uszkodzenie zapisu w tej bazie danych jest prawdopodobnie winowajcą. Zaryzykowałbym stwierdzenie, że bardziej prawdopodobne jest złe założenie, ponieważ mój CCC nie mógł tego napisać (ani nie mógłbym skopiować go do innego katalogu)