Linukso-agordado por plibonigi la agadon de PostgreSQL. Ilja Kosmodemjanskij

Transskribo de la raporto (2015) de Ilya Kosmodemyansky "Linuksa agordo por plibonigi PostgreSQL-efikecon"

Malgarantio: Mi rimarkas, ke ĉi tiu raporto estas datita de novembro 2015 - pli ol 4 jaroj pasis kaj multe da tempo pasis. Versio 9.4 diskutita en la raporto ne plu estas subtenata. Dum la pasintaj 4 jaroj, estis 5 novaj eldonoj de PostgreSQL kaj 15 versioj de la Linukso-kerno. Se vi reverkas ĉi tiujn lokojn, vi finos kun malsama raporto. Sed jen fundamenta Linukso-agordado por PostgreSQL, kiu ankoraŭ estas grava hodiaŭ.

Mia nomo estas Ilja Kosmodemjanskij. Mi laboras por PostgreSQL-Consulting firmao. Kaj nun mi parolos iomete pri kion fari kun Linukso rilate al datumbazoj ĝenerale kaj PostgreSQL precipe, ĉar la principoj estas sufiĉe similaj.

Pri kio oni diskutos? Se vi traktas PostgreSQL, tiam vi devas esti UNIX-administranto iagrade. Kion ĝi signifas? Se ni komparas Oracle kaj PostgreSQL, tiam en Oracle vi devas esti 80% DBA-datumbaza administranto kaj 20% Linukso-administranto.

PostgreSQL estas iom pli malfacila. Kun PostgreSQL, vi devas havi multe pli bonan ideon pri kiel funkcias Linukso. Kaj samtempe kuru iom post la lokomotivo, ĉar lastatempe ĉio estas sufiĉe mojosa ĝisdatigita. Kaj novaj kernoj aperas, kaj aperas novaj funkcioj, rendimento pliboniĝas ktp.

Kial ni parolas pri Linukso? Tute ne ĉar ni estas ĉe la Linukso-konferenco Peter, sed ĉar en modernaj kondiĉoj unu el la plej pravigitaj operaciumoj por funkcii kun datumbazoj ĝenerale kaj kun PostgreSQL precipe estas Linukso. Ĉar FreeBSD, bedaŭrinde, disvolviĝas en iu tre stranga direkto. Kaj estos problemoj kun ambaŭ agado kaj multaj aliaj aferoj. La agado de PostgreSQL sur Vindozo estas ĝenerale aparta severa temo, kiu baziĝas sur la fakto, ke Vindozo ne havas tian komunan memoron kiel UNIX, kaj PostgreSQL temas pri ĉi tiu komerco, ĉar ĝi estas plurproceza sistemo.

Kaj ekzotikuloj kiel Solaris, mi opinias, malpli interesas ĉiuj, do ni iru.

Moderna Linukso-distribuo havas pli ol 1 syctl-opciojn, depende de kiel la kerno estas konstruita. Samtempe, se ni rigardas malsamajn nuksojn, tiam ankoraŭ povas esti multaj manieroj ĝustigi ion. Estas dosiersistemaj opcioj pri kiel munti. Se vi havas demandojn pri kiel komenci: kion ebligi en la BIOS, kiel agordi la aparataron, ktp.

Ĉi tio estas tre granda volumo, pri kiu oni povas paroli plurajn tagojn, kaj ne en unu mallonga raporto, sed mi nun koncentriĝos pri gravaj aferoj, kiel eviti tiujn rastilojn, kiuj ne permesos al vi bone funkcii datumbazon en Linukso, se vi ne riparas ilin. . Kaj samtempe grava punkto estas, ke multaj defaŭltaj parametroj ne estas inkluzivitaj en la agordoj ĝustaj por la datumbazo. Tio estas, defaŭlte ĝi funkcios malbone aŭ tute ne funkcios.

Kio estas la tradiciaj agordaj celoj en Linukso? Mi pensas, ke ĉar vi ĉiuj traktas Linuksan administradon, ne necesas klarigi, kiaj celoj estas.

Vi povas agordi:

• CPUoj.
• Memoro.
• Stokado.
• alia. Pri tio ni parolos fine por manĝeto. Eĉ, ekzemple, agordoj kiel energiŝpara politiko povas influi rendimenton en tre neantaŭvidebla kaj ne tre agrabla maniero.

Kio estas la specifaĵoj de PostgreSQL kaj la datumbazo ĝenerale? La problemo estas, ke vi ne povas ĝustigi iun apartan nukson kaj vidi, ke nia agado multe pliboniĝis.

Jes, ekzistas tiaj aparatoj, sed la datumbazo estas komplika afero. Ŝi interagas kun ĉiuj rimedoj, kiujn la servilo havas kaj preferas plene interagi. Se vi rigardas la nunajn gvidliniojn de Oracle pri kiel uzi gastigantan OS, estas kiel tiu mongola astronaŭto ŝerco - nutru la hundon kaj nenion tuŝu. Ni donu al la datumbazo ĉiujn rimedojn, la datumbazo mem detruos ĉion.

Principe, iagrade, la situacio estas ĝuste la sama kun PostgreSQL. La diferenco kuŝas en tio, ke la bazo ankaŭ ne kapablas preni ĉiujn rimedojn por si mem, tio estas, ie sur la Linukso-nivelo vi devas ordigi ĉion memstare.

