Umieszczanie dzienników ponawiania Oracle na DRAM SSD w celu intensywnego zapisu bazy danych?

9

Mam Sun M4000 podłączony do macierzy EMC CX4-120 z bazą danych obciążoną do zapisu. Zapisuje szczyt przy około 1200 IO / si 12 MB / s.

Według EMC nasycam pamięć podręczną zapisu w macierzy EMC.

Myślę, że najprostszym rozwiązaniem jest przeniesienie dzienników powtórzeń na dysk SSD oparty na pamięci DRAM. Zmniejszy to obciążenie macierzy EMC o połowę, a aplikacje nie będą widzieć bufora dziennika. Tak, DBWR może stać się wąskim gardłem, ale aplikacje nie będą na to czekać (tak jak robią to po ponownym zatwierdzeniu!)

Obecnie przeglądam około 4 dzienników przeróbek 4 GB, więc nawet 20 GB SSD zrobiłoby dużą różnicę. Ponieważ jest to pamięć krótkotrwała i jest ciągle nadpisywana, dyski SSD Flash nie są prawdopodobnie dobrym pomysłem.

M4000 nie ma żadnych dodatkowych partii dysków, więc karta PCI-E byłaby idealna, mogłem przejść na zewnątrz lub przenieść woluminy rozruchowe do EMC i zwolnić dyski lokalne.

Firma Sun sprzedaje kartę PCIe Flash Accelerator F20, ale wydaje się, że jest to pamięć podręczna dla niektórych dysków SATA, a nie rozwiązanie DRAM SSD. Szczegóły są pobieżne, nie zawiera M4000 jako obsługiwanego, a ja jestem zmęczony walką z drzewem telefonicznym Suna w poszukiwaniu ludzkiej pomocy. :(

Czy inni zgadzają się, że najlepszym rozwiązaniem jest dysk DRAM SSD? Jakieś rekomendacje dotyczące sprzętu?

AKTUALIZACJA Oprócz informacji zawartych w komentarzu poniżej, wypróbowałem różne ustawienia dla „commit_write” i to nie miało znaczenia.

rmeden
źródło
Czy gdzieś archiwizujesz dzienniki? Jeśli ostatecznie będą musiały zostać skopiowane z dysku SSD na dysk, możesz po prostu przenieść wąskie gardło do archiwizacji.
Gary
Tak ... dzienniki ponawiania są archiwizowane, a IO faktycznie zwiększa się do około 80 MB / s podczas kopiowania dzienników ponawiania, ponieważ jest to zapis sekwencyjny. Zawsze myślałem, że ponowne wykonywanie dzienników jest sekwencyjne, ale nie sądzę.
rmeden

Odpowiedzi:

9

Po pierwsze - myślę, że masz bardzo mało dysków w macierzy. 1200IOPS może być łatwo obsługiwany przez 12 wirujących dysków (100 IOPS na dysk jest bardzo rozsądne). Jeśli pamięć podręczna nie może sobie z tym poradzić, oznacza to, że twoja trwała szybkość zapisu wynosząca 1200 IOPS jest znacznie większa niż twoje dyski są w stanie obsłużyć.

W każdym razie SSD dla dzienników powtórzeń raczej nie pomoże. Po pierwsze, czy twoja sesja czeka głównie na instrukcję COMMIT? Sprawdź zdarzenia największego oczekiwania w statspack / AWR, aby je zweryfikować. Wydaje mi się, że ~ 95% twoich operacji we / wy w ogóle nie dotyczy dzienników ponownych. Na przykład wstawianie jednego wiersza do tabeli z 5 indeksami może wykonać 1 We / Wy, aby odczytać blok tabeli (który ma miejsce na wiersz), odczytać 5 bloków indeksu (aby je zaktualizować), zapisać 1 blok danych, 1 cofnąć blok i 5 bloków indeksu (lub więcej, jeśli bloki nieskrzydłe są aktualizowane) i 1 blok powtórzenia. Tak więc sprawdź statspack i zobacz zdarzenia oczekiwania, prawdopodobnie czekasz zarówno na CZYTANIE, jak i NAPISY na dane / indeksy. Oczekiwanie na odczyt spowalnia INSERT, a działanie WRITE powoduje, że READs są jeszcze wolniejsze - są to te same dyski (BTW - czy naprawdę potrzebujesz wszystkich indeksów? Upuszczenie tych, którzy nie muszą, przyspieszy wstawianie).

Kolejną rzeczą do sprawdzenia jest definicja RAID - czy to RAID1 (dublowanie - każdy zapis to dwa zapisy) lub RAID 5 (każdy zapis to 2 odczyty i dwa zapisy do obliczenia sumy kontrolnej). RAID 5 jest znacznie wolniejszy przy obciążeniu intensywnie zapisującym.

BTW - jeśli dyski nie mogą obsłużyć obciążenia zapisu, DBWR będzie wąskim gardłem. Twój SGA będzie pełen brudnych bloków i nie będziesz miał miejsca na czytanie nowych bloków (takich jak bloki indeksu, które muszą zostać przetworzone / zaktualizowane), dopóki DBWR nie może zapisać brudnych bloków na dyskach. Ponownie sprawdź statspack / awr report / addm, aby zdiagnozować, co jest wąskim gardłem, zwykle w oparciu o 5 najważniejszych zdarzeń oczekiwania.

Ofir Manor
źródło
1
+1 - i dałbym to +10, gdybym mógł.
Helvick
2
+1 za poradę, aby dowiedzieć się, gdzie jest wąskie gardło.
DCookie
Oczekiwania to „synchronizacja pliku dziennika” i „przestrzeń buforu dziennika”. Za pomocą DD mogę uzyskać około 150 MB / s do woluminu. Podejrzewam, że LGWR czeka na zakończenie IO przed przesłaniem następnego. Czas usługi IO wynosi około 1ms. EMC ma aż 500 MB pamięci podręcznej, co według EMC nie może zostać zwiększone bez aktualizacji całego pudełka. Mamy 22 TB w tablicy, dlaczego nie oferują mi czegoś z tak małą pamięcią podręczną. Dzienniki ponawiania znajdują się obecnie w RAID 5 o szerokości 5, ale nie było różnicy z RAID 10 (kolejny powód, by podejrzewać pamięć podręczną)
rmeden
BTW, jeśli było więcej pamięci podręcznej, dysk nadal może nie nadążyć. Poprzez przeniesienie REDO poza macierz EMC, która zwalnia pojemność dysków z danymi i zmniejsza I / O o połowę. Mały dysk SSD DRAM może być najtańszym dyskiem o wysokiej wydajności, ponieważ może być mały.
rmeden
meden - ile przeróbek pisze Oracle na sekundę? powiedziałeś, że całkowite I / O to 12 MB / si 1200 IOPS, co oznacza wiele małych IO (średnio 10 KB). Jeśli przeniesiesz dzienniki powtórzeń na dysk SSD, zobaczysz tylko różne zdarzenia oczekiwania, ponieważ DBWR stanie się wąskim gardłem, a INSERT będzie czekać na wolny bufor w SGA. Proszę sprawdzić - jaki macie macierz RAID, jaki jest rozmiar paska i jaki jest rozmiar bloku Oracle (również, czy wasze pliki danych są rozłożone na wszystkich dyskach?). Sprawdź także statspack źródło dla większości operacji we / wy - czy to przeróbka, czy coś innego - sprawdź operacje we / wy według przestrzeni tabel
Ofir Manor
2

dd jest niczym w porównaniu do bloku we / wy.

W przypadku niektórych innych widoków sprawdź, anandtech.com wykonał dokładny test (przyznany z serwerem MS SQL) z obrotowym SAS vs SSD, w różnych kombinacjach, a świat Solaris ma ZFS z SSD tworzącym różne części (logi, pamięć podręczna itp.) ).

