Hirdetés
 

Top 10 ABAP dump - második rész

PDF
Nyomtatás
dump1.jpgA TOP 10 ABAP dump első részében megtudhattuk, hogy az egyes SAP verziók milyen szervereket támogatnak, valamint belemélyültünk jó pár Windows paraméter beállításba is.
Ebben a fejezetben ígéretemnek megfelelően a memóriakezelést tárgyaljuk az SAP berkeiben.
top10dump_2.jpg

A második dump volna a TSV_TNEW_PAGE_ALLOC_FAILED. A programnak több memóriára volt szüksége a rendszertől, mert egy belső táblával dolgozott, de nem volt szabad elérhető memória. Mikor az Extended Memory teljesen felhasználódik, a folyamat át fog menni PRIV módba és el fogja indítani a Heap Memory használatát a Windows esetében, vagy fordítva Unix esetében. Először belép a PRIV módba, másképp a felhasználó nem tud megfelelően dolgozni. Miután az Enough Memory végzett, utána nem fogunk hibával találkozni.

topdump1_icon1.jpg

SAP Note 649327 - Analysis of memory consumption

Gyakran előfordul az a probléma, hogy egy ABAP program váratlanul nagy memóriát használ fel. Többek között ez is okozhat futásidő hibát (runtime error).
Belső táblák gyakran használják a memóriát. Általában a dinamikusan használt 'CREATE OBJECT' és 'CREATE DATA' parancsokat használjuk. Ezek viszont tartalmazhatnak belső táblákat. Amikor már ezekre az objektumokra nincs szükség, akkor töröljük a garbage collector segítségével (garbage collector (szemétgyűjtő) megkísérli eltávolítani a memóriából azokat az objektumokat, amelyeket az alkalmazás már nem használ) és felszabadul a memória. Ez azonban csak akkor lehetséges, ha már az objektumok nincsenek használatban és egyik változó sem hivatkozik az objektumokra. Ha több objektum is hivatkozik egymásra, de már nem tudjuk elérni őket, akkor is használhatjuk a garbage collector -t. (SAP Note 628303)

topdump1_icon1.jpg

SAP Note 628303 - Heuristic for calling the garbage collector

A garbage collector a következő három küszöbérték elérésekor aktiválódik:
- a memória küszöbértéke belső állapotban használódik
- a memória küszöbértéke az objektumokat közvetlenül használja és ismeretlenek az adat objektumok
- az objektumok küszöbérték száma és ismeretlen adat objektumok generálódtak az utolsó garbage collector futás óta

a ) segítségek a memória ellenőrzéshez

Néha a memória nagy mennyiségű szelekciót használ az adatbázisból, az importáló fájl túl nagy vagy más hasonló oka van. Más esetekben viszont a debug alkalmazás is segíthet.
A következő tranzakciók használjuk a memória ellenőrzéshez:
- ST02 (tune summary - átfogó képet kapunk a memóriakezelésről)
- ST03 (workload - munkaterhelés ellenőrzése)
- SE30 (runtime analysis - futásidő hiba elemzése)
- ST22 (ABAP futásidő hiba - miért szakadt meg a program)

b ) teljes memória-felhasználás ellenőrzése a Debugger-ben

Lépjünk be az ST02-be majd klikk a System/Utilities/Debug ABAP -ra:

top10dump201.jpg

A képernyő bal alsó sarkában megkapjuk az üzenetet, hogy bekapcsoltuk a Debugging -t.

Az SM50-s tranzakcióba belépve láthatjuk, hogy éppen milyen programok futnak. Jelöljünk ki egy futó programot majd Program/session/Program/Debugging

top10dump201.jpg

SAP átdob az ABAP debugger-be, ahol lépésenként ellenőrizhetjük a programot

top10dump201.jpg

Az SM50-ben egy dupla klikk után láthatjuk a program memória kezelését:

top10dump201.jpg

c ) memory inspector

