Rregullimi i Linux për të përmirësuar performancën e PostgreSQL. Ilya Kosmodemyansky

Shpjegimi i raportit të vitit 2015 nga Ilya Kosmodemyansky "Rregullimi i Linux për të përmirësuar performancën e PostgreSQL"

Kujdes: Dua të theksoj se ky raport është datuar në nëntor të vitit 2015 — kanë kaluar më shumë se 4 vjet dhe ka kaluar shumë kohë. Versioni i trajtuar në raportin është 9.4, i cili tashmë nuk mbështetet. Gjatë këtyre 4 viteve janë lëshuar 5 versione të reja të PostgreSQL dhe 15 versione të bërthamës së Linuxit. Nëse do të rishkruajmë këto pika, në fund do të kemi një raport tjetër. Por këtu është trajtuar rregullimi themelor i Linux për PostgreSQL, i cili mbetet aktual edhe tani.

Më quajnë Ilya Kosmodemyansky. Punoj në kompaninë PostgreSQL-Consulting. Tani do të flas pak për atë se çfarë të bëjmë me Linux në lidhje me bazat e të dhënave dhe në veçanti me PostgreSQL, sepse parimet janë mjaft të ngjashme.

Për çfarë do të flasim? Nëse komunikoni me PostgreSQL, në një farë mase duhet të jeni administrator UNIX. Çfarë do të thotë kjo? Nëse e krahasojmë Oracle dhe PostgreSQL, në Oracle duhet të jeni 80 % DBA dhe 20 % administrator Linux.

Me PostgreSQL është pak më e komplikuar. Me PostgreSQL duhet të keni një njohuri shumë më të mirë se si funksionon Linux. Dhe për këtë duhet të ndjekim zhvillimet, sepse kohët e fundit gjithçka po azhurnohet në mënyrë të konsiderueshme. Po lëshohen bërthama të reja, po shfaqen funksionalitete të reja, performanca përmirësohet, etj.

Pse flasim për Linux? Jo sepse jemi në konferencën Linux në St. Petersburg, por sepse në kushte moderne një nga sistemet operative më të arsyeshme për përdorimin me bazat e të dhënave, dhe veçanërisht me PostgreSQL, është Linux. Sepse FreeBSD, për fat të keq, po zhvillohet në një drejtim shumë të çuditshëm. Do të ketë probleme si me performancën, ashtu edhe me shumë gjëra të tjera. Performanca e PostgreSQL në Windows – është një temë e veçantë e njohur, që ndikon në faktin se Windows nuk ka atë memorie të ndarë si në UNIX, dhe PostgreSQL është shumë e lidhur me këtë, sepse është një sistem me shumë procese.

Dhe egzotika si Solaris, mendoj se intereson më pak njerëz, prandaj le të vazhdojmë.

Në një distribucion modern të Linux, ka më shumë se 1,000 parametra syctl, në varësi të mënyrës se si është ndërtuar bërthama. Gjithashtu, nëse shikojmë në disa rregulla, ka shumë mënyra për të bërë rregullime. Ka parametra të sistemeve të skedarëve, si t'i montoni ato. Nëse ka pyetje si t'i aktivizoni: çfarë të aktivizoni në BIOS, si të konfiguroni harduerin, etj.

Ky është një volum shumë i madh, për të cilin mund të flitet për disa ditë dhe jo për një raport të shkurtër, por tani do të ndalem në gjëra të rëndësishme, si të shmangni ato ngërçet, të cilat me siguri do të pengojnë shkëlqimin e bazës së të dhënave në Linux, nëse nuk i korrigjoni. Gjithashtu, një pikë e rëndësishme është se shumë nga parametrat e default janë të nisur në konfigurime që nuk janë të përshtatshme për bazën e të dhënave. Pra, në mënyrë të parazgjedhur do të funksionojë keq ose nuk do të funksionojë fare.

Cilat janë objektivat tradicionale të rregullimit në Linux? Mendoj se pasi të gjithë kanë të bëjnë me administrimin e Linux, atëherë nuk ka nevojë të shpjegojmë shumë se çfarë janë objektivat.

Mund të rregullohet:

• CPU.
• Memoria.
• Ruajtja.
• Të tjera. Këtë do ta diskutojmë në fund si një përfundim. Edhe, për shembull, parametrat si politika e kursimit të energjisë mund të ndikojnë në performancë në mënyra shumë të papritura dhe jo shumë të këndshme.

Cila është specifika e PostgreSQL dhe e bazës së të dhënave përgjithësisht? Problemi është se nuk mund të rregulloni ndonjë pjesë të veçantë dhe të shikoni nëse performanca është përmirësuar ndjeshëm.

Po, ka pjesë të tilla, por baza e të dhënave është një gjë komplekse. Ajo ka ndërveprim me të gjitha burimet që ka serveri dhe preferon të bashkëpunojë në mënyrën më të plotë. Nëse shikoni rekomandimet moderne të Oracle për përdorimin e sistemit operativ, do të jetë si në anekdotën për atë astronautin mongol – të ushqesh qenin dhe të mos prekje asgjë. Le të japim të gjitha burimet bazës së të dhënave, ajo do të rregullojë gjithçka vetë.

Në parim, deri diku situata me PostgreSQL është e ngjashme. Diferenca është se baza nuk mund të marrë të gjitha burimet vetë, pra ndonjëherë duhet të rregullohen këto gjëra në nivelin e Linux.

