Strojenie Linuksa w celu poprawy wydajności PostgreSQL. Ilia Kosmodemyansky

Transkrypcja raportu Ilyi Kosmodemyansky'ego z 2015 r. „Trenowanie Linuksa w celu poprawy wydajności PostgreSQL”

Zastrzeżenie: Zwracam uwagę, że niniejszy raport jest datowany na listopad 2015 r. – minęły ponad 4 lata i minęło dużo czasu. Wersja 9.4 omawiana w raporcie nie jest już obsługiwana. W ciągu ostatnich 4 lat wydano 5 nowych wydań PostgreSQL i 15 wersji jądra Linuksa. Jeśli przepiszesz te fragmenty, otrzymasz inny raport. Ale tutaj rozważamy podstawowe dostrojenie Linuksa dla PostgreSQL, które jest nadal aktualne.

Nazywam się Ilya Kosmodemyansky. Pracuję w PostgreSQL-Consulting. A teraz opowiem trochę o tym, co zrobić z Linuksem w odniesieniu do baz danych w ogóle, a PostgreSQL w szczególności, ponieważ zasady są dość podobne.

O czym będziemy rozmawiać? Jeśli komunikujesz się z PostgreSQL, to w pewnym stopniu musisz być administratorem UNIX-a. Co to znaczy? Jeśli porównamy Oracle i PostgreSQL, to w Oracle trzeba być w 80% administratorem bazy danych DBA i w 20% administratorem Linuksa.

W przypadku PostgreSQL jest to trochę bardziej skomplikowane. Dzięki PostgreSQL musisz znacznie lepiej zrozumieć, jak działa Linux. A przy okazji pobiegnij trochę za lokomotywą, bo ostatnio wszystko zostało całkiem fajnie zaktualizowane. Wydawane są nowe jądra, pojawia się nowa funkcjonalność, poprawia się wydajność itp.

Dlaczego mówimy o Linuksie? Bynajmniej nie dlatego, że jesteśmy na konferencji Linux, Peter, ale dlatego, że w dzisiejszych warunkach jednym z najbardziej uzasadnionych systemów operacyjnych do korzystania z baz danych w ogóle, a PostgreSQL w szczególności jest Linux. Ponieważ FreeBSD niestety rozwija się w bardzo dziwnym kierunku. Będą problemy zarówno z wydajnością, jak i wieloma innymi rzeczami. Wydajność PostgreSQL w systemie Windows jest generalnie odrębnym poważnym problemem, wynikającym z faktu, że Windows nie ma tej samej pamięci współdzielonej co UNIX, podczas gdy PostgreSQL jest z tym powiązany, ponieważ jest to system wieloprocesowy.

I myślę, że wszystkich mniej interesują egzotyki takie jak Solaris, więc chodźmy.

Nowoczesna dystrybucja Linuksa ma ponad 1 opcji syctl, w zależności od sposobu zbudowania jądra. Jednocześnie, jeśli spojrzymy na różne nakrętki, możemy coś dostosować na wiele sposobów. Istnieją parametry systemu plików dotyczące sposobu ich montowania. Jeśli masz pytania dotyczące tego, jak to uruchomić: co włączyć w BIOS-ie, jak skonfigurować sprzęt itp.

To bardzo duży tom, który można omówić przez kilka dni, a nie w jednym krótkim raporcie, ale teraz skupię się na ważnych sprawach, jak uniknąć tych grabieży, które gwarantują, że nie będziesz mógł dobrze korzystać z bazy danych w systemie Linux, jeśli nie poprawiaj ich. Jednocześnie ważnym punktem jest to, że wiele parametrów domyślnych nie jest uwzględnionych w ustawieniach poprawnych dla bazy danych. Oznacza to, że domyślnie będzie działać słabo lub wcale.

Jakie tradycyjne cele dostrajania są dostępne w systemie Linux? Myślę, że skoro wszyscy zajmujecie się administracją Linuksem, nie ma szczególnej potrzeby wyjaśniania, jakie są cele.

Możesz dostroić:

• CPU.
• Pamięć.
• Przechowywanie.
• Inny. Porozmawiamy o tym na koniec na przekąskę. Nawet takie parametry jak polityka oszczędzania energii mogą wpływać na wydajność w bardzo nieprzewidywalny i niezbyt przyjemny sposób.

Jaka jest specyfika PostgreSQL i ogólnie bazy danych? Problem w tym, że nie można zmodyfikować żadnego pojedynczego nakrętki i zobaczyć, że nasza wydajność znacznie się poprawiła.

Tak, istnieją takie gadżety, ale baza danych to skomplikowana sprawa. Współpracuje ze wszystkimi zasobami, którymi dysponuje serwer i woli w pełni współdziałać. Jeśli spojrzysz na aktualne zalecenia Oracle dotyczące korzystania z systemu operacyjnego hosta, będzie to przypominać żart o tym mongolskim kosmonaucie – nakarm psa i niczego nie dotykaj. Dajmy bazie danych wszystkie zasoby, sama baza danych wszystko uporządkuje.

W zasadzie w pewnym stopniu sytuacja wygląda dokładnie tak samo jak w przypadku PostgreSQL. Różnica jest taka, że ​​baza danych nie jest jeszcze w stanie sama przejąć wszystkich zasobów, czyli gdzieś na poziomie Linuksa trzeba to wszystko poukładać samodzielnie.

