Linux regulēšana, lai uzlabotu PostgreSQL veiktspēju. Iļja Kosmodemjanskis

Iļjas Kosmodemjanska 2015. gada ziņojuma "Linux tuning, lai uzlabotu PostgreSQL veiktspēju" atšifrējums

Atruna: atzīmēju, ka šis ziņojums ir datēts ar 2015. gada novembri — ir pagājuši vairāk nekā 4 gadi un pagājis daudz laika. Pārskatā aplūkotā versija 9.4 vairs netiek atbalstīta. Pēdējo 4 gadu laikā ir izlaistas 5 jaunas PostgreSQL versijas un 15 Linux kodola versijas. Ja jūs pārrakstīsit šos fragmentus, jūs saņemsiet citu ziņojumu. Bet šeit mēs apsveram fundamentālu Linux regulēšanu PostgreSQL, kas joprojām ir aktuāla šodien.

Mani sauc Iļja Kosmodemjanskis. Es strādāju PostgreSQL-Consulting. Un tagad es nedaudz parunāšu par to, ko darīt ar Linux saistībā ar datu bāzēm kopumā un konkrēti PostgreSQL, jo principi ir diezgan līdzīgi.

Par ko mēs runāsim? Ja jūs sazināties ar PostgreSQL, tad zināmā mērā jums ir jābūt UNIX administratoram. Ko tas nozīmē? Ja salīdzinām Oracle un PostgreSQL, tad Oracle jums ir jābūt 80% DBA datu bāzes administratoram un 20% Linux administratoram.

Ar PostgreSQL tas ir nedaudz sarežģītāk. Izmantojot PostgreSQL, jums ir daudz labāk jāizprot, kā darbojas Linux. Un tajā pašā laikā nedaudz paskriet pēc lokomotīves, jo pēdējā laikā viss ir diezgan smuki atjaunināts. Un tiek izlaisti jauni kodoli, parādās jauna funkcionalitāte, uzlabojas veiktspēja utt.

Kāpēc mēs runājam par Linux? Pavisam ne tāpēc, ka esam Linux konferencē Pēteris, bet gan tāpēc, ka mūsdienu apstākļos viena no attaisnotākajām operētājsistēmām datu bāzu lietošanai kopumā un jo īpaši PostgreSQL ir Linux. Jo FreeBSD diemžēl attīstās kaut kādā ļoti dīvainā virzienā. Un būs problēmas gan ar sniegumu, gan ar daudzām citām lietām. PostgreSQL veiktspēja operētājsistēmā Windows parasti ir atsevišķa nopietna problēma, kuras pamatā ir fakts, ka sistēmai Windows nav tādas pašas koplietotās atmiņas kā UNIX, savukārt PostgreSQL viss ir saistīts ar to, jo tā ir vairāku procesu sistēma.

Un es domāju, ka visus mazāk interesē tāda eksotika kā Solaris, tāpēc ejam.

Mūsdienu Linux izplatīšanā ir vairāk nekā 1 syctl opciju atkarībā no tā, kā veidojat kodolu. Tajā pašā laikā, ja mēs skatāmies uz dažādiem riekstiem, mēs varam kaut ko pielāgot daudzos veidos. Ir failu sistēmas parametri, kā tos uzstādīt. Ja jums ir jautājumi par to, kā to palaist: ko iespējot BIOS, kā konfigurēt aparatūru utt.

Šis ir ļoti liels apjoms, ko var apspriest vairākas dienas, un ne vienā īsā ziņojumā, bet tagad es koncentrēšos uz būtiskām lietām, kā izvairīties no tiem grābekļiem, kas garantēti neļaus jums labi izmantot datubāzi uz Linux, ja jūs nelabojiet tos. Un tajā pašā laikā svarīgs ir tas, ka daudzi noklusējuma parametri nav iekļauti iestatījumos, kas ir pareizi datubāzei. Tas ir, pēc noklusējuma tas darbosies slikti vai nedarbosies vispār.

Kādi tradicionālie regulēšanas mērķi ir Linux? Es domāju, ka, tā kā jūs visi nodarbojaties ar Linux administrēšanu, nav īpaši jāskaidro, kādi ir mērķi.

Jūs varat noregulēt:

• PROCESORS.
• Atmiņas
• Uzglabāšana.
• Cits. Mēs par to runāsim beigās, lai uzkodētu. Pat, piemēram, tādi parametri kā enerģijas taupīšanas politika var ietekmēt veiktspēju ļoti neparedzamā un ne tajā patīkamākajā veidā.

Kāda ir PostgreSQL un datu bāzes specifika kopumā? Problēma ir tā, ka jūs nevarat nomainīt nevienu atsevišķu uzgriezni un redzēt, ka mūsu veiktspēja ir ievērojami uzlabojusies.

Jā, tādi sīkrīki ir, taču datu bāze ir sarežģīta lieta. Tas mijiedarbojas ar visiem servera rīcībā esošajiem resursiem, un tas dod priekšroku pilnīgai mijiedarbībai. Ja paskatās uz Oracle aktuālajiem ieteikumiem, kā lietot saimnieku OS, tad tas būs kā joks par to mongoļu kosmonautu – pabaro suni un neko neaiztiec. Dosim datubāzei visus resursus, pati datu bāze visu sakārtos.

Principā zināmā mērā situācija ir tieši tāda pati ar PostgreSQL. Atšķirība ir tāda, ka datu bāze vēl nespēj visus resursus paņemt sev, t.i., kaut kur Linux līmenī tas viss ir jāsakārto pašam.