La ĉefa ideo estas ne elekti ununuran celon kaj komenci agordi ĝin, ekzemple, memoro, CPU aŭ io simila, sed analizi la laborkvanton kaj provi plibonigi la trairon kiel eble plej multe por ke la ŝarĝo, kiun kreis bonaj programistoj por ni, inkluzive de niaj uzantoj.

Jen bildo por klarigi kio ĝi estas. Estas Linukso OS-bufro kaj ekzistas komuna memoro kaj ekzistas PostgreSQL-komunumbufroj. PostgreSQL, male al Oracle, funkcias rekte nur per la kernbufro, tio estas, por ke paĝo de disko eniru sian komunan memoron, ĝi devas trairi la kernan bufron kaj reen ĝuste la saman situacion.

Diskoj vivas sub ĉi tiu sistemo. Mi desegnis ĝin kiel diskojn. Fakte, povas esti RAID-regilo, ktp.

Kaj ĉi tiu enigo-eliro unu maniero aŭ alia okazas tra ĉi tiu kazo.

PostgreSQL estas klasika datumbazo. Ĝi estas ene de la paĝo. Kaj ĉiuj enigo-produktado okazas helpe de paĝoj. Ni levas blokojn en memoro per paĝoj. Kaj se nenio okazis, ni nur legas ilin, tiam iom post iom ili sinkas el ĉi tiu kaŝmemoro, el komunaj bufroj kaj revenas al la disko.

Se ni anstataŭigis ion ie, tiam nia tuta paĝo estas markita kiel malpura. Mi markis ilin blue ĉi tie. Kaj ĉi tio signifas, ke ĉi tiu paĝo devas esti sinkronigita kun bloka stokado. Tio estas, kiam ni malpurigis ĝin, ni faris enskribon en WAL. Kaj en iu bona momento, venis fenomeno nomata kontrolpunkto. Kaj ĉi tiu protokolo registris informojn, ke li venis. Kaj ĉi tio signifas, ke ĉiuj malpuraj paĝoj, kiuj estis ĉi tie en tiu momento en ĉi tiuj komunaj bufroj, estis sinkronigitaj kun la stoka disko uzante fsync per la kerna bufro.

Por kio ĝi estas? Se ni perdis tension, tiam ni ne ricevis la situacion, ke ĉiuj datumoj estis perditaj. Konstanta memoro, pri kiu ĉiuj rakontis al ni, estas ĝis nun en datumbaza teorio - tio estas brila estonteco, al kiu ni kompreneble strebas kaj ni ŝatas ĝin, sed ĝis nun ili ankoraŭ vivas en minus 20 jaroj. Kaj, kompreneble, ĉio ĉi devas esti monitorita.

Kaj la tasko maksimumigi la trairon estas agordi en ĉiuj ĉi tiuj stadioj, por ke ĉio rapide iru tien kaj reen. Komuna memoro estas esence paĝa kaŝmemoro. En PostgreSQL, ni sendis elektan ion tie peton, ĝi ricevis ĉi tiujn datumojn de la disko. Ili eniris komunajn bufrojn. Sekve, por ke ĉi tio funkciu pli bone, devas esti multe da memoro.

Por ke ĉio ĉi funkciu bone kaj rapide, vi devas ĝuste agordi la operaciumon en ĉiuj stadioj. Kaj elektu ekvilibran feron, ĉar se vi havas malekvilibron en iu loko, tiam vi povas fari multe da memoro, sed ĝi estos servata kun nesufiĉa rapideco.

Ni trairu ĉiun el ĉi tiuj punktoj.

Por ke ĉi tiuj paĝoj vojaĝu tien kaj reen pli rapide, vi devas atingi la jenajn:

• Unue, vi devas labori pli efike kun memoro.
• Due, ĉi tiu transiro devus esti pli efika kiam paĝoj de memoro iras al disko.
• Kaj, trie, devas esti bonaj diskoj.

Se vi havas 512 GB da RAM en la servilo kaj ĉio ĉi finiĝas sur SATA malmola disko sen ajna kaŝmemoro, tiam la tuta datumbaza servilo fariĝas ne nur en kukurbo, sed en kukurbo kun SATA-interfaco. Vi renkontos ĝin rekte. Kaj nenio vin savos.

Koncerne la unuan punkton pri memoro, estas tri aferoj, kiuj povas malfaciligi la vivon.

La unua estas NUMA. NUMA estas aĵo kiu estas farita por plibonigi rendimenton. Depende de la laborkvanto, vi povas optimumigi malsamajn aferojn. Kaj en ĝia nova nuna formo, ĝi ne estas tre bona por aplikoj kiel datumbazo, kiuj intense uzas paĝkaŝmemoron komunajn bufrojn.

En malmultaj vortoj. Kiel kompreni, ke io misas ĉe NUMA? Vi havas ian malagrablan frapon, subite iu CPU estas troŝarĝita. Samtempe, vi analizas demandojn en PostgreSQL kaj vidas, ke ekzistas nenio simila tie. Ĉi tiuj petoj ne devus esti tiom CPU-intensaj. Vi povas kapti ĝin dum longa tempo. Estas pli facile uzi la ĝustajn konsilojn dekomence pri kiel agordi NUMA por PostgreSQL.

Kio vere okazas? NUMA signifas Non-Uniform Memory Access. Kio estas la afero? Vi havas CPU, apud ĝi estas ĝia loka memoro. Kaj ĉi tiu memoro interkonekti povas tiri memoron de aliaj CPUoj.

