Memória hibakeresés Linuxban: kulcsfontosságú eszközök és technikák

Informatec Digital » Erőforrás » Memória hibakeresés Linuxban: kulcsfontosságú eszközök és technikák

Amikor valami rosszul megy egy Linux szerveren, az ok gyakran a memóriahasználatban és a hibakereső eszközökben rejlik , de amíg nem tudjuk, mit kell keresni, minden a számok és folyamatok kaotikus zűrzavarának tűnik. A RAM-ban történő események, a programok viselkedésének és a memóriaképek rögzítésének megértése kulcsfontosságú ahhoz, hogy elkerüljük a vakon történő hibakeresést minden egyes furcsa hiba vagy szegmentálási hiba esetén.

Ebben a cikkben részletesen és közérthetően áttekintjük, hogyan vizsgálhatjuk meg a memóriát, hibakereshetjük a programokat és elemezhetjük a memóriaképeket Linuxban rendszerparancsok (free, vmstat, /proc/meminfo), hibakeresők, mint például a GDB, memóriaelemzők, mint például a Valgrind, valamint .NET-re és más környezetekre jellemző segédprogramok segítségével. A cél az, hogy egy praktikus eszköztárral távozz, amellyel diagnosztizálhatod a memória- és CPU-problémákat szervereken és professzionális fejlesztői környezetekben.

Áttekintés: Memória Linuxban és miért nem szabad a 100%-nál jobban kihasználni

Egy Linux szerveren a RAM gyors tárolóként szolgál az adatok és a kód számára, amelyeket a rendszernek hamarosan újra kell használnia. A RAM elérése sokkal gyorsabb, mint a lemez elérése, így a kernel ezt kihasználva gyorsítótárként használja a fájlok, pufferek és memórialapok számára, amelyekre hamarosan újra szükség lehet.

Egy Apache vagy Nginx rendszert futtató webszerver , illetve egy MySQL vagy MariaDB adatbázisszerver esetében elengedhetetlen a foglalt, a szabad és a gyorsítótárban tárolt memória mennyisége a szolgáltatások megfelelő méretezéséhez, valamint a névterek és a cgroupok megértéséhez . Valójában az olyan optimalizáló eszközök, mint a MySQLTuner , ezeket az adatokat (és más információkat) használják fel a puffer-, a gyorsítótár- és a kapcsolatbeállítások javaslatára.

Fontos megérteni egy olyan koncepciót, ami elsőre gyakran meglepheti az embereket: a RAM-ot használatra tervezték . A 90%-os vagy akár a 100%-os kihasználtság sem feltétlenül jelent problémát; a Linux a RAM-ot lemezgyorsítótárral tölti fel a rendszer felgyorsítása érdekében. Ami igazán aggasztó, az az, amikor memóriahiányos hibákat kapunk , a folyamatok OOM (Out Of Memory) üzenettel összeomlanak, vagy a szolgáltatások lefagynak, nem csak akkor, amikor a grafikon "magas kihasználtságot" mutat.

Csak akkor van értelme az agresszív optimalizáláshoz folyamodni, ha azt tapasztaljuk, hogy a szerver instabillá, lassúvá válik, vagy a túlzott memóriahasználat miatt leállítja a szolgáltatásokat, vagy ha tudjuk, hogy a forgalom olyan megugrása várható, amely túlterhelheti a jelenlegi erőforrásokat.

Alapvető parancsok a memória vizsgálatához Linuxon

A memóriaproblémák elhárításának első lépése a teljes RAM mennyiségének megértése , valamint annak a felhasznált memória, a szabad memória, a gyorsítótár és a swap memória közötti megoszlása . A Linux számos segédprogramot kínál ehhez, mindegyik más részletességi szinttel.

szabad parancs: RAM és swap gyors áttekintése

A leggyakrabban használt parancs a gyors áttekintéshez a következő: ingyenes, különösen a paraméterrel -h Méretek olvasható formátumban történő megjelenítéséhez: További információkért ezen mérőszámok értelmezéséről és optimalizálásáról, lásd: optimalizálja a memória statisztikáit.

free -h