Główną ideą nie jest wybranie pojedynczego celu i rozpoczęcie jego strojenia, na przykład pamięci, procesora lub czegoś podobnego, ale przeanalizowanie obciążenia i próba maksymalnego poprawienia przepustowości, aby obciążenie, które stworzyli dobrzy programiści dla nas, w tym naszych użytkowników.

Oto zdjęcie wyjaśniające, co to jest. Istnieje bufor systemu operacyjnego Linux, pamięć współdzielona i bufory współdzielone PostgreSQL. PostgreSQL w przeciwieństwie do Oracle działa bezpośrednio tylko poprzez bufor jądra, czyli aby strona z dysku dostała się do jego pamięci współdzielonej, musi przejść przez bufor jądra i z powrotem, dokładnie taka sama sytuacja.

Dyski żyją w tym systemie. Narysowałem to jako dyski. W rzeczywistości może istnieć kontroler RAID itp.

I to wejście-wyjście w ten czy inny sposób dzieje się poprzez tę materię.

PostgreSQL to klasyczna baza danych. W środku jest strona. Całe wejście i wyjście odbywa się za pomocą stron. Za pomocą stron wnosimy bloki do pamięci. A jeśli nic się nie stało, po prostu je czytamy, po czym stopniowo znikają z tej pamięci podręcznej, ze współdzielonych buforów i lądują z powrotem na dysku.

Jeśli coś gdzieś wymienimy, to cała strona zostaje oznaczona jako zabrudzona. Zaznaczyłem je tutaj na niebiesko. A to oznacza, że ​​ta strona musi być zsynchronizowana z pamięcią blokową. Oznacza to, że kiedy to zabrudziliśmy, dokonaliśmy wpisu w WAL. I w pewnym cudownym momencie pojawiło się zjawisko zwane punktem kontrolnym. I w tym dzienniku zapisano informację, że przybył. A to oznacza, że ​​wszystkie brudne strony, które znajdowały się w tym momencie w tych współdzielonych buforach, zostały zsynchronizowane z dyskiem magazynującym za pomocą fsync poprzez bufor jądra.

Dlaczego to się robi? Jeśli straciliśmy napięcie, to nie dostaliśmy sytuacji, że wszystkie dane zostały utracone. Pamięć trwała, o której wszyscy nam mówili, jest póki co w teorii baz danych – to świetlana przyszłość, do której oczywiście dążymy i nam się to podoba, ale na razie żyją za minus 20 lat. I oczywiście wszystko to należy monitorować.

Zadaniem maksymalizacji przepustowości jest dostrojenie wszystkich tych etapów tak, aby wszystko przebiegało szybko tam i z powrotem. Pamięć współdzielona to w zasadzie pamięć podręczna stron. W PostgreSQL wysłaliśmy zapytanie wybierające lub coś, co pobrało te dane z dysku. Trafiły do ​​wspólnych buforów. W związku z tym, aby to działało lepiej, musi być dużo pamięci.

Aby to wszystko działało dobrze i szybko, musisz poprawnie skonfigurować system operacyjny na wszystkich etapach. I wybierz sprzęt zrównoważony, bo jeśli w jakimś miejscu masz brak równowagi, to możesz zrobić dużo pamięci, ale nie będzie ona obsługiwana z wystarczającą szybkością.

I przejrzyjmy każdy z tych punktów.

Aby strony te poruszały się tam i z powrotem szybciej, musisz osiągnąć następujące cele:

• Po pierwsze, musisz wydajniej pracować z pamięcią.
• Po drugie, to przejście, gdy strony z pamięci trafiają na dysk, powinno być wydajniejsze.
• I po trzecie, muszą być dobre dyski.

Jeśli masz w serwerze 512 GB RAM-u i to wszystko ląduje na dysku twardym SATA bez pamięci podręcznej, to cały serwer bazy danych zamienia się w nie tylko dynię, ale dynię z interfejsem SATA. Wpadniesz na to bezpośrednio. I nic cię nie uratuje.

Jeśli chodzi o pierwszy punkt dotyczący pamięci, są trzy rzeczy, które mogą bardzo utrudnić życie.

Pierwszym z nich jest NUMA. NUMA to rzecz stworzona w celu poprawy wydajności. W zależności od obciążenia można optymalizować różne rzeczy. W swojej nowej, obecnej formie nie jest zbyt dobry dla aplikacji takich jak bazy danych, które intensywnie korzystają ze współdzielonych buforów pamięci podręcznej stron.

W skrócie. Jak rozpoznać, że coś jest nie tak z NUMA? Odczuwasz nieprzyjemne pukanie, nagle jakiś procesor jest przeciążony. Jednocześnie analizujesz zapytania w PostgreSQL i widzisz, że nie ma tam nic podobnego. Zapytania te nie powinny obciążać tak procesora. Można to złapać przez długi czas. Łatwiej jest od samego początku zastosować się do właściwej rekomendacji dotyczącej konfiguracji NUMA dla PostgreSQL.

Co się naprawdę dzieje? NUMA oznacza nierównomierny dostęp do pamięci. Jaki jest sens? Masz procesor, obok niego jest jego pamięć lokalna. A te połączenia pamięci mogą pobierać pamięć z innych procesorów.

