Настройка на 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% DBA администратор на база данни и 20% Linux администратор.

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

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

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

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

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

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

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

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

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

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

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

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

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

Дисковете живеят под тази система. Нарисувах го като дискове. Всъщност може да има RAID контролер и т.н.

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

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

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

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

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

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

Нека да преминем през всяка от тези точки.

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

• Първо, трябва да работите по-ефективно с паметта.
• Второ, този преход трябва да бъде по-ефективен, когато страниците от паметта отиват на диск.
• И трето, трябва да има добри дискове.

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

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

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

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

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

Ако тичаш numactl --hardware, тогава ще получите толкова голям лист. Освен всичко друго ще има поле за разстояния. Ще има бройки - 10-20, нещо такова. Тези числа не са нищо друго освен броя на скокове, за да вземете тази отдалечена памет и да я използвате локално. По принцип добра идея. Това подобрява добре производителността при редица работни натоварвания.

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

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

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

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

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

Следователно правилният подход е да деактивирате напълно NUMAнапример при рестартиране. В повечето случаи печалбите са в такъв ред, че изобщо няма въпрос кое е по-добро.

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

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

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

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

Следващият момент са огромни страници. Огромните страници са трудни за тестване поотделно и няма смисъл от това, въпреки че има бенчмаркове, които могат да направят това. Лесно се търсят в гугъл.

Какъв е смисълът? Имате не много скъп сървър, който има много RAM, например повече от 30 GB. Не използвате огромни страници. Това означава, че определено имате режийни разходи за използване на паметта. И това режийно далеч не е най-приятното.

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

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

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

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

И как да се сприятеляваме с PostgreSQL? Първо, огромните страници трябва да бъдат разрешени в ядрото на Linux.

Второ, те трябва да бъдат изрично посочени от параметъра sysctl - колко са. Номерата тук са от някой стар сървър. Можете да изчислите приблизително колко споделени буфери имате, така че огромни страници да се поберат там.

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

Преди версия 9.2 (ако не греша, от версия 8.2) беше възможно да се сприятелявате с огромни страници PostgreSQL, използвайки библиотека на трета страна. И това винаги трябва да се прави. Първо, трябва ядрото да може да разпределя правилно огромни страници. И, второ, за да може приложението, което работи с тях, да ги използва. Просто няма да се използва по този начин. Тъй като PostgreSQL разпредели памет в системен стил 5, това може да се направи с помощта на libhugetlbfs - това е пълното име на библиотеката.

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

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

Опитайте е най-сигурната опция. Когато PostgreSQL стартира, когато разпределя споделена памет, той се опитва да грабне тази памет от огромни страници. И ако не работи, тогава се връща към обичайния избор. И ако имате FreeBSD или Solaris, можете да опитате, винаги е безопасно.

Ако е включено, просто не стартира, ако не може да избере от огромни страници. Ето вече - на кого и кое е по-сладко. Но ако опитате, проверете дали наистина имате подчертано това, от което се нуждаете, защото има много места за грешка. В момента тази функционалност работи само на Linux.

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

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

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

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

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

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

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

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

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

Какво представлява и как изглежда? Обикновено хората, които работят с PostgreSQL, са влизали в този бизнес повече от веднъж. ще обясня Както казах, PostgreSQL периодично прави контролни точки за изхвърляне на мръсни страници в споделената памет на диск. Ако имаме голямо количество споделена памет, тогава контролната точка започва интензивно да засяга диска, защото fsync изхвърля тези страници. Пристига в буфера на ядрото и се записва на диск с помощта на fsync. И ако обемът на този корпус е голям, тогава можем да наблюдаваме неприятен ефект, а именно много голямо използване на дискове.

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

Ако имате дисков масив, тогава има малко по-различна история. Там зависи как е конфигуриран, какъв масив и т.н.

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

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

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

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

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

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

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

Каква е уловката? Номерът е, че тези параметри в съвременния свят от 20 и 10% от цялата RAM, която има на машината, те са абсолютно чудовищни ​​по отношение на пропускателната способност на всяка дискова система, която имате.

Представете си, че имате 128 GB RAM. 12,8 GB идва към вашата дискова система. И какъвто и кеш да имаш там, какъвто и масив да имаш, няма да издържат толкова.

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

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

Какво се случва, ако не се вписвате? Написал съм, че ефективно спира всяко зачервяване, но всъщност е фигура на речта. Операционната система има голям проблем - има много мръсни страници, така че IO, който вашите клиенти генерират, ефективно спира, т.е. приложението е дошло да изпрати sql заявка към базата данни, то чака. Всеки I/O към него е с най-нисък приоритет, тъй като базата е заета от контролната точка. И когато тя свърши е напълно неразбираемо. И когато сте достигнали нефоново, нефоново промиване, това означава, че всичките ви IO са заети от него. И докато не свърши, нищо няма да направите.

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

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

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

И как развалят живота? Какво е sched_migration_cost? Планировчикът на Linux може да мигрира процес от един процесор към друг. А за PostgreSQL, който изпълнява заявки, мигрирането към друг процесор е напълно неразбираемо защо. От гледна точка на операционната система, когато превключвате прозорци между openoffice и терминал, това може да е добре, но за базата данни - много е зле. Следователно, разумна политика е да се зададе migration_cost на някаква голяма стойност, поне няколко хиляди наносекунди.

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

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

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

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

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

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

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

И съответно губернаторът е само изпълнение. Ondemand, powersave и всичко останало - това не е за вас.

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

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

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

въпроси:

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

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

Какъв е проблемът? Ако това е виртуална машина, тогава най-вероятно ще имате много проблеми, например с факта, че повечето виртуални машини имат доста непостоянна латентност на диска. Дори ако пропускателната способност на диска е добра, тогава една неуспешна I/O транзакция, която не влияе значително на средната пропускателна способност, случила се по време на контролна точка или по време на запис в WAL, тогава базата данни ще пострада значително от това. И ще забележите това, преди да се натъкнете на тези проблеми.

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

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

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

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

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

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

Не давай. Това може да се обясни по много начини. Но всъщност те просто не го дават. Каква е историята на PostgreSQL? При стартиране той разпределя голяма част от споделената памет. Прозрачни са в същото време или не са прозрачни - няма никакво значение. Фактът, че се открояват още в началото, обяснява всичко. И ако има много памет и трябва да изградите отново сегмента shared_memory, тогава прозрачните огромни страници ще бъдат подходящи. В PostgreSQL той просто се маркира в началото с огромно парче и това е, след което нищо особено не се случва там. Можете, разбира се, да го използвате, но има шанс да получите curruption shared_memory, когато преразпределя нещо. PostgreSQL не знае за това.

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