A tipikus kimenet néhány sorban mutatja a teljes, használt, szabad, megosztott, puffer és gyorsítótár memória méretét mind a RAM, mind a swap területre vonatkozóan. Valami ilyesmit fogsz látni:

Összes felhasznált szabad megosztott puffer gyorsítótárazott Mem: 2.0G 1.5G 470M 300M 0B 414M -/+ pufferek/gyorsítótár: 1.1G 885M Swap: 0B 0B 0B

vonal -/+ buffers/cache Különösen hasznos, mert megmutatja a folyamatok által ténylegesen használt memóriát (a pufferek/gyorsítótár nélkül), valamint az új alkalmazások számára potenciálisan rendelkezésre álló memóriát. Sokan kevés "szabad memóriát" látnak az első sorban, és megijednek, miközben a valóságban annak nagy része csak gyorsítótárban van, és... dráma nélkül újrahasznosítható.

vmstat: aktív, tétlen memória és rendszermetrikák

Ha valami részletesebbre van szükséged, a vmstat technikaibb képet ad a rendszerről. A következővel:

vmstat -s -S M

Kapsz egy listát a teljes memória, a felhasznált memória, a szabad memória, az aktív memória, az inaktív memória, a pufferek, a swap memória stb. méretéről. Például:

2048 MB teljes memória 1582 MB használt memória 1124 MB aktív memória 406 MB inaktív memória 465 MB szabad memória 0 MB puffermemória 407 MB swap gyorsítótár 0 MB teljes swap 0 MB használt swap 0 MB szabad swap

Az üresjárati memória fogalma érdekes: ez egy használatban lévő memória, amely nem kapcsolódik aktív folyamatokhoz, így gyakorlati okokból úgy viselkedik, mint egy olyan memória, amelyet a rendszer helyreállíthat . Ez segít megmagyarázni, hogy miért tűnhet úgy, hogy a Linux "felhasználja az összes helyet", holott a valóságban van hely, amit szükség esetén felszabadíthat.

/proc/meminfo: a nyers kernel részletei

Ha a kernel által kezelt összes részletre kíváncsi, mindig megnézheti a /proc/meminfo fájlt :

cat /proc/meminfo

Ez a fájl több tucat, a belső memória-kezeléssel kapcsolatos mezőt tartalmaz : teljes memória, szabad memória, pufferek, gyorsítótár, slab, hugepages, elérhető memória stb. Nagyon hasznos automatizált eszközökhöz és monitorozó szkriptekhez, bár a közvetlen olvasása némileg kevésbé felhasználóbarát, mint a `free` vagy a `vmstat`, és alapos ismeretet igényel az egyes mezők jelentéséről.

Vezérlőpanelek és azok „párhuzamos valósága”

Ha olyan szervert kezelsz, amely olyan vezérlőpultokkal rendelkezik, mint a cPanel, Plesk, VestaCP vagy Webmin , látni fogod, hogy ezek jellemzően egy webes felületen keresztül jelenítik meg a használt, szabad és gyorsítótárazott memória grafikonjait. Ez az adat kényelmes, de ne feledd, hogy rendszeresen frissül , és néha nem tükrözi a pontos valós idejű állapotot. Az alapos diagnosztikához és finomhangoláshoz mindig a legjobb a terminált és annak natív parancsait használni.

Folyamatok és memória hibakeresése rendszereszközökkel

Miután megismerte a rendelkezésre álló memória mennyiségét és általános felhasználását, a következő lépés annak meghatározása, hogy mely folyamatok fogyasztják rendellenesen az erőforrásokat, és elemezni kell a viselkedésüket. Itt jönnek képbe a klasszikus segédprogramok, mint a ps, top, htop, strace és ltrace, valamint a hálózati és lemezparancsok, amelyek segítenek a szűk keresztmetszetek kiküszöbölésében.

ps, top és htop: a folyamatok és a CPU röntgenfelvétele

A `ps` parancs megjeleníti az aktív folyamatokat. Szűrőkkel és rendezéssel kombinálva lehetővé teszi a CPU-t használó folyamatok gyors megtalálását.

ps aux --sort=-%cpu | head