Se vi kuras numactl --hardware, tiam vi ricevos tian grandan folion. Interalie, estos kampo de distancoj. Estos numeroj - 10-20, io tia. Ĉi tiuj nombroj estas nenio krom la nombro da lupolo por preni ĉi tiun foran memoron kaj uzi ĝin loke. Esence bona ideo. Ĉi tio bone plibonigas rendimenton en kelkaj laborŝarĝoj.

Nun imagu, ke vi havas unu CPU unue provantan uzi ĝian lokan memoron, poste provas eltiri alian memoron per interkonekto por io. Kaj via tuta PostgreSQL-paĝa kaŝmemoro atingas ĉi tiun CPU - jen, kiom da gigabajtoj estas tie. Vi ĉiam ricevas la plej malbonan kazon ĉar kutime estas malmulte da memoro sur la CPU rekte en tiu modulo. Kaj la tuta memoro kiu estas servata pasas tra ĉi tiuj interkonektiĝoj. Ĝi rezultas malrapide kaj malĝoje. Kaj vi havas procesoron kiu servas ĉi nodo estas konstante superŝarĝita. Kaj la alirtempo de ĉi tiu memoro estas malbona, malrapida. Ĉi tiu estas la speco de situacio, kiun vi ne volas, se vi uzas ĉi tiun kazon por datumbazo.

Sekve, pli ĝusta opcio por la datumbazo estas, ke la Linukso operaciumo tute ne scias, kio okazas tie. Por ke ŝi alparolas la memoron kiel ŝi alparolas.

Kial estas tio? Ŝajnus, ke devus esti inverse. Ĉi tio okazas pro simpla kialo, ke ni bezonas multe da memoro por paĝa kaŝmemoro - dekoj, centoj da gigabajtoj.

Kaj se ni atribuas ĉion ĉi kaj konservis niajn datumojn tie, tiam la gajno de uzado de la kaŝmemoro estos signife pli granda ol la gajno de tia ruza memoraliro. Kaj tiamaniere ni gajnos nekompareble kompare kun tio, ke ni aliros memoron pli efike uzante NUMA.

Tial, ekzistas du aliroj nuntempe, ĝis venos brila estonteco, kaj la datumbazo mem ne povas eltrovi sur kiuj CPU-oj ĝi funkcias kaj de kie ĝi devas tiri ion.

Tial, la ĝusta aliro estas tute malŝalti NUMAekz. ĉe rekomenco. Plejofte, la gajnoj estas en tiaj ordoj, ke tute ne estas demando, kio estas pli bona.

Estas alia opcio. Ni uzas ĝin pli ofte ol la unua, ĉar kiam kliento venas al ni por subteno, tiam por li rekomenci la servilon estas tuta afero. Li havas komercon tie. Kaj ili spertas problemojn pro NUMA. Tial ni provas malŝalti ĝin en malpli enpenetraj manieroj ol rekomenci, sed ĉi tie zorgu kontroli, ke ĝi estas malŝaltita. Ĉar, kiel sperto montras, ke ni malŝaltas NUMA ĉe la gepatra procezo de PostgreSQL, tio estas bona, sed tute ne necesas, ke tio funkcios. Ni devas kontroli kaj vidi ke ŝi vere malŝaltis.

Estas bona afiŝo de Robert Haas. Ĉi tiu estas unu el la kommitantoj de PostgreSQL. Unu el la ŝlosilaj programistoj de ĉiuj malaltnivelaj gibeloj. Kaj se vi sekvas la ligilojn de ĉi tiu afiŝo, ĝi priskribas plurajn buntajn rakontojn pri kiel NUMA malfaciligis la vivon por homoj. Rigardu, studu la kontrolon de la sistemadministranto pri tio, kio devas esti agordita en la servilo por ke nia datumbazo bone funkciu. Ĉi tiuj agordoj devas esti registritaj kaj kontrolitaj, ĉar alie ĝi ne estos tre bona.

Mi atentigas vin pri tio, ke ĉi tio validas por ĉiuj agordoj, pri kiuj mi parolos. Sed kutime datumbazoj estas kunvenitaj en majstra-sklava reĝimo por faŭltoleremo. Ne forgesu fari ĉi tiujn agordojn sur la sklavo, ĉar iam vi havos akcidenton kaj vi ŝanĝos al la sklavo kaj ĝi fariĝos la mastro.

En kriz-okazo, kiam ĉio estas tre malbona, via telefono senĉese sonoras kaj via estro venas kurante kun granda bastono, vi ne havos tempon por pensi pri kontrolo. Kaj la rezultoj povas esti tre katastrofaj.

La sekva momento estas grandegaj paĝoj. Grandegaj paĝoj malfacilas provi aparte, kaj ĉi tio ne utilas, kvankam ekzistas komparnormoj, kiuj povas fari tion. Oni facile guglas ilin.

Kio estas la afero? Vi havas ne tre multekostan servilon, kiu havas multe da RAM, ekzemple pli ol 30 GB. Vi ne uzas grandegajn paĝojn. Ĉi tio signifas, ke vi certe havas superkoston pri memoruzado. Kaj ĉi tiu supre estas malproksime de la plej agrabla.

Kial estas tio? Kaj kio okazas? La operaciumo asignas memoron en malgrandaj partoj. Tiel oportuna, tiel historie. Kaj se vi eniras detalojn, tiam la OS devas traduki virtualajn adresojn en fizikajn. Kaj ĉi tiu procezo ne estas la plej facila, do la OS konservas la rezulton de ĉi tiu operacio en la Translation Lookaside Buffer (TLB).