Jeśli biegniesz numactl --hardware, wtedy otrzymasz tak duży arkusz. Nie zabraknie między innymi pola odległości. Będą liczby - 10-20, coś w tym stylu. Liczby te to nic innego jak liczba przeskoków potrzebnych do pobrania tej zdalnej pamięci i użycia jej lokalnie. W zasadzie dobry pomysł. Zwiększa to wydajność znacznie w przypadku różnych obciążeń.

Teraz wyobraź sobie, że masz jeden procesor, który najpierw próbuje skorzystać ze swojej pamięci lokalnej, a następnie próbuje do czegoś pobrać inną pamięć poprzez połączenie międzysieciowe. A ten procesor pobiera całą pamięć podręczną strony PostgreSQL – to wszystko, niektóre gigabajty. Zawsze spotykasz się z najgorszym przypadkiem, ponieważ na procesorze w samym module jest zwykle mało pamięci. Cała obsługiwana pamięć przechodzi przez te połączenia. Okazuje się, że jest powolny i smutny. A Twój procesor obsługujący ten węzeł jest stale przeciążony. A czas dostępu do tej pamięci jest zły, powolny. Jest to sytuacja, której nie chcesz, jeśli używasz tej bazy danych.

Dlatego bardziej poprawną opcją dla bazy danych jest to, że system operacyjny Linux w ogóle nie wie, co się w niej dzieje. Aby uzyskać dostęp do pamięci w ten sam sposób.

Dlaczego? Wydawałoby się, że powinno być odwrotnie. Dzieje się tak z jednego prostego powodu: potrzebujemy dużo pamięci na pamięć podręczną strony - dziesiątki, setki gigabajtów.

A jeśli to wszystko przydzielimy i tam zbuforujemy nasze dane, wówczas zysk z korzystania z pamięci podręcznej będzie znacznie większy niż zysk z tak trudnego dostępu do pamięci. I odniesiemy tym samym korzyści nieporównywalne w porównaniu z tym, że efektywniej uzyskamy dostęp do pamięci za pomocą NUMA.

Dlatego w tej chwili istnieją dwa podejścia, dopóki nie nadejdzie świetlana przyszłość, a sama baza danych nie będzie w stanie dowiedzieć się, na jakich procesorach działa i skąd musi coś pobrać.

Dlatego właściwym podejściem jest całkowite wyłączenie NUMAna przykład podczas ponownego uruchamiania. W większości przypadków wygrane są tak rzędu wielkości, że pytanie, które jest lepsze, w ogóle nie pojawia się.

Jest inna opcja. Używamy go częściej niż pierwszego, ponieważ gdy klient przychodzi do nas po wsparcie, restart serwera jest dla niego dużą sprawą. Ma tam firmę. I doświadczają problemów z powodu NUMA. Dlatego staramy się go wyłączyć w mniej inwazyjny sposób niż ponowne uruchomienie, ale pamiętaj, aby sprawdzić, czy jest wyłączony. Bo jak pokazuje doświadczenie, dobrze jest, że wyłączymy NUMA na nadrzędnym procesie PostgreSQL, ale wcale nie jest konieczne, aby to działało. Musimy sprawdzić i przekonać się, że naprawdę się wyłączyła.

Jest dobry post Roberta Haasa. To jest jeden z osób zatwierdzających PostgreSQL. Jeden z kluczowych twórców wszystkich podrobów niskiego poziomu. A jeśli skorzystacie z linków z tego wpisu, opisują one kilka barwnych historii o tym, jak NUMA utrudniała ludziom życie. Spójrz, przestudiuj listę kontrolną administratora systemu dotyczącą tego, co należy skonfigurować na serwerze, aby nasza baza danych działała dobrze. Trzeba te ustawienia spisać i sprawdzić, bo inaczej nie będzie dobrze.

Pamiętaj, że dotyczy to wszystkich ustawień, o których będę mówić. Jednak zazwyczaj bazy danych są gromadzone w trybie master-slave w celu zapewnienia odporności na awarie. Nie zapomnij dokonać tych ustawień na urządzeniu podrzędnym, ponieważ pewnego dnia będziesz miał wypadek i przełączysz się na urządzenie podrzędne, a ono stanie się urządzeniem nadrzędnym.

W sytuacji awaryjnej, gdy wszystko jest bardzo źle, Twój telefon ciągle dzwoni, a szef przybiega z wielkim kijem, nie będziesz miał czasu myśleć o sprawdzaniu. A skutki mogą być dość katastrofalne.

Następnym punktem są ogromne strony. Ogromne strony są trudne do testowania osobno i nie ma sensu tego robić, chociaż istnieją testy porównawcze, które mogą to zrobić. Łatwo je znaleźć w Google.

Jaki jest sens? Masz niezbyt drogi serwer z dużą ilością pamięci RAM, na przykład ponad 30 GB. Nie używasz ogromnych stron. Oznacza to, że na pewno masz obciążenie związane z wykorzystaniem pamięci. A te koszty ogólne nie należą do najprzyjemniejszych.

Dlaczego? Więc co się dzieje? System operacyjny przydziela pamięć w małych fragmentach. To takie wygodne, tak to się działo w przeszłości. A jeśli wejdziemy w szczegóły, system operacyjny musi przetłumaczyć adresy wirtualne na fizyczne. Proces ten nie jest najprostszy, dlatego system operacyjny buforuje wynik tej operacji w buforze Translation Lookaside Buffer (TLB).

