Linux Justering for å forbedre PostgreSQL-ytelsen. Ilya Kosmodemyansky

Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"

Disclaimer: Замечу что доклад этот датирован ноябрем 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 Питер, а потому что в современных условиях одна из самых оправданных ОС для эксплуатации с базами данных вообще и с PostgreSQL в частности – это Linux. Потому что FreeBSD, к сожалению, развивается в каком-то очень странном направлении. И будут проблемы как с производительностью, так и с многими другими вещами. Производительность PostgreSQL на Windows – это вообще отдельная суровая тема, упирающая в то, что у Windows нет такой шаредной памяти как у UNIX, а у PostgreSQL все на это дело завязано, потому что многопроцессная система.

Og jeg tror alle er mindre interessert i eksotiske ting som Solaris, så la oss gå.

У современного дистрибутива Linux более 1 000 параметров syctl, в зависимости от того, как собрать ядро. При этом, если мы посмотрим еще на разные гайки, то там можно еще многими способами что-нибудь поднастраивать. Есть параметры файловых систем, как монтировать. Если вопросы, как запустить: что в BIOS включить, как железки настроить и т. д.

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

Какие традиционные tuning targets есть в Linux? Я думаю, что поскольку вы все имеете дело с администрированием Linux, то что такое targets объяснять особо не надо.

Du kan stille inn:

• CPU.
• Hukommelse.
• Oppbevaring.
• Annen. Vi snakker om dette på slutten for en matbit. Selv for eksempel parametere som energisparepolitikk kan påvirke ytelsen på en svært uforutsigbar og ikke den mest behagelig måte.

Hva er detaljene til PostgreSQL og databasen generelt? Problemet er at du ikke kan justere noen individuelle mutter og se at ytelsen vår har forbedret seg betydelig.

Ja, det finnes slike gadgets, men en database er en kompleks ting. Den samhandler med alle ressursene som serveren har og foretrekker å samhandle til det fulle. Hvis du ser på Oracles nåværende anbefalinger om hvordan du bruker et verts-OS, vil det være som spøken om den mongolske kosmonauten - mat hunden og ikke rør noe. La oss gi databasen alle ressursene, selve databasen vil ordne opp i alt.

В принципе, до некоторой степени с PostgreSQL точно такая же ситуация. Разница заключается в том, что база еще и не все ресурсы сама умеет себе забирать, т. е. где-то нужно на уровне Linux это все разруливать самостоятельно.

Hovedideen er ikke å velge et enkelt mål og begynne å justere det, for eksempel minne, CPU eller noe sånt, men å analysere arbeidsbelastningen og prøve å forbedre gjennomstrømningen så mye som mulig slik at belastningen som gode programmerere skapte den for oss, inkludert våre brukere.

Вот такая картинка для пояснения того, что это такое. Есть буфер ОС Linux и есть шаредная память и есть шаредные буфера PostgreSQL. PostgreSQL в отличие от Oracle работает непосредственно только через буфер ядра, т. е. чтобы страничка с диска попала в его шаредную память, она должна пройти через kernel buffer и обратно точно такая же ситуация.

Disker lever under dette systemet. Jeg tegnet dette som disker. Faktisk kan det være en RAID-kontroller, etc.

Og denne input-output på en eller annen måte skjer gjennom denne saken.

PostgreSQL er en klassisk database. Det er en side inni. Og all input og output skjer ved hjelp av sider. Vi hever blokker inn i minnet med sider. Og hvis ingenting skjedde, leser vi dem bare, så forsvinner de gradvis fra denne cachen, fra de delte bufferne og havner tilbake på disken.

Hvis vi erstatter noe et sted, blir hele siden merket som skitten. Jeg merket dem her med blått. Og dette betyr at denne siden må synkroniseres med blokklagring. Det vil si at når vi gjorde det skittent, gjorde vi en oppføring i WAL. Og på et eller annet fantastisk tidspunkt kom et fenomen kalt sjekkpunkt. Og det ble registrert informasjon i denne loggen om at han var kommet. Og dette betyr at alle de skitne sidene som var her på det tidspunktet i disse delte bufferne ble synkronisert med lagringsdisken ved å bruke fsync gjennom kjernebufferen.