Galvenā ideja ir nevis izvēlēties vienu mērķi un sākt to noregulēt, piemēram, atmiņu, centrālo procesoru vai kaut ko tamlīdzīgu, bet gan analizēt darba slodzi un mēģināt pēc iespējas uzlabot caurlaidspēju, lai tā būtu slodze, kādu to radīja labi programmētāji. mums, tostarp mūsu lietotājiem.

Šeit ir attēls, lai izskaidrotu, kas tas ir. Ir Linux OS buferis un koplietojamā atmiņa, un ir PostgreSQL koplietotie buferi. PostgreSQL atšķirībā no Oracle darbojas tieši caur kodola buferi, t.i., lai lapa no diska nonāktu tās koplietojamā atmiņā, tai ir jāiet caur kodola buferi un atpakaļ, tieši tāda pati situācija.

Diski dzīvo saskaņā ar šo sistēmu. Es to uzzīmēju kā diskus. Patiesībā var būt RAID kontrolieris utt.

Un šī ievade-izeja tā vai citādi notiek caur šo lietu.

PostgreSQL ir klasiska datu bāze. Iekšā ir lapa. Un visa ievade un izvade notiek, izmantojot lapas. Mēs ceļam blokus atmiņā ar lapām. Un, ja nekas nenotika, mēs tos vienkārši nolasām, tad pakāpeniski tie pazūd no šīs kešatmiņas, no koplietotajiem buferiem un nonāk atpakaļ diskā.

Ja kaut kur kaut ko nomainām, tad visa lapa tiek atzīmēta kā netīra. Es tos šeit atzīmēju zilā krāsā. Un tas nozīmē, ka šī lapa ir jāsinhronizē ar bloku krātuvi. Tas ir, kad mēs to sasmērējām, mēs izdarījām ierakstu WAL. Un kādā brīnišķīgā laika brīdī nāca parādība, ko sauc par kontrolpunktu. Un šajā žurnālā tika ierakstīta informācija, ka viņš ir ieradies. Un tas nozīmē, ka visas netīrās lapas, kas tajā brīdī atradās šajos koplietotajos buferos, tika sinhronizētas ar atmiņas disku, izmantojot fsync caur kodola buferi.

Kāpēc tas tiek darīts? Ja pazuda spriegums, tad nesanāca situācija, ka pazuda visi dati. Neatlaidīgā atmiņa, par kuru mums visi stāstīja, pagaidām ir datubāzes teorijā - tā ir gaiša nākotne, uz kuru mēs, protams, tiecamies un mums patīk, bet pagaidām viņi dzīvo mīnus 20 gados. Un, protams, tas viss ir jāuzrauga.

Un uzdevums palielināt caurlaidspēju ir precīzi noregulēt visus šos posmus, lai tas viss ātri pārvietotos uz priekšu un atpakaļ. Koplietotā atmiņa būtībā ir lapas kešatmiņa. PostgreSQL mēs nosūtījām atlases vaicājumu vai kaut ko citu, tas izguva šos datus no diska. Viņi nokļuva koplietotajos buferos. Attiecīgi, lai tas darbotos labāk, ir jābūt daudz atmiņas.

Lai tas viss darbotos labi un ātri, jums visos posmos ir pareizi jākonfigurē operētājsistēma. Un izvēlies sabalansētu aparatūru, jo ja tev ir nelīdzsvarotība kādā vietā, tad var uztaisīt daudz atmiņas, bet tā netiks apkalpota pietiekamā ātrumā.

Un apskatīsim katru no šiem punktiem.

Lai šīs lapas pārvietotos ātrāk un atpakaļ, jums ir jāsasniedz tālāk norādītais.

• Pirmkārt, jums ir efektīvāk jāstrādā ar atmiņu.
• Otrkārt, šai pārejai, kad lapas no atmiņas pāriet uz disku, vajadzētu būt efektīvākai.
• Un treškārt, jābūt labiem diskiem.

Ja serverī ir 512 GB RAM un visa tā nonāk SATA cietajā diskā bez kešatmiņas, tad viss datu bāzes serveris pārvēršas ne tikai par ķirbi, bet par ķirbi ar SATA interfeisu. Jūs tajā nonāksit tieši. Un nekas tevi neglābs.

Runājot par pirmo punktu ar atmiņu, ir trīs lietas, kas dzīvi var ļoti sarežģīt.

Pirmais no tiem ir NUMA. NUMA ir lieta, kas radīta, lai uzlabotu veiktspēju. Atkarībā no darba slodzes dažādas lietas var optimizēt. Un jaunajā pašreizējā formā tas nav īpaši piemērots tādām lietojumprogrammām kā datu bāzes, kas intensīvi izmanto lapu kešatmiņas koplietotos buferus.

Īsumā. Kā noteikt, vai ar NUMA kaut kas nav kārtībā? Jums ir kaut kāds nepatīkams klauvējiens, pēkšņi kāds CPU ir pārslogots. Tajā pašā laikā jūs analizējat vaicājumus programmā PostgreSQL un redzat, ka tur nav nekā līdzīga. Šiem vaicājumiem nevajadzētu būt tik intensīviem CPU. Jūs varat to noķert ilgu laiku. Jau no paša sākuma ir vieglāk izmantot pareizo ieteikumu par NUMA konfigurēšanu PostgreSQL.

Kas īsti notiek? NUMA apzīmē Non-Uniform Memory Access. Kāda jēga? Jums ir centrālais procesors, blakus tam ir tā lokālā atmiņa. Un šie atmiņas savienojumi var piesaistīt atmiņu no citiem CPU.

