Tuning Linux për të përmirësuar performancën PostgreSQL. Ilya Kosmodemyansky

Transkripti i raportit të vitit 2015 nga Ilya Kosmodemyansky "Saktonizimi i Linux për të përmirësuar performancën PostgreSQL"

Mohim përgjegjësie: Unë vërej se ky raport është i datës Nëntor 2015 - kanë kaluar më shumë se 4 vjet dhe ka kaluar shumë kohë. Versioni 9.4 i diskutuar në raport nuk mbështetet më. Gjatë 4 viteve të fundit, janë lëshuar 5 versione të reja të PostgreSQL dhe janë lëshuar 15 versione të kernelit Linux. Nëse i rishkruani këto pasazhe, do të përfundoni me një raport tjetër. Por këtu kemi parasysh akordimin themelor të Linux për PostgreSQL, i cili është ende i rëndësishëm sot.

Emri im është Ilya Kosmodemyansky. Unë punoj në PostgreSQL-Consulting. Dhe tani do të flas pak se çfarë të bëjmë me Linux në lidhje me bazat e të dhënave në përgjithësi dhe PostgreSQL në veçanti, sepse parimet janë mjaft të ngjashme.

Për çfarë do të flasim? Nëse komunikoni me PostgreSQL, atëherë në një farë mase duhet të jeni një administrator UNIX. Çfarë do të thotë? Nëse krahasojmë Oracle dhe PostgreSQL, atëherë në Oracle duhet të jeni 80% administrator i bazës së të dhënave DBA dhe 20% administrator Linux.

Me PostgreSQL është pak më e ndërlikuar. Me PostgreSQL ju duhet të keni një kuptim shumë më të mirë se si funksionon Linux. Dhe në të njëjtën kohë, vraponi pak pas lokomotivës, sepse kohët e fundit gjithçka është përditësuar mjaft bukur. Dhe kernelet e reja lëshohen, dhe funksionaliteti i ri shfaqet, performanca përmirësohet, etj.

Pse po flasim për Linux? Aspak sepse jemi në konferencën e Linux Peter, por sepse në kushtet moderne një nga sistemet operative më të justifikuara për përdorimin e bazave të të dhënave në përgjithësi dhe PostgreSQL në veçanti është Linux. Sepse FreeBSD, për fat të keq, po zhvillohet në një drejtim shumë të çuditshëm. Dhe do të ketë probleme si me performancën ashtu edhe me shumë gjëra të tjera. Performanca e PostgreSQL në Windows është përgjithësisht një çështje serioze më vete, bazuar në faktin se Windows nuk ka të njëjtën memorie të përbashkët si UNIX, ndërsa PostgreSQL është e gjitha e lidhur me këtë, sepse është një sistem me shumë procese.

Dhe unë mendoj se të gjithë janë më pak të interesuar për ekzotikët si Solaris, kështu që le të shkojmë.

Një shpërndarje moderne Linux ka mbi 1 opsione syctl, në varësi të mënyrës se si e ndërtoni kernelin. Në të njëjtën kohë, nëse shohim arrat e ndryshme, mund të rregullojmë diçka në shumë mënyra. Ekzistojnë parametra të sistemit të skedarëve se si t'i montoni ato. Nëse keni pyetje se si ta filloni: çfarë të aktivizoni në BIOS, si të konfiguroni harduerin, etj.

Ky është një vëllim shumë i madh që mund të diskutohet për disa ditë, dhe jo në një raport të shkurtër, por tani do të përqendrohem në gjëra të rëndësishme, si të shmangni ato raketa që garantojnë se do t'ju pengojnë të përdorni mirë bazën e të dhënave në Linux, nëse ju mos i korrigjoni ato. Dhe në të njëjtën kohë, një pikë e rëndësishme është se shumë parametra të paracaktuar nuk përfshihen në cilësimet që janë të sakta për bazën e të dhënave. Kjo do të thotë, si parazgjedhje do të funksionojë dobët ose aspak.

Cilat synime tradicionale të akordimit ekzistojnë në Linux? Unë mendoj se duke qenë se të gjithë merreni me administrimin e Linux, nuk ka nevojë të veçantë për të shpjeguar se cilat janë objektivat.

Mund të akordoni:

• CPU
• Kujtesa.
• Storage.
• Të tjera. Ne do të flasim për këtë në fund për një meze të lehtë. Madje, për shembull, parametra të tillë si politikat e kursimit të energjisë mund të ndikojnë në performancën në një mënyrë shumë të paparashikueshme dhe jo më të këndshme.

Cilat janë specifikat e PostgreSQL dhe bazës së të dhënave në përgjithësi? Problemi është se nuk mund të shkulësh asnjë arrë individuale dhe të shohësh se performanca jonë është përmirësuar ndjeshëm.

Po, ka pajisje të tilla, por një bazë të dhënash është një gjë komplekse. Ai ndërvepron me të gjitha burimet që ka serveri dhe preferon të ndërveprojë në maksimum. Nëse shikoni rekomandimet aktuale të Oracle se si të përdorni një sistem operativ pritës, do të jetë si shaka për atë kozmonaut mongol - ushqeni qenin dhe mos prekni asgjë. Le t'i japim bazës së të dhënave të gjitha burimet, vetë baza e të dhënave do të zgjidhë gjithçka.

Në parim, në një farë mase situata është saktësisht e njëjtë me PostgreSQL. Dallimi është se baza e të dhënave nuk është ende në gjendje të marrë të gjitha burimet për vete, d.m.th. diku në nivelin Linux ju duhet t'i zgjidhni të gjitha vetë.