Hvorfor gjøres dette? Hvis vi mistet spenningen, så fikk vi ikke situasjonen at all data gikk tapt. Vedvarende hukommelse, som alle fortalte oss om, er så langt i databaseteorien - dette er en lys fremtid, som vi selvfølgelig streber etter og vi liker det, men for nå lever de om minus 20 år. Og selvfølgelig må alt dette overvåkes.

Og oppgaven med å maksimere gjennomstrømningen er å finjustere på alle disse stadiene slik at det hele beveger seg raskt frem og tilbake. Delt minne er i utgangspunktet en sidebuffer. I PostgreSQL sendte vi en utvalgsspørring eller noe, den hentet disse dataene fra disken. De havnet i delte buffere. Følgelig, for at dette skal fungere bedre, må det være mye minne.

For at alt dette skal fungere godt og raskt, må du konfigurere operativsystemet riktig i alle stadier. Og velg balansert maskinvare, for hvis du har ubalanse et sted, så kan du lage mye minne, men det vil ikke bli betjent i tilstrekkelig hastighet.

Og la oss gå gjennom hvert av disse punktene.

For å få disse sidene til å reise frem og tilbake raskere, må du oppnå følgende:

• For det første må du jobbe mer effektivt med minne.
• For det andre bør denne overgangen når sider fra minne går til disk være mer effektiv.
• Og for det tredje må det være gode disker.

Hvis du har 512 GB RAM server Og hvis alt dette ender opp på en SATA-harddisk uten mellomlagring, blir hele databaseserveren ikke bare til et gresskar, men et gresskar med et SATA-grensesnitt. Du vil bli sittende fast der. Og ingenting vil redde deg.

Når det gjelder det første punktet med hukommelse, er det tre ting som kan gjøre livet veldig vanskelig.

Den første av dem er NUMA. NUMA er en ting som er laget for å forbedre ytelsen. Avhengig av arbeidsmengden kan forskjellige ting optimaliseres. Og i sin nye nåværende form er det ikke særlig bra for applikasjoner som databaser som intensivt bruker delte buffere for sidebuffer.

I et nøtteskall. Hvordan kan du finne ut om noe er galt med NUMA? Du har en slags ubehagelig banking, plutselig er en CPU overbelastet. Samtidig analyserer du spørringer i PostgreSQL og ser at det ikke er noe lignende der. Disse spørringene bør ikke være så CPU-intensive. Dette kan du fange lenge. Det er lettere å bruke riktig anbefaling helt fra begynnelsen av hvordan du konfigurerer NUMA for PostgreSQL.

Hva skjer egentlig? NUMA står for Non-Uniform Memory Access. Hva er poenget? Du har en CPU, ved siden av den er det det lokale minnet. Og disse minneforbindelsene kan trekke opp minne fra andre CPUer.

Hvis du løper numactl --hardware, så får du et så stort ark. Det blir blant annet et avstandsfelt. Det blir tall - 10-20, noe sånt. Disse tallene er ikke mer enn antall hopp for å plukke opp dette eksterne minnet og bruke det lokalt. I prinsippet en god idé. Dette øker ytelsen godt under en rekke arbeidsbelastninger.

Tenk deg nå at du har én CPU som først prøver å bruke det lokale minnet, og deretter prøver å trekke opp et annet minne via sammenkobling for noe. Og denne CPU-en får hele PostgreSQL-sidebufferen din - det er det, noen gigabyte. Du får alltid det verste tilfellet, for på CPUen er det vanligvis lite minne i selve modulen. Og alt minnet som betjenes går gjennom disse sammenkoblingene. Det viser seg tregt og trist. Og prosessoren din som betjener denne noden er konstant overbelastet. Og tilgangstiden til dette minnet er dårlig, treg. Dette er situasjonen du ikke ønsker hvis du bruker dette for en database.

Поэтому более правильный вариант для базы данных, чтобы операционная система Linux вообще не знала, что там происходит. Чтобы она обращалась к памяти как обращается.

Hvorfor det? Det ser ut til at det burde være omvendt. Dette skjer av én enkel grunn: vi trenger mye minne for sidebufferen - titalls, hundrevis av gigabyte.

Og hvis vi allokerte alt dette og cachede dataene våre der, så vil gevinsten ved å bruke cachen være betydelig større enn gevinsten fra en så vanskelig tilgang til minnet. Og vi vil dermed ha en uforlignelig fordel sammenlignet med det faktum at vi får tilgang til minne mer effektivt ved å bruke NUMA.