Ez a CPU-használat százalékos aránya , a memóriahasználat, a felhasználó és a parancs szerint rendezett folyamatokat jeleníti meg . Ideális pillanatképként a fő gyanúsított azonosításához, amikor a szerver erőforrásai fogynak; a terminál használatának elsajátítása segít gyorsan cselekedni.

Másrészről a `top` és annak vizuálisabb változata , a `htop` valós idejű képet ad a folyamatokról, a CPU-használatról, a memóriahasználatról, az állapotról (R, S, D, stb.) és az átlagos terhelésről . A `top`-ot a következővel kezdjük:

top -o %CPU

Arra koncentrálhatsz, hogy mely folyamatok használják a legtöbb CPU-t. A számokon túl fontos a mintázatokat is keresni :

• R (futó) állapotban lévő folyamatok amelyek sokáig a csúcson ragadnak.
• Hirtelen változások a terhelés átlagában amelyek a közelmúltbeli terheléscsúcsokat jelzik.
• CPU-kiosztás %us, %sy és %wa (felhasználói idő, rendszeridő és I/O várakozás).
• Ha a problémás folyamat egy rendszerszolgáltatás, egy adott felhasználó vagy egy démon.
• Ha a fogyasztás stabil, vagy Rángatózásokkal fel-le jár., ami kötegelt feladatokra vagy szabálytalan forgalomra utalhat.

A nagyon magas %wa (I/O várakozás) érték arra utalhat, hogy a szűk keresztmetszet nem a CPU-ban, hanem a lemezen vagy a tároló alrendszerben lehet.

Szálak áttekintése egy folyamatban: top -H

Többszálú alkalmazások (Java, Python, Node stb.) esetén nem elég tudni, hogy melyik folyamat használja a CPU-t; látni kell, hogy melyik konkrét szál fogy ki az irányítás alól.

top -H -p PID

A folyamaton belüli egyes szálak részleteit megkapod. Ha az egyik 100%-on jelenik meg, a többi pedig tétlen, akkor valószínűleg egy végtelen ciklusról, egy furcsa blokkolási problémáról vagy egy rosszul megtervezett kritikus szakaszról van szó a kód adott részében.

Folyamatprioritás: szép és szép

Ha egy erőforrás-igényes folyamat jogos, de meg szeretné akadályozni, hogy túlterhelje a rendszer többi részét, akkor módosíthatja a prioritását (niceness) . A `nice` és `renice` parancsok lehetővé teszik alacsonyabb prioritású folyamatok indítását, vagy egy meglévő folyamat prioritásának módosítását, így a kernel kevesebb CPU-időt foglal le számukra más kritikus feladatokhoz képest.

Egyéb billentyűparancsok: pidof, kill, strace és ltrace

Amikor a rendszer nyomás alatt van, hasznos, ha gyorsan meg tudjuk találni és szabályozni tudjuk a folyamatokat:

• pidof: a folyamat PID-jét a nevéből nyeri ki, tökéletes szkriptekhez vagy gyors beavatkozásokhoz.
• megöl: jeleket küld a folyamatoknak (TERM, KILL stb.), hogy vagy rendezett módon leállítsák őket, vagy hogy rövidre zárják a feladatot, ha elakadtak.
• Eztán: mutatja a rendszerhívások amely egy folyamatot hajt végre; ideális annak megtekintésére, hogy min ragadt le (lemezolvasások, socketek stb.).
• ltnyomHasonló az strace-hez, de a hangsúly a következőn van: hívások könyvesboltokba, hasznos a megosztott API-használati problémák hibakereséséhez.

Ezek az eszközök nemcsak a memóriaszivárgások vagy összeomlások felkutatására hasznosak, hanem széles körben használják őket a kiberbiztonságban, a forenzikus elemzésben és a furcsa bináris viselkedés hibakeresésében is.

Fájl- és lemezparancsok: lsof, df, du, locate

Amikor gyanítod, hogy valami nincs rendben a tárolóval (például sok megnyitott fájl vagy megtelt lemez), más parancsok jönnek létre:

• lsof: sorold fel a egy folyamat által megnyitott fájlok, hasznos a leírók vagy fájlok szivárgásainak felderítésére, amelyek megakadályozzák a fájlrendszer leválasztását.
• df: mutatja a szabad lemezterület fájlrendszer szerint, ami elengedhetetlen a kaszkádos hibákat okozó lemezek 100%-ának kizárásához.
• du: számítsa ki a könyvtárak által használt hely, nagyon hasznos a kontrollálatlanul növekvő mappák (naplók, biztonsági mentések stb.) megkereséséhez.
• elhelyez: lehetővé teszi egy fájl név szerinti keresését indexelt adatbázis használatával, ami sok esetben gyorsabb, mint a keresés.

Hálózati parancsok diagnosztikához: nc, netstat, ab, tcpdump, wireshark, nmap

A teljesítmény- és memóriaproblémák gyakran hálózati szűk keresztmetszetek vagy támadások kísérik , ezért érdemes kéznél tartani néhány alapvető eszközt:

• nc (netcat): egy igazi svájci bicska a hálózatépítésben; megnyitja a socketeket, küld és fogad adatokat, lehetővé teszi a szolgáltatások tesztelését, sőt, még improvizált alagutak létrehozását is.
• netstat: megjeleníti az aktív kapcsolatokat, a figyelő socketeket és a hálózati statisztikákat, amelyek hasznosak annak megtekintéséhez, hogy egy adott porthoz sok kapcsolat van-e.
• ab (Apache Benchmark): terhelést generál egy webszerveren a válaszidők és a stressz alatti viselkedés mérésére.
• tcpdump és Wireshark: hálózati csomagok rögzítése mélyreható forgalomelemzés; tcpdump konzolban, Wireshark grafikus felülettel.
• nmapPort- és szolgáltatásszkenner, széles körben használják mind biztonsági auditokhoz, mind a szerver expozíciós felület.

GDB: a klasszikus hibakereső memóriahibákhoz és futásidejű összeomlásokhoz

Amikor egy Linux program szegmentációs hibával vagy más súlyos hibával összeomlik , a következő logikus lépés egy jó hibakereső használata. A GNU világának sztáreszköze a GDB (GNU Debugger) , amely lehetővé teszi a program belső állapotának vizsgálatát, leállítását bárhol, a változók és a memóriahasználat megtekintését, valamint a végrehajtás lépésről lépésre történő követését.

A GDB-t eredetileg C és C++ programokhoz tervezték, de kiterjesztették más nyelvekre is, mint például a Rust és az Assembly , valamint az olyan könyvtári elérési utak kezelésére, mint az LD_LIBRARY_PATH . Alapvető fontosságú a fejlesztésben, de a kiberbiztonságban is, ahol visszafejtésre, sebezhetőségek felkutatására, valamint támadások fejlesztésére vagy hibakeresésére használják.

Indítsd el a GDB-t és futtass egy programot

A GDB futtatható fájllal való használatához ajánlott a programot a következővel lefordítani: hibakeresési információk opció használatával -g a GCC-től:

gcc -g -Wall programa.c -o programa

Aztán elindítod a következővel:

gdb programa

A GDB-n belül a program még nem fut. Elindíthatod a következővel:

• futásIndítsd el a programot a kívánt argumentumokkal.
• kezdet: ugyanaz, mint a run, de a függvény elején megáll main.

Ha van egy futtatható fájlod, amelynek neve például Suma És ha látni szeretnéd, hogyan dolgozza fel az argumentumait, akkor menj be a GDB-be, és használd a következőt: run 3 5 hogy a hibakeresőből származó paraméterekkel indítsa el.

Töréspontok és figyelőpontok: a program szüneteltetése ott, ahol szükséges

A töréspontok a forráskód leállítási pontjai: amikor a végrehajtás eléri őket, a program szünetel, és megvizsgálhatjuk a belső állapotát. A GDB-ben a következő paranccsal definiálhatók :

break lugar

ahol a „hely” lehet egy függvény neve, sorszám vagy file:line . Egy tipikus példa erre:

break main

így a GDB a fő függvénybe lépéskor megáll. Amikor a program egy töréspontnál megáll, a kódot az l (lista) paranccsal tekintheti meg, változókat ellenőrizhet, és navigálhat a hívásveremben.