Ja tu skrien numactl --hardware, tad jūs saņemsiet tik lielu lapu. Cita starpā būs distanču laukums. Būs cipari - 10-20, kaut kas līdzīgs. Šie skaitļi ir nekas cits kā apiņu skaits, lai uzņemtu šo attālo atmiņu un izmantotu to lokāli. Principā laba doma. Tas ievērojami paātrina veiktspēju dažādās darba slodzēs.

Tagad iedomājieties, ka jums ir viens centrālais procesors, kas vispirms mēģina izmantot savu vietējo atmiņu, pēc tam mēģina izvilkt citu atmiņu, izmantojot starpsavienojumu. Un šis centrālais procesors iegūst visu jūsu PostgreSQL lapas kešatmiņu — tas ir, daži gigabaiti. Jūs vienmēr saņemat sliktāko gadījumu, jo CPU pašā modulī parasti ir maz atmiņas. Un visa apkalpotā atmiņa iet caur šiem starpsavienojumiem. Tas izrādās lēni un skumji. Un jūsu procesors, kas apkalpo šo mezglu, ir pastāvīgi pārslogots. Un šīs atmiņas piekļuves laiks ir slikts, lēns. Šī ir situācija, kuru jūs nevēlaties, ja izmantojat šo datu bāzei.

Tāpēc pareizāks datu bāzes variants ir, lai Linux operētājsistēma vispār nezinātu, kas tur notiek. Lai tā piekļūtu atmiņai tāpat kā.

Kāpēc ir tā, ka? Šķiet, ka vajadzētu būt otrādi. Tas notiek viena vienkārša iemesla dēļ: mums ir nepieciešams daudz atmiņas lapas kešatmiņai - desmitiem, simtiem gigabaitu.

Un, ja mēs to visu piešķiram un kešatmiņā saglabāsim savus datus, tad ieguvums no kešatmiņas izmantošanas būs ievērojami lielāks nekā ieguvums no tik sarežģītas piekļuves atmiņai. Un tādējādi mēs iegūsim nesalīdzināmus ieguvumus salīdzinājumā ar to, ka atmiņai piekļūsim efektīvāk, izmantojot NUMA.

Līdz ar to te šobrīd ir divas pieejas, kamēr nav pienākusi gaišā nākotne un pati datu bāze nespēj saprast, uz kuriem CPU tā darbojas un no kurienes kaut kas jāvelk.

Tāpēc pareizā pieeja ir pilnībā atspējot NUMA, piemēram, pārstartējot. Vairumā gadījumu laimests ir tādā apjomā, ka jautājums par to, kurš ir labāks, vispār nerodas.

Ir vēl viens variants. Mēs to izmantojam biežāk nekā pirmo, jo, kad klients vēršas pie mums pēc atbalsta, servera pārstartēšana viņam ir liela problēma. Viņam tur ir bizness. Un viņiem rodas problēmas NUMA dēļ. Tāpēc mēs cenšamies to atspējot mazāk invazīvos veidos nekā atsāknēšana, taču esiet uzmanīgi, lai pārbaudītu, vai tas ir atspējots. Jo, kā rāda pieredze, ir labi, ka mēs atspējojam NUMA galvenajā PostgreSQL procesā, taču tas nemaz nav nepieciešams, lai tas darbotos. Mums ir jāpārbauda un jāpārliecinās, vai viņa patiešām ir izslēgta.

Ir labs Roberta Hāsa ieraksts. Šis ir viens no PostgreSQL apņēmējiem. Viens no galvenajiem visu zema līmeņa sēņu izstrādātājiem. Un, ja sekojat saitēm no šīs ziņas, tajās ir aprakstīti vairāki krāsaini stāsti par to, kā NUMA apgrūtināja cilvēku dzīvi. Skatieties, izpētiet sistēmas administratora kontrolsarakstu par to, kas ir jākonfigurē serverī, lai mūsu datu bāze darbotos labi. Šie iestatījumi ir jāpieraksta un jāpārbauda, ​​jo pretējā gadījumā tas nebūs īpaši labi.

Lūdzu, ņemiet vērā, ka tas attiecas uz visiem iestatījumiem, par kuriem es runāšu. Bet parasti datu bāzes tiek apkopotas galvenā-slave režīmā, lai nodrošinātu kļūdu toleranci. Neaizmirstiet veikt šos iestatījumus uz vergu, jo kādu dienu jums būs negadījums, un jūs pārslēgsities uz vergu, un tas kļūs par galveno.

Ārkārtas situācijā, kad viss ir ļoti slikti, tavs telefons nepārtraukti zvana un priekšnieks skrien ar lielu nūju, tev nebūs laika domāt par pārbaudi. Un rezultāti var būt diezgan postoši.

Nākamais punkts ir milzīgas lapas. Lielas lapas ir grūti pārbaudīt atsevišķi, un nav jēgas to darīt, lai gan ir kritēriji, kas to var izdarīt. Tie ir viegli Google.

Kāda jēga? Jums ir ne pārāk dārgs serveris ar lielu RAM, piemēram, vairāk nekā 30 GB. Jūs neizmantojat lielas lapas. Tas nozīmē, ka atmiņas lietojuma ziņā jums noteikti ir pieskaitāmas izmaksas. Un šīs pieskaitāmās izmaksas ir tālu no patīkamākajām.

