Dlaczego IIS zjada dysk?
Serwery WWW obsługujące dobreprogramy są w całości zwirtualizowane, a co za tym idzie, ich dyski to nie talerze ani komórki pamięci Flash (przynajmniej nie wprost), ale wykrojone na miarę obszary na prawdziwych woluminach, które to notabene też nie są do końca prawdziwe, bo są to tylko wirtualne LUNy stworzone z kilku czy kilkunastu fizycznych dysków twardych. Możliwość krojenia na miarę jest bardzo interesująca i warto przemyśleć, ile tak naprawdę przeznaczyć gigabajtów na dysk systemowy, dyski na dane, dyski na logi czy pliki tymczasowe i tak dalej.
Jeśli korzystacie z maszyn wirtualnych na swoich komputerach, to z dużym prawdopodobieństwem używacie do tego celu tzw. cienkich dysków (thin-provisioned ). Dyski takie, choć mają pojemność np. 50 GB, początkowo fizycznie liczą kilka megabajtów. Następnie rosną wraz z rosnącą ilością danych na nich zapisywanych. Niestety ten proces "stopniowego przyrostu" jest kłopotliwy, pochłania zasoby i w efekcie spowalnia operacje I/O na dysku. Dlatego tam, gdzie liczy się wydajność, a mniej mobilność, dokonuje się początkowej alokacji 100% powierzchni takiego wirtualnego dysku. Czyli dysk wirtualny czy jest pusty, czy jest pełny, zajmuje zawsze np. 50 GB. Pytanie teraz: jak pogodzić chęć szybkiego przenoszenia dysków pomiędzy fizycznym magazynem danych (np. z macierzy na macierz), szybkiego robienia backupów blokowych (backupów całych dysków) z chęcią posiadania szybkiego dostępu do danych :) Teoretyczna odpowiedź jest prosta: trzeba kroić jak najmniejsze dyski.
A w praktyce? Wydaje się, że Windows, którego używamy przecież na wszystkich ważnych serwerach, jest tu wręcz obżartuchem jeśli chodzi o przestrzeń dyskową. Gdy migrowaliśmy kilka lat temu na serwery wirtualne (i przy okazji z Windows Server 2003 na Windows Server 2008) mieliśmy niewielkie doświadczenie w kwestii potrzeb dyskowych nowego serwerowego systemu Microsoftu. Zdecydowaliśmy się jednak na bardzo niewielkie dyski systemowe 30 GB. Ostatecznie zawsze można je rozszerzyć (choć często ze stratą dla wydajności). Praktyka kilku lat pokazała, że nie ma z tym żadnego problemu i spokojnie można zmieścić się na takim dysku, o ile wyrzucimy z niego wszystkie logi. Sama witryna główna portalu dobreprogramy, czyli bez grafik, CSSów i dodatkowych elementów, tylko na jednym węźle (serwerze) klastra generuje dziennie blisko 500 MB logów w pliku tekstowym. Wymienione przeze mnie elementy dodatkowe serwujemy z oddzielnej domeny dla poprawy wydajności i tam log jest jeszcze większy. Na szczęście efektywność pakowania czystego tekstu jest bardzo zadowalająca ;)
Do napisania tego wpisu skłoniło mnie jednak coś, przez co kiedyś zwątpiłem w możliwość zmieszczenia się na 30 GB.
Tak, powyższe trzy akapity to był wstęp :P
W pewnym momencie, właściwie już po kilku miesiącach, okazało się, że miejsce się kończy i zaczęliśmy się zastanawiać, dlaczego. Czy to poprawki? W końcu co miesiąc jakieś tam się instalują. Czy to cache? Pliki tymczasowe? Zaczęliśmy szukać. Okazało się, że winne były pliki logów sterownika http.sys, czyli najważniejszego komponentu serwera webowego, który pracuje w trybie jądra i odpowiada za obsługę wywołań HTTP. W ciągu godziny w szczycie oglądalności potrafi on logować około 5-7 MB informacji. Pytanie czy potrzebnych? W zasadzie wszystkie wpisy to błędy Timer_ConnectionIdle.
Tak naprawdę jednak to... wcale nie błędy. Jest to zupełnie naturalne i pożądane zachowanie protokołu HTTP. Dotyczy sytuacji, w której klient (czyli Wasza przeglądarka) decyduje się nie rozłączać połączenia TCP z naszym serwerem WWW, bo przewiduje - zwykle słusznie - że za bardzo krótką chwilę nastąpi kolejne połączenie. Istotnie w większości przypadków ma rację, bo jedna odsłona naszego portalu to kilkanaście albo nawet kilkadziesiąt wywołań - pobieracie przecież nie tylko dokument HTML, ale także grafiki, style CSS, skrypty... Czasami jednak zdarza się, że pozostawione połączenie nie zostanie wykorzystane. Wtedy następuje timeout i nasz serwer je zamyka, by mógł połączyć się ktoś inny.
Logowanie tych "błędów" jest w Windows Server 2008 włączone domyślnie, co na serwerach obsługujących tak duży ruch jak nasz może być zabójcze. Szybki rzut oka w artykuł KB820729 pozwala jednak dotrzeć do ustawień rejestru, które umożliwiają ograniczenie lub nawet całkowite wyłączenie logowania przez http.sys. Dzięki dostosowaniu tych parametrów do własnych potrzeb i opracowaniu właściwej polityki retencji logów (również przenosząc lokalizację tych plików na inny dysk, co zazwyczaj jest dobrym pomysłem) można z powodzeniem zmieścić system na dysku 30 GB, i to z naprawdę sporym zapasem! Jeśli administrujecie serwerem IIS, sprawdźcie katalog C:\Windows\System32\LogFiles\HTTPERR - jest spora szansa, że znajdziecie tam parę gigabajtów. Wasza macierz Wam za to podziękuje ;)