A figyelőpontok másképp működnek: a kód egy adott pontján való megállásra nem képesek, hanem egy változó értékének megváltozásakor . Nagyon hasznosak a memória sérülésének vagy a kritikus struktúrák váratlan módosításainak észlelésére anélkül, hogy a kódot nyomtatási utasításokkal kellene elárasztani.

Finom áramlásszabályozás: lépés, következő, folytatás, befejezés

Miután a program egy töréspontnál leállt, több lehetőség közül választhat a folytatáshoz:

• lépés: végrehajtja a következő sort és belép a meghívott függvényekbe.
• következő: a következő sort végrehajtja a függvények beírása nélkül (egyszerre futtatja azokat).
• folytatódik: folytatja a végrehajtást a következő töréspontig vagy a program leállásáig.
• befejezni: addig folytatódik, amíg az aktuális függvény vissza nem tér, és vissza nem tér arra a pontra, ahol meghívták.

Ez lehetővé teszi a gyanús kód lépésről lépésre történő vizsgálatát anélkül, hogy az egész programot „le kellene nyelni”. Egy hasznos trükk: a GDB-ben Az Enter megnyomása megismétli az utolsó parancsotideális számos elkészítéséhez next o step majd kevesebb gépelés.

Hívásverem és keretek: hogyan jutottunk el idáig

Ahhoz, hogy megértsük, miért történt egy hiba egy adott ponton, létfontosságú látni, hogy mely függvényeket hívták meg addig a pontig. Az ezt az információt tároló struktúra a hívásverem . A GDB számos parancsot kínál a kezelésére:

• bt (visszakövetés): a teljes veremlistát mutatja a beágyazott függvények listájával és a keretszámokkal.
• up: egy szinttel feljebb lép a veremben, arra a pontra, ahol az aktuális függvényt meghívta.
• le-: egy szinttel lejjebb ugrik, az éppen futó függvényhez.
• fr (képkocka): megjeleníti az aktuális képkockát, vagy lehetővé teszi a másikra váltást a számának megadásával.

Ez lehetővé teszi, hogy a hívás különböző szintjein elhelyezkedj (például egy belső függvényről a main füvényre ugorva ), és lásd, hogyan helyezkedtek el a változók az egyes helyeken.

Interakció a memóriával: set, return, backtrace yx

A GDB egyik nagy előnye, hogy lehetővé teszi a memória olvasását és módosítását a program leállított állapotában. Néhány hasznos művelet:

• készlet: megváltoztatja egy változó értékét végrehajtás közben, ideális tesztelési forgatókönyvekhez újrafordítás nélkül.
• visszatérési érték: arra kényszeríti az aktuális függvényt, hogy visszaadja a megadott értéket a kód végrehajtásának folytatása nélkül.
• visszakövetés: már látható, az aktuális hívásverem megjelenítéséhez.
• x: egy címtől kiindulva vizsgálja a memória tartalmát, különböző formátumokban és méretekben (például, x/4xw 0x7fffffffe000 hogy négy szót lássunk hexadecimális formában).

Ezekkel a beállításokkal replikálhatja a hibákat, ellenőrizheti, hogy egy veszélyes bemenet okoz-e túlcsordulást, vagy megvizsgálhatja a verem vagy a heap összetett adatszerkezeteit.

Utóvizsgálati hibakeresés központi dump-okkal

A Linux képes létrehozni egy központi fájlt, amikor egy folyamat összeomlik egy olyan jel miatt, mint a SIGSEGV. Ez a fájl tartalmazza a folyamat teljes állapotát az összeomlás időpontjában: memória, regiszterek, verem stb. Egy munkamenetben való aktiválásához egyszerűen tegye a következőket:

ulimit -c unlimited

Ha véglegesebb módon szeretné engedélyezni őket a felhasználók számára, szerkesztheti az /etc/security/limits.conf fájlt , és hozzáadhat egy ehhez hasonló sort:

* soft core unlimited

Amikor egy program összeomlik, létrehoz egy általában „core” nevű fájlt a munkakönyvtárban. Ezt aztán a GDB-vel a következőképpen elemezheted:

gdb ejecutable core

