Articles

SQL: oldal várható élettartama

Posted by admin

tünetek: az SQL az oldal várható élettartamának csökkenését észlelte, lassabb válaszokat produkálva.

hatás: közepes

a lassú SQL-válaszok rontják a felhasználói élményt, ami a szervezet működésének gyenge hatékonyságát eredményezi.

várható viselkedés:

minél hosszabb ideig marad egy oldal a pufferkészletben, és a memóriából olvasható, annál jobb a rendszer teljesítménye. Javasoljuk, hogy a küszöbértéket 300 másodpercben állítsa be minden 4 GB pufferkészlet (BP) memóriához.

a tartósan alacsony oldal várható élettartama (PLE) lehetséges okai

alacsony CPU teljesítmény prioritás: közepes
ajánlott művelet :
az alacsony PLE-vel járó folyamatos magas használat jelezheti a CPU frissítésének vagy több processzor hozzáadásának szükségességét. Lásd a CPU-használat magyarázatát itt
Alternatív megoldásként a magas CPU-használati arány rosszul hangolt alkalmazást vagy SQL-kódot jelezhet. Az alkalmazás optimalizálása csökkentheti a CPU kihasználtságát.

nem megfelelő RAM prioritás: Közepes
tekintse át az SQL-hez rendelt teljes RAM mennyiségét (miközben továbbra is elegendő RAM-ot tart fenn az operációs rendszer igényeihez). Hasonlítsa össze az SQL memória arányát az adatbázis méretével-tapasztalataink alapján a legnagyobb adatbázis 20% – ánál nagyobb teljes RAM aránya optimális.
Javasolt művelet:
ha lehetséges, rendeljen több memóriát az SQL-hez, vagy felváltva adjon hozzá fizikai RAM-ot a kiszolgálóhoz, és növelje az SQL memóriafoglalást.

oldalfájl foglalt/lassú prioritás: alacsony
ellenőrizze, hogy mi fut még, ami lassíthatja a lemezelérési sebességet. A pufferkészlet az oldalakat lemezre cseréli, ha memóriaterületre van szükség. Ez a folyamat nagymértékben függ az adatok olvasási/írási műveleteinek hatékonyságától a merevlemezen és a kereslet szintjétől.
ajánlott művelet:
a lemez I/O sebességének és a késleltetés csökkentésének érdekében keresse meg az oldalfájlt a leggyorsabb elérhető meghajtón (vagy frissítsen hatékonyabb hardverre). Ezenkívül csökkentse az erőforrásért folytatott versenyt más műveletekből. Az AimBetter resource monitor átfogó statisztikákat nyújt a teljes lemezterületről, szabad területről és oldalfájl-tevékenységről.

helytelen pufferkészlet-kiosztási prioritás: Low
az SQL Server-ben az adatok 8 KB-os oldalakon vannak tárolva. Ha adatra van szükség a bemenethez/kimenethez, az oldalt először a lemezről olvassa le, majd tárolja a memóriában. A kiosztott területet Pufferkészletnek nevezzük. Amint egy oldal betöltődik a készletbe, minden további hozzáférés nagyon gyors és hatékony, míg a lemez I/O viszonylag lassú. A lehető legtöbb memóriát el kell osztani a pufferkészlethez, anélkül, hogy éheztetné az operációs rendszert.
ajánlott művelet:
Rendelje meg a fizikai RAM optimális arányát a BP-hez, de hagyjon elegendő RAM-ot az operációs rendszer műveleteihez. Állítson be egy értéket a ‘Kiszolgálómemória-Beállítások’ oldal maximális kiszolgálómemória opciójában, amely elegendő memóriát hagy magának az operációs rendszernek. Javasoljuk, hogy körülbelül 4 GB kevesebb, mint a telepített RAM teljes mennyisége

lehetséges okok vagy átmeneti alacsony oldal élettartam (PLE)

index hiányzó vagy sérült prioritás: a magas
hiányzó indexek azt jelentik, hogy az SQL Server azt sugallja, hogy a lekérdezés gyorsabban futhat egy index segítségével. Az esetek 99% – ában a korrupció lemez vagy lemezillesztő/firmware-rel kapcsolatos.
ajánlott művelet:
hiányzó index esetén forduljon vissza a rendszertervező csapathoz.
sérült indexek esetén kérjen segítséget a tárhelykezelő csapattól vagy támogatási szakértőinktől. Az egyik lehetséges megoldás azokban az esetekben, amikor a korrupció megismétlődik, az adatbázis klónozása egy új hardverkonfigurációra.

