Articles

SQL: sivun elinajanodote

Posted by admin

oireet: SQL on havainnut sivun elinajanodotteen alenevan, jolloin vasteet ovat hitaampia.

Impact: Medium

hitaat SQL-vastaukset heikentävät käyttäjäkokemusta, mikä johtaa organisaation toiminnan huonoon tehokkuuteen.

odotettu käyttäytyminen:

mitä kauemmin sivu voi pysyä puskuripoolissa ja lukea muistista, sitä parempi on järjestelmän suorituskyky. Suosittelemme kynnysarvon asettamista 300 sekuntiin jokaista 4 GB: n puskuripoolin (BP) muistia kohti.

mahdolliset syyt jatkuvaan alhaiseen sivun elinikään

Alhainen SUORITINTEHOPRIORITEETTI: keskitaso
suositeltava toiminta:
jatkuva korkea käyttö yhdistettynä alhaiseen PLE: hen saattaa viitata tarpeeseen päivittää suoritinta tai lisätä useita suorittimia. Katso SELITYKSEMME suorittimen käytöstä täältä
vaihtoehtoisesti korkea suorittimen käyttöaste voi kertoa huonosti viritetystä sovelluksesta tai SQL-koodista. Sovelluksen optimointi voi alentaa suorittimen käyttöä.

riittämätön RAM-prioriteetti: Medium
Tarkista SQL: lle varatun RAM-muistin kokonaismäärä (säilyttäen silti riittävä RAM-muisti käyttöjärjestelmän tarpeisiin). Vertaa SQL-muistin suhdetta tietokannan kokoon-kokemuksemme perusteella KOKONAISMUISTIN suhde yli 20% suurimmasta tietokannasta on optimaalinen.
suositeltu toiminto:
jos mahdollista, jaa enemmän muistia SQL: lle tai lisää vuorotellen fyysistä RAM-muistia palvelimelle ja lisää SQL-muistin varausta.

page file busy/slow Priority: Low
Check what other is running that might be slowing disk access speed. Puskuripoolissa sivut vaihtuvat levylle, kun muistitilaa tarvitaan. Tämä prosessi on erittäin riippuvainen tehokkuudesta tietojen lukea/kirjoittaa toimia kiintolevylle ja kysynnän taso.
suositeltava toiminto :
nopeuttaaksesi levyn I/O: ta ja alentaaksesi latenssia, etsi sivu-tiedosto nopeimmasta käytettävissä olevasta asemasta (tai päivitä tehokkaampaan laitteistoon). Myös vähentää kilpailua tästä resurssista muista toiminnoista. AimBetter resource monitor antaa kattavat tilastot koko levytilaa, vapaata tilaa, ja sivun tiedoston toimintaa.

virheellinen Puskuripoolin Jakoprioriteetti: Matala
SQL Server-palvelimessa tiedot tallennetaan 8 KB: n sivuille. Kun tietoja tarvitaan syöttöön/lähtöön, sivu luetaan ensin levyltä ja tallennetaan muistiin. Varattua aluetta kutsutaan Puskuripooliksi. Kun sivu on ladattu altaaseen, kaikki myöhemmät käyttöoikeudet ovat erittäin nopeita ja tehokkaita, kun taas levyn I/O on suhteellisen hidas. Mahdollisimman paljon muistia tulisi varata puskuripooliin, ilman että käyttöjärjestelmä nälkiintyy.
suositeltu toiminta :
Määritä optimaalinen fyysisen muistin osuus BP: hen, mutta jätä riittävä RAM-muisti käyttöjärjestelmän operaatioille. Aseta arvo Palvelinmuistin enimmäisvaihtoehdossa’ Palvelinmuistiasetukset ’ – sivulla, joka jättää tarpeeksi muistia itse käyttöjärjestelmälle. Suosittelemme noin 4 Gt vähemmän kuin asennettu RAM-muistin kokonaismäärä

mahdolliset syyt tai ohimenevä Alhainen sivun elinajanodote (PLE)

indeksi puuttuu tai korruptoitunut prioriteetti: Korkea
puuttuvat indeksit tarkoittaa, että SQL Server viittaa siihen, että kyselysi voisi toimia nopeammin indeksillä. 99% ajasta, korruptio on levy tai levyohjain / firmware liittyvät.
suositeltava toimenpide:
puuttuvan indeksin tapauksessa palaa järjestelmäsuunnittelutiimiin.
jos indeksit ovat vioittuneet, pyydä apua varastonhallintatiimiltäsi tai tukiasiantuntijoiltamme. Yksi mahdollinen korjaus tapauksissa, joissa korruptio toistuu, on kloonata tietokanta uudelle laitteistokokoonpanolle.