Ez lehetővé teszi a program utólagos elemzését, mintha még mindig működne, ami ideális, ha a hiba igény szerint nem könnyen reprodukálható.

Valgrind: memóriaszivárgások és hibák keresése

A C/C++ (és hasonló nyelvek) számos memóriaproblémájának megoldására a GDB nem elegendő, mivel nem képes automatikusan észlelni az illegális olvasásokat, szivárgásokat vagy inicializálatlan memóriahasználatot . Itt jön képbe a Valgrind – egy hibakereső és profilkészítő rendszer, amely emulálja a processzort és minden memória-hozzáférést figyel.

A Valgrind számos eszközt tartalmaz, de a legszélesebb körben használt a Memcheck , amely a C szabványos memóriakezelőjét a sajátjával helyettesíti, amely védelmi zónákat tartalmaz a lefoglalt blokkok körül . Ez lehetővé teszi a következők észlelését:

• Nem inicializált memóriahasználat (változók, amelyeket az érték hozzárendelése előtt használunk).
• Olvasások/írások a szabadnapok után (felhasználás utáni felszabadulás).
• Hozzáférés a határokon kívül egy memóriablokkról.
• Memóriaszivárgások (szabad malloc, elveszett mutatók stb.).

Hibamentes példa: „tiszta” program Memcheck alatt

Tegyük fel, hogy lefordítasz egy kis "hello world" programot hibakeresési információkkal:

gcc -Wall -gstabs valgrind_hello_good.c -o valgrind_hello_good

Ha Valgrind alatt futtatod:

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_good

Egy olyan nyomkövetést fogsz kapni, amelynek végén a HIBAÖSSZEFOGLALÓ 0 hibát jelez, és nem jelent szivárgást. Ez igazolja, hogy legalábbis a Memcheck szempontjából a program nem mutat memória-anomáliákat.

Memóriaszivárgások észlelése

Ha módosítod a kódot, hogy felszabadítás nélkül malloc-ot hajtson végre (például lefoglalsz egy bájtot, és soha nem szabadítod fel), és újrafordítod:

gcc -Wall -gstabs valgrind_hello_bad.c -o valgrind_hello_bad

futás közben:

valgrind --tool=memcheck --leak-check=full -v ./valgrind_hello_bad

A Valgrind egy HEAP SUMMARY-t jelenít meg egy nem nulla "használatban kilépéskor" értékkel, amely a fel nem használt memória mennyiségét jelzi. Ezenkívül a "határozottan elveszett" szakasz mutatja a kiszivárgott bájtok és blokkok számát, valamint a szivárgást okozó híváskövetést (függvény, fájl és kódsor).

Bonyolultabb esetekben, amikor szűrőket használnak, pl. 100 bájt egy leak() függvénybenA Valgrind kijárata egyértelműen a következőre mutat: malloc problémás, lehetővé téve a hozzáadását free megfelelő, és utána ellenőrizze, hogy az összesítés nulla szivárgásra áll-e vissza.

Illegális cselekmények és hatókörön kívüli hozzáférés

Egy másik tipikus hiba, amit a Memcheck észlel, az érvénytelen címekre írás , például a 0. memóriahelyre (NULL) vagy egy tömb végén túlra írás. Ha olyan programot fordítasz, amely érvénytelen írást hajt végre:

gcc -gstabs -Wall valgrind_illegal_read_write.c -o valgrind_illegal_read_write

és ezt hajtod végre:

valgrind -v ./valgrind_illegal_read_write

Az alábbi üzenetekhez hasonló üzeneteket fog látni:

Érvénytelen írási művelet 4 méretben a 0x80483C4 címen: main (valgrind_illegal_read_write.c:8) A 0x0 cím nincs stackelve, mallocálva vagy (nemrég) felszabadítva.

Ez pontosan megmondja, hogy hol történt az illegális írás és mekkora volt, ami normál végrehajtások során általában egy egyszerű "szegmentációs hibaként" jelentkezik további nyomok nélkül.

Nem inicializált változók és értékfüggőségeik