Derfor er det to tilnærminger her for øyeblikket, helt til den lyse fremtiden har kommet, og databasen selv ikke klarer å finne ut hvilke CPUer den kjører på og hvor den må hente noe fra.

Derfor er den riktige tilnærmingen å deaktivere NUMA helt, for eksempel ved omstart. I de fleste tilfeller er gevinstene av en slik størrelsesorden at spørsmålet om hva som er best ikke oppstår i det hele tatt.

Det er et annet alternativ. Vi bruker den oftere enn den første, fordi når en klient kommer til oss for å få støtte, er det en stor sak for ham å starte serveren på nytt. Han har en virksomhet der. Og de opplever problemer på grunn av NUMA. Derfor prøver vi å deaktivere den på mindre invasive måter enn omstart, men vær forsiktig med å sjekke at den er deaktivert. Fordi, som erfaring viser, er det bra at vi deaktiverer NUMA på den overordnede PostgreSQL-prosessen, men det er slett ikke nødvendig at det vil fungere. Vi må sjekke og se at hun virkelig slo seg av.

Det er et godt innlegg av Robert Haas. Dette er en av PostgreSQL-committerne. En av nøkkelutviklerne av alle lavnivå-innmat. Og hvis du følger lenkene fra dette innlegget, beskriver de flere fargerike historier om hvordan NUMA gjorde livet vanskelig for mennesker. Se, studer systemadministratorens sjekkliste over hva som må konfigureres på serveren for at databasen vår skal fungere bra. Disse innstillingene må skrives ned og kontrolleres, for ellers blir det ikke veldig bra.

Vær oppmerksom på at dette gjelder alle innstillinger som jeg vil snakke om. Men vanligvis samles databaser i master-slave-modus for feiltoleranse. Ikke glem å gjøre disse innstillingene på slaven fordi en dag vil du ha en ulykke og du vil bytte til slaven og den vil bli masteren.

I en nødsituasjon, når alt er veldig dårlig, telefonen ringer konstant og sjefen din kommer løpende med en stor pinne, vil du ikke ha tid til å tenke på å sjekke. Og resultatene kan være ganske katastrofale.

Neste punkt er store sider. Enorme sider er vanskelig å teste hver for seg, og det er ingen vits i å gjøre det, selv om det finnes benchmarks som kan gjøre dette. De er enkle å Google.

Hva er poenget? Du har en ikke veldig dyr server med mye RAM, for eksempel mer enn 30 GB. Du bruker ikke store sider. Dette betyr at du definitivt har overhead når det gjelder minnebruk. Og denne overheaden er langt fra den mest behagelige.

Hvorfor det? Så hva skjer? Operativsystemet tildeler minne i små biter. Det er så praktisk, det er slik det skjedde historisk. Og hvis vi går i detalj, må operativsystemet oversette virtuelle adresser til fysiske. Og denne prosessen er ikke den enkleste, så OS cacher resultatet av denne operasjonen i Translation Lookaside Buffer (TLB).

Og siden TLB er en cache, oppstår alle problemene som ligger i en cache i denne situasjonen. For det første, hvis du har mye RAM og alt er tildelt i små biter, blir denne bufferen veldig stor. Og hvis cachen er stor, går det tregere å søke gjennom den. Overhead er sunt og tar i seg selv plass, det vil si at RAM blir konsumert av noe feil. Denne gangen.

Два – чем больше разрастается кэш в такой ситуации, тем больше вероятность того, что у вас будет cache misses. И эффективность этого кэша стремительно падает с ростом его размера. Поэтому в операционных системах придумали простой подход. В Linux он давно уже используется. В FreeBSD не так давно появился. Но мы говорим о Linux. Это huge pages.

Og her bør det bemerkes at enorme sider, som en idé, i utgangspunktet ble presset av fellesskap som inkluderte Oracle og IBM, dvs. databaseprodusenter trodde sterkt at dette ville være nyttig for databaser også.

Og hvordan kan dette bli venner med PostgreSQL? For det første må enorme sider aktiveres i Linux-kjernen.

For det andre må de spesifiseres eksplisitt av sysctl-parameteren - hvor mange det er. Tallene her er fra en gammel server. Du kan beregne hvor mange delte buffere du har slik at store sider får plass der.