A ponieważ TLB jest pamięcią podręczną, w tej sytuacji pojawiają się wszystkie problemy związane z pamięcią podręczną. Po pierwsze, jeśli masz dużo pamięci RAM i jest ona przydzielona w małych porcjach, wówczas bufor ten staje się bardzo duży. A jeśli pamięć podręczna jest duża, przeszukiwanie jej jest wolniejsze. Narzut jest zdrowy i sam zajmuje miejsce, tj. RAM jest zużywany przez coś nieprawidłowego. Tym razem.

Po drugie – im bardziej powiększy się pamięć podręczna w takiej sytuacji, tym większe jest prawdopodobieństwo, że będziesz mieć braki w pamięci podręcznej. Wydajność tej pamięci podręcznej szybko maleje wraz ze wzrostem jej rozmiaru. Dlatego systemy operacyjne wymyśliły proste podejście. Jest używany w Linuksie od dłuższego czasu. Pojawił się we FreeBSD nie tak dawno temu. Ale mówimy o Linuksie. To są ogromne strony.

I tutaj należy zauważyć, że pomysł ogromnych stron był początkowo forsowany przez społeczności, do których należały Oracle i IBM, tj. producenci baz danych mocno wierzyli, że będzie to przydatne również w przypadku baz danych.

A jak można to zaprzyjaźnić się z PostgreSQL? Po pierwsze, w jądrze Linuksa muszą być włączone ogromne strony.

Po drugie, muszą być jawnie określone przez parametr sysctl - ile ich jest. Liczby tutaj pochodzą z jakiegoś starego serwera. Możesz obliczyć, ile masz wspólnych buforów, aby zmieściły się w nich ogromne strony.

A jeśli cały Twój serwer jest dedykowany PostgreSQL, dobrym punktem wyjścia jest przydzielenie albo 25% pamięci RAM na współdzielone bufory, albo 75%, jeśli masz pewność, że Twoja baza danych na pewno zmieści się w tych 75%. Punkt wyjścia pierwszy. I zastanów się, czy masz 256 GB pamięci RAM, odpowiednio będziesz mieć 64 GB dużych buforów. Oblicz w przybliżeniu z pewnym marginesem - na jaką wartość należy ustawić tę liczbę.

Przed wersją 9.2 (jeśli się nie mylę, od wersji 8.2) możliwe było połączenie PostgreSQL z dużymi stronami za pomocą biblioteki innej firmy. I tak należy zawsze postępować. Po pierwsze, potrzebujesz jądra, aby móc poprawnie przydzielać duże strony. A po drugie, aby aplikacja, która z nimi współpracuje, mogła z nich korzystać. Nie będzie to po prostu używane w ten sposób. Ponieważ PostgreSQL przydzielał pamięć w stylu System 5, można to zrobić za pomocą libhugetlbfs - to pełna nazwa biblioteki.

W wersji 9.3 poprawiono wydajność PostgreSQL podczas pracy z pamięcią i porzucono metodę alokacji pamięci w systemie 5. Wszyscy byli bardzo zadowoleni, bo w przeciwnym razie próbujesz uruchomić dwie instancje PostgreSQL na jednej maszynie, a on mówi, że nie mam wystarczającej ilości pamięci współdzielonej. I mówi, że sysctl należy poprawić. I jest taki sysctl, że nadal trzeba ponownie uruchomić komputer itp. Ogólnie wszyscy byli zadowoleni. Ale alokacja pamięci mmap przerwała korzystanie z ogromnych stron. Większość naszych klientów korzysta z dużych współdzielonych buforów. I zdecydowanie zalecamy, aby nie przechodzić na wersję 9.3, ponieważ koszty ogólne zaczęły być obliczane w dobrych procentach.

Społeczność zwróciła jednak uwagę na ten problem i w wersji 9.4 bardzo dobrze przerobiła to wydarzenie. W wersji 9.4 w pliku postgresql.conf pojawił się parametr, w którym można włączyć opcję try, on lub off.

Wypróbuj to najbezpieczniejsza opcja. Kiedy PostgreSQL się uruchamia, kiedy przydziela pamięć współdzieloną, próbuje pobrać tę pamięć z ogromnych stron. A jeśli to nie zadziała, nastąpi powrót do normalnego wyboru. A jeśli masz FreeBSD lub Solaris, możesz spróbować, zawsze jest bezpiecznie.

Jeśli jest włączony, po prostu się nie uruchamia, jeśli nie może wybierać spośród dużych stron. Tutaj już jest o tym, kto i co jest ładniejsze. Ale jeśli spróbujesz, sprawdź, czy naprawdę wyróżniłeś to, czego potrzebujesz, ponieważ jest dużo miejsca na błędy. Obecnie ta funkcja działa tylko w systemie Linux.