Kāpēc ir tā, ka? Tātad, kas notiek? Operētājsistēma atmiņu piešķir mazos gabaliņos. Tas ir tik ērti, tā tas notika vēsturiski. Un, ja mēs iedziļināmies detaļās, OS ir jāpārvērš virtuālās adreses fiziskās. Un šis process nav no vienkāršākajiem, tāpēc operētājsistēma šīs darbības rezultātu saglabā kešatmiņā Translation Lookaside Buffer (TLB).

Un tā kā TLB ir kešatmiņa, šajā situācijā rodas visas kešatmiņai raksturīgās problēmas. Pirmkārt, ja jums ir daudz RAM un tas viss ir sadalīts mazos gabalos, tad šis buferis kļūst ļoti liels. Un, ja kešatmiņa ir liela, tad meklēšana tajā notiek lēnāk. Pieskaitāmās izmaksas ir veselīgas un tās pašas aizņem vietu, t.i., RAM patērē kaut kas nepareizs. Šoreiz.

Divi - jo vairāk palielinās kešatmiņa šādā situācijā, jo lielāka iespēja, ka jums būs kešatmiņas neveiksmes. Un šīs kešatmiņas efektivitāte strauji samazinās, palielinoties tās izmēram. Tāpēc operētājsistēmas nāca klajā ar vienkāršu pieeju. Tas ir izmantots Linux ilgu laiku. Tas parādījās FreeBSD ne tik sen. Bet mēs runājam par Linux. Tās ir milzīgas lapas.

Un te jāatzīmē, ka milzīgas lapas kā ideju sākotnēji bīdīja kopienas, kurās bija Oracle un IBM, t.i., datubāzu ražotāji stingri domāja, ka tas noderēs arī datu bāzēm.

Un kā to var sadraudzēties ar PostgreSQL? Pirmkārt, Linux kodolā ir jāiespējo milzīgas lapas.

Otrkārt, tie ir skaidri jānorāda ar sysctl parametru - cik daudz to ir. Šeit norādītie numuri ir no kāda veca servera. Varat aprēķināt, cik daudz koplietojamo buferu jums ir, lai tur varētu ietilpt milzīgas lapas.

Un, ja viss jūsu serveris ir veltīts PostgreSQL, tad labs sākumpunkts ir piešķirt vai nu 25% no RAM koplietotajiem buferiem vai 75%, ja esat pārliecināts, ka jūsu datu bāze noteikti ietilps šajos 75%. Sākuma punkts viens. Un ņemiet vērā, ja jums ir 256 GB RAM, tad attiecīgi jums būs 64 GB lieli buferi. Aprēķiniet aptuveni ar kādu rezervi - kāds šis skaitlis ir jāiestata.

Pirms versijas 9.2 (ja nemaldos, kopš versijas 8.2) bija iespējams savienot PostgreSQL ar milzīgām lapām, izmantojot trešās puses bibliotēku. Un tas vienmēr ir jādara. Pirmkārt, jums ir nepieciešams kodols, lai varētu pareizi piešķirt milzīgas lapas. Un, otrkārt, lai lietojumprogramma, kas ar viņiem strādā, varētu tos izmantot. Tas tiks izmantots ne tikai tādā veidā. Tā kā PostgreSQL piešķīra atmiņu sistēmas 5 stilā, to var izdarīt, izmantojot libhugetlbfs - tas ir pilns bibliotēkas nosaukums.

Programmā 9.3 tika uzlabota PostgreSQL veiktspēja, strādājot ar atmiņu, un tika atmesta sistēmas 5 atmiņas piešķiršanas metode. Visi bija ļoti apmierināti, jo pretējā gadījumā jūs mēģināt palaist divus PostgreSQL gadījumus vienā mašīnā, un viņš saka, ka man nav pietiekami daudz koplietojamās atmiņas. Un viņš saka, ka sysctl ir jālabo. Un ir tāds sysctl, ka vēl vajag pārstartēt utt.. Vispār visi bija apmierināti. Taču mmap atmiņas piešķiršana pārtrauca milzīgu lapu izmantošanu. Lielākā daļa mūsu klientu izmanto lielus koplietotus buferus. Un ļoti ieteicām nepāriet uz 9.3, jo tur pieskaitāmās izmaksas sāka rēķināt labās proporcijās.

Taču sabiedrība pievērsa uzmanību šai problēmai, un 9.4 versijā viņi ļoti labi pārstrādāja šo notikumu. Un 9.4 failā postgresql.conf parādījās parametrs, kurā varat iespējot mēģinājumu, ieslēgt vai izslēgt.

Mēģināt ir drošākais variants. Kad PostgreSQL startē un piešķir koplietojamo atmiņu, tas mēģina iegūt šo atmiņu no lielajām lapām. Un, ja tas nedarbojas, tas atgriežas normālā atlasē. Un, ja jums ir FreeBSD vai Solaris, varat mēģināt, tas vienmēr ir droši.

Ja tas ir ieslēgts, tas vienkārši nesākas, ja nevar atlasīt no lielajām lapām. Šeit jau runa ir par to, kurš un kas ir jaukāks. Bet, ja esat pamēģinājuši, tad pārbaudiet, vai jums patiešām ir izcelts tas, kas jums nepieciešams, jo ir daudz iespēju kļūdīties. Pašlaik šī funkcionalitāte darbojas tikai operētājsistēmā Linux.