Og hvis hele serveren din er dedikert til PostgreSQL, så er et godt utgangspunkt å allokere enten 25 % av RAM til delte buffere, eller 75 % hvis du er sikker på at databasen din definitivt vil passe inn i disse 75 %. Utgangspunkt én. Og tenk på at hvis du har 256 GB RAM, vil du følgelig ha 64 GB store buffere. Beregn omtrentlig med litt margin - hva dette tallet skal settes til.

Før versjon 9.2 (hvis jeg ikke tar feil, siden versjon 8.2), var det mulig å koble PostgreSQL med enorme sider ved hjelp av et tredjepartsbibliotek. Og dette bør alltid gjøres. Først trenger du kjernen for å kunne tildele enorme sider riktig. Og for det andre, slik at applikasjonen som fungerer med dem kan bruke dem. Det vil ikke bare brukes på den måten. Siden PostgreSQL allokerte minne i system 5-stilen, kan dette gjøres ved å bruke libhugetlbfs - dette er det fulle navnet på biblioteket.

I 9.3 ble PostgreSQL-ytelsen forbedret ved arbeid med minne, og system 5-minnetildelingsmetoden ble forlatt. Alle var veldig fornøyde, for ellers prøver du å kjøre to PostgreSQL-forekomster på en maskin, og han sier at jeg ikke har nok delt minne. Og han sier at sysctl må korrigeres. Og det er en slik sysctl at du fortsatt trenger å starte på nytt osv. Generelt var alle fornøyde. Men tildeling av mmap-minne brøt bruken av enorme sider. De fleste av våre kunder bruker store delte buffere. Og vi anbefalte på det sterkeste å ikke bytte til 9.3, fordi overhead der begynte å bli beregnet i gode prosenter.

Men samfunnet tok hensyn til dette problemet, og i 9.4 omarbeidet de denne hendelsen veldig bra. Og i 9.4 dukket det opp en parameter i postgresql.conf der du kan aktivere forsøk, på eller av.

Prøv er det sikreste alternativet. Når PostgreSQL starter, når den tildeler delt minne, prøver den å hente dette minnet fra de enorme sidene. Og hvis det ikke fungerer, går det tilbake til det normale valget. Og hvis du har FreeBSD eller Solaris, så kan du prøve, det er alltid trygt.

Если on, то он просто не стартует, если не смог выделить из huge pages. Тут уже – кому и что более мило. Но если у вас стоит try, то проверяйте, что у вас действительно то, что нужно выделилось, потому что пространств для ошибки там много. Сейчас этот функционал работает только на Linux.

En liten merknad til før vi går videre. Gjennomsiktige enorme sider handler ikke om PostgreSQL ennå. Han kan ikke bruke dem normalt. Og med transparente enorme sider for en slik arbeidsmengde, når et stort stykke delt minne er nødvendig, kommer fordelene bare med svært store volumer. Hvis du har terabyte med minne, kan dette spille inn. Hvis vi snakker om mer hverdagslige applikasjoner, når du har 32, 64, 128, 256 GB minne på maskinen din, så er de vanlige enorme sidene Ok, og vi deaktiverer ganske enkelt Transparent.

Og det siste med hukommelse er ikke direkte relatert til frukt, det kan virkelig ødelegge livet ditt. All gjennomstrømming vil bli sterkt påvirket av at serveren stadig bytter.

И это будет очень неприятно в ряде моментов. И основная неприятность заключается в том, что в современных ядрах немножко разнится поведение с более старыми ядрами Linux. И эта вещь, на которую наступать довольно неприятно, потому что, когда мы говорим о какой-то работе с swap’ом, заканчивается это не своевременным приходом OOM-killer. И OOM-killer, который не своевременно пришел и скинул PostgreSQL, это неприятно. Об этом узнают все, т. е. до последнего пользователя.

Hva skjer? Du har en stor mengde RAM der, alt fungerer bra. Men av en eller annen grunn henger serveren i swap og bremser ned på grunn av dette. Det ser ut til at det er mye minne, men dette skjer.

