Temat: MSSQL ciekawy przypadek

Witam,

Mam bardzo ciekawy case związany z windowsem i sql serverem. Mianowicie na jednym z serwerów, na którym stoi baza danych (mssql server 2008) obsługująca system magazynowy w dużym centrum logistycznym pojawiają się piki, podczas których serwer zamiera na chwilę. Piki pojawiają się na następujących licznikach:

Log write wait
Procesor privileged time

Witać to na poniższym obrazku:





Konfiguracja serwera, na którym występuje ten problem to:

HP DL380 G6
2xXEON e5520
72GB RAM

Bazy danych są składowane na dość specyficznym storage'u FusionIO ioDrive:
http://www.fusionio.com/products/iodrive/

W serwerze są zamontowane 3 karty ioDrive 320 GB z czego karta, na której przechowywane są dane jest sformatowana na 320GB, a dwie pozostałe, przechowujące T-Loga są sformatowane na max write performance, po 220GB każda.

Cluster size dla wszystkich dysków jest ustawiony na 64KB, wyłączone HT na prockach, wszystkie bazy w trybie Full Recovery, włączony mirroring dla wszystkich baz użytkownika, włączony log shipping co 15 minut aby zapanować nad t-logami.

Podczas takiego piku SQL zamiera na chwilę, po czym znowu śmiga normalnie. Ma ktoś może jakiś pomysł, którym kierunku szukać? Brakuje mi trochę pomysłów ;(

Co ciekawe miałem niedawno podobny problem u innego klienta, który korzystał z bardziej typowego storage'a Hitachi AMS 2100 SAN. U niego również występowały takie same piki (ale było trochę niższe rzędu 300ms na log write wait). Był to klaster złożony z 2 node'ów podłączonych do macierzy przez sieć SAN. W tym przypadku udało się za pomocą xperf'a zlokalizować problematyczny sterownik storport.sys, który nie dawał sobie rady z zapisami poniżej 4kb i generował mnóstwo opóźnień. Łatka do windowsa załatwiła sprawę. Jedyna zbieżność tych dwóch przypadków, to to, że obydwa serwery (ten z iodrive i klaster) były wykorzystywane przez WMS'a. Chociaż obydwa te systemy magazynowe były systemami autorskimi tworzonymi lokalnie w firmach i nie miały ze sobą nic wspólnego:)

Natomiast po załączeniu xperf'a dla pierwszego przypadku nie mogę znaleźć nic, co by się jakoś mocno rzucało w oczy i stoję w miejscu. Proszę o propozycje rozwiązań/sposobów diagnozowania, gdyż przypadek jest dość ciekawy i może posłużyć społeczności...

Dodam jeszcze, że karty ioDrive wykorzystujemy w większej ilości serwerów i tylko w tym jednym przypadku występują piki wydajności.

PozdrawiamMaciej Krasuski edytował(a) ten post dnia 25.01.11 o godzinie 09:09

Temat: MSSQL ciekawy przypadek

Nie wiem czy to tylko u mnie, ale obrazka cos nie widac :)

w zwiazku ztym pytanie czy piki wystepuja w miare regularnie czy tak zupelnie losowo?

Jak wyglada wykorzystanie pamieci? moze sa jakies zrzuty cache'u na dyski?

Ile operacji read/write? w jakich proporcjach?

Jak wyglada rzeczywtista wydajnosc tych kart? mozesz sprawdzic transfer za pomoca http://www.microsoft.com/downloads/en/details.aspx?fam... ?

W serwerze są zamontowane 3 karty ioDrive 320 GB z czego karta, na której przechowywane są dane jest sformatowana na 320GB, a dwie pozostałe, przechowujące T-Loga są sformatowane na max write performance, po 220GB każda.

a co do tego - karta z danymi jest tylko jedna? nie mirrorowana? rozumiem ze w przypadku gdu padnie to jest zapasowa zeby na nia przywrocic dane;>

Temat: MSSQL ciekawy przypadek

nie widząc obrazka zapytam czy x64 i czy blokujesz strony w pamięci

Temat: MSSQL ciekawy przypadek

Grzegorz L.:
Nie wiem czy to tylko u mnie, ale obrazka cos nie widac :)

w zwiazku ztym pytanie czy piki wystepuja w miare regularnie czy tak zupelnie losowo?

Jak wyglada wykorzystanie pamieci? moze sa jakies zrzuty cache'u na dyski?

Ile operacji read/write? w jakich proporcjach?