kódolási problémák prioritás: alacsony
talán olyan problémák eredménye, mint a nem hatékony lekérdezési tervek vagy a nem megfelelő kódolási szabványok.
ajánlott művelet:
ellenőrizze az SQL által használt tervet, hogy meghatározza, hogy optimális-e.
vizsgálja meg az adatbázis-lekérdezéseket, hogy a szükséges adat lekérdezések sérültek-e vagy helytelenek.
vizsgálja meg a kódolást, tehát nézze meg, hogy javítható-e a hatékonyság.

a pufferkészlet prioritását telítő lekérdezések: alacsony
ezek az okok nem maradnak fenn hosszú ideig. A fő okok a következők:

  • nagy memória támogatások megszerzése
  • nagyszámú oldal kiszorítása a memóriában újakkal
  • sok oldal módosítása, kényszerítve őket a lemezre való öblítésre
  • sok egyidejű (vagy nagyon nagy) lekérdezés

ajánlott művelet :
azokban az esetekben, amikor újra előfordulnak, vagy a nagyságrend növekedésére hajlamosak (alacsonyabb PLE), vizsgálja meg az alábbiakban a többi lehetséges okot.

DBCC CHECKDB running Priority: Low
a CHECKDB nagyon erőforrás – igényes-valószínűleg az egyik leginkább erőforrás-igényes dolog, amit az SQL Server végez. Ennek a folyamatnak a bevezetése további IO-terhelésként a normál SQL Server-terhelés mellett azt jelenti, hogy a lemezfejek folyamatosan mozognak.
ajánlott művelet :
javasoljuk, hogy futtassa az alapvető CHECKDB folyamatokat minimális SQL Server terhelés mellett, vagy alternatív módon az adatbázisok biztonsági másolatain offline állapotban.

az Index újraépíti a futási prioritást: Low
az index-újraépítési művelet mindig új indexet épít, ami azt jelenti, hogy extra helyre van szükség az új index felépítéséhez, mielőtt eldobná a régit; sok CPU és I/O erőforrás szükséges, ami túlterhelheti a rendszert.
ajánlott művelet :
ha gyakran fordul elő, akkor az indexelési eljárás megváltoztatásával korrigálható, például egy olyan stratégiára való áttéréssel, amelyben a fragmentációt minden este elemzik, és csak a fragmentált indexeket dolgozzák fel. Szakértői támogató csapatunk tanácsadói rendelkezésre állnak az elemzéshez és a segítségnyújtáshoz.

háttér

az oldal várható élettartama mutató azt méri, hogy az oldalak átlagosan hány másodpercig tartózkodnak a pufferkészletben. Szorosan kapcsolódik az oldalfájl használatához – lásd itt.
az optimális teljesítmény érdekében az adatokat a memóriából kell olvasni, nem pedig a lemezről, ami sokkal lassabb. Az SQL ezt úgy éri el, hogy a legutóbb elért adatokat tároló memóriaoldalakat használja. Ezen oldalak tárolásához rendelkezésre áll egy fenntartott memóriaterület (a pufferkészlet). Ha a pufferkészlet megtelt, és az SQL új helyet igényel, a kiszolgáló kicseréli a legrégebbi oldalt a lemezen lévő oldalfájlra, és beolvassa az új adatokat. A memória és a lemez közötti cserék számának növekedése közvetlenül befolyásolja a teljesítményt.
a PLE tartósan alacsony szintje az SQL Server memória nyomásának megbízható mutatója. Ez a nyomás lehet A nagy igény vagy a nem hatékony adatszervezés eredménye, mind fizikai, mind logikai
javasoljuk, hogy a küszöbértéket 300 másodpercben állítsa be a kiszolgáló minden 4 GB-os pufferkészlet (BP) memóriájára, ami azt jelenti, hogy a kiszolgálónak legalább 5 percig meg kell őriznie az adott oldalt a memóriában (miután egy folyamat hivatkozik az oldalra) a pufferkészletben, mielőtt a lemezre öblítené. Ha a pufferkészlet kevesebb, mint 300 másodperc alatt öblíti az oldalakat, akkor valószínűleg probléma van.
minél több memóriával rendelkezik a szerver, annál több gyorsítótárazott lemez olvasható és írható. A rendszermemória hiánya magas, nem gyorsítótárazott lemezolvasást és-írást okozhat. Memória hozzáadása a kiszolgálóhoz csökkentheti a fizikai lemezelérést.

Related Post

Leave A Comment