Ideja kryesore është të mos përzgjidhni një objektiv të vetëm dhe të filloni ta rregulloni atë, për shembull, memorie, CPU ose diçka të ngjashme, por të analizoni ngarkesën e punës dhe të përpiqeni të përmirësoni maksimalisht kapacitetin për të siguruar që ngarkesa që programuesit e sjellin tek ne, përfshirë dhe përdoruesit tanë, kalon sa më efektivisht përmes bazës sonë të të dhënave.

Ja është një imazh për të shpjeguar se çfarë është kjo. Ka një bufer të OS Linux, ka memorie të ndarë dhe ka buferë të ndarë të PostgreSQL. PostgreSQL, ndryshe nga Oracle, funksionon direkt vetëm përmes buferit të bërthamës, do të thotë se për të kaluar një faqe nga disku në memorien e saj të ndarë, ajo duhet të kalojë përmes buferit të bërthamës dhe përmbi të njëjtën situatë.

Nën këtë sistem jetojnë diskët. E kam vizatuar si diskë. Në të vërtetë, aty mund të ketë një kontrollues RAID, etj.

Dhe ky hyrje-dalje ndodh përmes kësaj.

PostgreSQL është një bazë e dhënash klasike. Brenda saj ka faqe. Të gjithë hyrje-daljet ndodhin përmes faqeve. Ne ngremë blloqe në memorie përmes faqeve. Dhe nëse nuk ka ndodhur asgjë, ne vetëm i kemi lexuar, ato gradualisht përfundojnë nga ky kesh, nga buferët e ndarë dhe rikthehen në disk.

Nëse ndryshojmë diçka, e gjithë faqja shënohet si e ndotur. Unë i kam shënuar ato këtu me ngjyrën blu. Dhe kjo do të thotë se kjo faqe duhet të sinkronizohet me ruajtjen e bllokëve. Pra, kur e bëmë të ndotur, bëmë një regjistrim në WAL. Dhe në një moment të shkëlqyer erdhi një fenomen i quajtur checkpoint. Dhe në këtë log u regjistrua informacioni se ai erdhi. Kjo do të thotë se të gjitha faqet e ndotura që ishin këtu në atë moment në këto buferë të ndarë u sinkronizuan me diskun e ruajtjes përmes fsync përmes buferit të bërthamës.

Përse bëhet kjo? Nëse na mungon energjia, nuk do ta kemi situatën që të gjitha të dhënat humbin. Memoria e qëndrueshme, për të cilën na kanë treguar të gjithë, është ende teorike në bazat e të dhënave – kjo është e ardhmja e ndritur, në të cilën ne sigurisht që synojmë dhe na pëlqen, por për momentin ato ende jetojnë 20 vjet mbrapa. Dhe sigurisht, për këtë duhet të vigjiloni.

Dhe detyra e maksimalizimit të kapacitetit është që të optimizohet në të gjitha këto hapa, që të gjithë të funksionojnë shpejt. Memoria e ndarë është kryesisht kesh i faqeve. Në PostgreSQL dërgojmë një kërkesë select diçka aty, ai nxjerr të dhënat nga disku. Ato kalojnë në buferët e ndarë. Prandaj, për të funksionuar më mirë, duhet të ketë shumë memorie.

Për të siguruar që e gjithë kjo të funksionojë mirë dhe shpejt, ju nevojitet të konfiguroni saktë në çdo hap të sistemit operativ. Dhe të zgjidhni pajisjet në mënyrë të balancuar, sepse nëse ndonjë vend do të ketë disbalancë, mund të keni shumë memorie, por do të shërbehet me një shpejtësi të pamjaftueshme.

Dhe do të kalojmë në secilin nga këto pika.

Për të siguruar që këto faqe të udhëtojnë më shpejt, duhet të arrihet e ardhmja:

• Së pari, duhen punuar më efikas me memorien.
• Së dyti, duhet të jetë më efikase kalimi, kur faqet kalojnë nga memoria në disk.
• Dhe, së treti, duhen të jenë disqe të mira.

Nëse keni 512 GB RAM në serveri dhe e gjithë kjo përfundon në një disk mekanik SATA pa asnjë kesh, gjithmonë serveri i bazës së të dhënave do të shndërrohet në një kungull, madje me një ndërfaqe SATA. Do të jeni të detyruar ta përballoni përballë, dhe asgjë nuk do t'ju shpëtojë.

Sa i përket pikës së parë me memorien, ka tre gjëra që mund të komplikohet jetën.

E para është NUMA. NUMA është gjë që është bërë për të përmirësuar performancën. Në varësi të ngarkesës mund të optimizoni gjëra të ndryshme. Dhe në formën e saj të tanishme, ajo nuk është shumë e favorshme për aplikacione të tillë si baza e të dhënave, që përdorin intensitet të lartë të buferëve të ndarë të keshit të faqeve.

Në dy fjalë. Si ta kuptoni se diçka nuk është në rregull me NUMA? Keni një zhurmë të padëshiruar, papritur një CPU është i mbingarkuar. Në të njëjtën kohë analizoni kërkesat në PostgreSQL dhe shihni se nuk ka asgjë të tillë që ndodhin. Këto kërkesa nuk duhet të konsumojnë kaq fuqishëm CPU. Është e lehtë ta kapni këtë për një kohë të gjatë. Më mirë është të përdorni rekomandimin e duhur që nga fillimi se si të konfiguroni NUMA për PostgreSQL.

