W ślad za zeszłomiesięcznym Tuning Linux dla niskich opóźnień PostgreSQL, teraz wykonano gigantyczny stos testów na dwóch systemach plików, trzech łatach i dwóch zestawach parametrów dostrajania jądra. Wynikiem jak dotąd jest kilka interesujących nowych danych i jeszcze jedno wprowadzone usprawnienie w tym obszarze, które jest teraz w PostgreSQL 9.1 (łącznie trzy, pozostałe dwie to łatki monitorujące). O zalecanych praktykach opowiem w przyszłym miesiącu podczas jednej z moich prelekcji na PostgreSQL East, a także zgłosiłem coś w tym zakresie na majowy PGCon. Tutaj powiem też trochę więcej o ślepych zaułkach, podczas gdy te wspomnienia są wciąż świeże.
Podstawowym problemem jest to, że sposób, w jaki PostgreSQL wykorzystuje pamięć podręczną systemu operacyjnego podczas pisania, pozwala na gromadzenie dużych ilości danych. Wynikiem zakończenia punktów kontrolnych bazy danych może być duże opóźnienie w oczekiwaniu na zapisanie danych. Okazuje się, że program pgbench, który jest dostarczany z PostgreSQL, jest naprawdę dobry w tworzeniu tego problemu, więc tego właśnie używałem do wszystkich testów. Pytania dotyczące środków, na które chciałem odpowiedzieć, były następujące:
- Czy zmiana ze starego systemu plików ext3 rzeczywiście pokazuje poprawę wydajności zadań bazy danych? Napisałem coś o powrocie XFS na Linuksie w zeszłym roku, co wykazało niezłą poprawę w prostych testach porównawczych. To jednak nie zawsze przekłada się na ulepszenia bazy danych.
- Czy ostatnie strojenie linuksowe dirty_bytes i dirty_background_bytes naprawdę poprawiają opóźnienia w najgorszym przypadku?
- Które zmiany w bazie danych sugerowane w celu poprawy zachowania faktycznie działają?
Możesz zobaczyć wszystkie wyniki testu, jeśli chcesz sprawdzić surowe dane. To, co zostało zmienione dla każdego zestawu testów, jest udokumentowane, a jeśli przejdziesz do pojedynczego testu, zobaczysz użyte parametry bazy danych i kilka innych podstawowych informacji o systemie operacyjnym. Ta strona internetowa jest tym, co wychodzi z mojego programu testującego pgbench-tools, jeśli chcesz sam spróbować tego typu rzeczy.
Wyniki nie były zbyt zaskakujące, ale były interesujące. Wszystkie testy zostały tutaj wykonane z dwoma rozmiarami bazy danych. Przy mniejszym rozmiarze bazy danych (scale=500, około 8 GB bazy danych, która z łatwością mieści się w 16 GB pamięci RAM serwera), ext3 zarządzał 690 transakcjami na sekundę, podczas gdy przy dwukrotnie większym rozmiarze (scale=1000, około 16 GB bazy danych) było to znacznie więcej szukaj związanych i zarządzanych tylko 349 TPS. XFS zwiększył te dwie liczby do 1757 TPS i 417 TPS – odpowiednio o 255% i 19%. Co więcej, opóźnienie w najgorszym przypadku dla pojedynczej transakcji spadło z zakresu od 34 do 56 sekund (!) do zakresu od 2 do 5 sekund. Chociaż nawet 5 sekund nie jest świetne, jest to syntetyczne obciążenie, które ma sprawić, że ten problem będzie naprawdę poważny. Liczby ext3 są tak okropne, że nadal możesz napotkać nieprzyjemny problem, mimo że faktycznie widziałem lepsze zachowanie na tym systemie plików niż we wcześniejszych jądrach (zostało to zrobione w 2.6.32).
Runda 1: XFS wygrywa w osuwisku. Nie mogę polecić ext3 jako realnego systemu plików w systemach Linux z dużą ilością pamięci, jeśli planujesz intensywnie pisać; to po prostu nie działa w tym kontekście. Ten serwer miał tylko 16 GB pamięci RAM, więc możesz sobie wyobrazić, jak poważny jest ten problem na poważnym serwerze produkcyjnym tutaj w 2011 roku.
Następnie strojone są dirty_bytes i dirty_background_bytes. Te dwa poprawiły nieco opóźnienia na ext3, kosztem niektórych spowolnień. Najgorszego z nich, spowolnionego czasu konserwacji z włączonym VACUUM, nie widać w samych wynikach testów; Omówiłem to już we wcześniejszym wpisie na blogu. W XFS obniżenie tych parametrów to katastrofa wydajności. Przy mniejszej skali bazy danych wydajność TPS spada o 46%, a ponadto opóźnienia faktycznie się pogarszają.
Runda 2: Nie oczekuj żadnych cudów od brudnych_bajtów lub brudnych_tła_bajtów. Wydaje się, że w niektórych okolicznościach mają one pozytywny wpływ, ale potencjalne wady są również duże. Upewnij się, że testujesz dokładnie i uwzględnij VACUUM w swoich testach, zanim zmienisz te dwa w dół.
Następnie w ramach ostatniego CommitFestu oceniłem trzy pomysły na poprawki do PostgreSQL:
- Rozpowszechniaj synchronizację punktów kontrolnych na dysku (fsync) w miarę upływu czasu. Odnieśliśmy pewien sukces na zajętym serwerze klienckim w połączeniu z poprawioną obsługą sposobu, w jaki inne operacje synchronizacji były buforowane przez bazę danych
- Kompaktowe żądania fsync. Pomysł ten wyrósł z pierwszego i przekształcił się w łatkę napisaną przez Roberta Haasa. Pomysł polega na tym, że klienci próbujący synchronizować dane na dysku mogą konkurować z zapisem w punkcie kontrolnym. Łatka pozwala klientom oczyścić kolejkę żądań fsync, jeśli kiedykolwiek uznają, że jest pełna.
- Sortuj zapisy w punktach kontrolnych. Koncepcja polega na tym, że jeśli zapiszesz rzeczy w kolejności, w jakiej baza danych uważa, że są one przechowywane na dysku, system operacyjny może pisać wydajniej. Ta łatka pojawiła się kilka lat temu, a niektóre wyniki testów sugerują, że działała, ale w tym czasie nikt nie był w stanie powtórzyć ulepszeń. Pomysł pasował do reszty pracy na tyle dobrze, że ponownie go oceniłem.
Runda 3:Po tygodniach prób, jedynym podejściem z tego zestawu, które wykazało poprawę przy prawie wszystkich rozmiarach obciążenia, było podejście do kompaktowania fsync. Oryginalny kod synchronizacji punktu kontrolnego rozprzestrzeniania się pomógł w tym obszarze, ale konkretna implementacja, która jest teraz zatwierdzona dla wersji 9.1, działała jeszcze lepiej. Był to prawie 10% wzrost w przypadku większości testów, które przeprowadziłem z dużym obciążeniem zapisem. To wspaniałe ulepszenie dla PostgreSQL 9.1 i powinno całkowicie wyeliminować problem, który spowodował znacznie większe spowolnienie w systemach produkcyjnych tutaj.
Reszta pomysłów tutaj nie uzyskała tak pozytywnej oceny po ciężkich benchmarking, więc na razie te wracają na półkę. Będę nadal zbierać dane tutaj - niektóre testy ext4 są kolejną logiczną rzeczą do wypróbowania - a potem wrócę do rozwoju. Uzyskanie 10% zysku na niektórych trudnych obciążeniach jest z pewnością przyjemne, ale wciąż jest tu zbyt wiele najgorszych zachowań, aby uznać problemy z synchronizacją punktów kontrolnych za zamknięty temat.
