Filozofia enkonduko
Kiel vi scias, ekzistas nur du metodoj por solvi problemojn:
- Metodo de analizo aŭ metodo de dedukto, aŭ de ĝenerala al specifa.
- Metodo de sintezo aŭ metodo de indukto, aŭ de aparta al ĝenerala.
Por solvi la problemon "plibonigi datumbazan rendimenton", ĝi povus aspekti tiel.
Анализ — ni analizas la problemon en apartajn partojn kaj solvante ilin ni provas plibonigi la agadon de la datumbazo entute.
En praktiko, la analizo aspektas kiel ĉi tio:
- Problemo okazas (efikeckazaĵo)
- Kolekti statistikajn informojn pri la stato de la datumbazo
- Serĉante botelojn
- Ni solvas problemojn el boteloj
Datenbazaj proplempunktoj — infrastrukturo (CPU, Memoro, Diskoj, Reto, OS), agordoj (postgresql.conf), demandoj:
Infrastrukturo: La eblecoj de influo kaj ŝanĝo por inĝeniero estas preskaŭ nulaj.
Datumbazaj Agordoj: la eblecoj por ŝanĝoj estas iomete pli grandaj ol en la antaŭa kazo, sed kutime ili estas ankoraŭ sufiĉe malfacilaj, precipe en la nuboj.
Petoj al la datumbazo: nur spaco por manovro.
Sintezo — ni plibonigas la agadon de individuaj partoj, atendante, ke la rendimento de la datumbazo pliboniĝos kiel rezulto.
Lirika enkonduko aŭ kial ĉio ĉi estas necesa
Kio estas la procezo por solvi spektaklokazaĵojn se datumbaza rendimento ne estas monitorita:
Kliento - "ĉio estas malbona ĉe ni, ĝi daŭras tro longe, faru ion bonan por ni"
Inĝeniero - "kiel malbona estas tio?"
La kliento - "tiel estas nun (antaŭ unu horo, hieraŭ, lasta fojo), malrapide"
Inĝeniero - "kiam ĝi estis bona?"
Kliento – “antaŭ semajno (du semajnoj) ĝi ne estis malbona. "(Estas bonŝance)
Kliento - "Mi ne memoras, kiam ĝi estis bona, sed nun ĝi estas malbona" (Regula respondo)
La rezulto estas klasika bildo:
Kiu kulpas kaj kion fari?
La unua parto de la demando estas la plej facile respondebla - la DBA-inĝeniero ĉiam kulpas.
La dua parto ankaŭ ne estas tro malfacila por respondi - vi devas efektivigi datumbazan rendimentan monitoradsistemon.
La unua demando ŝprucas - kion kontroli?
Vojo 1. Ni kontrolos ĈION
CPU-ŝarĝo, nombro da disko-legi/skribaj operacioj, grandeco de asignita memoro, kaj alia megatono da malsamaj nombriloj, kiujn povas provizi pli-malpli laboranta monitora sistemo.
La rezulto estas amaso da grafikaĵoj, resumaj tabeloj kaj kontinuaj retpoŝtaj sciigoj kaj 100% okupata inĝeniero solvante amason da identaj biletoj, tamen, kutime, kun la norma vortumo - "Provizora afero. Neniu ago necesa." Sed ĉiuj estas okupataj, kaj ĉiam estas io por montri al la kliento - laboro estas en plena svingo.
Vojo 2. Monitoru nur tion, kio estas bezonata, kaj tio, kio ne estas bezonata, ne bezonas esti kontrolata
Vi povas monitori, iom alie, nur entojn kaj eventojn:
- Kiun DBA-Inĝeniero Povas Influi
- Por kiu ekzistas algoritmo de agoj kiam okazaĵo okazas aŭ ento ŝanĝiĝas.
Surbaze de ĉi tiu supozo kaj memoro "Filozofia enkonduko"por eviti regulan ripeton"Lirika enkonduko aŭ kial ĉio ĉi estas necesa"Estus konsilinde kontroli la agadon de individuaj demandoj por optimumigo kaj analizo, kio finfine devus konduki al plibonigita agado de la tuta datumbazo.
Sed por plibonigi pezan demandon, kiu influas ĝeneralan datumbazan rendimenton, vi unue devas trovi ĝin.
Do, du interrilataj demandoj ekestas:
- kiu peto estas konsiderata malfacila
- kiel serĉi malfacilajn demandojn.
Evidente, peza demando estas demando, kiu uzas multajn OS-resursojn por akiri la rezulton.
Ni transiru al la dua demando - kiel serĉi kaj poste kontroli pezajn demandojn?
Kiajn konsultajn monitoradkapablojn havas PostgreSQL?
Kompare kun Oracle, estas malmultaj eblecoj, sed tamen io povas esti farita.
PG_STAT_STATEMENTS
Por serĉi kaj kontroli pezajn demandojn en PostgreSQL, la norma etendaĵo pg_stat_statements estas celita.
Post instalo de la etendo, vido de la sama nomo aperas en la cela datumbazo, kiu devus esti uzata por monitoraj celoj.
Celu pg_stat_statements-kolumnojn por konstrui monitoran sistemon:
- queryid Interna hashkodo kalkulita de la analiza arbo de la funkciigisto
- max_tempo Maksimuma tempo pasigita por deklaro, en milisekundoj
Amasigante kaj uzante statistikojn pri ĉi tiuj du kolumnoj, vi povas konstrui monitoran sistemon.
Kiel pg_stat_statements estas uzata por kontroli la agadon de PostgreSQL
Por kontroli demandan rendimenton uzu:
Sur la cela datumbazo flanko - pg_stat_statements vido
De la flanko servilo kaj monitorado de datumbazoj - aro de bash-skriptoj kaj servaj tabeloj.
Etapo 1 - kolekto de statistikaj datumoj
Sur la cron monitora gastiganto, skripto estas regule lanĉita kiu kopias la enhavon de la pg_stat_statements vido de la cela datumbazo al la pg_stat_history tabelo en la monitorada datumbazo.
Ĉi tio kreas historion de individuaj demandaj ekzekutoj, kiuj povas esti uzataj por generi rendimentajn raportojn kaj agordi metrikojn.
Etapo 2 - agordo de agado-metrikoj
Surbaze de la kolektitaj datumoj, ni elektas demandojn, kies ekzekuto estas plej kritika/grava por la kliento (aplikaĵo). En konsento kun la kliento, ni fiksas la valorojn de agado-metrikoj uzante la queryid kaj max_time kampoj.
Rezulto - komenco de agado-monitorado
- La monitora skripto, kiam ĝi ruliĝas, kontrolas la agordajn agadon-metrikojn komparante la max_time-valoron de la metriko kun la valoro de la pg_stat_statements-vido en la cela datumbazo.
- Se la valoro en la cela datumbazo superas la metrikan valoron, averto estas generita (okazaĵo en la biletsistemo)
Plia opcio 1
Pridemandu planhistorion
Por posta solvado de agado-okazaĵoj, estas tre bone havi historion de ŝanĝado de demandaj ekzekutplanoj.
La tabelo de servo log_query estas uzata por konservi historion. La tabelo estas plenigita kiam oni analizas la ŝarĝitan protokoldosieron de PostgreSQL. Ĉar la protokolo-dosiero, male al la vido pg_stat_statements, enhavas la plenan tekston kun la valoroj de ekzekutparametroj, kaj ne normaligita teksto, eblas registri ne nur la tempon kaj daŭron de petoj, sed ankaŭ stoki ekzekutplanojn ĉe la aktuala. tempo.
Plia opcio 2
Procezo de kontinua plibonigo de rendimento
Monitorado de individuaj demandoj ĝenerale ne intencas solvi la problemon de kontinue plibonigado de la agado de la datumbazo entute, ĉar ĝi monitoras kaj solvas rendimentajn problemojn nur por individuaj demandoj. Tamen, vi povas etendi la metodon kaj agordi monitorajn demandojn por ĉiuj datumbazoj.
Por fari tion, vi devas enigi pliajn rendimentajn metrikojn:
- En la lastaj tagoj
- Por la baza periodo
La skripto elektas demandojn el la vido pg_stat_statements en la cela datumbazo kaj komparas la max_time-valoron kun la meza max_time-valoro, en la unua kazo por la lastaj tagoj aŭ por la elektita tempoperiodo (bazlinio), en la dua kazo.
Tiel, en kazo de rendimento degenero por iu peto, averto estos generita aŭtomate, sen mana analizo de raportoj.
Kion rilatas la sintezo?
En la priskribita aliro, kiel la sinteza metodo sugestas, plibonigante individuajn partojn de la sistemo, ni plibonigas la sistemon entute.
- Demando efektivigita de datumbazo - abstrakta
- Modifita peto - antitezo
- Ŝanĝi la staton de la sistemo - sintezo
Sistemevoluo
- Etendaĵoj de kolektitaj statistikoj aldonante historion por la pg_stat_activity-sistemvido
- Pligrandigante la kolektitajn statistikojn aldonante historion por statistikoj de individuaj tabeloj partoprenantaj en demandoj
- Integriĝo kun AWS-nuba monitora sistemo
- Kaj tamen, vi povas elpensi ion...
fonto: www.habr.com