Çfarë ndodh në të vërtetë? NUMA do të thotë Non-Uniform Memory Access. Qëllimi i saj është? Keni një CPU, pranë tij është memoria e tij lokale. Dhe kjo memorie e ndër lidhjeve mund të tërheqë memorien nga CPU të tjera.

Nëse e aktivizoni numactl --hardware, do t'ju dalë një fletë e 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ë asgjë tjetër veçse numri i hops për të marrë atë memorie të largët dhe për ta përdorur lokal. Në thelb, ide e mirë. Kjo përmirëson performancën në disa ngarkesa.

Imagjinoni se keni një CPU që fillimisht përpiqet të përdorë memorjen e tij lokale, pastaj përpiqet të tërheqë memorje tjetër përmes interkonektivës për ndonjë qëllim. Dhe në këtë CPU përfundon gjithë cache-in tuaj të faqeve PostgreSQL – të gjitha, disa gigabajt. Ju gjithmonë merrni rasten më të keq, sepse zakonisht ka pak në këtë moduli të memorjes. Dhe e gjithë memorja që shërbehet kalon përmes këtyre interkonektivëve. Kështu që ndodhet ngadalë dhe e trishtuar. Dhe keni një procesor që shërben këtë nyje, i ngarkuar vazhdimisht. Dhe koha e aksesit të kësaj memorjeje është e dobët, e ngadalshme. Ky është një situatë që nuk doni, nëse e përdorni këtë për një bazë të dhënash.

Prandaj, një opsion më i drejtë për një bazë të dhënash është që sistemi operativ Linux të mos dijë fare se çfarë po ndodh. Që ai të aksesojë memorjen ashtu siç do.

Pse kështu? Do të dukej se duhet të ishte e kundërta. Kjo ndodh për një arsye të thjeshtë, që ne kemi nevojë për shumë memorje për cache-in e faqeve – dhjetëra, qindra gigabajt.

Dhe nëse i kemi ndarë të gjitha këto dhe i kemi cached të dhënat tona atje, përfitimi nga përdorimi i cache do të jetë ndjeshëm më i madh se sa përfitimi nga ky qasje i zgjuar në memorje. Dhe në këtë mënyrë do të fitojmë në mënyrë të paqenë krahasuar me atë që do të ishim më eficient në qasjen në memorje duke përdorur NUMA.

Prandaj, ka dy qasje për momentin, derisa e ardhmja e ndritur të ketë ardhur dhe baza e dhënash të dijë vetë në cilat CPU ajo punon dhe nga ku i duhet të tërheqë diçka.

Prandaj, qasja e duhur është që të çaktivizohet NUMA, për shembull, gjatë rinisjes. Në shumicën e rasteve, përfitimet janë kaq të mëdha sa që nuk ka asnjë pyetje se si është më mirë.

Ka një opsion tjetër. Ne e përdorim atë më shpesh se sa të parin, sepse kur një klient vjen për mbështetje, rinisja e serverit është një çështje e madhe. Ai ka biznes që funksionon. Dhe ai përballet me probleme për shkak të NUMA. Prandaj ne përpiqemi ta çaktivizojmë në mënyra më pak invazive se sa rinisja, por këtu duhet të kontrolloni se çfarë është çaktivizuar. Sepse, siç e tregon përvoja, çaktivizimi i NUMA për procesin prindor të PostgreSQL është i mirë, por nuk është domosdoshmërisht se do të funksionojë. Duhet ta kontrolloni dhe shikoni se a është çaktivizuar me të vërtetë.

Ka një post të mirë nga Robert Haas. Ai është një nga kontribuesit e PostgreSQL. Një nga zhvilluesit kryesorë të të gjitha derivateve të ulëta. Dhe nëse ndiheni përmes lidhjeve nga ky post, atje përshkruhen disa histori interesante për mënyrën si NUMA ka komplikuar jetën e njerëzve. Shikoni, studioni check-list-in për administratorin e sistemeve, çfarë duhet të mundësohet në server për që baza e të dhënave të funksionojë mirë. Këto konfigurime duhet të shkruhen dhe kontrollohen, sepse ndryshe nuk do të jetë shumë mirë.

Vërej se kjo përfshin të gjitha konfigurimet për të cilat do të flas. Por zakonisht bazat e të dhënave mblidhen në modin master-slave për qëndrueshmëri. Mos haroni të bëni këto konfigurime në slave, sepse një ditë do t'ju ndodhë një katastrofë dhe do të kaloni në slave, dhe ai do të bëhet master.

Në një situatë katastrofike, kur gjithçka është shumë e keqe, telefoni juaj do të thërrasë vazhdimisht dhe shefi do të vijë me një shkop të madh, nuk do të keni kohë të mendoni për të kontrolluar. Dhe rezultatet mund të jenë mjaft tragjike.

Moment tjetër – janë huge pages. Huge pages janë të vështira për t'u testuar veçmas, dhe nuk ka kuptim për këtë, megjithëse ka benchmarke që dinë ta bëjnë. Ato janë të lehta për t'u gjetur në internet.

Çfarë ka kuptim? Keni një server jo shumë të shtrenjtë, në të cilin ka shumë memorje operative, për shembull, më shumë se 30 GB. Nuk jeni duke përdorur huge pages. Kjo do të thotë që patjetër ka overhead nga përdorimi i memorjes. Dhe ky overhead nuk është aspak i këndshëm.