Ideja kryesore nuk është të zgjidhni një objektiv të vetëm dhe të filloni ta rregulloni atë, për shembull, memorie, CPU ose diçka të tillë, por të analizoni ngarkesën e punës dhe të përpiqeni të përmirësoni xhiros sa më shumë që të jetë e mundur në mënyrë që ngarkesa që programuesit e mirë e krijuan atë. për ne, duke përfshirë përdoruesit tanë.

Këtu është një foto për të shpjeguar se çfarë është. Ekziston një tampon Linux OS dhe ka memorie të përbashkët dhe ka buffer të përbashkët PostgreSQL. PostgreSQL, ndryshe nga Oracle, punon drejtpërdrejt vetëm përmes buferit të kernelit, d.m.th., në mënyrë që një faqe nga disku të futet në memorien e tij të përbashkët, duhet të kalojë përmes buferit të kernelit dhe të kthehet, saktësisht e njëjta situatë.

Disqet jetojnë nën këtë sistem. Unë e vizatova këtë si disqe. Në fakt, mund të ketë një kontrollues RAID, etj.

Dhe ky input-output në një mënyrë ose në një tjetër ndodh përmes kësaj çështjeje.

PostgreSQL është një bazë të dhënash klasike. Ka një faqe brenda. Dhe të gjitha hyrjet dhe daljet ndodhin duke përdorur faqet. Ne po ngremë blloqe në kujtesë me faqe. Dhe nëse asgjë nuk ka ndodhur, ne thjesht i lexojmë ato, pastaj gradualisht ato zhduken nga kjo cache, nga buferat e përbashkëta dhe përfundojnë përsëri në disk.

Nëse zëvendësojmë diçka diku, atëherë e gjithë faqja shënohet si e ndotur. Këtu i shënova me blu. Dhe kjo do të thotë që kjo faqe duhet të sinkronizohet me ruajtjen e bllokut. Domethënë, kur e bëmë pis, bëmë një hyrje në WAL. Dhe në një moment të mrekullueshëm në kohë, erdhi një fenomen i quajtur postblloku. Dhe informacioni u regjistrua në këtë regjistër se ai kishte mbërritur. Dhe kjo do të thotë që të gjitha faqet e pista që ishin këtu në atë moment në këto bufera të përbashkëta u sinkronizuan me diskun e ruajtjes duke përdorur fsync përmes buferit të kernelit.

Pse po bëhet kjo? Nëse kemi humbur tensionin, atëherë nuk kemi marrë situatën që të gjitha të dhënat janë humbur. Kujtesa e vazhdueshme, për të cilën të gjithë na treguan, është deri më tani në teorinë e bazës së të dhënave - kjo është një e ardhme e ndritur, për të cilën ne, natyrisht, përpiqemi dhe na pëlqen, por tani për tani ata jetojnë në minus 20 vjet. Dhe, sigurisht, e gjithë kjo duhet të monitorohet.

Dhe detyra e maksimizimit të xhiros është të rregulloni mirë në të gjitha këto faza në mënyrë që të gjitha të lëvizin përpara dhe mbrapa shpejt. Kujtesa e përbashkët është në thelb një cache faqesh. Në PostgreSQL ne dërguam një pyetje të zgjedhur ose diçka tjetër, ai i mori këto të dhëna nga disku. Ata përfunduan në bufera të përbashkëta. Prandaj, që kjo të funksionojë më mirë, duhet të ketë shumë memorie.

Në mënyrë që e gjithë kjo të funksionojë mirë dhe shpejt, duhet të konfiguroni saktë sistemin operativ në të gjitha fazat. Dhe zgjidhni pajisje të balancuara, sepse nëse keni një çekuilibër në një vend, atëherë mund të krijoni shumë memorie, por nuk do të shërbehet me shpejtësi të mjaftueshme.

Dhe le të kalojmë nëpër secilën nga këto pika.

Për t'i bërë këto faqe të udhëtojnë përpara dhe mbrapa më shpejt, duhet të arrini sa vijon:

• Së pari, duhet të punoni në mënyrë më efikase me kujtesën.
• Së dyti, ky kalim kur faqet nga memoria shkojnë në disk duhet të jetë më efikas.
• Dhe së treti, duhet të ketë disqe të mirë.

Nëse keni 512 GB RAM në server dhe e gjithë kjo përfundon në një hard disk SATA pa asnjë cache, atëherë i gjithë serveri i bazës së të dhënave nuk kthehet në një kungull, por në një kungull me një ndërfaqe SATA. Do të hasni drejtpërdrejt. Dhe asgjë nuk do t'ju shpëtojë.

Për sa i përket pikës së parë me kujtesën, janë tre gjëra që mund ta bëjnë jetën shumë të vështirë.

E para prej tyre është NUMA. NUMA është një gjë që është krijuar për të përmirësuar performancën. Në varësi të ngarkesës së punës, mund të optimizohen gjëra të ndryshme. Dhe në formën e tij të re aktuale, nuk është shumë i mirë për aplikacione të tilla si bazat e të dhënave që përdorin intensivisht buferët e përbashkët të cache-it të faqeve.

Me pak fjalë. Si mund ta dalloni nëse diçka nuk shkon me NUMA? Keni një lloj trokitjeje të pakëndshme, papritmas një CPU është mbingarkuar. Në të njëjtën kohë, ju analizoni pyetjet në PostgreSQL dhe shihni se nuk ka asgjë të ngjashme atje. Këto pyetje nuk duhet të jenë aq intensive në CPU. Ju mund ta kapni këtë për një kohë të gjatë. Është më e lehtë të përdorësh rekomandimin e saktë që në fillim se si të konfigurosh NUMA për PostgreSQL.

Çfarë po ndodh në të vërtetë? NUMA qëndron për Qasje Jo-Uniforme e Memories. Ç'kuptim ka? Ju keni një CPU, pranë tij ka memorien e tij lokale. Dhe kjo ndërlidhje memorie mund të tërheqë memorie nga CPU-të e tjera.

