31 sierpnia 2011

Jak można zapełnić cały dysk i wyjść z tego cało?

Ignorancja to prosta droga do problemów


Pracując na wirtualnej maszynie i po raz kolejny ratując mój SharePoint'owy świat od zagłady, spostrzegłem, że na dysku C zostało mi 10 MB. Byłem zaskoczony, ale cóż mogę zrobić. Usunąłem niepotrzebne pliki na dysku i zyskałem 400MB, poczułem ulgę. Po 20 minutach znowu zabrakło mi miejsca na dysku C, zacząłem wiec myśleć (uff ...w końcu).

Uruchomiłem Process Monitor'a (z SysInternals Suite), ustawiłem filtr na operacje zapisu do plik


zacząłem przeglądać trace'a i ...




.... zobaczyłem, że na dysku E generowane jest dużo plików z informacją o Assembly Binding (Assembly Binder Log Entry). Spowodowane było to włączeniem logowania binding'u przez Fusion Log Viewer (Fuslogvw.exe), które zapomniałem wyłączyć (jak włączyć logowanie pisałem tutaj).



Widzę, że ewidentnie to na dysku E generują się te pliku logu, ale "może" (to już jest lamerstwo z mojej strony) też coś na dysku C było zapisywane. Wyłączyłem logowanie i zrestartowałem wszystki procesy i serwisy korzystającego z CLR.NET, aby zaprzestać generowaniu plików z assembly biding.

Szczęśliwy wróciłem do pracy i znowu po jakim czasie skończyło się miejsc na dysku C. Tym razem sięgnąłem po narzędzie zwane  WinDirStat. To cudo niemieckiej technologi, narysowało mi fajne mapki (TreeMap), przeszukało mi wszystkie pliki na dysku, przypisało kategorie na podstawie rozszerzenia pliku, i znalazło duży plik logu bazy danych (.ldf) i page file'a.




Najbardziej podobał mi się TreeMap, który w zależności od rozmiaru pliku rysuje proporcjonalny kwadracik. Np. na czerwono widać plik o rozszerzeniu *.sys, a na zielono i żółto kolejno pliki baz danych *.mdf i *.ldf. Taka mapka umożliwia bardzo szybkie zlokalizowanie przerośniętego pliku i określenie, jakiego typu pliki zajmują najwięcej miejsca na dysku.



Na wirtualnej maszynie nie robię backup'ów baz danych, a domyślnie bazy kontentowe SharePoint'a są ustawione na Full recovery model. Zatem transakcyjny log rośnie do dowolnych rozmiarów zanim nie zostanie przeprowadzony Full backup bazy lub chociaż backup logu.  Zmiana recovery model na Simple i shrink pliku logu transakcyjnego rozwiązało problem ciągłego przyrostu i zmiejszyło rozmiar pliku *.ldf.



Page file'a zwalczyłem w następujący sposób (Manage Computer->Advanced system settings->Advanced tab->Performance->Advanced tab->Change button.


Nie polecam takich ustawień Page File'a na produkcyjnym serwerze, ale mi potrzebne było miejsce na dysku.

Hope this help.

Brak komentarzy:

Prześlij komentarz

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.