Linux-en sintonizazioa PostgreSQL-ren errendimendua hobetzeko. Ilya Kosmodemyansky

Ilya Kosmodemyansky-ren 2015eko txostenaren transkripzioa "Linux-en sintonizazioa PostgreSQL-ren errendimendua hobetzeko"

Lege-oharra: txosten honek 2015eko azaroko data duela ohartzen naiz; 4 urte baino gehiago igaro dira eta denbora asko igaro dira. Txostenean eztabaidatutako 9.4 bertsioa jada ez da onartzen. Azken 4 urteotan, PostgreSQL-ren 5 bertsio berri kaleratu dira eta Linux nukleoaren 15 bertsio kaleratu dira. Pasarte hauek berridazten badituzu, beste txosten batekin amaituko duzu. Baina hemen PostgreSQL-ren Linux-en oinarrizko sintonizazioa kontuan hartzen dugu, gaur egun oraindik garrantzitsua dena.

Nire izena Ilya Kosmodemyansky da. PostgreSQL-Consulting-en egiten dut lan. Eta orain pixka bat hitz egingo dut Linux-ekin zer egin behar den datu-baseei buruz orokorrean eta PostgreSQL-i bereziki, printzipioak nahiko antzekoak direlako.

Zertaz hitz egingo dugu? PostgreSQL-rekin komunikatzen bazara, neurri batean UNIX administratzailea izan behar duzu. Zer esan nahi du? Oracle eta PostgreSQL konparatzen baditugu, orduan Oracle-n %80 DBA datu-baseen administratzailea eta %20 Linux administratzailea izan behar duzu.

PostgreSQL-rekin pixka bat konplexuagoa da. PostgreSQL-rekin Linux nola funtzionatzen duen askoz hobeto ulertu behar duzu. Eta, aldi berean, korrika pixka bat lokomotora atzetik, azkenaldian dena nahiko ondo eguneratu delako. Eta nukleo berriak kaleratzen dira, eta funtzionaltasun berriak agertzen dira, errendimendua hobetzen da, etab.

Zergatik ari gara Linuxaz hitz egiten? Ez batere Peter Linux konferentzian gaudelako, baizik eta baldintza modernoetan datu-baseak orokorrean eta PostgreSQL bereziki erabiltzeko sistema eragile justifikatuenetako bat Linux delako. FreeBSD, zoritxarrez, oso norabide arraro batean garatzen ari delako. Eta arazoak izango dira bai errendimenduarekin eta baita beste hainbat gauzarekin ere. PostgreSQL-ren errendimendua Windows-en, oro har, aparteko arazo larria da, Windows-ek ez duela UNIX-en memoria partekatu bera, PostgreSQL-k, berriz, horri lotuta dago, prozesu anitzeko sistema delako.

Eta uste dut mundu guztiari gutxiago interesatzen zaiela Solaris bezalako exotikoekin, beraz, goazen.

Linux banaketa moderno batek 1 syctl aukera baino gehiago ditu, nukleoa nola eraikitzen duzunaren arabera. Aldi berean, fruitu lehorrei erreparatzen badiegu, modu askotan zerbait egokitu dezakegu. Fitxategi-sistemaren parametroak daude horiek muntatzeko. Nola abiarazteko galderarik baduzu: zer gaitu BIOSan, nola konfiguratu hardwarea, etab.

Bolumen oso handia da, hainbat egunetan eztabaidatu daitekeena, eta ez txosten labur batean, baina orain gauza garrantzitsuetan zentratuko naiz, nola saihestu zure datu-basea Linux-en ondo erabiltzea eragozteko bermatuta dauden arrasto horiek nola saihestu. ez zuzendu . Eta, aldi berean, puntu garrantzitsu bat da datu-baserako zuzenak diren ezarpenetan parametro lehenetsi asko ez daudela sartzen. Hau da, lehenespenez gaizki edo batere ez du funtzionatuko.

Zein ohiko sintonizazio helburu daude Linuxen? Uste dut denok Linux administrazioarekin ari zaretenez, ez dagoela helburu berezirik azaldu beharrik.

Sintonizatu dezakezu:

• CPU.
• Memoria.
• Biltegiratzea.
• Bestela. Honetaz hitz egingo dugu amaieran mokadutxo bat egiteko. Nahiz eta, adibidez, energia aurrezteko politika bezalako parametroek errendimenduan eragina izan dezakete oso ezusteko moduan eta ez modu atseginenean.

Zeintzuk dira PostgreSQLren eta, oro har, datu-basearen berezitasunak? Arazoa da ezin duzula intxaur indibidual bat moldatu eta gure errendimendua nabarmen hobetu dela ikusi.

Bai, badaude horrelako tramankuluak, baina datu-base bat gauza konplexua da. Zerbitzariak dituen baliabide guztiekin elkarreragiten du eta nahiago du ahalik eta gehien interakzioan aritzea. Ostalari OS bat erabiltzeko Oracleren egungo gomendioei erreparatuz gero, mongoliar kosmonauta horri buruzko txantxa bezalakoa izango da: elikatu txakurra eta ez ukitu ezer. Eman diezaiogun datu-baseari baliabide guztiak, datu-baseak berak ordenatuko du dena.

Printzipioz, neurri batean egoera berdina da PostgreSQL-rekin. Desberdintasuna da datu-baseak oraindik ez dituela baliabide guztiak beretzat hartzeko gai, hau da, Linux mailan zuk zeuk ordenatu behar duzula.