Nëse vraponi numactl --hardware, atëherë do të merrni një fletë kaq të madhe. Ndër të tjera do të ketë një fushë distancash. Do të ketë numra - 10-20, diçka e tillë. Këta numra nuk janë gjë tjetër veçse numri i kërcimeve për të marrë këtë memorie në distancë dhe për ta përdorur atë në nivel lokal. Në parim, një ide e mirë. Kjo përshpejton mirë performancën nën një sërë ngarkesash pune.

Tani imagjinoni që keni një CPU së pari duke u përpjekur të përdorë memorien e tij lokale, më pas duke u përpjekur të tërheqni një memorie tjetër përmes ndërlidhjes për diçka. Dhe ky CPU merr të gjithë memorien tuaj të faqes PostgreSQL - kaq, disa gigabajt. Ju merrni gjithmonë rastin më të keq, sepse në CPU zakonisht ka pak memorie në vetë atë modul. Dhe e gjithë kujtesa që shërbehet kalon nëpër këto ndërlidhje. Rezulton i ngadaltë dhe i trishtuar. Dhe procesori juaj që e shërben këtë nyje është vazhdimisht i mbingarkuar. Dhe koha e aksesit të kësaj memorie është e keqe, e ngadaltë. Kjo është situata që nuk dëshironi nëse e përdorni këtë për një bazë të dhënash.

Prandaj, një opsion më i saktë për bazën e të dhënave është që sistemi operativ Linux të mos dijë fare se çfarë po ndodh atje. Kështu që ai akseson kujtesën ashtu siç bën.

Pse eshte ajo? Duket se duhet të jetë anasjelltas. Kjo ndodh për një arsye të thjeshtë: ne kemi nevojë për shumë memorie për cache-in e faqeve - dhjetëra, qindra gigabajt.

Dhe nëse i ndamë të gjitha këto dhe i ruajmë të dhënat tona atje, atëherë fitimi nga përdorimi i cache-it do të jetë dukshëm më i madh se fitimi nga një akses kaq i ndërlikuar në memorie. Dhe kështu ne do të përfitojmë në mënyrë të pakrahasueshme në krahasim me faktin që do t'i qasemi memorjes në mënyrë më efikase duke përdorur NUMA.

Prandaj, ka dy qasje këtu për momentin, derisa të vijë e ardhmja e ndritur, dhe vetë baza e të dhënave nuk është në gjendje të kuptojë se në cilat CPU po funksionon dhe nga duhet të tërheqë diçka.

Prandaj, qasja e saktë është të çaktivizoni NUMA krejtësisht, për shembull, kur rindizni. Në shumicën e rasteve, fitimet janë të shkallës së tillë që pyetja se cila është më e mirë nuk lind fare.

Ekziston një opsion tjetër. Ne e përdorim atë më shpesh se i pari, sepse kur një klient vjen tek ne për mbështetje, rindezja e serverit është një punë e madhe për të. Ai ka një biznes atje. Dhe ata përjetojnë probleme për shkak të NUMA. Prandaj, ne përpiqemi ta çaktivizojmë atë në mënyra më pak invazive sesa rindezja, por kini kujdes të kontrolloni nëse është i çaktivizuar. Sepse, siç tregon përvoja, është mirë që ne çaktivizojmë NUMA në procesin mëmë PostgreSQL, por nuk është aspak e nevojshme që ai të funksionojë. Ne duhet të kontrollojmë dhe të shohim se ajo është fikur vërtet.

Ka një postim të mirë nga Robert Haas. Ky është një nga komisionerët PostgreSQL. Një nga zhvilluesit kryesorë të të gjitha gjilpërave të nivelit të ulët. Dhe nëse ndiqni lidhjet nga ky postim, ato përshkruajnë disa histori shumëngjyrëshe se si NUMA e bëri jetën të vështirë për njerëzit. Shikoni, studioni listën e kontrollit të administratorit të sistemit të asaj që duhet të konfigurohet në server në mënyrë që databaza jonë të funksionojë mirë. Këto cilësime duhet të shënohen dhe të kontrollohen, sepse përndryshe nuk do të jenë shumë të mira.

Ju lutemi vini re se kjo vlen për të gjitha cilësimet për të cilat do të flas. Por zakonisht bazat e të dhënave mblidhen në modalitetin master-slave për tolerancën e gabimeve. Mos harroni t'i bëni këto cilësime skllavit sepse një ditë do të keni një aksident dhe do të kaloni te skllavi dhe ai do të bëhet zot.

Në një situatë emergjente, kur gjithçka është shumë e keqe, telefoni juaj po bie vazhdimisht dhe shefi juaj vjen duke vrapuar me një shkop të madh, nuk do të keni kohë të mendoni për kontrollin. Dhe rezultatet mund të jenë mjaft katastrofike.

Pika tjetër janë faqet e mëdha. Faqet e mëdha janë të vështira për t'u testuar veçmas, dhe nuk ka kuptim ta bësh këtë, megjithëse ka standarde që mund ta bëjnë këtë. Ato janë të lehta për t'u Google.

Ç'kuptim ka? Ju keni një server jo shumë të shtrenjtë me shumë RAM, për shembull, më shumë se 30 GB. Ju nuk përdorni faqe të mëdha. Kjo do të thotë që ju patjetër keni shpenzime të larta për sa i përket përdorimit të memories. Dhe kjo shpenzime është larg nga më e këndshmja.

