Monthly Archives: Lipiec 2012

BUG w LCD :)

Lato to zdecydowanie nie jest czas na spędzanie czasu przed komputerem. Pogoda jest cudna, na dworze ciepło, słońce w pełni, a ja przed chwilą wróciłem ze spaceru. Odpaliłem sprzęt by sprawdzić pocztę i ewentualnie poklikać trochę na necie, a tu po ekranie „pomyka” mi jakieś małe „coś”, którego (dość niewyraźną fotkę) można zobaczyć poniżej:

Jak to zwykle bywa w tego typu przypadkach – stwierdziłem, że „to coś” unicestwię i zajmę się przeglądaniem poczty. W tym momencie poczułem pierwsze zaskoczenie:

To nie jest nic NA MONITORZE !!!

Stwierdziłem, że może ślepnę i po prostu jest to jakiś dziwny program – żart, wirus albo inny soft, którego na pewno nie chciałem na moim komputerze. Od kilku lat już nie miałem żadnego wirusa, ale cóż … zdarza się 🙂

No, niestety NIE JEST TO WIRUS !!!

Odłączyłem monitor od komputera i „to coś” nadal tam jest. Gdyby nie fakt, że się przemieszcza, to uznałbym to za jakiś wadliwy piksel. Spytałem googla:

W tym momencie okazało się z czym dokładnie mam do czynienia.

Jest gatunek robaka, który żyje w LCD !!!

W życiu bym nie przypuszczał, że takie coś jest możliwe. Inną sprawą jest fakt, że raczej się nad tym nie zastanawiałem. Mimo wszystko jest zaskoczenie. Co więcej z jednej strony nauczyłem się czegoś nowego … ale z drugiej … dostałem doła …

W domu raczej posprzątane, monitor czyszczę raz na tydzień, żona mówiła mi, że mam poodkurzać, ale żeby od razu robal w LCD … Trochę niefart 🙂

Dla zainteresowanych link do opisu robaka z wikipedii:

http://pl.wikipedia.org/wiki/Wciornastki

Reklamy

Mity o SQL Server: Ilość rdzeni na serwerze a ilość plików tempdb

Na początku maja rozpocząłem serię postów, mówiącą na temat różnego rodzaju mitów i niedomówień związanych z działaniem SQL Server. Zgodnie z obietnicą tematem drugiego wpisu będzie następujący mit:

„Ilość plików w tempdb powinna być równa ilości rdzeni na jakich pracuje SQL” 

Mit ten jest dość popularny i jak zauważył mmoskit można na ten temat znaleźć oficjalne wzmianki w white paper-ach wydanych przez Microsoft, np:

http://www.microsoft.com/en-us/download/details.aspx?id=18473

„Make as many tempdb files as you have physical CPU, accounting for any affinity mask settings. Do not factor in hyperthreading or dual cored CPUs into the count ”

W dalszej części tego wpisu chciałbym pokazać, dlaczego nie warto stosować się do tego zalecenia „z automatu”., gdyż może ono prowadzić do utraty wydajności zainstalowanej instancji.

Środowisko testowe:

Zanim zaczniemy test, przedstawię nieco środowisko testowe. Konfiguracja sprzętowa wygląda następująco:

  1. SERWER HP DL 360 GS
  2. 2 x Intel Xeon  E5420 Quad Core 2,5 GHz
  3. 8 GB RAM
  4. 2 x HDD 146 GB,  10000rpm – zestawione w RAID 1
  5. 2 x  HDD 74GB 15000rpm – widoczne pojedynczo (oddzielnie)

Jeśli chodzi o zainstalowane oprogramowanie, to posłużyłem się:

  1. WINDOWS 2008R2 SP1 w Enterprise
  2. SQL Server 2012 Enterprise
  3. Przykładową bazą danych ContosoRetailDW

Całość została ustawiona przeze mnie w następujący sposób:

  1. System wraz z silnikiem SQL i bazami (za wyjątkiem tempdb) na dyskach 146GB 10000 obr/min
  2. Pliki danych tempdb na dysku 74 GB 15000 obr/min (zamontowanym jako dysk logiczny F)
  3. Plik logu tempdb na dysku 74 GB 15000 obr/min (zamontowanym jako dysk logiczny G)
  4. Affinity Mask Serwera SQL ustawiona na zero (używam wszystkich rdzeni)
  5. Min Server Memory = 1000MB, Max Server Memory = 6000 MB

Ustawienie zgodnie z zaleceniem MS

Wykonany test zacząłem od  ustawienia instancji zgodnie z przytoczonym white paper-em. Ponieważ mój serwer jest ośmiordzeniowy, to baza tempdb powinna mieć 8 plików danych o takiej samej zaalokowanej ilości miejsca na dysku:

Następnie stworzyłem proste zapytanie, które będzie obciążać bazę tempdb:

SELECT *
INTO #t
FROM ContosoRetailDW.dbo.[FactITMachine]

DROP TABLE #t

Test właściwy polegał na odpaleniu powyższego skryptu w 10 wątkach po 100 razy za pomocą programu SQLQueryStress. Wynik tej operacji  – nieco ponad minuta (próba była powtarzana 3 razy, do zestawienia brany był najniższy wynik):

Ustawienie niezgodne z zaleceniem MS

Drugą częścią testu było ustawienie bazy tempdb w taki sposób, aby miała tylko jeden plik danych:

Następnie odpaliłem stworzony wcześniej skrypt. Ponownie w 10 wątkach po 100 razy. Czas wykonania był tym razem około 30% krótszy, gdyż wynosił 45 sekund:

Dlaczego ustawienie zgodne z zaleceniem jest GORSZE ?!!!

Przyczyną zmniejszonej wydajności operacji I/O w bazie tempdb jest „fizyczność” dysku twardego, na którym posadowiłem pliki z danymi. Konfigurując bazę tempdb na oddzielnym dysku i tworząc w niej 8 równych plików z danymi sprawiliśmy, że SQL Server zaczął używać mechanizmu proporcjonalnego wypełnienia. Sprawdźmy w jaki sposób ten algorytm zadziałał w badanym przypadku:

1. Ustawmy baze tempdb tak, aby miała 8 plików z danymi

2. Odpalmy pierwszą część skryptu używając SQL Server Management Studio:

SELECT *
INTO #t
FROM ContosoRetailDW.dbo.FactITMachine

3. Sprawdzamy w jakich plikach są przechowywane dane naszej tabeli:

SELECT REPLACE(LEFT(sys.fn_PhysLocFormatter(%%physloc%%), 2), '(', '') AS FileID,
  COUNT(*) As NumRows
FROM #t
GROUP BY LEFT(sys.fn_PhysLocFormatter(%%physloc%%), 2)
ORDER BY FileID

Jak widać na powyższym zrzucie ekranu, SQL Server porozdzielał wiersze pomiędzy pliki. Algorytm proporcjonalnego wypełnienia sprawił, że głowica dysku twardego musiała zmieniać pozycję „skacząc” pomiędzy plikami sprawiając, że zapis na nich był wolniejszy.

Poniżej przedstawiam zrzuty ekranów z Resource Monitora, najpierw dla konfiguracji z 8 plikami:

A teraz dla jednego pliku z danymi:

Porównując oba obrazki widać, że różnica w szybkości zapisu jest znaczna (35MB vs 59MB na korzyść konfiguracji z 1 plikiem)

Podsumowanie

Stosowanie się do przytoczonego zalecenia MS odnośnie konfiguracji bazy tempdb może powodować spadek wydajności SQL Server. W erze wielordzeniowych procesorów, gdzie serwery bazodanowe mogą bez większego problemu posiadać po kilkadziesiąt rdzeni, utworzenie takiej samej ilości plików z danymi tempdb może okazać się dosyć kiepskim pomysłem. W związku z powyższym jestem zwolennikiem niestosowania się do tego zalecenia z automatu. Należy jednak w tym miejscu wspomnieć, że istnieją sytuacje w których zwiększenie ilość plików poprawia osiągi serwera. Jedną z takich sytuacji jest np. problem z dostępem do stron PFS w tempdb – co możliwe, że będzie tematem do dalszych rozważań i kolejnych wpisów 🙂

Edit: Dla niedowiarków 🙂

Aby nie być gołosłownym, sprawdziłem jak będzie wyglądać odczyt z takiej tabeli w zależności od ilości plików tempdb. Test jest dosyć prosty i wyglądał następująco:

1. Ponowna konfiguracja tempdb, tak aby miała 8 plików z danymi

2. Utworzenie tabeli testowej:

SELECT *
INTO tempdb.dbo.test
FROM ContosoRetailDW.dbo.FactITMachine

3. Cykliczne wykonanie następującego wsadu T-SQL:

-- Czyścimy RAM serwera
CHECKPOINT
DBCC DROPCLEANBUFFERS
-- odpalamy zapytanie (dane z dysku)
SELECT COUNT(*)
FROM tempdb.dbo.test
OPTION (QUERYTRACEON 8649)

Wynik tego zabiegu można zobaczyć poniżej (ponad 9 sekund):

Analogiczny test przeprowadzony dla tempdb z jednym plikiem (nieco ponad 7 sekund):

Podsumowanie dla niedowiarków 🙂

Niezależnie czy piszemy, czy odczytujemy dane z bazy tempdb ustawionej zgodnie z zaleceniem MS, to wydajność serwera jest niższa niż w przypadku posiadania tylko 1 pliku tempdb przy badanej konfiguracji dyskowej.