Pse kështu? Çfarë ndodh? Sistemi operativ e ndan memorjen në copëza të vogla. Aq e përshtatshme, aq historikisht është vendosur. Dhe nëse shtojmë hollësira, OS duhet të translate adresat virtuale në ato fizike. Dhe ky proces nuk është më i lehti, prandaj OS e ruan rezultatin e kësaj operacioneje në Translation Lookaside Buffer (TLB).

Dhe për sa kohë TLB – është një cache, në këtë situatë ndodhin të gjitha problemet e njohura të cache-it. Së pari, nëse keni shumë memorje operative dhe e gjithë ajo është e ndarë në copëza të vogla, atëherë ky buffer bëhet shumë i madh. Dhe nëse cache-i është i madh, kërkimi në të bëhet më i ngadalshëm. Overhead-i është i shëndoshë dhe ai vetë konsumon vend, dmth. memorja operative konsumon diçka të papërshtatshme. Kjo është njëra nga arsyet.

Dy – sa më shumë që rritet cache në një situatë të tillë, aq më shumë rritet mundësia që të keni cache misses. Efikasiteti i këtij cache bie shumë shpejt me rritjen e madhësisë së tij. Prandaj, në sistemet operative është ideuar një qasje e thjeshtë. Në Linux, kjo është e njohur prej kohësh. Në FreeBSD, kjo u shfaq jo shumë kohë më parë. Por ne po flasim për Linux. Këto janë huge pages.

Dhe këtu duhet të theksohet se huge pages, si ide, fillimisht u promovua nga komunitetet që përfshinin Oracle dhe IBM, dmth. prodhuesit e bazave të të dhënave mendojnë se kjo do të jetë e dobishme, përfshirë për bazat e të dhënave.

Dhe si ta lidhim këtë me PostgreSQL? Së pari, në bërthamën e Linux-it duhet të aktivizohen huge pages.

Së dyti, ato duhet të përcaktohen qartë me parametrin sysctl - sa prej tyre do të ketë. Numrat këtu janë nga ndonjë server i vjetër. Mund të llogaritni se sa afërsisht keni shared buffers, në mënyrë që huge pages të përshtaten atje.

Dhe nëse e gjithë serveri është dedikuar për PostgreSQL, një pikë e mirë fillestare është të ndajmë ose 25% të memorie RAM për shared buffers, ose 75%, nëse jeni të sigurt se në këtë 75% baza juaj e të dhënave do të përshtatet me siguri. Një pikë fillestare e parë. Dhe llogaritni, nëse keni 256 GB memorie RAM, atëherë, përkatësisht, do të keni 64 GB të shared buffers. Llogaritni pak me ndonjë rezervë – se çfarë duhet të jetë ky numër.

Derisa të arrijë versionin 9.2 (nese nuk gaboj, që nga versioni 8.2) mund të lidhni PostgreSQL me huge pages përmes një biblioteke të jashtme. Dhe kjo gjithmonë duhet bërë. Së pari, ju duhet që bërthama të dijë si të alokojë saktësisht huge pages. Dhe, së dyti, aplikacioni që punon me to duhet të jetë në gjendje t'i përdorë ato. Ajo nuk do t'i përdorë thjesht për asgjë. Duke qenë se PostgreSQL alokonte memorie në stilin e sistemit 5, kjo mund të bëhej përmes libhugetlbfs - ky është emri i plotë i bibliotekës.

Në versionin 9.3, u përmirësua performanca e PostgreSQL-it në punën me memorien dhe u hoq metoda e alokimit të memories së sistemit 5. Të gjithë u gëzuan shumë, sepse ndryshe, kur përpiqesh të nisësh dy instanca PostgreSQL në një makinë, ai thotë se nuk kam mjaftueshëm memorje të ndarë. Dhe thotë se duhet të rregullohet sysctl. Dhe aty është një sysctl të tillë, që duhet të rivendosesh dhe kështu me radhë. Përmbledhtazi, të gjithë u gëzuan. Por alokimi i memories mmap prishi përdorimin e huge pages. Shumica e klientëve tanë përdorin buffers të mëdha të ndara. Dhe ne e rekomanduam me këmbëngulje që të mos kalojnë në 9.3, sepse aty overhead-i fillonte të ishte në përqindje të mira.

Por, komuniteti i vuri re këtë problem dhe në versionin 9.4 e përmirësuan shumë këtë proces. Dhe në 9.4 u shfaq një parameter në postgresql.conf, ku mund të aktivizoni try, on ose off.

Try – është parametri më i sigurt. Kur PostgreSQL fillon, kur alokon memorjen e ndarë, ai përpiqet të marrë këtë memorje nga huge pages. Dhe nëse nuk arrin, atëherë rikthehet në alokim të zakonshëm. Dhe nëse keni FreeBSD ose Solaris, atëherë mund ta vendosni try, kjo është gjithmonë e sigurt.

Nëse është on, atëherë ai thjesht nuk nis nëse nuk ka arritur të alokojë nga huge pages. Këtu tashmë – kush e preferon çfarë më shumë. Por nëse keni vendosur try, atëherë kontrolloni që vërtet të keni marrë atë që duhet alokuar, sepse ka shumë hapësirë për gabime. Tani ky funksionalitet punon vetëm në Linux.

Një vërejtje e vogël, para se të vazhdojmë më tej. Transparent huge pages - nuk ka të bëjë me PostgreSQL derimë. Ai nuk mund ta përdorë normalisht. Dhe me Transparent huge pages, për një ngarkesë të tillë pune, kur nevojitet një copë e madhe e memorjes të ndarë, përfitimet ndodhin vetëm nëse volumet janë shumë të mëdha. Nëse keni terabajt të memories, atëherë kjo mund të ketë rëndësi. Nëse flasim për aplikacione më të zakonshme, kur keni 32, 64, 128, 256 GB memorie në makinë, atëherë huge pages e zakonshme është e mirë, dhe Transparent thjesht e ndalojmë.