Jeszcze jedna mała uwaga, zanim pójdziemy dalej. Przezroczyste, ogromne strony nie dotyczą jeszcze PostgreSQL. Nie może ich normalnie używać. A dzięki przezroczystym, ogromnym stronom przy takim obciążeniu pracą, gdy potrzebny jest duży fragment pamięci współdzielonej, korzyści pojawiają się tylko w przypadku bardzo dużych wolumenów. Jeśli masz terabajty pamięci, może to mieć znaczenie. Jeśli mówimy o bardziej codziennych aplikacjach, gdy masz 32, 64, 128, 256 GB pamięci na swoim komputerze, to zwykłe ogromne strony są w porządku i po prostu wyłączamy Transparent.

I ostatnia rzecz dotycząca pamięci nie jest bezpośrednio związana z owocami, może naprawdę zrujnować ci życie. Na całą przepustowość duży wpływ będzie mieć fakt, że serwer stale się zmienia.

A to będzie bardzo nieprzyjemne pod wieloma względami. Głównym problemem jest to, że nowoczesne jądra zachowują się nieco inaczej niż starsze jądra Linuksa. A nadepnięcie na tę rzecz jest dość nieprzyjemne, ponieważ kiedy mówimy o jakiejś pracy z wymianą, kończy się to przedwczesnym przybyciem zabójcy OOM. A OOM-killer, który nie przybył na czas i upuścił PostgreSQL, jest nieprzyjemny. Wszyscy będą o tym wiedzieć, czyli do ostatniego użytkownika.

Co się dzieje? Masz tam dużą ilość RAM-u, wszystko działa dobrze. Ale z jakiegoś powodu serwer zawiesza się podczas wymiany i z tego powodu zwalnia. Wydawałoby się, że jest dużo pamięci, ale tak się dzieje.

Wcześniej zalecaliśmy ustawienie vm.swappiness na zero, czyli wyłączenie wymiany. Wcześniej wydawało się, że 32 GB RAM-u i odpowiadające im współdzielone bufory to ogromna ilość. Głównym celem zamiany jest zapewnienie miejsca do rzucenia skorupy, jeśli spadniemy. I nie było to już szczególnie spełnione. I co wtedy zrobisz z tą skorupą? Jest to zadanie, w którym nie jest zbyt jasne, dlaczego konieczna jest zamiana, zwłaszcza przy takim rozmiarze.

Ale w bardziej nowoczesnych, tj. Trzecich wersjach jądra, zachowanie się zmieniło. A jeśli ustawisz swap na zero, tj. wyłączysz go, to prędzej czy później, nawet jeśli pozostanie trochę pamięci RAM, przyjdzie do ciebie zabójca OOM, aby zabić najbardziej intensywnych konsumentów. Bo uzna, że ​​przy takim nakładzie pracy jeszcze trochę nam zostało i wyskoczymy, czyli nie po to, żeby dobić proces systemowy, ale żeby dograć coś mniej ważnego. Ten mniej ważny będzie intensywnym konsumentem pamięci współdzielonej, czyli poczmistrzem. A potem będzie dobrze, jeśli baza nie będzie musiała być przywracana.

Dlatego teraz domyślnie, o ile pamiętam, większość dystrybucji znajduje się gdzieś w okolicach 6, tj. w którym momencie należy zacząć używać wymiany w zależności od ilości pozostałej pamięci. Zalecamy teraz ustawienie vm.swappiness = 1, ponieważ to praktycznie go wyłącza, ale nie daje takich samych efektów jak w przypadku OOM-killera, który niespodziewanie przybył i zabił całość.

Co dalej? Kiedy mówimy o wydajności baz danych i stopniowo przechodzimy w stronę dysków, wszyscy zaczynają łapać się za głowy. Bo prawdę o tym, że dysk jest powolny, a pamięć szybka, znają wszyscy od dzieciństwa. I wszyscy wiedzą, że baza danych będzie miała problemy z wydajnością dysku.

Główny problem z wydajnością PostgreSQL związany ze skokami punktów kontrolnych nie występuje, ponieważ dysk jest wolny. Dzieje się tak najprawdopodobniej dlatego, że przepustowość pamięci i dysku nie jest zrównoważona. Jednakże mogą one nie być zrównoważone w różnych miejscach. PostgreSQL nie jest skonfigurowany, system operacyjny nie jest skonfigurowany, sprzęt nie jest skonfigurowany i sprzęt jest nieprawidłowy. A ten problem nie występuje tylko wtedy, gdy wszystko dzieje się jak należy, czyli albo nie ma obciążenia, albo ustawienia i sprzęt są dobrze dobrane.

Co to jest i jak wygląda? Zwykle osoby pracujące z PostgreSQL poruszały się w tej sprawie więcej niż raz. Wytłumaczę. Jak powiedziałem, PostgreSQL okresowo tworzy punkty kontrolne, aby zrzucić na dysk brudne strony z pamięci współdzielonej. Jeżeli mamy dużą ilość pamięci współdzielonej to checkpoint zaczyna intensywnie oddziaływać na dysk, gdyż zrzuca te strony za pomocą fsync. Dociera do bufora jądra i jest zapisywany na dyskach za pomocą fsync. A jeśli wolumen tego biznesu jest duży, możemy zaobserwować nieprzyjemny efekt, a mianowicie bardzo duże wykorzystanie dysków.

Tutaj mam dwa zdjęcia. Teraz wyjaśnię, co to jest. Są to dwa wykresy skorelowane w czasie. Pierwszy wykres przedstawia wykorzystanie dysku. Tutaj osiąga w tym momencie prawie 90%. Jeśli masz awarię bazy danych na dyskach fizycznych i wykorzystanie kontrolera RAID na poziomie 90%, jest to zła wiadomość. Oznacza to, że jeszcze trochę i osiągnie 100, a wejścia/wyjścia zatrzymają się.

