Ech proposéieren Iech den Transkript vum Bericht vum Ufank vum 2016 vum Andrey Salnikov ze liesen "Typesch Feeler an Applikatiounen, déi zu Bloat am Postgresql féieren"
An dësem Bericht wäert ech d'Haaptfehler an Uwendungen analyséieren, déi an der Stadium vum Design an der Applikatiounscode entstinn. An ech huelen nëmmen déi Feeler, déi zu Bloat am Postgresql féieren. Als Regel, ass dëst den Ufank vum Enn vun der Leeschtung vun Ärem System als Ganzt, obwuel am Ufank keng Viraussetzunge fir dës sichtbar waren.
Frou jidderengem begréissen ze kënnen! Dëse Bericht ass net sou technesch wéi dee virdrun vu mengem Kolleg. Dëse Bericht riicht sech haaptsächlech op Backend System Entwéckler well mir eng zimlech grouss Zuel vu Clienten hunn. A si maachen all déiselwecht Feeler. Ech wäert Iech iwwer si soen. Ech wäert erkläre wat fatal a schlecht Saachen dës Feeler féieren.
Firwat gi Feeler gemaach? Si ginn aus zwee Grënn gemaach: zoufälleg, vläicht klappt et a wéinst Ignoranz vun e puer Mechanismen, déi um Niveau tëscht der Datebank an der Applikatioun geschéien, wéi och an der Datebank selwer.
Ech ginn Iech dräi Beispiller mat schreckleche Biller vun wéi schlecht Saache ginn. Ech soen Iech kuerz iwwer de Mechanismus deen do geschitt. A wéi mat hinnen ëmzegoen, wéini se geschitt sinn, a wéi eng präventiv Methoden ze benotzen fir Feeler ze vermeiden. Ech soen Iech iwwer d'Hëllefsinstrumenter a liwweren nëtzlech Linken.
Ech hunn eng Test Datebank benotzt wou ech zwee Dëscher haten. Eng Plack mat Clientskonten, déi aner mat Transaktiounen op dëse Konten. A mat e puer Frequenz aktualiséieren mir d'Saldoten op dëse Konten.
Éischt Daten vun der Plack: et ass relativ kleng, 2 MB. D'Äntwertzäit fir d'Datebank a speziell fir d'Schëld ass och ganz gutt. An eng zimlech gutt Laascht - 2 Operatiounen pro Sekonn no der Plack.
An duerch dëse Bericht weisen ech Iech Grafike fir datt Dir kloer kënnt verstoen wat geschitt. Et ginn ëmmer 2 Rutschen mat Grafiken. Déi éischt Rutsch ass wat am Allgemengen um Server geschitt.
An an dëser Situatioun gesi mer datt mir wierklech e klengt Schëld hunn. Den Index ass kleng bei 2 MB. Dëst ass déi éischt Grafik op der lénker Säit.
Déi duerchschnëttlech Äntwertzäit um Server ass och stabil a kuerz. Dëst ass déi uewe riets Grafik.
Déi ënnescht lénks Grafik weist déi längsten Transaktiounen. Mir gesinn datt Transaktiounen séier ofgeschloss sinn. An den Autovakuum funktionnéiert nach net hei, well et war e Starttest. Et wäert weider schaffen a wäert eis nëtzlech sinn.
Déi zweet Rutsch wäert ëmmer der Plack gewidmet ginn, déi getest gëtt. An dëser Situatioun aktualiséieren mir dauernd de Kontsalden vum Client. A mir gesinn datt déi duerchschnëttlech Äntwertzäit fir eng Updateoperatioun zimlech gutt ass, manner wéi eng Millisekonnen. Mir gesinn datt Prozessorressourcen (dëst ass déi uewe riets Grafik) och gläichméisseg an zimlech kleng verbraucht ginn.
Déi ënnescht riets Grafik weist wéi vill Betribs- an Disk Memory mir duerchgoen op der Sich no eiser gewënschter Linn ier se aktualiséieren. An d'Zuel vun den Operatiounen no dem Schëld ass 2 pro Sekonn, wéi ech am Ufank gesot hunn.
An elo hu mir eng Tragedie. Aus e puer Grënn gëtt et eng laang vergiess Transaktioun. D'Grënn sinn normalerweis all banal:
- Ee vun de meescht üblech ass datt mir ugefaang hunn Zougang zu engem externen Service am Applikatiounscode. An dëse Service äntwert eis net. Dat ass, mir hunn eng Transaktioun opgemaach, eng Ännerung an der Datebank gemaach an aus der Applikatioun gaang fir Mail ze liesen oder op en anere Service an eiser Infrastruktur, a fir e puer Grond reagéiert se net op eis. An eis Sessioun stécht an engem Zoustand wou et onbekannt ass wéini et geléist gëtt.
- Déi zweet Situatioun ass wann eng Ausnam an eisem Code aus irgendege Grënn geschitt ass. An an der Ausnam hu mir d'Ofschloss vun der Transaktioun net veraarbecht. A mir hu mat enger hängenden Sessioun mat enger oppener Transaktioun ofgeschloss.
- An déi lescht ass och e relativ heefegste Fall. Dëst ass niddereg Qualitéit Code. E puer Kaderen maachen eng Transaktioun op. Et hänkt, an Dir wësst vläicht net an der Applikatioun datt Dir et hänkt.
Wou féiere sou Saachen?
Bis zum Punkt datt eis Dëscher an Indexen dramatesch ufänken ze schwellen. Dëst ass genau dee selwechte Bloat Effekt. Fir d'Datebank bedeit dëst datt d'Datebankreaktiounszäit ganz staark eropgeet an d'Laascht op den Datebankserver eropgeet. An als Resultat wäert eis Applikatioun leiden. Well wann Dir 10 Millisekonnen an Ärem Code op eng Ufro un d'Datebank verbruecht hutt, 10 Millisekonnen op Är Logik, dann huet Är Funktioun 20 Millisekonnen gedauert fir ze kompletéieren. An elo wäert Är Situatioun ganz traureg sinn.
A kucke wat geschitt. Déi ënnescht lénks Grafik weist datt mir eng laang laang Transaktioun hunn. A wa mir déi iewescht lénks Grafik kucken, gesi mer datt d'Gréisst vun eisem Dësch op eemol vun zwee Megabytes op 300 Megabytes sprang ass. Zur selwechter Zäit ass d'Quantitéit vun den Donnéeën an der Tabell net geännert, dat heescht datt et eng zimlech grouss Quantitéit vu Gerempels ass.
D'allgemeng Situatioun betreffend der Moyenne Server Äntwert Zäit huet och duerch e puer Uerden vun Gréisst geännert. Dat ass, all Ufroen um Server ugefaang komplett ze falen. A gläichzäiteg goufen intern Postgres Prozesser a Form vun Autovakuum lancéiert, déi probéieren eppes ze maachen a Ressourcen ze konsuméieren.
Wat ass mat eisem Schëld lass? Datselwecht. Eis duerchschnëttlech Äntwertzäit no dem Schëld ass e puer Uerderen vun der Gréisst eropgaang. Besonnesch a punkto verbrauchte Ressourcen gesi mir datt d'Laascht op de Prozessor staark eropgaang ass. Dëst ass déi uewe riets Grafik. An et ass eropgaang, well de Prozessor muss duerch eng Rëtsch nëtzlos Linnen sortéieren op der Sich no deem néidegen. Dëst ass ënnen riets Grafik. An als Resultat hunn eis Zuel vun Uriff pro Sekonn ganz däitlech erofgaang, well d'Datebank keng Zäit hat fir déiselwecht Unzuel vun Ufroen ze veraarbecht.
Mir mussen zréck an d'Liewen kommen. Mir ginn online an erauszefannen, datt laang Transaktiounen zu Problemer féieren. Mir fannen an ëmbréngen dës Transaktioun. An alles gëtt fir eis normal. Alles funktionnéiert wéi et soll.
Mir sinn berouegt, awer no enger Zäit fänken mer un ze mierken datt d'Applikatioun net déiselwecht funktionnéiert wéi virum Noutfall. Ufroe ginn nach ëmmer méi lues a wesentlech méi lues veraarbecht. Een an en halleft bis zweemol méi lues speziell a mengem Beispill. D'Laascht op de Server ass och méi héich wéi virum Accident.
An d'Fro: "Wat geschitt mat der Basis am Moment?" An déi folgend Situatioun geschitt mat der Basis. Op der Transaktiounsdiagramm kënnt Dir gesinn datt et gestoppt ass an et gëtt wierklech keng laangfristeg Transaktiounen. Awer d'Gréisst vum Schëld ass während dem Accident fatal eropgaang. An zënterhier sinn se net erofgaang. Der Moyenne Zäit op der Basis huet stabiliséiert. An d'Äntwerten schéngen adäquat mat enger Geschwindegkeet ze kommen déi eis akzeptabel ass. Den Autovakuum gouf méi aktiv an huet ugefaang eppes mam Schëld ze maachen, well et muss méi Daten duerchsichen.
Speziell, no der Testplack mat Konten, wou mir Salden änneren: d'Äntwertzäit fir eng Ufro schéngt normal zréckzekommen. Awer a Wierklechkeet ass et annerhallef Mol méi héich.
A vun der Laascht op de Prozessor gesi mir datt d'Laascht op de Prozessor net zréck op den erfuerderleche Wäert virum Crash ass. An d'Grënn do leien genee an der rietser ënnen Grafik. Et kann gesi ginn datt do eng gewësse Quantitéit un Erënnerung gesicht gëtt. Dat ass, fir déi erfuerderlech Linn ze fannen, verschwende mir d'Ressourcen vum Datebankserver wärend mir nëtzlos Daten sortéieren. D'Zuel vun Transaktiounen pro Sekonn huet stabiliséiert.
Allgemeng gutt, awer d'Situatioun ass méi schlecht wéi et war. Kloer Datebank Degradatioun als Konsequenz vun eiser Applikatioun déi mat dëser Datebank funktionnéiert.
A fir ze verstoen wat do lass ass, wann Dir net am virege Bericht war, loosst eis elo eng kleng Theorie kréien. Theorie iwwer den internen Prozess. Firwat en Auto Staubsauger a wat mécht et?
Wuertwiertlech kuerz fir ze verstoen. Irgendwann hu mir en Dësch. Mir hunn Reihen an der Tabell. Dës Linnen kënnen aktiv sinn, lieweg, a wat mir elo brauchen. Si sinn gréng am Bild markéiert. An et sinn doudege Linnen, déi scho ausgeschafft goufen, aktualiséiert goufen, an nei Entréen sinn op hinnen opgetaucht. A si sinn markéiert datt se net méi interessant sinn fir d'Datebank. Awer si sinn an der Tabell wéinst enger Postgres Feature.
Firwat braucht Dir en Auto Staubsauger? Irgendwann kënnt den Autovakuum, gitt op d'Datebank zou a freet et: "Gëff mir w.e.g. d'Id vun der eelster Transaktioun déi am Moment an der Datebank op ass." D'Datebank gëtt dës ID zréck. An den Autovakuum, dorop vertrauen, sortéiert duerch d'Linnen an der Tabell. A wann hie gesäit, datt verschidde Linnen duerch vill méi al Transaktioune geännert goufen, dann huet hien d'Recht, se als Zeilen ze markéieren, déi mir an Zukunft kënne weiderbenotzen, andeems se nei Daten do schreiwen. Dëst ass en Hannergrondprozess.
Zu dëser Zäit schaffe mir weider mat der Datebank a maache weider e puer Ännerungen un den Dësch. An op dës Linnen, déi mir kënne weiderbenotzen, schreiwen mir nei Donnéeën. An domat kréie mer en Zyklus, d.h. déi ganzen Zäit kommen do e puer doud al Zeilen op, amplaz schreiwen mir nei Zeilen op, déi mir brauchen. An dëst ass en normalen Zoustand fir PostgreSQL ze schaffen.
Wat ass während dem Accident geschitt? Wéi ass dëse Prozess do geschitt?
Mir haten e Schëld an e puer Zoustand, e puer liewen, e puer dout Linnen. Den Autosvakuum ass ukomm. Hien huet d'Datebank gefrot wat eis eelst Transaktioun ass a wat seng ID ass. Ech krut dës ID, déi viru ville Stonnen, vläicht zéng Minutte viru kéint sinn. Et hänkt dovun of wéi schwéier d'Laascht Dir op Ärer Datebank hutt. An hien ass no Linnen gesicht, déi hien als erëmbenotzt markéiere konnt. An ech hunn net esou Linnen an eiser Tabell fonnt.
Awer zu dëser Zäit schaffe mir weider mam Dësch. Mir maachen eppes dran, aktualiséieren et, änneren d'Donnéeën. Wat soll d'Datebank zu dëser Zäit maachen? Si huet keng aner Wiel wéi nei Zeilen op d'Enn vun der existéierender Dësch ze addéieren. An esou fänkt eis Dëschgréisst un ze schwellen.
A Wierklechkeet brauche mir gréng Linnen fir ze schaffen. Mä während esou engem Problem, et stellt sech eraus, datt de Prozentsaz vun gréng Linnen ganze ganzen Dësch extrem niddereg ass.
A wa mir eng Ufro ausféieren, muss d'Datebank duerch all d'Linnen goen: rout a gréng, fir déi gewënscht Linn ze fannen. An den Effekt vun der Bloat vun engem Dësch mat onnëtzlechen Donnéeën gëtt "bloat" genannt, wat och eis Disk Space ësst. Erënneren, et war 2 MB, et gouf 300 MB? Elo ännert Megabytes op Gigabytes an Dir verléiert séier all Är Diskressourcen.
Wéi eng Konsequenze kënnen et fir eis sinn?
- A mengem Beispill ass den Dësch an den Index 150 Mol gewuess. E puer vun eise Clienten hu méi fatale Fäll, wa se einfach ugefaang hunn aus dem Disk Space ze lafen.
- D'Gréisst vun den Dëscher selwer wäert ni erofgoen. Autovacuum an e puer Fäll kann de Schwäif vum Dësch ofschneiden wann et nëmmen doudege Linnen sinn. Awer well et konstant Rotatioun ass, kann eng gréng Linn um Enn afréieren an net aktualiséiert ginn, während all déi aner iergendwou am Ufank vum Plack opgeschriwwe ginn. Awer dëst ass sou en onwahrscheinlech Event datt Ären Dësch selwer an der Gréisst schrumpft, also sollt Dir net hoffen.
- D'Datebank muss duerch eng ganz Rëtsch vun nëtzlosen Linnen sortéieren. A mir Offall Scheif Ressourcen, mir Offall Prozessor Ressourcen a Stroum.
- An dëst beaflosst direkt eis Applikatioun, well wa mir am Ufank 10 Millisekonnen op der Ufro verbruecht hunn, 10 Millisekonnen op eise Code, dann hu mir während dem Crash ugefaang eng Sekonn un der Ufro ze verbréngen an 10 Millisekonnen op de Code, also eng Bestellung vun Gréisst vun der Applikatioun Leeschtung ofgeholl. A wéi den Accident geléist gouf, hu mir ugefaang 20 Millisekonnen op eng Ufro ze verbréngen, 10 Millisekonnen op engem Code. Dat heescht, datt mir nach annerhallef Mol an der Produktivitéit erofgaange sinn. An dat ass alles wéinst enger Transaktioun déi gefruer ass, vläicht duerch eis Schold.
- An d'Fro: "Wéi kréie mer alles zréck?", fir datt alles gutt ass mat eis an d'Demande kommen esou séier wéi virum Accident.
Fir dësen Zweck gëtt et e gewëssen Zyklus vun der Aarbecht déi duerchgefouert gëtt.
Als éischt musse mir déi problematesch Dëscher fannen déi opgeblosen sinn. Mir verstinn, datt an e puer Dëscher den Opnahmen méi aktiv ass, an anerer manner aktiv. A fir dëst benotze mir d'Extensioun . Andeems Dir dës Extensioun installéiert, kënnt Dir Ufroen schreiwen, déi Iech hëllefen, Dëscher ze fannen déi zimlech opgeblosen sinn.
Wann Dir dës Dëscher fonnt hutt, musst Dir se kompriméieren. Et gi schonn Tools fir dëst. An eiser Firma benotze mir dräi Tools. Déi éischt ass den agebaute VACUUM FULL. Hien ass grausam, haart a barmhäerzlech, awer heiansdo ass hien ganz nëtzlech. и - Dëst sinn Drëtt Partei Utilities fir Dëscher ze kompriméieren. A si behandelen d'Datebank méi virsiichteg.
Si gi benotzt jee no wat fir Iech méi bequem ass. Mee ech wäert Iech dat um Enn soen. Den Haapt Saach ass datt et dräi Tools sinn. Et gi vill ze wielen aus.
Nodeems mir alles korrigéiert hunn a séchergestallt hunn datt alles gutt ass, musse mir wëssen, wéi mir dës Situatioun an Zukunft verhënneren:
- Et kann ganz einfach verhënnert ginn. Dir musst d'Dauer vun de Sessiounen um Master Server iwwerwaachen. Besonnesch geféierlech Sessiounen am Idle am Transaktiounsstaat. Dëst sinn déi, déi just eng Transaktioun opgemaach hunn, eppes gemaach hunn a lénks, oder einfach hänke gelooss, verluer am Code.
- A fir Iech, als Entwéckler, ass et wichteg Äre Code ze testen wann dës Situatiounen entstinn. Et ass net schwéier ze maachen. Dëst wäert eng nëtzlech Scheck sinn. Dir wäert eng grouss Zuel vu "kandleche" Problemer mat laangen Transaktiounen verbonne vermeiden.
An dëse Grafike wollt ech Iech weisen wéi d'Zeechen an d'Verhalen vun der Datebank geännert hunn nodeems ech an dësem Fall d'Schëld mat VACUUM FULL duerchgaange sinn. Dëst ass keng Produktioun fir mech.
D'Tablegréisst ass direkt zréck an säin normalen Operatiounszoustand vun e puer Megabytes. Dëst huet d'Moyenne Äntwertzäit fir de Server net vill beaflosst.
Awer speziell fir eis Testzeechen, wou mir d'Kontosalden aktualiséiert hunn, gesi mir datt d'Duerchschnëttsreaktiounszäit fir eng Ufro fir d'Daten am Schëld ze aktualiséieren op Pre-Nout-Niveau reduzéiert gouf. D'Ressourcen, déi vum Prozessor verbraucht goufen fir dës Ufro ofzeschléissen, sinn och op Pre-Crash Niveauen erofgaang. An déi riets ënnen Grafik weist, datt mir elo genee déi Linn fannen, déi mir direkt brauchen, ouni duerch d'Koppel vun doudege Linnen ze goen, déi do waren ier den Dësch kompriméiert gouf. An déi duerchschnëttlech Ufrozäit blouf ongeféier um selwechten Niveau. Awer hei hunn ech éischter e Feeler a menger Hardware.
Dëst ass wou déi éischt Geschicht endet. Et ass am meeschte verbreet. An et geschitt fir jiddereen, onofhängeg vun der Erfahrung vum Client a wéi qualifizéiert d'Programméierer sinn. Desto oder spéider geschitt dat.
Déi zweet Geschicht, an där mir d'Laascht verdeelen an d'Serverressourcen optimiséieren
- Mir sinn schonn opgewuess a ginn sérieux Kärelen. A mir verstinn datt mir eng Replica hunn an et wier gutt fir eis d'Laascht ze balanséieren: Schreift un de Master, a liest aus der Replica. An normalerweis entsteet dës Situatioun wann mir e puer Berichter oder ETL virbereeden wëllen. An d'Geschäft ass ganz frou doriwwer. Hie wëll wierklech eng Vielfalt vu Berichter mat vill komplexer Analyse.
- Berichter daueren vill Stonnen, well komplex Analyse kann net a Millisekonnen berechent ginn. Mir, wéi dapere Kärelen, schreiwen Code. An der Insertiounsapplikatioun maache mir den Opnahmen um Master, a féieren d'Rapporte iwwer d'Replika aus.
- Verdeelen d'Laascht.
- Alles funktionnéiert perfekt. Mir sinn super.
A wéi gesäit dës Situatioun aus? Speziell op dës Grafiken hunn ech och d'Dauer vun Transaktiounen aus der Replika fir d'Transaktiounsdauer bäigefüügt. All aner Grafike bezéie sech nëmmen op de Master Server.
Zu dëser Zäit war meng Berichterstattung gewuess. Et gi méi vun hinnen. Mir gesinn datt déi duerchschnëttlech Server Äntwertzäit stabil ass. Mir gesinn datt mir op der Replik eng laangjähreg Transaktioun hunn déi fir 2 Stonnen leeft. Mir gesinn déi roueg Operatioun vum Autovakuum, deen Doudelinnen veraarbecht. An alles ass gutt mat eis.
Speziell, laut der gepréifter Plack, aktualiséieren mir d'Kontosalden do weider. A mir hunn och eng stabil Äntwert Zäit fir Ufroen, stabil Ressource Konsum. Alles ass gutt mat eis.
Alles ass gutt bis de Moment wou dës Berichter ufänken zréckzekommen wéinst engem Konflikt mat Replikatioun. A si schéissen a reegelméissegen Ofstänn zréck.
Mir ginn online a fänken un ze liesen firwat dat geschitt. A mir fannen eng Léisung.
Déi éischt Léisung ass d'Replikatiounslatenz ze erhéijen. Mir wëssen datt eise Bericht iwwer 3 Stonnen leeft. Mir setzen d'Replikatiounsverzögerung op 3 Stonnen. Mir lancéiere alles, awer mir hunn nach ëmmer Problemer mat Berichter déi heiansdo annuléiert ginn.
Mir wëllen datt alles perfekt ass. Mir klammen weider. A mir hunn e coole Kader um Internet fonnt - hot_standby_feedback. Loosst eis et un. Hot_standby_feedback erlaabt eis den Autovakuum um Master ze halen. Also gi mir komplett vu Replikatiounskonflikter lass. An alles funktionnéiert gutt fir eis mat Berichter.
A wat geschitt mam Master Server zu dëser Zäit? A mir sinn am Ganzen Ierger mam Master Server. Elo gesi mir d'Grafiken wann ech béid vun dësen Astellungen aktivéiert hunn. A mir gesinn datt d'Sessioun op eiser Replica iergendwéi ugefaang huet d'Situatioun um Master Server ze beaflossen. Si huet en Effekt well se den Autovakuum gestoppt huet, wat d'Deadline läscht. Eis Dëschgréisst ass nees an d'Luucht gaangen. Déi duerchschnëttlech Ufro-Ausféierungszäit iwwer déi ganz Datebank ass och an d'Luucht gaangen. D'Autovacuums hunn e bësse méi zougemaach.
Speziell, vun eiser Plack, gesi mir datt d'Datenaktualiséierung dorop och an den Himmel sprang. CPU Konsum ass ähnlech staark eropgaang. Mir ginn erëm duerch eng grouss Zuel vun doudege, nëtzlos Linnen. An d'Äntwertzäit fir dëst Schëld an d'Zuel vun den Transaktiounen ass erofgaang.
Wéi wäert et ausgesinn wa mir net wësse vu wat ech virdru geschwat hunn?
- Mir fänken no Problemer ze sichen. Wa mir Problemer am éischten Deel begéint, mir wëssen, datt dëst wéinst enger laanger Transaktioun kann a gitt op de Master. Mir hunn e Problem mam Master. Wurscht him. Et hëtzt op, säi Laaschtduerchschnëtt ass ongeféier honnert.
- Ufroen do sinn lues, mee mir gesinn do keng laang-Lafen Transaktiounen. A mir verstinn net wat d'Saach ass. Mir verstinn net wou mir kucken.
- Mir kontrolléieren Server Equipement. Vläicht ass eis Razzia erofgefall. Vläicht ass eise Memory Stick verbrannt. Jo, alles ka geschéien. Awer nee, d'Servere sinn nei, alles funktionnéiert gutt.
- Jidderee leeft: Administrateuren, Entwéckler an den Direkter. Näischt hëlleft.
- An iergendwann fänkt alles op eemol selwer ze korrigéieren.
Zu dëser Zäit gouf d'Ufro op eiser Replik veraarbecht a verlooss. Mir kruten de Rapport. D'Geschäft ass nach ëmmer glécklech. Wéi Dir gesitt, ass eis Schëld erëm gewuess a wäert net schrumpelen. Op der Grafik mat Sessiounen hunn ech e Stéck vun dëser laanger Transaktioun vun enger Replika hannerlooss fir datt Dir kënnt schätzen wéi laang et dauert bis d'Situatioun stabiliséiert.
D'Sessioun ass eriwwer. An eréischt no enger Zäit kënnt de Server méi oder manner an der Rei. An déi duerchschnëttlech Äntwertzäit fir Ufroen um Master Server geet zréck op normal. Well endlech huet den Autovakuum d'Méiglechkeet dës Deadline ze botzen an ze markéieren. An hien huet ugefaang seng Aarbecht ze maachen. A wéi séier hien et mécht, sou séier wäerte mir an der Rei kommen.
No der getest Tablet, wou mir Kont Saldo aktualiséieren, gesinn mir genee déi selwecht Bild. Déi duerchschnëttlech Kontaktualiséierungszäit ass och graduell normaliséiert. D'Ressourcen, déi vum Prozessor verbraucht ginn, ginn och reduzéiert. An d'Zuel vun Transaktiounen pro Sekonn geet zréck op normal. Awer erëm si mir erëm normal, net datselwecht wéi virum Accident.
An all Fall, mir kréien eng Leeschtung drawdown, wéi am éischte Fall, vun annerhallef bis zwee Mol, an heiansdo méi.
Mir schéngen alles richteg gemaach ze hunn. Verdeelt d'Laascht. D'Ausrüstung ass net idle. Mir hunn d'Demande no eisem Verstand opgedeelt, awer trotzdem ass alles schlecht ausgefall.
- Hot_standby_feedback net aktivéieren? Jo, et ass net recommandéiert et ouni besonnesch staarke Grënn unzeschalten. Well dës Twist direkt de Master Server beaflosst an d'Operatioun vum Autovakuum do suspendéiert. Andeems Dir et op e puer Replika aktivéiert an doriwwer vergiess hutt, kënnt Dir de Master ëmbréngen a grouss Probleemer mat der Applikatioun kréien.
- max_standby_streaming_delay erhéijen? Jo, fir Berichter ass dëst richteg. Wann Dir en dräi Stonne Bericht hutt an Dir wëllt net datt et duerch Replikatiounskonflikter ofbriechen, da vergréissert einfach d'Verzögerung. E laangfristeg Bericht erfuerdert ni Daten déi elo an der Datebank ukomm sinn. Wann Dir et fir dräi Stonnen hutt, da leeft Dir et fir e puer al daten Period. A fir Iech, ob et eng dräi-Stonn Verspéidung oder eng sechs-Stonn Verspéidung gëtt keen Ënnerscheed maachen, mä Dir wäert Rapporte konsequent kréien a wäert keng Problemer mat hinnen falen.
- Natierlech musst Dir laang Sessiounen op Repliken kontrolléieren, besonnesch wann Dir decidéiert hot_standby_feedback op enger Replika z'aktivéieren. Well alles ka geschéien. Mir hunn dës Replica dem Entwéckler ginn, fir datt hien d'Ufroe konnt testen. Hien huet eng verréckt Ufro geschriwwen. Hien huet et lancéiert an ass fortgaang fir Téi ze drénken, a mir hunn den etabléierte Master kritt. Oder vläicht hu mir déi falsch Applikatioun do gesat. D'Situatiounen si variéiert. Sessiounen op Repliken musse sou suergfälteg iwwerwaacht ginn wéi um Master.
- A wann Dir séier a laang Ufroen op Repliken hutt, dann ass et an dësem Fall besser se ze trennen fir d'Laascht ze verdeelen. Dëst ass e Link op Streaming_delay. Fir séier, huelt eng Replikatioun mat enger klenger Replikatiounsverzögerung. Fir laang lafende Berichterstellungsufroen, hutt eng Replika déi mat 6 Stonnen oder engem Dag lags kann. Dëst ass eng ganz normal Situatioun.
Mir eliminéieren d'Konsequenzen op déiselwecht Manéier:
- Mir fannen opgeblosen Dëscher.
- A mir kompriméieren et mat dem bequemste Tool dat eis passt.
Déi zweet Geschicht endet hei. Loosst eis op déi drëtt Geschicht goen.
Och ganz heefeg fir eis an deem mir Migratioun maachen.
- All Softwareprodukt wiisst. D'Ufuerderunge fir et änneren. Mir wëllen op alle Fall entwéckelen. An et geschitt datt mir d'Donnéeën an der Tabell aktualiséieren, nämlech fir en Update ze maachen wat eis Migratioun ugeet fir déi nei Funktionalitéit déi mir als Deel vun eiser Entwécklung aféieren.
- Den alen Dateformat ass net zefriddestellend. Loosst eis elo soen, mir ginn elo op den zweeten Dësch, wou ech Transaktiounen op dëse Konten hunn. A loosst eis soen datt se an Rubelen waren, a mir hu beschloss d'Genauegkeet ze erhéijen an et an Kopecken ze maachen. A fir dëst musse mir en Update maachen: d'Feld mat der Transaktiounsbetrag vun honnert multiplizéieren.
- An der heiteger Welt benotze mir automatiséiert Datebank Versiounskontroll Tools. Loosst eis soen . Mir registréieren eis Migratioun do. Mir testen et op eiser Testbasis. Alles ass gutt. Den Update geet duerch. Et blockéiert d'Aarbecht fir eng Zäit, awer mir kréien aktualiséiert Donnéeën. A mir kënnen nei Funktionalitéit op dëser lancéieren. Alles gouf getest a gepréift. Alles gouf confirméiert.
- Mir hunn geplangten Aarbechten duerchgefouert a Migratioun duerchgefouert.
Hei ass d'Migratioun mam Update virun Iech presentéiert. Well dës sinn meng Kont Transaktiounen, der Plack war 15 GB. A well mir all Zeil aktualiséieren, hu mir d'Gréisst vum Dësch mam Update verduebelt, well mir all Zeil nei geschriwwen hunn.
Wärend der Migratioun konnte mir näischt mat dëser Plack maachen, well all Ufroen dozou goufen an der Schlaang gewaart a gewaart bis dësen Update ofgeschloss ass. Awer hei wëll ech Iech op d'Zuelen opmierksam maachen, déi op der vertikaler Achs sinn. Dat ass, mir hunn eng Moyenne Ufro Zäit virun Migratioun vun ongeféier 5 Millisekonnen an der Prozessor Belaaschtung, d'Zuel vun de Block Operatiounen fir d'Liesen vun Disk Memory ass manner wéi 7,5.
Mir hunn d'Migratioun duerchgefouert an hunn erëm Problemer.
D'Migratioun war erfollegräich, awer:
- Déi al Funktionalitéit dauert elo méi laang fir ze kompletéieren.
- Den Dësch ass nees méi grouss ginn.
- D'Laascht op de Server gouf nees méi grouss wéi virdrun.
- An natierlech, mir sinn nach ëmmer mat der Funktionalitéit déi gutt geschafft huet, mir hunn et e bësse verbessert.
An dëst ass erëm eng Bloat, déi eist Liewen erëm ruinéiert.
Hei weisen ech datt den Dësch, wéi déi zwee virdrun Fäll, net op seng fréier Gréissten zréckkënnt. Déi duerchschnëttlech Serverbelaaschtung schéngt adäquat ze sinn.
A wa mir op den Dësch mat Konte ginn, wäerte mir gesinn, datt d'Moyenne Ufro Zäit fir dësen Dësch verduebelt huet. D'Laascht op de Prozessor an d'Zuel vun de Linnen, déi an der Erënnerung zortéiert sinn, sprangen iwwer 7,5, awer war méi niddereg. An et sprang 2 Mol am Fall vu Prozessoren, 1,5 Mol am Fall vu Blockoperatiounen, dh mir hunn eng Degradatioun vun der Serverleistung kritt. An als Resultat - Degradatioun vun der Leeschtung vun eiser Applikatioun. Zur selwechter Zäit blouf d'Zuel vun den Uriff ongeféier um selwechten Niveau.
An den Haapt Saach hei ass ze verstoen wéi esou Migratiounen richteg ze maachen. A si musse gemaach ginn. Mir maachen dës Migratiounen zimlech konsequent.
- Esou grouss Migratiounen geschéien net automatesch. Si mussen ëmmer ënner Kontroll sinn.
- Iwwerwaachung vun enger erfuerderter Persoun ass erfuerderlech. Wann Dir en DBA an Ärem Team hutt, da loosst d'DBA et maachen. Et ass seng Aarbecht. Wann net, da loosst déi erfuerene Persoun et maachen, dee weess wéi mat Datenbanken ze schaffen.
- En neit Datebankschema, och wa mir eng Kolonn aktualiséieren, preparéiere mir ëmmer an Etappe, dh am Viraus ier déi nei Versioun vun der Applikatioun ausgerullt gëtt:
- Nei Felder ginn bäigefüügt an deenen mir déi aktualiséiert Donnéeën ophuelen.
- Mir transferéieren Daten aus dem ale Feld an dat neit Feld a klengen Deeler. Firwat maache mir dat? Éischtens, mir kontrolléieren ëmmer de Prozess vun dësem Prozess. Mir wëssen, datt mir scho sou vill Chargen iwwerginn hunn a mir hunn esou vill lénks.
- An den zweete positiven Effekt ass datt tëscht all esou Charge mir d'Transaktioun zoumaachen, eng nei opmaachen, an dëst erlaabt den Autovakuum no der Plack ze schaffen, d'Deadline fir d'Wiederverwendung markéieren.
- Fir d'Zeilen déi erschéngen wärend d'Applikatioun leeft (mir hunn nach ëmmer déi al Applikatioun laafen), addéiere mir en Ausléiser deen nei Wäerter an nei Felder schreift. An eisem Fall ass dëst Multiplikatioun mat honnert vum alen Wäert.
- Wa mir komplett haartnäckege sinn an déi selwecht Feld wëllen, dann op Réalisatioun vun all Migratiounen a virun Rolling vun enger neier Versioun vun der Applikatioun, mir ëmbenennen einfach d'Felder. Déi al ginn e erfonnten Numm, an déi nei Felder ginn op déi al ëmbenannt.
- An nëmmen duerno lancéiere mir eng nei Versioun vun der Applikatioun.
A gläichzäiteg wäerte mir net e Bloat kréien a wäerten net a punkto Leeschtung leiden.
Dëst ass wou déi drëtt Geschicht endet.
An elo e bësse méi Detail iwwer d'Tools déi ech an der alleréischter Geschicht ernimmt hunn.
Ier Dir no Bloat sicht, musst Dir d'Extensioun installéieren .
Fir datt Dir net mat Ufroe muss kommen, hu mir dës Ufroen schonn an eiser Aarbecht geschriwwen. Dir kënnt se benotzen. Et ginn zwou Ufroen hei.
- Deen éischten dauert zimmlech laang fir ze schaffen, awer et wäert Iech déi exakt Bloatwäerter vum Dësch weisen.
- Déi zweet funktionnéiert méi séier an ass ganz effektiv wann Dir séier muss beurteelen ob et e Bloat ass oder net no der Tabell. An Dir sollt och verstoen datt Bloat ëmmer an engem Postgres Dësch präsent ass. Dëst ass eng Feature vu sengem MVCC Modell.
- An 20% Bloat ass normal fir Dëscher an de meeschte Fäll. Dat ass, Dir sollt Iech keng Suergen maachen an dësen Dësch kompriméieren.
Mir hunn erausfonnt wéi Dëscher z'identifizéieren déi mat nëtzlosen Donnéeën geschwollen sinn.
Elo iwwer wéi een Bloat fixéiert:
- Wa mir e klengen Tablet a gutt Disken hunn, dat heescht op engem Tablet bis zu engem Gigabyte, ass et ganz méiglech VACUUM FULL ze benotzen. Hien wäert en exklusive Spär vun Iech op den Dësch fir e puer Sekonnen huelen an okay, mä hie wäert alles séier an haart maachen. Wat mécht VACUUM FULL? Et hëlt en exklusive Spär op den Dësch an rewrites liewen Zeile vun der al Dëscher an den neien Dësch. An um Enn ersetzt hien se. Et läscht al Dateien an ersetzt déi al mat neien. Mä fir d'Dauer vu senger Aarbecht, et hëlt en exklusive Spär op den Dësch. Dëst bedeit datt Dir näischt mat dëser Tabelle maache kënnt: weder schreiwen, nach liesen, nach änneren. A VACUUM FULL erfuerdert zousätzlech Disk Space fir Daten ze schreiwen.
- Nächst Tool . A sengem Prinzip ass et ganz ähnlech wéi VACUUM FULL, well et och Daten vun alen Dateien op nei nei schreift an se an der Tabell ersetzt. Awer gläichzäiteg hëlt et net en exklusive Spär um Dësch am Ufank vu senger Aarbecht, awer hëlt se nëmmen am Moment wou et scho fäerdeg Donnéeën huet fir d'Dateien z'ersetzen. Seng Diskressource Ufuerderunge sinn ähnlech wéi déi vu VACUUM FULL. Dir braucht zousätzlech Disk Space, an dëst ass heiansdo kritesch wann Dir Terabyte Dëscher hutt. An et ass zimlech Prozessor-hongereg well et aktiv mat I/O funktionnéiert.
- Déi drëtt Utility ass . Et ass méi virsiichteg mat Ressourcen well et no liicht anere Prinzipien funktionnéiert. D'Haaptidee vum pgcompacttable ass datt et all Live Reihen op den Ufank vun der Tabell beweegt mat Updates an der Tabell. An dann leeft et e Vakuum op dësem Dësch, well mir wëssen, datt mir um Ufank liewen Zeile hunn an dout Zeile um Enn. An de Vakuum selwer schneidt dëse Schwanz of, dh et brauch net vill zousätzlech Disk Space. A gläichzäiteg kann et nach ëmmer a Saache Ressourcen gepresst ginn.
Alles mat Tools.
Wann Dir d'Bloat Thema interessant fannt wat Dir méi dobanne kënnt, hei sinn e puer nëtzlech Linken:
- - Dëst ass e Bericht vu mengem Kolleg. Et ass allgemeng iwwer wou de Postgres säi Raum wärend senger Aarbecht a Liewen geet. An et gëtt eng ganz grouss an detailléiert technesch Stéck fir Datebank Administrateuren iwwer bloat.
- - Dëst ass e Link op eise Repository, wou mir eng Rëtsch nëtzlech Scripte späicheren fir den Zoustand vun der Datebank ze kontrolléieren. Do kënnt Dir Skripte fannen fir no Bloat ze sichen.
- и Linken op Tools déi Iech hëllefen Schëlder ze schrumpelen.
- - Dëst ass e Post vu mengem Kolleg. Do analyséiert hien ganz eescht an technesch bloat am Detail op engem Niveau no bei Administrateuren.
Ech hu méi probéiert eng Horrorgeschicht fir Entwéckler ze weisen, well se eis direkt Clientë vun Datenbanken sinn a musse verstoen wat a wat Aktiounen féieren. Ech hoffen ech hunn et gelongen. Merci fir är Opmierksamkeet!
Är Froen
Merci fir de Bericht! Dir hutt geschwat wéi Dir Probleemer identifizéiere kënnt. Wéi kënne si gewarnt ginn? Dat ass, ech hat eng Situatioun wou Ufroe hänken net nëmme well se op e puer extern Servicer zougräifen. Dëst waren nëmmen e puer wëll joins. Et waren e puer kleng, harmlos Ufroen, déi fir en Dag hänke bleiwen, an dunn ugefaang hunn e bëssen Nonsens ze maachen. Dat ass, ganz ähnlech zu deem wat Dir beschreift. Wéi verfollegen ech dëst? Sëtzt a stänneg kucken wéi eng Ufro festhält? Wéi kann dat verhënnert ginn?
An dësem Fall ass dëst eng Aufgab fir d'Administrateuren vun Ärer Firma, net onbedéngt fir d'DBA.
Ech sinn en Administrateur.
PostgreSQL huet eng Vue genannt pg_stat_activity déi dangling Ufroen weist. An Dir kënnt gesinn wéi laang et do hänkt.
Muss ech all 5 Minutten eran kommen a kucken?
Ariichten Cron a kontrolléieren. Wann Dir eng laangfristeg Demande hutt, schreift e Bréif an dat ass et. Dat ass, Dir musst net mat Ären Aen kucken, et kann automatiséiert ginn. Dir kritt e Bréif, Dir reagéiert drop. Oder Dir kënnt automatesch schéissen.
Ginn et evident Grënn firwat dëst geschitt?
Ech hunn e puer opgezielt. Aner méi komplex Beispiller. An et kann e Gespréich fir eng laang Zäit ginn.
Merci fir de Bericht! Ech wollt iwwer de pg_repack Utility klären. Wann hatt keen exklusive Schloss mécht, dann ...
Si mécht en exklusive Spär.
... da kéint ech potenziell Daten verléieren. Sollt meng Applikatioun näischt während dëser Zäit ophuelen?
Nee, et funktionnéiert glat mam Dësch, dh pg_repack transferéiert éischt all Live Linnen déi existéieren. Natierlech kënnt do eng Aart vun Entrée an den Dësch. Hien werft just dëse Ponytail eraus.
Dat ass, mécht hien et tatsächlech um Enn?
Um Enn hëlt hien en exklusive Spär fir dës Dateien auszetauschen.
Wäert et méi séier sinn wéi VACUUM FULL?
VAKUUM VOLLZÄIT, soubal et ugefaangen, huet direkt en exklusive Spär. A bis hien alles mécht, léisst hien hatt net lass. An pg_repack hëlt en exklusive Spär nëmmen an der Zäit vun Fichier Ersatz. Zu dësem Moment wäert Dir net do schreiwen, awer d'Donnéeë ginn net verluer, alles wäert gutt sinn.
Hallo! Dir hutt iwwer d'Operatioun vun engem Autosvakuum geschwat. Et war eng Grafik mat roude, giel a gréngen Opzeechnungszellen. Dat ass, giel - hien huet se als geläscht markéiert. An als Resultat kann eppes Neies an hinnen geschriwwe ginn?
Jo. Postgres läscht keng Linnen. Hien huet esou eng Spezifizitéit. Wa mir eng Zeil aktualiséiert hunn, hu mir déi al als geläscht markéiert. D'Id vun der Transaktioun déi dës Linn geännert huet schéngt do, a mir schreiwen eng nei Linn. A mir hunn Sessiounen déi se potenziell kënne liesen. Irgendwann ginn se zimlech al. An d'Essenz vu wéi den Autovakuum funktionnéiert ass datt et duerch dës Linnen geet an se als onnéideg markéiert. An do kanns de Daten iwwerschreiwe.
Ech verstinn. Awer dat ass net wat d'Fro ass. Ech hunn net fäerdeg. Loosst eis unhuelen datt mir en Dësch hunn. Et huet Felder vun variabelen Gréisst. A wann ech probéieren eppes Neies anzeginn, kann et einfach net an déi al Zell passen.
Nee, op alle Fall gëtt déi ganz Linn do aktualiséiert. Postgres huet zwee Datelagerungsmodeller. Et wielt aus der Datentyp. Et gëtt Daten déi direkt an der Tabell gespäichert sinn, an et gëtt och Tosdaten. Dëst si grouss Quantitéiten un Daten: Text, json. Si ginn an getrennten Placke gelagert. An no dësen Pëllen geschitt déiselwecht Geschicht mat Bloat, dh alles ass d'selwecht. Si sinn just separat opgezielt.
Merci fir de Bericht! Ass et akzeptabel Aussoen Timeout Ufroen ze benotzen fir Dauer ze limitéieren?
Ganz akzeptabel. Mir benotzen dëst iwwerall. A well mir keng eege Servicer hunn, bidden mir Fernsupport, mir hu ganz vill Clienten. An domat ass jidderee ganz zefridden. Dat ass, mir hunn Cron Aarbechtsplazen déi kontrolléieren. D'Dauer vun de Sessiounen ass einfach mam Client ausgemaach, virdru si mir net averstanen. Et kéint eng Minutt sinn, et kéint 10 Minutten sinn. Et hänkt vun der Belaaschtung op der Basis a sengem Zweck of. Awer mir benotzen all pg_stat_activity.
Merci fir de Bericht! Ech probéieren Äre Bericht op meng Uwendungen ëmzesetzen. An et schéngt wéi wann mir eng Transaktioun iwwerall ufänken, a kloer iwwerall fäerdeg maachen. Wann et eng Ausnahm ass, da geschitt d'Rollback nach ëmmer. An dunn hunn ech ugefaang ze denken. No all, kann d'Transaktioun net explizit ufänken. Dëst ass wahrscheinlech en Hiweis fir d'Meedchen. Wann ech just e Rekord aktualiséieren, fänkt d'Transaktioun an PostgreSQL un a fäerdeg nëmmen wann d'Verbindung ofgeschalt ass?
Wann Dir elo iwwer den Uwendungsniveau schwätzt, da hänkt et vum Chauffer of deen Dir benotzt, vum ORM deen benotzt gëtt. Et gi vill Astellungen do. Wann Dir automatesch engagéiert hutt aktivéiert, da fänkt eng Transaktioun do un an ass direkt zou.
Dat ass, et mécht direkt no der Aktualiséierung zou?
Et hänkt vun den Astellungen of. Ech hunn eng Astellung genannt. Dëst ass automatesch engagéiert. Et ass ganz heefeg. Wann et aktivéiert ass, ass d'Transaktioun opgemaach an zougemaach. Ausser Dir sot explizit "Start Transaktioun" an "Enn Transaktioun", awer einfach eng Ufro an d'Sessioun lancéiert.
Hallo! Merci fir de Bericht! Loosst eis virstellen datt mir eng Datebank hunn déi schwëllt a schwëllt an da leeft de Raum um Server aus. Ginn et Tools fir dës Situatioun ze fixéieren?
De Raum um Server muss richteg iwwerwaacht ginn.
Zum Beispill ass d'DBA fir Téi gaang, war an engem Resort, asw.
Wann e Dateiesystem erstallt gëtt, gëtt op d'mannst eng Aart vu Backupraum erstallt wou Daten net geschriwwe ginn.
Wat wann et komplett ënner Null ass?
Do gëtt et reservéiert Plaz genannt, dat heescht et kann befreit ginn an jee nodeem wéi grouss en erstallt gouf, kritt Dir fräi Plaz. Par défaut weess ech net wéi vill et sinn. An an engem anere Fall, liwwert Disken, sou datt Dir Plaz hutt fir eng rekonstruktiv Operatioun ze maachen. Dir kënnt e puer Dësch läschen datt Dir garantéiert net brauchen.
Ginn et aner Tools?
Et ass ëmmer handgemaach. A lokal gëtt et kloer, wat am beschten do ze maachen ass, well verschidde Donnéeën kritesch sinn an anerer net kritesch. A fir all Datebank an d'Applikatioun déi domat funktionnéiert, hänkt et vum Geschäft of. Et gëtt ëmmer lokal decidéiert.
Merci fir de Bericht! Ech hunn zwou Froen. Als éischt hutt Dir Rutschen gewisen, déi gewisen hunn datt wann Transaktioune festhalen, souwuel d'Tablespacegréisst an d'Indexgréisst wuessen. A weider um Bericht gouf et eng Rëtsch Utilities déi den Tablet packen. Wat iwwer den Index?
Si packen se och.
Mee de Vakuum beaflosst den Index net?
E puer schaffen mat engem Index. Zum Beispill, pg_rapack, pgcompacttable. De Vakuum erstellt d'Indexen nei an beaflosst se. Mat VACUUM FULL ass d'Iddi alles ze iwwerschreiwen, dat heescht et funktionnéiert mat jidderengem.
An déi zweet Fro. Ech verstinn net firwat Berichter iwwer Repliken sou vill vun der Replikatioun selwer hänken. Et huet mir geschéngt datt Berichter gelies ginn, a Replikatioun ass geschriwwen.
Wat verursaacht e Replikatiounskonflikt? Mir hunn e Master op deem Prozesser stattfannen. Mir hunn en Auto Vakuum lass. Wat mécht en Autovakuum eigentlech? Hien schneiden e puer al Linnen aus. Wa mir zu dëser Zäit eng Ufro op der Replica hunn, déi dës al Linnen liest, an um Master ass eng Situatioun geschitt datt den Autovakuum dës Linnen als méiglech markéiert huet fir ze iwwerschreiwe, dann hu mir se iwwerschriwwen. A mir hunn en Datepaket kritt, wa mir dës Linnen mussen iwwerschreiwe déi d'Ufro op der Replika brauch, wäert de Replikatiounsprozess op den Timeout waarden deen Dir konfiguréiert hutt. An da wäert PostgreSQL entscheeden wat méi wichteg ass. A Replikatioun ass méi wichteg fir him wéi d'Ufro, an hie wäert d'Ufro schéissen fir dës Ännerungen op der Replika ze maachen.
Andrey, ech hunn eng Fro. Dës wonnerbar Grafiken, déi Dir während der Presentatioun gewisen hutt, sinn dës d'Resultat vun der Aarbecht vun enger Aart vun Ärem Utility? Wéi goufen d'Grafike gemaach?
Dëst ass e Service .
Ass dëst e kommerziellen Produkt?
Jo. Dëst ass e kommerziellen Produkt.
Source: will.com