Dhe gjëja e fundit në lidhje me memorien, që nuk është drejtpërdrejt e lidhur me throughput, mund të prishë shumë jetën tuaj. E gjithë kapaciteti i kalimit do të vuajë për shkak se serveri vazhdimisht swap-on.

Dhe kjo do të jetë shumë e pakëndshme në disa momente. Dhe e keqja kryesore është se në bërthamat moderne, sjellja pak a shumë ndryshon nga bërthamat më të vjetra të Linux-it. Dhe kjo është një gjë, mbi të cilën është mjaft e pakëndshme të qëndrosh, sepse, kur flasim për ndonjë punë me swap-in, përfundon me një ardhje të papërshtatshme të OOM-killer. Dhe OOM-killer, i cili nuk arriti në kohë dhe ndaloi PostgreSQL-in, është e pakëndshme. Këtë do ta dinë të gjithë, dmth. deri te përdoruesi i fundit.

Çfarë ndodh? Ju keni një sasi të madhe të memorjes RAM, gjithçka funksionon mirë. Por për një arsye, serveri ngec në swap dhe ngadalëson për këtë shkak. Duket se ka shumë memorie, por ndodhi kështu.

Më parë ne rekomandonim të vendosnim vm.swappiness në zero, domethënë, të çaktivizonim swap-in. Ishte dukur se 32 GB memorie RAM dhe bufferët e ndarë të ngjashëm ishin një sasi e madhe. Qëllimi kryesor i swap-it është të ketë një vend për të hedhur një proces, nëse ne dështojmë. Dhe ndodhte që ky funksion nuk po realizohej shumë. Por çfarë do të bësh me atë proces më pas? Ky është një problem ku nuk është shumë e qartë pse ne kemi nevojë për swap, sidomos një të tillë në këtë madhësi.

Por në versionet më moderne, domethënë, në versionet e treta të bërthamës, sjellja ka ndryshuar. Dhe nëse vendosni swap-in në zero, domethënë, ta çaktivizoni, për shumë shpejt, edhe kur keni akoma një sasi të caktuar memorie operativ, do të vijë OOM-killer-i për të vrarë konsumatorët më intensivë. Sepse ai do të mendojë se me këtë ngarkesë na ka mbetur pak dhe do të dalim, dmth të mos vrasim procesin sistemor, por të ulim diçka më pak të rëndësishme. Kjo gjë më pak e rëndësishme do të jetë konsumatori intensiv i memories së ndarë, konkretisht postmaster. Pas kësaj, do të jetë mirë nëse nuk do të duhet të rikuperojmë bazën.

Prandaj tani defolt, sa mbaj mend, shumica e distribucioneve janë diku 6, domethënë, në çfarë momenti të fillojmë të përdorim swap-in në varësi të asaj që ka mbetur nga memoria. Tani ne rekomandojmë të vendosim vm.swappiness = 1, sepse kjo në praktikë e çaktivizon atë, por nuk shkakton efekte të tilla si me OOM-killer-in që vjen papritur dhe gjithë kjo e vret.

Çfarë ndodh më pas? Kur flasim për performancën e bazave të të dhënave dhe gradualisht arrijmë te disqet, të gjithë fillojnë të shqetësohen. Sepse e vërteta se disku është i ngadalshëm dhe memoria është e shpejtë është e njohur për të gjithë nga fëmijëria. Çdo kush e di se do të ketë probleme me performancën e diskut në bazën e të dhënave.

Problemi kryesor me performancën e PostgreSQL-it, i lidhur me rritjet në checkpoints, nuk ndodh për shkak se disku është i ngadalshëm. Kjo është më shumë për shkak se kapaciteti i memories dhe disqet nuk janë të balancuar. Për më tepër, ato mund të mos jenë të balancuara në vende të ndryshme. PostgreSQL nuk është i konfigurueshëm, OS nuk është konfigurueshëm, hardueri nuk është i konfigurueshëm dhe hardueri është i gabuar. Dhe ky problem nuk ndodh vetëm nëse gjithçka po shkon siç duhet, dmth ose nuk ka ngarkesa, ose konfigurimet dhe hardueri janë të përshtatura mirë.

Çfarë është kjo dhe si duket? Zakonisht njerëzit që punojnë me PostgreSQL kanë kaluar shpesh në këtë situatë. Ta sqaroj. Siç e thashë, PostgreSQL herë pas here bën checkpoints, për të hedhur faqet e ndotura në memorie në disk. Nëse kemi një sasi të madhe të memories së ndarë, atëherë checkpoint fillon të ndikojë fuqishëm në disk, sepse transferon këto faqe me fsync. Ai arrin në buffer-in e kernel-it dhe shkruhet në disqe me anë të fsync. Dhe nëse sasia e këtij procesi është e madhe, ne mund të shohim një efekt të pakëndshëm, dmth një shfrytëzim shumë të madh të disqeve.

Këtu kam dy figura. Do t'i shpjegoj se çfarë janë. Këto janë dy grafika të korrelacionuara në kohë. Grafiku i parë është shfrytëzimi i diskut. Aty rritet pothuajse deri në 90% në atë moment. Nëse keni një bazë të dhënash me disqe fizike, me një kontrollues RAID dhe shfrytëzimi është deri në 90%, atëherë kjo është lajm i keq. Kjo do të thotë se pak më vonë do të arrijë 100 dhe hyrja-dalja do të ndalojë.