A memory inspector-t 6.20-s verzióban a 29-s Support Package-ben és ennél nagyobb csomagokban található meg. A debugger-ben tudjuk megjeleníteni a legtöbbet használt belső táblákat, stringeket, az objektumokat és a dinamikusan létrehozott adat objektumokat a menüben a 'Goto -> Display condition -> Memory usage' -nél érhetőek el. Ezen kívül, akkor is meg tudjuk jeleníteni a referencia objektum változóit vagy a stringeket, amik az objektumra hivatkoznak.
Ahhoz hogy elkerüljük a gyakori újra leosztást, egy kicsivel több memóriát kell foglalnunk, mind amennyire szükségünk van abban a pillanatban. Ezért teszünk különbséget a lefoglalt memória és a használt memória között. Egy objektum lehet nagyon kicsi, de tartalmazhat hivatkozást egy másik objektumra, anélkül hogy tartalmaz egy nagyobb belső táblát. Ezért is teszünk különbséget kötött és hivatkozott memória között. (A 7.00 verzió memóriájára hivatkozott objektumként kell tekinteni, nem pedig kötött memóriára. Így a kötött memória az a memória, ami akkor szabadul fel, mikor töröljük az objektumot.) Ezen felül létre kell hoznunk egy olyan memória snapshot-t (pillanatkép a jelenlegi állapotról), amivel el tudjuk menteni a jelenleg létező minden belső tábla, string, objektum és dinamikusan generált adat objektum információit. Az S_MEMORY_INSPECTOR tranzakció segítségével össze tudjuk hasonlítani a snapshot-al létrehozott jelenlegi memória állapotát egy későbbi időpontban lévő memória állapottal.
Bármely tranzakcióban tudunk memória snapshot-t készíteni /hmusa beírásával a parancs mezőba.
A 7.00 verzióban, a menüben a System -> Utilities -> Memory Analisys -> Create Memory Snapshot-nál tudunk készíteni memória snapshot-t.
A Debugger-ben a Development -> Memory Analysis -> Create Memory Snapshot-nál tudunk memória snapshot-t készíteni.
A 7.00 verzióban a menüben System -> Utilities -> Memory Analysis -> Compare Memory Snapshots-nál tudunk memória összehasonlításos snapshot-t készíteni.

d ) legnagyobb belső táblák ellenőrzése

A 4.6-s és a 6.10-s verzióban a legnagyobb belső táblák a debugger-ben a parancs mezőbe dis -t írva jelennek meg, és utána keressük a csúszkával az ITAB-TOP25 területet. Ez vonatkozik a 6.20-ra is, de a rendszer nem tartalmaz memory inspector-t.

e ) objektumok statisztikái

A 4.6-s verzióban úgy tudjuk megjeleníteni a Debugger-ben lévő objektumok számait, hogy a parancs mezőbe beírjuk azt, hogy dis majd Enter és a csúszkával keressük meg az OBJMGR területet. Következő értékek olvashatók ki:
- utoljára milyen objektumok léteztek az utolsó garbage collector futása óta
- milyen objektumok generálódtak az utolsó garbage collector futása óta
- milyen objektumok foglalódtak le az utolsó garbage collector futása óta

A dinamikusan generált adat objektumokat nem tartalmazzák. A 6.20-s verzió kernel patch 907 szintje tartalmazza ezeket. A következő értékeket hívja meg:
- milyen objektumok és adat objektumok vannak az utolsó garbage collector futása óta
- milyen objektumok és adat objektumok generálódtak az utolsó garbage collector futása óta
- foglalások száma az utolsó garbage collector futása óta
A Debugger-ben az objektumokat a menüben a 'Goto -> System -> Find reference' -nál tudjuk lekérdezni.

f ) a garbage collector meghívása

A 4.6-s verzióban a garbage collector-t a Debugger-ből a Goto -> System -> Garbage collector -> Execute lépésekkel tudjuk elindítani teszt célokra.
Alkalmanként kifejezetten érdemes a garbage collector-t használni ABAP programokban. (SAP Note 580871)

topdump1_icon1.jpg

SAP Note 580871 Calling the Garbage Collector explicitly


A garbage collector-t kifejezetten a DO_GARBAGE_COLLECTION metóddal hívható meg a CL_ABAP_MEMORY_UTILITIES osztályból:
CL_ABAP_MEMORY_UTILITIES=>DO_GARBAGE_COLLECTION( ).

Ha a CL_ABAP_MEMORY_UTILITIES nem elérhető, akkor a következő megoldást használjuk:
SYSTEM CALL OBJMGR PERFORM GARBAGE COLLECTION.

topdump1_icon1.jpg

SAP Note 20527 - Runtime error TSV_TNEW_PAGE_ALLOC_FAILED

További memória szükséges a belső tábla kiterjesztéséhez. Általában a rendszer már kért további több mint 100 MB memóriát.
A runtime error elolvasásakor megtudjuk, hogy mennyi a jelenleg használt memória. Konfigurációs problémák esetében olvassuk el az online dokumentációt a memóriakezeléshez. A roll terület rendszer erőforrásainak a hiánya miatt jelentkezik ez a hiba. A roll terület a hagyományos roll területből áll, Extended Memory területből és Heap Memory területből. Amikor a feldolgozási táblák a dialógusban vannak, a rendszer fokozatosan kér memóriát ezekre a területekre. Runtime error lép fel, ha a Heap Memory kimerült, vagy az egyik paraméter érték abap/heap_area_total vagy abap/heap_area_dia felélte. A háttérben futó job esetében hiba lép fel, akkor meg kell növelni a swap területet, ezáltal lemegy az egy paraméter értéke. (A merevlemez azon részét, amelyet a virtuális memória használja swap területnek nevezzük.) Az operációs rendszer szinten tudja a rendszergazda konfigurálni a swap területet.

