serwerze<\/a> a wszystko to ostatecznie trafia na dysk twardy SATA bez \u017cadnej pami\u0119ci podr\u0119cznej, ca\u0142y serwer baz danych staje si\u0119 nie tylko dyni\u0105, ale dyni\u0105 z interfejsem SATA. B\u0119dziesz si\u0119 z tym bezpo\u015brednio zderza\u0107. I nic ci\u0119 nie uratuje.<\/p>\n<\/p>\n
<\/p>\n
Je\u015bli chodzi o pierwszy punkt dotycz\u0105cy pami\u0119ci, istniej\u0105 trzy rzeczy, kt\u00f3re mog\u0105 znacznie utrudni\u0107 \u017cycie. <\/p>\n
<\/p>\n
Pierwsza z nich to NUMA. NUMA to rzecz, kt\u00f3ra ma na celu popraw\u0119 wydajno\u015bci. W zale\u017cno\u015bci od obci\u0105\u017cenia mo\u017cna optymalizowa\u0107 r\u00f3\u017cne rzeczy. W swoim nowym obecnym kszta\u0142cie nie jest zbyt dobra dla aplikacji takich jak baz danych, kt\u00f3re intensywnie korzystaj\u0105 z pami\u0119ci podr\u0119cznej stron. <\/p>\n
<\/p>\n
<\/p>\n
Kr\u00f3tko m\u00f3wi\u0105c, jak zrozumie\u0107, \u017ce co\u015b jest nie tak z NUMA? Masz jaki\u015b nieprzyjemny ha\u0142as, nagle kt\u00f3ry\u015b z procesor\u00f3w jest przeci\u0105\u017cony. Analizujesz zapytania w PostgreSQL i widzisz, \u017ce nie ma tam nic, co by to uzasadnia\u0142o. Te zapytania nie powinny tak intensywnie obci\u0105\u017ca\u0107 CPU. Mo\u017cna to \u0142apa\u0107 d\u0142ugo. Pro\u015bciej skorzysta\u0107 na samym pocz\u0105tku z w\u0142a\u015bciwej rekomendacji, jak skonfigurowa\u0107 NUMA dla PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
Co tak naprawd\u0119 si\u0119 dzieje? NUMA to Non-Uniform Memory Access. O co chodzi? Masz CPU, obok niego jest jego lokalna pami\u0119\u0107. Ta pami\u0119\u0107 mo\u017ce przyci\u0105ga\u0107 pami\u0119\u0107 z innych CPU przez interkonekty.<\/p>\n
<\/p>\n
Je\u015bli uruchomisz numactl --hardware<\/code>, to zobaczysz du\u017cy zestaw danych. Mi\u0119dzy innymi b\u0119dzie tam pole distances. B\u0119d\u0105 cyfr\u00f3wki \u2013 10-20, co\u015b w tym stylu. Te cyfr\u00f3wki to nic innego jak liczba hop\u00f3w, aby pod\u0142\u0105czy\u0107 t\u0119 zdaln\u0105 pami\u0119\u0107 i u\u017cywa\u0107 jej lokalnie. W zasadzie to dobry pomys\u0142. Przy odpowiednich obci\u0105\u017ceniach znacznie przyspiesza wydajno\u015b\u0107.<\/p>\n<\/p>\n
Wyobra\u017a sobie, \u017ce masz jeden CPU, kt\u00f3ry najpierw pr\u00f3buje korzysta\u0107 z w\u0142asnej pami\u0119ci lokalnej, a nast\u0119pnie pr\u00f3buje za\u0142adowa\u0107 inn\u0105 pami\u0119\u0107 przez interconnect do czego\u015b. Ca\u0142a pami\u0119\u0107 podr\u0119czna strony PostgreSQL trafia na ten CPU \u2013 to wszystko, ile\u015b tam gigabajt\u00f3w. Zawsze dostajesz najgorszy przypadek, poniewa\u017c w module pami\u0119ci bezpo\u015brednio pod\u0142\u0105czonym do tego CPU zazwyczaj jest ma\u0142o pami\u0119ci. A ca\u0142a pami\u0119\u0107, kt\u00f3ra jest obs\u0142ugiwana, przemieszcza si\u0119 przez te interconnecty. To jest wolne i smutne. I masz procesor, kt\u00f3ry obs\u0142uguje ten w\u0119ze\u0142, non-stop przeci\u0105\u017cony. A czas dost\u0119pu do tej pami\u0119ci \u2013 jest z\u0142y, wolny. To sytuacja, kt\u00f3rej nie chcesz, je\u015bli u\u017cywasz tego do bazy danych. <\/p>\n
<\/p>\n
Dlatego bardziej poprawn\u0105 opcj\u0105 dla bazy danych jest ca\u0142kowite ukrycie dzia\u0142ania systemu operacyjnego Linux. Powinna ona odnosi\u0107 si\u0119 do pami\u0119ci tak, jak zwykle to robi. <\/p>\n
<\/p>\n
Dlaczego tak? Wydawa\u0142oby si\u0119, \u017ce powinno by\u0107 na odwr\u00f3t. Dzieje si\u0119 tak z jednego prostego powodu \u2013 potrzebujemy wiele pami\u0119ci dla pami\u0119ci podr\u0119cznej strony \u2013 dziesi\u0105tki, setki gigabajt\u00f3w. <\/p>\n
<\/p>\n
A je\u015bli to wszystko przydzielimy i zbuforujemy nasze dane w niej, to zysk z wykorzystania buforu b\u0119dzie zdecydowanie wi\u0119kszy ni\u017c korzy\u015b\u0107 z takiego sprytnego dost\u0119pu do pami\u0119ci. W ten spos\u00f3b zyskamy niepor\u00f3wnywalnie wi\u0119cej ni\u017c w przypadku bardziej efektywnego dost\u0119pu do pami\u0119ci z wykorzystaniem NUMA.<\/p>\n
<\/p>\n
Dlatego w chwili obecnej istniej\u0105 dwa podej\u015bcia, dop\u00f3ki jasna przysz\u0142o\u015b\u0107 nie nasta\u0142a i baza danych nie nauczy\u0142a si\u0119 sama rozumie\u0107, na kt\u00f3rych CPU dzia\u0142a i sk\u0105d powinna co\u015b pobra\u0107. <\/p>\n
<\/p>\n
<\/p>\n
Dlatego prawid\u0142owym podej\u015bciem jest ca\u0142kowite wy\u0142\u0105czenie NUMA<\/strong>, na przyk\u0142ad przy ponownym uruchomieniu. W wi\u0119kszo\u015bci przypadk\u00f3w zyski s\u0105 tak du\u017ce, \u017ce w og\u00f3le nie ma pytania, co jest lepsze. <\/p>\n<\/p>\n
Jest inna opcja. Cz\u0119\u015bciej korzystamy z niej ni\u017c z pierwszej, poniewa\u017c, gdy klient zg\u0142asza si\u0119 do nas z problemem, ponowne uruchomienie serwera to dla niego du\u017ca sprawa. Jego biznes tam dzia\u0142a. A oni do\u015bwiadczaj\u0105 problem\u00f3w z NUMA. Dlatego staramy si\u0119 wy\u0142\u0105czy\u0107 to mniej inwazyjnymi metodami ni\u017c reboot, ale tutaj trzeba ostro\u017cnie sprawdzi\u0107, czy zosta\u0142o to wy\u0142\u0105czone. Poniewa\u017c do\u015bwiadczenie pokazuje, \u017ce wy\u0142\u0105czaj\u0105c NUMA dla g\u0142\u00f3wnego procesu PostgreSQL, to dzia\u0142a dobrze, ale niekoniecznie jest gwarancj\u0105, \u017ce to zadzia\u0142a. Nale\u017cy sprawdzi\u0107 i upewni\u0107 si\u0119, \u017ce rzeczywi\u015bcie to wy\u0142\u0105czono. <\/p>\n
<\/p>\n
Jest dobry post Roberta Haasa. To jeden z komituj\u0105cych do PostgreSQL. Jeden z kluczowych deweloper\u00f3w wszystkich niskopoziomowych komponent\u00f3w. Je\u015bli przejdziecie przez linki zawarte w tym po\u015bcie, opisuje kilka barwnych historii o tym, jak NUMA utrudnia\u0142a \u017cycie. Sp\u00f3jrzcie, przestudiujcie checklist\u0119 administratora systemu, co nale\u017cy skonfigurowa\u0107 na serwerze, aby nasza baza danych dzia\u0142a\u0142a dobrze. Te ustawienia nale\u017cy zanotowa\u0107 i monitorowa\u0107, poniewa\u017c w przeciwnym razie b\u0119dzie to mia\u0142o nieprzyjemne skutki. <\/p>\n
<\/p>\n
Zwracam uwag\u0119, \u017ce to dotyczy wszystkich ustawie\u0144, o kt\u00f3rych b\u0119d\u0119 m\u00f3wi\u0142. Zazwyczaj bazy danych s\u0105 konfigurowane w trybie master-slave dla zapewnienia odporno\u015bci na awarie. Nie zapomnijcie wprowadzi\u0107 tych ustawie\u0144 na slave, poniewa\u017c w pewnym momencie dojdzie do awarii, przestawicie si\u0119 na slave, a on stanie si\u0119 masterem. <\/p>\n
<\/p>\n
W sytuacji awaryjnej, gdy wszystko jest bardzo \u017ale, telefon non stop dzwoni, a szef przybiega z du\u017c\u0105 pa\u0142\u0105, nie b\u0119dziecie mieli czasu na my\u015blenie o sprawdzeniu. A wyniki mog\u0105 by\u0107 bardzo niekorzystne.<\/p>\n
<\/p>\n
<\/p>\n
Nast\u0119pny aspekt to huge pages. Huge pages trudno przetestowa\u0107 osobno, a w zasadzie nie ma sensu, chocia\u017c s\u0105 benchmarki, kt\u00f3re potrafi\u0105 to zrobi\u0107. \u0141atwo je znale\u017a\u0107 w Internecie. <\/p>\n
<\/p>\n
Na czym to polega? Macie serwer, kt\u00f3ry nie jest bardzo drogi, ale ma du\u017co pami\u0119ci RAM, na przyk\u0142ad powy\u017cej 30 GB. Nie u\u017cywacie huge pages. To oznacza, \u017ce macie z pewno\u015bci\u0105 overhead zwi\u0105zany z u\u017cywaniem pami\u0119ci. A ten overhead wcale nie jest przyjemny. <\/p>\n
<\/p>\n
<\/p>\n
Dlaczego tak jest? Co si\u0119 dzieje? System operacyjny przydziela pami\u0119\u0107 w ma\u0142ych kawa\u0142kach. To wygodne, tak historycznie si\u0119 u\u0142o\u017cy\u0142o. A je\u015bli wnikn\u0105\u0107 w szczeg\u00f3\u0142y, to OS musi przet\u0142umaczy\u0107 adresy wirtualne na fizyczne. Proces ten nie jest najprostszy, dlatego OS przechowuje wynik tej operacji w buforze Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Poniewa\u017c TLB to pami\u0119\u0107 podr\u0119czna, to w takiej sytuacji wyst\u0119puj\u0105 wszystkie charakterystyczne problemy zwi\u0105zane z pami\u0119ci\u0105 podr\u0119czn\u0105. Po pierwsze, je\u015bli macie bardzo du\u017co pami\u0119ci RAM i jest ona przydzielona w ma\u0142ych fragmentach, to bufor staje si\u0119 bardzo du\u017cy. A je\u015bli pami\u0119\u0107 podr\u0119czna jest du\u017ca, to jej przeszukiwanie zajmuje wi\u0119cej czasu. Overhead jest znaczny, a on sam zajmuje miejsce, to znaczy, \u017ce pami\u0119\u0107 RAM konsumuje co\u015b niepoprawnego. To pierwsza kwestia. <\/p>\n
<\/p>\n
Im wi\u0119cej ro\u015bnie pami\u0119\u0107 podr\u0119czna w takiej sytuacji, tym wi\u0119ksze prawdopodobie\u0144stwo, \u017ce do\u015bwiadczysz b\u0142\u0119d\u00f3w pami\u0119ci podr\u0119cznej. A efektywno\u015b\u0107 tej pami\u0119ci podr\u0119cznej szybko spada wraz ze wzrostem jej rozmiaru. Dlatego w systemach operacyjnych wymy\u015blono prosty spos\u00f3b. W Linuksie jest to od dawna stosowane. W FreeBSD wprowadzono to niedawno. Ale m\u00f3wimy o Linuksie. To s\u0105 huge pages.<\/p>\n
<\/p>\n
Warto zaznaczy\u0107, \u017ce huge pages jako koncepcja zosta\u0142a pierwotnie wprowadzona przez spo\u0142eczno\u015bci, kt\u00f3re obejmowa\u0142y Oracle i IBM, co oznacza, \u017ce producenci baz danych mocno zastanawiali si\u0119, jak to przyda si\u0119 tak\u017ce dla baz danych. <\/p>\n
<\/p>\n
<\/p>\n
Jak to po\u0142\u0105czy\u0107 z PostgreSQL? Po pierwsze, w j\u0105drze Linuksa musz\u0105 by\u0107 w\u0142\u0105czone huge pages.<\/p>\n
<\/p>\n
Po drugie, musz\u0105 by\u0107 wyra\u017anie okre\u015blone przez parametr sysctl \u2013 ile ich ma by\u0107. Liczby tutaj pochodz\u0105 z jakiego\u015b starego serwera. Mo\u017cesz obliczy\u0107, ile mniej wi\u0119cej masz shared buffers, aby huge pages mog\u0142y si\u0119 tam zmie\u015bci\u0107. <\/p>\n
<\/p>\n
Je\u015bli ca\u0142y serwer jest dedykowany PostgreSQL, dobrym punktem wyj\u015bcia jest przydzielenie 25% pami\u0119ci RAM na shared buffers lub 75%, je\u015bli jeste\u015b pewien, \u017ce w tych 75% twoja baza danych na pewno si\u0119 zmie\u015bci. To jest pierwszy punkt wyj\u015bcia. Oblicz, je\u015bli masz 256 GB pami\u0119ci RAM, to odpowiednio 64 GB b\u0119dzie twoimi shared buffers. Oblicz to z pewnym zapasem \u2013 na jak\u0105 warto\u015b\u0107 powiniene\u015b ustawi\u0107 t\u0119 liczb\u0119.<\/p>\n
<\/p>\n
Do wersji 9.2 (je\u015bli si\u0119 nie myl\u0119, to od wersji 8.2) mo\u017cna by\u0142o po\u0142\u0105czy\u0107 PostgreSQL z huge pages za pomoc\u0105 zewn\u0119trznej biblioteki. Zawsze nale\u017cy to robi\u0107. Po pierwsze, musisz mie\u0107 pewno\u015b\u0107, \u017ce j\u0105dro potrafi poprawnie przydziela\u0107 huge pages. Po drugie, aplikacja dzia\u0142aj\u0105ca z nimi musi m\u00f3c z nich skorzysta\u0107. Tak po prostu nie skorzysta. Poniewa\u017c PostgreSQL przydziela\u0142 pami\u0119\u0107 w stylu systemu 5, mo\u017cna by\u0142o to zrobi\u0107 za pomoc\u0105 libhugetlbfs \u2013 pe\u0142na nazwa biblioteki.<\/p>\n
<\/p>\n
W wersji 9.3 poprawiono wydajno\u015b\u0107 PostgreSQL w zakresie zarz\u0105dzania pami\u0119ci\u0105 i porzucono metod\u0119 przydzielania pami\u0119ci systemu 5. Wszyscy si\u0119 ucieszyli, poniewa\u017c w przeciwnym razie pr\u00f3buj\u0105c uruchomi\u0107 dwa instancje PostgreSQL na jednej maszynie, otrzymywa\u0142e\u015b komunikat o braku pami\u0119ci wsp\u00f3\u0142dzielonej. I m\u00f3wi\u0142, \u017ce trzeba poprawi\u0107 sysctl. A tam taki sysctl, \u017ce trzeba jeszcze zrestartowa\u0107 system itp. Og\u00f3lnie rzecz bior\u0105c, wszyscy si\u0119 ucieszyli. Jednak przydzielanie pami\u0119ci mmap zepsu\u0142o u\u017cycie huge pages. Wi\u0119kszo\u015b\u0107 naszych klient\u00f3w korzysta z du\u017cych bufor\u00f3w wsp\u00f3\u0142dzielonych. I zdecydowanie zalecali\u015bmy, aby nie przechodzi\u0107 na wersj\u0119 9.3, poniewa\u017c overhead zaczyna\u0142 si\u0119 liczy\u0107 w sporych procentach.<\/p>\n
<\/p>\n
Ale z drugiej strony spo\u0142eczno\u015b\u0107 zwr\u00f3ci\u0142a uwag\u0119 na ten problem i w wersji 9.4 bardzo dobrze przemy\u015blano t\u0119 kwesti\u0119. W wersji 9.4 pojawi\u0142 si\u0119 parametr w postgresql.conf, kt\u00f3ry pozwala w\u0142\u0105czy\u0107 tryb try, on lub off.<\/p>\n
<\/p>\n
Try to najbardziej bezpieczny parametr. Podczas uruchamiania PostgreSQL, kiedy przydziela pami\u0119\u0107 wsp\u00f3\u0142dzielon\u0105, pr\u00f3buje przej\u0105\u0107 t\u0119 pami\u0119\u0107 z huge pages. I je\u015bli si\u0119 nie uda, wraca do zwyk\u0142ego przydzielania. Je\u015bli korzystasz z FreeBSD lub Solaris, mo\u017cesz ustawi\u0107 try, to zawsze jest bezpieczne. <\/p>\n
<\/p>\n
Je\u015bli on, to po prostu nie uruchomi si\u0119, je\u015bli nie uda mu si\u0119 przydzieli\u0107 z huge pages. Tutaj ju\u017c \u2013 komu co bardziej odpowiada. Ale je\u015bli masz try, sprawdzaj, czy na pewno przydzieli\u0142o to, co trzeba, poniewa\u017c jest du\u017co przestrzeni na b\u0142\u0105d. Obecnie ta funkcjonalno\u015b\u0107 dzia\u0142a tylko na systemach Linux.<\/p>\n
<\/p>\n
Jeszcze jedna ma\u0142a uwaga, zanim przejdziemy dalej. Transparent huge pages \u2013 to nie jest opcja dla PostgreSQL jak dot\u0105d. Nie mo\u017ce ich wykorzysta\u0107 w spos\u00f3b prawid\u0142owy. A przy Transparent huge pages dla takiego obci\u0105\u017cenia, kt\u00f3re wymaga du\u017cych fragment\u00f3w pami\u0119ci wsp\u00f3\u0142dzielonej, korzy\u015bci pojawiaj\u0105 si\u0119 tylko przy naprawd\u0119 du\u017cych pojemno\u015bciach. Je\u015bli masz terabajty pami\u0119ci, wtedy mo\u017ce mie\u0107 to znaczenie. Je\u015bli m\u00f3wimy o bardziej codziennych zastosowaniach, gdy masz 32, 64, 128, 256 GB pami\u0119ci na maszynie, to zwyk\u0142e huge pages s\u0105 ok, a Transparent po prostu wy\u0142\u0105czamy. <\/p>\n
<\/p>\n
<\/p>\n
I ostatnia sprawa, dotycz\u0105ca pami\u0119ci, niezwi\u0105zana bezpo\u015brednio z wydajno\u015bci\u0105, mo\u017ce bardzo uprzykrzy\u0107 \u017cycie. Ca\u0142a przepustowo\u015b\u0107 mo\u017ce bardzo ucierpie\u0107, gdy serwer stale wymienia pami\u0119\u0107. <\/p>\n
<\/p>\n
I to b\u0119dzie bardzo nieprzyjemne w wielu momentach. A zasadnicza nieprzyjemno\u015b\u0107 polega na tym, \u017ce w nowoczesnych j\u0105drach zachowanie r\u00f3\u017cni si\u0119 nieco od starszych j\u0105der Linux. I to jest co\u015b, na co denerwuj\u0105co si\u0119 natykamy, poniewa\u017c, gdy m\u00f3wimy o pracy z swap'em, ko\u0144czy si\u0119 to nieterminowym przybyciem OOM-killera. A OOM-killer, kt\u00f3ry przyszed\u0142 za p\u00f3\u017ano i zabi\u0142 PostgreSQL, to nieprzyjemna sytuacja. Dowie si\u0119 o tym ka\u017cdy, to znaczy a\u017c do ostatniego u\u017cytkownika. <\/p>\n
<\/p>\n
<\/p>\n
Co si\u0119 dzieje? Masz tam du\u017c\u0105 ilo\u015b\u0107 pami\u0119ci operacyjnej, wszystko dzia\u0142a dobrze. Ale z jakiego\u015b powodu serwer zawiesza si\u0119 w swapie i zwalnia si\u0119 przez to. Wydawa\u0142oby si\u0119, \u017ce jest du\u017co pami\u0119ci, ale tak si\u0119 dzieje. <\/p>\n
<\/p>\n
<\/p>\n
Kiedy\u015b doradzali\u015bmy, aby ustawi\u0107 vm.swappiness na zero, tzn. wy\u0142\u0105czy\u0107 swap. Kiedy\u015b wydawa\u0142o si\u0119, \u017ce 32 GB pami\u0119ci operacyjnej i odpowiednie bufory shared to ogromna ilo\u015b\u0107. G\u0142\u00f3wnym celem swapu jest posiadanie miejsca, do kt\u00f3rego mo\u017cna wrzuci\u0107 procesy, je\u015bli co\u015b si\u0119 wysypie. I to ju\u017c przesta\u0142o dzia\u0142a\u0107. A co potem z tymi procesami? To ju\u017c takie zadanie, w kt\u00f3rym nie bardzo wiadomo, po co potrzebny jest swap, tym bardziej w tak du\u017cym rozmiarze. <\/p>\n
<\/p>\n
Jednak w nowoczesnych wersjach, tzn. w trzecich wersjach j\u0105dra, zachowanie si\u0119 zmieni\u0142o. I je\u015bli ustawisz swap na zero, tzn. wy\u0142\u0105czysz go, to pr\u0119dzej czy p\u00f3\u017aniej, nawet przy pozosta\u0142ej pewnej ilo\u015bci pami\u0119ci operacyjnej, OOM-killer przyjdzie, aby zabi\u0107 najbardziej intensywnych konsument\u00f3w. Poniewa\u017c uzna, \u017ce przy takim obci\u0105\u017ceniu zosta\u0142o nam jeszcze troch\u0119 i wyskoczymy, tzn. nie zabi\u0107 proces systemowy, ale czego\u015b mniej wa\u017cnego. Tym mniej wa\u017cnym oka\u017ce si\u0119 intensywny konsument pami\u0119ci shared, a mianowicie postmaster. I po tym b\u0119dzie dobrze, je\u015bli nie trzeba b\u0119dzie przywraca\u0107 bazy. <\/p>\n
<\/p>\n
Dlatego teraz domy\u015blnie, o ile pami\u0119tam, w wi\u0119kszo\u015bci dystrybucji to oko\u0142o 6, tzn. w jakim momencie zacz\u0105\u0107 u\u017cywa\u0107 swapu w zale\u017cno\u015bci od tego, ile pami\u0119ci pozosta\u0142o. Obecnie doradzamy ustawienie vm.swappiness = 1, poniewa\u017c praktycznie to wy\u0142\u0105cza, ale nie ma takich efekt\u00f3w, jak z niespodziewanie przyby\u0142ym OOM-killerem, kt\u00f3ry wszystko to zabija.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Co dalej? Kiedy m\u00f3wimy o wydajno\u015bci baz danych i stopniowo przechodzimy do dysk\u00f3w, wszyscy chwytaj\u0105 si\u0119 za g\u0142ow\u0119. Prawda jest taka, \u017ce dyski s\u0105 wolne, a pami\u0119\u0107 szybka, co jest znane ka\u017cdemu od dzieci\u0144stwa. Wszyscy wiedz\u0105, \u017ce w bazach danych pojawi\u0105 si\u0119 problemy z wydajno\u015bci\u0105 dysk\u00f3w.<\/p>\n
<\/p>\n
G\u0142\u00f3wny problem z wydajno\u015bci\u0105 PostgreSQL zwi\u0105zany z szczytami checkpoint\u00f3w nie wynika z wolnych dysk\u00f3w. Wynika to raczej z tego, \u017ce przepustowo\u015b\u0107 pami\u0119ci i dysk\u00f3w nie jest zr\u00f3wnowa\u017cona. Mog\u0105 by\u0107 one nier\u00f3wnowa\u017cone w r\u00f3\u017cnych miejscach. PostgreSQL nie jest skonfigurowany, system operacyjny nie jest skonfigurowany, sprz\u0119t nie jest skonfigurowany i sprz\u0119t jest niew\u0142a\u015bciwy. Tego problemu unika si\u0119 tylko w sytuacji, gdy wszystko dzia\u0142a jak nale\u017cy, to znaczy, \u017ce albo nie ma obci\u0105\u017cenia, albo ustawienia i sprz\u0119t s\u0105 dobrze dobrane. <\/p>\n
<\/p>\n
<\/p>\n
Czym to jest i jak to wygl\u0105da? Zazwyczaj ludzie, kt\u00f3rzy pracuj\u0105 z PostgreSQL, wielokrotnie stawali przed tym zagadnieniem. Ju\u017c wyja\u015bniam. Jak m\u00f3wi\u0142em, PostgreSQL okresowo wykonuje checkpointy, aby zapisa\u0107 brudne strony w pami\u0119ci wsp\u00f3\u0142dzielonej na dysku. Je\u015bli mamy du\u017c\u0105 ilo\u015b\u0107 pami\u0119ci wsp\u00f3\u0142dzielonej, to checkpoint zaczyna intensywnie wp\u0142ywa\u0107 na dysk, poniewa\u017c zapisuje te strony za pomoc\u0105 fsync. Trafia do bufora j\u0105dra i jest zapisywany na dyski za pomoc\u0105 fsync. Je\u015bli obj\u0119to\u015b\u0107 tego procesu jest du\u017ca, mo\u017cemy zaobserwowa\u0107 nieprzyjemny efekt, a mianowicie bardzo du\u017c\u0105 utylizacj\u0119 dysk\u00f3w.<\/p>\n
<\/p>\n
Tutaj mam dwa wykresy. Zaraz wyja\u015bni\u0119, czym one s\u0105. To dwa skorelowane w czasie wykresy. Pierwszy wykres to utylizacja dysk\u00f3w. W tym momencie osi\u0105ga prawie 90%. Je\u015bli masz baz\u0119 danych z fizycznymi dyskami i z kontrolerem RAID z utylizacj\u0105 blisk\u0105 90%, to s\u0105 to z\u0142e wie\u015bci. To znaczy, \u017ce jeszcze troch\u0119, a osi\u0105gnie 100% i operacje wej\u015bcia\/wyj\u015bcia zostan\u0105 zatrzymane. <\/p>\n
<\/p>\n
Je\u015bli masz macierz dyskow\u0105, to tam sytuacja jest nieco inna. Wtedy wszystko zale\u017cy od tego, jak jest skonfigurowana, co to za macierz itp. <\/p>\n
<\/p>\n
Jednocze\u015bnie skonfigurowano tutaj wykres z wewn\u0119trznej widoku Postgress, kt\u00f3ry pokazuje, jak odbywa si\u0119 checkpoint. Zielonym kolorem wskazano, ile bufor\u00f3w, tych brudnych stron, w tym momencie przyby\u0142o do tego checkpointu w celu synchronizacji. I to jest najwa\u017cniejsze, co tutaj nale\u017cy wiedzie\u0107. Wida\u0107, \u017ce mamy tutaj du\u017co stron, a w pewnym momencie napotkali\u015bmy na szczeliny, tzn. pisali\u015bmy pisali\u015bmy, wida\u0107, \u017ce system dyskowy jest bardzo zaj\u0119ty. I nasz checkpoint wywiera silny wp\u0142yw na dysk. W idealnej sytuacji powinno to wygl\u0105da\u0107 raczej tak, tzn. mieli\u015bmy mniej zapis\u00f3w. I ustawieniami mo\u017cemy to naprawi\u0107, aby tak by\u0142o w przysz\u0142o\u015bci. Tzn. utylizacja jest niewielka, ale gdzie\u015b co\u015b zapisujemy. <\/p>\n
<\/p>\n
Co trzeba zrobi\u0107, aby pokona\u0107 ten problem? Je\u015bli zatrzyma\u0142o si\u0119 IO pod baz\u0105 danych, to znaczy, \u017ce wszyscy u\u017cytkownicy, kt\u00f3rzy przyszli wykona\u0107 swoje zapytania, b\u0119d\u0105 czeka\u0107. <\/p>\n
<\/p>\n
<\/p>\n
Patrz\u0105c z punktu widzenia Linuxa, je\u015bli wzi\u0105\u0142e\u015b dobry sprz\u0119t, odpowiednio go skonfigurowa\u0142e\u015b, poprawnie skonfigurowa\u0142e\u015b PostgreSQL, aby rzadziej robi\u0142 te checkpointy, rozprzestrzenia\u0142 je w czasie, wchodzi si\u0119 w domy\u015blne parametry Debiana. Dla wi\u0119kszo\u015bci dystrybucji Linux taki obrazek: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Co to oznacza? Od j\u0105dra 2.6 pojawi\u0142 si\u0119 jeden demon flushingu. Pdglush w zale\u017cno\u015bci od tego, kto co u\u017cywa, kt\u00f3ry zajmuje si\u0119 t\u0142em zrzucania brudnych stron z bufora j\u0105dra oraz zrzucania, gdy to konieczne, za wszelk\u0105 cen\u0119 zrzucania brudnych stron, gdy backgroundowe zrzucanie ju\u017c nie pomaga. <\/p>\n
<\/p>\n
Kiedy nast\u0119puje background? Kiedy 10 % ca\u0142ej pami\u0119ci RAM, kt\u00f3ra jest dost\u0119pna na serwerze, jest zaj\u0119ta brudnymi stronami w buforze j\u0105dra, wywo\u0142ywana jest specjalna funkcja zrzucania w tle. Dlaczego nazywa si\u0119 to background? Przyjmuje jako parametr, ile stron zrzuci\u0107. I, powiedzmy, zrzuca N stron. A przez pewien czas ten mechanizm zasypia. A potem znowu przychodzi i zrzuca jeszcze pewn\u0105 ilo\u015b\u0107 stron. <\/p>\n
<\/p>\n
To bardzo prosta historia. Tutaj zadanie jest jak z basenem, kiedy w jedna rur\u0119 wlewa si\u0119, a druga wlewa. Nasz checkpoint przyszed\u0142 i je\u015bli wys\u0142a\u0142 ma\u0142o brudnych stron do zrzucenia, to stopniowo z bufora j\u0105dra pgflush to wszystko delikatnie si\u0119 wch\u0142onie. <\/p>\n
<\/p>\n
Je\u015bli te brudne strony b\u0119d\u0105 si\u0119 dalej gromadzi\u0107, mog\u0105 osi\u0105gn\u0105\u0107 20%; wtedy system operacyjny priorytetowo zarchiwizuje to na dysk, poniewa\u017c zasilanie mo\u017ce si\u0119 wy\u0142\u0105czy\u0107, a my b\u0119dziemy mieli problem. Stracimy na przyk\u0142ad te dane. <\/p>\n
<\/p>\n
Gdzie tkwi haczyk? Haczyk polega na tym, \u017ce te parametry w nowoczesnym \u015bwiecie 20% i 10% ca\u0142kowitej pami\u0119ci RAM, kt\u00f3r\u0105 ma maszyna, s\u0105 naprawd\u0119 ogromne z punktu widzenia przepustowo\u015bci jakiegokolwiek systemu dyskowego, kt\u00f3ry posiadasz.<\/strong> <\/p>\n<\/p>\n
Wyobra\u017a sobie, \u017ce masz 128 GB pami\u0119ci RAM. 12,8 GB trafia do twojego systemu dyskowego. I niezale\u017cnie od tego, jaki masz tam cache, ani jaki masz macierz, nie poradz\u0105 sobie z tym. <\/p>\n
<\/p>\n
<\/p>\n
Dlatego zalecamy natychmiastowe ustawienie tych warto\u015bci zgodnie z mo\u017cliwo\u015bciami twojego kontrolera RAID.<\/strong> Oto od razu podana rekomendacja dla kontrolera, kt\u00f3ry ma 512 MB cache. <\/p>\n<\/p>\n
Wszystko jest bardzo proste. Mo\u017cesz ustawi\u0107 vm.dirty_background w bajtach. Te ustawienia zast\u0119puj\u0105 dwa poprzednie. Albo domy\u015blne ratio, albo aktywowane te, kt\u00f3re s\u0105 w bajtach; zadzia\u0142aj\u0105 te w bajtach. Ale poniewa\u017c jestem konsultantem DBA i pracuj\u0119 z r\u00f3\u017cnymi klientami, staram si\u0119 zabezpiecza\u0107, wi\u0119c je\u015bli w bajtach, to w bajtach. Nikt nie daje \u017cadnej gwarancji, \u017ce dobry administrator nie doda pami\u0119ci serwerowi, nie zrestartuje go, a liczba pozostanie taka sama. Po prostu oszacuj te warto\u015bci, aby z gwarancj\u0105 wszystko si\u0119 zmie\u015bci\u0142o. <\/p>\n
<\/p>\n
Co si\u0119 stanie, je\u015bli nie zmie\u015bcisz si\u0119? Mam napisane, \u017ce skutecznie zatrzymuje si\u0119 wszelkie flushowanie, ale w rzeczywisto\u015bci to figura retoryczna. System operacyjny ma du\u017cy problem \u2013 ma du\u017co brudnych stron, wi\u0119c skutecznie zatrzymuje si\u0119 ten IO, kt\u00f3ry generuj\u0105 twoi klienci, tzn. gdy aplikacja wysy\u0142a zapytanie SQL do bazy danych, czeka. Ka\u017cdy I\/O w niej ma najni\u017cszy priorytet, poniewa\u017c baza jest zaj\u0119ta checkpointem. I kiedy j\u0105 zako\u0144czy, nie wiadomo. A gdy osi\u0105gniesz flushing, kt\u00f3ry nie jest t\u0142em ani w tle, to oznacza, \u017ce wszystkie IO s\u0105 zaj\u0119te tym. I dop\u00f3ki to si\u0119 nie zako\u0144czy, nic nie zrobisz. <\/p>\n
<\/p>\n
S\u0105 jeszcze dwa istotne aspekty, kt\u00f3re wykraczaj\u0105 poza ten raport. Te ustawienia powinny by\u0107 zgodne z ustawieniami w postgresql.conf, tzn. ustawieniami checkpoint\u00f3w. A tw\u00f3j system dyskowy musi by\u0107 odpowiednio skonfigurowany. Je\u015bli masz pami\u0119\u0107 podr\u0119czn\u0105 na RAID, to musi by\u0107 w niej bateria.<\/strong> Ludzie kupuj\u0105 RAID z dobr\u0105 pami\u0119ci\u0105 podr\u0119czn\u0105 bez baterii. Je\u015bli masz SSD w RAID, to powinny to by\u0107 serwerowe, musz\u0105 by\u0107 w nim kondensatory.<\/strong> Tutaj znajduje si\u0119 szczeg\u00f3\u0142owa lista kontrolna. Pod tym linkiem jest m\u00f3j raport na temat konfigurowania wydajno\u015bci dysk\u00f3w w PostgreSQL. Tam znajduj\u0105 si\u0119 wszystkie te listy kontrolne. <\/p>\n<\/p>\n
<\/p>\n
Co jeszcze mo\u017ce bardzo utrudni\u0107 \u017cycie? To dwa parametry. S\u0105 stosunkowo nowe. Domy\u015blnie mog\u0105 by\u0107 w\u0142\u0105czone w r\u00f3\u017cnych aplikacjach. Mog\u0105 znacznie skomplikowa\u0107 \u017cycie, je\u015bli zostan\u0105 w\u0142\u0105czone niew\u0142a\u015bciwie. <\/p>\n
<\/p>\n
<\/p>\n
S\u0105 dwie stosunkowo nowe rzeczy. Pojawi\u0142y si\u0119 ju\u017c w trzecich rdzeniach. To sched_migration_cost w nanosekundach oraz sched_autogroup_enabled, kt\u00f3ry domy\u015blnie jest aktywowany. <\/p>\n
<\/p>\n
Jak one psuj\u0105 \u017cycie? Co to jest sched_migration_cost? Harmonogram w Linuksie mo\u017ce przenie\u015b\u0107 proces z jednego CPU na inny. Dla PostgreSQL, kt\u00f3ry wykonuje zapytania, migracja na inny CPU jest zupe\u0142nie niezrozumia\u0142a. Z punktu widzenia systemu operacyjnego, kiedy prze\u0142\u0105czasz okna mi\u0119dzy openoffice a terminalem, mo\u017ce to by\u0107 dobre, ale dla bazy danych \u2013 to bardzo \u017ale.<\/strong> Dlatego rozs\u0105dna polityka to ustawienie migration_cost na jak\u0105\u015b du\u017c\u0105 warto\u015b\u0107, przynajmniej kilka tysi\u0119cy nanosekund.<\/strong> <\/p>\n<\/p>\n
Co to b\u0119dzie oznacza\u0107 dla scheduler? B\u0119dzie uwa\u017ca\u0107, \u017ce przez ten czas ten proces wci\u0105\u017c jest gor\u0105cy. Tzn. je\u015bli masz jak\u0105\u015b d\u0142ug\u0105 transakcj\u0119, kt\u00f3ra czym\u015b d\u0142ugo si\u0119 zajmuje, scheduler to zrozumie. B\u0119dzie uwa\u017ca\u0107, \u017ce p\u00f3ki nie minie ten czas, migracja tego procesu nigdzie nie jest potrzebna. Je\u015bli proces co\u015b robi, to nie zostanie nigdzie przeniesiony, spokojnie doko\u0144czy na tym CPU, kt\u00f3re mu przydzielono. I rezultat jest znakomity. <\/p>\n
<\/p>\n
Drugi punkt \u2013 to autogroup. Jest to dobra idea dla specyficznych obci\u0105\u017ce\u0144 roboczych, kt\u00f3re nie maj\u0105 zwi\u0105zku z nowoczesnymi bazami danych \u2013 grupowanie proces\u00f3w wed\u0142ug tego wirtualnego terminala, z kt\u00f3rego zosta\u0142y uruchomione. To wygodne dla niekt\u00f3rych zada\u0144. W praktyce PostgreSQL to system wieloprocesowy z preforkiem, uruchamiany z jednego terminala. Macie blokad\u0119 pisania, punkt kontrolny i wszystkie Wasze zapytania klienckie zostan\u0105 zgrupowane w jednym harmonogramie, na jednym CPU. B\u0119d\u0105 tam czeka\u0107, a\u017c si\u0119 zwolni, aby przeszkodzi\u0107 sobie i zajmowa\u0107 go d\u0142u\u017cej. To historia, kt\u00f3ra jest ca\u0142kowicie niepotrzebna w przypadku takiego obci\u0105\u017cenia, dlatego nale\u017cy to wy\u0142\u0105czy\u0107.<\/strong><\/p>\n<\/p>\n
<\/p>\n
M\u00f3j kolega Aleksiej Lesowski przeprowadza\u0142 testy z prostym pgbench'em, gdzie zwi\u0119ksza\u0142 kilkukrotnie migration_cost i wy\u0142\u0105cza\u0142 autogroup. R\u00f3\u017cnica na s\u0142abym sprz\u0119cie wynios\u0142a prawie 10%.<\/strong>. Jest dyskusja na li\u015bcie dyskusyjnej postgres, gdzie ludzie przedstawiaj\u0105 wyniki, jak podobne zmiany wp\u0142yn\u0119\u0142y na pr\u0119dko\u015b\u0107 zapytania. wp\u0142yn\u0119\u0142y na 50%.<\/strong>. Takich historii jest ca\u0142kiem sporo.<\/p>\n<\/p>\n
<\/p>\n
I na koniec o polityce oszcz\u0119dzania energii. Dobrze, \u017ce teraz Linux mo\u017cna u\u017cywa\u0107 na laptopie. I teoretycznie b\u0119dzie dobrze gospodarowa\u0107 bateri\u0105. Ale niespodziewanie okazuje si\u0119, \u017ce na serwerze te\u017c mo\u017ce by\u0107 tak samo. <\/p>\n
<\/p>\n
Co wi\u0119cej, je\u015bli wynajmujecie serwery od jakiego\u015b hostera, to '\u017cyczliwi' hosterzy<\/a> nie dbaj\u0105 o to, \u017ceby\u015bcie mieli lepsz\u0105 wydajno\u015b\u0107. Ich celem jest maksymalna efektywno\u015b\u0107 utylizacji sprz\u0119tu. Dlatego domy\u015blnie mog\u0105 w systemie operacyjnym w\u0142\u0105czy\u0107 tryb oszcz\u0119dzania energii dla laptop\u00f3w.<\/p>\n<\/p>\n
Je\u015bli u\u017cywacie na serwerze z baz\u0105 danych pod intensywnym obci\u0105\u017ceniem tego rodzaju dobroci, to Waszym wyborem jest acpi_cpufreq + performance. Ju\u017c z ondemand b\u0119d\u0105 problemy.<\/strong> <\/p>\n<\/p>\n
Intel_pstate to ju\u017c nieco inny sterownik. I obecnie preferowane jest to rozwi\u0105zanie, jako nowsze i lepiej dzia\u0142aj\u0105ce.<\/p>\n
<\/p>\n
I w zwi\u0105zku z tym, governor tylko performance. Ondemand, powersave i wszystko inne \u2013 to nie dla Was. <\/p>\n
<\/p>\n
Wyniki z explain analyze w PostgreSQL mog\u0105 si\u0119 r\u00f3\u017cni\u0107 o kilka rz\u0119d\u00f3w wielko\u015bci, je\u015bli w\u0142\u0105czycie powersave, poniewa\u017c w zasadzie CPU pod baz\u0105 b\u0119dzie planowane w zupe\u0142nie nieprzewidywalny spos\u00f3b.<\/p>\n
<\/p>\n
Te rzeczy mog\u0105 by\u0107 w\u0142\u0105czone domy\u015blnie. Uwa\u017cnie sprawd\u017acie \u2013 czy nie w\u0142\u0105czyli ich domy\u015blnie. To mo\u017ce by\u0107 naprawd\u0119 du\u017cym problemem. <\/p>\n
<\/p>\n
<\/p>\n
Na koniec chcia\u0142em podzi\u0119kowa\u0107 ekipie naszego zespo\u0142u DBA PosgreSQL-Consulting, a konkretnie Maksowi Boguku i Aleksiejowi Lesowskiemu, kt\u00f3rzy ka\u017cdego dnia ucz\u0105 si\u0119 na b\u0142\u0119dach. Staramy si\u0119, aby dla naszych klient\u00f3w wszystko dzia\u0142a\u0142o jak najlepiej. To jak z instrukcjami bezpiecze\u0144stwa lotniczego. Wszystko jest zapisane krwi\u0105. Ka\u017cda z tych nakr\u0119tek zosta\u0142a odkryta w trakcie rozwi\u0105zywania jakiego\u015b problemu. Z rado\u015bci\u0105 dziel\u0119 si\u0119 nimi z wami.<\/p>\n
<\/p>\n
Pytania:<\/p>\n
<\/p>\n
Dzi\u0119kuj\u0119! Je\u015bli na przyk\u0142ad firma chce zaoszcz\u0119dzi\u0107 i umie\u015bci\u0107 baz\u0119 danych oraz logik\u0119 aplikacji na jednym serwerze, lub je\u015bli firma pod\u0105\u017ca za modn\u0105 tendencj\u0105 architektur mikroserwisowych, w kt\u00f3rych PostgreSQL dzia\u0142a w kontenerze. Jaka jest kwintesencja? Sysctl globalnie wp\u0142ywa na ca\u0142e j\u0105dro. Nie s\u0142ysza\u0142em, aby sysctl jako\u015b si\u0119 wirtualizowa\u0142, aby dzia\u0142a\u0142 oddzielnie na kontenerze. Jest tylko cgroup, gdzie kontrola jest tylko cz\u0119\u015bciowa. Jak mo\u017cna z tym \u017cy\u0107? A je\u015bli chcesz wydajno\u015bci, to uruchom PostgreSQL na oddzielnym serwerze fizycznym i optymalizuj go?<\/em><\/p>\n<\/p>\n
Odpowiedzieli\u015bmy na twoje pytanie na oko\u0142o trzy sposoby. Je\u015bli chodzi o serwer fizyczny, kt\u00f3ry mo\u017cna optymalizowa\u0107, to zrelaksuj si\u0119, wszystko b\u0119dzie dzia\u0142a\u0107 dobrze bez tych ustawie\u0144. Je\u015bli obci\u0105\u017cenie jest na tyle du\u017ce, \u017ce potrzebujesz tych ustawie\u0144, to pr\u0119dzej czy p\u00f3\u017aniej i tak uzyskasz dost\u0119p do serwera fizycznego.<\/p>\n
<\/p>\n
Jaki jest problem? Je\u015bli to wirtualna maszyna, prawdopodobnie napotkasz wiele problem\u00f3w, na przyk\u0142ad z tym, \u017ce na wi\u0119kszo\u015bci wirtualek latencja dysku jest wystarczaj\u0105co niekonsekwentna. Nawet je\u015bli przepustowo\u015b\u0107 dysk\u00f3w jest dobra, jedna nieudana transakcja operacji wej\u015bcia\/wyj\u015bcia, kt\u00f3ra niezbyt wp\u0142ywa na \u015bredni\u0105 przepustowo\u015b\u0107, wyst\u0119puj\u0105ca w momencie checkpointa lub zapisu w WAL, spowoduje, \u017ce baza danych b\u0119dzie znacznie cierpie\u0107. Zauwa\u017cysz to wcze\u015bniej, ni\u017c napotykasz te problemy. <\/p>\n
<\/p>\n
Je\u015bli na tym samym serwerze b\u0119dzie NGINX, wyst\u0105pi ten sam problem. B\u0119dzie walczy\u0142 o wsp\u00f3\u0142dzielon\u0105 pami\u0119\u0107. I nie dojdziesz do problem\u00f3w opisanych tutaj.<\/p>\n
<\/p>\n
Z drugiej strony jednak niekt\u00f3re z tych parametr\u00f3w b\u0119d\u0105 dla Ciebie istotne. Na przyk\u0142ad, w sysctl ustaw dirty_ratio, aby nie by\u0142o to zbyt ekstremalne \u2013 w ka\u017cdym razie to pomo\u017ce. Tak czy inaczej, b\u0119dziesz mia\u0142 interakcj\u0119 z dyskiem. B\u0119dzie ona jednak przebiega\u0107 wed\u0142ug niew\u0142a\u015bciwego schematu. To w zasadzie domy\u015blne te parametry, kt\u00f3re pokazywa\u0142em. W ka\u017cdym razie lepiej je zmieni\u0107. <\/p>\n
<\/p>\n
Z NUMA mog\u0105 by\u0107 problemy. VmWare, na przyk\u0142ad, dobrze dzia\u0142a z NUMA z dok\u0142adnie przeciwnymi ustawieniami. I tutaj musisz wybiera\u0107 \u2013 serwer fizyczny czy nie fizyczny. <\/p>\n
<\/p>\n
Mam pytanie zwi\u0105zane z Amazon AWS. Maj\u0105 zdj\u0119cia wst\u0119pnie skonfigurowane. Jeden z nich nazywa si\u0119 Amazon RDS. Czy s\u0105 tam jakie\u015b niestandardowe ustawienia dla ich systemu operacyjnego?<\/em><\/p>\n<\/p>\n
S\u0105 tam ustawienia, ale to s\u0105 inne ustawienia. Tutaj konfigurujemy system operacyjny z punktu widzenia tego, jak baza danych b\u0119dzie tego u\u017cywa\u0107. A tam s\u0105 parametry, kt\u00f3re okre\u015blaj\u0105, gdzie teraz powinni\u015bmy i\u015b\u0107, taki shaping. To znaczy potrzebujemy tylu zasob\u00f3w, kt\u00f3re teraz b\u0119dziemy konsumowa\u0107. Po tym Amazon RDS te zasoby uruchamia i tam wydajno\u015b\u0107 spada. S\u0105 osobne historie, jak ludzie zaczynaj\u0105 si\u0119 tym zajmowa\u0107. Czasami nawet z do\u015b\u0107 du\u017cym sukcesem. Ale to nie ma zwi\u0105zku z ustawieniami OS. To jak hackowanie chmury. To inna historia.<\/p>\n
<\/p>\n
Dlaczego Transparent huge pages nie daj\u0105 efektu w por\u00f3wnaniu z Huge TLB?<\/em><\/p>\n<\/p>\n
Nie daj\u0105. Mo\u017cna to wyja\u015bni\u0107 na wiele sposob\u00f3w. Ale w rzeczywisto\u015bci po prostu go nie daj\u0105. Jaka jest historia PostgreSQL? Przy starcie przydziela du\u017cy kawa\u0142ek pami\u0119ci wsp\u00f3\u0142dzielonej. To, czy s\u0105 transparentne, czy nie transparentne \u2013 nie ma to wcale znaczenia. Fakt, \u017ce s\u0105 przydzielane na starcie, wyja\u015bnia wszystko. I je\u015bli pami\u0119ci jest bardzo du\u017co i trzeba przebudowa\u0107 segment shared_memory, wtedy Transparent huge pages b\u0119d\u0105 istotne. W PostgreSQL po prostu przy starcie s\u0105 przydzielane ogromnym kawa\u0142kiem i to wszystko, a dalej nic szczeg\u00f3lnego si\u0119 nie dzieje. Oczywi\u015bcie mo\u017cna u\u017cywa\u0107, ale istnieje ryzyko uzyskania uszkodzonej pami\u0119ci wsp\u00f3\u0142dzielonej, gdy b\u0119dzie ponownie przydziela\u0107 cokolwiek. PostgreSQL o tym nie wie.<\/p>\n
\u0179r\u00f3d\u0142o: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Tuning](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n