Industria aliro al agordado de PostgreSQL: eksperimentoj kun datumbazoj." Nikolaj Samoĥvalov

Mi sugestas vin legi la transskribon de la raporto de Nikolaj Samokhvalov "Industria aliro al agordo de PostgreSQL: eksperimentoj pri datumbazoj"

Shared_buffers = 25% - ĉu multe aŭ malmulte? Aŭ ĝuste ĝuste? Kiel vi scias, ĉu tiu ĉi - sufiĉe malmoderna - rekomendo taŭgas en via aparta kazo?

Estas tempo alproksimiĝi al la temo de elektado de postgresql.conf parametroj "kiel plenkreskulo." Ne helpe de blindaj "aŭtomataj agordiloj" aŭ malmodernaj konsiloj de artikoloj kaj blogoj, sed surbaze de:

1. strikte kontrolitaj eksperimentoj pri datumbazoj, faritaj aŭtomate, en grandaj kvantoj kaj sub kondiĉoj kiel eble plej proksimaj al "batali" tiajn,
2. profunda kompreno de la trajtoj de la DBMS kaj OS.

Uzante Nancy CLI (https://gitlab.com/postgres.ai/nancy), ni rigardos specifan ekzemplon - la konatan shared_buffers - en malsamaj situacioj, en malsamaj projektoj kaj provos eltrovi kiel elekti la optimuman agordon por nia infrastrukturo, datumbazo kaj ŝarĝo.

Ni parolos pri eksperimentoj kun datumbazoj. Ĉi tio estas rakonto, kiu daŭras iom pli ol ses monatojn.

Iom pri mi. Sperto kun Postgres dum pli ol 14 jaroj. Kelkaj sociaj retaj kompanioj fondis. Postgres estis kaj estas uzata ĉie.

Ankaŭ la grupo RuPostgres pri Meetup, 2-a loko en la mondo. Ni malrapide alproksimiĝas al 2 000 homoj. RuPostgres.org.

Kaj ĉe komputiloj de diversaj konferencoj, inkluzive de Highload, mi respondecas pri datumbazoj, precipe Postgres ekde la komenco.

Kaj en la lastaj jaroj, mi rekomencis mian Postgres-konsultan praktikon 11 horzonojn de ĉi tie.

Kaj kiam mi faris tion antaŭ kelkaj jaroj, mi havis iom da paŭzo en aktiva manlaboro kun Postgres, verŝajne ekde 2010. Mi estis surprizita kiom malmulte la laborrutino de DBA ŝanĝiĝis, kaj kiom da manlaboro ankoraŭ bezonas esti uzata. Kaj mi tuj pensis, ke io misas ĉi tie, mi devas aŭtomatigi pli de ĉio.

Kaj ĉar ĉio estis malproksima, la plej multaj el la klientoj estis en la nuboj. Kaj multo jam estis aŭtomatigita, evidente. Pli pri tio poste. Tio estas, ĉio ĉi rezultigis la ideon, ke devus ekzisti kelkaj iloj, t.e., ia platformo, kiu aŭtomatigos preskaŭ ĉiujn DBA-agojn por ke granda nombro da datumbazoj povas esti administrita.

Ĉi tiu raporto ne inkluzivos:

• "Arĝentaj kugloj" kaj deklaroj kiel - starigu 8 GB aŭ 25% shared_buffers kaj vi estos bone. Ne estos multe pri shared_buffers.
• Hardcore "internaĵoj".

Kio okazos?

• Estos optimumigaj principoj, kiujn ni aplikas kaj disvolvas. Estos ĉiaj ideoj kiuj aperos survoje kaj diversaj iloj kiujn ni kreas plejparte en Malferma Fonto, t.e. ni faras la bazon en Malferma Fonto. Krome, ni havas biletojn, ĉiu komunikado estas praktike Open Source. Vi povas vidi kion ni faras nun, kio estos en la venonta eldono, ktp.
• Ankaŭ estos iom da sperto pri uzado de ĉi tiuj principoj, ĉi tiuj iloj en kelkaj kompanioj: de malgrandaj noventreprenoj ĝis grandaj kompanioj.

Kiel ĉio ĉi evoluas?

Unue, la ĉefa tasko de DBA, krom certigi la kreadon de petskriboj, deplojo de sekurkopioj, ktp., estas trovi proplempunktojn kaj optimumigi rendimenton.

Nun ĝi estas starigita tiel. Ni rigardas la monitoradon, ni vidas ion, sed mankas al ni iuj detaloj. Ni komencas fosi pli zorge, kutime per niaj manoj, kaj komprenas kion fari kun ĝi unumaniere aŭ alian.

Kaj estas du aliroj. Pg_stat_statements estas la defaŭlta solvo por identigi malrapidajn demandojn. Kaj analizo de Postgres protokoloj uzante pgBadger.

Ĉiu aliro havas gravajn malavantaĝojn. En la unua alproksimiĝo, ni forĵetis ĉiujn parametrojn. Kaj se ni vidas la grupojn SELECT * FROM tabelo kie kolumno estas egala al la "?" aŭ "$" ekde Postgres 10. Ni ne scias ĉu ĉi tio estas indeksa skanado aŭ seq-skanado. Ĝi tre dependas de la parametro. Se vi anstataŭigas tie malofte renkontitan valoron, ĝi estos indeksa skanado. Se vi anstataŭigas valoron kiu okupas 90% de la tabelo tie, la seq-skanado estos evidenta, ĉar Postgres konas la statistikojn. Kaj ĉi tio estas granda malavantaĝo de pg_stat_statements, kvankam iuj laboroj estas en kurso.

La plej granda malavantaĝo de log-analizo estas, ke vi ne povas pagi "log_min_duration_statement = 0" kiel regulo. Kaj ankaŭ pri tio ni parolos. Sekve, vi ne vidas la tutan bildon. Kaj iu konsulto, kiu estas tre rapida, povas konsumi grandegan kvanton da rimedoj, sed vi ne vidos ĝin ĉar ĝi estas sub via sojlo.

Kiel DBA-oj solvas la problemojn, kiujn ili trovas?

Ekzemple, ni trovis iun problemon. Kion oni kutime faras? Se vi estas programisto, tiam vi faros ion en iu kazo kiu ne estas la sama grandeco. Se vi estas DBA, tiam vi havas surscenigon. Kaj povas esti nur unu. Kaj li malfruis ses monatojn. Kaj vi pensas, ke vi iros al produktado. Kaj eĉ spertaj DBA-oj tiam kontrolu produktadon, sur kopio. Kaj okazas, ke ili kreas provizoran indekson, certigas, ke ĝi helpas, faligas ĝin kaj donas ĝin al la programistoj, por ke ili povu meti ĝin en la migrajn dosierojn. Jen tia sensencaĵo, kiu okazas nun. Kaj ĉi tio estas problemo.

• Agordu agordojn.
• Optimumigu la aron de indeksoj.
• Ŝanĝu la SQL-demandon mem (ĉi tiu estas la plej malfacila metodo).
• Aldonu kapablon (la plej facila maniero en la plej multaj kazoj).

Multe okazas kun ĉi tiuj aferoj. Estas multaj teniloj en Postgres. Estas multo por scii. Estas multaj indeksoj en Postgres, danke ankaŭ al la organizantoj de ĉi tiu konferenco. Kaj ĉio ĉi devas esti konata, kaj ĉi tio igas ne-DBA-ojn senti kiel DBA-oj praktikas nigran magion. Tio estas, vi devas studi dum 10 jaroj por komenci kompreni ĉion ĉi normale.

Kaj mi estas batalanto kontraŭ ĉi tiu nigra magio. Mi volas fari ĉion, por ke ekzistas teknologio, kaj ne estas intuicio en ĉio ĉi.

Ekzemploj de reala vivo

Mi observis tion en almenaŭ du projektoj, inkluzive de mia propra. Alia blogaĵo diras al ni, ke valoro de 1 por default_statistict_target estas bona. Bone, ni provu ĝin en produktado.

Kaj jen ni, uzante nian ilon du jarojn poste, helpe de eksperimentoj pri la datumbazoj, pri kiuj ni parolas hodiaŭ, ni povas kompari kio estis kaj kio fariĝis.

Kaj por tio ni devas krei eksperimenton. Ĝi konsistas el kvar partoj.

• La unua estas la medio. Ni bezonas pecon da aparataro. Kaj kiam mi venas al iu firmao kaj subskribas kontrakton, mi diras al ili, ke ili donu al mi la saman aparataron kiel en produktado. Por ĉiu el viaj Majstroj, mi bezonas almenaŭ unu aparataron tia. Aŭ ĉi tio estas virtuala maŝino en Amazon aŭ Guglo, aŭ mi bezonas ĝuste la saman aparataron. Tio estas, mi volas rekrei la medion. Kaj en la koncepto de medio ni inkluzivas la ĉefan version de Postgres.
• La dua parto estas la objekto de nia esploro. Ĉi tio estas datumbazo. Ĝi povas esti kreita en pluraj manieroj. Mi montros al vi kiel.
• La tria parto estas la ŝarĝo. Ĉi tiu estas la plej malfacila momento.
• Kaj la kvara parto estas tio, kion ni kontrolas, t.e. kion ni komparos kun kio. Ni diru, ke ni povas ŝanĝi unu aŭ plurajn parametrojn en la agordo, aŭ ni povas krei indekson, ktp.

Ni lanĉas eksperimenton. Jen pg_stat_statements. Maldekstre estas kio okazis. Dekstre - kio okazis.

Maldekstre default_statistics_target = 100, dekstre = 1 000. Ni vidas, ke tio helpis nin. Ĝenerale, ĉio pliboniĝis je 8%.

Sed se ni rulumu malsupren, estos grupoj de petoj de pgBadger aŭ de pg_stat_statements. Estas du opcioj. Ni vidos, ke iu peto malpliiĝis je 88%. Kaj jen venas la inĝenieristiko. Ni povas fosi pli enen ĉar ni scivolas kial ĝi sinkis. Vi devas kompreni kio okazis kun la statistiko. Kial pli da siteloj en statistiko kondukas al pli malbonaj rezultoj.

Aŭ ni ne povas fosi, sed faru "ALTER TABLE ... ALTER COLUMN" kaj redonu 100 sitelojn al la statistiko de ĉi tiu kolumno. Kaj tiam per alia eksperimento ni povas certigi, ke ĉi tiu flikaĵo helpis. Ĉiuj. Ĉi tio estas inĝenieristiko, kiu helpas nin vidi la grandan bildon kaj fari decidojn bazitajn sur datumoj prefere ol sur intuicio.

Paro da ekzemploj el aliaj areoj. Ekzistas CI-testoj en testado dum multaj jaroj. Kaj neniu projekto en sia ĝusta menso vivus sen aŭtomatigitaj testoj.

En aliaj industrioj: en aviado, en la aŭtomobila industrio, kiam ni testas aerodinamikon, ni ankaŭ havas la ŝancon fari eksperimentojn. Ni ne lanĉos ion el desegnaĵo rekte en la spacon, aŭ ni ne tuj prenos iun aŭton sur la trakon. Ekzemple, estas ventotunelo.

Ni povas tiri konkludojn el observoj de aliaj industrioj.

Unue, ni havas specialan medion. Ĝi estas proksima al produktado, sed ne proksima. Ĝia ĉefa trajto estas, ke ĝi estu malmultekosta, ripetebla kaj kiel eble plej aŭtomatigita. Kaj ankaŭ devas esti specialaj iloj por fari detalan analizon.

Plej verŝajne, kiam ni lanĉas aviadilon kaj flugas, ni havas malpli da ŝanco studi ĉiun milimetron de la flugilsurfaco ol ni havas en ventotunelo. Ni havas pli da diagnozaj iloj. Ni povas havigi porti pli pezajn aĵojn kiujn ni ne povas havigi surmeti aviadilon en la aero. Same kun Postgres. Ni povas, en iuj kazoj, ebligi plenan ensalutadon dum eksperimentoj. Kaj ni ne volas fari ĉi tion en produktado. Ni eĉ povas plani ebligi ĉi tion per auto_explain.

Kaj kiel mi diris, alta nivelo de aŭtomatigo signifas, ke ni premas la butonon kaj ripetas. Tiel devus esti, por ke estu multe da eksperimentado, por ke ĝi estu surflua.

Nancy CLI - la fundamento de la "datumbaza laboratorio"

Kaj do ni faris ĉi tiun aferon. Tio estas, pri ĉi tiuj ideoj mi parolis en junio, antaŭ preskaŭ unu jaro. Kaj ni jam havas la tiel nomatan Nancy CLI en Open Source. Ĉi tio estas la fundamento por konstrui datumbazan laboratorion.

nancy — Ĝi estas en Malferma Kodo, sur Gitlab. Vi povas diri ĝin, vi povas provi ĝin. Mi disponigis ligilon en la lumbildoj. Vi povas klaki sur ĝi kaj ĝi estos tie helpi en ĉiuj aspektoj.

Kompreneble, estas multo ankoraŭ evoluanta. Estas multaj ideoj tie. Sed ĉi tio estas io, kion ni uzas preskaŭ ĉiutage. Kaj kiam ni havas ideon - kial kiam ni forigas 40 liniojn, ĉio venas al IO, tiam ni povas fari eksperimenton kaj rigardi pli detale por kompreni kio okazas kaj tiam provi ripari ĝin dum la irado. Tio estas, ni faras eksperimenton. Ekzemple, ni ĝustigas ion kaj vidas kio okazas finfine. Kaj ni ne faras tion en produktado. Jen la esenco de la ideo.

Kie ĉi tio povas funkcii? Ĉi tio povas funkcii loke, t.e. vi povas fari ĝin ie ajn, vi eĉ povas ruli ĝin sur MacBook. Ni bezonas dokeron, ni iru. Tio estas ĉio. Vi povas ruli ĝin en iu okazo sur aparataro, aŭ en virtuala maŝino, ie ajn.

Kaj ankaŭ ekzistas la ŝanco kuri malproksime en Amazon en EC2 Instanco, en lokoj. Kaj ĉi tio estas tre bonega ŝanco. Ekzemple, hieraŭ ni faris pli ol 500 eksperimentojn pri i3-instanco, komencante per la plej juna kaj finiĝante per i3-16-xlarge. Kaj 500 eksperimentoj kostis al ni $64. Ĉiu daŭris 15 minutojn. Tio estas, pro la fakto, ke makuloj estas uzataj tie, ĝi estas tre malmultekosta - 70% rabato, la sekunda fakturado de Amazon. Vi povas fari multon. Vi povas fari veran esploron.

Kaj tri ĉefaj versioj de Postgres estas subtenataj. Ne estas tiel malfacile fini kelkajn malnovajn kaj ankaŭ la novan 12-an version.

Ni povas difini objekton en tri manieroj. Ĉi tio:

• Dump/sql dosiero.
• La ĉefa maniero estas kloni la dosierujon PGDATA. Kiel regulo, ĝi estas prenita de la rezerva servilo. Se vi havas normalajn binarajn sekurkopiojn, vi povas fari klonojn de tie. Se vi havas nubojn, tiam nuba oficejo kiel Amazon kaj Google faros tion por vi. Ĉi tio estas la plej grava maniero por kloni realan produktadon. Jen kiel ni disvolviĝas.
• Kaj la lasta metodo taŭgas por esplorado kiam vi volas kompreni kiel io funkcias en Postgres. Ĉi tio estas pgbench. Vi povas generi uzante pgbench. Ĝi estas nur unu "db-pgbench" opcio. Vi diru al li kian skalon. Kaj ĉio estos generita en la nubo, kiel dirite.

Kaj ŝarĝu:

• Ni povas ekzekuti la ŝarĝon en unu SQL-fadeno. Ĉi tio estas la plej primitiva maniero.
• Kaj ni povas imiti la ŝarĝon. Kaj ni povas imiti ĝin unue en la sekva maniero. Ni devas kolekti ĉiujn ŝtipojn. Kaj ĝi estas dolora. Mi montros al vi kial. Kaj uzante pgreplay ni ludas, kiu estas konstruita en Nancy.
• Aŭ alia opcio. La tiel nomata metia ŝarĝo, kiun ni faras kun certa peno. Analizante nian nunan ŝarĝon sur la batalsistemo, ni eltiras la ĉefajn grupojn de petoj. Kaj uzante pgbench ni povas imiti ĉi tiun ŝarĝon en la laboratorio.

• Aŭ ni devas plenumi ian SQL, t.e. ni kontrolas ian migradon, kreas indekson tie, ekzekuti ANALAZE tie. Kaj ni rigardas kio okazis antaŭ la vakuo kaj post la vakuo. Ĝenerale, ajna SQL.
• Aŭ ni ŝanĝas unu aŭ plurajn parametrojn en la agordo. Ni povas diri al ni kontroli, ekzemple, 100 valorojn en Amazon por nia terabajta datumbazo. Kaj post kelkaj horoj vi havos la rezulton. Kiel regulo, vi bezonos plurajn horojn por deploji terabajtan datumbazon. Sed estas diakilo en disvolviĝo, ni havas serion ebla, t.e. vi povas konstante uzi la samajn pgdatumojn sur la sama servilo kaj kontroli. Postgres rekomencos kaj kaŝmemoroj estos rekomencigitaj. Kaj vi povas stiri la ŝarĝon.

• Dosierujo alvenas kun amaso da malsamaj dosieroj, komencante de pg momentfotojstat***. Kaj la plej interesa afero estas pg_stat_statements, pg_stat_kcacke. Ĉi tiuj estas du etendoj, kiuj analizas petojn. Kaj pg_stat_bgwriter enhavas ne nur pgwriter-statistikojn, sed ankaŭ pri kontrolpunkto kaj kiel la backends mem delokigas malpurajn bufrojn. Kaj ĉio estas interese vidi. Ekzemple, kiam ni starigas shared_buffers, estas tre interese vidi kiom ĉiuj anstataŭigis.
• Ankaŭ postgresaj protokoloj alvenas. Du protokoloj - preparado-protokolo kaj ŝarĝa reprodukta protokolo.
• Relative nova funkcio estas FlameGraphs.
• Ankaŭ, se vi uzis pgreplay aŭ pgbench-opciojn por ludi la ŝarĝon, tiam ilia eligo estos denaska. Kaj vi vidos latentecon kaj TPS. Eblos kompreni kiel ili vidis ĝin.
• Sisteminformoj.
• Bazaj CPU kaj IO-kontroloj. Ĉi tio estas pli por EC2-instanco en Amazon, kiam vi volas lanĉi 100 identajn okazojn en fadeno kaj ruli 100 malsamajn kurojn tie, tiam vi havos 10 eksperimentojn. Kaj vi devas certigi, ke vi ne renkontas misan kazon, kiu jam estas subpremata de iu. Aliaj aktivas pri ĉi tiu aparataro kaj vi restas malmulte da rimedo. Pli bone estas forĵeti tiajn rezultojn. Kaj helpe de sysbench de Alexey Kopytov, ni faras plurajn mallongajn kontrolojn kiuj venos kaj povas esti komparitaj kun aliaj, t.e. vi komprenos kiel la CPU kondutas kaj kiel la IO kondutas.

Kio estas la teknikaj malfacilaĵoj bazitaj sur la ekzemplo de malsamaj kompanioj?

Ni diru, ke ni volas ripeti la realan ŝarĝon uzante protokolojn. Estas bonega ideo se ĝi estas skribita sur Open Source pgreplay. Ni uzas ĝin. Sed por ke ĝi bone funkciu, vi devas ebligi plenan ensalutadon kun parametroj kaj tempo.

Estas iuj komplikaĵoj kun daŭro kaj tempomarko. Ni malplenigos ĉi tiun tutan kuirejon. La ĉefa demando estas ĉu vi povas pagi ĝin aŭ ne?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

La problemo estas, ke ĝi eble ne disponeblas. Antaŭ ĉio, vi devas kompreni, kia fluo estos skribita al la protokolo. Se vi havas pg_stat_statements, vi povas uzi ĉi tiun demandon (la ligilo estos disponebla en la diapozitivoj) por kompreni proksimume kiom da bajtoj estos skribitaj sekundo.

Ni rigardas la longecon de la peto. Ni neglektas la fakton, ke ne ekzistas parametroj, sed ni scias la longecon de la peto kaj ni scias kiom da fojoj por sekundo ĝi estis efektivigita. Tiel ni povas taksi proksimume kiom da bajtoj sekundo. Ni eble eraros duoble pli, sed ni certe komprenos la ordon tiamaniere.

Ni povas vidi, ke 802 fojojn je sekundo ĉi tiu peto estas efektivigita. Kaj ni vidas, ke bytes_per sek - 300 kB/s estos skribitaj plus aŭ minus. Kaj, kiel regulo, ni povas pagi tian fluon.

Sed! La fakto estas, ke ekzistas malsamaj registradsistemoj. Kaj la defaŭlto de homoj estas kutime "syslog".

Kaj se vi havas syslog, tiam vi eble havas bildon kiel ĉi tiu. Ni prenos pgbench, ebligos demandan registradon kaj vidos kio okazas.

Sen ensaluti - ĉi tiu estas la kolumno maldekstre. Ni ricevis 161 TPS. Kun syslog - ĉi tio estas en Ubuntu 000 sur Amazon, ni ricevas 16.04 TPS. Kaj se ni ŝanĝas al du aliaj registradaj metodoj, tiam la situacio estas multe pli bona. Tio estas, ni atendis, ke ĝi falos, sed ne samgrade.

Kaj ĉe CentOS 7, en kiu ankaŭ journald partoprenas, igante protokolojn en binaran formaton por facila serĉado, ktp., tiam ĝi estas koŝmaro tie, ni faligas 44 fojojn en TPS.

Kaj jen kio homoj vivas. Kaj ofte en kompanioj, precipe grandaj, tio estas tre malfacile ŝanĝi. Se vi povas foriri de syslog, do bonvolu foriri de ĝi.

• Taksi IOPS kaj skribu fluon.
• Kontrolu vian registran sistemon.
• Se la projekciita ŝarĝo estas troe granda, konsideru specimenigon.

Ni havas pg_stat_statements. Kiel mi diris, ĝi devas esti tie. Kaj ni povas preni kaj priskribi ĉiun grupon de petoj en speciala maniero en dosiero. Kaj tiam ni povas uzi tre oportunan funkcion en pgbench - ĉi tio estas la kapablo enmeti plurajn dosierojn per la opcio "-f".

Ĝi komprenas multe da "-f". Kaj vi povas diri helpe de "@" ĉe la fino, kian parton ĉiu dosiero devus havi. Tio estas, ni povas diri, ke fari ĉi tion en 10% de kazoj, kaj ĉi tio en 20%. Kaj ĉi tio proksimigos nin al tio, kion ni vidas en produktado.

Kiel ni komprenos kion ni havas en produktado? Kia parto kaj kiel? Ĉi tio estas iom flanken. Ni havas unu plian produkton postgres-kontrolo. Ankaŭ bazo en Open Source. Kaj ni nun aktive disvolvas ĝin.

Li naskiĝis pro iomete malsamaj kialoj. Pro kialoj, ke monitorado ne sufiĉas. Tio estas, vi venas, rigardu la bazon, rigardu la problemojn, kiuj ekzistas. Kaj, kiel regulo, vi faras san_kontrolon. Se vi estas sperta DBA, tiam vi faras health_check. Ni rigardis la uzon de indeksoj, ktp. Se vi havas OKmeter, do bonege. Ĉi tio estas bonega monitorado por Postgres. OKmeter.io - bonvolu instali ĝin, ĉio estas farita tre bone tie. Ĝi estas pagita.

Se vi ne havas tian, tiam vi kutime ne havas multon. En monitorado, estas kutime CPU, IO, kaj poste kun rezervoj, kaj jen ĉio. Kaj ni bezonas pli. Ni devas vidi kiel funkcias la aŭtomata vakuo, kiel funkcias la kontrolpunkto, en io ni devas apartigi la kontrolpunkton de la bgwriter kaj de la backends, ktp.

La problemo estas, ke kiam vi helpas grandan kompanion, ili ne povas efektivigi ion rapide. Ili ne povas rapide aĉeti OKmeter. Eble ili aĉetos ĝin post ses monatoj. Ili ne povas rapide liveri kelkajn pakaĵojn.

Kaj ni elpensis la ideon, ke ni bezonas specialan ilon, kiu ne postulas ion ajn por esti instalita, t.e. vi tute ne devas instali ion ajn en produktado. Instalu ĝin sur via tekkomputilo, aŭ sur observa servilo de kie vi rulos ĝin. Kaj ĝi analizos multajn aferojn: la operaciumon, la dosiersistemon, kaj Postgres mem, farante kelkajn malpezajn demandojn, kiuj povas esti rulitaj rekte al produktado kaj nenio malsukcesos.

Ni nomis ĝin Postgres-checkup. En medicinaj terminoj, ĉi tio estas regula sankontrolo. Se ĝi estas aŭtomobila temo, tiam ĝi estas kiel prizorgado. Vi prizorgas vian aŭton ĉiujn ses monatojn aŭ jare, depende de la marko. Ĉu vi prizorgas vian bazon? Tio estas, ĉu vi faras profundan esploron regule? Ĝi devas esti farita. Se vi faras sekurkopiojn, tiam faru kontrolon, ĉi tio ne estas malpli grava.

Kaj ni havas tian ilon. Ĝi komencis aktive aperi nur antaŭ ĉirkaŭ tri monatoj. Li estas ankoraŭ juna, sed estas multe tie.

Kolektante la plej "influajn" grupojn de demandoj - raportu K003 en Postgres-checkup

Kaj estas grupo de raportoj K. Tri raportoj ĝis nun. Kaj ekzistas tia raporto K003. Estas la supro de pg_stat_statements, ordigita laŭ totala_tempo.

Kiam ni ordigas petajn grupojn laŭ totala_tempo, supre ni vidas la grupon, kiu plej ŝarĝas nian sistemon, t.e. konsumas pli da rimedoj. Kial mi nomas demandajn grupojn? Ĉar ni forĵetis la parametrojn. Tiuj ne plu estas petoj, sed grupoj de petoj, t.e. ili estas abstraktitaj.

Kaj se ni optimumigas de supre ĝis malsupre, ni malpezigos niajn rimedojn kaj prokrastos la momenton, kiam ni bezonos ĝisdatigi. Ĉi tio estas tre bona maniero ŝpari monon.

Eble ĉi tio ne estas tre bona maniero prizorgi uzantojn, ĉar ni eble ne vidas maloftajn, sed tre ĝenajn kazojn, kie persono atendis 15 sekundojn. Entute ili estas tiel maloftaj, ke ni ne vidas ilin, sed ni traktas rimedojn.

Kio okazis en ĉi tiu tabelo? Ni faris du momentfotojn. Postgres_checkup donos al vi delton por ĉiu metriko: totala tempo, alvokoj, vicoj, shared_blks_read, ktp. Jen, la delto estis kalkulita. La granda problemo kun pg_stat_statements estas ke ĝi ne memoras kiam ĝi estis rekomencigita. Se pg_stat_database memoras, tiam pg_stat_statements ne memoras. Vi vidas, ke estas nombro de 1, sed ni ne scias de kie ni kalkulis.

Kaj jen ni scias, jen ni havas du momentfotojn. Ni scias, ke la delto en ĉi tiu kazo estis 56 sekundoj. Tre mallonga interspaco. Ordigita laŭ totala_tempo. Kaj tiam ni povas diferencigi, t.e. ni dividas ĉiujn metrikojn per daŭro. Se ni dividas ĉiun metrikon per daŭro, ni havos la nombron da vokoj por sekundo.

Poste, total_time je sekundo estas mia plej ŝatata metriko. Ĝi estas mezurita en sekundoj, je sekundo, t.e. kiom da sekundoj necesis nia sistemo por efektivigi ĉi tiun grupon de petoj je sekundo. Se vi vidas pli ol sekundon tie, tio signifas, ke vi devis doni pli ol unu kernon. Ĉi tio estas tre bona metriko. Vi povas kompreni, ke ĉi tiu amiko, ekzemple, bezonas almenaŭ tri kernojn.

Ĉi tio estas nia scipovo, mi neniam vidis ion tian ie ajn. Bonvolu noti - tio estas tre simpla afero - sekundo por sekundo. Kelkfoje, kiam via CPU estas 100%, tiam duonhoro por sekundo, tio estas, vi pasigis duonhoron farante nur ĉi tiujn petojn.

Poste ni vidas vicojn por sekundo. Ni scias kiom da vicoj por sekundo ĝi revenis.

Kaj poste estas ankaŭ interesa afero. Kiom da shared_buffers ni legas je sekundo el la shared_buffers mem. La sukcesoj jam estis tie, kaj ni prenis la vicojn el la mastruma kaŝmemoro aŭ el la disko. La unua opcio estas rapida, kaj la dua povas aŭ ne esti rapida, depende de la situacio.

Kaj la dua maniero de diferencigo estas dividi la nombron da petoj en ĉi tiu grupo. En la dua kolumno vi ĉiam havos unu demandon dividitan per demando. Kaj tiam estas interese - kiom da milisekundoj estis en ĉi tiu peto. Ni scias kiel ĉi tiu demando averaĝe kondutas. 101 milisekundoj estis postulataj por ĉiu peto. Ĉi tiu estas la tradicia metriko, kiun ni bezonas kompreni.

Kiom da vicoj ĉiu demando resendis averaĝe? Ni vidas 8 ĉi tiu grupo revenas. Averaĝe, kiom estis prenita el la kaŝmemoro kaj legita. Ni vidas, ke ĉio estas bele konservita. Solidaj sukcesoj por la unua grupo.

Kaj la kvara subĉeno en ĉiu linio estas kia procento de la tuta. Ni havas vokojn. Ni diru 1 000 000. Kaj ni povas kompreni, kian kontribuon faras ĉi tiu grupo. Ni vidas, ke ĉi-kaze la unua grupo kontribuas malpli ol 0,01%. Tio estas, ĝi estas tiel malrapida, ke ni ne vidas ĝin en la ĝenerala bildo. Kaj la dua grupo estas 5% sur vokoj. Tio estas, 5% de ĉiuj vokoj estas la dua grupo.

Tuta_tempo ankaŭ estas interesa. Ni elspezis 14% de nia tuta labortempo por la unua grupo de petoj. Kaj por la dua - 11%, ktp.

Mi ne eniros detalojn, sed estas subtilecoj tie. Ni montras eraron ĉe la supro, ĉar kiam ni komparas, momentfotoj povas flosi, tio estas, iuj petoj povas elfali kaj ne plu povas ĉeesti en la dua, dum kelkaj novaj povas aperi. Kaj tie ni kalkulas la eraron. Se vi vidas 0, tiam tio estas bona. Ne estas eraroj. Se la eraroprocento estas ĝis 20%, ĝi estas en ordo.

Poste ni revenas al nia temo. Ni devas krei la laborkvanton. Ni prenas ĝin de supre malsupren kaj iras ĝis ni atingas 80% aŭ 90%. Kutime ĉi tio estas 10-20 grupoj. Kaj ni faras dosierojn por pgbench. Ni uzas hazarde tie. Kelkfoje ĉi tio, bedaŭrinde, ne funkcias. Kaj en Postgres 12 estos pli da ŝancoj uzi ĉi tiun aliron.

Kaj tiam ni gajnas 80-90% en totala_tempo tiamaniere. Kion mi poste metu post “@”? Ni rigardas la vokojn, rigardas kiom da intereso estas kaj komprenas, ke ni ŝuldas tiom da intereso ĉi tie. El ĉi tiuj procentoj ni povas kompreni kiel ekvilibrigi ĉiun el la dosieroj. Post tio ni uzas pgbench kaj eklaboru.

Ni ankaŭ havas K001 kaj K002.

K001 estas unu granda ŝnuro kun kvar subŝnuroj. Ĉi tio estas karakterizaĵo de nia tuta ŝarĝo. Vidu duan kolumnon kaj duan subvicon. Ni vidas, ke ĉirkaŭ unu kaj duono sekundoj sekundo, t.e. se estas du kernoj, tiam ĝi estos bona. Estos proksimume 75% kapacito. Kaj ĝi funkcios tiel. Se ni havas 10 kernojn, tiam ni ĝenerale estos trankvilaj. Tiel ni povas taksi rimedojn.

K002 estas tio, kion mi nomas demandaj klasoj, t.e. ELEKTU, INSERT, UPDATE, DELETE. Kaj aparte SELECT FOR UPDATE, ĉar ĝi estas seruro.

Kaj ĉi tie ni povas konkludi, ke SELECT estas ordinaraj legantoj - 82% de ĉiuj vokoj, sed samtempe - 74% en totala_tempo. Tio estas, ili nomiĝas multe, sed konsumas malpli da rimedoj.

Kaj ni revenas al la demando: "Kiel ni povas elekti la ĝustajn shared_buffers?" Mi observas, ke la plej multaj komparnormoj baziĝas sur la ideo - ni vidu kia estos la trafluo, t.e. kia estos la trafluo. Ĝi estas kutime mezurita en TPS aŭ QPS.

Kaj ni provas elpremi kiel eble plej multajn transakciojn por sekundo de la aŭto uzante agordajn parametrojn. Jen ĝuste 311 por sekundo por elektita.

Sed neniu veturas al la laboro kaj reen hejmen plenrapide. Ĉi tio estas stulta. Same kun datumbazoj. Ni ne devas veturi plenrapide, kaj neniu faras. Neniu vivas en produktado, kiu havas 100% CPU. Kvankam, eble iu vivas, sed ĉi tio ne estas bona.

La ideo estas, ke ni kutime veturas je 20 procentoj de kapablo, prefere ne pli ol 50%. Kaj ni provas antaŭ ĉio optimumigi respondtempon por niaj uzantoj. Tio estas, ni devas turni niajn knobs tiel ke ekzistas minimuma latencia je 20% rapideco, kondiĉe. Ĉi tio estas ideo, kiun ni ankaŭ provas uzi en niaj eksperimentoj.

Kaj finfine rekomendoj:

• Nepre faru Database Lab.
• Se eble, faru ĝin laŭpostule, por ke ĝi disvolvu iom da tempo - ludu kaj forĵetu ĝin. Se vi havas nubojn, tiam ĉi tio nepre, t.e. havas multe da starado.
• Estu scivolema. Kaj se io estas malĝusta, tiam kontrolu per eksperimentoj kiel ĝi kondutas. Nancy povas esti uzata por trejni vin por kontroli kiel funkcias la bazo.
• Kaj celu la minimuman respondtempon.
• Kaj ne timu Postgres-fontojn. Kiam vi laboras kun fontoj, vi devas scii la anglan. Estas multe da komentoj tie, ĉio estas klarigita tie.
• Kaj kontrolu la sanon de la datumbazo regule, almenaŭ unufoje ĉiujn tri monatojn, permane, aŭ Postgres-checkup.

Viaj demandoj

Multaj dankoj! Tre interesa afero.

Du pecoj.

Jes, du pecoj. Nur mi ne tute komprenis. Kiam Nancy kaj mi laboras, ĉu ni povas ĝustigi nur unu parametron aŭ tutan grupon?

Ni havas delta agordan parametron. Vi povas turni tien tiom kiom vi volas tuj. Sed vi devas kompreni, ke kiam vi ŝanĝas multajn aferojn, vi povas tiri malĝustajn konkludojn.

Jes. Kial mi demandis? Ĉar estas malfacile fari eksperimentojn kiam vi havas nur unu parametron. Vi streĉu ĝin, vidu kiel ĝi funkcias. Mi elmetis lin. Tiam vi komencas la sekvan.

Vi povas streĉi ĝin samtempe, sed tio dependas de la situacio, kompreneble. Sed estas pli bone testi unu ideon. Ni havis ideon hieraŭ. Ni havis tre proksiman situacion. Estis du agordoj. Kaj ni ne povis kompreni kial estis granda diferenco. Kaj ekestis la ideo, ke oni devas uzi dikotomion por konstante kompreni kaj trovi, kia estas la diferenco. Vi povas tuj fari duonon de la parametroj samaj, poste kvaronon, ktp. Ĉio estas fleksebla.

Kaj estas unu plia demando. La projekto estas juna kaj evoluanta. La dokumentaro jam estas preta, ĉu estas detala priskribo?

Mi specife faris tie ligon al la priskribo de la parametroj. Ĝi estas tie. Sed multaj aferoj ankoraŭ ne estas tie. Mi serĉas samideanojn. Kaj mi trovas ilin kiam mi plenumas. Ĉi tio estas tre mojosa. Iu jam laboras kun mi, iu helpis kaj faris ion tie. Kaj se vi interesiĝas pri ĉi tiu temo, donu komentojn pri tio, kio mankas.

Post kiam ni konstruos la laboratorion, eble estos sugestoj. Ni vidu. Dankon!

Saluton! Dankon pro la raporto! Mi vidis, ke ekzistas Amazon-subteno. Ĉu ekzistas planoj subteni GSP?

Bona demando. Ni komencis fari ĝin. Kaj ni frostigis ĝin nuntempe ĉar ni volas ŝpari monon. Tio estas, ekzistas subteno uzanta run on localhost. Vi povas mem krei ekzemplon kaj labori loke. Cetere, tion ni faras. Mi faras tion ĉe Getlab, tie ĉe GSP. Sed ni ankoraŭ ne vidas la signifon fari nur tian instrumentadon, ĉar Guglo ne havas malmultekostajn lokojn. Estas ??? okazoj, sed ili havas limojn. Unue, ili ĉiam havas nur 70% rabaton kaj vi ne povas ludi kun la prezo tie. Sur lokoj, ni pliigas la prezon je 5-10% por redukti la verŝajnecon, ke vi estos piedbatita. Tio estas, vi ŝparas makulojn, sed ili povas esti forprenitaj de vi iam ajn. Se vi ofertos iom pli alte ol aliaj faras, vi estos mortigita poste. Guglo havas tute malsamajn specifaĵojn. Kaj estas alia tre malbona limigo - ili vivas nur 24 horojn. Kaj foje ni volas fari eksperimenton dum 5 tagoj. Sed vi povas fari tion en lokoj; makuloj foje daŭras monatojn.

Saluton! Dankon pro la raporto! Vi menciis kontrolon. Kiel vi kalkulas erarojn de stat_statements?

Tre bona demando. Mi povas montri kaj rakonti al vi tre detale. Resume, ni rigardas kiel flosis la aro de petaj grupoj: kiom da defalis kaj kiom da novaj aperis. Kaj tiam ni rigardas du metrikojn: totala_tempo kaj vokoj, do estas du eraroj. Kaj ni rigardas la kontribuon de la flosantaj grupoj. Estas du subgrupoj: tiuj kiuj foriris kaj tiuj kiuj alvenis. Ni vidu, kia estas ilia kontribuo al la ĝenerala bildo.

Ĉu vi ne timas, ke ĝi turniĝos tien du aŭ tri fojojn dum la tempo inter momentfotoj?

Tio estas, ĉu ili denove registriĝis aŭ kio?

Ekzemple, ĉi tiu peto jam estis antaŭigita unufoje, tiam ĝi venis kaj denove estis antaŭigita, tiam ĝi denove venis kaj denove estis antaŭigita. Kaj vi kalkulis ion ĉi tie, kaj kie ĉio estas?

Bona demando, ni devos rigardi.

Mi faris similan aferon. Estis pli simple, kompreneble, mi faris ĝin sola. Sed mi devis restarigi, restarigi stat_statements kaj eltrovi ĉe la momento de la momentfoto, ke estis malpli ol certa frakcio, kiu ankoraŭ ne atingis la plafonon de kiom stat_statements povus akumuliĝi tie. Kaj mia kompreno estas ke, plej verŝajne, nenio estis delokigita.

Jes Jes.

Sed mi ne komprenas kiel alie fari ĝin fidinde.

Bedaŭrinde, mi ne precize memoras ĉu ni uzas la demandtekston tie aŭ queryid kun pg_stat_statements kaj koncentriĝas pri ĝi. Se ni koncentriĝas pri queryid, tiam en teorio ni komparas kompareblajn aferojn.

Ne, li povas esti pelita plurfoje inter momentfotoj kaj veni denove.

Kun la sama identigilo?

Jes.

Ni studos ĉi tion. Bona demando. Ni devas studi ĝin. Sed nuntempe, kion ni vidas, estas aŭ skribita 0...

Ĉi tio estas, kompreneble, malofta kazo, sed mi estis ŝokita kiam mi eksciis, ke stat_statemetns povas translokiĝi tien.

Povas esti multaj aferoj en Pg_stat_statements. Ni trovis la fakton, ke se vi havas track_utility = on, tiam viaj aroj ankaŭ estas spuritaj.

Jes kompreneble.

Kaj se vi havas java hibernate, kio estas hazarda, tiam la hashtabelo komencas troviĝi tie. Kaj tuj kiam vi malŝaltas tre ŝarĝitan aplikaĵon, vi finiĝas kun 50-100 grupoj. Kaj ĉio estas pli-malpli stabila tie. Unu maniero kontraŭbatali ĉi tion estas pliigi pg_stat_statements.max.

Jes, sed vi devas scii kiom. Kaj iel ni devas observi lin. Tion mi faras. Tio estas, mi havas pg_stat_statements.max. Kaj mi vidas, ke en la momento de la momentfoto mi ne atingis 70%. Bone, do ni nenion perdis. Ni restarigi. Kaj ni savas denove. Se la sekva momentfoto estas malpli ol 70, tiam plej verŝajne vi nenion perdis denove.

Jes. La defaŭlta nun estas 5 000. Kaj ĉi tio sufiĉas por multaj homoj.

Kutime jes.

Video:

PS En mia propra nomo, mi aldonos, ke se Postgres enhavas konfidencajn datumojn kaj ĝi ne povas esti inkluzivita en la testa medio, tiam vi povas uzi PostgreSQL Anonymizer. La skemo estas proksimume kiel sekvas:

fonto: www.habr.com