Nëse keni një çik të disqeve, atëherë aty është një histori pak më ndryshe. Ajo varet nga mënyra si është ndarë, çfarë lloj disku është, etj.

Dhe paralelisht këtu është konfigurimi i grafikut nga një pamje e brendshme e PostgreSQL-it, e cila tregon se si ndodh checkpoint-i. Dhe me ngjyrë të gjelbër këtu është shënuar sasia e bufferave, këto faqe të ndotura që arritën në këtë checkpoint për sinkronizim. Dhe kjo është kryesorja që duhet të dini këtu. Ne shohim se shumë faqe janë arritur dhe në një moment jemi përballur me një pengesë, domethënë kemi shkruar-shkruar, këtu është e qartë se sistemi i disqeve është shumë i angazhuar. Dhe checkpoint-i ka ndikim të madh në disk. Në mënyrë ideale, situata duhet të duket më shumë kështu, domethënë këtu kemi pasur më pak shkrime. Dhe ne mund ta rregullojmë këtë me konfigurime, për ta mbajtur më kështu. Domethënë, shfrytëzimi është i vogël, por ndonjëherë ne shkruajmë diçka.

Çfarë duhet të bëni për ta zgjidhur këtë problem? Nëse ju ka ndaluar IO nën bazën e të dhënave, atëherë kjo do të thotë se të gjithë përdoruesit që erdhën për të ekzekutuar kërkesat e tyre do të presin.

Nëse e shikoni nga këndvështrimi i Linux-it, nëse keni marrë një harduer të mirë, e keni konfiguruar siç duhet, e keni konfigurur PostgreSQL-in që të bëjë këto checkpoints më rrallë, për t'i shpërndarë ato ndërmjet njëri-tjetrit, atëherë ju jeni të futur në parametrat defolt të Debian-it. Për shumicën e distribucioneve Linux, kjo është pamja: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Çfarë do të thotë kjo? Me kernelin 2.6, është shfaqur një demon flushing. Pdglush, në varësi të asaj që përdorim, merret me pastrimin e faqeve të papastra nga buffer-i i kernel-it dhe i hedh ato kur është e nevojshme, duke hedhur faqe të papastra kur pastrimi në sfond nuk ndihmon më.

Kur fillon pastrimi në sfond? Kur 10% e gjithë memorie së aksesorëve në server është e mbushur me faqe të papastra në bufferin e kernel-it, aktivizohet një funksion special për pastrim në sfond. Pse quhet pastrim në sfond? Sepse merr si parametër numrin e faqeve që të heqë. Dhe, për shembull, heq N faqe. Dhe për një kohë të caktuar kjo gjë bën pushim. Pastaj kthehet dhe heq një sasi më të madhe faqeve.

Kjo është një histori shumë e thjeshtë. Këtu ndodhemi si me një pishinë, ku në një tub derdhet, në tjetrin derdhet. Na ka ardhur një checkpoint dhe, nëse ka dërguar pak faqe të papastra për pastrim, atëherë gradualisht nga buffer-i i kernel-it pgflush do ta heqë këtë ndihmën e kujdesshme.

Nëse vazhdojnë të grumbullohen këto faqe të papastra, ato grumbullohen deri në 20%, pas së cilës prioritare për sistemin operativ është që ta heqë këtë në disk, sepse nëse ndalon energjia, do të kemi probleme. Ne do të humbasim këto të dhëna, për shembull.

Cila është strategjia? Strategjia është se këto parametra në botën moderne, 20% dhe 10% nga e gjithë memoria që ka makina, janë të tmerrshme në aspektin e kapacitetit të çdo sistemi disk që keni.

Imagjinoni se keni 128 GB RAM. 12,8 GB arrijnë në sistemin tuaj të diskut. Dhe çfarëdo që keni si cache, çfarëdo array, ato nuk do ta mbajnë këtë sasi.

Prandaj ne rekomandojmë që këto numra të konfigurohen menjëherë sipas mundësive të kontrollorit tuaj RAID. Këtu është dhënë një rekomandim për kontrollorin që ka 512 MB cache.

Të gjithë e llogarisin shumë thjeshtë. Mund ta vendosni vm.dirty_background në byte. Dhe këto konfigurime anullojnë dy të parat. Ose ratio sipas parazgjedhjes, ose janë aktivizuar ato që janë në byte, atëherë do të funksionojnë ato që janë në byte. Por, sepse jam një konsulent DBA dhe punoj me klientë të ndryshëm, përpiqem të mbaj gjërat të sigurta, prandaj, nëse është në byte, atëherë në byte. Askush nuk dha asnjë garanci se një administrator i mirë nuk do të shtojë memorie në server dhe nuk do ta rindezë atë, ndërsa numri do të mbetet i njëjtë. Thjesht llogaritni këta numra që të siguroheni se gjithçka do të hyjë atje.

Çfarë do të ndodhë nëse nuk do të hyjë? Kam shkruar se çdo flushing efektivisht ndalohet, por në të vërtetë kjo është një figurë e fjalës. Sistemi operativ ka një problem të madh – ka shumë faqe të papastra, prandaj ndalohet efektivisht IO-të që krijojnë klientët tuaj, dmth. aplikacioni që ka dërguar një kërkesë SQL në bazë, po pret. Çdo hyrje – dalje në të është në prioritetin më të ulët, sepse baza është e zënë me checkpoint. Dhe kur do të përfundojë, nuk dihet. Dhe kur keni arritur deri në flushing të zakonshëm, kjo do të thotë se të gjitha IO-të janë të zëna me të. Dhe derisa të përfundojë, nuk do të bëni asgjë.