Ideia nagusia ez da helburu bakarra hautatzea eta sintonizatzen hastea, adibidez, memoria, CPU edo horrelako zerbait, baizik eta lan karga aztertzea eta errendimendua ahalik eta gehien hobetzen saiatzea, programatzaile onek sortu duten karga izan dadin. guretzat, gure erabiltzaileak barne.

Hona hemen argazki bat zer den azaltzeko. Linux OS buffer bat dago eta memoria partekatua dago eta PostgreSQL buffer partekatuak daude. PostgreSQL-k, Oracle-k ez bezala, nukleo-buffer-aren bidez soilik funtzionatzen du zuzenean, hau da, diskoko orri bat bere memoria partekatuan sartzeko, nukleo-buffer-etik eta atzera egin behar du, egoera bera.

Diskoak sistema honen pean bizi dira. Hau disko gisa marraztu nuen. Izan ere, RAID kontroladore bat egon daiteke, etab.

Eta sarrera-irteera hau nola edo hala gertatzen da gai honen bidez.

PostgreSQL datu-base klasikoa da. Orrialde bat dago barruan. Eta sarrera eta irteera guztiak orrialdeak erabiliz gertatzen dira. Blokeak memoriara altxatzen ari gara orrialdeekin. Eta ezer gertatu ezean, irakurri besterik ez dugu egiten, gero pixkanaka cache honetatik, partekatutako bufferetatik desagertu eta berriro diskoan amaitzen dira.

Zerbait ordezkatzen badugu nonbait, orduan orri osoa zikin gisa markatuko da. Hemen markatu ditut urdinez. Eta horrek esan nahi du orrialde hau blokeen biltegiratzearekin sinkronizatu behar dela. Hau da, zikintzen genuenean, WALen sarrera bat egin genuen. Eta momentu zoragarri batean, checkpoint izeneko fenomenoa etorri zen. Eta erregistro horretan jasota zegoen informazioa heldu zela. Eta horrek esan nahi du une horretan partekatutako buffer horietan hemen zeuden orri zikin guztiak biltegiratze diskoarekin sinkronizatu zirela fsync erabiliz nukleoaren bufferaren bidez.

Zergatik egiten da hau? Tentsioa galtzen bagenuen, orduan ez genuen lortu datu guztiak galdu zirelako egoera. Oroimen iraunkorra, denek kontatu digutena, orain arte datu-baseen teorian dago - hau etorkizun distiratsua da, eta, noski, ahalegintzen gara eta gustatzen zaigu, baina oraingoz 20 urte gutxiagotan bizi dira. Eta, noski, horren guztiaren jarraipena egin behar da.

Eta errendimendua maximizatzeko zeregina fase hauetan guztietan finkatzea da, dena azkar mugi dadin aurrera eta atzera. Partekatutako memoria, funtsean, orrialde-cachea da. PostgreSQL-n hautatutako kontsulta bat edo zerbait bidali genuen, datu hauek diskotik berreskuratu zituen. Buffer partekatuetan amaitu zuten. Horren arabera, honek hobeto funtziona dezan, memoria asko egon behar da.

Horrek guztiak ondo eta azkar funtziona dezan, sistema eragilea behar bezala konfiguratu behar duzu fase guztietan. Eta aukeratu hardware orekatua, zeren lekuren batean desoreka bat baduzu, orduan memoria asko egin dezakezu, baina ez da nahikoa abiaduran zainduko.

Eta goazen puntu horietako bakoitza.

Orrialde hauek aurrera eta atzera azkarrago bidaiatzeko, honako hau lortu behar duzu:

• Lehenik eta behin, memoriarekin modu eraginkorragoan lan egin behar duzu.
• Bigarrenik, memoriatik orriak diskora doazenean trantsizio hori eraginkorragoa izan beharko litzateke.
• Eta hirugarrenik, disko onak egon behar dira.

Zerbitzarian 512 GB RAM badituzu eta hori guztia SATA disko gogorrean amaitzen bada, inolako cacherik gabe, datu-basearen zerbitzari osoa kalabaza bat ez ezik, SATA interfazea duen kalabaza bihurtzen da. Zuzenean sartuko zara. Eta ezer ez zaitu salbatuko.

Memoriaren lehen puntuari dagokionez, hiru gauza daude bizitza oso zaildu dezaketenak.

Horietako lehena NUMA da. NUMA errendimendua hobetzeko egindako gauza bat da. Lan kargaren arabera, gauza desberdinak optimiza daitezke. Eta gaur egungo forma berrian, ez da oso ona orrialde-cache-ko buffer partekatuak modu intentsiboan erabiltzen dituzten datu-baseetarako.

Hitz gutxitan. Nola jakin dezakezu zerbait gaizki dagoen NUMArekin? Kolpe desatsegin bat duzu, bat-batean CPU batzuk gainkargatuta daude. Aldi berean, PostgreSQL-n kontsultak aztertzen dituzu eta ikusten duzu ez dagoela antzekorik. Kontsulta hauek ez lukete hainbeste CPU intentsiboa izan behar. Denbora luzez harrapatzeko dezakezu. Errazagoa da hasiera-hasieratik gomendio zuzena erabiltzea PostgreSQL-rako NUMA nola konfiguratzeko.

