Hvordan drepe tomgangstilkoblinger i PostgreSql

Det første trinnet i å gjøre endringer eller lese litt informasjon fra en PostgreSQL -databank er å etablere tilkoblinger. På den annen side genererte hver kobling overhead å bruke prosedyre og lagring. Det er grunnen til at en enhet med minimale ressurser (les, lagring, maskinvare) kan støtte det begrensede aggregatet av tilkoblinger. Når det begrensede aggregatet har gått langt utover et punkt, bør det fortsette å kaste feil eller nekte tilkoblinger. Innen PostgreSql.Conf, PostgreSql gjør en anstendig jobb med å begrense lenker. I denne opplæringen skal vi se på de forskjellige former for stater som PostgreSQL -lenker kan ha. Vi viser deg hvordan du kan avgjøre om lenken er aktiv eller har vært inaktiv i lang varighet, der tilfelle den kan kobles fra for å frigjøre koblinger og ressurser.

Koble til serveren:

I starten, må du sørge for at du har blitt installert PGADMIN4. Åpne den fra applikasjonene dine. Du må koble det til Localhost ved å oppgi et passord.

Etter tilkoblingen med root localhost, kobler du den til PostgreSQL -serveren. Skriv inn passordet for PostgreSQL 13 -brukeren Postgres for å koble til. Trykk på OK -knappen for å fortsette.

Nå har du blitt koblet til PostgreSQL 13 -serveren. Du kan se en liste over databaser som er bosatt på serveren som presentert på bildet vedlagt nedenfor. Postgres database er standarddatabasen 'opprettet på tidspunktet for PostgreSQL -installasjonen, mens' Test '-databasen er opprettet av en bruker etterpå installasjonen.

Tilkoblingsstater:

Hvis en PostgreSQL -kobling er etablert, kan den utføre forskjellige handlinger som resulterer i statlige overganger. En rasjonell beslutning bør tas om hvorvidt lenken fungerer eller den har blitt liggende på tomgang/ubrukt avhengig av staten og varigheten den har vært i hver stat. Det er viktig å merke seg at inntil applikasjonen bevisst lukker forbindelsen, vil den fortsette å operere og kaste bort ressurser lenge etter at klienten er løsrevet. Det er de fire potensielle tilstandene for en forbindelse:

• Aktiv: Dette betyr at lenken er i gang.
• Tomgang: Dette betyr at lenken er inaktiv, så vi må føre en oversikt over dem avhengig av hvor lenge de har vært ledige.
• Tomgang (i transaksjon): Dette betyr at backend er engasjert i en spørring, selv om den faktisk er inaktiv og kanskje forventer innspill fra sluttklienten.
• Tomgang i transaksjon (abortert): Denne tilstanden tilsvarer tomgang i prosessen. Imidlertid kulminerte en av erklæringene i en feil. Det kan spores avhengig av hvor lenge det har vært inaktiv.

Identifiser tilkoblingstilstandene:

PostgreSql-katalogtabellene gir en innebygd visning 'PG_STAT_ACTIVITY' for å sjekke statistikk om hva en lenke gjør eller hvor mye tid det har vært i denne tilstanden. For å sjekke all statistikk angående hver database og hver tilkoblingsstatus, åpner du spørringsverktøyet og utfører spørringen nedenfor:

>> Velg * fra PG_STAT_ACTIVITY;

Spørringen er implementert fruktbart, og prestasjonsnotatet er vist.

Når du sjekker datautgangssiden, finner du en tabell med flere kolonner, som vist nedenfor. Du kan sjekke forbindelsene for tilkoblinger ved å sjekke verdiene til feltet 'tilstand'.

For å forenkle utdataene og ha en klar ide om tilkoblinger, deres stater, brukere og servere i disse tilstandene, må du utføre den nedenfor-modifiserte spørringen i spørringsverktøyet. Denne spørringen viser bare de 5 feltet med poster for tilkoblinger og spesielle data angående dem. Kolonnen 'PID' står for prosess -ID. Kolonnen 'State' holder prosessene for prosesser. Kolonnen 'brukernavn' identifiserer brukeren som har jobbet med den aktuelle prosessen. Kolonnen 'Datname' spesifiserte databasenavnet som transaksjonen har utført. Kolonnen 'DatID' står for database -ID.

>> Velg PID, tilstand, brukernavn DATNAME, DATID, fra PG_STAT_ACTIVITY;

Utgangen har totalt 8 prosesser registrert. Kolonnen 'State' viser at det bare er tre prosesser som fungerer akkurat nå. Den ene holdes som standard database 'Postgres og de to andre holdes av databasen' Test '. Samtidig har 'Postgres -brukeren utført disse prosessene.

Identifiser tomgangstilkoblingene:

"Staten" ser ut til å være den eneste verdien vi søker etter innen resultatene nevnt ovenfor. Vi vil bruke denne informasjonen til å bestemme hvilke prosesser eller spørsmål som er i hvilke stater og etterpå graver dypere. Vi kan slanke detaljene vi søker etter ved å foredle spørringen, slik at vi kan utarbeide et inngrep på den spesifikke forbindelsen. Vi kunne gjøre dette ved å velge bare de ledige pidene ved å bruke hvor leddet og statene for disse pidene. Vi bør også følge med på hvor lenge lenken har vært inaktiv og sikre at vi ikke har noen forsømte koblinger som ødelegger ressursene våre. Som et resultat vil vi bruke kommandoen nedenfor for å bare vise poster som er relevante for prosessene som for øyeblikket er ledige:

>> Velg PID, brukernavn, useSysid, DATID, DATName, Application_name, backend_start, state_change, state from pg_stat_activity hvor state = 'Idle';

Spørringen har hentet bare 2 poster over data der staten var 'tomgang' ved å bruke WHERE -leddet. Resultatet viser de to tomgangsprosessene med viss informasjon angående dem.

Drep en ledig forbindelse:

Etter identifisering av ledige tilkoblinger, nå en tid til å drepe dem. Når vi har pisket ned prosessen enten i holdetilstand eller inaktiv i mye lenger, kan vi bruke den enkle kommandoen for å enkelt avslutte back-end-mekanismen uten å forstyrre serverens aktiviteter. Vi må gi prosessen 'ID' i spørringen i en avslutningsfunksjon.

>> Velg PG_TERMINATE_BACKEND (7408);

Prosessen er praktfullt drept.

Sjekk nå de gjenværende ledige tilkoblingene fra den nedenfor-anvendte spørringen.

>> Velg DatID, Usenavn, Datname, PID, tilstand fra PG_STAT_ACTIVITY hvor staten = 'Idle';

Utgangen viser bare 1 gjenværende prosess, som er inaktiv.

Konklusjon:

Sørg for ikke å gå glipp av noe trinn for å drepe de inaktive tilkoblingene fra PostgreSQL -databasen effektivt.