Këtu janë edhe dy pika të rëndësishme që dalin jashtë këtij raporti. Këto konfigurime duhet të përputhen me konfigurimet në postgresql.conf, dmth. konfigurimet e checkpoints. Dhe sistemi juaj i disqeve duhet të jetë i konfiguruar në mënyrë adekuate. Nëse keni cache në RAID, atëherë duhet të ketë një bateri. Njerëzit blejnë RAID me cache të mirë pa bateri. Nëse keni SSD në RAID, ato duhet të jenë të destinuara për serverë dhe duhet të kenë kondensatorë. Këtu është një listë e detajuar. Në këtë link ndodhet raporti im në lidhje me konfigurimin e performancës së disqeve në PostgreSQL. Atje janë të gjitha këto lista kontrolle.

Çfarë tjetër mund ta ndërlikojë shumë jetë? Këta janë dy parametra. Ata janë relativisht të rinj. Mund të jenë të aktivizuar si parazgjedhje në aplikacione të ndryshme. Dhe ata mund të ndërlikojnë jetën në të njëjtën masë, nëse aktivizohen gabim.

Ka dy gjëra relativisht të reja. Të dy u shfaqën në bërthamën e tretë. Ky është sched_migration_cost në nanosekonda dhe sched_autogroup_enabled, i cili është një në parazgjedhje.

Dhe si i prishin jetën? Çfarë është sched_migration_cost? Me planifikuesin Linux, një proces mund të migrohet nga një CPU në tjetrin. Dhe për PostgreSQL, që ekzekuton kërkesa, migrimi në një CPU tjetër është komplet i paqartë. Nga këndvështrimi i sistemit operativ, kur ndërmerrni dritaret midis openoffice dhe terminalit, ndoshta është e mirë, por për bazën e të dhënave është shumë e keqe. Prandaj, politika e arsyeshme është të vendosni migration_cost në një vlerë të madhe, të paktën disa mijëra nanosekonda.

Çfarë do të thotë kjo për scheduler? Do të mendojë se gjatë këtij kohë ky proces është ende aktiv. Pra, nëse keni ndonjë transaksion të gjatë që merret me diçka për një kohë të gjatë, scheduler do ta kuptojë këtë. Ai do të mendojë se derisa të kalojë kjo kohë skadimi, nuk ka nevojë të migrojë këtë proces askund. Nëse procesi po bën diçka, atëherë ai nuk do të migrohet askund, ai do të përfundojë pa shqetësim në CPU-në që i është alokuar. Dhe rezultati është për ta çmuar.

Pika tjetër është autogroup. Ka një ide të mirë për ngarkesa specifike që nuk kanë lidhje me bazat e të dhënave moderne – grupimi i proceseve sipas terminalit virtual, nga i cili janë nisur. Kjo është e dobishme për disa detyra. Në praktikë, PostgreSQL është një sistem me shumë procese me prefork, i cili niset nga një terminal. Ju keni lock writer, checkpoint dhe të gjitha kërkesat tuaja nga klientët do të grupohen në një scheduler, në një CPU. Aty do të presin së bashku, kur ai të lirohet, që të mos e pengojnë njëri-tjetrin dhe të qëndrojnë atje sa më gjatë. Kjo histori nuk është aspak e nevojshme në rast të tillë ngarkese dhe prandaj duhet të çaktivizohet.

Kolegji im Aleksej Lesovski ka bërë teste me pgbench të thjeshtë, ku rriti ndjeshëm migration_cost dhe çaktivizoi autogroup. Ndryshimi në një harduer të dobët doli gati 10%.. Ka një diskutim në listën e postimeve të postgres, ku njerëzit tregojnë rezultate se si këto ndryshime kanë ndikuar në shpejtësinë e kërkeseve. kanë ndikuar deri në 50%.. Ka shumë histori të tilla.

Dhe përfundimisht lidhur me politikën e kursimit të energjisë. Mirë është që tani Linux mund të përdoret në laptop. Dhe ai do të konsumonte në dukje mirë baterinë. Por papritur del se kjo mund të ndodhi edhe në server.

Për më tepër, nëse merrni serverë me qira nga ndonjë host, atëherë 'të mirët' hostuese nuk e kujdesen që ju të keni performancë më të mirë. Detyra e tyre është të sigurojnë që hardueri të përdoret maksimumi në mënyrë efikase. Prandaj ata mund të aktivizojnë si parazgjedhje modalitetin e kursimit të energjisë të laptopit në sistemin operativ.

Nëse përdorni në një server me bazën e të dhënave nën ngarkesë intensive këtë mund, atëherë zgjedhja juaj është acpi_cpufreq + performance. Edhe me ondemand do të keni probleme.

Intel_pstate është një drejtues pak më ndryshe. Dhe tani preferohet ky, si një më i vonshëm dhe më mirë funksionues.

Dhe, përkatësisht, guvernatori vetëm performance. Ondemand, powersave dhe të tjera – nuk janë për ju.

Rezultatet nga explain analyze PostgreSQL mund të ndryshojnë me disa rend mjeshtrive, nëse aktivizoni powersave, sepse praktikisht CPU-të do të programohen në një mënyrë krejt të paparashikueshme.