Zer ari da gertatzen benetan? NUMA ez-Uniform Memory Access da. Zer da kontua? CPU bat duzu, ondoan bere memoria lokala dago. Eta memoria interkonexio honek beste CPU batzuetako memoria atera dezake.

Korrika egiten baduzu numactl --hardware, orduan hain orri handi bat lortuko duzu. Besteak beste, distantzien zelaia egongo da. Zenbakiak egongo dira - 10-20, horrelako zerbait. Zenbaki hauek urruneko memoria hau hartzeko eta lokalean erabiltzeko salto kopurua baino ez dira. Printzipioz, ideia ona. Honek errendimendua ondo bizkortzen du lan-karga ezberdinetan.

Orain imajinatu CPU bat duzula lehenik bere memoria lokala erabiltzen saiatzen ari dela, gero beste memoria bat ateratzen saiatzen dela zerbaitetarako interkonexioaren bidez. Eta CPU honek zure PostgreSQL orrialdearen cache osoa lortzen du - hori da, gigabyte batzuk. Beti lortzen duzu kasurik txarrena, CPUan normalean memoria gutxi dagoelako modulu horretan bertan. Eta zerbitzatzen den memoria guztia interkonexio horietatik pasatzen da. Astiro eta triste bihurtzen da. Eta nodo honi zerbitzua ematen dion prozesadorea etengabe gainkargatuta dago. Eta memoria honen sarbide-denbora txarra da, motela. Hau da datu-base baterako erabiltzen ari bazara nahi ez duzun egoera.

Horregatik, datu-baserako aukera zuzenagoa da Linux sistema eragileak bertan zer gertatzen den batere ez jakitea. Memorian sartzen den moduan sartzeko.

Zergatik da hori? Alderantziz izan beharko litzatekeela dirudi. Hau arrazoi sinple batengatik gertatzen da: memoria asko behar dugu orrialdeko cacherako - hamarnaka, ehunka gigabyte.

Eta hori guztia esleitu eta gure datuak bertan gordetzen baditugu, orduan cachea erabiltzearen irabazia memoriarako sarbide zaila den irabazia baino nabarmen handiagoa izango da. Eta horrela etekin paregabea izango dugu NUMA erabiliz memoria modu eraginkorragoan sartuko garenarekin alderatuta.

Hori dela eta, une honetan bi ikuspegi daude, etorkizun distiratsua iritsi arte, eta datu-basea bera ez da gai zein CPUtan exekutatzen ari den eta nondik atera behar duen zerbait.

Hori dela eta, ikuspegi zuzena NUMA guztiz desgaitzea da, adibidez, berrabiaraztean. Kasu gehienetan, irabaziak halako tamainakoak dira, zein den hobea den galdera batere sortzen ez den.

Bada beste aukera bat. Lehena baino maizago erabiltzen dugu, bezero bat laguntza bila etortzen zaigunean zerbitzaria berrabiaraztea gauza handia baita berarentzat. Han negozio bat dauka. Eta arazoak izaten dituzte NUMA dela eta. Hori dela eta, berrabiarazi baino modu gutxiago inbaditzaileetan desgaitzen saiatzen gara, baina kontuz ibili desgaituta dagoela egiaztatzen. Izan ere, esperientziak erakusten duenez, ona da NUMA desgaitzea PostgreSQL prozesu nagusian, baina ez da batere beharrezkoa funtzionatuko duenik. Egiaztatu eta benetan itzali zela ikusi behar dugu.

Robert Haas-en mezu on bat dago. Hau PostgreSQL-ren komisarioetako bat da. Behe-mailako giblets guztien garatzaile nagusietako bat. Eta mezu honetako estekak jarraitzen badituzu, NUMAk jendeari bizitza zaildu zuenari buruzko hainbat istorio koloretsu deskribatzen dituzte. Begira, aztertu zerbitzarian konfiguratu behar den sistema-administratzailearen kontrol-zerrenda gure datu-baseak ondo funtziona dezan. Ezarpen hauek idatzi eta egiaztatu behar dira, bestela ez baita oso ona izango.

Kontuan izan hau buruz hitz egingo dudan ezarpen guztiei aplikatzen zaiela. Baina normalean datu-baseak maisu-esklabu moduan biltzen dira akatsen tolerantziarako. Ez ahaztu konfigurazio hauek esklaboan egitea, egunen batean istripu bat izango duzulako eta esklabora aldatuko zara eta maisu bihurtuko zara.

Larrialdi egoeran, dena oso gaizki dagoenean, zure telefonoak etengabe jotzen duenean eta zure nagusia makila handi batekin korrika etortzen denean, ez duzu egiaztatzen pentsatzeko astirik izango. Eta emaitzak nahiko negargarriak izan daitezke.

Hurrengo puntua orrialde erraldoiak dira. Orrialde erraldoiak zailak dira bereizita probatzea, eta ez du balio hori egiteak, nahiz eta hori egin dezaketen erreferentziak dauden. Googlen errazak dira.

Zer da kontua? Zerbitzari ez oso garestia daukazu RAM asko duena, adibidez, 30 GB baino gehiagokoa. Ez duzu orrialde handirik erabiltzen. Horrek esan nahi du behin betiko gainkostua duzula memoria erabilerari dagokionez. Eta gainkostu hori atseginena izatetik urrun dago.