Pse eshte ajo? Pra, çfarë po ndodh? Sistemi operativ shpërndan memorie në copa të vogla. Është kaq i përshtatshëm, kështu ka ndodhur historikisht. Dhe nëse shkojmë në detaje, OS duhet të përkthejë adresat virtuale në ato fizike. Dhe ky proces nuk është më i thjeshti, kështu që sistemi operativ ruan rezultatin e këtij operacioni në Translation Lookaside Buffer (TLB).

Dhe meqenëse TLB është një cache, të gjitha problemet e natyrshme në cache lindin në këtë situatë. Së pari, nëse keni shumë RAM dhe është e ndarë e gjitha në copa të vogla, atëherë ky bufer bëhet shumë i madh. Dhe nëse cache është e madhe, atëherë kërkimi nëpër të është më i ngadalshëm. Pjesa e sipërme është e shëndetshme dhe vetë zë hapësirë, d.m.th. RAM-i po konsumohet nga diçka e gabuar. Kësaj radhe.

Dy - sa më shumë të rritet cache në një situatë të tillë, aq më shumë ka të ngjarë që të keni mungesë të cache. Dhe efikasiteti i këtij cache zvogëlohet me shpejtësi ndërsa madhësia e tij rritet. Prandaj, sistemet operative dolën me një qasje të thjeshtë. Është përdorur në Linux për një kohë të gjatë. Ajo u shfaq në FreeBSD jo shumë kohë më parë. Por ne po flasim për Linux. Këto janë faqe të mëdha.

Dhe këtu duhet theksuar se faqet e mëdha, si ide, fillimisht u shtynë nga komunitetet që përfshinin Oracle dhe IBM, d.m.th. prodhuesit e bazës së të dhënave menduan fuqimisht se kjo do të ishte e dobishme edhe për bazat e të dhënave.

Dhe si mund të miqësohet kjo me PostgreSQL? Së pari, faqet e mëdha duhet të aktivizohen në kernelin Linux.

Së dyti, ato duhet të specifikohen në mënyrë eksplicite nga parametri sysctl - sa janë. Numrat këtu janë nga një server i vjetër. Mund të llogarisni sa bufera të përbashkëta keni në mënyrë që faqet e mëdha të mund të vendosen atje.

Dhe nëse i gjithë serveri juaj i është dedikuar PostgreSQL, atëherë një pikënisje e mirë është të ndani ose 25% të RAM-it për buferët e përbashkët, ose 75% nëse jeni i sigurt se baza e të dhënave juaj do të përshtatet patjetër në këtë 75%. Pika e fillimit një. Dhe merrni parasysh, nëse keni 256 GB RAM, atëherë, në përputhje me rrethanat, do të keni 64 GB buferë të mëdhenj. Llogaritni përafërsisht me një diferencë - në çfarë duhet të vendoset kjo shifër.

Përpara versionit 9.2 (nëse nuk gabohem, që nga versioni 8.2), ishte e mundur të lidhesh PostgreSQL me faqe të mëdha duke përdorur një bibliotekë të palëve të treta. Dhe kjo duhet bërë gjithmonë. Së pari, ju duhet kerneli që të jetë në gjendje të shpërndajë faqet e mëdha në mënyrë korrekte. Dhe, së dyti, në mënyrë që aplikacioni që punon me to të mund t'i përdorë ato. Nuk do të përdoret vetëm në këtë mënyrë. Meqenëse PostgreSQL ndau memorie në stilin e sistemit 5, kjo mund të bëhet duke përdorur libhugetlbfs - ky është emri i plotë i bibliotekës.

Në 9.3, performanca e PostgreSQL u përmirësua kur punoni me memorie dhe metoda e ndarjes së memories së sistemit 5 u braktis. Të gjithë ishin shumë të lumtur, sepse përndryshe ju përpiqeni të ekzekutoni dy instanca PostgreSQL në një makinë, dhe ai thotë se nuk kam mjaftueshëm memorie të përbashkët. Dhe ai thotë se sysctl duhet të korrigjohet. Dhe ka një sysctl të tillë që ju duhet ende të rindizni, etj. Në përgjithësi, të gjithë ishin të lumtur. Por shpërndarja e kujtesës mmap prishi përdorimin e faqeve të mëdha. Shumica e klientëve tanë përdorin buferë të mëdhenj të përbashkët. Dhe ne rekomanduam fuqimisht të mos kalonim në 9.3, sepse shpenzimet e sipërme filluan të llogariteshin në përqindje të mira.

Por komuniteti i kushtoi vëmendje këtij problemi dhe në 9.4 ata e ripunuan shumë mirë këtë ngjarje. Dhe në 9.4 u shfaq një parametër në postgresql.conf në të cilin mund të aktivizoni provoni, aktivizoni ose çaktivizoni.

Provoni është alternativa më e sigurt. Kur PostgreSQL fillon, kur shpërndan memorie të përbashkët, ai përpiqet ta rrëmbejë këtë memorie nga faqet e mëdha. Dhe nëse nuk funksionon, atëherë kthehet në përzgjedhjen normale. Dhe nëse keni FreeBSD ose Solaris, atëherë mund ta provoni, është gjithmonë i sigurt.

Nëse aktivizohet, atëherë thjesht nuk fillon nëse nuk mund të zgjidhte nga faqet e mëdha. Këtu bëhet fjalë tashmë se kush dhe çfarë është më e bukur. Por nëse keni provuar, atëherë kontrolloni që vërtet e keni të theksuar atë që ju nevojitet, sepse ka shumë vend për gabime. Aktualisht ky funksion funksionon vetëm në Linux.

