Настройки на Linux за подобряване на производителността на PostgreSQL. Иля Космодемянски

Разшифровка доклад от 2015 г. на Илия Космодемьянски "Linux настройка за подобряване на производителността на PostgreSQL"

Отказ: Забелязвам, че този доклад е от ноември 2015 г. — изминали са повече от 4 години и времето е минало. Версията 9.4, разглеждана в доклада, вече не се поддържа. През последните 4 години излязоха 5 нови издания на PostgreSQL и 15 версии на ядрото на Linux. Ако се пренаписват тези места, в крайна сметка ще се получи друг доклад. Но тук се разглежда основната настройка на Linux за PostgreSQL, която е актуална и сега.

Казвам се Илия Космодемьянски. Работя в компанията PostgreSQL-Consulting. И сега ще говоря малко за това, какво да правим с Linux за бази данни изобщо и с PostgreSQL по-специално, защото принципите са доста сходни.

Какво ще се обсъжда? Ако комуникирате с PostgreSQL, до известна степен трябва да бъдете администратор на UNIX. Какво означава това? Ако сравним Oracle и PostgreSQL, то в Oracle трябва да бъдете на 80% администратор на базата данни и на 20% администратор на Linux.

С PostgreSQL е малко по-сложно. С PostgreSQL трябва много по-добре да разбирате как работи Linux. И в същото време трябва да следите с бързина, защото напоследък всичко се обновява доста активно. Излизат нови ядра, нова функционалност, производителността се подобрява и т.н.

Защо говорим за Linux? Не защото сме на конференция Linux Питър, а защото в съвременни условия една от най-разумните операционни системи за експлоатация с бази данни изобщо и с PostgreSQL по-специално е Linux. Защото FreeBSD, за съжаление, се развива в странна посока. И ще има проблеми както с производителността, така и с много други неща. Производителността на PostgreSQL на Windows е изцяло отделна сурова тема, която се сблъсква с факта, че Windows няма споделена памет като UNIX, а при PostgreSQL всичко зависи от това, защото е многопроцесна система.

И екзотиката като Solaris, мисля, в по-малка степен интересува всички, така че да продължим.

Съвременната дистрибуция на Linux разполага с над 1 000 параметра syctl, в зависимост от това как е сглобено ядрото. В същото време, ако погледнем и различни гайки, там може да се настройва по много начини. Има параметри на файловите системи, как да се монтират. Ако имате въпроси, как да стартирате: какво да включите в BIOS, как да настроите хардуера и т.н.

Това е много голямо количество информация, за което може да се говори с дни, а не в един кратък доклад, но сега ще се спра на важните неща, как да избегнем капаните, които със сигурност няма да ви позволят да експлоатирате базата данни на Linux добре, ако не ги коригирате. И важното тук е, че много от параметрите по подразбиране не са настроени правилно за базата данни. Т.е. по подразбиране ще работи зле или изобщо няма да работи.

Какви традиционни tuning targets има в Linux? Мисля, че тъй като всички вие имате работа с администриране на Linux, не трябва особено да обяснявам какво означава targets.

Може да се тюнира:

• CPU.
• Памет.
• Съхранение.
• Други. За това ще поговорим в края, като малко закуска. Дори, например, такива параметри, като политиката на пестене на енергия, могат да повлияят на производителността по много непредсказуем и неприятен начин.

Каква е спецификата на PostgreSQL и на базата данни изобщо? Проблемът е, че не може да се настрои някакъв отделен елемент и да се види, че производителността се е подобрила значително.

Да, такива елементи съществуват, но базата данни е сложна система. Тя взаимодейства с всички ресурси на сървъра и предпочита да взаимодействува напълно. Ако погледнете съвременните препоръки на Oracle за това как да използвате хостовата ОС, ще видите нещо подобно на шегата за монголския космонавт – нахранете кучето и не пипайте нищо. Осигурете на базата всички ресурси и тя сама ще се справи.

В принципе, до известна степен при PostgreSQL ситуацията е същата. Разликата е, че базата не може сама да взема всички ресурси, т.е. трябва да се управлява всичко на ниво Linux.