Jeśli masz macierz dyskową, to jest to nieco inna historia. Zależy to od tego, jak jest skonfigurowany, jakiego rodzaju jest to tablica itp.

Równolegle konfigurowany jest tutaj wykres z wewnętrznego widoku postgres, który informuje, jak następuje punkt kontrolny. Kolor zielony pokazuje, ile buforów, tych brudnych stron, dotarło w tym momencie do tego punktu kontrolnego w celu synchronizacji. I to jest najważniejsza rzecz, którą musisz tutaj wiedzieć. Widzimy, że mamy tu sporo stron i w pewnym momencie trafiliśmy na planszę, czyli pisaliśmy i pisaliśmy, tutaj system dyskowy jest wyraźnie bardzo zajęty. A nasz punkt kontrolny ma bardzo silny wpływ na dysk. Idealnie sytuacja powinna wyglądać mniej więcej tak, czyli mieliśmy tutaj mniej nagrań. I możemy to naprawić za pomocą ustawień, aby nadal tak było. Czyli recykling jest niewielki, ale gdzieś tu coś piszemy.

Co należy zrobić, aby pokonać ten problem? Jeśli zatrzymałeś IO w bazie danych, oznacza to, że wszyscy użytkownicy, którzy przyszli spełnić swoje żądania, będą czekać.

Jeśli spojrzeć z punktu widzenia Linuksa, jeśli wziąłeś dobry sprzęt, poprawnie go skonfigurowałeś, normalnie skonfigurowałeś PostgreSQL tak, aby rzadziej tworzył te punkty kontrolne, rozkładał je w czasie między sobą, wtedy wkraczasz w domyślne parametry Debiana. W przypadku większości dystrybucji Linuksa wygląda to następująco: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Co to znaczy? Z jądra 2.6 pojawił się jeden demon opróżniania. Pdglush, w zależności od tego, kto używa którego, który jest zaangażowany w odrzucanie w tle brudnych stron z bufora jądra i odrzucanie, gdy konieczne jest odrzucenie brudnych stron bez względu na wszystko, gdy odrzucanie w tle nie pomaga.

Kiedy pojawia się tło? Kiedy 10% całkowitej pamięci RAM dostępnej na serwerze jest zajęte przez brudne strony w buforze jądra, w tle wywoływana jest specjalna funkcja odpisywania. Dlaczego to jest tło? Jako parametr bierze pod uwagę, ile stron należy odpisać. I powiedzmy, że zapisuje N stron. I na chwilę to coś zasypia. A potem przychodzi ponownie i kopiuje kolejne strony.

To niezwykle prosta historia. Problem jest jak z basenem, gdy wleje się do jednej rury, wpadnie do drugiej. Przybył nasz punkt kontrolny i jeśli wysłał kilka brudnych stron do wyrzucenia, to stopniowo cała sprawa zostanie starannie rozwiązana z bufora jądra pgflush.

Jeśli te brudne strony będą się nadal kumulować, to kumuluje się ich aż do 20%, po czym priorytetem systemu operacyjnego jest spisanie całości na dysk, bo zabraknie prądu i wszystko będzie dla nas złe. Stracimy te dane np.

Co to za sztuczka? Sztuczka polega na tym, że te parametry we współczesnym świecie wynoszą 20 i 10% całkowitej pamięci RAM znajdującej się na komputerze, są one absolutnie monstrualne pod względem przepustowości dowolnego posiadanego systemu dyskowego.

Wyobraź sobie, że masz 128 GB pamięci RAM. W systemie dyskowym pojawia się 12,8 GB. I bez względu na to, jaką masz pamięć podręczną, niezależnie od tego, jaką masz tam tablicę, nie wytrzymają tak długo.

Dlatego zalecamy natychmiastowe dostosowanie tych liczb w oparciu o możliwości kontrolera RAID. Od razu zaleciłem tutaj kontroler z 512 MB pamięci podręcznej.

Wszystko uważa się za bardzo proste. Możesz umieścić vm.dirty_background w bajtach. Te ustawienia anulują dwa poprzednie. Domyślnie jest ustawiony albo współczynnik, albo te z bajtami są aktywowane, wtedy te z bajtami będą działać. Ale ponieważ jestem konsultantem DBA i pracuję z różnymi klientami, próbuję rysować słomki, a zatem jeśli w bajtach, to w bajtach. Nikt nie dał żadnej gwarancji, że dobry administrator nie doda więcej pamięci do serwera, nie zrestartuje go i liczba pozostanie taka sama. Wystarczy obliczyć te liczby, aby wszystko się tam zmieściło z gwarancją.

Co się stanie, jeśli nie będziesz pasować? Napisałam, że skutecznie powstrzymuje się wszelkie zaczerwienienia, ale w rzeczywistości jest to przenośnia. System operacyjny ma duży problem - ma mnóstwo brudnych stron, więc IO, które generują Twoi klienci, zostaje skutecznie zatrzymane, czyli aplikacja przyszła wysłać zapytanie sql do bazy danych, czeka. Każde wejście/wyjście do niego ma najniższy priorytet, ponieważ baza danych jest zajęta przez punkt kontrolny. A kiedy skończy, nie jest całkowicie jasne. A kiedy osiągniesz opróżnianie bez tła, oznacza to, że całe twoje IO jest przez to zajęte. I dopóki to się nie skończy, nie zrobisz nic.