Një shënim tjetër i vogël para se të shkojmë më tej. Faqet e mëdha transparente nuk kanë të bëjnë ende me PostgreSQL. Ai nuk mund t'i përdorë ato normalisht. Dhe me faqet e mëdha transparente për një ngarkesë të tillë pune, kur nevojitet një pjesë e madhe e memories së përbashkët, përfitimet vijnë vetëm me vëllime shumë të mëdha. Nëse keni terabajt memorie, atëherë kjo mund të hyjë në lojë. Nëse po flasim për më shumë aplikacione të përditshme, kur keni 32, 64, 128, 256 GB memorie në kompjuterin tuaj, atëherë faqet e zakonshme të mëdha janë në rregull, dhe ne thjesht çaktivizojmë Transparent.

Dhe gjëja e fundit në lidhje me kujtesën nuk lidhet drejtpërdrejt me frutat, ajo mund t'ju shkatërrojë vërtet jetën. I gjithë xhiroja do të ndikohet shumë nga fakti që serveri po ndërron vazhdimisht.

Dhe kjo do të jetë shumë e pakëndshme në disa mënyra. Dhe problemi kryesor është se kernelet moderne sillen paksa ndryshe nga kernelet e vjetra Linux. Dhe kjo gjë është mjaft e pakëndshme për të shkelur, sepse kur flasim për një lloj pune me shkëmbim, ajo përfundon me ardhjen e parakohshme të vrasësit të OOM. Dhe vrasësi OOM, i cili nuk mbërriti në kohën e duhur dhe hoqi PostgreSQL, është i pakëndshëm. Të gjithë do të dinë për këtë, domethënë deri në përdoruesin e fundit.

Cfare po ndodh? Ju keni një sasi të madhe RAM atje, gjithçka funksionon mirë. Por për disa arsye serveri varet në shkëmbim dhe ngadalësohet për shkak të kësaj. Duket se ka shumë kujtesë, por kjo ndodh.

Më parë, ne këshilluam vendosjen e vm.swappiness në zero, pra çaktivizimin e shkëmbimit. Më parë, dukej se 32 GB RAM dhe buferët përkatës të përbashkët ishin një sasi e madhe. Qëllimi kryesor i shkëmbimit është që të kemi një vend ku të hedhim koren nëse biem. Dhe nuk u përmbush më veçanërisht. Dhe atëherë çfarë do të bëni me këtë kore? Kjo është një detyrë ku nuk është shumë e qartë pse nevojitet shkëmbimi, veçanërisht i një madhësie të tillë.

Por në versionet më moderne, d.m.th., të tretë të kernelit, sjellja ka ndryshuar. Dhe nëse e vendosni shkëmbimin në zero, domethënë e fikni, atëherë herët a vonë, edhe nëse ka mbetur pak RAM, një vrasës OOM do të vijë tek ju për të vrarë konsumatorët më intensivë. Sepse ai do të konsiderojë se me një ngarkesë të tillë do të na mbetet edhe pak dhe do të hidhemi jashtë, d.m.th., jo për të gozhduar procesin e sistemit, por për të ngulur poshtë diçka më pak të rëndësishme. Ky më pak i rëndësishëm do të jetë konsumatori intensiv i kujtesës së përbashkët, përkatësisht drejtori i postës. Dhe pas kësaj do të jetë mirë nëse baza nuk duhet të restaurohet.

Prandaj, tani parazgjedhja, me sa mbaj mend, shumica e shpërndarjeve janë diku rreth 6, d.m.th. në cilën pikë duhet të filloni të përdorni swap në varësi të sasisë së memories së mbetur. Tani rekomandojmë vendosjen e vm.swappiness = 1, sepse kjo praktikisht e fiket, por nuk jep të njëjtat efekte si me një vrasës OOM që erdhi papritur dhe vrau të gjithë.

Ç'pritet më tej? Kur flasim për performancën e bazave të të dhënave dhe gradualisht shkojmë drejt disqeve, të gjithë fillojnë të kapin kokën. Sepse e vërteta që disku është i ngadaltë dhe kujtesa është i shpejtë është e njohur për të gjithë që nga fëmijëria. Dhe të gjithë e dinë që baza e të dhënave do të ketë probleme me performancën e diskut.

Problemi kryesor i performancës së PostgreSQL i lidhur me pikat e kontrollit nuk ndodh sepse disku është i ngadaltë. Kjo ka shumë të ngjarë për faktin se memoria dhe gjerësia e brezit të diskut nuk janë të balancuara. Megjithatë, ato mund të mos jenë të balancuara në vende të ndryshme. PostgreSQL nuk është konfiguruar, OS nuk është konfiguruar, hardueri nuk është konfiguruar dhe pajisja është e pasaktë. Dhe ky problem nuk ndodh vetëm nëse gjithçka ndodh siç duhet, d.m.th. ose nuk ka ngarkesë, ose cilësimet dhe pajisja janë zgjedhur mirë.

Çfarë është dhe si duket? Zakonisht njerëzit që punojnë me PostgreSQL kanë hyrë në këtë çështje më shumë se një herë. Unë do të shpjegoj. Siç thashë, PostgreSQL bën periodikisht pika kontrolli për të hedhur faqet e pista në memorien e përbashkët në disk. Nëse kemi një sasi të madhe memorie të përbashkët, atëherë pika e kontrollit fillon të ketë një ndikim intensiv në disk, sepse i hedh këto faqe me fsync. Ai mbërrin në buferin e kernelit dhe shkruhet në disqe duke përdorur fsync. Dhe nëse vëllimi i këtij biznesi është i madh, atëherë mund të vërejmë një efekt të pakëndshëm, përkatësisht një përdorim shumë të madh të disqeve.

Këtu kam dy foto. Tani do të shpjegoj se çfarë është. Këta janë dy grafikë të ndërlidhur me kohën. Grafiku i parë është përdorimi i diskut. Këtu ajo arrin pothuajse 90% në këtë pikë në kohë. Nëse keni një dështim të bazës së të dhënave me disqe fizike, me një përdorim të kontrolluesit RAID në 90%, atëherë ky është një lajm i keq. Kjo do të thotë që pak më shumë dhe do të arrijë në 100 dhe I/O do të ndalojë.