Ale tak, jeśli RAID 5 vs RAID 10 jest taki sam (w przypadku zapisu), robisz coś złego. W przypadku zapisu liniowego, do cholery RAID 5 może być szybszy (tzn. Może wykonać parzystość w pamięci, a następnie zapisać paski i parzystość jednocześnie), ale przy losowym małym bloku (4-8k), zabijamy cię poprzez aktualizację pasków (jako zauważone przez innych), nalot 10 powinien być ponad dwukrotnie szybszy, jeśli nie, coś jest nie tak.

Musisz wydobywać głębiej, zanim wydasz pieniądze na sprzęt.

Ronald Pottol
źródło
2

Widziałem post na temat montowania partycji UFS przy użyciu opcji „forceirectio” i ustawiania parametru Oracle „filesystemio_options” na „setall”.

Wypróbowałem to i zobaczyłem 4-5-krotną poprawę w zapisach Oracle! Tak!

Kluczowymi objawami były niska przepustowość, ale dobre czasy reakcji na dysku. To wydaje się pomagać niektórym ludziom, ale innym nie. Z pewnością spełniło to moje zadanie.

Mogę rozważyć użycie dysków SSD dla nowych serwerów, ale ten serwer działa teraz dobrze.

Robert

rmeden
źródło
Najprawdopodobniej przyspieszenie, którego doświadczyłeś, nie było spowodowane włączeniem bezpośrednich we / wy, ale włączeniem asynchronicznych we / wy. W Oracle setall oznacza bezpośrednie + asynchroniczne.
kubańczyk
1

Gdyby to pudełko było tylko Linuxem z procesorem x86 / 64, z radością poleciłbym jedną z kart napędów FusionIO PCIe - są zadziwiająco szybkie i nie „giną” przy ciężkich zapisach jak na dyskach SSD. Niestety nie są obsługiwane przez Sparc ani Solaris, możesz jednak skontaktować się z nimi w celu omówienia tego.

Siekacz 3
źródło
1

Karta PCIe F20e jest podobna do funkcji we / wy Fusion. Zasadniczo jest to tylko dysk Flash SSD podłączony do PCIe. Przy pisaniu dużego obciążenia trzeba będzie się martwić zarówno o utrzymanie wystarczającej liczby wolnych bloków (poprzez pewnego rodzaju usuwanie śmieci na podstawie dysku), aby nie skończyć z cyklem Wymazywanie / Program na dysku SSD, który staje się wąskim gardłem, a także ograniczone cykle zapisu dostępne na dyskach SSD Flash. Jest zdecydowanie szybki, ale może nie być najlepszym zestawem do tej pracy.

Jan
źródło
tks John. Nie sądziłem, że to zadziała dla mnie. Sun nawet nie obsługuje tego na M4000. :(
rmeden