Tidligere anbefalte vi å sette vm.swappiness til null, det vil si å deaktivere swap. Tidligere så det ut til at 32 GB RAM og tilsvarende delte buffere var en enorm mengde. Hovedformålet med byttet er å ha et sted å kaste skorpen hvis vi faller av. Og det var ikke lenger spesielt oppfylt. Og hva skal du gjøre med denne skorpen? Dette er en oppgave hvor det ikke er veldig klart hvorfor bytte er nødvendig, spesielt av en slik størrelse.

Men i mer moderne, dvs. tredje versjoner av kjernen, har oppførselen endret seg. Og hvis du setter swap til null, dvs. slår den av, så før eller siden, selv om det er litt RAM igjen, vil en OOM-killer komme til deg for å drepe de mest intensive forbrukerne. Fordi han vil vurdere at med en slik arbeidsmengde har vi fortsatt litt igjen og vi vil hoppe ut, det vil si ikke for å spikre fast systemprosessen, men for å spikre noe mindre viktig. Denne mindre viktige vil være den intensive forbrukeren av delt minne, nemlig postmesteren. Og etter det vil det være bra hvis basen ikke må gjenopprettes.

Derfor, nå standard, så vidt jeg husker, er de fleste distribusjoner et sted rundt 6, dvs. på hvilket tidspunkt bør du begynne å bruke swap avhengig av hvor mye minne som er igjen. Vi anbefaler nå å sette vm.swappiness = 1, fordi dette praktisk talt slår den av, men ikke gir de samme effektene som med en OOM-killer som uventet kom og drepte hele greia.

Hva blir det neste? Når vi snakker om ytelsen til databaser og gradvis beveger oss mot disker, begynner alle å ta tak i hodet. Fordi sannheten om at disken er treg og minnet er rask er kjent for alle fra barndommen. Og alle vet at databasen vil ha problemer med diskytelse.

Det viktigste PostgreSQL-ytelsesproblemet knyttet til sjekkpunktspiker oppstår ikke fordi disken er treg. Dette er mest sannsynlig på grunn av det faktum at minne og diskbåndbredde ikke er balansert. Imidlertid kan de ikke balanseres på forskjellige steder. PostgreSQL er ikke konfigurert, OS er ikke konfigurert, maskinvaren er ikke konfigurert og maskinvaren er feil. Og dette problemet skjer ikke bare hvis alt skjer som det skal, det vil si enten det ikke er noen belastning, eller innstillingene og maskinvaren er godt valgt.

Hva er det og hvordan ser det ut? Vanligvis har folk som jobber med PostgreSQL gått inn i denne saken mer enn én gang. Jeg skal forklare. Som sagt, PostgreSQL lager med jevne mellomrom sjekkpunkter for å dumpe skitne sider i delt minne til disk. Hvis vi har en stor mengde delt minne, begynner sjekkpunkt å ha en intensiv innvirkning på disken, fordi den dumper disse sidene med fsync. Den kommer til kjernebufferen og skrives til disker ved hjelp av fsync. Og hvis volumet av denne virksomheten er stort, kan vi observere en ubehagelig effekt, nemlig en veldig stor utnyttelse av disker.

Her har jeg to bilder. Jeg skal nå forklare hva det er. Dette er to tidskorrelerte grafer. Den første grafen er diskutnyttelse. Her når den nesten 90 % på dette tidspunktet. Hvis du har en databasefeil med fysiske disker, med en RAID-kontrollerutnyttelse på 90 %, så er dette dårlige nyheter. Dette betyr at litt mer og det vil nå 100 og I/O vil stoppe.

Hvis du har en diskarray, er det en litt annen historie. Det avhenger av hvordan det er konfigurert, hva slags array det er osv.

Og parallelt konfigureres her en graf fra den interne postgres-visningen, som forteller hvordan sjekkpunktet oppstår. Og den grønne fargen her viser hvor mange buffere, disse skitne sidene, i det øyeblikket ankom dette sjekkpunktet for synkronisering. Og dette er det viktigste du trenger å vite her. Vi ser at vi har mange sider her og på et tidspunkt traff vi brettet, det vil si at vi skrev og skrev, her er disksystemet helt klart veldig travelt. Og sjekkpunktet vårt har en veldig sterk innvirkning på disken. Ideelt sett burde situasjonen se mer slik ut, det vil si at vi hadde mindre opptak her. Og vi kan fikse det med innstillingene slik at det fortsetter å være slik. Det vil si at gjenvinningen er liten, men et sted skriver vi noe her.

