Zachęcam do zapoznania się z interpretacją raportu Nikołaja Samochwałowa „Przemysłowe podejście do tuningu PostgreSQL: eksperymenty nad bazami danych”
Shared_buffers = 25% – czy to dużo, czy mało? A może w sam raz? Jak zrozumieć, czy ta – dość przestarzała – rekomendacja pasuje do twojego konkretnego przypadku?
Nadeszła pora, by podejść do kwestii doboru parametrów postgresql.conf „na poważnie”. Nie przy pomocy ślepych „autotuners” ani przestarzałych porad z artykułów i blogów, lecz na podstawie:
- stricte przeprowadzonych eksperymentów na bazach danych, realizowanych automatycznie, w dużych ilościach i w warunkach maksymalnie zbliżonych do „bojowych”,
- głębokiego zrozumienia specyfiki działania systemów baz danych i systemu operacyjnego.
Korzystając z Nancy CLI (), przyjrzymy się konkretnemu przykładzie – słynne shared_buffers – w różnych sytuacjach, w różnych projektach, i spróbujemy zrozumieć, jak dobrać optymalne ustawienia dla naszej infrastruktury, baz danych i obciążenia.
Będzie mowa o eksperymentach nad bazami danych. To historia, która trwa już nieco ponad pół roku.
Kilka słów o mnie. Doświadczenie z Postgrem mam już ponad 14 lat. Utworzyłem kilka firm zajmujących się sieciami społecznościowymi. Wszędzie był i jest wykorzystywany Postgres.
Również grupa RuPostgres na Meetup zajmuje 2. miejsce na świecie. Powoli zbliżamy się do 2000 osób. RuPostgres.org.
Na różnych konferencjach, w tym Highload, odpowiadam za bazy danych, w szczególności za Postgres od samego początku.
W ciągu ostatnich kilku lat wznowiłem moją praktykę związaną z konsultingiem w dziedzinie Postgresa w 11 strefach czasowych tutaj.
Kiedy zrobiłem to kilka lat temu, miałem pewną przerwę w aktywnej pracy z Postgrem, prawdopodobnie od 2010 roku. Byłem zaskoczony, jak mało zmieniły się codzienne obowiązki DBA, wciąż wymaga się dużo ręcznej pracy. Od razu pomyślałem, że coś jest nie tak, trzeba zautomatyzować więcej.
Ponieważ wszystko działo się w trybie zdalnym, większość klientów znajdowała się w chmurze. Już wiele zautomatyzowano, co było oczywiste. O tym trochę później. Tzn. wszystko to doprowadziło do myśli, że powinno być kilka narzędzi, tzn. pewna platforma, która zautomatyzuje praktycznie wszystkie działania DBA, aby można było zarządzać dużą ilością baz.
W tym raporcie nie będzie:
- „Złotych środków” ani stwierdzeń typu – postawcie 8 GB lub 25% shared_buffers, a będziecie zadowoleni. O shared_buffers nie będzie zbyt wiele.
- Czujne "wnętrzności".
Co będzie dalej?
- Będą zasady optymalizacji, które stosujemy i rozwijamy. Pojawią się różne pomysły, które będą się rodzić na naszej drodze, oraz różne narzędzia, które tworzymy w większości jako Open Source, tzn. podstawy robimy w Open Source. Co więcej, mamy zgłoszenia, prawie całe nasze komunikowanie się odbywa w Open Source. Możecie obserwować, co aktualnie robimy, co będzie w następnej wersji itp.
- Będzie też pewne doświadczenie w stosowaniu tych zasad oraz narzędzi w różnych firmach: od małych startupów po duże korporacje.
Jak to wszystko się rozwija?
Przede wszystkim, głównym zadaniem DBA, oprócz zapewnienia tworzenia instancji, wdrażania kopii zapasowych itp., jest identyfikacja wąskich gardeł i optymalizacja wydajności.
Obecnie wszystko działa w ten sposób. Obserwujemy monitorowanie, widzimy coś, czegoś brakuje. Zaczynamy drążyć głębiej, zazwyczaj ręcznie, aby zrozumieć, co z tym zrobić w taki czy inny sposób.
Istnieją dwa podejścia. Pg_stat_statements – standardowe rozwiązanie domyślne do identyfikacji wolnych zapytań. I analiza logów Postgres za pomocą pgBadger.
Każde z podejść ma poważne wady. W pierwszym podejściu wszystkie parametry są zignorowane. Jeśli widzimy grupy SELECT * FROM table where kolumna równa się znakowi „?” lub „$” od wersji Postgres 10. Nie wiemy – czy to skanowanie indeksu, czy skanowanie sekwencyjne. To bardzo mocno zależy od parametru. Podstawisz tam rzadko występującą wartość, będzie to skanowanie indeksu. Podstawisz wartość, która zajmuje 90 % tabeli, będzie to oczywiście skanowanie sekwencyjne, ponieważ Postgres zna statystyki. I to jest poważna wada pg_stat_statements, chociaż prowadzone są jakieś prace.
Główną wadą analiz logów jest to, że nie możecie sobie pozwolić na „log_min_duration_statement = 0”, w większości przypadków. O tym również porozmawiamy. W związku z tym nie widzicie całego obrazu. Jakieś zapytanie, które jest bardzo szybkie, może wykorzystywać ogromną ilość zasobów, ale go nie zobaczycie, ponieważ jest poniżej waszego progu.
Jak DBA rozwiązują zidentyfikowane problemy?
Na przykład, napotkaliśmy jakiś problem. Co zazwyczaj się robi? Jeśli jesteś deweloperem, będziesz pracować nad jakimś instance, który nie jest zbyt duży. Jeśli jesteś DBA, masz staging. I może być tylko jeden. I on jest spóźniony o pół roku. A ty myślisz, że pójdziesz na produkcję. Nawet doświadczeni DBA sprawdzają potem na produkcji, na replikacji. Czasem tworzą tymczasowy indeks, upewniają się, że pomaga, usuwają go i oddają deweloperom, aby umieścili go w plikach migracyjnych. Taki absurd się teraz dzieje. I to jest problem.
- Dostosowywać konfiguracje.
- Optymalizować zestaw indeksów.
- Zmieniać sam SQL (to najtrudniejszy sposób).
- Dodawać moc (najprostszy sposób w większości przypadków).
Z tymi rzeczami jest bardzo dużo. Jest wiele narzędzi w Postgresie. Trzeba dużo wiedzieć. W Postgresie jest wiele indeksów, między innymi dzięki organizatorom tej konferencji. I wszystko to trzeba znać, i to właśnie wywołuje u nie-DBA wrażenie, że DBA zajmują się czarną magią. Tzn. trzeba poświęcić około 10 lat, aby zacząć to wszystko dobrze rozumieć.
I ja jestem przeciwnikiem tej czarnej magii. Chcę, aby była technologia, a nie intuicja w tym wszystkim.
Przykłady z życia
Obserwowałem to przynajmniej w dwóch projektach, w tym moim. Kolejny wpis na blogu informuje nas, że wartość 1 000 dla default_statistict_target to dobrze. Dobrze, spróbujmy w produkcji.
I tutaj, używając naszego narzędzia dwa lata później w wyniku eksperymentów nad bazami danych, o których dzisiaj mówimy, możemy porównać co było i co się zmieniło.
I w tym celu musimy stworzyć eksperyment. Składa się on z czterech części.
- Pierwsza – to środowisko. Potrzebujemy sprzętu. I kiedy przychodzę do jakiejś firmy i podpisuję umowę, mówię, aby dawali mi taki sam sprzęt jak na produkcji. Dla każdego z waszych Mistrzów potrzebuję przynajmniej jeden taki sam sprzęt. Może to być wirtualna maszyna instance w Amazonie lub w Google, lub potrzebuję dokładnie takiego samego sprzętu. Tzn. chcę odtworzyć środowisko. A w pojęcie środowiska włączamy główną wersję Postgresa.
- Druga część – to obiekt naszych badań. To baza danych. Można ją stworzyć na kilka sposobów. Pokażę jak.
- Trzecia część – to obciążenie. To najtrudniejszy moment.
- Czwarta część to to, co sprawdzamy, tzn. z czym będziemy porównywać. Możemy zmienić jeden lub kilka parametrów w konfiguracji lub możemy utworzyć indeks.
Rozpoczynamy eksperyment. Oto pg_stat_statements. Po lewej – to, co było. Po prawej – co się zmieniło.
Po lewej default_statistics_target = 100, po prawej = 1 000. Widzę, że to nam pomogło. Ogólnie wszystko poprawiło się o 8 %.
Ale jeśli przewiniemy w dół, zobaczymy grupy zapytań z pgBadger lub pg_stat_statements. Są dwa scenariusze. Zobaczymy, że jakieś zapytanie spadło o 88 %. I wtedy już musimy podejść inżynieryjnie. Możemy zbadać sprawę dalej, bo interesuje nas, dlaczego spadło. Musimy zrozumieć, co działo się ze statystyką. Dlaczego większa liczba koszyków w statystyce prowadzi do gorszego wyniku.
Możemy nie badać, a po prostu wykonać «ALTER TABLE… ALTER COLUMN» i przywrócić mu 100 koszyków w statystyce tej kolumny. Dalszym eksperymentem możemy się upewnić, że ta poprawka pomogła. I to wszystko. To jest inżynieryjne podejście, które pozwala nam widzieć całość i podejmować decyzje na podstawie danych, a nie intuicji.
Kilka przykładów z innych obszarów. W testach CI istnieją już od wielu lat. Żaden projekt w zdrowym rozsądku nie będzie funkcjonował bez testów automatycznych.
W innych branżach: w lotnictwie, w motoryzacji, kiedy testujemy aerodynamikę, również mamy możliwość przeprowadzania eksperymentów. Nie będziemy od razu wysyłać czegoś na orbitę na podstawie rysunku ani wprowadzać samochodu na trasę. Na przykład, mamy tunel aerodynamiczny.
Na podstawie obserwacji w innych branżach możemy wyciągnąć wnioski.
Po pierwsze, mamy specjalne środowisko. Jest bliskie produkcji, ale nie jest tym samym. Jego główną cechą jest to, że musi być tanie, powtarzalne i maksymalnie zautomatyzowane. Dodatkowo muszą być specjalne narzędzia do przeprowadzania szczegółowej analizy.
Najprawdopodobniej, kiedy uruchamiamy samolot i latamy, mamy mniej możliwości badania każdego milimetra powierzchni skrzydła niż w tunelu aerodynamicznym. Dysponujemy większymi środkami do diagnostyki. Możemy sobie pozwolić na dodatkowe ciężkie sprzęty, które nie mogłyby zostać umieszczone w samolocie w powietrzu. Podobnie jest z Postgresem. W niektórych przypadkach możemy włączyć pełne logowanie zapytań podczas eksperymentów. A tego na produkcji nie chcemy robić. Możliwe, że nawet w planach włączymy to za pomocą auto_explain.
I jak już powiedziałem, wysoki poziom automatyzacji oznacza, że naciśniesz przycisk i powtórzysz. Tak to powinno wyglądać, aby było wiele eksperymentów i aby to było na bieżąco.
Nancy CLI – fundament „laboratorium baz danych”
I oto stworzyliśmy coś takiego. Tzn. o tych pomysłach mówiłem w czerwcu, prawie rok temu. I już mamy w Open Source tzw. Nancy CLI. To fundament do budowania laboratorium baz danych.
– Jest to w Open Source, na Gitlab. Możecie powiedzieć, możecie spróbować. Dałem link w slajdach. Można w niego kliknąć i tam będzie we wszystkich parametrach.
Oczywiście, wiele rzeczy jest jeszcze w fazie rozwoju. Jest wiele pomysłów. Ale to już jest coś, czego używamy właściwie codziennie. I kiedy mamy pomysł – co się dzieje, gdy usuwamy 40 000 000 wierszy, gdzie wszystko utknęło w IO, możemy przeprowadzić eksperyment i przyjrzeć się bliżej, aby zrozumieć, co się dzieje, a potem spróbować to naprawić w locie. Tzn. przeprowadzamy eksperyment. Na przykład, coś zmieniamy i patrzymy, co z tego wynika. I robimy to nie na produkcji. To jest sedno idei.
Gdzie to może działać? Może to działać lokalnie, tzn. można to robić wszędzie, można nawet uruchomić to na MacBooku. Potrzebny jest Docker, jedziemy. I już. Można uruchomić na jakimś instancie na sprzęcie, albo w wirtualce, gdziekolwiek.
Istnieje również możliwość uruchamiania na Amazonie na instancji EC2, w spotach. To naprawdę świetna opcja. Na przykład, wczoraj przeprowadziliśmy ponad 500 eksperymentów na instancji i3, od najniższej do i3-16-xlarge. Kosztowało nas to 500 eksperymentów tylko 64 dolary. Każdy trwał 15 minut. Dzięki temu, że używane są spoty, to bardzo tanio – zniżka 70%, rozliczanie na podstawie sekund przez Amazon. Można zrobić naprawdę wiele. Można przeprowadzać rzeczywiste badania.
Wspierane są trzy główne wersje Postgresa. Nie jest tak trudno dodać jakieś starsze oraz nową wersję 12.
Możemy definiować obiekt na trzy sposoby. Oto one:
- Dump / plik sql.
- Głównym sposobem jest klonowanie katalogu PGDATA. Zazwyczaj pobiera się go z serwera kopii zapasowej. Jeśli masz normalne kopie zapasowe binarne, możesz stamtąd robić klony. Jeśli korzystasz z chmury, wówczas taka chmurowa firma jak Amazon czy Google zrobi to za Ciebie. To jest główny sposób na klonowanie rzeczywistego środowiska produkcyjnego. W ten sposób w rzeczywistości rozstawiamy.
- Ostatni sposób nadaje się do badań, gdy chcemy zrozumieć, jak coś działa w Postgresie. To jest pgbench. Możesz go wygenerować za pomocą pgbench. To po prostu jedna opcja „db-pgbench”. Mówisz mu, jaki zestaw danych. A wszystko będzie wygenerowane w chmurze, jak to zostało powiedziane.
I obciążenie:
- Obciążenie możemy wykonać w jednym wątku SQL. To najprostszy sposób.
- Możemy również emulować obciążenie. A emulację możemy przede wszystkim przeprowadzić w następujący sposób. Musimy zebrać wszystkie logi. I to jest bolesne. Pokażę, dlaczego. A następnie odtwarzamy je za pomocą pgreplay, który jest wbudowany w Nancy.
- Lub inna opcja. Tzw. rzemieślnicze obciążenie, które tworzymy z pewną ilością wysiłku. Analizując nasze aktualne obciążenie w systemie produkcyjnym, wybieramy najlepsze grupy zapytań. A przy pomocy pgbench możemy emulować to obciążenie w laboratorium.
- Albo musimy wykonać jakieś SQL, tzn. sprawdzamy jakąś migrację, tworzymy indeks, wykonujemy ANALYZE. I patrzymy, co było przed a po vacuums. Ogólnie, dowolny SQL.
- Możemy zmienić jeden lub kilka parametrów w konfiguracji. Możemy poprosić, aby sprawdzono na przykład 100 wartości na Amazonie dla naszej bazy danych terabajtowej. I po kilku godzinach otrzymasz wynik. Z reguły rozłożenie terabajtowej bazy zajmuje kilka godzin. Ale w rozwoju jest poprawka, mamy możliwość serii, tzn. możesz kolejno na tym samym serwerze używać tej samej pgdata i przeprowadzać kontrole. Postgres będzie restartowany, cache będzie czyszczony. I możesz testować obciążenie.
- Przyjeżdża katalog z wieloma różnymi plikami, zaczynając od zrzutów pgstat***. A tam najciekawsze – to pg_stat_statements, pg_stat_kcache. To dwa rozszerzenia, które analizują zapytania. I pg_stat_bgwriter zawiera nie tylko statystyki pgwriter, ale również statystyki związane z checkpointami i z tym, jak same backendy wypychają brudne bufory. I to wszystko jest ciekawe do obejrzenia. Na przykład, kiedy konfigurujemy shared_buffers, warto zobaczyć, ile tam kto wypchnął.
- Przyjeżdżają również logi Postgresa. Dwa logi – log przygotowania i log odtwarzania obciążenia.
- Stosunkowo nowa funkcja – to FlameGraphs.
- Dodatkowo, jeśli korzystałeś z pgreplay lub pgbench, aby odtwarzać obciążenie, to pojawi się ich rodzimy wynik. Będziesz mógł zobaczyć opóźnienie i TPS. Będzie można zrozumieć, jak to widzieli.
- Informacje o systemie.
- Podstawowe kontrole CPU i IO. To bardziej dla instancji EC2 w Amazonie, gdy chcesz uruchomić 100 identycznych instancji i przeprowadzić na nich 100 różnych testów, będziesz mieć 10 000 eksperymentów. Musisz upewnić się, że nie trafiłeś na wadliwą instancję, która jest już tłamszona przez kogoś innego. Na tym sprzęcie inni są aktywni i masz mało zasobów. Takie wyniki lepiej odrzucić. I właśnie przy pomocy sysbench od Aleksieja Kopytowa robimy kilka krótkich testów, które przybędą i można je porównać z innymi, tzn. zrozumiesz, jak zachowuje się CPU i jak zachowuje się IO.
Jakie są techniczne trudności w przykładowych firmach?
Załóżmy, że chcemy powtarzać rzeczywiste obciążenie za pomocą logów. Doskonały pomysł, jeśli jest napisany w Open Source pgreplay. Używamy go. Ale aby działał dobrze, musisz włączyć pełne logowanie zapytań z parametrami i czasem.
Są pewne trudności związane z duration i timestamp. Pomińmy tę kwestię. Główne pytanie brzmi – czy możesz sobie na to pozwolić, czy nie?
Problem polega na tym, że może to być niedostępne. Przede wszystkim musisz zrozumieć, jaki strumień będzie zapisywany w logu. Jeśli masz pg_stat_statements, możesz takim zapytaniem (link będzie dostępny w slajdach) określić, ile mniej więcej bajtów będzie zapisywanych na sekundę.
Patrzymy na długość zapytania. Ignorujemy fakt, że nie ma parametrów, ale znamy długość zapytania i wiemy, ile razy na sekundę jest wykonywane. W ten sposób możemy oszacować, ile mniej więcej bajtów na sekundę. Możemy się pomylić o czynnik dwa, ale na pewno zrozumiemy to w ten sposób.
Możemy zobaczyć, że to zapytanie jest wykonywane 802 razy na sekundę. I widzimy, że bytes_per sec – 300 kB/s będzie zapisywane plus minus. I zazwyczaj możemy sobie pozwolić na taki strumień.
Ale! Chodzi o to, że są różne systemy logowania. Domyślnie ludzie mają zazwyczaj „syslog”.
I jeśli masz syslog, to możesz zobaczyć coś takiego. Weźmiemy pgbench, włączymy logowanie zapytań i zobaczymy, co się dzieje.
Bez logowania – to lewy słupek. Osiągnęliśmy 161 000 TPS. Z syslog – to w Ubuntu 16.04 w Amazonie osiągamy 37 000 TPS. A jeśli zmienimy na dwa inne sposoby logowania, sytuacja będzie znacznie lepsza. To znaczy, spodziewaliśmy się spadku, ale nie aż tak dużego.
A na CentOS 7, gdzie jeszcze uczestniczy journald, przekształcając logi w format binarny do łatwego przeszukiwania itd., to jest zupełny koszmar, spadamy o 44 razy w TPS.
I to jest coś, z czym żyją ludzie. I często w firmach, szczególnie dużych, bardzo trudno to zmienić. Jeśli możesz odejść od syslog, to proszę, odejdź od niego.
- Oceń IOPS i strumień zapisu.
- Sprawdź swój system logowania.
- Jeśli przewidywane obciążenie jest zbyt duże, rozważ opcję próbkowania.
Mamy pg_stat_statements. Jak powiedziałem, musi on być obecny. Możemy wziąć każdą grupę zapytań i specjalnie ją opisać w pliku. Następnie możemy wykorzystać bardzo wygodną funkcję w pgbench – możliwość wprowadzenia kilku plików za pomocą opcji „-f”.
Rozumie wiele opcji „-f”. Można też wskazać za pomocą „@” na końcu, jaka część każdego pliku powinna być. Tzn. możemy powiedzieć, że ten plik powinien być uruchamiany w 10% przypadków, a ten w 20%. To przybliża nas do tego, co widzimy na produkcji.
A jak zrozumiemy, co mamy na produkcji? Jaka jest proporcja i czego? Tutaj trochę odchodzimy od tematu. Mamy jeszcze jeden produkt. . To też baza w Open Source. Obecnie aktywnie nad nim pracujemy.
Powstał z nieco innych powodów. Z powodów związanych z tym, że monitoring jest niewystarczający. Tzn. przychodzisz, przyglądasz się bazie, patrzysz na problemy, które występują. I zazwyczaj wykonujesz health_check. Jeśli jesteś doświadczonym DBA, to wykonujesz health_check. Sprawdzasz wykorzystanie indeksów itd. Jeśli masz OKmeter, to świetnie. To wspaniały monitoring dla Postgresa. OKmeter.io – proszę, zainstalujcie to, wszystko jest tam bardzo dobrze zrobione. Jest płatny.
Jeśli go nie masz, zazwyczaj masz mało informacji. W monitoringu zwykle mamy CPU, IO i to z zastrzeżeniami, i tyle. A potrzebujemy więcej. Musimy widzieć, jak działa autovakuum, jak działa checkpoint, w przypadku IO musimy oddzielić checkpoint od bgwritera i backendów itd.
Problem polega na tym, że gdy pomagasz jakiejś dużej firmie, nie mogą szybko wdrożyć czegoś. Nie mogą szybko zakupić OKmeter. Może kupią to dopiero za pół roku. Nie mogą szybko zainstalować żadnych pakietów.
I pojawił się pomysł, że potrzebujemy specjalnego narzędzia, które nie wymaga żadnej instalacji, tzn. nie musisz nic instalować na produkcji. Instalujesz je na swoim laptopie lub na serwerze monitorującym, z którego będziesz uruchamiać. Będzie analizować wiele rzeczy: zarówno system operacyjny, jak i system plików, jak i samego Postgresa, wykonując lekkie zapytania, które można uruchamiać bezpośrednio na produkcji i nic się nie zawiesi.
Nazwaliśmy to Postgres-checkup. Jeśli mówimy o medycynie, to jest to regularne badanie zdrowia. Jeśli o motoryzacji, to – to jak przegląd techniczny. Robisz przegląd co sześć miesięcy lub rok, w zależności od marki. A czy robisz przegląd swojej bazy? Tzn. czy regularnie wykonujesz dokładne badania? To jest konieczne. Jeśli robisz kopie zapasowe, to rób także checkup, to nie mniej ważne.
Mamy więc takie narzędzie. Zaczęło się rozwijać intensywnie dopiero trzy miesiące temu. Jest jeszcze młode, ale ma już wiele funkcji.
Zbieramy najbardziej „wpływowe” grupy zapytań – raport K003 w Postgres-checkup
I tam jest grupa raportów K. Na razie są trzy raporty. I jest taki raport K003. Tam znajduje się szczyt z pg_stat_statements, posortowany według total_time.
Kiedy sortujemy grupy zapytań według total_time, na szczycie widzimy taką grupę, która obciąża nasz system w największym stopniu, tzn. zużywa najwięcej zasobów. Dlaczego nazywam to grupami zapytań? Ponieważ wyeliminowaliśmy parametry. To już nie są zapytania, a grupy zapytań, tzn. są one zabstractowane.
I jeśli będziemy optymalizować od góry do dołu, będziemy odciążać nasze zasoby i odkładać moment, w którym będziemy musieli dokonać uaktualnienia. To bardzo dobry sposób na zaoszczędzenie pieniędzy.
Może to nie jest najlepszy sposób w kontekście opieki nad użytkownikami, ponieważ może nie dostrzegamy rzadkich, ale bardzo przykrych przypadków, gdy ktoś czekał 15 sekund. W sumie są one tak rzadkie, że ich nie widzimy, ale mimo to zajmujemy się zasobami.
Co się stało w tej tabeli? Zrobiliśmy dwa zrzuty. Postgres_checkup zrobi dla ciebie deltę dla każdej metryki: total-time, calls, rows, shared_blks_read itd. Wszystko, delta obliczona. Głównym problemem pg_stat_statements jest to, że nie pamięta, kiedy był reset. Jeśli pg_stat_database pamięta, to pg_stat_statements nie pamięta. Widzisz tam liczbę 1 000 000, ale nie wiemy, skąd to liczono.
A tutaj wiemy, mamy dwa zrzuty. Wiemy, że delta w tym przypadku wyniosła 56 sekund. Bardzo krótki okres. Posortowane po total_time. A dalej możemy różnicować, tzn. dzielimy wszystkie metryki przez duration. Jeśli każdą metrykę podzielimy przez duration, będziemy mieli liczbę wywołań na sekundę.
Dalej total_time na sekundę – to moja ulubiona metryka. Mierzona jest w sekundach, na sekundę, tzn. ile sekund nasz system potrzebował na wykonanie tej grupy zapytań na sekundę. Jeśli widzisz tam więcej niż jedna sekunda na sekundę, to oznacza, że potrzebowałeś więcej niż jednego rdzenia. To bardzo dobra metryka. Możesz zrozumieć, że temu „towarzyszowi”, na przykład, potrzeba minimum trzech rdzeni.
To nasze know-how, czegoś takiego nigdzie nie widziałem. Zauważ – to bardzo prosta rzecz – sekunda na sekundę. Czasami, gdy masz 100 % CPU, to pół godziny na sekundę, tzn. przez pół godziny zajmowałeś się tylko tym zapytaniem.
Następnie widzimy liczby wierszy na sekundę. Wiemy, ile wierszy na sekundę zostało zwróconych.
I dalej jest też ciekawa rzecz. Ile razy odczytaliśmy shared_buffers z samego shared_buffers. Uderzenia były już tam, a wiersze pobraliśmy z pamięci podręcznej systemu operacyjnego lub z dysku. Pierwsza opcja jest szybka, a druga może być szybka, a może i nie, w zależności od sytuacji.
A drugi sposób różnicowania – dzielimy liczbę zapytań w tej grupie. W drugiej kolumnie zawsze będzie jedno zapytanie podzielone przez zapytanie. A następnie interesujące – ile milisekund zajmowało to zapytanie. Wiemy, jak przeciętnie zachowuje się to zapytanie. Każde zapytanie trwało średnio 101 milisekund. To tradycyjna metryka, która jest nam potrzebna do zrozumienia.
Ile wierszy każde zapytanie zwróciło średnio. Widzimy, grupa ta zwraca 8. Ile średnio pobrano i odczytano z pamięci podręcznej. Widzimy, że wszystko jest świetnie zbuforowane. Same uderzenia dla pierwszej grupy.
A czwarty podtekst w każdym wierszu – to ile procent od ogólnej liczby. Mamy calls. Na przykład, w 1 000 000. I możemy zrozumieć, jaki wkład wnosi ta grupa. Widzimy, że w tym przypadku pierwsza grupa wnosi wkład mniejszy niż 0,01%. To znaczy, że jest tak wolna, że nie widzimy jej w ogólnym obrazie. A druga grupa – 5% w wywołaniach. To znaczy, 5% ze wszystkich wywołań to druga grupa.
Po total_time również ciekawe. Na pierwszą grupę zapytań wydaliśmy 14% całego czasu pracy. A na drugą – 11% itd.
Nie będę wchodził w szczegóły, ale są tam niuanse. Wyżej pokazujemy błąd, ponieważ, gdy porównujemy, zrzuty mogą się zmieniać, to znaczy, niektóre zapytania mogą wypaść i w drugim już mogą nie być obecne, a inne mogą się pojawić. I tam obliczamy błąd. Jeśli widzisz 0, to dobrze. To oznacza, że nie ma błędów. Jeśli wskaźnik błędu wynosi do 20%, to jest O.K.
Następnie wracamy do naszego tematu. Musimy zrealizować obciążenie robocze. Bierzemy od góry do dołu, aż zbierzemy 80% lub 90%. Zazwyczaj jest to 10-20 grup. I tworzymy pliki do pgbench. Tam używamy random. Czasami, niestety, się to nie udaje. A w Postgres 12 będzie więcej możliwości zastosowania takiego podejścia.
A następnie w ten sposób osiągamy 80-90% w total_time. Co dalej wpisać po "@"? Przyglądamy się wywołaniom, patrzymy, ile procent i rozumiemy, że tutaj powinniśmy mieć tyle procent. Na podstawie tych procentów możemy zrozumieć, jak zrównoważyć każdy z plików. Po tym używamy pgbench i zaczynamy pracować.
Mamy też K001 i K002.
K001 – to jeden duży ciąg z czterema podciągami. To charakterystyka całego naszego obciążenia. Zobaczcie drugą kolumnę i drugi podciąg. Widzimy, że to około półtorej sekundy na sekundę, tzn. jeśli będzie dwa rdzenie, to będzie dobrze. Około 75% obciążenia. I tak będzie to działać. Jeśli będziemy mieli 10 rdzeni, to będziemy całkowicie spokojni. Tak możemy oceniać zasoby.
K002 – to, co nazywam klasami zapytań, tzn. SELECT, INSERT, UPDATE, DELETE. Osobno SELECT FOR UPDATE, ponieważ blokuje.
I tutaj możemy wyciągnąć wniosek, że zwykłe czytające SELECT – to 82% wszystkich wywołań, ale jednocześnie – 74% w total_time. Tzn. są często wywoływane, ale zużywają mniej zasobów.
I wracamy do pytania: "Jak prawidłowo dobrać shared_buffers?". Obserwuję, że większość benchmarków opiera się na idei – spójrzmy, jaka będzie przepustowość, tzn. jaka będzie zdolność do przetwarzania. Mierzy się to zazwyczaj w TPS lub QPS.
I staramy się wycisnąć z maszyny jak najwięcej transakcji na sekundę za pomocą ustawień tuningu. Tutaj mamy dokładnie 311 na sekundę dla select.
Ale nikt nie jeździ do pracy i z powrotem do domu po drodze na pełnej prędkości. To głupie. Tak samo z bazami danych. Nie powinniśmy jeździć na pełnej prędkości, nikt tego nie robi. Nikt nie żyje w produkcji, gdzie CPU ma 100%. Choć być może ktoś tak żyje, ale to niezdrowe.
Idea jest taka, że zazwyczaj jeździmy na około 20% możliwości, najlepiej nie więcej niż 50%. I staramy się optymalizować czas odpowiedzi dla naszych użytkowników przede wszystkim. Tzn. musimy kręcić naszymi rękami tak, aby było minimalne opóźnienie przy 20% prędkości, umownie. To taka idea, którą również staramy się wykorzystywać w naszych eksperymentach.
I na zakończenie rekomendacje:
- Koniecznie zróbcie Database Lab.
- Jeżeli to możliwe, zróbcie on demand, aby rozwijać się na jakiś czas – pobawiliście się i usunęli. Jeżeli macie chmury, to oczywiście, tzn. miejcie sporo standing.
- Bądźcie ciekawi. I jeśli coś jest nie tak, sprawdzajcie eksperymentami, jak to działa. Nancy można wykorzystać do nauki i sprawdzania, jak działa baza.
- Skupcie się na minimalnym czasie odpowiedzi.
- I nie obawiajcie się źródeł Postgres. Gdy pracujecie z kodem źródłowym, musicie znać angielski. Jest tam wiele komentarzy, wszystko jest wyjaśnione.
- I regularnie sprawdzajcie stan bazy, przynajmniej raz na trzy miesiące ręcznie lub za pomocą Postgres-checkup.
Pytania
Dziękuję bardzo! Bardzo interesująca sprawa.
Dwie rzeczy.
Tak, dwie rzeczy. Tylko nie do końca zrozumiałem. Kiedy pracujemy z Nancy, możemy regulować tylko jeden parametr czy całą grupę?
Mamy parametr delta-configuration. Możecie tam regulować tyle, ile chcecie. Ale musicie rozumieć, że gdy zmieniacie wiele rzeczy, możecie wyciągać błędne wnioski.
Tak. Dlaczego pytam? Ponieważ trudno przeprowadzać eksperymenty, gdy masz tylko jeden parametr. Regulujesz go, patrzysz, jak działa. Ustawiasz go. Potem zaczynasz od następnego.
Można regulować jednocześnie, ale to oczywiście zależy od sytuacji. Lepiej jednak sprawdzać jedną ideę. Wczoraj mieliśmy pomysł. Mieliśmy bardzo podobną sytuację. Były dwa configi. I nie mogliśmy zrozumieć, dlaczego była taka duża różnica. Pojawił się pomysł, że trzeba zastosować dychotomię, aby stopniowo zrozumieć i znaleźć różnicę. Można od razu ustawić połowę parametrów na identyczne, potem ćwierć itd. Wszystko elastyczne.
I mam jeszcze pytanie. Projekt jest młody, rozwija się. Czy dokumentacja już jest gotowa, jest szczegółowy opis?
Tam specjalnie dodałem link do opisu parametrów. To istnieje. Ale wiele rzeczy wciąż brakuje. Szukam ludzi myślących podobnie. I odnajduję ich, kiedy występuję. To jest super. Ktoś już ze mną pracuje, ktoś pomógł i coś zrobił. Jeśli interesuje Was ten temat, dajcie znać – co jest potrzebne.
Kiedy zrobimy laboratorium, może pojawią się opinie. Zobaczymy. Dziękuję!
Witam! Dziękuję za wystąpienie! Zauważyłem, że jest wsparcie dla Amazona. Czy planowane jest wsparcie dla GSP?
Dobre pytanie. Rozpoczęliśmy pracę nad tym. Na razie to zatrzymaliśmy, ponieważ chcemy oszczędzać. Tzn. jest wsparcie za pomocą run on localhost. Możesz samodzielnie stworzyć instancję i pracować lokalnie. Swoją drogą, tak robimy. W Getlab tak działam, tam na GSP. Ale nie widzimy sensu w takiej orkiestracji, ponieważ Google nie ma tanich spotów. Tam są ??? instancje, ale mają ograniczenia. Po pierwsze, zawsze mają tylko 70% zniżki i nie można bawić się ceną. Spoty podnosimy o 5-10% ceny, aby zmniejszyć ryzyko, że cię ukarzą. Tzn. na spotach oszczędzasz, ale mogą ci je w każdej chwili odebrać. Jeśli ustalasz cenę trochę wyższą niż u innych, później zostaniesz zabity. W Google jest zupełnie inna specyfika. I jest jeszcze jedno bardzo niekorzystne ograniczenie – działają tylko przez 24 godziny. A czasami chcemy przeprowadzać eksperyment przez 5 dni. Ale na spotach można to robić, spoty czasami żyją przez miesiące.
Witaj! Dziękuję za prezentację! Wspomniałeś o checkupie. Jak obliczasz błędy stat_statements?
Bardzo dobre pytanie. Mogę to dokładnie pokazać i wyjaśnić. Krótko – sprawdzamy, jak zmienił się zestaw grup zapytań: ile zostało z nich usuniętych i ile nowych się pojawiło. Następnie przyglądamy się dwóm metrykom: total_time i calls, dlatego są tam dwie błędy. I patrzymy, jaki wkład mają zmieniające się grupy. Są tam dwie podgrupy: te, które odeszły i te, które przybyły. Sprawdzamy, jaki mają wkład w całość.
Czy nie obawiasz się, że ona obróci się tam dwa lub trzy razy w czasie między snapshotami?
Tzn. zarejestrowali się ponownie czy jak?
Na przykład, to zapytanie raz już zostało wypchnięte, potem znów nadeszło i ponownie zostało wypchnięte, a następnie jeszcze raz nadeszło i ponownie zostało wypchnięte. I ty tu coś policzyłeś, a gdzie to wszystko?
Dobre pytanie, trzeba się temu przyjrzeć.
Zrobiłem coś podobnego. Oczywiście, zrobiłem to sam. Ale musiałem zresetować stat_statements i orientować się w momencie snapshotu, że tam jest mniej określonej części, że i tak nie dotarło do sufitu, ile stat_statements może się zebrać. I orientuję się, że prawdopodobnie nic nie zostało wypchnięte.
Tak, tak.
Ale nie rozumiem, jak można to zrobić inaczej wiarygodnie.
Niestety, dokładnie nie pamiętam – czy używamy tam tekstu zapytania czy queryid z pg_stat_statements i na tym się opieramy. Jeśli opieramy się na queryid, to teoretycznie porównujemy porównywalne rzeczy.
Nie, może on być usunięty kilka razy między snapshotami i wrócić ponownie.
Z tym samym id?
Tak.
Przyjrzymy się temu. Dobre pytanie. Musimy to zbadać. Ale na razie to, co widzimy, to po prostu 0...
To oczywiście rzadki przypadek, ale byłem zszokowany, gdy dowiedziałem się, że stat_statements może być usunięty.
W Pg_stat_statements może być dużo rzeczy. Spotkaliśmy się z tym, że jeśli masz track_utility = on, to zestawy również są śledzone.
Tak, oczywiście.
I jeśli masz losowy Java Hibernate, to tam zaczyna się blokować tabela haszowa. I jak tylko wyłączysz bardzo obciążoną aplikację, masz 50-100 grup. I wszystko jest mniej więcej stabilne. Jednym ze sposobów walki z tym jest zwiększenie pg_stat_statements.max.
Tak, ale musisz wiedzieć, o ile. I musisz jakoś to monitorować. Tak właśnie robię. Tzn. mam pg_stat_statements.max. I patrzę, że w momencie snapshotu nie osiągnąłem 70%. Dobrze, więc nic nie straciliśmy. Robimy reset. I zbieramy ponownie. Jeśli w następnym snapshotie jest mniej niż 70, to prawdopodobnie znowu nic nie straciliśmy.
Tak. Domyślnie teraz 5000. I dla wielu osób to wystarcza.
Zazwyczaj – tak.
Wideo:
P.S. Dodam, że jeśli w Postgresie znajdują się dane poufne, które nie mogą trafić do środowiska testowego, można skorzystać z . Schemat jest mniej więcej taki:
Źródło: habr.com