Vēl viena neliela piezīme, pirms dodamies tālāk. Caurspīdīgas milzīgas lapas vēl nav par PostgreSQL. Viņš nevar tos izmantot normāli. Un ar Transparent milzīgām lapām šādai darba slodzei, kad ir nepieciešams liels koplietošanas atmiņas apjoms, priekšrocības ir tikai ļoti liela apjoma dēļ. Ja jums ir terabaiti atmiņas, tas var noderēt. Ja runājam par ikdienišķākām aplikācijām, kad tavā mašīnā ir 32, 64, 128, 256 GB atmiņas, tad parastās milzīgās lapas ir Ok, un mēs vienkārši atspējojam Transparent.

Un pēdējais, kas attiecas uz atmiņu, nav tieši saistīts ar fruutu, tas var patiešām sabojāt jūsu dzīvi. Visu caurlaidspēju lielā mērā ietekmēs fakts, ka serveris pastāvīgi apmainās.

Un tas būs ļoti nepatīkami vairākos veidos. Un galvenā problēma ir tā, ka mūsdienu kodoli darbojas nedaudz savādāk nekā vecāki Linux kodoli. Un šai lietai ir diezgan nepatīkami uzkāpt, jo, kad mēs runājam par kaut kādu darbu ar mijmaiņu, tas beidzas ar OOM-killer nelaiku ierašanos. Un OOM-killer, kas neieradās savlaicīgi un atmeta PostgreSQL, ir nepatīkams. Par to zinās visi, tas ir, līdz pēdējam lietotājam.

Kas notiek? Jums tur ir daudz RAM, viss darbojas labi. Bet kaut kādu iemeslu dēļ serveris uzkaras mijmaiņas režīmā un tāpēc palēninās. Šķiet, ka ir daudz atmiņas, bet tas notiek.

Iepriekš mēs ieteicām iestatīt vm.swappiness uz nulli, t.i., atspējot mijmaiņu. Iepriekš šķita, ka 32 GB RAM un attiecīgie koplietotie buferi ir milzīgs daudzums. Mijmaiņas galvenais mērķis ir, lai būtu kur izmest garozu, ja mēs nokristu. Un tas vairs nebija īpaši izpildīts. Un ko tad tu darīsi ar šo garozu? Tas ir uzdevums, kurā nav īsti skaidrs, kāpēc ir nepieciešams mijmaiņas pakalpojums, īpaši šāda izmēra.

Bet modernākās, t.i., trešajā kodola versijās, uzvedība ir mainījusies. Un, ja jūs iestatāt swap uz nulli, t.i., izslēdzat to, tad agri vai vēlu, pat ja paliks nedaudz RAM, pie jums atnāks OOM killer, lai nogalinātu intensīvākos patērētājus. Jo viņš uzskatīs, ka pie tādas slodzes mums vēl mazliet palicis un mēs izleksim ārā, t.i., nevis pienaglot sistēmas procesu, bet gan nolakot kaut ko mazāk svarīgu. Šis mazāk svarīgais būs intensīvs koplietošanas atmiņas patērētājs, proti, pasta pārzinis. Un pēc tam būs labi, ja pamatne nebūs jāatjauno.

Tāpēc tagad noklusējuma, cik atceros, lielākā daļa distribūciju ir kaut kur ap 6, t.i., kurā brīdī jāsāk lietot swap atkarībā no tā, cik daudz atmiņas paliek. Tagad mēs iesakām iestatīt vm.swappiness = 1, jo tas praktiski izslēdz to, bet nedod tādus pašus efektus kā ar OOM-killer, kas negaidīti ieradās un nogalināja visu.

Ko tālāk? Kad mēs runājam par datu bāzu veiktspēju un pamazām virzāmies uz diskiem, visi sāk saķert galvu. Jo patiesība, ka disks ir lēns un atmiņa ir ātra, visiem ir pazīstama no bērnības. Un visi zina, ka datu bāzē būs problēmas ar diska veiktspēju.

Galvenā PostgreSQL veiktspējas problēma, kas saistīta ar kontrolpunktu kāpumiem, nerodas, jo disks ir lēns. Visticamāk, tas ir saistīts ar faktu, ka atmiņa un diska joslas platums nav līdzsvaroti. Tomēr dažādās vietās tie var nebūt līdzsvaroti. PostgreSQL nav konfigurēts, OS nav konfigurēta, aparatūra nav konfigurēta un aparatūra ir nepareiza. Un šī problēma nenotiek tikai tad, ja viss notiek tā, kā vajadzētu, t.i., vai nu nav slodzes, vai arī iestatījumi un aparatūra ir labi atlasīti.

Kas tas ir un kā tas izskatās? Parasti cilvēki, kas strādā ar PostgreSQL, ir iesaistījušies šajā jautājumā vairāk nekā vienu reizi. Es paskaidrošu. Kā jau teicu, PostgreSQL periodiski veic kontrolpunktus, lai koplietotajā atmiņā esošās netīrās lapas izmestu diskā. Ja mums ir daudz koplietojamās atmiņas, tad kontrolpunkts sāk intensīvi ietekmēt disku, jo tas šīs lapas izmet ar fsync. Tas nonāk kodola buferī un tiek ierakstīts diskos, izmantojot fsync. Un, ja šī biznesa apjoms ir liels, tad mēs varam novērot nepatīkamu efektu, proti, ļoti lielu disku noslodzi.

Šeit man ir divas bildes. Tagad es paskaidrošu, kas tas ir. Tie ir divi ar laiku saistīti grafiki. Pirmais grafiks ir diska izmantošana. Šeit tas šajā brīdī sasniedz gandrīz 90%. Ja jums ir datu bāzes kļūme ar fiziskiem diskiem un RAID kontrollera izmantošana ir 90%, tad tā ir slikta ziņa. Tas nozīmē, ka vēl nedaudz, un tas sasniegs 100, un I/O apstāsies.

