Czy dobrą praktyką jest używanie kompresji NTFS w folderach dziennika IIS?

Czy dobrą praktyką jest stosowanie kompresji NTFS w folderach i plikach dziennika IIS?

W ten sposób udało mi się zmniejszyć z 20 GB do 7 GB. Dzienniki IIS są dzienne i mają średni rozmiar 20 MB, ale niektóre ekstremalne dni mają 200 MB.

Zastanawiam się, czy IIS musi otworzyć cały plik w pamięci, zmuszając NTFS do rozpakowania za każdym razem 20 MB (lub w skrajnych przypadkach 200 MB)? Czy jest jakaś magia, która pozwala IIS na dołączanie treści? Jaki wpływ ma system? Czy może to stanowić problem, jeśli zwiększymy ruch?

Czy powinienem je dzielić na godzinę zamiast na dzień?

Jakiś oficjalny artykuł Microsoft na ten temat? Nie mogłem go znaleźć.

— Malartre
źródło

Jeśli chcesz przechowywać dzienniki w dłuższej perspektywie, dlaczego nie przenieść ich? Zachowaj dzienniki bieżącego dnia na serwerze, a resztę przenieś / zarchiwizuj gdzie indziej. Do czego w ogóle używasz dzienników?

— joeqwerty

Przeprowadzka dodaje kolejny proces, który może się nie powieść. Próbowałem Całować.

— Malartre

Odpowiedzi:

Ponieważ Evan udzielił już ogólnej odpowiedzi, chciałbym odpowiedzieć na dwa z twoich pytań cząstkowych:

Czy IIS opróżnia dzienniki co X minut?

http.sys, część trybu IIS trybu jądra jest odpowiedzialna za logowanie i buforuje dane w pamięci przed zapisaniem ich do plików dziennika. Nie jestem pewien, ale nie sądzę, aby spłukiwał się co x sekundy, bardziej prawdopodobne po zapełnieniu bufora.

Czy podczas dodawania pojedynczego wiersza należy odczytać cały plik?

Nie, NTFS zapisuje aktualizacje pliku we własnej pamięci podręcznej, a następnie kompresuje i dołącza dane asynchronicznie do pliku. Zapis do skompresowanego pliku nie jest znacznie wolniejszy niż do nieskompresowanego pliku.

Dlatego nie powinno być problemu z użyciem kompresji NTFS w plikach dziennika IIS.

Źródła:

IIS 7 Resource Kit, rozdział 15: Rejestrowanie - Microsoft Press 2008

Windows Wewnętrzne wydanie 6 część 2, rozdział 12: Systemy plików Microsoft Press 2012

— Peter Hahndorf
źródło

Dokładnie takiej odpowiedzi szukałem: @ peter-hahndorf!

— Malartre,

Co ciekawe, w tym artykule Microsoft zaleca się inaczej:

If you run a program that uses transaction logging and that constantly writes to a database or log, configure the program to store its files on a volume that is not compressed. If a program modifies data through mapped sections in a compressed file, the program can produce "dirty" pages faster than the mapped writer can write them.

Pytanie brzmi, jaka jest definicja stale ?

— Zero3,

@ Zero3 Logowanie transakcji jest czymś nieco innym niż dzienniki IIS. W takim przypadku funkcja wewnątrz programu nie może powrócić z powodzeniem, dopóki zmiana transakcyjna nie zostanie trwale zapisana na dysku, więc wydajność aplikacji jest bezpośrednio związana z prędkością zapisu na dysku dla dzienników transakcji.

— NReilingh,

@NReilingh Być może masz rację. Właściwie nie wiem, czy IIS zapisuje w swoich plikach dziennika synchronizację / asynchronię. Tak czy inaczej, myślę, że ogólną kwestią poruszoną w tym artykule (są w nim inne przykłady, takie jak foldery użytkowników z dużą ilością odczytów i zapisów) jest to, że ciężkie operacje wejścia / wyjścia mogą być problemem w przypadku folderów skompresowanych.

— Zero3

Kompresuję moje dzienniki IIS na wielu serwerach IIS, aczkolwiek głównie na serwerach z programem Outlook Web Access / App lub stronami o niskiej objętości. Nie mam z tym żadnych problemów i podoba mi się oszczędność miejsca na dysku.

Podejmując tę decyzję, handlujesz procesorem na pamięć. Jeśli zaczynasz od procesora, prawdopodobnie nie jest to dobry kompromis. W przypadku moich serwerów OWA, które mogą powiększać gigabajty dzienników (dzięki urządzeniom ActiveSync), myślę, że kompromis jest dobry.

Sterownik systemu plików NTFS obsługuje kompresję, więc nie zmienia to sposobu, w jaki IIS zapisuje do plików.

Edytować:

Potencjalnie również wymieniasz część przepustowości we / wy i IOPS. Jeśli masz wystarczająco dużo woluminów, aby dzienniki zapisywały znaczące zużycie zasobów we / wy, możesz zauważyć spadek zużycia we / wy po włączeniu kompresji.

Jedynym sposobem, w jaki powiesz, jak to na ciebie wpływa, jest samodzielna analiza. Wybierz linię bazową z wyłączoną kompresją, a następnie włączoną i porównaj je. Nie ma magicznej różdżki, aby machnąć, aby wiedzieć, jak to na ciebie wpłynie - w grze jest po prostu zbyt wiele niedeterministycznych czynników.

— Evan Anderson
źródło

Pobij mnie do tego o kilka sekund ... nie masz pracy, zamiast grać w ServerFault? : p W każdym razie +1. Robiłem to samo od wieków, a mimo to mam z tego powodu problem.

— HopelessN00b

Ta odpowiedź jest niepotwierdzona i zabawna, ale szukam więcej faktów. Patrzę na szczegóły, na przykład, czy dzienniki opróżniania IIS co X minut i czy musi czytać cały plik, aby dodać jedną linię.

— Malartre

@Malartre To naprawdę nie jest anegdota. Jak wspomniano, kompresja plików / folderów NTFS stanowi kompromis - miejsce na dysku dla cykli procesora (i bardzo niewielkie zwiększenie zużycia pamięci). Jest to tak szczegółowe i oparte na faktach, jak to możliwe, bez przeprowadzania testów porównawczych i przeprowadzania rzeczywistych testów w określonym środowisku.

— HopelessN00b,