Zergatik da hori? Beraz, zer gertatzen da? Sistema eragileak memoria zati txikitan esleitzen du. Hain erosoa da, horrela gertatu zen historikoki. Eta xehetasunetan sartzen bagara, OSak helbide birtualak fisikoetara itzuli behar ditu. Eta prozesu hau ez da errazena, beraz, sistema eragileak eragiketa honen emaitza Translation Lookaside Buffer-en (TLB) gordetzen du.

Eta TLB cache bat denez, egoera honetan sortzen dira cache baten berezko arazo guztiak. Lehenik eta behin, RAM asko baduzu eta zati txikitan esleituta badago, buffer hau oso handia izango da. Eta cachea handia bada, motelagoa da haren bidez bilatzea. Gainekoak osasuntsu daude eta berak lekua hartzen du, hau da, RAM okerren batek kontsumitzen du. Oraingoan.

Bi: zenbat eta gehiago hazi cachea horrelako egoera batean, orduan eta litekeena da cache hutsak izatea. Eta cache honen eraginkortasuna azkar gutxitzen da bere tamaina handitu ahala. Hori dela eta, sistema eragileak planteamendu sinple bat sortu zuten. Linuxen aspalditik erabiltzen da. FreeBSDen agertu zen duela ez hainbeste. Baina Linuxez ari gara. Orrialde handiak dira hauek.

Eta hemen kontuan izan behar da orrialde erraldoiak, ideia gisa, hasieran Oracle eta IBM barne hartzen zituzten komunitateek bultzatu zutela, hau da, datu-baseen fabrikatzaileek gogor pentsatu zuten hori datu-baseetarako ere erabilgarria izango zela.

Eta nola egin daiteke hau PostgreSQL-rekin lagun? Lehenik eta behin, orrialde erraldoiak gaitu behar dira Linux nukleoan.

Bigarrenik, sysctl parametroaren bidez esplizituki zehaztu behar dira - zenbat dauden. Hemengo zenbakiak zerbitzari zahar batzuetakoak dira. Zenbat buffer partekatu dituzun kalkula dezakezu, orrialde erraldoiak bertan kabitzeko.

Eta zure zerbitzari osoa PostgreSQL-ra dedikatuta badago, abiapuntu ona da RAMaren % 25 buffer partekatuetara esleitzea edo % 75 zure datu-basea % 75 horretan sartuko dela ziur bazaude. Abiapuntua bat. Eta kontuan hartu, 256 GB RAM badituzu, orduan, horren arabera, 64 GB-ko buffer handi izango dituzu. Kalkulatu gutxi gorabehera marjina batekin - zertan ezarri behar den zifra hau.

9.2 bertsioa baino lehen (oker ez banago, 8.2 bertsiotik aurrera), posible zen PostgreSQL orrialde erraldoiekin konektatzea hirugarrenen liburutegi bat erabiliz. Eta hau beti egin behar da. Lehenik eta behin, nukleoa behar duzu orrialde erraldoiak behar bezala esleitu ahal izateko. Eta, bigarrenik, haiekin lan egiten duen aplikazioak erabil ditzan. Ez da horrela bakarrik erabiliko. PostgreSQL-k memoria sistema 5 estiloan esleitu zuenez, hau libhugetlbfs erabiliz egin liteke - hau da liburutegiaren izen osoa.

9.3-n, PostgreSQL-ren errendimendua hobetu zen memoriarekin lan egitean eta sistema 5 memoria esleitzeko metodoa alde batera utzi zen. Guztiak oso pozik zeuden, bestela bi PostgreSQL instantzia exekutatzen saiatzen zarelako makina batean, eta esan zuen ez dudala memoria partekatu nahikoa. Eta sysctl zuzendu behar dela dio. Eta hala nola sysctl bat dago oraindik berrabiarazi behar duzula, etab. Oro har, denak pozik zeuden. Baina mmap memoria esleitzeak orrialde erraldoien erabilera hautsi zuen. Gure bezero gehienek partekatutako buffer handiak erabiltzen dituzte. Eta 9.3ra ez aldatzea gomendatzen dugu, gainkostuak ehuneko onetan kalkulatzen hasi zirelako.

Baina komunitateak arreta jarri zion arazo honi eta 9.4an oso ondo birlanizatu zuten gertaera hau. Eta 9.4-n postgresql.conf-en parametro bat agertu zen eta bertan saiatu, aktibatu edo desaktibatu dezakezu.

Saiatzea da aukerarik seguruena. PostgreSQL abiaraztean, memoria partekatua esleitzen duenean, memoria hori orri handietatik ateratzen saiatzen da. Eta funtzionatzen ez badu, aukeraketa arruntera itzultzen da. Eta FreeBSD edo Solaris baduzu, probatu dezakezu, beti da segurua.

Aktibatuta badago, ez da abiarazten orri handietatik hautatu ezin badu. Hemen dagoeneko nor eta zer den politagoa da. Baina saiatu bazara, egiaztatu behar duzuna nabarmenduta duzula, akatsetarako tarte handia baitago. Gaur egun funtzionalitate honek Linux-en bakarrik funtzionatzen du.