Ja jums ir disku masīvs, tas ir nedaudz atšķirīgs stāsts. Tas ir atkarīgs no tā, kā tas ir konfigurēts, kāda veida masīvs tas ir utt.

Un paralēli šeit tiek konfigurēts grafiks no iekšējā postgres skata, kas stāsta, kā notiek kontrolpunkts. Un zaļā krāsa šeit parāda, cik daudz buferu, šīs netīrās lapas, tajā brīdī ieradās šajā sinhronizācijas kontrolpunktā. Un tas ir galvenais, kas jums šeit jāzina. Mēs redzam, ka mums šeit ir daudz lapu un kādā brīdī mēs uzsitām uz tāfeles, tas ir, mēs rakstījām un rakstījām, šeit diska sistēma ir nepārprotami ļoti noslogota. Un mūsu kontrolpunktam ir ļoti spēcīga ietekme uz disku. Ideālā gadījumā situācijai vajadzētu izskatīties vairāk šādai, t.i., mums šeit bija mazāk ierakstu. Un mēs varam to labot ar iestatījumiem, lai tas būtu arī turpmāk. Tas ir, pārstrāde ir neliela, bet kaut kur mēs šeit kaut ko rakstām.

Kas jādara, lai šo problēmu pārvarētu? Ja esat apturējis IO zem datu bāzes, tas nozīmē, ka visi lietotāji, kuri ieradās, lai izpildītu savus pieprasījumus, gaidīs.

Ja paskatās no Linux viedokļa, ja paņēmāt labu aparatūru, pareizi konfigurējāt, normāli konfigurējāt PostgreSQL, lai tas šos kontrolpunktus padarītu retāk, izkliedētu tos laika gaitā savā starpā, tad jūs ieejat noklusējuma Debian parametros. Lielākajai daļai Linux izplatījumu šis attēls ir: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Ko tas nozīmē? Viens pietvīkums dēmons parādījās no kodola 2.6. Pdglush, atkarībā no tā, kurš kuru izmanto, kas nodarbojas ar netīro lapu izmešanu fonā no kodola bufera un izmešanu, kad ir nepieciešams izmest netīrās lapas neatkarīgi no tā, kad fona atmešana nepalīdz.

Kad nāk fons? Ja 10% no kopējās serverī pieejamās RAM ir aizņemtas netīrās lapas kodola buferī, fonā tiek izsaukta īpaša norakstīšanas funkcija. Kāpēc tas ir fons? Kā parametrs tas ņem vērā, cik lappušu norakstīt. Un, teiksim, viņš noraksta N lapas. Un uz kādu laiku šī lieta aizmieg. Un tad viņa atkal atnāk un pārkopē vēl dažas lapas.

Šis ir ārkārtīgi vienkāršs stāsts. Problēma šeit ir kā ar peldbaseinu, kad tas ielej vienā caurulē, tas ieplūst citā. Mūsu kontrolpunkts ieradās un, ja tas nosūtīja dažas netīras lapas izmešanai, tad pamazām viss tiks glīti atrisināts no kodola bufera pgflush.

Ja šīs netīrās lapas turpina uzkrāties, tās sakrājas līdz 20%, pēc tam OS prioritāte ir visu norakstīt uz diska, jo pietrūks strāvas un mums viss būs slikti. Mēs, piemēram, pazaudēsim šos datus.

Kāds ir triks? Viltība ir tāda, ka šie parametri mūsdienu pasaulē ir 20 un 10% no kopējās RAM, kas atrodas iekārtā, tie ir absolūti milzīgi jebkuras diska sistēmas caurlaidspējas ziņā.

Iedomājieties, ka jums ir 128 GB RAM. Jūsu diska sistēmā nonāk 12,8 GB. Un neatkarīgi no tā, kāda kešatmiņa jums tur ir, neatkarīgi no tā, kāds masīvs jums tur ir, tie nedarbosies tik ilgi.

Tāpēc mēs iesakām nekavējoties pielāgot šos skaitļus, pamatojoties uz jūsu RAID kontrollera iespējām. Es šeit nekavējoties sniedzu ieteikumu kontrolierim, kuram ir 512 MB kešatmiņas.

Viss tiek uzskatīts par ļoti vienkāršu. Varat ievietot vm.dirty_background baitos. Un šie iestatījumi atceļ iepriekšējos divus. Vai nu attiecība ir pēc noklusējuma, vai arī tie, kuriem ir baiti, ir aktivizēti, tad darbosies tie, kuriem ir baiti. Bet tā kā esmu DBA konsultante un strādāju ar dažādiem klientiem, tad cenšos zīmēt salmiņus un tāpēc ja baitos, tad baitos. Neviens nedeva nekādu garantiju, ka labs admins nepievienos serverim vairāk atmiņas, pārstartēs to un cipars paliks nemainīgs. Vienkārši aprēķiniet šos skaitļus, lai ar garantiju viss ietilptu.

Kas notiks, ja tu neiederēsies? Esmu rakstījis, ka jebkurš pietvīkums tiek efektīvi apturēts, bet patiesībā tas ir runas skaitlis. Operētājsistēmai ir liela problēma - tajā ir daudz netīru lapu, tāpēc jūsu klientu ģenerētais IO faktiski tiek apturēts, t.i., aplikācija ir atnākusi nosūtīt sql vaicājumu datu bāzei, tā gaida. Jebkurai ievadei/izvadei tajā ir zemākā prioritāte, jo datu bāzi aizņem kontrolpunkts. Un kad viņa pabeigs, ir pilnīgi neskaidrs. Un, kad esat sasniedzis nefona skalošanu, tas nozīmē, ka tas aizņem visu jūsu IO. Un līdz tas beigsies, jūs neko nedarīsit.