Основната идея е да не изберете някакъв единствен target и да започнете да го тюните, например, памет, CPU или нещо от този род, а да анализирате работната натовареност и да се опитате да подобрите максимално пропускателната способност, така че през нашата база данни максимално ефективно да преминава натоварването, което добрите програмисти са създали, включително и нашите потребители.

Ето такава картинка за обяснение на това какво е. Има буфер на ОС Linux, има споделена памет и има споделени буфери на PostgreSQL. PostgreSQL, за разлика от Oracle, работи директно само чрез ядрения буфер, т.е. за да попадне страница от диска в неговата споделена памет, тя трябва да мине през ядрения буфер и обратно — точно такава е ситуацията.

Под тази система живеят дисковете. Нарисувал съм го като дискове. В действителност там може да има RAID контролер и т.н.

И ето, че този вход-изход по един или друг начин се случва чрез това.

PostgreSQL е класическа база данни. Вътре има страници. И целият вход-изход се извършва с помощта на страниците. Ние повдигаме блокове в паметта с помощта на страниците. И ако нищо не се е случило, просто сме ги прочели, то постепенно те от този кеш, от споделените буфери, потъват обратно на диска.

Ако някъде сме заменили нещо, то цялата страница се маркира като мръсна. Тук съм го отбелязал в син цвят. И това означава, че тази страница трябва да бъде синхронизирана с блочното хранилище. Т.е. когато я направим мръсна, записваме в WAL. И в някой прекрасен момент идва явлението, наречено checkpoint. И в този лог записва информация за това, че е дошъл. И това означава, че всички мръсни страници, които са били тук в този момент в тези споделени буфери, са синхронизирани с дисковото хранилище чрез fsync през ядрения буфер.

Защо се прави това? Ако ни прекъсне напрежението, ние няма да получим ситуация, в която всички данни изчезват. Персистентната памет, за която всички ни разказваха, е все още в теорията на базите данни — светло бъдеще, към което разбира се се стремим и което ни харесва, но все още живее в минус 20 години. И разбира се, необходимо е да се следи всичко това.

Задачата за максимизиране на пропускната способност е да се оптимизира на всички тези етапи, за да може всичко да работи бързо. Споделената памет — това е основно кеш на страници. В PostgreSQL, когато изпратим запитване select нещо там, то извлича тези данни от диска. Те поползват в споделените буфери. Следователно, за да работи по-добре, трябва да има много памет.

За да работи всичко добре и бързо, трябва да настроите операционната система правилно на всички етапи. И да изберете балансирано хардуерно решение, тъй като ако в някоя част има дисбаланс, можете да имате много памет, но тя ще се обслужва с недостатъчна скорост.

Нека разгледаме всеки от тези пункта.

За да се движат тези страници по-бързо, трябва да постигнем следното:

• На първо място, трябва да работим по-ефективно с паметта.
• На второ място, преходът между паметта и диска трябва да бъде по-ефективен.
• На трето място, необходимите дискове трябва да са качествени.

Ако имате 512 GB оперативна памет в сървър и всичко това в крайна сметка стига до SATA твърд диск без никакъв кеш, то целият сървър за база данни се превръща не просто в тиква, а в тиква с SATA интерфейс. Ще се сблъскате с това директно. И нищо няма да ви спаси.

Що се отнася до първата точка с паметта, има три неща, които могат да усложнят живота значително.

Първото от тях е NUMA. NUMA е механизъм, създаден за подобряване на производителността. В зависимост от натоварването могат да се оптимизират различни неща. И в новия си актуален вид тя не е много подходяща за приложения, като например база данни, които интензивно използват shared buffer и page cache.

С две думи. Как да разберем, че нещо не е наред с NUMA? Имате неприятно шумолене, внезапно някой CPU е претоварен. При това анализирате заявките в PostgreSQL и виждате, че там няма нищо подобно. Тези заявки не трябва да консумират CPU толкова интензивно. Може да отнеме време да уловите това. По-добре е още от самото начало да следвате правилните препоръки за настройка на NUMA за PostgreSQL.

