Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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 ;) 

porady serwery

Komentarze

0 nowych
4lpha   9 #1 12.01.2012 23:04

Ciekawy wpis i przydatny.

tfl   8 #2 13.01.2012 07:58

Dzieki!

wszerad   5 #3 13.01.2012 08:02

Myślałem, że takie zachowania to jest norma przy serwerach trochę się wam dziwie, że tego wcześniej nie wykryliście :D Macie może jakieś dane co do ilości zapytań do serwera na sekundę? Czego używacie do serwowania statycznych plików na static.dpcdn.pl?

  #4 13.01.2012 08:25

A ja się nie znam na tych rzeczach. Dlaczego używane są serwery wirtualne zamiast niewirtualnych?

Docent REDAKCJA  13 #5 13.01.2012 08:52

@wszerad:

Wykryliśmy to już dawno temu, zresztą tak jak pisałem nie było to trudne przy takim tempie logowania danych ;)

static.dpcdn.pl serwujemy oczywiście z IIS, ale odpowiednio skonfigurowanego (bez .NETu, bez niektórych modułów, z innymi, bardziej agresywnymi ustawieniami output cache itd.)

zoso71   8 #6 13.01.2012 09:55

No tak droga redakcjo - to my, użyszkodniki zgotowaliśmy wam ten los! ;-P

Docent REDAKCJA  13 #7 13.01.2012 10:06

@Dominik1111:

Nie wiem czy widziałeś już ten materiał wideo? http://www.dobreprogramy.pl/dobreprogramy-okiem-administratora,Wideo,26959.html

wszerad   5 #8 13.01.2012 11:28

Nie eksperymentowaliście coś: nginx + memcached albo mongoDB do wyświetlania danych o programach? Wydaje mi się, że mongoDB nadaje się do tego jak żadna inna baza danych.

Docent REDAKCJA  13 #9 13.01.2012 11:47

@wszerad:

Nasz SQL Server spisuje się bardzo dobrze, więc nie eksperymentujemy ;)

Saracen   6 #10 13.01.2012 12:53

C:\Windows\system32\LogFiles\W3SVC1

Docent REDAKCJA  13 #13 13.01.2012 13:05

@Saracen:

Nie wiem co chciałeś przez to powiedzieć, ale to nie o logi witryn chodzi tutaj...

Saracen   6 #14 13.01.2012 13:13

Chciałem pomóc odpowiedzieć na pytanie "Dlaczego IIS zjada dysk"

johnyby   2 #15 13.01.2012 13:54

Prosta i ciekawa odpowiedz. Polecam

Spankin   2 #16 19.01.2012 08:27

fajny artykulik, przydatny :)

ale może czas się przesiąść na Unixy? większość serwerów na świecie pracuje na różnych odmianach (nie mówiąc o superkomputerach, gdzie Unixy to ponad 90%), Windows jest dobry ale dla użytkowników końcowych :) może czas o tym pomyśleć? chociaż potestować :)

  #17 19.01.2012 08:59

Spankin, było już 1020102 tłumaczone dlaczego Windows Server a nie inne systemy :]