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

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.

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.

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.

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

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.

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.