Ohar txiki bat gehiago joan aurretik. Orrialde handi gardenak ez dira PostgreSQLri buruz oraindik. Ezin ditu normalean erabili. Eta Transparent orrialde erraldoiekin horrelako lan-kargarako, partekatutako memoria zati handi bat behar denean, onurak oso bolumen handiekin bakarrik datoz. Terabyte-ko memoria badituzu, baliteke hau jokoan jartzea. Eguneroko aplikazio gehiagoz ari bagara, zure makinan 32, 64, 128, 256 GB memoria dituzunean, ohiko orrialde erraldoiak ondo daude, eta Transparent desgaitzen dugu.

Eta oroimenari buruzko azken gauza ez dago fruituarekin zerikusi zuzena, benetan zure bizitza honda dezake. Zerbitzaria etengabe trukatzen ari denaren eragin handia izango du errendimendu guztia.

Eta hori oso desatsegina izango da hainbat modutan. Eta arazo nagusia da nukleo modernoek Linux nukleo zaharrekiko apur bat ezberdin jokatzen dutela. Eta gauza hau nahiko desatsegina da zapaltzea, izan ere, swap-arekin lan mota bati buruz hitz egiten dugunean, OOM-hiltzailearen garaiz kanpoko etorrerarekin amaitzen da. Eta OOM-hiltzailea, garaiz iritsi ez zena eta PostgreSQL jaitsi zuena, desatsegina da. Guztiek jakingo dute horren berri, hau da, azken erabiltzailea arte.

Zer ari da gertatzen? Bertan RAM kopuru handia duzu, dena ondo dabil. Baina arrazoiren batengatik zerbitzaria trukean zintzilikatzen da eta moteldu egiten da horregatik. Badirudi memoria asko dagoela, baina hori gertatzen da.

Aurretik, vm.swappiness zero ezartzea gomendatzen genuen, hau da, swap desgaitzea. Aurretik, zirudien 32 GB RAM eta dagozkion buffer partekatuak kopuru handia zela. Trukearen helburu nagusia erortzen bagara lurrazala botatzeko lekua izatea da. Eta jada ez zen bereziki betetzen. Eta orduan zer egingo duzu lurrazal honekin? Zertarako trukea behar den oso argi ez dagoen zeregina da, batez ere tamaina horretakoa.

Baina modernoagoetan, hots, nukleoaren hirugarren bertsioetan, portaera aldatu egin da. Eta swap zeroan ezartzen baduzu, hau da, itzali egiten baduzu, lehenago edo beranduago, RAM pixka bat geratzen bada ere, OOM hiltzaile bat etorriko zaizu kontsumitzaile intentsiboenak hiltzeko. Kontuan hartuko duelako halako lan karga batekin oraindik pixka bat geratzen zaigula eta salto egingo dugulako, hau da, ez sistemaren prozesua iltze aldera, garrantzi gutxiagoko zerbait iltze aldera baizik. Garrantzi txikiagoko hau memoria partekatuaren kontsumitzaile intentsiboa izango da, posta-zuzendaria alegia. Eta horren ostean ona izango da oinarria zaharberritu behar ez bada.

Hori dela eta, orain lehenetsia, gogoratzen dudanez, banaketa gehienak 6 inguruan daude, hau da, zein puntutan hasi behar zenuke swap erabiltzen zenbat memoria geratzen den arabera. Orain vm.swappiness = 1 ezartzea gomendatzen dugu, honek ia desaktibatzen duelako, baina ez duelako ustekabean iritsi eta guztia hil duen OOM-hiltzaile baten efektu berdinak ematen.

Zer da hurrengoa? Datu-baseen errendimenduaz hitz egiten dugunean eta pixkanaka diskoetara joaten garenean, denak burua hartzen hasten dira. Diskoa motela eta memoria azkarra dela egia da txikitatik ezaguna baita. Eta denek daki datu-baseak diskoaren errendimendu arazoak izango dituela.

Kontrol-puntuen puntuekin lotutako PostgreSQL-ren errendimendu-arazo nagusia ez da gertatzen diskoa motela delako. Litekeena da hori memoria eta diskoaren banda-zabalera orekatuta ez daudelako. Hala ere, baliteke leku ezberdinetan orekaturik ez egotea. PostgreSQL ez dago konfiguratuta, OS ez dago konfiguratuta, hardwarea ez dago konfiguratuta eta hardwarea okerra da. Eta arazo hau ez da gertatzen dena behar den bezala gertatzen bada, hau da, edo ez dago kargarik, edo ezarpenak eta hardwarea ondo hautatuta badaude.

Zer da eta nolakoa da? Normalean PostgreSQL-rekin lan egiten duten pertsonak behin baino gehiagotan sartu dira gai honetan. azalduko dut. Esan bezala, PostgreSQL-k aldian-aldian kontrol-puntuak egiten ditu memoria partekatuko orrialde zikinak diskora botatzeko. Partekatutako memoria kopuru handia badugu, checkpoint-ak diskoan eragin intentsiboa izaten hasten da, orrialde hauek fsync-ekin botatzen dituelako. Nukleoaren bufferera iristen da eta diskoetan idazten da fsync erabiliz. Eta negozio honen bolumena handia bada, orduan efektu desatsegin bat ikus dezakegu, hots, diskoen erabilera oso handia.

Hemen bi argazki ditut. Orain azalduko dut zer den. Denborarekin erlazionatutako bi grafiko dira. Lehenengo grafikoa diskoaren erabilera da. Hemen ia % 90era iristen da une honetan. Disko fisikoekin datu-basearen hutsegite bat baduzu, RAID kontrolagailuaren erabilera % 90ean, orduan albiste txarra da. Horrek esan nahi du apur bat gehiago eta 100era iritsiko dela eta I/O gelditu egingo dela.