Какво всъщност се случва? NUMA е Non-Uniform Memory Access. Какъв е смисълът? Имате CPU, до него е локалната му памет. И тази памет interconnects може да тегли памет и от други CPU.

Ако стартирате numactl --hardware, ще получите дълъг списък. Сред другото там ще има поле distances. Ще видите числа – 10-20, нещо от сорта. Тези числа не са нищо друго освен броят на хоповете, необходими за достъп до тази отдалечена памет и използването ѝ локално. Принципно, това е добра идея. Това значително ускорява производителността при редица натоварвания.

Сега си представете, че имате един CPU, който първо се опитва да използва своята локална памет, а след това се опитва да извлече допълнителна памет през interconnect за нещо. И целият ваш page cache на PostgreSQL попада на този CPU – всичките там, колкото и гигабайти да са. Винаги получавате най-лошия случай, защото на CPU-то директно в този модул памет обикновено има малко. И цялата памет, която се обслужва, преминава през тези interconnects. Става бавно и мизерно. И имате процесор, който обслужва този възел, постоянно претоварен. И времето за достъп до тази памет е лошо и бавно. Това е ситуацията, която не искате, ако използвате това за база данни.

Затова по-правилният вариант за база данни е, че операционната система Linux изобщо не знае какво се случва. За да може тя да се обръща към паметта, както обикновено.

Защо е така? Би трябвало да е обратното. Това се случва по една проста причина: необходима ни е много памет за page cache – десетки, стотици гигабайти.

И ако всичко това сме отделили и кеширали данните си там, то печалбата от използването на кеша ще бъде значително по-голяма, отколкото печалбата от такова хитро обръщение към паметта. И по този начин ще спечелим несравнимо повече в сравнение с това, че ще се обръщаме по-ефективно към паметта с използване на NUMA.

Затова в момента има два подхода, докато светлото бъдеще не настъпи, и базата данни не знае сама на кои CPU работи и от къде трябва да извлече нещо.

Лекото решение е изцяло да отключите NUMA, например, при рестартиране. В повечето случаи печалбите са толкова значителни, че въпросът какво е най-добре не стои.

Има и друг вариант. Ние го използваме по-често от първия, защото, когато клиент дойде при нас за поддръжка, рестартирането на сървъра е голяма работа. Там бизнесът му тече. А проблемите заради NUMA те ги изпитват. Затова се опитваме да отключим по-щадящи начини, отколкото рестарт, но тук внимавайте да проверите дали действително е отключена. Защото, както показва опитът, отключването на NUMA за родителския процес на PostgreSQL е добро, но съвсем не е задължително, че това ще сработи. Трябва да проверите и да видите, че наистина е отключена.

Има добър пост от Робърт Хаас. Той е един от комитерите на PostgreSQL. Един от ключовите разработчици на всичките ниско ниво компоненти. И ако последвате връзките в този пост, там са описани няколко колоритни истории за това как NUMA е затруднявала живота на хората. Погледнете, изучете системния чеклист, какво трябва да се настрои на сървъра, за да работи базата данни добре. Тези настройки е нужно да бъдат записани и проверени, защото иначе може да се получи проблем.

Обърнете внимание, че това касае всички настройки, за които ще говоря. Но обикновено базите данни се изграждат в режим master-slave за отказоустойчивост. Не забравяйте да внесете тези настройки на slave, защото в един момент може да имате авария и да преминете на slave, а той ще стане master.

В аварийна ситуация, когато всичко е много лошо, телефонът ви ще звъни постоянно и началникът ще се появи с голяма пръчка; няма да имате време да проверите. И резултатите могат да бъдат много плачевни.

Следващият момент - това са huge pages. Huge pages е трудно да се тества самостоятелно, а и няма смисъл в това, въпреки че има бенчмаркове, които могат да го правят. Лесно се намират в интернет.

Какъв е смисълът? Имам не много скъп сървър с много оперативна памет, например, над 30 GB. Не използвате huge pages. Това означава, че определено имате излишък в използването на паметта. И този излишък далеч не е приятен.

