Sugeruję przeczytanie transkrypcji raportu Nikołaja Samochwałowa „Przemysłowe podejście do strojenia PostgreSQL: eksperymenty na bazach danych”
Shared_buffers = 25% – to dużo czy mało? Albo po prostu dobrze? Skąd wiesz, czy to – raczej przestarzałe – zalecenie jest odpowiednie w Twoim konkretnym przypadku?
Czas podejść do kwestii doboru parametrów postgresql.conf „jak dorosły”. Nie za pomocą ślepych „auto tunerów” lub przestarzałych porad z artykułów i blogów, ale w oparciu o:
- ściśle zweryfikowane eksperymenty na bazach danych, przeprowadzane automatycznie, w dużych ilościach i w warunkach jak najbardziej zbliżonych do „walki”,
- głębokie zrozumienie funkcji DBMS i systemu operacyjnego.
Korzystanie z Nancy CLI (), przyjrzymy się konkretnemu przykładowi - osławionym Shared_buffers - w różnych sytuacjach, w różnych projektach i spróbujemy dowiedzieć się, jak wybrać optymalne ustawienie dla naszej infrastruktury, bazy danych i obciążenia.
Porozmawiamy o eksperymentach z bazami danych. To historia, która trwa nieco ponad sześć miesięcy.
Trochę o mnie. Doświadczenie w Postgres od ponad 14 lat. Założyło wiele firm zajmujących się sieciami społecznościowymi. Postgres był i jest używany wszędzie.
Również grupa RuPostgres na Meetupie, 2 miejsce na świecie. Powoli zbliżamy się do 2 osób. RuPostgres.org.
A na komputerach różnych konferencji, w tym Highload, od samego początku odpowiadam za bazy danych, w szczególności Postgres.
W ciągu ostatnich kilku lat ponownie uruchomiłem swoją praktykę konsultingową Postgres 11 stref czasowych stąd.
A kiedy robiłem to kilka lat temu, miałem przerwę w aktywnej pracy ręcznej z Postgresem, prawdopodobnie od 2010 roku. Byłem zaskoczony, jak mało zmieniła się rutyna pracy administratora bazy danych i ile pracy ręcznej nadal trzeba włożyć. I od razu pomyślałem, że coś tu jest nie tak, muszę bardziej wszystko zautomatyzować.
A ponieważ wszystko było odległe, większość klientów była w chmurach. Oczywiście wiele z nich zostało już zautomatyzowanych. Więcej na ten temat później. Czyli to wszystko zrodziło pomysł, że powinno być szereg narzędzi, czyli jakaś platforma, która zautomatyzuje niemal wszystkie działania DBA, tak aby można było zarządzać dużą liczbą baz danych.
Raport ten nie będzie zawierał:
- „Srebrne kule” i stwierdzenia typu - ustaw 8 GB lub 25% share_buffers i wszystko będzie dobrze. Nie będzie wiele o share_buffers.
- Hardcorowe „wnętrzności”.
A co się stanie?
- Będą zasady optymalizacji, które będziemy stosować i rozwijać. Po drodze pojawią się najróżniejsze pomysły i różne narzędzia, które w większości tworzymy w Open Source, czyli tworzymy podstawy w Open Source. Co więcej, mamy bilety, cała komunikacja jest praktycznie Open Source. Możesz zobaczyć, co robimy teraz, co będzie w następnej wersji itp.
- Będzie też pewne doświadczenie w stosowaniu tych zasad, tych narzędzi w wielu firmach: od małych start-upów po duże firmy.
Jak to wszystko się rozwija?
Po pierwsze, głównym zadaniem administratora danych, oprócz zapewnienia tworzenia instancji, wdrażania kopii zapasowych itp., jest wyszukiwanie wąskich gardeł i optymalizacja wydajności.
Teraz jest to ustawione tak. Patrzymy na monitoring, coś widzimy, ale brakuje nam kilku szczegółów. Zaczynamy kopać ostrożniej, zwykle rękami, i rozumiemy, co z tym zrobić w ten czy inny sposób.
Istnieją dwa podejścia. Pg_stat_statements to domyślne rozwiązanie do identyfikacji wolnych zapytań. I analiza logów Postgres przy użyciu pgBadger.
Każde podejście ma poważne wady. W pierwszym podejściu wyrzuciliśmy wszystkie parametry. A jeśli zobaczymy tabelę grup SELECT * FROM, w której kolumna jest równa „?” lub „$” od Postgres 10. Nie wiemy, czy jest to skanowanie indeksu, czy skanowanie sekwencyjne. Dużo zależy od parametru. Jeśli zastąpisz tam rzadko spotykaną wartość, będzie to skanowanie indeksu. Jeśli podstawisz tam wartość zajmującą 90% tabeli, skanowanie sekwencyjne będzie oczywiste, ponieważ Postgres zna statystyki. I to jest duża wada pg_stat_statements, chociaż pewne prace trwają.
Największą wadą analizy logów jest to, że z reguły nie można sobie pozwolić na „log_min_duration_statement = 0”. I o tym też porozmawiamy. W związku z tym nie widzisz całego obrazu. A niektóre zapytania, które są bardzo szybkie, mogą pochłonąć ogromną ilość zasobów, ale ich nie zobaczysz, ponieważ są poniżej Twojego progu.
W jaki sposób administratorzy baz danych rozwiązują znalezione problemy?
Na przykład znaleźliśmy pewien problem. Co zwykle się robi? Jeśli jesteś programistą, będziesz robić coś w przypadku, który nie jest tego samego rozmiaru. Jeśli jesteś administratorem baz danych, masz inscenizację. A może być tylko jeden. A spóźnił się o sześć miesięcy. I myślisz, że pójdziesz na produkcję. Nawet doświadczeni administratorzy danych sprawdzają następnie produkcję na replice. I zdarza się, że tworzą indeks tymczasowy, upewniają się, że to pomoże, upuszczają go i przekazują programistom, aby mogli umieścić go w plikach migracyjnych. To jest ten rodzaj nonsensu, który ma teraz miejsce. I to jest problem.
- Dostosuj konfiguracje.
- Zoptymalizuj zestaw indeksów.
- Zmień samo zapytanie SQL (jest to najtrudniejsza metoda).
- Dodaj pojemność (w większości przypadków najłatwiejszy sposób).
Dużo się dzieje w tych sprawach. W Postgresie jest wiele uchwytów. Jest wiele rzeczy do poznania. W Postgresie znajduje się wiele indeksów, także dzięki organizatorom tej konferencji. I to wszystko trzeba wiedzieć, i to właśnie sprawia, że osoby niebędące administratorami danych mają wrażenie, że administratorzy baz danych praktykują czarną magię. Oznacza to, że musisz uczyć się przez 10 lat, aby zacząć to wszystko normalnie rozumieć.
A ja jestem wojownikiem przeciwko tej czarnej magii. Chcę zrobić wszystko, żeby była technologia, a nie było w tym wszystkim intuicji.
Przykłady z życia wzięte
Zaobserwowałem to w co najmniej dwóch projektach, w tym w moim własnym. Z innego wpisu na blogu wynika, że wartość 1 dla parametru default_statistict_target jest dobra. OK, spróbujmy tego na produkcji.
I tu, korzystając z naszego narzędzia dwa lata później, przy pomocy eksperymentów na bazach danych, o których dziś mówimy, możemy porównać to, co było, i to, co się stało.
W tym celu musimy stworzyć eksperyment. Składa się z czterech części.
- Pierwszym z nich jest środowisko. Potrzebujemy kawałka sprzętu. A kiedy przychodzę do jakiejś firmy i podpisuję umowę, to mówię, żeby mi dali taki sam sprzęt, jak na produkcji. Dla każdego z Twoich Masterów potrzebuję przynajmniej jednego takiego sprzętu. Albo jest to instancyjna maszyna wirtualna w Amazon lub Google, albo potrzebuję dokładnie tego samego sprzętu. To znaczy chcę odtworzyć środowisko. A w koncepcji środowiska uwzględniamy główną wersję Postgres.
- Część druga jest przedmiotem naszych badań. To jest baza danych. Można go stworzyć na kilka sposobów. Pokażę ci jak.
- Trzecia część to obciążenie. To najtrudniejszy moment.
- A czwarta część to to, co sprawdzamy, czyli co z czym porównamy. Powiedzmy, że możemy zmienić jeden lub więcej parametrów w konfiguracji, możemy utworzyć indeks itp.
Rozpoczynamy eksperyment. Oto pg_stat_statements. Po lewej stronie jest to, co się wydarzyło. Po prawej - co się stało.
Po lewej stronie default_statistics_target = 100, po prawej = 1. Widzimy, że nam to pomogło. Ogólnie rzecz biorąc, wszystko poprawiło się o 000%.
Ale jeśli przewiniemy w dół, pojawią się grupy żądań z pgBadger lub z pg_stat_statements. Istnieją dwie opcje. Zobaczymy, że część żądań spadła o 88%. I tu pojawia się podejście inżynieryjne. Możemy kopać dalej w środku, bo zastanawiamy się, dlaczego zatonął. Musisz zrozumieć, co stało się ze statystykami. Dlaczego więcej segmentów w statystykach prowadzi do gorszych wyników.
Albo nie możemy kopać, ale robimy „ZMIŃ TABELĘ… ZMIEŃ KOLUMNĘ” i zwróć 100 wiader z powrotem do statystyk tej kolumny. A następnie, wykonując kolejny eksperyment, możemy upewnić się, że ta łatka pomogła. Wszystko. Jest to podejście inżynieryjne, które pomaga nam zobaczyć szerszy obraz i podejmować decyzje w oparciu o dane, a nie intuicję.
Kilka przykładów z innych dziedzin. Testy CI są obecne w testowaniu od wielu lat. Żaden projekt o zdrowych zmysłach nie obejdzie się bez automatycznych testów.
W innych branżach: w lotnictwie, w motoryzacji, gdy testujemy aerodynamikę, mamy także możliwość przeprowadzania eksperymentów. Nie wystrzelimy czegoś z rysunku bezpośrednio w kosmos, ani nie wyniesiemy od razu jakiegoś samochodu na tor. Na przykład istnieje tunel aerodynamiczny.
Wnioski możemy wyciągnąć z obserwacji innych branż.
Po pierwsze, mamy szczególne środowisko. Jest blisko produkcji, ale nie blisko. Jego główną cechą jest to, że powinien być tani, powtarzalny i jak najbardziej zautomatyzowany. Muszą też istnieć specjalne narzędzia do przeprowadzania szczegółowej analizy.
Najprawdopodobniej, kiedy wystrzeliwujemy samolot i lecimy, mamy mniej możliwości zbadania każdego milimetra powierzchni skrzydła niż w tunelu aerodynamicznym. Mamy więcej narzędzi diagnostycznych. Stać nas na przewożenie cięższych rzeczy, których nie stać nas na wrzucenie do samolotu w powietrze. To samo z Postgresem. W niektórych przypadkach możemy włączyć pełne rejestrowanie zapytań podczas eksperymentów. A nie chcemy tego robić na produkcji. Możemy nawet planować włączenie tej funkcji za pomocą funkcji auto_explain.
I jak mówiłem, wysoki poziom automatyzacji oznacza, że wciskamy przycisk i powtarzamy. Tak właśnie powinno być, żeby było dużo eksperymentów, żeby było na bieżąco.
Nancy CLI - fundament „laboratorium baz danych”
I tak zrobiliśmy tę rzecz. To znaczy mówiłem o tych pomysłach w czerwcu, prawie rok temu. I mamy już tak zwane Nancy CLI w Open Source. Jest to podstawa do zbudowania laboratorium baz danych.
— Jest w formacie Open Source, na Gitlabie. Możesz to powiedzieć, możesz spróbować. Link podałem na slajdach. Możesz na to kliknąć i będzie tam z całym szacunkiem.
Oczywiście wiele jest jeszcze w fazie rozwoju. Jest tam mnóstwo pomysłów. Ale jest to coś, z czego korzystamy niemal codziennie. A kiedy już mamy pomysł – dlaczego po usunięciu 40 000 000 linii wszystko sprowadza się do operacji wejścia/wyjścia, możemy przeprowadzić eksperyment i przyjrzeć się bliżej, aby zrozumieć, co się dzieje, a następnie spróbować naprawić to na bieżąco. Oznacza to, że przeprowadzamy eksperyment. Na przykład coś poprawiamy i zobaczymy, co się ostatecznie stanie. I nie robimy tego na produkcji. To jest istota pomysłu.
Gdzie to może zadziałać? Może to działać lokalnie, czyli można to zrobić w dowolnym miejscu, można nawet uruchomić na MacBooku. Potrzebujemy dokera, chodźmy. To wszystko. Można go uruchomić w dowolnym miejscu na sprzęcie lub na maszynie wirtualnej.
Istnieje również możliwość zdalnego uruchamiania w Amazon w instancji EC2, w spotach. I to jest bardzo fajna okazja. Na przykład wczoraj przeprowadziliśmy ponad 500 eksperymentów na instancji i3, zaczynając od najmłodszej, a kończąc na i3-16-xlarge. A 500 eksperymentów kosztowało nas 64 dolary. Każdy trwał 15 minut. Czyli ze względu na to, że wykorzystywane są tam spoty, jest to bardzo tanie – 70% rabatu, rozliczenie sekundowe Amazona. Możesz wiele zrobić. Możesz przeprowadzić prawdziwe badania.
Obsługiwane są trzy główne wersje Postgres. Nie jest tak trudno ukończyć niektóre stare i nową, 12-tą wersję.
Obiekt możemy zdefiniować na trzy sposoby. Ten:
- Plik zrzutu/sql.
- Głównym sposobem jest sklonowanie katalogu PGDATA. Z reguły pobierany jest z serwera zapasowego. Jeśli masz normalne kopie zapasowe binarne, możesz z nich tworzyć klony. Jeśli masz chmury, biuro w chmurze, takie jak Amazon i Google, zrobi to za Ciebie. Jest to najważniejszy sposób klonowania prawdziwej produkcji. W ten sposób się rozwijamy.
- I ostatnia metoda nadaje się do badań, gdy chcesz zrozumieć, jak coś działa w Postgresie. To jest pgbench. Możesz wygenerować za pomocą pgbench. To tylko jedna opcja „db-pgbench”. Powiedz mu, w jakiej skali. I wszystko będzie generowane w chmurze, jak stwierdzono.
I załaduj:
- Ładowanie możemy wykonać w jednym wątku SQL. To najbardziej prymitywny sposób.
- I możemy emulować obciążenie. I możemy to naśladować przede wszystkim w następujący sposób. Musimy zebrać wszystkie dzienniki. I to jest bolesne. Pokażę ci dlaczego. A za pomocą pgreplay gramy, który jest wbudowany w Nancy.
- Lub inna opcja. Tak zwane obciążenie rzemieślnicze, które wykonujemy z pewnym wysiłkiem. Analizując nasze obecne obciążenie systemu walki, wyciągamy najważniejsze grupy zgłoszeń. Za pomocą pgbench możemy emulować to obciążenie w laboratorium.
- Albo musimy wykonać jakiś SQL, czyli sprawdzamy jakąś migrację, tam tworzymy indeks, tam wykonujemy ANALIZĘ. Patrzymy na to, co działo się przed próżnią i po próżni. Ogólnie rzecz biorąc, dowolny SQL.
- Albo zmienimy jeden lub więcej parametrów w konfiguracji. Możemy nam kazać sprawdzić na przykład 100 wartości w Amazonie dla naszej terabajtowej bazy danych. A za kilka godzin będziesz miał wynik. Z reguły wdrożenie terabajtowej bazy danych zajmie Ci kilka godzin. Ale jest łatka w opracowaniu, mamy możliwą serię, tj. możesz konsekwentnie używać tych samych pgdata na tym samym serwerze i sprawdzać. Postgres uruchomi się ponownie, a pamięci podręczne zostaną zresetowane. I możesz prowadzić ładunek.
- Pojawia się katalog z wieloma różnymi plikami, zaczynając od migawek pgstan***. A najciekawsze jest pg_stat_statements, pg_stat_kcacke. Są to dwa rozszerzenia, które analizują żądania. A pg_stat_bgwriter zawiera nie tylko statystyki pgwritera, ale także punkty kontrolne i sposób, w jaki same backendy wypierają brudne bufory. I to wszystko jest ciekawe do zobaczenia. Na przykład, kiedy skonfigurujemy share_buffers, bardzo interesujące jest sprawdzenie, ile wszyscy zastąpili.
- Przychodzą także logi Postgresa. Dwa dzienniki – dziennik przygotowania i dziennik odtwarzania wczytywania.
- Stosunkowo nową funkcją jest FlameGraphs.
- Ponadto, jeśli do odtwarzania obciążenia użyłeś opcji pgreplay lub pgbench, ich dane wyjściowe będą natywne. Zobaczysz opóźnienie i TPS. Będzie można zrozumieć, jak to widzieli.
- Informacje o systemie.
- Podstawowe kontrole procesora i wejścia/wyjścia. To bardziej dotyczy instancji EC2 w Amazonie, jeśli chcesz uruchomić 100 identycznych instancji w wątku i uruchomić tam 100 różnych przebiegów, będziesz mieć 10 000 eksperymentów. I musisz się upewnić, że nie natkniesz się na wadliwą instancję, która jest już przez kogoś uciskana. Inni są aktywni na tym sprzęcie i pozostało Ci niewiele zasobów. Lepiej odrzucić takie wyniki. Za pomocą sysbencha Aleksieja Kopytowa wykonamy kilka krótkich kontroli, które przyjdą i będą można je porównać z innymi, tj. zrozumiesz, jak zachowuje się procesor i jak zachowuje się IO.
Jakie są trudności techniczne na przykładzie różnych firm?
Powiedzmy, że chcemy powtórzyć rzeczywiste obciążenie za pomocą dzienników. To świetny pomysł, jeśli jest napisany na pgreplay Open Source. Używamy tego. Ale aby to działało dobrze, musisz włączyć pełne rejestrowanie zapytań z parametrami i czasem.
Istnieją pewne komplikacje związane z czasem trwania i znacznikiem czasu. Opróżnimy całą kuchnię. Podstawowe pytanie brzmi: czy Cię na to stać, czy nie?
Problem w tym, że może być niedostępny. Przede wszystkim musisz zrozumieć, jaki strumień zostanie zapisany w dzienniku. Jeśli masz pg_stat_statements, możesz użyć tego zapytania (link będzie dostępny na slajdach), aby dowiedzieć się, ile bajtów zostanie zapisanych w przybliżeniu na sekundę.
Sprawdzamy długość żądania. Zaniedbujemy fakt, że nie ma żadnych parametrów, ale znamy długość żądania i wiemy, ile razy na sekundę było ono wykonywane. W ten sposób możemy oszacować w przybliżeniu liczbę bajtów na sekundę. Być może popełnimy błąd dwa razy częściej, ale na pewno w ten sposób zrozumiemy porządek.
Widzimy, że to żądanie jest wykonywane 802 razy na sekundę. I widzimy, że bytes_per sec – 300 kB/s zostanie zapisane plus lub minus. I z reguły możemy sobie pozwolić na taki przepływ.
Ale! Faktem jest, że istnieją różne systemy rejestrowania. Domyślnym ustawieniem jest zwykle „syslog”.
A jeśli masz syslog, możesz mieć taki obraz. Weźmiemy pgbench, włączymy rejestrowanie zapytań i zobaczymy, co się stanie.
Bez logowania - to jest kolumna po lewej stronie. Mamy 161 000 TPS. Z syslog - to jest w Ubuntu 16.04 na Amazonie, otrzymujemy 37 000 TPS. A jeśli przejdziemy na dwie inne metody logowania, sytuacja będzie znacznie lepsza. Oznacza to, że spodziewaliśmy się jego spadku, ale nie w takim samym stopniu.
A na CentOS 7, w którym Journald również uczestniczy, zamieniając logi do formatu binarnego w celu łatwego wyszukiwania itp., Tam jest koszmar, spadamy 44 razy w TPS.
I z tym ludzie żyją. A często w firmach, szczególnie dużych, bardzo trudno to zmienić. Jeśli możesz uciec od sysloga, odejdź od niego.
- Oceń IOPS i przepływ zapisu.
- Sprawdź swój system logowania.
- Jeżeli przewidywane obciążenie jest zbyt duże, należy rozważyć pobranie próbek.
Mamy pg_stat_statements. Jak mówiłem, musi tam być. A każdą grupę żądań możemy zebrać i opisać w specjalny sposób w pliku. I wtedy możemy skorzystać z bardzo wygodnej funkcji w pgbenchu - jest to możliwość wstawienia kilku plików za pomocą opcji „-f”.
Rozumie wiele „-f”. Za pomocą „@” na końcu możesz określić, jaki udział powinien mieć każdy plik. Oznacza to, że możemy powiedzieć, że robimy to w 10% przypadków, a to w 20%. A to przybliży nas do tego, co zobaczymy w produkcji.
Jak zrozumiemy, co mamy w produkcji? Jaki udział i w jaki sposób? To trochę na uboczu. Mamy jeszcze jeden produkt . Również baza w Open Source. Teraz aktywnie go rozwijamy.
Urodził się z nieco innych powodów. Z powodów, dla których monitorowanie nie wystarczy. To znaczy, przychodzisz, patrzysz na podstawę, patrzysz na problemy, które istnieją. I z reguły przeprowadzasz kontrolę stanu zdrowia. Jeśli jesteś doświadczonym administratorem danych, wykonaj health_check. Przyjrzeliśmy się wykorzystaniu indeksów itp. Jeśli masz OKmeter, to świetnie. To fajny monitoring dla Postgres. OKmeter.io – zainstaluj, wszystko tam jest zrobione bardzo dobrze. To jest płatne.
Jeśli go nie masz, to zazwyczaj nie masz go zbyt wiele. W monitorowaniu zwykle jest CPU, IO, potem z zastrzeżeniami i tyle. Potrzebujemy więcej. Musimy zobaczyć, jak działa automatyczna próżnia, jak działa punkt kontrolny, w io musimy oddzielić punkt kontrolny od bgwritera i od backendów itp.
Problem w tym, że gdy pomaga się dużej firmie, nie jest ona w stanie szybko czegoś wdrożyć. Nie mogą szybko kupić OKmeter. Może kupią go za sześć miesięcy. Nie mogą szybko dostarczyć niektórych paczek.
I wpadliśmy na pomysł, że potrzebujemy specjalnego narzędzia, które nie wymaga niczego do instalacji, czyli nie trzeba w ogóle niczego instalować na produkcji. Zainstaluj go na swoim laptopie lub na serwerze obserwacyjnym, z którego będziesz go uruchamiał. Przeanalizuje wiele rzeczy: system operacyjny, system plików i sam Postgres, wykonując kilka prostych zapytań, które można uruchomić bezpośrednio na produkcji i nic nie zawiedzie.
Nazwaliśmy to sprawdzaniem Postgres. Z medycznego punktu widzenia jest to regularna kontrola stanu zdrowia. Jeśli jest to temat motoryzacyjny, to przypomina konserwację. Konserwację samochodu przeprowadzasz co sześć miesięcy lub rok, w zależności od marki. Czy konserwujesz swoją bazę? To znaczy, czy regularnie przeprowadzasz głębokie badania? To musi być zrobione. Jeśli tworzysz kopie zapasowe, wykonaj kontrolę, jest to nie mniej ważne.
I mamy takie narzędzie. Zaczęło się aktywnie pojawiać dopiero około trzech miesięcy temu. Jest jeszcze młody, ale ma wiele do zaoferowania.
Zbieranie najbardziej „wpływowych” grup zapytań – raport K003 w Postgres-checkup
I jest grupa raportów K. Na razie trzy raporty. I jest taki raport K003. Jest górna część pg_stat_statements, posortowana według total_time.
Kiedy sortujemy grupy żądań według total_time, na górze widzimy grupę, która najbardziej obciąża nasz system, czyli zużywa więcej zasobów. Dlaczego nadaję nazwy grupom zapytań? Ponieważ wyrzuciliśmy parametry. Nie są to już żądania, ale grupy żądań, czyli są one abstrakcyjne.
A jeśli dokonamy optymalizacji od góry do dołu, odciążymy nasze zasoby i opóźnimy moment, w którym będziemy musieli dokonać aktualizacji. To bardzo dobry sposób na zaoszczędzenie pieniędzy.
Być może nie jest to zbyt dobry sposób na dbanie o użytkowników, ponieważ możemy nie spotkać rzadkich, ale bardzo irytujących przypadków, w których osoba czekała 15 sekund. W sumie są one na tyle rzadkie, że ich nie widzimy, ale mamy do czynienia z zasobami.
Co się wydarzyło w tej tabeli? Zrobiliśmy dwa zdjęcia. Postgres_checkup da ci deltę dla każdej metryki: całkowity czas, połączenia, wiersze,shared_blks_read itp. To wszystko, delta została obliczona. Dużym problemem z pg_stat_statements jest to, że nie pamięta, kiedy został zresetowany. Jeśli pg_stat_database pamięta, to pg_stat_statements nie pamięta. Widzisz, że jest liczba 1 000 000, ale nie wiemy, skąd liczyliśmy.
I tu wiemy, tu mamy dwie migawki. Wiemy, że delta w tym przypadku wynosiła 56 sekund. Bardzo krótka przerwa. Posortowane według całkowitego czasu. I wtedy możemy różnicować, czyli dzielimy wszystkie metryki według czasu trwania. Jeśli podzielimy każdą metrykę przez czas trwania, otrzymamy liczbę połączeń na sekundę.
Następnie total_time na sekundę to moja ulubiona metryka. Jest ona mierzona w sekundach na sekundę, czyli ile sekund zajęło naszemu systemowi wykonanie tej grupy żądań na sekundę. Jeśli widzisz tam więcej niż sekundę na sekundę, oznacza to, że musiałeś podać więcej niż jeden rdzeń. To bardzo dobry wskaźnik. Można zrozumieć, że na przykład ten przyjaciel potrzebuje co najmniej trzech rdzeni.
To jest nasze know-how, czegoś takiego nigdzie nie widziałem. Uwaga – to bardzo prosta rzecz – sekunda na sekundę. Czasami, gdy procesor jest obciążony w 100%, to pół godziny na sekundę, to znaczy, że spędziłeś pół godziny na wykonywaniu tylko tych żądań.
Następnie widzimy liczbę wierszy na sekundę. Wiemy, ile wierszy na sekundę zwróciło.
A potem jest jeszcze ciekawa rzecz. Ile wspólnych buforów odczytujemy na sekundę z samych dzielonych buforów. Trafienia już tam były i pobraliśmy wiersze z pamięci podręcznej systemu operacyjnego lub z dysku. Pierwsza opcja jest szybka, a druga może być szybka lub nie, w zależności od sytuacji.
Drugim sposobem różnicowania jest podzielenie liczby żądań w tej grupie. W drugiej kolumnie zawsze będziesz mieć jedno zapytanie podzielone na zapytanie. A to ciekawe - ile milisekund było w tym żądaniu. Wiemy, jak średnio zachowuje się to zapytanie. Na każde żądanie potrzeba było 101 milisekund. Jest to tradycyjny wskaźnik, który musimy zrozumieć.
Ile wierszy zwracało średnio każde zapytanie? Widzimy 8 powrotów tej grupy. Średnio, ile zostało pobrane z pamięci podręcznej i przeczytane. Widzimy, że wszystko jest ładnie buforowane. Solidne hity pierwszej grupy.
Czwarty podciąg w każdym wierszu określa procent całości. Mamy połączenia. Powiedzmy 1 000 000. Możemy zrozumieć, jaki wkład wnosi ta grupa. Widzimy, że w tym przypadku pierwsza grupa wniosła mniej niż 0,01%. Czyli jest na tyle powolny, że nie widzimy go na ogólnym obrazie. A druga grupa to 5% na połączenia. Oznacza to, że 5% wszystkich połączeń to druga grupa.
Total_time jest również interesujący. Na pierwszą grupę zgłoszeń poświęciliśmy 14% naszego całkowitego czasu pracy. A dla drugiego - 11% itd.
Nie będę wdawał się w szczegóły, ale są w tym subtelności. Na górze wyświetla się błąd, bo przy porównywaniu migawki mogą pływać, czyli część żądań może wypaść i w drugim już nie może się pojawić, natomiast mogą pojawić się jakieś nowe. I tam obliczamy błąd. Jeśli widzisz 0, to dobrze. Nie ma żadnych błędów. Jeśli poziom błędów wynosi do 20%, wszystko jest w porządku.
Następnie wracamy do naszego tematu. Musimy dostosować obciążenie pracą. Bierzemy to od góry do dołu i idziemy, aż osiągniemy 80% lub 90%. Zwykle jest to 10-20 grup. I tworzymy pliki dla pgbench. Używamy tam losowego. Czasem to niestety nie wychodzi. A w Postgres 12 będzie więcej możliwości wykorzystania tego podejścia.
A wtedy zyskujemy w ten sposób 80-90% całkowitego czasu. Co powinienem umieścić dalej po „@”? Przyglądamy się apelom, patrzymy, jak duże jest zainteresowanie i rozumiemy, że tak duże zainteresowanie tutaj zawdzięczamy. Z tych wartości procentowych możemy zrozumieć, jak zrównoważyć każdy z plików. Następnie korzystamy z pgbench i bierzemy się do pracy.
Mamy również K001 i K002.
K001 to jeden duży ciąg z czterema podciągami. Jest to cecha charakterystyczna całego naszego ładunku. Patrz druga kolumna i drugi podwiersz. Widzimy, że około półtorej sekundy na sekundę, czyli jeśli są dwa rdzenie, to będzie dobrze. Pojemność będzie wynosić około 75%. I to będzie działać w ten sposób. Jeśli będziemy mieli 10 rdzeni, to generalnie będziemy spokojni. W ten sposób możemy ocenić zasoby.
K002 to to, co nazywam klasami zapytań, tj. WYBIERZ, WSTAW, AKTUALIZUJ, USUŃ. I osobno WYBIERZ DO AKTUALIZACJI, bo to jest blokada.
I tutaj możemy stwierdzić, że SELECT to zwykli czytelnicy - 82% wszystkich połączeń, ale jednocześnie - 74% w total_time. Oznacza to, że nazywa się je dużo, ale zużywają mniej zasobów.
I wracamy do pytania: „Jak wybrać odpowiednie wspólne bufory?” Obserwuję, że większość benchmarków opiera się na pomyśle – zobaczmy jaka będzie przepustowość, czyli jaka będzie przepustowość. Zwykle mierzy się go w TPS lub QPS.
A my staramy się wycisnąć z samochodu jak najwięcej transakcji na sekundę za pomocą parametrów tuningowych. Tutaj jest dokładnie 311 na sekundę dla wyboru.
Ale nikt nie jeździ do pracy i z powrotem do domu na pełnych obrotach. To jest głupie. To samo z bazami danych. Nie musimy jechać z pełną prędkością i nikt tego nie robi. Nikt nie żyje w produkcji, która ma 100% CPU. Chociaż może ktoś żyje, ale to nie jest dobrze.
Pomysł jest taki, że zazwyczaj jedziemy na 20 procentach pojemności, a najlepiej nie więcej niż 50 procent. A przede wszystkim staramy się optymalizować czas reakcji dla naszych użytkowników. Oznacza to, że musimy obrócić pokrętła, aby warunkowo uzyskać minimalne opóźnienie przy prędkości 20%. To pomysł, który staramy się wykorzystywać także w naszych eksperymentach.
I na koniec rekomendacje:
- Pamiętaj o wykonaniu Laboratorium Baz Danych.
- Jeśli to możliwe, rób to na żądanie, aby się chwilę rozłożyło - pobaw się i wyrzuć. Jeśli masz chmury, jest to oczywiste, tj. masz dużo stania.
- Być ciekawym. A jeśli coś jest nie tak, sprawdź eksperymentalnie, jak się zachowuje. Nancy można wykorzystać do samodzielnego treningu sprawdzania działania bazy.
- I dąż do minimalnego czasu reakcji.
- I nie bój się źródeł Postgres. Pracując ze źródłami, musisz znać angielski. Jest tam mnóstwo komentarzy, wszystko jest tam wyjaśnione.
- Regularnie sprawdzaj stan bazy danych, przynajmniej raz na trzy miesiące, ręcznie lub za pomocą narzędzia Postgres.
pytania
Wielkie dzięki! Bardzo interesująca rzecz.
Dwa kawałki.
Tak, dwie sztuki. Tylko że nie do końca zrozumiałem. Czy podczas pracy z Nancy możemy zmienić tylko jeden parametr, czy całą grupę?
Mamy parametr konfiguracyjny delta. Możesz tam skręcić ile chcesz na raz. Ale musisz zrozumieć, że zmieniając wiele rzeczy, możesz wyciągnąć błędne wnioski.
Tak. Dlaczego zapytałem? Ponieważ trudno jest przeprowadzać eksperymenty, gdy masz tylko jeden parametr. Dokręć, zobacz jak to będzie działać. Wypuściłem go. Potem zaczynasz następny.
Można go jednocześnie dokręcić, ale oczywiście zależy to od sytuacji. Ale lepiej przetestować jeden pomysł. Wczoraj mieliśmy pomysł. Mieliśmy bardzo bliską sytuację. Były dwie konfiguracje. I nie mogliśmy zrozumieć, dlaczego jest taka duża różnica. I pojawił się pomysł, że trzeba zastosować dychotomię, aby konsekwentnie zrozumieć i znaleźć różnicę. Możesz od razu ustawić połowę parametrów tak samo, potem jedną czwartą itd. Wszystko jest elastyczne.
I jest jeszcze jedno pytanie. Projekt jest młody i rozwijający się. Dokumentacja jest już gotowa, czy jest szczegółowy opis?
Specjalnie umieściłem tam link do opisu parametrów. Jest tam. Ale wielu rzeczy jeszcze nie ma. Szukam ludzi o podobnych poglądach. I znajduję je, kiedy występuję. To jest bardzo fajne. Ktoś już ze mną współpracuje, ktoś tam pomógł i coś zrobił. A jeśli interesuje Cię ten temat, daj znać, czego brakuje.
Kiedy zbudujemy laboratorium, być może otrzymamy informację zwrotną. Zobaczmy. Dziękuję!
Cześć! Dziękujemy za raport! Widziałem, że istnieje wsparcie Amazon. Czy są plany wsparcia GSP?
Dobre pytanie. Zaczęliśmy to robić. I na razie to zamroziliśmy, bo chcemy zaoszczędzić pieniądze. Oznacza to, że istnieje obsługa uruchamiania na hoście lokalnym. Możesz samodzielnie utworzyć instancję i pracować lokalnie. Swoją drogą, właśnie to robimy. Robię to w Getlab, tam w GSP. Ale nie widzimy jeszcze sensu robienia takiej orkiestracji, ponieważ Google nie ma tanich miejsc. Jest ??? przypadkach, ale mają one ograniczenia. Po pierwsze, zawsze mają tylko 70% zniżki i nie można tam bawić się ceną. W miejscach spotowych podwyższamy cenę o 5-10%, aby zmniejszyć prawdopodobieństwo, że zostaniesz wyrzucony. Oznacza to, że oszczędzasz miejsca, ale możesz je odebrać w dowolnym momencie. Jeśli zaoferujesz trochę więcej niż inni, zostaniesz zabity później. Google ma zupełnie inną specyfikę. Jest jeszcze jedno bardzo złe ograniczenie – żyją tylko 24 godziny. Czasami chcemy przeprowadzić eksperyment przez 5 dni. Ale możesz to zrobić punktowo; plamy czasami utrzymują się miesiącami.
Cześć! Dziękujemy za raport! Wspomniałeś o sprawdzaniu. Jak obliczyć błędy stat_statements?
Bardzo dobre pytanie. Mogę Ci pokazać i opowiedzieć ze szczegółami. Krótko mówiąc, przyglądamy się, jak zmieniał się zbiór grup żądań: ile z nich odpadło, a ile nowych się pojawiło. Następnie sprawdzamy dwie metryki: całkowity czas i liczbę połączeń, więc występują dwa błędy. Przyglądamy się wkładowi pływających grup. Istnieją dwie podgrupy: ci, którzy wyjechali i ci, którzy przybyli. Zobaczmy, jaki jest ich wkład w ogólny obraz.
Nie boisz się, że w przerwie między migawkami obróci się tam dwa, trzy razy?
To znaczy, zarejestrowali się ponownie czy co?
Na przykład to żądanie zostało już raz wywłaszczone, następnie przyszło i zostało ponownie wywłaszczone, potem przyszło ponownie i zostało ponownie wywłaszczone. A tu coś obliczyłeś i gdzie to wszystko jest?
Dobre pytanie, będziemy musieli poszukać.
Zrobiłem podobną rzecz. Było oczywiście prościej, zrobiłem to sam. Musiałem jednak zresetować, zresetować stat_statements i w momencie tworzenia migawki dowiedzieć się, że było ich mniej niż pewna część, która nadal nie osiągnęła pułapu ilości stat_statements, które można tam zgromadzić. Rozumiem, że najprawdopodobniej nic nie zostało przemieszczone.
Tak tak.
Ale nie rozumiem, jak inaczej zrobić to niezawodnie.
Niestety nie pamiętam dokładnie, czy używamy tam tekstu zapytania, czy queryid z pg_stat_statements i na nim się skupiamy. Jeśli skupimy się na queryid, to teoretycznie porównujemy porównywalne rzeczy.
Nie, można go kilka razy wypchnąć pomiędzy migawkami i przyjść ponownie.
Z tym samym identyfikatorem?
Tak.
Przestudiujemy to. Dobre pytanie. Musimy to przestudiować. Ale na razie to, co widzimy, jest zapisane albo jako 0...
Jest to oczywiście rzadki przypadek, ale byłem zszokowany, gdy dowiedziałem się, że stat_statemetns może się tam przemieszczać.
W Pg_stat_statements może znajdować się wiele rzeczy. Natrafiliśmy na fakt, że jeśli masz włączone track_utility =, to Twoje zestawy również są śledzone.
Tak, oczywiście.
A jeśli masz hibernację Java, która jest losowa, wówczas tablica mieszająca zaczyna się tam znajdować. A gdy tylko wyłączysz bardzo załadowaną aplikację, otrzymasz 50-100 grup. I wszystko jest tam mniej więcej stabilne. Jednym ze sposobów walki z tym jest zwiększenie pg_stat_statements.max.
Tak, ale musisz wiedzieć, jak bardzo. I jakoś musimy na niego uważać. To jest to co robię. Oznacza to, że mam plik pg_stat_statements.max. I widzę, że w momencie robienia migawki nie osiągnąłem 70%. OK, więc nic nie straciliśmy. Zresetujmy. I znowu oszczędzamy. Jeśli następna migawka będzie mniejsza niż 70, najprawdopodobniej już nic nie straciłeś.
Tak. Wartość domyślna wynosi teraz 5. I to wielu osobom wystarczy.
Zwykle tak.
Video:
PS W swoim imieniu dodam, że jeśli Postgres zawiera poufne dane i nie da się ich włączyć do środowiska testowego, to można skorzystać . Schemat jest w przybliżeniu następujący:
Źródło: www.habr.com