Disko array bat baduzu, istorio apur bat ezberdina da. Nola konfiguratzen den, zer array mota den, etab.

Eta paraleloki, barne postgres ikuspegiko grafiko bat konfiguratzen da hemen, kontrol-puntua nola gertatzen den adierazten duena. Eta hemen kolore berdeak erakusten du zenbat buffer, orri zikin horiek, une horretan iritsi ziren sinkronizaziorako kontrol-puntu honetara. Eta hau da hemen jakin behar duzun gauza nagusia. Ikusten dugu hemen orrialde asko ditugula eta noizbait arbelera jo dugu, hau da, idatzi eta idatzi dugu, hemen disko sistema argi dago oso lanpetuta dagoela. Eta gure kontrol-puntuak oso eragin handia du diskoan. Egokiena, egoerak horrelako itxura gehiago izatea, hau da, hemen grabaketa gutxiago izan genuen. Eta ezarpenekin konpondu dezakegu horrela izaten jarrai dezan. Hau da, birziklapena txikia da, baina nonbait hemen zerbait idazten ari gara.

Zer egin behar da arazo hori gainditzeko? IO datu-basearen azpian gelditu baduzu, horrek esan nahi du beren eskaerak betetzera etorri diren erabiltzaile guztiek itxarongo dutela.

Linux-en ikuspuntutik begiratuz gero, hardware ona hartu baduzu, behar bezala konfiguratu baduzu, PostgreSQL normal konfiguratu baduzu, kontrol-puntu hauek gutxiagotan egin ditzan, denboran zehar elkarren artean zabaltzen badituzu, orduan Debian parametro lehenetsietan sartzen zara. Linux banaketa gehienetarako, hau da irudia: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Zer esan nahi du? 2.6 kerneletik deabru garbi bat agertu zen. Pdglush, nork erabiltzen duen zein den, zeina nukleoko bufferetik orrialde zikinak atzeko planoan baztertzen eta orri zikinak edozein dela ere baztertu behar direnean, atzeko planoa baztertzeak laguntzen ez duenean.

Noiz dator aurrekaria? Zerbitzarian eskuragarri dagoen RAM osoaren % 10 nukleoko buffer-eko orrialde zikinek okupatzen dutenean, atzeko planoan idazteko funtzio berezi bat deitzen da. Zergatik da atzeko planoa? Parametro gisa, zenbat orrialde kendu behar diren kontuan hartzen da. Eta, demagun, N orrialdeak idazten dituela. Eta denbora batez gauza hau loak hartzen du. Eta gero etortzen da berriro eta orrialde batzuk kopiatzen ditu.

Hau oso istorio sinplea da. Hemen arazoa igerileku batekin bezalakoa da, hodi batera isurtzen denean beste batera isurtzen da. Gure kontrol-puntua iritsi zen eta baztertzeko orri zikin batzuk bidaltzen bazituen, pixkanaka-pixkanaka guztia ondo konponduko da pgflush nukleoaren bufferetik.

Orri zikin horiek pilatzen jarraitzen badute, %20raino pilatzen dira, eta ondoren OSaren lehentasuna guztia diskoan idaztea da, potentzia huts egingo duelako eta dena txarra izango delako. Datu hauek galduko ditugu, adibidez.

Zein da trikimailua? Trikimailua da mundu modernoan parametro hauek makinan dagoen RAM osoaren % 20 eta 10 direla, erabat izugarriak dira zuk duzun edozein disko-sistemaren errendimenduari dagokionez.

Imajinatu 128 GB RAM dituzula. 12,8 GB zure disko sistemara iristen dira. Eta ez du axola zer cache duzun bertan, edozein array duzu han, ez dute horrenbeste iraungo.

Hori dela eta, zenbaki hauek berehala doitzea gomendatzen dugu zure RAID kontrolagailuaren gaitasunen arabera. Berehala gomendio bat egin nuen hemen 512 MB-ko cachea duen kontrolagailu baterako.

Dena oso sinpletzat jotzen da. vm.dirty_background jar dezakezu bytetan. Eta ezarpen hauek aurreko biak bertan behera uzten dituzte. Edo erlazioa lehenespenezkoa da, edo byteak dituztenak aktibatuta daude, orduan byteak dituztenek funtzionatuko dute. Baina DBA aholkularia naizenez eta bezero ezberdinekin lan egiten dudanez, lastoak marrazten saiatzen naiz eta, beraz, bytetan bada, byteetan. Inork ez zuen inolako bermerik eman administratzaile on batek zerbitzariari memoria gehiago gehituko ez zionik, berrabiaraziko eta zifra berdina izango zela. Zenbaki hauek kalkulatu besterik ez dago, dena berme batekin kabitzeko.

Zer gertatzen da sartzen ez bazara? Idatzi dut edozein hustuketa modu eraginkorrean gelditzen dela, baina, hain zuzen ere, hau hitz egiteko figura bat da. Sistema eragileak arazo handi bat du - orrialde zikin asko ditu, beraz, zure bezeroek sortzen duten IOa modu eraginkorrean gelditzen da, hau da, aplikazioa datu-basera sql kontsulta bat bidaltzera etorri da, zain dago. Haren edozein sarrera/irteera lehentasun txikiena du, datu-basea kontrol-puntu batek hartzen duelako. Eta noiz amaituko duen guztiz ez dago argi. Eta atzeko planoa ez den garbiketa lortzen duzunean, zure IO guztia okupatuta dagoela esan nahi du. Eta amaitu arte, ez duzu ezer egingo.