Защо така? И какво се случва? Операционната система разпределя паметта на малки части. Така е удобно, така исторически се е сложило. И ако задълбочим темата, ОС трябва да преведе виртуалните адреси в физически. И този процес не е лесен, затова ОС кешира резултата от тази операция в Translation Lookaside Buffer (TLB).

И тъй като TLB е кеш, в такава ситуация възникват всички присъщи на кеша проблеми. Първо, ако имате много оперативна памет и тя е разпределена на малки части, тогава този буфер става много голям. А ако кешът е голям, търсенето става по-бавно. Излишъкът е значителен и сам по себе си заема място, т.е. оперативната памет консумира нещо неправилно. Това е първото.

Две – колкото по-голямо е кеша в такава ситуация, толкова по-голяма е вероятността да имате cache misses. И ефективността на този кеш бързо намалява с увеличаването на размера му. Затова в операционните системи е измислен прост подход. В Linux той отдавна се използва. В FreeBSD наскоро се появи. Но ние говорим за Linux. Това са huge pages.

Тук трябва да се отбележи, че huge pages, като идея, първоначално беше прокарана от общности, включващи Oracle и IBM, т.е. производителите на бази данни сериозно обмисляха, че това ще бъде полезно и за бази данни.

Как можем да го свържем с PostgreSQL? На първо място, в ядрото на Linux трябва да бъдат включени huge pages.

На второ място, те трябва да бъдат изрично зададени с параметъра sysctl – колко от тях. Числата тук са от някой стар сървър. Можете да изчислите колко споделени буфери имате, за да се вместят huge pages.

И ако целият сървър е отдаден на PostgreSQL, то добра отправна точка е да заделите 25% от оперативната памет за споделени буфери, или 75%, ако сте сигурни, че базата данни ви ще се вмести в тези 75%. Първата отправна точка. И сметнете, ако имате 256 GB оперативна памет, то съответно 64 GB ще бъдат споделени буфери. Изчислете приблизително с малък резерв – на каква стойност трябва да бъде зададена тази цифра.

До версия 9.2 (ако не се лъжа, от версия 8.2) беше възможно да свържете PostgreSQL с huge pages с помощта на външна библиотека. А това винаги е необходимо. На първо място, трябва да уверите, че ядрото може да разпределя huge pages правилно. А на второ място, приложението, което работи с тях, трябва да може да ги използва. Просто така то няма да ги използва. Тъй като PostgreSQL разпределя памет в стил system 5, това може да бъде направено с помощта на libhugetlbfs — това е пълното наименование на библиотеката.

В версия 9.3 беше подобрена производителността на PostgreSQL при работа с паметта и беше отхвърлен метода на системата 5 за разпределение на паметта. Всички много се зарадваха, защото в противен случай, когато опитвате да стартирате два инстанса на PostgreSQL на една машина, той казва, че му липсва споделена памет. И казва, че трябва да коригирате sysctl. А там sysctl е такъв, че трябва и да се рестартира и т.н. Общо взето, всички се зарадваха. Обаче, разпределението на паметта mmap счупи използването на huge pages. Повечето от нашите клиенти използват големи споделени буфери. И настоятелно препоръчахме да не преминавате на 9.3, защото там overhead започва да се изчислява в впечатляващи проценти.

Но пък общността обърна внимание на този проблем и в 9.4 много добре переработиха тази функция. В 9.4 се появи параметър в postgresql.conf, с който може да включите try, on или off.

Try – това е най-безопасният параметър. При стартиране на PostgreSQL, когато той разпределя споделена памет, той се опитва да получи част от huge pages. И ако не успее, се връща на стандартното разпределение. И ако имате FreeBSD или Solaris, можете да зададете try, това винаги е безопасно.

Ако е on, той просто не стартира, ако не може да разпредели от huge pages. Тук вече е за предпочитание на всеки. Но ако имате try, проверявайте дали наистина е разпределено това, което трябва, защото там има много пространства за грешки. В момента тази функционалност работи само на Linux.