Kaj ĉar la TLB estas kaŝmemoro, tiam en ĉi tiu situacio ekestas ĉiuj problemoj propraj al la kaŝmemoro. Unue, se vi havas multe da RAM kaj ĝi estas ĉio asignita en malgrandaj partoj, tiam ĉi tiu bufro fariĝas tre granda. Kaj se la kaŝmemoro estas granda, tiam estas pli malrapide serĉi ĝin. Supre estas sana kaj okupas spacon memstare, t.e. io malĝusta konsumas RAM. Ĉifoje.

Du - ju pli la kaŝmemoro kreskas en tia situacio, des pli probable estas, ke vi havos kaŝmemorojn. Kaj la efikeco de ĉi tiu kaŝmemoro falas rapide kiam ĝia grandeco kreskas. Do operaciumoj elpensis simplan aliron. Linukso uzas ĝin delonge. Ĝi aperis en FreeBSD antaŭ ne longe. Sed ni parolas pri Linukso. Ĉi tiuj estas grandegaj paĝoj.

Kaj ĉi tie oni devas rimarki, ke grandegaj paĝoj, kiel ideo, estis komence puŝitaj de komunumoj, kiuj inkludis Oracle kaj IBM, tio estas, datumbazaj produktantoj pensis pri tio, ke tio estus utila, inkluzive por datumbazoj.

Kaj kiel amikiĝi kun PostgreSQL? Unue, grandegaj paĝoj devas esti ebligitaj en la Linukso-kerno.

Due, ili devas esti eksplicite specifitaj per la parametro sysctl - kiom da estas. La nombroj ĉi tie estas de iu malnova servilo. Vi povas kalkuli proksimume kiom da komunaj bufroj vi havas, por ke grandegaj paĝoj taŭgas tie.

Kaj se vi havas la tutan servilon dediĉitan al PostgreSQL, tiam bona deirpunkto estas aŭ doni 25% de RAM por komunaj bufroj, aŭ 75% se vi certas, ke via datumbazo certe taŭgas en ĉi tiuj 75%. Deirpunkto unue. Kaj konsideru, se vi havas 256 GB da RAM, tiam, laŭe, vi havos 64 GB da ŝertaj bufroj. Kalkulu proksimume kun iom da marĝeno - al kio vi devus agordi ĉi tiun ciferon.

Antaŭ la versio 9.2 (se mi ne eraras, ekde la versio 8.2) eblis amikiĝi kun grandegaj paĝoj PostgreSQL uzante trian bibliotekon. Kaj ĉi tio ĉiam devus esti farita. Unue, vi bezonas la kernon por povi asigni grandegajn paĝojn ĝuste. Kaj, due, por ke la aplikaĵo, kiu funkcias kun ili, povu uzi ilin. Ĝi simple ne estos uzata tiel. Ĉar PostgreSQL asignis memoron en sistemo 5 stilo, tio povus esti farita per libhugetlbfs - ĉi tiu estas la plena nomo de la biblioteko.

9.3 plibonigis la memoran rendimenton de PostgreSQL kaj forigis la metodon de asigno de memoro de la sistemo 5. Ĉiuj estis tre feliĉaj, ĉar alie vi provas ruli du PostgreSQL-instancojn sur la sama maŝino, kaj li diras, ke mi ne havas sufiĉe da komuna memoro. Kaj li diras, ke vi devas ripari sysctl. Kaj ekzistas tia sysctl, ke vi ankoraŭ bezonas rekomenci ktp. Ĝenerale, ĉiuj ĝojis. Sed mmap memorasigno rompis uzante grandegajn paĝojn. Plej multaj el niaj klientoj uzas grandajn komunajn bufrojn. Kaj ni forte rekomendis ne ŝanĝi al 9.3, ĉar tie supre komencis esti kalkulita en bonaj procentoj.

Sed aliflanke, la komunumo atentigis pri ĉi tiu problemo kaj en 9.4 ili tre bone reverkis tiun ĉi eventon. Kaj en 9.4, parametro aperis en postgresql.conf, en kiu vi povas ŝalti try, on aŭ malŝalti.

Provu estas la plej sekura opcio. Kiam PostgreSQL komenciĝas, kiam ĝi asignas komunan memoron, ĝi provas kapti ĉi tiun memoron el grandegaj paĝoj. Kaj se ĝi ne funkcias, tiam ĝi revenas al la kutima elekto. Kaj se vi havas FreeBSD aŭ Solaris, tiam vi povas provi, ĝi ĉiam estas sekura.

Se ĝi estas ŝaltita, tiam ĝi simple ne komenciĝas se ĝi ne povus elekti el grandegaj paĝoj. Ĉi tie jam - al kiu kaj kio estas pli bela. Sed se vi provas, tiam kontrolu, ke vi vere havas tion, kion vi bezonas reliefigita, ĉar estas multaj spacoj por eraro. Nuntempe ĉi tiu funkcio funkcias nur en Linukso.

Ankoraŭ unu noto antaŭ ol ni pluiru. Travideblaj grandegaj paĝoj ankoraŭ ne temas pri PostgreSQL. Li ne povas uzi ilin normale. Kaj kun Travideblaj grandegaj paĝoj por tia laborŝarĝo, kiam vi bezonas grandan pecon de komuna memoro, la plusoj venas nur kun tre grandaj volumoj. Se vi havas terabajtojn da memoro, tiam ĉi tio povas ludi rolon. Se ni parolas pri pli ĉiutagaj aplikoj, kiam vi havas 32, 64, 128, 256 GB da memoro sur la maŝino, tiam la kutimaj grandegaj paĝoj estas Bone, kaj ni simple malŝaltas Travidebla.