Këto gjëra mund të jenë të aktivizuara si parazgjedhje. Shikoni me kujdes – a janë aktivizuar automatikisht. Kjo mund të jetë një problem i vërtetë.

Dhe në fund doja të falenderoja djemtë nga ekipi ynë DBA i PosgreSQL-Consulting, veçanërisht Maksim Boguk dhe Aleksej Lesovski, të cilët çdo ditë dëshmojnë këtë çështje. Dhe për klientët tanë përpiqemi të bëjmë sa më mirë që ata të funksionojnë. Kjo është si me udhëzimet për sigurinë në aviacion. Këtu gjithçka është shkruar me gjak. Çdo kapëse e këtyre është zbuluar në procesin e ndonjë problemi. Unë me kënaqësi ndaja ato me ju.

Pyetje:

Faleminderit! Nëse, për shembull, një kompani dëshiron të kursejë dhe të vendosë bazën e të dhënave dhe logjikën e aplikacionit në një server të vetëm, ose nëse kompania ndjek tendencën bashkëkohore të arkitekturave me mikroshërbime, ku PostgreSQL ekzekutohet në një kontejner. Çfarë është këtu? Sysctl-ka globalisht ndikon në të gjithë bërthamën. Nuk kam dëgjuar që sysctl janë virtualizuar ndonjëherë, që ata të funksiononin veçmas në kontejner. Ka vetëm cgroup dhe aty ka vetëm një pjesë të kontrollit. Si mund të jetoni me këtë? Ose nëse dëshironi performancë, atëherë ekzekutoni PostgreSQL në një server të dedikuar dhe bëjeni atë të optimizuar?

Ne i kemi përgjigjur pyetjes tuaj në mënyrë të përafërt në tre mënyra. Nëse nuk bëhet fjalë për një server të dedikuar, që mund të optimizohet etj., atëherë relaksohuni, gjithçka do të funksionojë mirë pa këto caktime. Nëse keni një ngarkesë të tillë që duhet të bëni këto caktime, atëherë ju do të kaloni më parë te serveri i dedikuar sesa te ato caktime.

Cila është problemi? Nëse kjo është një virtualkë, atëherë, për shumë mundësi, do të keni shumë probleme, për shembull, me atë që në shumicën e virtualkave ka një latency mjaft të pamjaftueshme të diskut. Edhe nëse kapaciteti i disqeve është i mirë, një transaksion me probleme operacioni I/O, i cili nuk ndikon shumë në kapacitetin mesatar, ndodhi në momentin e checkpoint-it ose në momentin e shkruar në WAL, atëherë baza do të vuaje shumë nga kjo. Dhe ju do ta vëreni këtë më parë se do të ashpërsoheni në këto probleme.

Nëse keni NGINX në të njëjtin server, do të keni të njëjtin problem. Ai do të luftojë për memorien e përbashkët. Dhe nuk do të arrini në problemet që përshkruhen këtu.

Por nga ana tjetër, disa nga këta parametra megjithatë do të jenë të rëndësishëm për ju. Për shembull, vendosni dirty_ratio me sysctl, në mënyrë që të mos jetë kaq ekstrem – në çdo rast do të ndihmojë. Pavarësisht, do të keni ndërveprim me diskun. Dhe do të ndodhë me një skemë të gabuar. Këto janë cilësimet standarde që tregova. Dhe në çdo rast është më mirë t'i modificoni.

Me NUMA mund të ketë probleme. VmWare, për shembull, funksionon mirë me NUMA me cilësimet e kundërta. Dhe këtu duhet të zgjidhni – server të çeliktë ose jo.

Kam një pyetje lidhur me Amazon AWS. Ata kanë imazhe të parakonfiguruara. Një prej tyre quhet Amazon RDS. A ka ndonjë cilësim të personalizuar për sistemin e tyre operativ?

Aty ka cilësime, por është një set tjetër cilësimesh. Këtu ne konfigurojmë sistemin operativ nga pikëpamja se si do ta përdorë databaza. Dmth, ne kemi nevojë për kaq shumë resurse, dhe tani do t'i konsumojmë ato. Pas kësaj, Amazon RDS u merr këto resurse, dhe atje performanca bie. Ka histori të veçanta se si njerëzit fillojnë të manipulojnë me këtë. Disa herë mjaft me sukses. Por kjo nuk ka lidhje me cilësimet e OS. Kjo është në njëfarë mënyre hacking i cloud-it. Kjo është një histori tjetër.

Pse Transparent huge pages nuk japin efektin e krahasuar me Huge TLB?

Nuk japin. Kjo mund të shpjegohet në shumë mënyra. Por në fakt, ata thjesht nuk e ofrojnë. Cila është historia me PostgreSQL? Ai rezervon një pjesë të madhe të memories së përbashkët në nisje. Transparent apo jo Transparent – nuk ka rëndësi fare. Fakti se ata rezervohen në nisje shpjegon gjithçka. Dhe nëse ka shumë memorie dhe është e nevojshme të ri-strukturohet segmenti i shared_memory, atëherë Transparent huge pages do të ishin të rëndësishme. Tek PostgreSQL, ai është rezervuar thjesht si një copë e madhe në fillim dhe asgjë e veçantë nuk ndodh më tej. Sigurisht, mund të përdoret, por ka mundësinë e marrjes së korrupsionit të shared_memory, kur ai do të ri-rezervohet diçka. PostgreSQL nuk e di këtë.

Burimi: habr.com