Още едно малко забележка, преди да продължим напред. Transparent huge pages – това все още не е за PostgreSQL. Той не може да ги използва нормално. И при Transparent huge pages за такова натоварване, когато е необходим голям обем споделена памет, предимствата се наблюдават само при много големи обеми. Ако разполагате с терабайти памет, тогава това може да има значение. Ако говорим за по-битови приложения, когато имате 32, 64, 128, 256 GB памет на машината, обичайната huge pages е ОК, а Transparent просто я изключваме.

И последната вещ, свързана с паметта, пряко не е свързана с капацитета, но може да развали живота много. Цялата производителност ще пострада от това, че сървърът постоянно сменя контекста.

И това ще бъде много неприятно в редица моменти. Основната неприятност е, че в съвременните ядра поведенито малко се различава от по-старите Linux ядра. И това е нещо, на което е доста неприятно да стъпиш, защото когато говорим за работа със swap, това води до ненавременна намеса на OOM-killer. А OOM-killer, който не се е появил навреме и е убил PostgreSQL, е наистина неприятно. Всички ще разберат за това, т.е. до последния потребител.

Какво се случва? Имате голямо количество оперативна памет и всичко работи нормално. Но по някаква причина сървърът зацикля в swap и забавя производителността. Изглежда, че паметта е много, но нещата се получават по този начин.

По-рано съветвахме да зададете vm.swappiness на нула, т.е. да деактивирате swap. По-рано изглеждаше, че 32 GB оперативна памет и съответните споделени буфери са огромно количество. Основната цел на swap е да осигури място, където да поставим нещо, ако сме се сринали. И той вече не изпълняваше тази функция. И какво ще направите с това нещо след това? Това вече е задача, при която не е лесно да разберем защо swap е необходим, особено в такъв обем.

Но в по-съвременните, т.е. в третите версии на ядрото, поведението се промени. И ако зададете swap на нула, т.е. го изключите, рано или късно дори при остатък от оперативната памет, OOM-killer ще се появи, за да убие най-интензивните потребители. Защото той ще счита, че при такъв товар ни остава съвсем малко и че ще излязнат, т.е. не системният процес ще бъде убит, а нещо по-малко важно. Това по-малко важно ще бъде интензивният потребител на споделена памет, а именно postmaster. И след това ще е добре, ако базата не трябва да бъде възстановявана.

Затова сега по подразбиране, колкото си спомням, повечето дистрибуции задават стойност около 6, т.е. в кой момент да започне използването на swap в зависимост от остатъчната памет. В момента съветваме да зададете vm.swappiness на 1, защото практически го изключва, но не предизвиква такива ефекти като неочаквано появил се OOM-killer, който унищожава всичко.

Какво следва? Когато говорим за производителността на базите данни и постепенно се насочваме към дисковете, всички започват да се хванат за главата. Истината е, че дискът е бавен, а паметта бърза, е нещо, което всеки знае от детството си. И всички знаят, че в базата данни могат да възникнат проблеми с дисковата производителност.

Основният проблем с производителността на PostgreSQL, свързан с пиковете на checkpoints, не произтича от това, че дискът е бавен. По-скоро става дума за това, че пропускателната способност на паметта и диска не е балансирана. Те могат да бъдат не балансирани на различни места. PostgreSQL не е конфигуриран, операционната система не е настроена, хардуерът не е настроен и той е неправилен. И този проблем не настъпва, само когато всичко работи как трябва, т.е. или няма натоварване, или настройките и хардуерът са добре подбрани.

Какво представлява това и как изглежда? Обикновено хората, които работят с PostgreSQL, вече са се сблъсквали с това. Ще обясня. Както казах, PostgreSQL периодично извършва checkpoints, за да запише замърсените страници в общата памет на диска. Ако имаме голям обем обща памет, checkpoint започва интензивно да влияе на диска, тъй като записва тези страници с fsync. Те попадат в kernel buffer и се записват на дисковете с помощта на fsync. И ако обемът на това е голям, можем да наблюдаваме неприятен ефект, а именно много висока заетост на дисковете.

Тук имам две снимки. Сега ще обясня какво представляват те. Това са два корелирани по време графика. Първият график – това е дисковата заетост. Тук тя достига почти 90 % в този момент. Ако имате база данни с физически дискове и с RAID контролер, когато заетостта е близо до 90 %, това са лоши новини. Това означава, че още малко и ще достигне 100, а входно-изходната операция ще спре.