Kaj la lasta afero pri memoro ne rekte rilatas al fruputo, ĝi povas tre ruinigi la vivon. Ĉiu trafluo estos tre tuŝita de la fakto, ke la servilo konstante interŝanĝas.

Kaj ĝi estos tre malagrabla en iuj punktoj. Kaj la ĉefa problemo estas, ke en modernaj kernoj la konduto estas iomete malsama ol pli malnovaj Linukso-kernoj. Kaj ĉi tiu afero, kiu estas sufiĉe malagrabla surpaŝi, ĉar kiam ni parolas pri iu laboro kun interŝanĝo, ĝi finiĝas kun la malkonvena alveno de la OOM-murdinto. Kaj la OOM-murdinto, kiu ne venis ĝustatempe kaj forĵetis PostgreSQL, estas malagrabla. Ĉiuj scios pri ĝi, tio estas, ĝis la lasta uzanto.

Kio okazas? Vi havas grandan kvanton da RAM tie, ĉio funkcias bone. Sed ial la servilo pendas en interŝanĝo kaj malrapidiĝas pro tio. Ŝajnus, ke estas multe da memoro, sed ĝi okazas.

Antaŭe, ni konsilis ke vm.swappiness estu agordita al nulo, t.e. malŝalti interŝanĝon. Antaŭe, ŝajnis, ke 32 GB da RAM kaj respondaj komunaj bufroj estis grandega kvanto. La ĉefa celo de la interŝanĝo estas havi lokon por ĵeti kruston se ni defalas. Kaj ĝi ne estis tre bone farita. Kaj tiam kion vi faros kun ĉi tiu krusto? Ĉi tio jam estas tia tasko kiam ne estas tre klare kial interŝanĝado necesas, precipe de tia grandeco.

Sed en pli modernaj, t.e., en la triaj versioj de la kerno, la konduto ŝanĝiĝis. Kaj se vi agordas interŝanĝon al nulo, t.e. malŝaltas ĝin, tiam pli aŭ malpli frue, eĉ kun iom da RAM restanta, OOM-murdinto venos al vi por mortigi la plej intensajn konsumantojn. Ĉar li konsideros, ke kun tia laborŝarĝo ni ankoraŭ restas iom kaj ni elsaltos, tio estas, ne mortigos la sisteman procezon, sed mortigos ion malpli gravan. Ĉi tio malpli grava estos la peza konsumanto de komuna memoro, nome la poŝtestro. Kaj post tio estos bone, se la bazo ne devos esti restaŭrita.

Tial nun la defaŭlta, laŭ mia memoro, la plej multaj distribuoj estas ie ĉirkaŭ 6, t.e. en kiu punkto komenci uzi interŝanĝon, depende de kiom da memoro restas. Ni nun konsilas agordi vm.swappiness = 1, ĉar ĝi praktike malŝaltas ĝin, sed ne donas tiajn efikojn kiel kun neatendita OOM-murdinto, kiu venis kaj mortigis la tuton.

Kio sekvas? Kiam ni parolas pri la agado de datumbazoj kaj iom post iom, iom post iom, ni estas kiel diskoj, ĉiuj komencas kapti siajn kapojn. Ĉar la vero, ke la disko estas malrapida kaj la memoro estas rapida, estas konata al ĉiuj ekde infanaĝo. Kaj ĉiuj scias, ke estos problemoj pri disko rendimento en la datumbazo.

La ĉefa problemo de agado de PostgreSQL kun kontrolpunktoj ne estas ĉar la disko estas malrapida. Ĉi tio estas pli verŝajne pro la fakto, ke la memoro kaj disko-bendolarĝo ne estas ekvilibraj. Tamen, ili eble ne estas ekvilibraj en malsamaj lokoj. PostgreSQL ne estas agordita, OS ne estas agordita, aparataro ne estas agordita kaj aparataro malĝusta. Kaj ĉi tiu problemo ne okazas nur se ĉio iras kiel ĝi devus, t.e. aŭ ne estas ŝarĝo, aŭ la agordoj kaj aparataro estas bone elektitaj.

Kio ĝi estas kaj kiel ĝi aspektas? Kutime, homoj, kiuj laboras kun PostgreSQL, eniris ĉi tiun komercon pli ol unufoje. Mi klarigos. Kiel mi diris, PostgreSQL periode faras kontrolpunktojn por forĵeti malpurajn paĝojn en komuna memoro al disko. Se ni havas grandan kvanton da komuna memoro, tiam kontrolpunkto komencas intense influi la diskon, ĉar fsync forĵetas ĉi tiujn paĝojn. Ĝi alvenas en la kernbufron kaj estas skribita al disko uzante fsync. Kaj se la volumo de ĉi tiu kazo estas granda, tiam ni povas observi malagrablan efikon, nome, tre granda utiligo de diskoj.

Jen mi havas du bildojn. Mi nun klarigos kio ĝi estas. Ĉi tiuj estas du tempo-korelaciaj grafikaĵoj. La unua grafeo estas diskuzo. Ĉi tie ĝi atingas preskaŭ 90% en ĉi tiu momento. Se vi havas datumbazan falon kun fizikaj diskoj, kun RAID-regilo sub 90% utiligo, tiam ĉi tio estas malbona novaĵo. Ĉi tio signifas, ke venos iom pli kaj 100 kaj la enigo / eligo ĉesos.