Są tu jeszcze dwie ważne kwestie, które wykraczają poza zakres tego raportu. Ustawienia te powinny być zgodne z ustawieniami w pliku postgresql.conf, czyli ustawieniami punktów kontrolnych. Twój system dyskowy musi być odpowiednio skonfigurowany. Jeśli masz pamięć podręczną w macierzy RAID, musi ona mieć baterię. Ludzie kupują RAID z dobrą pamięcią podręczną bez baterii. Jeżeli masz dyski SSD w RAID to muszą być serwerowe, muszą być tam kondensatory. Oto szczegółowa lista kontrolna. Ten link zawiera mój raport na temat konfigurowania dysku wydajnościowego w PostgreSQL. Tam są wszystkie te listy kontrolne.

Co jeszcze może bardzo utrudnić życie? To są dwa parametry. Są stosunkowo nowe. Domyślnie można je uwzględnić w różnych aplikacjach. Mogą też sprawić, że życie będzie równie trudne, jeśli zostaną włączone nieprawidłowo.

Są dwie stosunkowo nowe rzeczy. Pojawiły się już w rdzeniach trzecich. Jest to koszt sched_migration_cost w nanosekundach i sched_autogroup_enabled, który domyślnie wynosi jeden.

I w jaki sposób rujnują Ci życie? Co to jest koszt_sched_migracji? W systemie Linux program planujący może migrować proces z jednego procesora do drugiego. A w przypadku PostgreSQL, który wykonuje zapytania, migracja na inny procesor jest całkowicie niejasna. Z punktu widzenia systemu operacyjnego, przełączanie okien między openoffice a terminalem może być dobre, ale dla bazy danych jest to bardzo złe. Dlatego rozsądną polityką jest ustawienie migracji_koszt na dużą wartość, co najmniej kilka tysięcy nanosekund.

Co to będzie oznaczać dla planisty? Należy uznać, że w tym czasie proces jest nadal gorący. Oznacza to, że jeśli masz długoterminową transakcję, która robi coś od dłuższego czasu, osoba planująca to zrozumie. Założy, że dopóki nie upłynie ten limit czasu, nie ma potrzeby migracji tego procesu nigdzie. Jeśli w tym samym czasie proces coś zrobi, to nie zostanie nigdzie migrowany, będzie spokojnie pracował na przydzielonym mu procesorze. Wynik jest doskonały.

Drugi punkt to autogrupa. Dobrym pomysłem jest przy konkretnych obciążeniach niezwiązanych z nowoczesnymi bazami danych - polega to na grupowaniu procesów według terminala wirtualnego, z którego są uruchamiane. Jest to wygodne w przypadku niektórych zadań. W praktyce PostgreSQL jest systemem wieloprocesowym z preforkiem uruchamianym z jednego terminala. Masz moduł zapisujący blokady, punkt kontrolny, a wszystkie żądania klientów zostaną zgrupowane w jednym harmonogramie dla każdego procesora. I będą tam zgodnie czekać, aż będzie wolny, aby sobie przeszkadzać i zająć go dłużej. Jest to historia zupełnie niepotrzebna w przypadku takiego obciążenia i dlatego trzeba ją wyłączyć.

Mój kolega Aleksiej Lesowski przeprowadził testy za pomocą prostego pgbencha, w którym zwiększył koszt migracji o rząd wielkości i wyłączył automatyczne grupowanie. Różnica na złym sprzęcie wyniosła prawie 10%. Na liście mailingowej Postgres toczy się dyskusja, w której ludzie podają wyniki podobnych zmian w szybkości zapytań wpływ na 50%. Takich historii jest całkiem sporo.

I na koniec o polityce oszczędzania energii. Dobrą rzeczą jest to, że Linuksa można teraz używać na laptopie. I podobno dobrze zużywa baterię. Ale nagle okazuje się, że może się to zdarzyć również na serwerze.

Co więcej, jeśli wynajmujesz serwery od jakiegoś hostingodawcy, „dobrym” hostingerom nie zależy na tym, abyś miał lepszą wydajność. Ich zadaniem jest dbanie o to, aby znajdujące się w nich żelazo było wykorzystywane jak najefektywniej. Dlatego domyślnie mogą włączyć tryb oszczędzania energii laptopa w systemie operacyjnym.

Jeśli używasz tych rzeczy na serwerze z bazą danych pod dużym obciążeniem, twoim wyborem jest acpi_cpufreq + wydajność. Nawet w przypadku usługi ondemand będą problemy.

Intel_pstate to nieco inny sterownik. A teraz preferowany jest ten, ponieważ jest później i działa lepiej.

I odpowiednio gubernator jest tylko wydajnością. Ondemand, oszczędzanie energii i wszystko inne nie dotyczy Ciebie.

Wyniki analizy wyjaśniającej PostgreSQL mogą różnić się o kilka rzędów wielkości, jeśli włączysz oszczędzanie energii, ponieważ praktycznie procesor Twojej bazy danych będzie działał w całkowicie nieprzewidywalny sposób.