Nëse keni një grup disqesh, atëherë është një histori paksa e ndryshme. Varet se si është konfiguruar, çfarë lloj grupi është, etj.

Dhe paralelisht, këtu është konfiguruar një grafik nga pamja e brendshme postgres, i cili tregon se si ndodh pika e kontrollit. Dhe ngjyra e gjelbër këtu tregon se sa buferë, këto faqe të pista, arritën në atë moment në këtë pikë kontrolli për sinkronizim. Dhe kjo është gjëja kryesore që duhet të dini këtu. Ne shohim që kemi shumë faqe këtu dhe në një moment kemi goditur tabelën, domethënë kemi shkruar dhe shkruar, këtu sistemi i diskut është dukshëm shumë i zënë. Dhe pika jonë e kontrollit ka një ndikim shumë të fortë në disk. Idealisht, situata duhet të duket më shumë kështu, dmth ne kishim më pak regjistrim këtu. Dhe mund ta rregullojmë me cilësimet në mënyrë që të vazhdojë të jetë kështu. Domethënë riciklimi është i vogël, por diku po shkruajmë diçka këtu.

Çfarë duhet bërë për të kapërcyer këtë problem? Nëse e keni ndalur IO nën bazën e të dhënave, kjo do të thotë që të gjithë përdoruesit që erdhën për të përmbushur kërkesat e tyre do të presin.

Nëse shikoni nga këndvështrimi i Linux-it, nëse keni marrë një harduer të mirë, e keni konfiguruar saktë, keni konfiguruar PostgreSQL normalisht në mënyrë që t'i bëjë këto pika kontrolli më rrallë, t'i shpërndajë ato me kalimin e kohës midis njëra-tjetrës, atëherë kaloni në parametrat e paracaktuar të Debian. Për shumicën e shpërndarjeve Linux, kjo është fotografia: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Çfarë do të thotë? Një demon i ndezur u shfaq nga kerneli 2.6. Pdglush, në varësi se kush po përdor cilin, i cili është i angazhuar në heqjen e faqeve të pista në sfond nga buferi i kernelit dhe hedhjen kur është e nevojshme të hidhen faqet e pista pa marrë parasysh çfarë, kur hedhja e sfondit nuk ndihmon.

Kur vjen sfondi? Kur 10% e totalit të RAM-it të disponueshëm në server është i zënë nga faqet e pista në buferin e kernelit, një funksion special i fshirjes thirret në sfond. Pse është sfond? Si parametër, merr parasysh sa faqe duhet të fshihen. Dhe, le të themi, ai shkruan N faqe. Dhe për një kohë kjo gjë bie në gjumë. Dhe pastaj ajo vjen përsëri dhe kopjon disa faqe të tjera.

Kjo është një histori jashtëzakonisht e thjeshtë. Problemi këtu është si me një pishinë, kur ajo derdhet në një tub, ajo derdhet në një tjetër. Pika jonë e kontrollit mbërriti dhe nëse dërgoi disa faqe të pista për t'u hedhur, atëherë gradualisht e gjithë gjëja do të zgjidhet mjeshtërisht nga bufferi i kernelit pgflush.

Nëse këto faqe të pista vazhdojnë të grumbullohen, ato grumbullohen deri në 20%, pas së cilës përparësia e OS është të fshijmë të gjithë në disk, sepse energjia do të dështojë dhe gjithçka do të jetë e keqe për ne. Ne do të humbasim këto të dhëna, për shembull.

Cili është truku? Truku është se këto parametra në botën moderne janë 20 dhe 10% e RAM-it total që është në makinë, ato janë absolutisht monstruoze për sa i përket xhiros së çdo sistemi disku që keni.

Imagjinoni që keni 128 GB RAM. 12,8 GB mbërrin në sistemin tuaj të diskut. Dhe pa marrë parasysh se çfarë cache keni atje, pavarësisht se çfarë grupi keni atje, ato nuk do të zgjasin aq gjatë.

Prandaj, ju rekomandojmë që t'i rregulloni menjëherë këto numra bazuar në aftësitë e kontrolluesit tuaj RAID. Unë menjëherë bëra një rekomandim këtu për një kontrollues që ka 512 MB cache.

Gjithçka konsiderohet shumë e thjeshtë. Mund të vendosni vm.dirty_background në bajt. Dhe këto cilësime anulojnë dy të mëparshmet. Ose raporti është si parazgjedhje, ose ato me bajt janë aktivizuar, atëherë ato me bajt do të funksionojnë. Por duke qenë se jam konsulent DBA dhe punoj me klientë të ndryshëm, përpiqem të vizatoj kashtë dhe për këtë arsye, nëse në bajt, atëherë në bajt. Askush nuk dha asnjë garanci se një administrator i mirë nuk do të shtonte më shumë memorie në server, do ta rindizte atë dhe shifra do të mbetej e njëjtë. Thjesht llogaritni këto shifra në mënyrë që gjithçka të përshtatet atje me një garanci.

Çfarë ndodh nëse nuk përshtateni? Unë kam shkruar që çdo skuqje ndalohet efektivisht, por në fakt kjo është një figurë e të folurit. Sistemi operativ ka një problem të madh - ka shumë faqe të pista, kështu që IO-ja që gjenerojnë klientët tuaj është ndalur në mënyrë efektive, d.m.th. aplikacioni ka ardhur për të dërguar një pyetje sql në bazën e të dhënave, është duke pritur. Çdo hyrje/dalje në të është e prioritetit më të ulët, sepse baza e të dhënave është e zënë nga një pikë kontrolli. Dhe kur ajo do të përfundojë është plotësisht e paqartë. Dhe kur keni arritur flushing pa sfond, kjo do të thotë që e gjithë IO juaj është e zënë prej saj. Dhe derisa të përfundojë, nuk do të bëni asgjë.