A Memcheck akkor is figyelmeztet, ha egy A szabályozási döntés egy inicializálatlan változótól függHa egy olyan lokális változóval fordítasz programot, amely soha nem inicializálódik, és egy if:

gcc -gstabs -Wall valgrind_unitialized.c -o valgrind_unitialized

és ezt futtatod:

valgrind -v --track-origins=yes ./valgrind_unitialized

A kimenet valami ilyesmit fog tartalmazni:

A feltételes ugrás vagy áthelyezés a 0x80483F2 címen található nem inicializált érték(ek)től függ: main (valgrind_unitialized.c:9) A nem inicializált értéket egy veremfoglalás hozta létre a 0x80483EA címen: main (valgrind_unitialized.c:7)

A –track-origins=yes paraméter segít megtalálni a nem inicializált változó létrehozási helyét, ami nagyban felgyorsítja a kódjavítást.

A szabad erőforrások helytelen használata és a hibaészlelés a halomban

A Valgrind azt is igazolja, hogy A free függvényt csak érvényes mutatók esetén hívjuk meg.Ha olyan memóriát próbálsz felszabadítani, ami nem innen származik mallocVagy ha duplán kattintasz ugyanarra a blokkra, akkor ilyen üzeneteket kapsz:

Érvénytelen free() / delete / delete[] / realloc() függvény a 0x402B06C címen: free (...) by 0x8048449: main (valgrind_illegal_free.c:11)

Sok esetben azt is megmondja, hogy melyik címről hívják. free Közvetlenül egy már felszabadított blokk után található, így azonosítható. mutatószámítási hibák vagy dupla kiadások.

Összefoglalva, a Valgrind elengedhetetlen eszköz, ha memóriaszivárgásra, felszabadítás utáni használatra vagy memória-sérülésre gyanakszunk natív programokban, és a GDB-vel kombinált használata nagyon hatékony képet ad az alkalmazások belső állapotáról.

Alapszintű dump-ok és elemzések Linux és Windows rendszeren

A modern alkalmazásokban, különösen a .NET Core -ban , az összetett memória- vagy teljesítményproblémák elemzése gyakran magában foglalja a memóriaképek rögzítését egy másik gépen történő gondos elemzéshez. Ezek a képelemek egy adott időpontban befagyasztják a folyamat állapotát, akárcsak egy hagyományos memóriakép.

.NET dump elemzése Linuxon dotnet-dump és LLDB használatával

Linux .NET Core környezetekben az egyik ajánlott eszköz a dotnet-dump . A dump rögzítése után a következővel kezdheti az elemzést:

dotnet-dump analyze <dump-file>

Fontos, hogy az elemzést egy olyan gépen végezzük, amelynek architektúrája és Linux disztribúciója megegyezik azzal a környezettel, ahol a dump generálódott. A dotnet-dump a felügyelt .NET kódhoz készült; natív kód (C/C++) elemzéséhez is célszerűbb az LLDB-t használni az SOS kiterjesztéssel együtt.

Az LLDB lehetővé teszi mind a felügyelt, mind a natív kód hibakeresését, és a dotnet-sos segítségével telepítheti az SOS bővítményt, amely specifikus parancsokat biztosít a .NET-hez. A .NET Core dump megfelelő betöltéséhez az LLDB és az SOS bizonyos bináris fájlokat igényel a dump létrehozási környezetéből:

1. libmscordaccore.so
2. libcoreclr.so
3. dotnet (az alkalmazás indításához használt gazdagép)

Ezek a bináris fájlok általában a dotnet-symbol eszközzel tölthetők le . Ha privát buildről van szó , vagy nem a szimbólumkiszolgálón találhatók, akkor mindig átmásolhatja őket az eredeti gépről. Ha a bináris fájlok nincsenek benne a dump fájlban, akkor a következőket használhatja az LLDB/SOS-ban:

• setclrpath <ruta> hogy jelezze, hol találhatók a .NET Core binárisok.
• setsymbolserver -directory <ruta> a szimbólumok helyének meghatározásához.

Miután minden szükséges dolog megvan, töltsd be a dump-ot az LLDB-be, és a dotnet hosztot add meg hibakeresésre futtatható fájlként:

lldb --core <dump-file> <host-program>

