poniedziałek, 2 maja 2016

Oracle SPARC M7 – śledzenie koprocesorów DAX

Kamil Stawiarski, Oracle Certified Master, szef firmy ORA-600
W epoce chmur pojawiają się czasem sprzętowe perełki, które zachwycają administratorów i programistów, przedkładających twarde fakty nad eteryczne byty. 
Jednym z takich rozwiązań jest nowy procesor SPARC M7 dostarczony przez dział Engineered Systems firmy Oracle. Pierwszy rzut oka na testową maszynę wystarczył żeby poczuć szacunek –jak często można pracować na maszynie posiadającej 256 corów i pół terabajta RAM? Nie to jest jednak największą mocą procesora SPARC M7 – są nią koprocesory DAX. 
Żeby jednak dokładnie wyjaśnić ich rolę, przyjrzyjmy się najpierw nowej funkcjonalności bazy 12.1.0.2 – In-Memory. 

Oracle Database In-Memory

Coraz częściej trudno jest jednoznacznie określić charakterystykę danego systemu – w wielu przypadkach mamy bowiem do czynienia z systemami mieszanymi – niby jest to system transakcyjny ale na bieżąco musimy wykonywać bardzo dużo analitycznych zapytań. Sprawa wydawałaby się łatwo rozwiązywalna w związku z faktem istnienia coraz tańszych kości pamięci RAM i coraz większych możliwości obsługi takiej pamięci w nowych serwerach. 

Problem jest jednak bardziej złożony – duża pamięć współdzielona oznacza konieczność istnienia mechanizmów chroniących takie obszary – np. latche i mutexy. W efekcie ciągłe podnoszenie wielkości pamięci SGA (a w ramach niej bufora BUFFER CACHE), prowadzi często do sytuacji wyglądającej teoretycznie absurdalnie – zapytania wykonywane z wielu sesji jednocześnie, odpowiadają szybciej, kiedy czytają z dysku niż kiedy walczą o blokady na poziomie dużych obszarów pamięci współdzielonej! 
Firma Oracle zaadresowała ten problem w funkcjonalności In-Memory, dostępnej wraz z bazą 12.1.0.2 EE (oczywiście za dodatkową opłatą). 
Opcja In-Memory pozwala trzymać w pamięci kolumnową reprezentację tabel w postaci skompresowanej, co zdecydowanie przyspiesza wszelkie zapytania analityczne, wykonujące się równolegle. 

Koprocesory DAX

Na procesorach Intel, Oracle wykorzystuje rejestry SIMD w celu akceleracji wykonania zapytań analitycznych In-Memory – nowy SPARC M7 dostarczył jednak czegoś znacznie ciekawszego – specjalnych koprocesorów DAX (data analytics accelerator), które stanowią implementację idei „software in silicon”. 

Koprocesory DAX wykonują sprzętowo operacje bezpośredniego dostępu do pamięci, dekompresji danych algorytmem OZIP i umieszczają wyniki bezpośrednio w warstwie cache L3 procesora. 
Każdy procesor M7 ma 8 koprocesorów DAX a każdy koprocesor posiada 4 tzw. „query pipelines”, które są właściwymi narzędziami akceleracji zapytań In-Memory. 

Offloading zapytań In-Memory dotyczy następujących funkcjonalności:
•  Złączenia typu HASH JOIN
•  Predykaty klauzuli WHERE 
•  Dekompresja i kompresja algorytmem OZIP używanym przez klauzulę: MEMCOMPRESS FOR QUERY HIGH 

Jednym z pierwszych pytań, które sobie zadałem w trakcie testów brzmiało: „Skąd mam wiedzieć, kiedy DAX jest uruchamiany?” 
Na szczęście system operacyjny Solaris jest wyposażony w niezwykle przydatne narzędzie – DTrace. Narzędzie to może zostać wykorzystane do dynamicznego śledzenia przebiegu skompilowanych programów, pozwalając nam na odkrycie ich niskopoziomowych sekretów. 

Zachęcam do przeczytania krótkiego tutoriala na temat podstaw używania narzędzia DTrace.

W części drugiej artykułu zamieścimy testy porównawcze czasu odpowiedzi dla procesorów SPARC M7, Intel® Xeon® X5670 (2.93 GHz), Intel® Xeon® E5-2699 v3 (2.3 GHz) oraz IBM Power 8.

Brak komentarzy:

Prześlij komentarz