Txosten honen esparrutik kanpo dauden bi puntu garrantzitsu gehiago daude hemen. Ezarpen hauek postgresql.conf-eko ezarpenekin bat etorri behar dute, hau da, kontrol-puntuen ezarpenekin. Eta zure disko-sistema behar bezala konfiguratuta egon behar da. RAID batean cache bat baduzu, bateria bat izan behar du. Jendeak cache onarekin erosten du RAID bateriarik gabe. RAID-en SSDak badituzu, zerbitzariak izan behar dute, kondentsadoreak egon behar dira bertan. Hona hemen kontrol-zerrenda zehatza. Esteka honek PostgreSQL-en errendimendu-disko bat konfiguratzeko nire txostena dauka. Hor daude kontrol-zerrenda horiek guztiak.

Zer gehiago egin dezake bizitza oso zaila? Hauek bi parametro dira. Berri samarrak dira. Berez, aplikazio ezberdinetan sar daitezke. Eta bizitza bezain zaila egin dezakete gaizki pizten badira.

Bi gauza berri samarrak daude. Dagoeneko hirugarren nukleoetan agertu dira. Hau sched_migration_cost da nanosegundotan eta sched_autogroup_enabled, hau da, lehenespenez.

Eta nola hondatzen dizute zure bizitza? Zer da sched_migration_cost? Linux-en, programatzaileak prozesu bat PUZ batetik bestera migra dezake. Eta kontsultak exekutatzen dituen PostgreSQLrentzat, beste CPU batera migratzea guztiz ez dago argi. Sistema eragilearen ikuspuntutik, leihoak openoffice eta terminal artean aldatzean, hau ona izan daiteke, baina datu-base baterako hori oso txarra da. Horregatik, zentzuzko politika da migration_cost balio handi batean ezartzea, gutxienez hainbat mila nanosegundo.

Zer esan nahi du honek programatzailearentzat? Kontuan hartuko da denbora horretan prozesua oraindik bero dagoela. Hau da, denbora luzez zerbait egiten ari den transakzio bat baduzu, programatzaileak hau ulertuko du. Suposatuko du denbora-muga hori igaro arte ez dagoela prozesu hau inora migratu beharrik. Aldi berean prozesuak zerbait egiten badu, orduan ez da inora migratuko, lasai-lasai lan egingo du esleitu zitzaion CPUan. Eta emaitza bikaina da.

Bigarren puntua autotaldea da. Datu-base modernoekin zerikusirik ez duten lan-karga zehatzetarako ideia ona da: prozesuak abiarazten diren terminal birtualaren arabera taldekatzea da. Hau erosoa da zeregin batzuetarako. Praktikan, PostgreSQL terminal bakar batetik exekutatzen den aurrefork bat duen prozesu anitzeko sistema bat da. Blokeo-idazlea, kontrol-puntu bat duzu eta zure bezeroen eskaera guztiak programatzaile batean bilduko dira, CPU bakoitzeko. Eta han bat-batean itxarongo dute aske egon arte, elkarri oztopatzeko eta luzaroago okupatuta mantentzeko. Hau karga baten kasuan guztiz beharrezkoa ez den istorio bat da eta, beraz, itzali behar da.

Nire lankide Alexey Lesovsky pgbench soil batekin probak egin zituen, non migration_cost handitu zuen magnitude ordena batean eta autogroup desaktibatu zuen. Hardware txarraren aldea ia % 10ekoa zen. Postgres-en posta-zerrendan eztabaida bat dago, non jendeak kontsulta-abiaduraren antzeko aldaketen emaitzak ematen dituen %50ean eragin zuen. Horrelako istorio asko daude.

Eta azkenik, energia aurrezteko politikari buruz. Gauza ona da orain Linux ordenagailu eramangarri batean erabil daitekeela. Eta ustez bateria ondo erabiliko du. Baina bat-batean gertatzen da zerbitzarian ere gerta daitekeela.

Gainera, ostalari batzuen zerbitzariak alokatzen badituzu, ostalari "onak" ez zaie axola errendimendu hobea izatea. Haien zeregina da burdina ahalik eta modu eraginkorrenean erabiltzen dela ziurtatzea. Hori dela eta, lehenespenez ordenagailu eramangarrien energia aurrezteko modua gaitu dezakete sistema eragilean.

Datu-base bat karga handia duen zerbitzari batean erabiltzen badituzu gauza hauek, orduan zure aukera acpi_cpufreq + permormance da. Ondemand-ekin ere arazoak izango dira.

Intel_pstate kontrolatzaile apur bat desberdina da. Eta orain lehentasuna ematen zaio honi, beranduago baita eta hobeto funtzionatzen baitu.

Eta, horren arabera, gobernadorea errendimendua baino ez da. Ondemand, powersave eta beste guztia ez dira zuri buruz.

PostgreSQL-ren azalpenaren analisiaren emaitzak hainbat magnitude-orden desberdinak izan daitezke potentzia-aurreztea gaitzen baduzu, ia zure datu-baseko CPUa guztiz ezusteko modu batean exekutatzen ari delako.