Jak wyglada rzeczywtista wydajnosc tych kart? mozesz sprawdzic transfer za pomoca http://www.microsoft.com/downloads/en/details.aspx?fam... ?

W serwerze są zamontowane 3 karty ioDrive 320 GB z czego karta, na której przechowywane są dane jest sformatowana na 320GB, a dwie pozostałe, przechowujące T-Loga są sformatowane na max write performance, po 220GB każda.

a co do tego - karta z danymi jest tylko jedna? nie mirrorowana? rozumiem ze w przypadku gdu padnie to jest zapasowa zeby na nia przywrocic dane;>

Obrazek poprawiłem i powinien już działać.

Piki są regularne co około 2 minuty. Na tym drugim serwerze, ze zwykłą macierzą piki były też w regularnych odstępach co około 10 minut.

Jeśli chodzi o wykorzystanie pamięci to jest w tej chwili zajęte około 65GB z czego 61GB zajmuje SQL Server.
Jeśli chodzi o operacje IO to tak to wygląda średnio:

page reads/sec = 6000
page writes/sec = 200

Cache hit ratio jest średnio na poziomie 99,7, a także PLE jest na wysokim poziomie.
Wydajność tych dysków najlepiej pokazuje poniższy screen:





Co do mirroringu to jest on włączony na poziomie baz danych, a nie na poziomie karty. Każda karta ma swój wewnętrzny RAID, dzięki któremu potrafi odbudować dane po crash'u. Mirroring jest wykonywany po sieci LAN na podobny serwer, tylko wykorzystujący macierz SAN ze zwykłymi dyskami. Mirroring jest asynchroniczny aby nie spowalniać serwera głównego i jest to wyliczone tak, że w przypadku awarii na takiej synchronizacji tracimy malutki wycinek danych, który można szybko odtworzyć.

Całą siłą tych urządzeń jest czas dostępu na poziomie 50 mikrosekund dlatego musieliśmy pójść na pewne ustępstwa jeśli chodzi o bezpieczeństwo, aczkolwiek bilans zysków (na wydajności) i strat (na zabezpieczeniu danych przy użyciu mirroringu) wychodzi mocno na korzyść ioDrive'ów.

Rozważamy też wprowadzenie multi site clusteringu zamiast mirroringu aby mieć synchronizacje na poziomie całego sql servera, a nie tylko poszczególnych baz danych, ale to wiąże się ze sporymi wydatkami ;)

Temat: MSSQL ciekawy przypadek

Robert Kubalski:
nie widząc obrazka zapytam czy x64 i czy blokujesz strony w pamięci

Tak, x64... nie używamy AWE.

Temat: MSSQL ciekawy przypadek

nie masz przypadkiem informacji o stronicowaniu pamięci?
daj troche mniej ramu na sqla i podejżyj co zwraca ci
SELECT *
FROM sys.dm_os_ring_buffers
where ring_buffer_type not in ('RING_BUFFER_SCHEDULER')

Temat: MSSQL ciekawy przypadek

Robert Kubalski:
nie masz przypadkiem informacji o stronicowaniu pamięci?
daj troche mniej ramu na sqla i podejżyj co zwraca ci
SELECT *
FROM sys.dm_os_ring_buffers
where ring_buffer_type not in ('RING_BUFFER_SCHEDULER')

Z tego co wiem bug ze stronnicowaniem dotyczył tylko wersji x64 standard, a u nas mamy enterprise. Ponadto na serwerze jest więcej pamięci RAM niż jest wykorzystywane. SQL ma ustawioną na sztywno max i min ilość ramu i nie ma żadnych dodatkowych aplikacji, które walczą z nim o zasoby. Około 7GB pozostaje wolnego miejsca w ramie.

Jednak dzięki za hinta bo z tego co widzę to nie mamy ustawionego Lock Pages in Memory dla konta sql servera. Wprowadzę te zmiany i dam Wam znać czy coś się zmieniło.

Temat: MSSQL ciekawy przypadek

Wprowadziłem zmiany związane z Lock pages in memory i zrestartowałem serwer. Jest za wcześnie aby coś powiedzieć ale myślę, że na to też warto zwrócić uwagę, że po restarcie piki są mniejsze i dopiero po jakimś czasie narastają. Poniżej fotka przedstawiająca jak wygląda ten log write wait counter po restarcie całej maszyny:





Otworzyłem też case'a w microsofcie na ten temat i zobaczymy co oni wymyślą, ale znając życie to trochę potrwa więc jak ktoś ma jakieś nowe pomysły to chętnie przeczytam i wypróbuje ;)