Se vi havas diskon, tiam estas iomete malsama rakonto. Tie dependas de kiel ĝi estas agordita, kia tabelo, ktp.

Kaj paralele, grafeo estas agordita ĉi tie de la interna postgres-vido, kiu rakontas kiel la kontrolpunkto okazas. Kaj la verda koloro ĉi tie montras kiom da bufroj de ĉi tiuj malpuraj paĝoj en tiu momento alvenis al ĉi tiu kontrolpunkto por sinkronigado. Kaj ĉi tio estas la ĉefa afero por scii ĉi tie. Ni vidas, ke ni havas multajn paĝojn ĉi tie kaj iam ni renkontis kotizon, tio estas, ni skribis kaj skribis, ĉi tie la disksistemo estas klare tre okupata. Kaj nia kontrolpunkto havas tre fortan efikon sur la disko. Ideale, la situacio devus aspekti pli tiel, t.e. ni havis malpli da rekordo ĉi tie. Kaj ni povas ripari ĝin per agordoj por ke ĝi daŭras tiel. Tio estas, la reciklado estas malgranda, sed ie ni skribas ion ĉi tie.

Kion oni devas fari por venki ĉi tiun problemon? Se vi haltigis IO sub la datumbazo, tiam ĉi tio signifas, ke ĉiuj uzantoj, kiuj venis por plenumi siajn petojn, atendos.

Se vi rigardas el la vidpunkto de Linukso, se vi prenis bonan aparataron, agordis ĝin ĝuste, agordis PostgreSQL normale tiel ke ĝi faru ĉi tiujn kontrolpunktojn malpli ofte, disvastigu ilin ĝustatempe inter si, tiam vi paŝas en la defaŭltajn Debianajn parametrojn. . Por plej multaj Linukso-distribuoj, jen la bildo: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Kion ĝi signifas? Ekde kerno 2.6, unu demona ruĝiĝo aperis. Pdglush, depende de kiu uzas kion, kiu traktas la fonon forĵetante malpurajn paĝojn el la kerno-bufro kaj forĵetante malpurajn paĝojn kiam ĝi estas necesa, negrave kio, kiam la fonĵetado ne helpas.

Kiam venas fono? Kiam 10% de la tuta RAM, kiu estas sur la servilo, estas okupataj de malpuraj paĝoj en la kerno-bufro, tiam speciala trompa funkcio en la fono estas nomita. Kial ŝi estas fono? Ĝi prenas kiel parametron kiom da paĝoj por forigi. Kaj, ni diru, forĵetas N paĝojn. Kaj dum iom da tempo, ĉi tiu afero endormiĝas. Kaj tiam ŝi revenas kaj forĵetas kelkajn pliajn paĝojn.

Ĉi tio estas ege simpla rakonto. Ĉi tie la tasko estas kiel ĉe lageto, kiam ĝi verŝas en unu pipon, verŝas en alian. Nia kontrolpunkto venis kaj se ĝi sendis kelkajn malpurajn paĝojn por forĵeti, tiam iom post iom el la kerna bufro pgflush ĉi tiu tuta afero nete solvos.

Se ĉi tiuj malpuraj paĝoj daŭre amasiĝas, ili amasiĝas ĝis 20%, post tio la OS-prioritato estas forigi la tuton al disko, ĉar la potenco forflugos, kaj ĉio estos malbona por ni. Ni perdos ĉi tiujn datumojn, ekzemple.

Kio estas la ruzo? La lertaĵo estas, ke ĉi tiuj parametroj en la moderna mondo de 20 kaj 10% de la tuta RAM, kiu estas sur la maŝino, ili estas absolute monstraj koncerne la trairon de iu ajn disksistemo, kiun vi havas.

Imagu, ke vi havas 128 GB da RAM. 12,8 GB venas al via disksistemo. Kaj negrave kian kaŝmemoron vi havas tie, negrave kian tabelon vi havas tie, ili ne eltenos tiom multe.

Tial ni rekomendas, ke ĉi tiuj nombroj estu ĝustigitaj tuj depende de la kapabloj de via RAID-regilo. Mi tuj donis rekomendon ĉi tie por regilo, kiu havas 512 MB da kaŝmemoro.

Ĉio estas konsiderata tre simpla. Vi povas meti vm.dirty_background en bajtoj. Kaj ĉi tiuj agordoj superas la antaŭajn du. Aŭ la proporcio estas defaŭlte, aŭ tiuj kun bajtoj estas aktivigitaj, tiam tiuj kun bajtoj funkcios. Sed ĉar mi estas DBA-konsultisto kaj mi laboras kun malsamaj klientoj, mi provas meti pajlojn kaj tial, se en bajtoj, tiam en bajtoj. Neniu donis ajnan garantion ke bona administranto ne aldonos memoron al la servilo, ne rekomencos ĝin, kaj la figuro restos la sama. Nur kalkulu ĉi tiujn nombrojn por ke ĉio konvenu tie kun garantio.

Kio okazas se vi ne taŭgas? Mi skribis, ke efike ĉesigas ajnan ruĝiĝon, sed fakte ĝi estas vortfiguro. La operaciumo havas grandan problemon - ĝi havas multajn malpurajn paĝojn, do la IO kiun viaj klientoj generas efike ĉesas, t.e. la aplikaĵo venis por sendi sql-demandon al la datumbazo, ĝi atendas. Ĉiu I/O al ĝi estas en la plej malsupra prioritato, ĉar la bazo estas okupita per la transirejo. Kaj kiam ŝi finas, ĝi estas tute nekomprenebla. Kaj kiam vi atingis ne-fonan, ne-fonan flufluadon, tio signifas, ke via tuta IO estas okupita de ĝi. Kaj ĝis ĝi finiĝos, vi faros nenion.