Hva må gjøres for å overvinne dette problemet? Hvis du har stoppet IO under databasen, betyr dette at alle brukere som kom for å oppfylle sine forespørsler vil vente.

Если посмотреть с точки зрения Linux, если вы взяли хороший hardware, правильно его настроили, нормально настроили PostgreSQL, чтобы он пореже делал эти checkpoints, размазывал их по времени друг между другом, то вы наступаете в дефолтные параметры Debian. Для большинства дистрибутивов Linux вот такая картина: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Hva betyr det? En spylingsdemon dukket opp fra kjerne 2.6. Pdglush, avhengig av hvem som bruker hvilken, som er engasjert i bakgrunnskasting av skitne sider fra kjernebufferen og forkasting når det er nødvendig å forkaste skitne sider uansett hva, når bakgrunnskasting ikke hjelper.

Når kommer bakgrunnen? Når 10 % av total RAM tilgjengelig på serveren er okkupert av skitne sider i kjernebufferen, kalles en spesiell avskrivingsfunksjon i bakgrunnen. Hvorfor er det bakgrunn? Som en parameter tar den hensyn til hvor mange sider som skal avskrives. Og la oss si at han avskriver N sider. Og for en stund sovner denne tingen. Og så kommer hun igjen og kopierer noen sider til.

Dette er en ekstremt enkel historie. Problemet her er som med et svømmebasseng, når det renner inn i ett rør, renner det inn i et annet. Kontrollpunktet vårt ankom, og hvis det sendte noen skitne sider for forkasting, vil det hele gradvis løses pent fra kjernebufferen pgflush.

Hvis disse skitne sidene fortsetter å samle seg, akkumuleres de opptil 20%, hvoretter OS-prioriteten er å skrive av hele greia til disken, fordi strømmen vil svikte og alt blir dårlig for oss. Vi mister for eksempel disse dataene.

Hva er trikset? Trikset er at disse parameterne i den moderne verden er 20 og 10% av den totale RAM-en som er på maskinen, de er helt monstrøse når det gjelder gjennomstrømmingen til ethvert disksystem du har.

Tenk deg at du har 128 GB RAM. 12,8 GB kommer til disksystemet ditt. Og uansett hvilken cache du har der, uansett hvilken array du har der, vil de ikke vare så lenge.

Derfor anbefaler vi at du umiddelbart justerer disse tallene basert på egenskapene til RAID-kontrolleren. Jeg ga umiddelbart en anbefaling her for en kontroller som har 512 MB cache.

Alt anses som veldig enkelt. Du kan sette vm.dirty_background i byte. Og disse innstillingene avbryter de to foregående. Enten forholdet er som standard, eller de med byte er aktivert, så vil de med byte fungere. Men siden jeg er DBA-konsulent og jobber med forskjellige kunder, prøver jeg å trekke sugerør og derfor, hvis i byte, så i byte. Ingen ga noen garanti for at en god admin ikke ville legge til mer minne til serveren, starte den på nytt, og tallet ville forbli det samme. Bare regn ut disse tallene slik at alt passer inn der med garanti.

Hva skjer hvis du ikke passer inn? Jeg har skrevet at enhver rødming effektivt stoppes, men faktisk er dette en talemåte. Operativsystemet har et stort problem - det har mange skitne sider, så IO-en som dine klienter genererer blir effektivt stoppet, det vil si at applikasjonen har kommet for å sende en sql-spørring til databasen, den venter. Enhver input/output til den har lavest prioritet, fordi databasen er okkupert av et sjekkpunkt. Og når hun blir ferdig er det helt uklart. Og når du har oppnådd ikke-bakgrunnsspyling, betyr det at all IO er opptatt av det. Og inntil det slutter, vil du ikke gjøre noe.

Det er ytterligere to viktige punkter her som ligger utenfor rammen av denne rapporten. Disse innstillingene skal samsvare med innstillingene i postgresql.conf, dvs. sjekkpunktinnstillinger. Og disksystemet ditt må være tilstrekkelig konfigurert. Hvis du har en cache på en RAID, så må den ha et batteri. Folk kjøper RAID med god cache uten batteri. Hvis du har SSD-er i RAID, så må de være servere, det må være kondensatorer der. Her er en detaljert sjekkliste. Denne lenken inneholder rapporten min om hvordan du konfigurerer en ytelsesdisk i PostgreSQL. Det er alle disse sjekklistene der.