Ако имате дисков масив, там историята е малко различна. Зависи от това как е настроен, какъв е масивът и т.н.

И тук е конфигуриран график от вътрешния postgres вид, който показва как протича checkpoint. В зелено е показано колко буфера, т. е. замърсени страници, в момента са дошли в този checkpoint за синхронизация. И това е основното, което трябва да знаете. Виждаме, че тук имаме много страници и в даден момент стигнахме до плато, т. е. писахме-писахме, тук явно дисковата система е много натоварена. И нашият checkpoint оказва значително влияние върху диска. В идеалния случай ситуацията трябва да изглежда по-скоро така, т. е. тук имаше по-малко записи. И с правилните настройки можем да поправим това, за да продължи така. Т. е. утилизацията е малка, но все пак нещо пишем тук.

Какво трябва да се направи, за да победим този проблем? Ако вашето IO под базата данни е спряло, това означава, че всички потребители, които са изпращали своите заявки, ще чакат.

Ако погледнем от гледна точка на Linux, ако сте взели добро оборудване, правилно сте го конфигурирали и нормално сте настроили PostgreSQL да прави по-рядко тези checkpoints, разпределяйки ги във времето, то влизате в стандартните параметри на Debian. За повечето дистрибуции на Linux картината е следната: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Какво означава това? С ядрото 2.6 се появи един демон за изчистване. Pdglush, в зависимост от това кой какво използва, служи за фоново изхвърляне на замърсени страници от kernel buffer и изтегляне, когато е необходимо да се изтеглят замърсени страници, когато фоновото изчистване не помага.

Кога настъпва фоновото изчистване? Когато 10% от цялата оперативна памет на сървера е заета от замърсени страници в kernel buffer, се извиква специална функция за изчистване в фон. Защо е фонова? Тя приема параметър за това колко страници да бъдат изчистени. И, например, изчиства N страници. И за известно време този процес заспива. След това отново се връща и изчиства още известно количество страници.

Това е изключително проста история. Тук задачата е като с басейн, когато в една тръба се излива, а в друга се влива. При нас е дошъл checkpoint и ако той е изпратил малко замърсени страници за изхвърляне, постепенно от kernel buffer pgflush това всичко ще се разсее внимателно.

Ако тези мръсни страници продължат да се натрупват, те ще достигнат до 20%, след което операционната система ще приоритизира записването им на диска, тъй като ако захранването спре, ще имаме сериозен проблем. Ще загубим тези данни, например.

В какво е трикът? Трикът е, че тези параметри от 20 и 10% от цялата оперативна памет на машината са напълно абсурдни от гледна точка на пропускната способност на всяка дискова система, която имате.

Представете си, че имате 128 GB оперативна памет. 12.8 GB достигат до вашата дискова система. Какъвто и кеш да имате там, какъвто и масив да имате, те няма да издържат на толкова.

Затова препоръчваме да настроите тези цифри веднага в зависимост от възможностите на вашия RAID контролер. Тук имам веднага препоръка за контролер с 512 MB кеш.

Всичко се изчислява много просто. Можете да зададете vm.dirty_background в байтове. Тези настройки отменят предишните две. Или по подразбиране ratio, или активираните с байтове, то ще работят именно те. Но тъй като съм DBA консултант и работя с различни клиенти, се старая да създавам резерви, затова ако е в байтове, да е в байтове. Никой не е дал никаква гаранция, че добър администратор няма да добави памет на сървъра или да го рестартира, а числото да остане същото. Просто изчислявайте тези стойности, за да се уверите, че всичко ще се побере.

Какво ще се случи, ако не се поберете? Написано е, че ефективно спира всяко flushing, но всъщност това е метафора. Операционната система има голям проблем – тя има много мръсни страници, затова спира ефективно IO, произвеждано от вашите клиенти, т.е. приложението иска да изпрати SQL запитване към базата данни и чака. Всеки вход-изход в нея е с най-нисък приоритет, тъй като базата е заета с checkpoint. И когато ще завърши, е абсолютно неясно. И когато достигнете не фоново, не бекграундно flushing, това означава, че всичкото ви IO е заето с него. И докато не завърши, няма да можете да направите нищо.