Estas du pli gravaj punktoj, kiuj estas ekster la amplekso de ĉi tiu raporto. Ĉi tiuj agordoj devus kongrui kun la agordoj en postgresql.conf, t.e. la kontrolpunktoj. Kaj via disksistemo devas esti taŭge agordita. Se vi havas kaŝmemoron sur la RAID, tiam ĝi devas havi kuirilaron. Homoj aĉetas RAID kun bona kaŝmemoro sen baterio. Se vi havas SSD en RAID, tiam ili devas esti serviloj, devas esti kondensiloj. Jen la pligrandigita kontrolo-listo. Ĉe ĉi tiu ligilo estas mia raporto pri kiel agordi disko-rendimenton en PostgreSQL. Ĉiuj tiuj kontrollistoj estas tie.

Kio alia povas malfaciligi la vivon? Ĉi tiuj estas du ebloj. Ili estas relative novaj. Defaŭlte, ili povas esti inkluzivitaj en malsamaj aplikoj. Kaj ili povas kompliki la vivon same multe se ili estas malĝuste ŝaltitaj.

Estas du relative novaj pecoj. Ili jam aperis en la triaj kernoj. Ĉi tiuj estas sched_migration_cost en nanosekundoj kaj sched_autogroup_enabled kiu estas unu defaŭlte.

Kaj kiel ili ruinigas la vivon? Kio estas sched_migration_cost? La Linukso-planisto povas migri procezon de unu CPU al alia. Kaj por PostgreSQL, kiu plenumas demandojn, migri al alia CPU estas tute nekomprenebla kial. De operaciuma vidpunkto, kiam vi ŝanĝas fenestrojn inter openoffice kaj terminalo, tio povas esti bona, sed por la datumbazo - ĝi estas tre malbona. Tial, akceptebla politiko estas agordi migration_cost al iu granda valoro, almenaŭ kelkajn mil nanosekundojn.

Kion ĉi tio signifos por la planisto? Oni supozos, ke dum ĉi tiu tempo ĉi tiu procezo ankoraŭ estas varma. Tio estas, se vi havas ian longan transakcion faranta ion dum longa tempo, la planisto komprenos ĉi tion. Li supozos, ke ĝis ĉi tiu tempopaso pasas, tiam ĉi tiu procezo ne bezonas esti migrita ie ajn. Se samtempe la procezo faras ion, tiam ĝi ne estos migrita ien, ĝi trankvile finos sur la CPU, kiu estis asignita al ĝi. Kaj la rezulto estas bonega.

La dua punkto estas aŭtogrupo. Estas bona ideo por specifaj laborŝarĝoj kiuj ne rilatas al modernaj datumbazoj - tio estas grupigi procezojn per la virtuala terminalo de kiu ili estas lanĉitaj. Ĝi estas oportuna por iuj taskoj. En praktiko, PostgreSQL estas antaŭfork-multproceza sistemo, kiu funkcias de ununura terminalo. Vi havas ŝlosilon, kontrolpunkton, kaj ĉiuj viaj klientpetoj estas grupigitaj en unu planilon, per CPU. Kaj ili tie atendos kune, kiam li estos libera, por enmiksiĝi unu la alian kaj okupi lin pli longe. Ĉi tio estas rakonto, kiu estas tute nenecesa en la kazo de tia ŝarĝo kaj tial ĝi devus esti malŝaltita.

Mia kolego Alexey Lesovsky faris provojn per simpla pgbench, kie li pliigis migrad_cost je grandordo kaj malŝaltis aŭtogrupon. La diferenco sur malbona ferpeco montriĝis preskaŭ 10%. Estas diskuto en la dissendolisto de postgres, kie homoj raportas rezultojn kiel similajn ŝanĝojn al konsultrapideco influis 50%. Estas sufiĉe multaj tiaj rakontoj.

Kaj fine, pri la energiŝpara politiko. Estas bone, ke Linukso nun povas esti uzata sur tekkomputilo. Kaj ĝi supozeble bone konsumos la kuirilaron. Sed subite montriĝas, ke tio ankaŭ povas okazi ĉe la servilo.

Krome, se vi luas servilojn de iu gastiganto, tiam "bonaj" gastigantoj ne zorgas, ke vi havas pli bonan rendimenton. Ilia tasko estas certigi, ke ilia fero estas uzata kiel eble plej efike. Tial, defaŭlte, ili povas ŝalti la tekkomputilan energiŝparan reĝimon en la operaciumo.

Se vi uzas ĉi tion sur tre ŝargita datumbaza servilo, tiam via elekto estas acpi_cpufreq + permormance. Eĉ kun ondemand, jam estos problemoj.

Intel_pstate estas iomete malsama ŝoforo. Kaj nun oni preferas al ĉi tiu, kiel al pli posta kaj pli bona funkcianta.

Kaj, sekve, la guberniestro estas nur agado. Postpeto, potencoŝparo kaj ĉio cetera - ĉi tio ne temas pri vi.

La rezultoj de ekspliki analizi PostgreSQL povas diferenci je pluraj grandordoj se vi ebligas potencoŝparon, ĉar praktike vi havos CPU-forĵetadon sub la datumbazo en tute neantaŭvidebla maniero.