Elementy te mogą być uwzględnione domyślnie. Przyjrzyj się uważnie, czy domyślnie to włączyli. To może być naprawdę duży problem.

Na koniec chciałem podziękować chłopakom z naszego zespołu DBA PosgreSQL-Consulting, a mianowicie Maxowi Bogukowi i Alexeyowi Lesovsky'emu, którzy każdego dnia robią postępy w tej kwestii. A my staramy się zrobić wszystko, co w naszej mocy, dla naszych klientów, aby wszystko działało dla nich. To tak jak z instrukcjami bezpieczeństwa w lotnictwie. Wszystko tutaj jest zapisane krwią. Każdy z tych orzechów znajduje się w trakcie jakiegoś problemu. Chętnie się nimi z Tobą podzielę.

Pytania:

Dziękuję! Jeśli na przykład firma chce zaoszczędzić pieniądze i umieścić bazę danych i logikę aplikacji na jednym serwerze, lub jeśli firma podąża za modnym trendem architektur mikroserwisowych, w których PostgreSQL działa w kontenerze. Co to za sztuczka? Sysctl wpłynie globalnie na całe jądro. Nie słyszałem o jakiejś wirtualizacji sysctls, tak aby działały osobno na kontenerze. Jest tylko grupa c i jest tam tylko część kontroli. Jak możesz z tym żyć? A jeśli zależy Ci na wydajności, uruchom PostgreSQL na oddzielnym serwerze sprzętowym i dostrój go?

Odpowiedzieliśmy na Twoje pytanie na trzy sposoby. Jeśli nie mówimy o serwerze sprzętowym, który można dostroić itp., Spokojnie, wszystko będzie działać dobrze bez tych ustawień. Jeśli masz takie obciążenie, że musisz dokonać tych ustawień, to dojdziesz do serwera żelaznego wcześniej niż do tych ustawień.

Jaki jest problem? Jeśli jest to maszyna wirtualna, najprawdopodobniej będziesz mieć wiele problemów, na przykład z faktem, że na większości maszyn wirtualnych opóźnienie dysku jest dość nierówne. Nawet jeśli przepustowość dysku jest dobra, to jedna nieudana transakcja we/wy, która nie wpływa znacząco na średnią przepustowość, która miała miejsce w momencie punktu kontrolnego lub w momencie zapisu do WAL, to baza danych bardzo ucierpi na tym. Zauważysz to, zanim napotkasz te problemy.

Jeśli masz NGINX na tym samym serwerze, będziesz miał ten sam problem. Będzie walczył o wspólną pamięć. I nie dojdziesz do opisanych tutaj problemów.

Ale z drugiej strony niektóre z tych parametrów nadal będą dla Ciebie istotne. Na przykład ustaw dirty_ratio za pomocą sysctl, aby nie było to takie szalone - w każdym razie to pomoże. Tak czy inaczej będziesz mieć interakcję z dyskiem. I będzie to według błędnego schematu. Jest to ogólnie ustawienie domyślne dla parametrów, które pokazałem. W każdym razie lepiej je zmienić.

Mogą jednak wystąpić problemy z NUMA. Na przykład VmWare dobrze współpracuje z NUMA przy dokładnie odwrotnych ustawieniach. I tutaj musisz wybrać - serwer żelazny lub nieżelazny.

Mam pytanie związane z Amazon AWS. Mają wstępnie skonfigurowane obrazy. Jeden z nich nazywa się Amazon RDS. Czy istnieją jakieś niestandardowe ustawienia dla ich systemu operacyjnego?

Są tam ustawienia, ale są to różne ustawienia. Tutaj konfigurujemy system operacyjny pod kątem tego, jak baza danych będzie z tego korzystać. Istnieją parametry, które określają, dokąd powinniśmy się teraz udać, takie jak kształtowanie. Oznacza to, że potrzebujemy tak wielu zasobów, że teraz je pochłoniemy. Następnie Amazon RDS zwiększa te zasoby i wydajność tam spada. Istnieją indywidualne historie o tym, jak ludzie zaczynają mieszać w tej sprawie. Czasem nawet całkiem skutecznie. Ale to nie ma nic wspólnego z ustawieniami systemu operacyjnego. To jak włamać się do chmury. To inna historia.

Dlaczego przezroczyste ogromne strony nie mają żadnego efektu w porównaniu z Huge TLB?

Nie dawaj. Można to wyjaśnić na wiele sposobów. Ale tak naprawdę po prostu tego nie dają. Jaka jest historia PostgreSQL? Podczas uruchamiania przydziela duży fragment pamięci współdzielonej. To, czy są przezroczyste, czy nie, jest całkowicie nieistotne. To, że wyróżniają się na początku, wyjaśnia wszystko. A jeśli jest dużo pamięci i trzeba odbudować segment pamięci współdzielonej, odpowiednie będą przezroczyste ogromne strony. W PostgreSQL jest on po prostu przydzielany na początku w ogromnej porcji i to wszystko, a potem nie dzieje się tam nic specjalnego. Możesz oczywiście z niego skorzystać, ale istnieje ryzyko uszkodzenia pamięci współdzielonej podczas ponownej alokacji. PostgreSQL o tym nie wie.

Źródło: www.habr.com