Има и още два важни момента, които излизат извън обхвата на този доклад. Тези настройки трябва да съвпадат с настройките в postgresql.conf, т.е. настройките на checkpoints. И вашата дискова система трябва да бъде адекватно настроена. Ако имате кеш на RAID, то той трябва да има батерия. Хората купуват RAID с добър кеш без батерия. Ако имате SSD в RAID, то те трябва да бъдат сървърни, там трябва да има кондензатори. Тук има подробен чеклист. Чрез този линк можете да намерите моя доклад за настройка на дискова производителност в PostgreSQL. Всички тези чеклисти са там.

Какво друго може да усложни живота? Това са два параметъра. Те са относително нови. По подразбиране може да бъдат включени в различни приложения. И те могат да усложнят живота не по-малко, ако бъдат неправилно включени.

Има две относително нови функции. Те вече се появиха в третите ядра. Това са sched_migration_cost в наносекунди и sched_autogroup_enabled, който по подразбиране е включен.

Как те развалят живота? Какво е sched_migration_cost? Linux scheduler може да мигрира процес от един CPU на друг. И за PostgreSQL, който изпълнява заявки, миграцията на друг CPU съвсем не е ясна причина. От гледна точка на операционната система, когато превключвате между openoffice и терминал, това може да е добре, но за базата данни – това е много лошо. Затова разумната политика е да се настрои migration_cost на някаква голяма стойност, поне няколко хиляди наносекунди.

Какво би означавало това за scheduler? Ще смята, че в течение на това време този процес все още е горещ. Тоест, ако имате някаква дълга транзакция, scheduler ще разбере това. Той ще смята, че докато не мине този тайм-аут, миграцията на този процес няма да е необходима. Ако в същото време процесът прави нещо, то той няма да бъде мигриран, а спокойно ще завърши на съответния CPU, който му е определен. Резултатът е отличен.

Вторият момент – това е autogroup. Съществува добра идея за специфични работни натоварвания, които нямат отношение към съвременните бази данни – да се групират процеси според виртуалния терминал, от който са стартирани. Това е удобно за някои задачи. На практика PostgreSQL е многонишкова система с prefork, която стартира от един терминал. Имате lock writer, checkpoint и всички клиентски заявки се групират на един scheduler, на един CPU. Те ще чакат дружно, докато се освободи, за да не се пречат една на друга и да заемат под longer. Тази ситуация е напълно ненужна при такава натовареност и затова трябва да бъде изключена.

Моят колега Алексей Лесовски направи тестове с прост pgbench, където увеличаваше migration_cost с порядък и изключваше autogroup. Разликата на слаб хардуер беше почти 10%.. Има дискусии в postgres-овия форум, където хора споделят резултати за това как подобни промени влияят на скоростта на заявките. влияеха на 50%.. Такива случаи са доста чести.

И накрая за политиката за пестене на енергия. Добре е, че сега Linux може да се използва на лаптопи. И той би трябвало да пести батерията. Но изведнъж се оказва, че на сървър това също може да се случи.

Освен това, ако наемате сървъри от някой хостинг доставчик, то "добри" хостърите не се грижат за по-добра производителност за вас. Тяхната задача е да осигурят максимална ефективност на хардуера. Затова по подразбиране може да активират режим за спестяване на енергия в операционната система.

Ако използвате на сървър с база данни под интензивно натоварване това добро, вашият избор е acpi_cpufreq + performance. Дори с ondemand вече ще имате проблеми.

Intel_pstate е вече съвсем различен драйвер. И сега предпочитанието е към него, защото е по-нов и по-добре работещ.

И, съответно, governor само performance. Ondemand, powersave и всичко останало – не е за вас.

Резултатите от explain analyze PostgreSQL могат да се различават с няколко порядъка, ако активирате powersave, защото практически с него CPU ще бъде планиран по напълно непредсказуем начин.