Këtu ka dy pika më të rëndësishme që janë përtej qëllimit të këtij raporti. Këto cilësime duhet të përputhen me cilësimet në postgresql.conf, pra cilësimet e pikave të kontrollit. Dhe sistemi juaj i diskut duhet të jetë i konfiguruar në mënyrë adekuate. Nëse keni një cache në një RAID, atëherë duhet të ketë një bateri. Njerëzit blejnë RAID me cache të mirë pa bateri. Nëse keni SSD në RAID, atëherë ato duhet të jenë ato të serverit, duhet të ketë kondensatorë atje. Këtu është një listë kontrolli e detajuar. Kjo lidhje përmban raportin tim se si të konfiguroni një disk të performancës në PostgreSQL. Aty janë të gjitha këto lista kontrolli.

Çfarë tjetër mund ta bëjë jetën shumë të vështirë? Këto janë dy parametra. Janë relativisht të reja. Si parazgjedhje, ato mund të përfshihen në aplikacione të ndryshme. Dhe ata mund ta bëjnë jetën po aq të vështirë nëse janë ndezur gabimisht.

Ka dy gjëra relativisht të reja. Ata tashmë janë shfaqur në bërthamat e treta. Ky është sched_migration_cost në nanosekonda dhe sched_autogroup_enabled, i cili është një si parazgjedhje.

Dhe si ta shkatërrojnë jetën tuaj? Çfarë është sched_migration_cost? Në Linux, planifikuesi mund të migrojë një proces nga një CPU në tjetrin. Dhe për PostgreSQL, e cila ekzekuton pyetje, migrimi në një CPU tjetër është plotësisht i paqartë. Nga pikëpamja e sistemit operativ, kur kaloni dritaret midis openoffice dhe terminalit, kjo mund të jetë e mirë, por për një bazë të dhënash kjo është shumë e keqe. Prandaj, një politikë e arsyeshme është të vendoset migration_cost në një vlerë të madhe, të paktën disa mijëra nanosekonda.

Çfarë do të thotë kjo për planifikuesin? Do të konsiderohet se gjatë kësaj kohe procesi është ende i nxehtë. Kjo do të thotë, nëse keni një transaksion afatgjatë që ka bërë diçka për një kohë të gjatë, planifikuesi do ta kuptojë këtë. Ai do të supozojë se derisa të kalojë ky afat, nuk ka nevojë të migrojë këtë proces askund. Nëse në të njëjtën kohë procesi bën diçka, atëherë ai nuk do të migrohet askund, ai do të funksionojë në heshtje në CPU që i është caktuar. Dhe rezultati është i shkëlqyer.

Pika e dytë është autogrupi. Ekziston një ide e mirë për ngarkesa specifike të punës që nuk lidhen me bazat e të dhënave moderne - kjo është për të grupuar proceset sipas terminalit virtual nga i cili nisen. Kjo është e përshtatshme për disa detyra. Në praktikë, PostgreSQL është një sistem me shumë procese me një prefork që shkon nga një terminal i vetëm. Ju keni një shkrimtar bllokimi, pikë kontrolli dhe të gjitha kërkesat e klientit tuaj do të grupohen në një planifikues, për CPU. Dhe ata do të presin atje njëzëri që ai të jetë i lirë, në mënyrë që të ndërhyjnë me njëri-tjetrin dhe ta mbajnë atë të zënë më gjatë. Kjo është një histori që është krejtësisht e panevojshme në rastin e një ngarkese të tillë dhe për këtë arsye duhet të fiket.

Kolegu im Alexey Lesovsky bëri teste me një pgbench të thjeshtë, ku rriti migration_cost me një renditje të madhësisë dhe çaktivizoi autogrupin. Diferenca në harduerin e keq ishte pothuajse 10%. Ekziston një diskutim në listën e postimeve të postgres ku njerëzit japin rezultate të ndryshimeve të ngjashme në shpejtësinë e pyetjeve ndikoi 50%. Ka shumë histori të tilla.

Dhe së fundi, për politikën e kursimit të energjisë. E mira është se Linux tani mund të përdoret në një laptop. Dhe supozohet se do të përdorë baterinë mirë. Por befas rezulton se kjo mund të ndodhë edhe në server.

Për më tepër, nëse merrni me qira serverë nga ndonjë hoster, atëherë hostet "të mirë" nuk kujdesen që të keni performancë më të mirë. Detyra e tyre është të sigurojnë që hekuri i tyre të përdoret në mënyrë sa më efikase. Prandaj, si parazgjedhje ata mund të aktivizojnë modalitetin e kursimit të energjisë së laptopit në sistemin operativ.

Nëse e përdorni këtë material në një server me një bazë të dhënash nën ngarkesë të madhe, atëherë zgjedhja juaj është acpi_cpufreq + permormance. Edhe me kërkesë do të ketë probleme.

Intel_pstate është një drejtues paksa i ndryshëm. Dhe tani preferenca i jepet këtij, pasi është më vonë dhe funksionon më mirë.

Dhe, në përputhje me rrethanat, guvernatori është vetëm performanca. Ondemand, powersave dhe gjithçka tjetër nuk kanë të bëjnë me ju.

Rezultatet e analizës së shpjegimit të PostgreSQL mund të ndryshojnë me disa renditje të madhësisë nëse aktivizoni kursimin e energjisë, sepse praktikisht CPU-ja nën bazën tuaj të të dhënave do të funksionojë në një mënyrë krejtësisht të paparashikueshme.