Šeit ir vēl divi svarīgi punkti, kas ir ārpus šī ziņojuma darbības jomas. Šiem iestatījumiem ir jāatbilst postgresql.conf iestatījumiem, t.i., kontrolpunktu iestatījumiem. Un jūsu diska sistēmai jābūt atbilstoši konfigurētai. Ja jums ir RAID kešatmiņa, tam ir jābūt akumulatoram. Cilvēki pērk RAID ar labu kešatmiņu bez akumulatora. Ja jums ir SSD diski RAID, tad tiem jābūt serveriem, tur jābūt kondensatoriem. Šeit ir detalizēts kontrolsaraksts. Šajā saitē ir mans ziņojums par veiktspējas diska konfigurēšanu programmā PostgreSQL. Tur ir visi šie kontrolsaraksti.

Kas vēl var ļoti sarežģīt dzīvi? Tie ir divi parametri. Tie ir salīdzinoši jauni. Pēc noklusējuma tos var iekļaut dažādās lietojumprogrammās. Un tie var padarīt dzīvi tikpat sarežģītu, ja tie ir nepareizi ieslēgti.

Ir divas salīdzinoši jaunas lietas. Tie jau ir parādījušies trešajā kodolā. Tas ir sched_migration_cost nanosekundēs un sched_autogroup_enabled, kas pēc noklusējuma ir viens.

Un kā viņi sabojā tavu dzīvi? Kas ir sched_migration_cost? Operētājsistēmā Linux plānotājs var migrēt procesu no viena CPU uz citu. Un PostgreSQL, kas izpilda vaicājumus, migrēšana uz citu CPU ir pilnīgi neskaidra. No operētājsistēmas viedokļa, pārslēdzot logus starp OpenOffice un termināli, tas var būt labi, taču datu bāzei tas ir ļoti slikti. Tāpēc saprātīga politika ir migrācijas_izmaksas iestatīt uz kādu lielu vērtību, vismaz vairākus tūkstošus nanosekunžu.

Ko tas nozīmēs plānotājam? Tiks uzskatīts, ka šajā laikā process joprojām ir karsts. Tas ir, ja jums ir ilgstošs darījums, kas kaut ko dara ilgu laiku, plānotājs to sapratīs. Viņš pieņems, ka, kamēr šis taimauts nav pagājis, šis process nekur nav jāmigrē. Ja tajā pašā laikā process kaut ko dara, tad tas nekur netiks migrēts, tas mierīgi strādās pie CPU, kas tam tika piešķirts. Un rezultāts ir lielisks.

Otrais punkts ir autogrupa. Ir laba ideja konkrētām darba slodzēm, kas nav saistītas ar modernām datu bāzēm - tas ir, lai grupētu procesus pēc virtuālā termināļa, no kura tie tiek palaisti. Tas ir ērti dažiem uzdevumiem. Praksē PostgreSQL ir vairāku procesu sistēma ar priekšdakšu, kas darbojas no viena termināļa. Jums ir bloķēšanas rakstītājs, kontrolpunkts, un visi jūsu klientu pieprasījumi tiks sagrupēti vienā plānotājā katram CPU. Un viņi tur vienprātīgi gaidīs, kad viņš būs brīvs, lai traucētu viens otram un ilgāk viņu aizņemtu. Tas ir stāsts, kas šādas slodzes gadījumā ir pilnīgi lieks un tāpēc ir jāizslēdz.

Mans kolēģis Aleksejs Ļesovskis veica testus ar vienkāršu pgbench, kur viņš palielināja migration_cost par lielumu un izslēdza autogrupu. Sliktas aparatūras atšķirība bija gandrīz 10%. Postgres adresātu sarakstā notiek diskusija, kurā cilvēki sniedz rezultātus par līdzīgām vaicājuma ātruma izmaiņām ietekmēja 50%. Tādu stāstu ir diezgan daudz.

Un visbeidzot par enerģijas taupīšanas politiku. Labā lieta ir tā, ka Linux tagad var izmantot klēpjdatorā. Un tas it kā labi iztērēs akumulatoru. Taču pēkšņi izrādās, ka tas var notikt arī serverī.

Turklāt, ja īrējat serverus no kāda mitinātāja, tad “labajiem” mitinātājiem ir vienalga, ka jums ir labāka veiktspēja. Viņu uzdevums ir nodrošināt, lai viņu dzelzs tiktu izmantots pēc iespējas efektīvāk. Tāpēc pēc noklusējuma tie var iespējot klēpjdatora enerģijas taupīšanas režīmu operētājsistēmā.

Ja izmantojat šo saturu serverī ar datu bāzi ar lielu slodzi, jūsu izvēle ir acpi_cpufreq + permormance. Pat ar pieprasījumu radīsies problēmas.

Intel_pstate ir nedaudz atšķirīgs draiveris. Un tagad priekšroka tiek dota šim, jo ​​tas ir vēlāk un darbojas labāk.

Un, attiecīgi, gubernators ir tikai sniegums. Ondemand, powersave un viss pārējais neattiecas uz jums.

Iespējojot enerģijas taupīšanu, PostgreSQL skaidrojošās analīzes rezultāti var atšķirties par vairākām kārtām, jo ​​praktiski jūsu datu bāzes centrālais procesors darbosies pilnīgi neparedzamā veidā.