Hva annet kan gjøre livet veldig vanskelig? Dette er to parametere. De er relativt nye. Som standard kan de inkluderes i forskjellige applikasjoner. Og de kan gjøre livet like vanskelig hvis de slås feil på.

Det er to relativt nye ting. De har allerede dukket opp i de tredje kjernene. Dette er sched_migration_cost i nanosekunder og sched_autogroup_enabled, som er en som standard.

И как они портят жизнь? Что такое sched_migration_cost? У Linux scheduler может смигрировать процесс с одного CPU на другой. И для PostgreSQL, который выполняет запросы, миграция на другой CPU совершенно не понятна зачем. С точки зрения операционной системы, когда вы переключаете окна между openoffice и терминалом, то это, может быть, хорошо, но for en database er dette veldig dårlig. Derfor er en rimelig policy å sette migration_cost til en eller annen stor verdi, minst flere tusen nanosekunder.

Hva vil dette bety for planleggeren? Det vil bli vurdert at i løpet av denne tiden er prosessen fortsatt varm. Det vil si at hvis du har en langvarig transaksjon som har gjort noe lenge, vil planleggeren forstå dette. Han vil anta at inntil denne tidsavbruddet går, er det ikke nødvendig å migrere denne prosessen noe sted. Hvis prosessen samtidig gjør noe, vil den ikke bli migrert noe sted, den vil stille og rolig fungere på CPU-en som ble tildelt den. Og resultatet er utmerket.

Det andre punktet er autogruppe. Det er en god idé for spesifikke arbeidsbelastninger som ikke er relatert til moderne databaser - dette er å gruppere prosesser etter den virtuelle terminalen de lanseres fra. Dette er praktisk for noen oppgaver. I praksis er PostgreSQL et multiprosesssystem med en forgaffel som kjører fra en enkelt terminal. Du har en låseskriver, sjekkpunkt, og alle klientforespørslene dine vil bli gruppert i én planlegger, per CPU. Og de vil vente der unisont på at han skal være fri, for å forstyrre hverandre og holde ham opptatt lenger. Dette er en historie som er helt unødvendig i tilfelle en slik belastning og derfor må den slås av.

Min kollega Alexey Lesovsky gjorde tester med en enkel pgbench, hvor han økte migration_cost med en størrelsesorden og slo av autogruppe. Forskjellen på dårlig maskinvare var nesten 10 %. Det er en diskusjon på postgres e-postliste der folk gir resultater av lignende endringer i spørringshastighet påvirket 50 %. Det er ganske mange slike historier.

И напоследок про power saving policy. Хорошо, что теперь Linux можно использовать на ноутбуке. И он будет якобы хорошо расходовать батарейку. Но внезапно оказывается, что на сервере такое тоже может быть.

Dessuten, hvis du leier servere fra en hvilken som helst hostingleverandør, så er det "bra" vertskap De bryr seg ikke om ytelsen din. Jobben deres er å sørge for at maskinvaren deres utnyttes så effektivt som mulig. Derfor kan de som standard aktivere strømsparingsmodus i operativsystemet, som ligner på en bærbar PC.

Hvis du bruker disse tingene på en server med en database under tung belastning, er valget ditt acpi_cpufreq + permormance. Selv med ondemand vil det være problemer.

Intel_pstate er en litt annen driver. Og nå foretrekkes denne, som den er senere og fungerer bedre.

Og følgelig er guvernør bare ytelse. Ondemand, strømsparing og alt annet handler ikke om deg.

Resultatene av forklaringsanalysen PostgreSQL kan variere med flere størrelsesordener hvis du aktiverer strømsparing, fordi praktisk talt CPUen under databasen din vil kjøre på en helt uforutsigbar måte.

Disse elementene kan være inkludert som standard. Se nøye for å se om de har slått den på som standard. Dette kan være et veldig stort problem.

Og til slutt ville jeg si takk til gutta fra vårt PosgreSQL-Consulting DBA-team, nemlig Max Boguk og Alexey Lesovsky, som gjør fremskritt i denne saken hver dag. Og vi prøver å gjøre det beste vi kan for kundene våre slik at alt fungerer for dem. Det er som med flysikkerhetsinstruksjoner. Alt her er skrevet i blod. Hver av disse nøttene er funnet i ferd med en slags problem. Jeg deler dem gjerne med deg.