Këto artikuj mund të përfshihen si parazgjedhje. Shikoni me kujdes për të parë nëse e kanë aktivizuar si parazgjedhje. Ky mund të jetë një problem vërtet i madh.

Dhe në fund, doja të falenderoja djemtë nga ekipi ynë i PosgreSQL-Consulting DBA, domethënë Max Boguk dhe Alexey Lesovsky, të cilët po bëjnë përparim në këtë çështje çdo ditë. Dhe ne përpiqemi të bëjmë më të mirën që mundemi për klientët tanë në mënyrë që gjithçka të funksionojë për ta. Është si me udhëzimet e sigurisë së aviacionit. Gjithçka këtu është e shkruar me gjak. Secila prej këtyre arra gjendet në procesin e një lloj problemi. Jam i lumtur t'i ndaj me ju.

pyetje:

Faleminderit! Nëse, për shembull, një kompani dëshiron të kursejë para dhe të vendosë bazën e të dhënave dhe logjikën e aplikacionit në një server, ose nëse kompania ndjek trendin e modës të arkitekturave të mikroserviseve, në të cilat PostgreSQL funksionon në një kontejner. Cili është truku? Sysctl do të ndikojë në të gjithë kernelin globalisht. Nuk kam dëgjuar që sysctls të virtualizohen disi në mënyrë që të punojnë veçmas në një kontejner. Ekziston vetëm një cgroup dhe ka vetëm një pjesë të kontrollit atje. Si mund të jetoni me këtë? Apo nëse dëshironi performancë, atëherë ekzekutoni PostgreSQL në një server të veçantë harduerësh dhe akordoni atë?

Ne iu përgjigjëm pyetjes suaj në rreth tre mënyra. Nëse nuk po flasim për një server harduerësh që mund të akordohet, etj., Atëherë pushoni, gjithçka do të funksionojë mirë pa këto cilësime. Nëse keni një ngarkesë të tillë që ju duhet të bëni këto cilësime, atëherë do të vini në serverin e hekurit më herët sesa në këto cilësime.

Cili është problemi? Nëse kjo është një makinë virtuale, atëherë ka shumë të ngjarë që do të keni shumë probleme, për shembull, me faktin se në shumicën e makinave virtuale vonesa e diskut është mjaft e paqëndrueshme. Edhe nëse xhiroja e diskut është e mirë, atëherë një transaksion I/O i dështuar që nuk ndikon shumë në xhiron mesatare që ka ndodhur në kohën e pikës së kontrollit ose në momentin e shkrimit në WAL, atëherë baza e të dhënave do të vuajë shumë nga kjo. Dhe këtë do ta vini re përpara se të hasni në këto probleme.

Nëse keni NGINX në të njëjtin server, do të keni gjithashtu të njëjtin problem. Ai do të luftojë për kujtesën e përbashkët. Dhe nuk do të arrini te problemet e përshkruara këtu.

Por nga ana tjetër, disa nga këto parametra do të jenë ende të rëndësishme për ju. Për shembull, vendosni dirty_ratio me sysctl në mënyrë që të mos jetë aq i çmendur - në çdo rast, kjo do të ndihmojë. Në një mënyrë apo tjetër, do të keni ndërveprim me diskun. Dhe do të jetë sipas modelit të gabuar. Ky është përgjithësisht një parazgjedhje për parametrat që tregova. Dhe në çdo rast është më mirë t'i ndryshoni ato.

Por mund të ketë probleme me NUMA. VmWare, për shembull, funksionon mirë me NUMA me cilësimet saktësisht të kundërta. Dhe këtu duhet të zgjidhni - një server hekuri ose jo hekuri.

Unë kam një pyetje në lidhje me Amazon AWS. Ata kanë imazhe të para-konfiguruara. Njëri prej tyre quhet Amazon RDS. A ka ndonjë cilësim personal për sistemin e tyre operativ?

Aty ka cilësime, por janë cilësime të ndryshme. Këtu ne konfigurojmë sistemin operativ për sa i përket mënyrës sesi baza e të dhënave do ta përdorë këtë gjë. Dhe ka parametra që përcaktojnë se ku duhet të shkojmë tani, siç është formimi. Kjo do të thotë, ne kemi nevojë për kaq shumë burime, tani do t'i hamë ato. Pas kësaj, Amazon RDS shtrëngon këto burime dhe performanca bie atje. Ka histori individuale se si njerëzit kanë filluar të ngatërrohen me këtë çështje. Ndonjëherë edhe me mjaft sukses. Por kjo nuk ka të bëjë me cilësimet e OS. Është si të hakerosh renë. Kjo është një histori tjetër.

Pse faqet e mëdha transparente nuk kanë asnjë efekt në krahasim me TLB të madhe?

Mos jep. Kjo mund të shpjegohet në shumë mënyra. Por në fakt ata thjesht nuk e japin atë. Cila është historia e PostgreSQL? Në fillimin, ai shpërndan një pjesë të madhe të memories së përbashkët. Nëse ato janë transparente apo jo, është krejtësisht e parëndësishme. Fakti që ata bien në sy në fillim shpjegon gjithçka. Dhe nëse ka shumë memorie dhe ju duhet të rindërtoni segmentin shared_memory, atëherë faqet e mëdha transparente do të jenë të rëndësishme. Në PostgreSQL, ai thjesht ndahet në një pjesë të madhe në fillim dhe kaq, dhe më pas asgjë e veçantë nuk ndodh atje. Sigurisht, mund ta përdorni, por ekziston mundësia që shared_memory të prishet kur rishpërndahet diçka. PostgreSQL nuk di për këtë.

Burimi: www.habr.com