Transkrypt raportu Bruce'a Momziana z 2020 roku "Odblokowanie menedżera blokad Postgresa".
(Uwaga: Wszystkie zapytania SQL z slajdów możesz uzyskać pod tym linkiem: )
Cześć! Cudownie znów być tutaj w Rosji. Przepraszam, że nie mogłem przyjechać w zeszłym roku, ale w tym roku mamy z Ivanem wielkie plany. Mam nadzieję, że będę tutaj znacznie częściej. Uwielbiam przyjeżdżać do Rosji. Odwiedzę Tiumeń i Twer. Bardzo się cieszę, że będę mógł odwiedzić te miasta.
Nazywam się Bruce Momjian. Pracuję w EnterpriseDB i zajmuję się Postgresem od ponad 23 lat. Mieszkam w Filadelfii w USA. Podróżuję około 90 dni w roku i uczestniczę w około 40 konferencjach. Moja , która zawiera slajdy, które teraz wam pokażę. Dlatego po konferencji możecie je pobrać z mojej osobistej strony. Znajduje się tam również około 30 prezentacji, a także filmy i wiele wpisów na blogu, ponad 500. To dość bogate źródło. I jeśli interesują was te materiały, serdecznie zapraszam do ich wykorzystania.
Kiedyś byłem wykładowcą, profesorem, zanim zacząłem pracować z Postgreaem. I bardzo się cieszę, że mogę teraz opowiedzieć wam to, co zamierzam przekazać. To jedna z moich najciekawszych prezentacji. Ta prezentacja zawiera 110 slajdów. Zaczniemy od prostych rzeczy, a na koniec wykład stanie się coraz trudniejszy i wystarczająco skomplikowany.
To dość nieprzyjemna rozmowa. Blokady nie są najbardziej popularnym tematem. Chcemy, aby to zniknęło. To jak chodzenie do dentysty.
- Blokady są problemem dla wielu osób pracujących w bazach danych, które mają jednocześnie wiele procesów. Potrzebują blokady. To znaczy, że dzisiaj przekażę wam podstawową wiedzę na temat blokad.
- Identyfikatory transakcji. To dość nudna część prezentacji, ale muszą być zrozumiane.
- Następnie omówimy rodzaje blokad. To dość mechaniczna część.
- A następnie podamy kilka przykładów blokad. I to będzie dość trudne do zrozumienia.
Porozmawiajmy o blokadach.
Terminologia jest u nas dość skomplikowana. Ile z was wie, skąd pochodzi ten fragment? Dwie osoby. To z gry zatytułowanej „Kolosalna przygoda w jaskini”. To była tekstowa gra komputerowa z lat 80-tych, wydaje mi się. Trzeba było wejść do jaskini, w labirynt, a tekst się zmieniał, ale treść była mniej więcej ta sama za każdym razem. Tak pamiętam tę grę.
I tutaj widzimy nazwy blokad, które przyszły do nas z Oracle. Używamy ich.
Tutaj widzimy terminy, które mnie niepokoją. Na przykład, SHARE UPDATE EXCLUSIVE. Następnie SHARE RAW EXCLUSIVE. Szczerze mówiąc, te nazwy nie są zbyt zrozumiałe. Postaramy się je przyjrzeć bardziej szczegółowo. Niektóre zawierają słowo „share”, które znaczy - oddzielić. Niektóre zawierają słowo „exclusive” - ekskluzywny. W niektórych zawarte są oba te słowa. Chciałbym zacząć od tego, jak te blokady działają.
I również bardzo ważne jest słowo „dostęp” - access. I słowo „row” - wiersz. T. j. dystrybucja dostępu, dystrybucja wierszy.
Jeszcze jeden problem, który należy zrozumieć w Postgres, niestety nie będę mógł o nim opowiedzieć podczas mojej prezentacji, to MVCC. Mam osobną prezentację na ten temat na mojej stronie internetowej. I jeśli myślisz, że ta prezentacja jest skomplikowana, to MVCC to prawdopodobnie moja najtrudniejsza tematyka. A jeśli jesteś zainteresowany, możesz obejrzeć ją na stronie. Możesz także zobaczyć wideo.
Kolejna kwestia, którą musimy zrozumieć - to identyfikatory transakcji. Wiele transakcji nie może działać bez unikalnych identyfikatorów. I tutaj mamy wyjaśnienie, czym jest transakcja. W Postgres istnieją dwa systemy numeracji transakcji. Wiem, że to nie jest zbyt estetyczne rozwiązanie.
Pamiętaj również, że slajdy będą dość trudne do przyswojenia, więc na czerwono zaznaczone elementy to te, na które należy zwrócić szczególną uwagę.
Patrzymy. Na czerwono zaznaczony jest numer transakcji. Tutaj pokazana jest funkcja SELECT pg_back. Zwraca moją transakcję i ID tej transakcji.
Jeszcze jeden moment, jeśli podoba Ci się ta prezentacja i chcesz ją uruchomić w swojej bazie danych, możesz kliknąć w ten różowy link i pobrać SQL dla tej prezentacji. Możesz po prostu uruchomić go w swoim PSQL, a cała prezentacja pojawi się na Twoim ekranie natychmiast. Nie zawiera ona kolorów, ale przynajmniej będziemy mogli ją zobaczyć.
W tym przypadku widzimy identyfikator transakcji. To numer, który jej nadaliśmy. Istnieje także inny typ identyfikatora transakcji w Postgres, który nazywa się wirtualnym identyfikatorem transakcji.
Musimy to zrozumieć. To bardzo ważne, inaczej nie będziemy mogli zrozumieć blokady w Postgres.
Wirtualny identyfikator transakcji to identyfikator transakcji, który nie zawiera stałych wartości. Na przykład, jeśli uruchamiam polecenie SELECT, prawdopodobnie nie zmienię bazy danych, nie zablokuję niczego. Dlatego, kiedy uruchamiamy prosty SELECT, nie nadajemy tej transakcji stałego identyfikatora. Przekazujemy jej tylko wirtualny identyfikator.
Zwiększa to wydajność Postgres, poprawiając możliwości czyszczenia, dlatego wirtualny identyfikator transakcji składa się z dwóch liczb. Pierwsza liczba przed ukośnikiem to identyfikator backendu. A po prawej stronie widzimy po prostu licznik.
Dlatego, jeśli uruchamiam zapytanie, mówi, że identyfikator backendu to 2.
A jeśli uruchamiam serię takich transakcji, widzimy, że licznik za każdym razem zwiększa się, gdy uruchamiam zapytanie. Na przykład, gdy uruchamiam zapytanie 2/10, 2/11, 2/12 itd.
Pamiętaj, że mamy tutaj dwie kolumny. Po lewej widzimy wirtualny identyfikator transakcji – 2/12. A po prawej mamy stały identyfikator transakcji. To pole jest puste. Ta transakcja nie modyfikuje bazy danych. Dlatego nie przypisuję jej stałego identyfikatora transakcji.
Gdy tylko uruchamiam polecenie analizować (ANALYZE), to samo zapytanie zwraca mi stały identyfikator transakcji. Zobacz, jak to się zmieniło. Wcześniej nie miałem tego identyfikatora, a teraz się pojawił.
Więc, oto kolejne zapytanie, kolejna transakcja. Wirtualny identyfikator transakcji to 2/13. Jeśli poproszę o stały identyfikator transakcji, to po uruchomieniu zapytania go otrzymam.
Więc jeszcze raz. Mamy wirtualny identyfikator transakcji i stały identyfikator transakcji. Po prostu zrozum ten moment, aby zrozumieć zachowanie Postgres.
Przechodzimy do trzeciej sekcji. Tutaj omówimy różne typy blokad w Postgres. To nie jest zbyt interesujące. Ostatnia sekcja będzie znacznie ciekawsza. Jednak musimy omówić podstawowe kwestie, aby zrozumieć, co będzie dalej.
Przejdziemy przez tę sekcję, przyjrzymy się każdemu typowi blokad. Pokażę wam przykłady, jak są ustalane, jak działają, zaprezentuję kilka zapytań, które można użyć, aby zobaczyć, jak działają blokady w Postgres.
Aby stworzyć zapytanie i zobaczyć, co się dzieje w Postgres, musimy wydać zapytanie w systemowym widoku. W tym przypadku na czerwono wyróżniony jest pg_lock. Pg_lock to tabela systemowa, która informuje nas, jakie blokady są obecnie używane w Postgres.
Jednakże trudno mi pokazać wam pg_lock samodzielnie, ponieważ jest to dość skomplikowane. Dlatego stworzyłem widok, który pokazuje pg_locks. Wykonuje on również dla mnie pewne zadania, które pozwalają lepiej zrozumieć sytuację. To znaczy, wyklucza moje blokady, moją własną sesję itd. To po prostu standardowy SQL i pozwala lepiej pokazać, co się dzieje.
Kolejnym problemem jest to, że ten widok jest bardzo obszerny, dlatego muszę stworzyć drugi – lockview2.
I pokazuje mi dodatkowe kolumny z tabeli. I jeszcze jeden, który pokazuje mi pozostałe kolumny. To dość skomplikowane, więc starałem się to przedstawić jak najprościej.
Zatem stworzyliśmy tabelę o nazwie Lockdemo. I dodaliśmy tam jeden wiersz. To nasza przykładowa tabela. Stworzymy sekcje, aby po prostu pokazać wam przykłady blokad.
I tak, jeden wiersz, jedna kolumna. Pierwszy typ blokady nazywa się ACCESS SHARE. Jest to najmniej restrykcyjna blokada. Oznacza to, że praktycznie nie koliduje z innymi blokadami.
Jeśli chcemy explicite zdefiniować blokadę, uruchamiamy polecenie „lock table”. To wyraźnie zablokuje, tj. w trybie ACCESS SHARE uruchamiamy lock table. Jeśli uruchomię PSQL w tle, to w ten sposób uruchamiam drugą sesję z mojej pierwszej sesji. Co więc tutaj zrobię? Przechodzę do innej sesji i mówię jej „pokaż mi lockview dla tego zapytania”. I tutaj mam AccessShareLock w tej tabeli. To dokładnie to, o co prosiłem. I on mówi, że blokada została przydzielona. Bardzo prosto.
Następnie, jeśli spojrzymy na drugą kolumnę, to tam nic nie ma. Są puste.
Jeśli uruchamiam polecenie „SELECT”, to jest to implicytna (jawna) metoda, aby zażądać AccessShareLock. Dlatego wypuszczam moją tabelę i uruchamiam zapytanie, a zapytanie zwraca kilka wierszy. W jednym z wierszy widzimy AccessShareLock. Tak więc SELECT powoduje utworzenie AccessShareLock w tabeli. I praktycznie nie koliduje z niczym, ponieważ to jest blokada niskiego poziomu.
Co jeśli uruchomię SELECT i będę miał trzy różne tabele? Wcześniej uruchamiałem tylko jedną tabelę, teraz uruchamiam trzy: pg_class, pg_namespace i pg_attribute.
A teraz, kiedy patrzę na zapytanie, widzę 9 AccessShareLocks w trzech tabelach. Dlaczego? Na niebiesko zaznaczone są trzy tabele: pg_attribute, pg_class, pg_namespace. Możesz również zauważyć, że wszystkie indeksy, które są zdefiniowane za pośrednictwem tych tabel, mają również AccessShareLock.
I to jest blokada, która praktycznie nie koliduje z innymi. A wszystko, co robi, to po prostu nie pozwala nam zresetować tabeli, dopóki jej nie wybierzemy. To ma sens. To znaczy, jeśli wybieramy tabelę, w tym momencie znika, to byłoby błędne, więc AccessShare to blokada niskiego poziomu, która mówi nam „nie usuwaj tej tabeli, dopóki pracuję”. W zasadzie to wszystko, co robi.
ROW SHARE to blokada, która trochę się różni.
Weźmy przykład. SELECT ROW SHARE to sposób blokowania każdej wiersza osobno. Tak więc nikt nie może ich usunąć ani zmienić, dopóki je oglądamy.
Cóż, co robi SHARE LOCK? Widzimy, że ID transakcji 681 dla SELECT-a. I to jest interesujące. Co się tutaj wydarzyło? Po raz pierwszy widzimy numer w polu „Lock”. Bierzemy ID transakcji, a on mówi, że blokuje go w trybie ekskluzywnym. Wszystko, co robi, to informuje, że mam wiersz, który technicznie jest zablokowany gdzieś w tabeli. Ale nie wskazuje, gdzie dokładnie. Nieco później przyjrzymy się temu dokładniej.
Tutaj mówimy, że blokada jest przez nas używana.
Zatem blokada ekskluzywna explicite (jawnie) oznacza, że jest ekskluzywna. I jeśli usuniesz wiersz w tej tabeli, to tak się stanie, jak możesz zobaczyć.
SHARE EXCLUSIVE – to dłuższa blokada.
To jest polecenie (ANALYZE) analityka, które będzie używane.
SHARE LOCK – możesz explicite zablokować w trybie share.
Możesz również stworzyć unikalny indeks. I tam możesz zobaczyć SHARE LOCK, który jest jego częścią. I blokuje tabelę oraz nakłada na nią blokadę SHARE LOCK.
Domyślnie SHARE LOCK na tabeli oznacza, że inni mogą czytać tabelę, ale nikt nie może jej modyfikować. I to właśnie się dzieje, gdy tworzysz unikalny indeks.
Jeśli tworzę unikalny indeks równocześnie, to będę miał inny typ blokady, ponieważ, jak pamiętasz, użycie równoległych indeksów zmniejsza zapotrzebowanie na blokady. I jeśli zastosuję normalną blokadę, normalny indeks, to tym samym zapobiegam zapisywaniu w indeksie tabeli podczas jego tworzenia. Jeśli używam równoległego indeksu, to potrzebuję użyć innego typu blokady.
SHARE ROW EXCLUSIVE – znów można ją ustawić explicite (jawnie).
Lub możemy stworzyć regułę, tzn. wziąć jakiś określony przypadek, w którym będzie używana.
Blokada EXCLUSIVE oznacza, że nikt inny nie będzie mógł zmieniać tabeli.
Tutaj widzimy różne typy blokad.
ACCESS EXCLUSIVE, na przykład, to polecenie blokady. Na przykład, jeśli robisz CLUSTER table, to oznacza, że nikt nie będzie mógł tam zapisywać. I blokuje nie tylko samą tabelę, ale także indeksy.
To jest druga strona blokady ACCESS EXCLUSIVE, gdzie widzimy konkretnie, co ona blokuje w tabeli. Blokuje pojedyncze wiersze tabeli, co jest dość interesujące.
To wszystko podstawowe informacje, które chciałem podać. Mówiliśmy o blokadach, o identyfikatorach transakcji, rozmawialiśmy o wirtualnych identyfikatorach transakcji i o stałych identyfikatorach transakcji.
A teraz przejdźmy do przykładów blokad. To najciekawsza część. Spojrzymy na bardzo interesujące przypadki. Moim zadaniem w tej prezentacji jest dać Wam lepsze zrozumienie tego, co tak naprawdę robi Postgres, gdy próbuje blokować różne rzeczy. Uważam, że bardzo dobrze radzi sobie z blokowaniem poszczególnych części.
Spójrzmy na konkretne przykłady.
Zacznijmy od tabel i jednej linii w tabeli. Gdy coś wstawiam, uzyskuję ExclusiveLock, identyfikator transakcji i ExclusiveLock na tabeli.
A co się stanie, jeśli wstawię jeszcze dwa wiersze? Mamy teraz trzy wiersze w naszej tabeli. Wstawiłem jeden wiersz i uzyskałem takie wyniki. A jeśli wstawiam jeszcze dwa wiersze, co jest dziwnego? Jest tu pewna dziwność, ponieważ dodałem trzy wiersze do tej tabeli, ale nadal mam dwa wiersze w tabeli blokad. I to jest zasadniczo podstawowe zachowanie Postgresa.
Wielu myśli, że jeśli w bazie danych blokujesz 100 wierszy, będziesz musiał stworzyć 100 wpisów blokad. Jeśli blokuję od razu 1000 wierszy, to będę potrzebował 1000 takich zapytań. A jeśli potrzebuję zablokować milion lub miliard. Ale jeśli zrobimy to w ten sposób, to nie będzie dobrze działać. Jeśli używasz systemu, który tworzy wpisy blokad dla każdego pojedynczego wiersza, widzisz, że to jest skomplikowane. Ponieważ musisz określić tabelę blokad, która może się przepełnić, ale Postgres tak nie robi.
Na tym slajdzie ważne jest, że wyraźnie pokazuje się, że istnieje jeszcze jeden system, który działa wewnątrz MVCC, który blokuje poszczególne wiersze. Dlatego, gdy blokujesz miliardy wierszy, Postgres nie tworzy miliarda oddzielnych komend blokad. I to bardzo dobrze wpływa na wydajność.
A co z aktualizacją? Aktualnie aktualizuję wiersz i możesz zauważyć, że jednocześnie wykonuje dwie różne operacje. Zablokował jednocześnie tabelę, ale również zablokował indeks. Musiał zablokować indeks, ponieważ na tej tabeli są unikalne ograniczenia. Chcemy mieć pewność, że nikt go nie zmienia, dlatego go blokujemy.
A co będzie, jeśli chcę zaktualizować dwa wiersze? Widzimy, że zachowuje się tak samo. Przeprowadzamy dwa razy więcej aktualizacji, ale dokładnie taką samą liczbę blokad wierszy.
Jeśli jesteś ciekawy, jak to działa w Postgresie, musisz przesłuchać moje wystąpienia na temat MVCC, aby dowiedzieć się, jak Postgres wewnętrznie oznacza te wiersze, które zmienia. Postgres ma sposób, w jaki to robi, ale nie robi tego na poziomie blokady tabeli, lecz na niższym i bardziej efektywnym poziomie.
A co, jeśli chcę coś usunąć? Jeśli usuwam, na przykład, jeden wiersz i nadal mam swoje dwa wprowadzone blokady, a nawet jeśli chciałbym usunąć je wszystkie, to one wciąż tam są.
Na przykład, jeśli chcę wstawić 1 000 wierszy, a potem albo usunąć, albo dodać 1 000 wierszy, to te poszczególne wiersze, które dodaję lub zmieniam, nie są tutaj zapisywane. Zapisują się na niższym poziomie wewnątrz samego wiersza. Podczas wystąpienia o MVCC mówiłem o tym szczegółowo. Ale bardzo ważne jest, aby przy analizowaniu blokad upewnić się, że masz blokadę na poziomie tabeli i że tutaj nie widzisz, jak zapisywane są poszczególne wiersze.
A co z eksplicitną blokadą?
Jeśli kliknę 'zaktualizuj', to mam dwa zablokowane wiersze. A jeśli zaznaczę je wszystkie i kliknę 'aktualizuj wszędzie', to wciąż pozostają mi dwie blokady.
Nie tworzymy oddzielnych zapisów dla każdego pojedynczego wiersza. Bo wtedy spada wydajność, może być ich za dużo. I możemy znaleźć się w nieprzyjemnej sytuacji.
I to samo, jeśli zrobimy shared, możemy zrobić to 30 razy.
Przywracamy naszą tabelę, wszystko usuwamy, a potem ponownie wstawiamy jeden wiersz.
In Postgres, another type of behavior you see is a well-known and desired one—namely, that you can conduct updates or selects. And you can do this simultaneously. A select does not block an update, and the same goes in the reverse direction. We tell the reader not to block the writer, and the writer does not block the reader.
I'll show you an example of this. I will make a selection now. We'll then do an INSERT. And you will be able to see—694. You will see the ID of the transaction that performed this insert. And that's how it works.
And if I now look at my backend ID, it has become—695.
And I can see that 695 appears in my table.
And if I perform an update like this, I get another case. In this situation, 695 is an exclusive lock, and updates exhibit the same behavior, but there is no conflict between them, which is quite unusual.
And you may notice that at the top there's a ShareLock, while at the bottom there's an ExclusiveLock. And both transactions were completed.
And you need to listen to my talk on MVCC to understand how this works. But this illustrates that you can do it simultaneously, i.e., perform SELECT and UPDATE at the same time.
Let's reset and perform one operation again.
If you try to run two updates on the same row simultaneously, it will get locked. And remember, I said that the reader does not block the writer, while the writer blocks the reader, but one writer blocks another writer. That is, we cannot have two people updating the same row at the same time. One must wait for the other to finish.
And to illustrate this, I will look at the Lockdemo table. And we'll examine one row. In transaction 698.
We updated this to 2. 699 is the first update. And it either went through successfully, or it's in a pending transaction waiting for us to confirm or cancel.
Ale zwróć uwagę na coś innego – 2/51 – to nasza pierwsza transakcja, nasza pierwsza sesja. 3/112 – to drugi żądanie, które pojawiło się na górze i które zmieniło tę wartość na 3. Jeśli zauważysz, górna sesja zablokowała się sama, która ma 699. Ale 3/112 nie zapewniły blokady. W kolumnie Lock_mode napisano, że czeka. Czeka na 699. I jeśli spojrzysz, gdzie jest 699, jest wyżej. A co zrobiła pierwsza sesja? Utworzyła blokadę ekskluzywną na swoim własnym identyfikatorze transakcyjnym. Tak działa Postgres. Blokuje własny identyfikator transakcyjny. I jeśli chcesz poczekać, aż ktoś potwierdzi lub wycofa, musisz czekać, aż będzie oczekująca transakcja. Dlatego możemy zobaczyć dziwny wiersz.
Spójrzmy ponownie. Po lewej widzimy nasze id przetwarzania. W drugiej kolumnie widzimy nasz wirtualny identyfikator transakcji, a w trzeciej widzimy lock_type. Co to oznacza? W zasadzie mówi, że blokuje identyfikator transakcyjny. Ale zauważ, że we wszystkich wierszach na dole napisano relation. Dlatego masz dwa rodzaje blokad w tabeli. Jest blokada relation. A także jest blokada transactionid, gdzie sami blokujemy, to dokładnie to, co się dzieje w pierwszym wierszu lub na samym dole, gdzie transactionid, gdzie czekamy na zakończenie operacji 699.
Patrzę, co się tutaj dzieje. I jednocześnie zachodzą tutaj dwie rzeczy. Patrzysz na blokadę według identyfikatora transakcyjnego w pierwszym wierszu, która blokuje sama siebie. I blokuje sama siebie, aby zmusić ludzi do czekania.
Jeśli spojrzysz na 6. wiersz, to ta sama zapis, co pierwszy. Dlatego transakcja 699 jest blokowana. 700 również się samoblokuje. A potem w dolnym wierszu zobaczysz, że czekamy, aż 699 zakończy swoją operację.
A w lock_type, tuple widzisz liczby.
Możesz zobaczyć, że jest 0/10. To numer strony, a także offset tego konkretnego wiersza.
I widzisz, że zmienia się na 0/11, gdy aktualizujemy.
Ale tak naprawdę – to 0/10, ponieważ występuje oczekiwanie na tę operację. Możemy zobaczyć, że to ten wiersz, który czekam, aby potwierdzić.
Gdy tylko to potwierdzimy i naciśniemy commit, a aktualizacja się zakończy, to co dostajemy z powrotem. Transakcja 700 to jedyne zablokowanie, nie czeka już na nikogo, ponieważ została zakomitowana. Po prostu czeka na zakończenie transakcji. Gdy tylko 699 się kończy, nie czekamy już na nic. A teraz transakcja 700 mówi, że wszystko jest w porządku, że wszystkie blokady, które są potrzebne, ma we wszystkich dozwolonych tabelach.
Aby jeszcze bardziej skomplikować tę sprawę, tworzymy kolejny widok, który tym razem dostarczy nam hierarchię. Nie oczekuję, że zrozumiecie ten zapytanie. Ale to da nam jaśniejszy obraz tego, co się dzieje.
To jest rekurencyjny widok, który ma także dodatkową sekcję. A następnie znowu zwraca wszystko razem. Użyjmy tego.
Co jeśli zrobimy trzy równoczesne aktualizacje i powiemy, że rząd teraz wynosi trzy. I zmienimy 3 na 4.
I oto widzimy 4. A identyfikator transakcji 702.
Następnie zmienię 4 na 5. A 5 na 6, a 6 na 7. I kolejkuję rząd ludzi, którzy będą czekać, aż ta jedna transakcja się zakończy.
I wszystko staje się jasne. Jaka jest pierwsza kolejka? To 702. To identyfikator transakcji, który początkowo ustawił tę wartość. A co mam zapisane w kolumnie Granted? Mam oznaczenia f. To są moje aktualizacje, które (5, 6, 7) nie mogą być zatwierdzone, ponieważ czekamy, aż identyfikator transakcji 702 się zakończy. Mamy blokadę identyfikatora transakcji. I dostajemy 5 blokad transakcyjnych ID.
A jeśli spojrzysz na 704, na 705, to tam jeszcze nic nie jest napisane, ponieważ jeszcze nie wiedzą, co się dzieje. Po prostu piszą, że nie mają pojęcia, co się dzieje. I po prostu zasną, ponieważ czekają, aż ktoś zakończy i obudzi ich, gdy będzie możliwość zmiany rzędu.
Tak to wygląda. Jasne, że wszyscy czekają na 12-ą linię.
To, co widzieliśmy tutaj. Oto 0/12.
I tak, gdy pierwsza transakcja zostanie zatwierdzona, możesz zobaczyć, jak działa hierarchia. I teraz wszystko staje się jasne. Wszyscy są czystymi. I oni tak naprawdę wciąż czekają.
Oto, co się dzieje. 702 zostaje zatwierdzone. A teraz 703 otrzymuje blokadę wiersza, a następnie 704 zaczyna czekać, aż 703 zostanie zatwierdzone. I 705 również na to czeka. A gdy wszystko to się kończy, same się oczyszczają. Chciałbym wskazać, że wszyscy ustawiają się w kolejce. To bardzo przypomina sytuację z korkiem, gdy wszyscy czekają na pierwsze auto. Pierwsze auto zatrzymało się, a wszyscy ustawiają się w długiej linii. Potem ono rusza, następne auto może przejechać do przodu i uzyskać swoją blokadę i tak dalej.
A jeśli uznaliście, że to niewystarczająco skomplikowane, to teraz porozmawiamy o deadlockach. Nie wiem, kto z was z nimi się spotkał. To dość powszechny problem w systemach baz danych. Ale deadlock to sytuacja, w której jedna sesja czeka, aby coś wykonała inna sesja. A w tym czasie inna sesja czeka, żeby pierwsza sesja coś wykonała.
Na przykład, jeśli Ivan mówi: „Daj mi coś”, a ja mówię: „Nie, dam ci to tylko, jeśli mi dasz coś innego”. A on mówi: „Nie, nie dam ci tego, jeśli mi nie dasz”. I w tej sytuacji mamy deadlock. Jestem pewien, że Ivan tak nie zrobi, ale rozumiesz sens, że mamy dwóch ludzi, którzy chcą coś uzyskać, i nie są gotowi tego oddać, dopóki nie dostaną tego, czego chcą od drugiej osoby. I tu nie ma rozwiązania.
W zasadzie twoja baza danych musi to wykrywać. A następnie należy usunąć lub zamknąć jedną z sesji, ponieważ w przeciwnym razie pozostaną tam na zawsze. Widzimy to w bazach danych, widzimy to w systemach operacyjnych. I wszędzie tam, gdzie mamy równoległe procesy, coś takiego może mieć miejsce.
Teraz ustawimy dwa deadlocki. Ustawimy 50 i 80. W pierwszym wierszu wykonałem aktualizację z 50 na 50. Otrzymam numer transakcji 710.
A następnie zmienię 80 na 81, a 50 na 51.
I tak to będzie wyglądać. Dlatego 710 ma blokadę wiersza, a 711 czeka na potwierdzenie. Widzieliśmy to, gdy aktualizowaliśmy. 710 jest właścicielem naszego wiersza. A 711 czeka, aż 710 zakończy transakcję.
A tam nawet jest napisane, na którym dokładnie wierszu mamy deadlock. I tutaj zaczyna się to robić dziwne.
Teraz aktualizujemy 80 na 80.
I tutaj zaczynają się deadlocki. 710 oczekuje na odpowiedź od 711, a 711 oczekuje na 710. To się źle skończy. I nie ma z tego wyjścia. Będą oczekiwać na siebie nawzajem.
I to po prostu zacznie wszystko opóźniać. A tego nie chcemy.
I w Postgres są sposoby, aby zauważyć, kiedy to się dzieje. A kiedy to się dzieje, otrzymasz taki błąd. Z tego widać, że dany proces oczekuje na SHARE LOCK od innego procesu, czyli który jest zablokowany przez proces 711. A ten proces oczekiwał na SHARE LOCK na danym ID transakcji i został zablokowany przez inny proces. Dlatego mamy tutaj sytuację deadlocku.
A czy zdarzają się deadlocki trzypodmiotowe? Czy to możliwe? Tak.
Wprowadzamy te liczby do tabeli. Zmieniamy 40 na 40, wprowadzamy blokadę.
Zmieniamy 60 na 61, 80 na 81.
A następnie zmieniamy 80, a potem – bum!
I 714 teraz oczekuje na 715. 716 oczekuje na 715. I nic z tym nie można zrobić.
Tutaj już nie ma dwóch osób, jest już trzy osoby. Chcę czegoś od ciebie, ten chce czegoś od trzeciej osoby, a trzecia osoba chce czegoś ode mnie. I dostajemy się w trójstronne oczekiwanie, ponieważ wszyscy czekamy, aż inna osoba zakończy to, co ma do zrobienia.
I Postgres wie, w którym wierszu to się dzieje. Dlatego wyda ci następujące powiadomienie, które pokazuje, że masz problem, gdzie trzy procesy blokują się nawzajem. I nie ma ograniczeń. Może to mieć miejsce tam, gdzie 20 wpisów blokuje się nawzajem.
Następnym problemem jest serializable.
Jeśli specjalna blokada serializable.
I wracamy do 719. Ma całkiem normalne wydanie.
I możesz kliknąć, aby wykonać transakcję z serializable.
I rozumiesz, że masz teraz inny rodzaj blokady SA – to oznacza serializable.
I dlatego mamy nowy rodzaj blokady, którą nazywamy SARieadLock, która jest blokadą serii i pozwala na wprowadzanie numerów seryjnych.
Możesz również wstawiać unikalne indeksy.
W tej tabeli mamy unikalne indeksy.
Dlatego jeśli wprowadzę tutaj liczbę 2, mam 2. Ale na samej górze wprowadzam jeszcze jedno 2. Widzisz, że 721 ma ekskluzywną blokadę. Ale teraz 722 oczekuje, aż 721 zakończy swoją operację, ponieważ nie może wstawić 2, dopóki nie wie, co się stanie z 721.
A jeśli robimy subtransaction.
Oto mamy 723.
Jeśli zatrzymujemy punkt, a następnie go aktualizujemy, otrzymujemy nowy identyfikator transakcji. To kolejny rodzaj zachowania, który warto znać. Jeśli to zwrócimy, identyfikator transakcji znika. 724 znika. Ale teraz pojawia się 725.
I co próbuję tutaj zrobić? Próbuję pokazać wam przykłady nietypowych blokad, które możecie napotkać: czy to blokady serializable, czy SAVEPOINT – to różne rodzaje blokad, które będą się pojawiać w tabeli blokad.
To tworzenie eksplicytnych blokad, które mają pg_advisory_lock.
I widzicie, że typ blokady jest tu określony jako advisory. I jest tu napisane na czerwono "advisory". Możecie jednocześnie zablokować to za pomocą pg_advisory_unlock.
Kończąc, chciałbym pokazać wam jeszcze jedną bardzo ciekawą rzecz. Stworzę inny typ. Ale połączę tabelę pg_locks z tabelą pg_stat_activity. I dlaczego chcę to zrobić? Ponieważ pozwoli mi to zobaczyć i zrozumieć wszystkie bieżące sesje oraz to, jakich blokad oczekują. To jest dość interesujące, kiedy zbieramy razem tabelę blokad i tabelę zapytań.
I tutaj tworzymy pg_stat_view.
Aktualizujemy wiersz o jeden. I widzimy 724. Następnie aktualizujemy nasz wiersz do trzech. Co widzicie tutaj teraz? To są zapytania, tzn. widzicie cały listę zapytań, które są wymienione w lewej kolumnie. A po prawej stronie możecie zauważyć blokady i to, co tworzą. Może to być bardziej zrozumiałe dla was, aby nie było potrzeby co chwilę wracać do każdej sesji i sprawdzać – czy trzeba do niej dołączyć, czy nie. Zrobią to za nas.
Kolejna bardzo przydatna funkcja to pg_blocking_pidsPewnie nigdy o tym nie słyszeliście. Co ona robi? Pozwala nam powiedzieć, jakie dokładnie ID procesów dla tej sesji 11740 ona oczekuje. Możecie zobaczyć, że 11740 oczekuje na 724, a 724 znajduje się na samej górze. A 11306 to wasz ID procesu. Właściwie ta funkcja przechodzi przez waszą tabelę blokad. Wiem, że to trochę skomplikowane, ale udaje wam się to zrozumieć. W zasadzie ta funkcja przeszukuje tę tabelę blokad i stara się znaleźć, gdzie znajduje się ten ID procesu, biorąc pod uwagę blokady, na które czeka. Również próbuje obliczyć, jaki dokładnie ID procesu ma ten proces, który czeka na blokady. Dlatego możecie uruchomić tę funkcję. pg_blocking_pids.
I to bywa bardzo przydatne. Dodaliśmy to dopiero w wersji 9.6, więc ta funkcja ma zaledwie 5 lat, ale jest bardzo, bardzo użyteczna. To samo dotyczy drugiego zapytania. Pokazuje dokładnie to, co musimy zobaczyć.
To jest to, o czym chciałem z wami porozmawiać. I jak się spodziewałem, wykorzystaliśmy cały nasz czas, ponieważ było tak wiele slajdów. Slajdy są dostępne do pobrania. Chciałbym wam podziękować za obecność. Jestem pewien, że spodoba wam się reszta konferencji, dziękuję bardzo!
Pytania:
Na przykład, jeśli próbuję zaktualizować wiersze, a druga sesja stara się usunąć całą tabelę. Z tego, co rozumiem, powinno być coś takiego jak intent lock. Czy coś takiego istnieje w Postgresie?
Wracając do początku. Możecie pamiętać, że kiedy robicie cokolwiek, na przykład wykonujecie SELECT, przyznajemy AccessShareLock. I to zapobiega usuwaniu tabeli. Dlatego jeśli na przykład chcecie zaktualizować wiersz w tabeli lub usunąć wiersz, to nikt nie może usunąć całej tabeli jednocześnie, ponieważ utrzymujecie ten AccessShareLock nad całą tabelą i nad wierszem. A kiedy skończycie, mogą to usunąć. Ale dopóki coś zmieniacie, nie będą mogli tego zrobić.
Zróbmy to jeszcze raz. Przejdźmy do przykładu z usunięciem. I widzicie, jak na wierszu jest ekskluzywna blokada nad całą tabelą.
Będzie to wyglądać jak blokada ekskluzywna, prawda?
Tak, to wygląda na to. Rozumiem, o czym mówisz. Mówisz, że jeśli wykonam SELECT, to będę miał ShareExclusive, a potem przekształcam to w stan Row Exclusive, czy to staje się problemem? Ale co zaskakujące, nie stwarza to problemu. To przypomina zwiększenie poziomu blokady, ale w rzeczywistości mam blokadę, która zapobiega usunięciu. I teraz, gdy wzmacniam tę blokadę, nadal zapobiega ona usunięciu. Więc to nie jest tak, że podnoszę ją w górę. Tzn. zapobiegała temu nawet na niższym poziomie, więc kiedy podnoszę jej poziom, nadal zapobiega usunięciu tabeli.
Rozumiem, o czym mówisz. Nie ma tu przypadku zwiększania poziomu blokady, gdzie próbujesz zrezygnować z jednej blokady, aby wprowadzić mocniejszą. Tutaj po prostu powszechnie zwiększa to zapobieganie, więc nie powoduje to żadnych konfliktów. Ale to dobre pytanie. Bardzo dziękuję, że je zadałeś!
Co musimy zrobić, aby uniknąć sytuacji deadlocka, gdy mamy wiele sesji, dużą liczbę użytkowników?
Postgres automatycznie wykrywa sytuacje deadlocka. I automatycznie usunie jedną z sesji. Jedynym sposobem, aby uniknąć sytuacji z martwymi blokadami, jest blokowanie ludzi w tej samej kolejności. Dlatego, gdy spojrzysz na swoje aplikacje, często powodem deadlocków… Załóżmy, że chcę zablokować dwie różne rzeczy. Jedna aplikacja blokuje tabelę 1, a inna aplikacja blokuje tabelę 2, a następnie tabelę 1. A najłatwiejszym sposobem na uniknięcie deadlocków jest spojrzenie na swoje aplikacje i upewnienie się, że blokowanie odbywa się w tej samej kolejności we wszystkich aplikacjach. I to zwykle eliminuje 80% problemów, ponieważ różni ludzie piszą te aplikacje. A jeśli blokujesz je w tej samej kolejności, to nie napotykasz sytuacji deadlocka.
Dziękuję bardzo za twoje wystąpienie! Mówiłeś o vacuum full i, jeśli dobrze rozumiem, to vacuum full przekształca porządek zapisów w osobnym przechowywaniu, dlatego zachowuje bieżące zapisy bez zmian. A dlaczego vacuum full wymaga wyłącznej blokady dostępu i dlaczego koliduje z operacjami zapisu?
To dobre pytanie. Powód jest taki, że vacuum full zajmuje tabelę. I w zasadzie tworzymy nową wersję tabeli. Tabela będzie nowa. Oznacza to, że będzie to zupełnie nowa wersja tabeli. Problem polega na tym, że kiedy to robimy, nie chcemy, by ludzie ją czytali, ponieważ potrzebujemy, aby zobaczyli nową tabelę. Dlatego to się wiąże z poprzednim pytaniem. Gdybyśmy mogli czytać jednocześnie, nie moglibyśmy przenieść i skierować ludzi do nowej tabeli. Musielibyśmy poczekać, aż wszyscy skończą czytanie tej tabeli, a więc w zasadzie mamy do czynienia z sytuacją lock exclusive.
Po prostu mówimy, że blokujemy od samego początku, ponieważ wiemy, że na końcu potrzebujemy ekskluzywnej blokady, aby przenieść wszystkich na nową kopię. Dlatego potencjalnie możemy to rozwiązać. I robimy to z równoczesnym indeksowaniem. Ale jest to znacznie trudniejsze do osiągnięcia. I to bardzo odnosi się do twojego poprzedniego pytania o lock exclusive.
Czy możliwe jest dodanie locking timeout w Postgres? W Oracle mogę na przykład napisać „wybierz do aktualizacji” i czekać 50 sekund na aktualizację. Było to dobre dla aplikacji. Ale w Postgres muszę to zrobić od razu i wcale nie czekać, albo czekać do jakiegoś momentu.
Tak, możesz ustawić timeout dla swoich blokad, swoich locks. Możesz także wydać polecenie no way, które będzie …, jeśli nie możesz od razu uzyskać blokady. Więc albo lock timeout, albo coś innego, co pozwoli ci to zrobić. Nie jest to realizowane na poziomie składniowym. Robi się to jako zmienna na serwerze. Czasami nie można tego używać.
Czy możesz otworzyć 75 slajd?
Tak.
A moje pytanie brzmi następująco. Dlaczego oba procesy aktualizacji czekają na 703?
To jest wspaniałe pytanie. Nie rozumiem, dlaczego Postgres tak robi. Kiedy 703 został utworzony, oczekiwał na 702. A gdy pojawiają się 704 i 705, wydaje się, że nie wiedzą, na co czekają, ponieważ nic jeszcze nie jest dostępne. Postgres działa w ten sposób: gdy nie możesz uzyskać blokady, mówi: „Po co cię obsługiwać?”, bo i tak czekasz na kogoś. Dlatego po prostu sprawmy, by wisiał w powietrzu, nie aktualizuje tego w ogóle. Ale co się tutaj wydarzyło? Gdy 702 zakończył proces, a 703 uzyskał swoją blokadę, system powrócił z powrotem. I oznajmił, że teraz mamy dwie osoby w oczekiwaniu. A teraz zaktualizujmy je razem. I wskażmy, że obie czekają.
Nie wiem, dlaczego Postgres tak postępuje. Ale jest problem, który nazywa się f…. Wydaje mi się, że to nie jest termin w języku rosyjskim. To wtedy wszyscy czekają na jedną blokadę, nawet jeśli jest 20 instancji, które czekają na blokadę. I nagle wszyscy budzą się jednocześnie. I wszyscy zaczynają próbować reagować. Ale system działa tak, że wszyscy czekają na 703. Ponieważ wszyscy czekają, natychmiast ustawiamy ich wszystkich w kolejce. A jeśli pojawia się jakiekolwiek inne nowe zapytanie, które zostało utworzone po tym, na przykład 707, to znów będzie pustka.
I myślę, że to robi się po to, by można było powiedzieć, że na tym etapie 702 czeka na 703, a wszyscy ci, którzy przyjdą później, nie będą mieli żadnego zapisu w tym polu. Ale gdy pierwszy oczekujący opuszcza, to wszyscy ci, którzy w tym momencie czekali na aktualizację, dostają ten sam znacznik. I dlatego wydaje mi się, że to zrobiono, aby móc obsługiwać je w kolejności, tak aby były poprawnie uporządkowane.
Zawsze patrzyłem na to jako na dość dziwny fenomen. Ponieważ tutaj, na przykład, w ogóle ich nie wymieniamy. Ale wydaje mi się, że za każdym razem, gdy dajemy nową blokadę, przyglądamy się wszystkim, którzy są w procesie oczekiwania. Wtedy ustawiamy ich wszystkich w kolejce. A następnie jakiekolwiek nowe zapytanie, które nadchodzi, trafia do kolejki dopiero wtedy, gdy następna osoba zakończy przetwarzanie. Bardzo dobre pytanie. Dziękuję bardzo za pytanie!
Wydaje mi się, że znacznie logiczniej jest, gdy 705 czeka na 704.
Ale problem jest następujący. Technicznie możesz obudzić ten lub ten. I dlatego obudzimy ten lub inny. Ale co się dzieje w działaniu systemu? Widzisz, jak 703 na samym szczycie zablokował swój własny identyfikator transakcji. Tak działa Postgres. I 703 jest zablokowany swoim własnym identyfikatorem transakcji, więc jeśli ktoś chce poczekać, będzie czekał na 703. A w zasadzie, 703 kończy. I dopiero po jego zakończeniu jakiś proces się budzi. I nie wiemy, który to będzie proces. Następnie stopniowo wszystko przetwarzamy. Ale nie jest jasne, który proces budzi się pierwszy, ponieważ może to być dowolny z tych procesów. W zasadzie mieliśmy harmonogram, który mówił, że teraz możemy budzić dowolny z tych procesów. Po prostu wybieramy jeden losowo. Dlatego oba muszą być oznaczone, ponieważ możemy budzić każdy z nich.
A problem polega na tym, że mamy CP-nieskończoność. I dlatego możemy obudzić późniejszy. I jeśli na przykład obudzimy późniejszy, to będziemy czekać na tego, który właśnie uzyskał blokadę, więc nie określamy, kto dokładnie będzie obudzony pierwszy. Tworzymy po prostu taką sytuację, a system będzie je budził w losowej kolejności.
Tak . Zobacz, są również interesujące i przydatne. Temat jest oczywiście przerażająco skomplikowany. Bardzo dziękuję, Bruce!
Źródło: habr.com