Koodausongelmat prioriteetti: Alhainen
saattaa johtua esimerkiksi tehottomista kyselysuunnitelmista tai vääristä koodausstandardeista.
suositeltu toimenpide :
tarkasta SQL: n käyttämä suunnitelma, onko se optimaalinen.
tutki tietokantakyselyt nähdäksesi, ovatko vaaditut datakyselyt viallisia vai virheellisiä.
tutki koodausta, joten katso, voidaanko tehokkuutta parantaa.

kyselyt, jotka kyllästävät puskurivaraston prioriteetin: Alhainen
nämä syyt eivät säily pitkiä aikoja. Tärkeimmät syyt ovat:

  • suurten muistiapurahojen saaminen
  • suurten muistimäärien korvaaminen uusilla
  • monien sivujen muokkaaminen siten, että ne joudutaan huuhtelemaan levylle
  • monet samanaikaiset (tai hyvin suuret) kyselyt

suositeltava toiminta :
jos niitä esiintyy uudelleen tai niillä on taipumusta suuruusluokan kasvuun (alempi PLE), tutkitaan alla olevia muita mahdollisia syitä.

DBCC CHECKDB running Priority: Low
CHECKDB on hyvin resurssikeskeinen – luultavasti yksi resurssikeskeisimmistä asioista, joita SQL Server suorittaa. Tämän prosessin käyttöönotto ylimääräisenä IO-kuormana normaalin SQL Server-kuormituksen päälle tarkoittaa, että levypäät liikkuvat jatkuvasti.
suositeltu toimenpide :
suosittelemme, että suoritat kaikki olennaiset CHECKDB-prosessit minimaalisella SQL Server-kuormituksella tai vaihtoehtoisesti varmuuskopiokopioilla tietokannoista offline-tilassa.

Index Rebuilds running Priority: Low
index rebuild-operaatio rakentaa aina uuden indeksin, mikä tarkoittaa, että uuden indeksin rakentamiseen tarvitaan ylimääräistä tilaa ennen vanhan pudottamista; tarvitaan paljon CPU-ja I/O-resursseja, jotka voivat ylikuormittaa järjestelmän.
suositeltu toimenpide :
jos se esiintyy usein, se voidaan korjata indeksointimenettelyn muutoksilla, esimerkiksi siirtymällä strategiaan, jossa fragmentaatiota analysoidaan joka yö ja vain fragmentoituneita indeksejä käsitellään. Asiantuntijatukitiimimme konsultit ovat käytettävissä analysoimaan ja avustamaan.

Tausta

sivu elinajanodote mittari mittaa puskuripoolissa oleskelevien sekuntien keskiarvoa. Se liittyy läheisesti page file usage-katso täältä.
optimaalisen suorituskyvyn saavuttamiseksi tiedot pitäisi lukea muistista eikä levyltä, mikä on paljon hitaampaa. SQL saavuttaa tämän hyödyntämällä muistisivuja, jotka tallentavat viimeisintä tietoa. Näiden sivujen tallentamiseen on varattu muistialue (puskurivarasto). Kun puskuripooli on täynnä ja SQL vaatii uutta tilaa, palvelin vaihtaa vanhimman sivun levylle ja lukee uudet tiedot. Muistin ja levyn välisten vaihtojen määrän kasvu vaikuttaa suoraan suorituskykyyn.
jatkuva alhainen PLE-taso on luotettava indikaattori SQL Server-muistin paineesta. Tämä paine voi johtua suuresta kysynnästä tai tehottomasta tiedon organisoinnista, sekä fyysisestä että loogisesta
suosittelemme raja-arvon asettamista 300 sekuntiin jokaista 4 GB: n Puskuripoolista (BP) muistia kohden palvelimellasi, mikä tarkoittaa, että palvelimen tulisi säilyttää jokin sivu muistissa (kun prosessi viittaa sivuun) puskuripoolissa vähintään 5 minuuttia ennen kuin se huuhdellaan levylle. Jos puskuripooli huuhtelee sivuja alle 300 sekunnissa, on todennäköisesti ongelma.
mitä enemmän muistia palvelimellasi on, sitä enemmän välimuistissa oleva levy lukee ja kirjoittaa se voi suorittaa. Järjestelmän muistin puute voi aiheuttaa suuren välimuistin ulkopuolisen levyn lukemisen ja kirjoittamisen. Muistin lisääminen palvelimeen voi auttaa vähentämään fyysistä levynkäyttöä.

Related Post

Leave A Comment