topdump1_icon1.jpg

SAP Note 369726 - TSV_TNEW_PAGE_ALLOC_FAILED

Az alkalmazás program próbált terjeszkedni egy belső táblában, de a memóriaigénye túl nagy volt.
Lehetséges okok:
- R/3 tároló paraméterei hibásan vannak beállítva
- túl kevés a fizikai memória vagy helytelenek az operációs rendszer beállításai
- program hiba (memory leak)
- helytelenül használtuk a memóriát (túl sok adatot szelektáltunk)

Ilyen esetekben az ST02 tranzakcióban ellenőrizzük a SAP memóriát, buffer méreteket és aktuális paramétereket.

top10dump_3.jpgA harmadik dump a TSV_TNEW_OCCURS_NO_ROLL_MEMORY . Ezzel a hibával ezt szeretné az SAP üzenni, hogy a roll buffer kiürült. A saját buffer használatunkat az ST02-ben ellenőrizhetjük. A rdisp/ROLL_MAXFS paraméterrel tudjuk növelni a buffer méretét. De előtte győződjünk meg arról, hogy van-e elegendő szabad hely a merevlemezen a további buffer növeléshez, ha a roll írni akarja a merevlemezt.

 

topdump1_icon1.jpg

SAP Note 185185 - Application: Analysis of memory bottlenecks

Mit tegyünk olyankor, ha ellenőrizni akarjuk a memória felhasználást, de a Memory Inspector nem áll rendelkezésre a rendszerben (ez leginkább a 6.20-nál alacsonyabb verziókat érinti):

a) ellenőrizzük a memória paramétereket

b ) elemezzük az alkalmazás forráskódját

Bár a memória beállítások helyesek, de a hiba továbbra is fenn áll. Az alkalmazás fejlesztőnek kell megállapítania, hogy az alkalmazás hol foglalódott le a memóriában. Amikor ez már megállapításra került, akkor vagy korlátozzuk a kiválasztásokat vagy megváltoztatjuk a programot vagy csökkenteni kell a használt memória mennyiséget.

topdump1_icon3.jpg

Hogy lehet megtalálni a memória zabálót?


a ) használjuk az applikációs ismereteket a debugging-ban

Általában az applikációk ismerik a potenciális memória zabálókat, pl. nagy belső táblák, extract-k. Hibakereséskor korlátozni tudjuk a hibákat a táblákban.

b ) dump analízis ST22-ben

Belső táblák területére a belépés általában nem szokott segíteni, mert a rendszer törölte a nagyobb belső táblákat mielőtt a dump utasítás ellátta volna a memóriát az aktuális dump kimenettel. Azonban a rendszermezők közleményei nagyon hasznosak lehetnek. Ha a memória hibák nagy listával jelennek meg, akkor fontosak lehetnek a következő paraméterek:
- sy-pagno (oldalak száma)
- sy-colno (oszlopok száma)
- sy-linno (sorok száma)

c ) SE30 - hierarchia

- lépjünk be az SE30 tranzakcióba
- adjuk meg a programot vagy a tranzakciót
- válasszuk az Execute
- hajtsuk végre a tranzakciót
- a dump megjenés után Enter /nse30
- válasszuk az Analyze
- majd a subsequent screen-nél válasszuk a call hierarchy
- a hierarchiában megjeleníti a rendszer az aktuális memória felhasználást a jobb szélen
- ezzel meg tudjuk állapítani, hogy mely parancsok okoznak nagy memória felhasználást

d ) befejezés háttérben

- lépjünk be az ST02 tranzakcióba
- válasszuk a Detail Analysis Menu gombot
- majd SAP memory
- majd Mode list
- itt láthatjuk a felhasználók munkafolyamatait és memória szükségleteit

Ebben a két dump-ban képet kaptunk arról, hogy az SAP esetében is milyen fontos a memória megfelelő használata. Próbáltam minél részletesebben megfogalmazni az ellenőrzési lehetőségeket és a problémák megoldásait. Remélem ezek után sem adtátok fel az ABAP programozói álmokat és találkozni fogunk a következő fejezetben is, ami már utolsó lesz. A finisben ABAP program hibákkal és SAP RFC-hez kapcsolódó kérdésekkel fogunk foglalkozni.


A szerző a veszprémi Mérnök Informatika szakon végezett, majd egy multinál az SAP-val dolgozott key user-ként az MM,SD és XI modulokban, ahol a fő feladata a folyamatok felállítása és meglévők optimalizálása volt. 2010-től egy középvállalatnál dolgozik ugyancsak key user-ként a AM, MM, PM, PP, SD, WM területeken. Jelenleg egy SAP ugrade előkészítésén dolgozik.

További cikkek a szerzőtől


Nincs hozzászólása.
A téma megvitatása a fórumon. (0 hozzászólás)