Ĉi tiuj aferoj povas esti ebligitaj defaŭlte. Rigardu atente por vidi ĉu ili estis ebligitaj defaŭlte. Ĉi tio povas esti vere granda problemo.

Kaj finfine, mi volis danki la ulojn de nia PosgreSQL-Consulting DBA-teamo, nome Max Boguk kaj Alexey Lesovsky, kiuj ĉiutage plenigas ŝvelaĵojn en ĉi tiu komerco. Kaj por niaj klientoj, ni provas fari la plej bonan, por ke ĉio funkciu por ili. Estas kiel kun instrukcioj pri aviada sekureco. Ĉio ĉi tie estas skribita en sango. Ĉiu el ĉi tiuj nuksoj estas malkovrita en la procezo de ia problemo. Mi feliĉas dividi ilin kun vi.

Demandoj:

Dankon! Se, ekzemple, firmao volas ŝpari monon kaj gastigi la datumbazon kaj aplikaĵlogikon sur la sama servilo, aŭ se la firmao sekvas la modan tendencon de mikroservaj arkitekturoj en kiuj PostgreSQL funkcias en ujo. Kio estas la afero? Sysctl tutmonde influas la tutan kernon. Mi ne aŭdis, ke sysctl estas iel virtualigita tiel ke ili funkcias aparte sur la ujo. Estas nur cgroup kaj nur parto de ĝi havas kontrolon. Kiel vi povas vivi kun ĉi tio? Aŭ se vi volas rendimenton, do rulu PostgreSQL sur aparta fera servilo kaj agordu ĝin?

Ni respondis al via demando ĉirkaŭ tri manieroj. Se ni ne parolas pri ferservilo, kiu povas esti agordebla ktp., tiam malstreĉiĝi, ĉio funkcios bone sen ĉi tiuj agordoj. Se vi havas tian ŝarĝon, ke vi devas fari ĉi tiujn agordojn, tiam vi venos al la ferservilo pli frue ol ĉi tiuj agordoj.

Kio estas la problemo? Se ĉi tio estas virtuala maŝino, tiam plej verŝajne vi havos multajn problemojn, ekzemple kun la fakto, ke la plej multaj virtualaj maŝinoj havas sufiĉe malkonsekvencan disk-latentecon. Eĉ se diska trairo estas bona, ununura malsukcesa I/O-transakcio kiu ne multe influas la mezan trairon kiu okazis ĉe la tempo de transirejo aŭ dum la skribado al WAL, tiam la datumbazo multe suferos de tio. Kaj vi rimarkos ĉi tion antaŭ ol vi renkontos ĉi tiujn problemojn.

Se vi havas NGINX sur la sama servilo, vi ankaŭ havos la saman problemon. Li batalos por komuna memoro. Kaj vi ne atingos la problemojn, kiuj estas priskribitaj ĉi tie.

Sed aliflanke, iuj el ĉi tiuj parametroj ankoraŭ estos gravaj por vi. Ekzemple, kun sysctl, agordu dirty_ratio por ke ĝi ne estu tiel freneza - ĉiukaze tio helpos. Unu maniero aŭ alia, vi havos interagon kun la disko. Kaj estos malĝuste. Ĉi tio ĝenerale estas la defaŭlta de la parametroj, kiujn mi montris. Kaj ĉiuokaze, estas pli bone ŝanĝi ilin.

Kaj kun NUMA povas esti problemoj. VmWare, ekzemple, funkcias bone kun NUMA kun ĝuste la kontraŭaj agordoj. Kaj ĉi tie vi devas elekti - feran servilon aŭ ne-feran.

Mi havas demandon rilate al Amazon AWS. Ili havas bildojn antaŭkonfiguritaj. Unu el ili nomiĝas Amazon RDS. Ĉu ekzistas kutimaj agordoj por ilia operaciumo?

Estas agordoj, sed ili estas malsamaj agordoj. Ĉi tie ni agordas la operaciumon laŭ kiel la datumbazo uzos ĉi tiun komercon. Kaj estas parametroj kiuj determinas kien ni devus iri nun, tia formado. Tio estas, ni bezonas tiom da rimedoj, ni manĝos ilin nun. Post tio, Amazon RDS fiksas ĉi tiujn rimedojn, kaj rendimento falas tie. Estas apartaj rakontoj pri kiel homoj komencas kemion kun ĉi tiu afero. Kelkfoje eĉ sufiĉe sukcese. Sed ĝi havas nenion komunan kun OS-agordoj. Estas kiel nuba hakado. Estas malsama historio.

Kial Travideblaj grandegaj paĝoj ne efikas kompare kun Huge TLB?

Ne donu. Ĉi tio povas esti klarigita en multaj manieroj. Sed fakte ili simple ne donas ĝin. Kio estas la historio de PostgreSQL? Ĉe ekfunkciigo, ĝi asignas grandan parton de komuna memoro. Travideblaj ili estas samtempe aŭ ne travideblaj - tute ne gravas. La fakto ke ili elstaras ĉe la komenco klarigas ĉion. Kaj se estas multe da memoro kaj vi devas rekonstrui la shared_memory-segmenton, tiam Travideblaj grandegaj paĝoj estos gravaj. En PostgreSQL, ĝi estas simple emfazita komence per grandega peco kaj jen, kaj tiam nenio speciala okazas tie. Vi povas, kompreneble, uzi ĝin, sed estas ŝanco akiri kurruption shared_memory kiam ĝi re-asignas ion. PostgreSQL ne scias pri tio.

fonto: www.habr.com