Itt Ez az út a szemétlerakáshoz és Általában bináris. dotnet, kivéve, ha önálló alkalmazásról van szó, amely esetben az alkalmazás saját futtatható fájlja lenne (.dll kiterjesztés nélkül).

Az LLDB-n belül gyakran szükséges a megfelelő szimbólumkiszolgáló konfigurálása a következővel: setsymbolserver -ms a Microsoft szerverének használatához, vagy setsymbolserver -directory <ruta> egy helyi könyvtárhoz, és futtassa a loadsymbols a natív szimbólumok betöltéséhez. Innen a szokásos SOS parancsokkal elemezheti a kezelt heap-et, a szálakat, a kivételeket stb.

Linux dump elemzés Windows rendszerből

A Linuxban generált dump-ok elemzése nem korlátozódik ugyanazon a rendszeren; Windowsból is megnyithatók olyan eszközökkel, mint a Visual Studio, a WinDbg vagy a dotnet-dump. A képességek eltérőek:

• Visual Studio: lehetővé teszi a szemétlerakók tisztítását a következők keverékével natív és felügyelt kódegy nagyon felhasználóbarát grafikus felülettel. Javasoljuk, hogy tekintse át a vonatkozó útmutatót. Visual Studio memóriaképek hibakeresése.
• WinDbgSpeciális támogatás a felhasználói memóriaképekhez, beleértve a Linux dumpok a Windowshoz hasonló munkafolyamattal. A WinDbg x64-es verzióját kell használnia a Linux x64 vagy Arm64 környezetekből származó memóriaképekhez, és az x86-os verziót az x86-os memóriaképekhez.
• dotnet-dump Windows rendszeren: ugyanúgy használható, mint Linuxon, dotnet-dump analyzeNe felejtsd el az eszköz x64 vagy x86 verzióját kiválasztani a memóriakép architektúrájának megfelelően.

Magas CPU- és memóriahasználat professzionális diagnosztizálása

A Linux memória-kiürítése a speciális eszközökön túl általában egy strukturált munkafolyamatot is magában foglal a véletlenszerű műveletek elkerülése érdekében. A szerverek esetében egy gyakorlati séma a következő:

• Megnézi felső gyanús betöltési minták és folyamatok észlelésére.
• Nyugtázza a gombbal ps a legtöbb CPU-t és memóriát használó folyamatok.
• Ellenőrizd, hogy a felhasználás logikus-e (fordítások, kötegelt, indexelt), vagy rendellenes viselkedésre utal-e.
• Szálak elemzése a következővel: felső -H -p PID ha többszálú folyamatokról van szó.
• ellenőrzés szerviznaplók journalctl vagy tail használatával.
• Ellenőrizd, hogy a probléma valóban a CPU-val kapcsolatos-e, vagy valami másban rejlik... lemez I/O iostat használatával.

Annak megállapításához, hogy a szűk keresztmetszet a CPU-ban vagy a lemezen van-e, az iostat -xz 1 3 parancs nagyon hasznos: ha magas kihasználtságú és hosszú várakozási idejű lemezeket lát, valamint magas %wa értéket a top mappában , a probléma valószínűleg nem a CPU-val, hanem a tárolóval van.

Ennek a munkafolyamatnak az alkalmazásával könnyebb diagnosztizálni az olyan eseteket, mint:

• Botok vagy rosszindulatú forgalom php-fpm folyamatok elindítása és a webszerver túlterhelése.
• Un Java mikroszolgáltatás egy végtelen ciklusban lévő szállal egy egész magot felemésztve.
• Egy Python folyamat, ami CPU-hoz kötöttnek tűnik, de valójában az zárolva, lemezre vár egy ciklus minden iterációjában.

Rendszereszközök (ps, top, vmstat, free), hibakeresők (GDB, LLDB, dotnet-dump), memóriaelemzők (Valgrind), valamint hálózati és lemezparancsok kombinálásával olyan munkamódszert hozhat létre, ahol a Linux memória- és teljesítményproblémái már nem fekete dobozok , hanem olyanokká válnak, amelyek módszeres és türelemmel jelentős pontossággal azonosíthatók és korrigálhatók.