Тези неща могат да бъдат включени по подразбиране. Внимателно проверете – не са ли включени по подразбиране. Това може да бъде наистина голям проблем.

И накрая исках да благодаря на момчетата от нашия DBA екип PosgreSQL-Consulting, по-специално на Макс Богук и Алексей Лесовски, които всеки ден преминават през трудностите в работата си. Ние се стараем да направим всичко възможно, за да работи добре за нашите клиенти. Това е като с инструкциите за безопасност в авиацията. Всичко е написано с кръв. Всяка от тези гайки е открита в процеса на решаване на определени проблеми. С радост ги споделям с вас.

Въпроси:

Благодаря! Ако, например, компания иска да спести и да размести базата данни и приложната логика на един сървър или ако компанията следва модерната тенденция на микросервизните архитектури, в които PostgreSQL работи в контейнер. Каква е идеята? Sysctl влияе глобално на ядрото. Не съм чувал sysctl да се виртуализира, така че да работи отделно в контейнер. Има само cgroup и там контролът е само за част от ресурсите. Как можем да живеем с това? Или ако искате производителност, стартирайте PostgreSQL на отделен физически сървър и го оптимизирайте.

Отговорихме на въпроса ви по три начина. Ако не става въпрос за физически сървър, който може да се настрои и т.н., то отпуснете се, всичко ще работи добре и без тези настройки. Ако натоварването стане толкова голямо, че е необходимо да направите тези настройки, то ще стигнете до физическия сървър много по-рано, отколкото до тези настройки.

В какъв е проблемът? Ако това е виртуална машина, вероятно ще имате много проблеми, например с нестабилната латентност на дисковете в повечето виртуалки. Дори и да имате добра пропускна способност на дисковете, всяка провалена транзакция по време на операции с вход/изход, която не влияе много на средната пропускна способност, но се случи по време на checkpoint или при запис в WAL, ще нарани базата данни. И ще забележите това много преди да се сблъскате с проблемите.

Ако на същия сървър имате NGINX, то ще имате същия проблем. Той ще се състезава за споделена памет. И ще достигнете до описаните тук проблеми.

Но от друга страна, някои от тези параметри все още ще са актуални за вас. Например, с sysctl да зададете dirty_ratio, за да не е толкова безумно – в крайна сметка това ще помогне. Така или иначе, ще имате взаимодействие с диска. И то ще бъде по неправилна схема. Това всъщност е дефолтът на параметрите, които показвах. И в крайна сметка по-добре е да ги промените.

А с NUMA могат да се появят проблеми. VmWare, например, работи добре с NUMA при точно противоположни настройки. И тук трябва да изберете – метален сървър или не.

Имам въпрос, свързан с Amazon AWS. Те имат предварително конфигурирани образи. Един от тях се нарича Amazon RDS. Има ли там някакви персонализирани настройки за тяхната операционна система?

Има настройки, но това са различни настройки. Тук настройваме операционната система с оглед на това как базата данни ще използва това. А там има параметри, които определят накъде да тръгнем сега, нещо като shaping. Тоест, имаме нужда от толкова ресурси, които в момента ще използваме. След това Amazon RDS свързва тези ресурси, и там производителността спада. Има отделни истории, как хората започват да експериментират с това. Понякога дори доста успешно. Но това няма отношение към настройките на ОС. Това е нещо като хакване на облака. Това е друга история.

Защо Transparent huge pages не дават ефект в сравнение с Huge TLB?

Не дават. Може да се обясни по много начини. Но фактически просто не дават ефект. Каква е историята с PostgreSQL? Той при стартиране заделя голямо парче споделена памет. Transparent или не transparent – това абсолютно няма значение. Фактът, че те се заделят при старта, обяснява всичко. И ако паметта е много и трябва да се реконфигурира shared_memory сегмент, тогава Transparent huge pages ще бъде актуален. В PostgreSQL той просто е заделен в голямо парче при стартиране и това е всичко, и след това не се случва нищо особено. Може, разбира се, да се използва, но има шанс за корупция на shared_memory, когато той бъде повторно заделен. PostgreSQL не знае за това.

Източник: habr.com