spørsmål:

Takk skal du ha! Hvis for eksempel et selskap ønsker å spare penger og plassere databasen og applikasjonslogikken på én server, eller hvis selskapet følger den moteriktige trenden med mikrotjenestearkitekturer, der PostgreSQL kjører i en container. Hva er trikset? Sysctl vil påvirke hele kjernen globalt. Jeg har ikke hørt om sysctls som på en eller annen måte er virtualisert slik at de fungerer separat på en container. Det er bare en cgroup og det er bare en del av kontrollen der. Hvordan kan du leve med dette? Eller hvis du vil ha ytelse, så kjør PostgreSQL på en egen maskinvareserver og finjuster den?

Vi svarte på spørsmålet ditt på omtrent tre måter. Hvis vi ikke snakker om en maskinvareserver som kan stilles inn osv., så slapp av, alt vil fungere fint uten disse innstillingene. Hvis du har en slik belastning at du må gjøre disse innstillingene, så kommer du til jernserveren tidligere enn til disse innstillingene.

Hva er problemet? Hvis dette er en virtuell maskin, vil du mest sannsynlig ha mange problemer, for eksempel med det faktum at på de fleste virtuelle maskiner er latensen til disken ganske inkonsekvent. Selv om diskgjennomstrømningen er god, så vil én mislykket I/O-transaksjon som ikke i stor grad påvirker den gjennomsnittlige gjennomstrømningen som skjedde på tidspunktet for sjekkpunkt eller i skrivende stund til WAL, da vil databasen lide mye av dette. Og du vil merke dette før du støter på disse problemene.

Hvis du har NGINX på samme server, vil du også ha det samme problemet. Han vil kjempe for felles minne. Og du kommer ikke til problemene som er beskrevet her.

Men på den annen side vil noen av disse parameterne fortsatt være relevante for deg. Sett for eksempel dirty_ratio med sysctl slik at det ikke er så sprøtt - i alle fall vil dette hjelpe. På en eller annen måte vil du ha interaksjon med disken. Og det blir etter feil mønster. Dette er vanligvis en standard for parameterne jeg viste. Og i alle fall er det bedre å endre dem.

Men det kan være problemer med NUMA. VmWare, for eksempel, fungerer bra med NUMA med nøyaktig motsatte innstillinger. Og her må du velge - en jernserver eller en ikke-jernholdig.

Jeg har et spørsmål knyttet til Amazon AWS. De har forhåndskonfigurerte bilder. En av dem heter Amazon RDS. Er det noen egendefinerte innstillinger for deres operativsystem?

Det er innstillinger der, men det er forskjellige innstillinger. Her konfigurerer vi operativsystemet i forhold til hvordan databasen vil bruke denne tingen. Og det er parametere som bestemmer hvor vi skal gå nå, for eksempel forming. Det vil si at vi trenger så mange ressurser, vi skal nå spise dem opp. Etter dette strammer Amazon RDS inn disse ressursene, og ytelsen synker der. Det er individuelle historier om hvordan folk begynner å rote med denne saken. Noen ganger til og med ganske vellykket. Men dette har ingenting med OS-innstillinger å gjøre. Det er som å hacke skyen. Det er en annen historie.

Hvorfor har Transparente enorme sider ingen effekt sammenlignet med Huge TLB?

Ikke gi. Dette kan forklares på mange måter. Men faktisk gir de det rett og slett ikke. Hva er historien til PostgreSQL? Ved oppstart tildeler den et stort stykke delt minne. Om de er gjennomsiktige eller ikke er helt irrelevant. Det at de skiller seg ut i starten forklarer alt. Og hvis det er mye minne og du trenger å gjenoppbygge shared_memory-segmentet, vil Transparente enorme sider være relevante. I PostgreSQL blir det ganske enkelt tildelt i en stor del i starten, og det er det, og så skjer det ikke noe spesielt der. Du kan selvfølgelig bruke det, men det er en sjanse for å få en korrupsjon av shared_memory når den tildeler noe på nytt. PostgreSQL vet ikke om dette.

Kilde: www.habr.com