Elementu hauek lehenespenez sar daitezke. Begiratu arretaz lehenespenez aktibatu duten ikusteko. Benetan arazo handia izan daiteke.

Eta azkenean, eskerrak eman nahi nizkieke gure PosgreSQL-Consulting DBA taldeko mutilei, hau da, Max Boguk eta Alexey Lesovsky, gai honetan aurrera egiten ari diren egunero. Eta gure bezeroei ahal dugun onena egiten saiatzen gara, dena beraientzat funtziona dezan. Abiazioko segurtasun-argibideekin bezala da. Hemen dena odolez idatzita dago. Fruitu lehor horietako bakoitza arazo motaren baten prozesuan aurkitzen da. Pozik nago zuekin partekatzeaz.

galderak:

Eskerrik asko! Esaterako, enpresa batek dirua aurreztu eta datu-basea eta aplikazio logika zerbitzari batean jarri nahi baditu, edo enpresak mikrozerbitzuen arkitekturaren modan dagoen joera jarraitzen badu, PostgreSQL edukiontzi batean exekutatzen baita. Zein da trikimailua? Sysctl-ek nukleo guztiari eragingo dio globalki. Ez dut entzun sysctls nolabait birtualizatzen direnik, edukiontzi batean bereizita lan egiteko. cgroup bat bakarrik dago eta kontrolaren zati bat besterik ez dago bertan. Nola bizi dezakezu honekin? Edo errendimendua nahi baduzu, exekutatu PostgreSQL aparteko hardware zerbitzari batean eta sintonizatu?

Zure galdera hiru modutan erantzun dugu. Sintonizatu daitekeen hardware zerbitzari bati buruz ari ez bagara, eta abar, lasai, dena ondo funtzionatuko du ezarpen hauek gabe. Ezarpen hauek egin behar dituzun karga bat baduzu, ezarpen hauetara baino lehenago iritsiko zara burdina zerbitzarira.

Zein da arazoa? Hau makina birtuala bada, ziurrenik arazo asko izango dituzu, adibidez, makina birtualetan diskoaren latentzia nahiko ez-koherentea dela. Diskoaren transmisioa ona bada ere, kontrol-puntuan edo WAL-en idazteko unean gertatutako batez besteko errendimenduan asko eragiten ez duen I/O transakzio huts batek, orduan datu-baseak asko sufrituko du. Eta hori nabarituko duzu arazo hauekin ibili aurretik.

NGINX zerbitzari berean baduzu, arazo bera izango duzu. Memoria partekatuaren alde borrokatuko du. Eta ez dituzu hemen azaldutako arazoetara iritsiko.

Baina, bestalde, parametro horietako batzuk oraindik garrantzitsuak izango dira zuretzat. Adibidez, ezarri dirty_ratio sysctl-rekin hain zoroa izan ez dadin; edonola ere, honek lagunduko du. Modu batera edo bestera, diskoarekin interakzioa izango duzu. Eta eredu okerraren arabera izango da. Oro har, erakutsi ditudan parametroen lehenetsia da. Eta nolanahi ere hobe da horiek aldatzea.

Baina NUMArekin arazoak egon daitezke. VmWare-k, adibidez, ondo funtzionatzen du NUMArekin guztiz kontrako ezarpenekin. Eta hemen aukeratu behar duzu - burdinazko zerbitzari bat edo burdinazkoa ez den bat.

Amazon AWS-ri lotutako galdera bat daukat. Aurrez konfiguratuta dauzkate irudiak. Horietako bat Amazon RDS deitzen da. Ba al dago bere sistema eragilerako ezarpen pertsonalizaturik?

Ezarpenak daude hor, baina ezarpen desberdinak dira. Hemen sistema eragilea konfiguratzen dugu datu-baseak gauza hau nola erabiliko duen kontuan hartuta. Eta orain nora joan behar dugun zehazten duten parametroak daude, konformazioa adibidez. Hau da, hainbeste baliabide behar ditugu, orain jango ditugu. Honen ostean, Amazon RDS-k baliabide hauek estutu egiten ditu, eta hor errendimendua jaisten da. Jendea gai honekin nahasten hasten den istorio indibidualak daude. Batzuetan nahiko arrakastaz ere bai. Baina honek ez du zerikusirik OS ezarpenekin. Hodeia pirateatzea bezalakoa da. Hori beste istorio bat da.

Zergatik ez du Orrialde erraldoi Transparentek eraginik Huge TLBrekin alderatuta?

Ez eman. Modu askotan azal daiteke. Baina egia esan, besterik gabe, ez dute ematen. Zein da PostgreSQL-ren historia? Abiaraztean, partekatutako memoria zati handi bat esleitzen du. Gardenak diren ala ez guztiz ez du garrantzirik. Hasieran nabarmentzeak dena azaltzen du. Eta memoria asko badago eta shared_memory segmentua berreraiki behar baduzu, orduan garrantzitsuak izango dira Transparenten orrialde erraldoiak. PostgreSQL-n, hasieran zati handi batean esleitzen da eta kitto, eta gero ez da ezer berezirik gertatzen. Erabili dezakezu, noski, baina zerbait berriro esleitzen duenean shared_memory usteltzea lortzeko aukera dago. PostgreSQL-k ez daki honen berri.

Iturria: www.habr.com