Šie vienumi var būt iekļauti pēc noklusējuma. Uzmanīgi pārbaudiet, vai tas ir ieslēgts pēc noklusējuma. Tā var būt patiešām liela problēma.

Un nobeigumā es vēlējos pateikt paldies puišiem no mūsu PosgreSQL-Consulting DBA komandas, proti, Maksam Bogukam un Aleksejam Lesovskim, kuri katru dienu gūst panākumus šajā jautājumā. Un mēs cenšamies darīt visu iespējamo mūsu klientu labā, lai tas viss viņiem derētu. Tas ir tāpat kā ar aviācijas drošības instrukcijām. Šeit viss ir rakstīts ar asinīm. Katrs no šiem riekstiem ir atrodams kāda veida problēmu procesā. Es priecājos dalīties tajos ar jums.

Jautājumi:

Paldies! Ja, piemēram, uzņēmums vēlas ietaupīt naudu un izvietot datubāzi un lietojumprogrammu loģiku vienā serverī, vai arī uzņēmums seko modīgajai mikropakalpojumu arhitektūru tendencei, kurā PostgreSQL darbojas konteinerā. Kāds ir triks? Sysctl ietekmēs visu kodolu globāli. Es neesmu dzirdējis, ka sysctls būtu kaut kā virtualizēts, lai tie konteinerā strādātu atsevišķi. Ir tikai cgrupa, un tur ir tikai daļa no vadības. Kā ar to var sadzīvot? Vai arī, ja vēlaties veiktspēju, palaidiet PostgreSQL atsevišķā aparatūras serverī un noregulējiet to?

Mēs atbildējām uz jūsu jautājumu aptuveni trīs veidos. Ja mēs nerunājam par aparatūras serveri, kuru var noregulēt utt., tad atpūtieties, bez šiem iestatījumiem viss darbosies labi. Ja jums ir tāda slodze, ka jums ir jāveic šie iestatījumi, tad jūs nonāksit pie dzelzs servera agrāk nekā uz šiem iestatījumiem.

Kāda ir problēma? Ja šī ir virtuālā mašīna, visticamāk, jums būs daudz problēmu, piemēram, ar to, ka lielākajā daļā virtuālo mašīnu diska latentums ir diezgan nekonsekvents. Pat ja diska caurlaidspēja ir laba, tad viena neveiksmīga I/O transakcija, kas īpaši neietekmē vidējo caurlaidspēju, kas notika kontrolpunkta vai rakstīšanas WAL laikā, tad datubāze no tā ļoti cietīs. Un jūs to pamanīsit, pirms saskaraties ar šīm problēmām.

Ja jums ir NGINX tajā pašā serverī, arī jums būs tāda pati problēma. Viņš cīnīsies par kopīgu atmiņu. Un jūs nesasniegsit šeit aprakstītās problēmas.

Bet, no otras puses, daži no šiem parametriem jums joprojām būs aktuāli. Piemēram, iestatiet dirty_ratio ar sysctl, lai tas nebūtu tik traki - jebkurā gadījumā tas palīdzēs. Vienā vai otrā veidā jums būs mijiedarbība ar disku. Un tas būs pēc nepareizā modeļa. Tas parasti ir noklusējuma parametriem, kurus es parādīju. Un jebkurā gadījumā labāk tos mainīt.

Bet var būt problēmas ar NUMA. Piemēram, VmWare labi darbojas ar NUMA ar tieši pretējiem iestatījumiem. Un te ir jāizvēlas - dzelzs serveris vai nedzelzs.

Man ir jautājums par Amazon AWS. Viņiem ir iepriekš konfigurēti attēli. Viens no tiem saucas Amazon RDS. Vai viņu operētājsistēmai ir kādi pielāgoti iestatījumi?

Tur ir iestatījumi, taču tie ir atšķirīgi iestatījumi. Šeit mēs konfigurējam operētājsistēmu attiecībā uz to, kā datu bāze izmantos šo lietu. Un ir parametri, kas nosaka, kur mums tagad jāiet, piemēram, formēšana. Tas ir, mums vajag tik daudz resursu, mēs tagad tos apēdīsim. Pēc tam Amazon RDS palielina šos resursus, un veiktspēja samazinās. Ir atsevišķi stāsti par to, kā cilvēki sāk sajaukties ar šo lietu. Dažreiz pat diezgan veiksmīgi. Bet tam nav nekāda sakara ar OS iestatījumiem. Tas ir tāpat kā mākoņa uzlaušana. Tas ir cits stāsts.

Kāpēc Transparent milzīgajām lapām nav nekāda efekta salīdzinājumā ar milzīgo TLB?

Nedod. To var izskaidrot dažādos veidos. Bet patiesībā viņi to vienkārši nedod. Kāda ir PostgreSQL vēsture? Startēšanas laikā tas piešķir lielu daļu koplietojamās atmiņas. Neatkarīgi no tā, vai tie ir caurspīdīgi vai nē, ir pilnīgi vienalga. Tas, ka viņi izceļas startā, visu izskaidro. Un, ja ir daudz atmiņas un jums ir jāpārbūvē share_memory segments, tad caurspīdīgas milzīgas lapas būs aktuālas. PostgreSQL sākumā tas vienkārši tiek sadalīts milzīgā daļā, un tas arī viss, un tad tur nenotiek nekas īpašs. Jūs, protams, varat to izmantot, taču pastāv iespēja, ka share_memory tiks bojāta, kad tā kaut ko piešķir atkārtoti. PostgreSQL par to nezina.

Avots: www.habr.com