Kompletan tutorijal o curenju memorije u Linuxu

Ako ste ikada imali slavinu za kuhinjski sudoper koja polako curi, znate koliko curenja mogu biti podmukla: u početku ne izgledaju velika, ali s vremenom mogu uzrokovati pravi problem. Curenje memorije u Linuxu je potpuno isto.Počinju kao gotovo neprimjetno kapanje, a završavaju tako što sruše servis, kritični mikroservis ili čak cijeli server.

U sistemu koji uvijek mora biti dostupan (serveri, produkcijski kontejneri, ugrađeni uređaji itd.), curenje memorije koje niko ne prati je poput tempirane bombe. Ako ne pratiš, ne otkrivaš i ne ispravljašU suprotnom, suočit ćete se s procesima koje je ubio OOM Killer, nasumičnim padovima sistema i ljutitim korisnicima koji ne razumiju baš šta se dogodilo. U ovom tutorijalu ćemo detaljno, ali koristeći lako razumljiv jezik, vidjeti kako otkriti i analizirati curenje memorije u Linuxu koristeći osnovne alate kao što su vrh/vrh čak i napredni profileri poput Valgrind, memleax ili gdb, pored komunalnih usluga kao što su /proc, pmap ili smem.

Šta je curenje memorije u Linuxu i zašto je toliko opasno?

Do curenja memorije dolazi kada program Rezervira sistemsku memoriju (heap, strukture, bafere itd.) i nikada je ne oslobađa. kada više nije potreban. U jezicima poput C ili C++, ovo se obično prevodi u pozive funkcije malloc, calloc, new koje nisu popraćene odgovarajućim free o deleteili u referencama koje se zaglave i onemogućavaju ponovnu upotrebu te memorije.

U praksi, proces se nastavlja normalno odvijati, ali Njegova potrošnja memorije se postepeno povećava Sa svakim zahtjevom, svakim radnim ciklusom ili svakim novim zadatkom, ovaj rast može biti vrlo spor (reda veličine nekoliko KB ili MB dnevno), što ga čini posebno teškim za otkrivanje na prvi pogled bez dobrog praćenja.

Posljedice ignorisanja ovog problema su jasne: degradacija performansi, stalne zamjene, ogromne latencijeI u određenom trenutku, sistemu ponestane dostupne memorije. Tu se Ubica OOM-a Linux kernela, koji zaustavlja procese koji troše najviše memorije (ili one koje algoritam smatra najpotrošnijim) kako bi se spriječio pad cijelog sistema.

Ovo ponašanje se obično najbolje vidi u grafovima praćenja: RSS memoriji procesa Postepeno raste tokom nekoliko dana Sve dok, iznenada, ne padne u trenutku kada ga OOM Killer prekine i servis se ponovo pokrene. Ako niko ne analizira ove događaje, curenje će ostati i ciklus će se ponoviti.

Zato je ključno shvatiti da Curenje memorije nije samo problem kodaali i rada i uočljivosti: potrebno je znati kako ih detektovati u produkciji, povezati ih sa sistemskim događajima i imati alate za njihovu analizu kako u procesima koji se već izvršavaju, tako i u testnim okruženjima.

Tipični uzroci i jasni simptomi curenja memorije

Sa razvojne perspektive, najčešći uzroci gubitaka pamćenja su obično greške u programiranju i loše prakse upravljanja resursimaMeđu najčešćim razlozima su: zaboravljanje oslobađanja memorije, održavanje memorijskih struktura koje se nikada ne čiste, nezatvaranje deskriptora koji imaju pridruženi bafer ili korištenje biblioteka trećih strana s internim greškama.

U dugotrajnim aplikacijama, kao što su demoni, web servisi ili batch procesi koji se nikada ne ponovo pokreću, problemi se pogoršavaju jer Svako malo curenje se vremenom akumuliraČak i rijetka greška koja se javlja samo u određenom rubnom slučaju može potrošiti RAM ako proces ostane aktivan mjesecima.

Simptomi koji bi vas trebali upozoriti su prilično prepoznatljivi ako znate na šta treba paziti. Najočitije je vidjeti kako Memorija procesa (RES/RSS) neprestano raste čak i ako radno opterećenje ostane stabilno. To je kao da gledate kako pokazivač goriva pada u parkiranom automobilu.

Još jedan tipičan efekat je progresivno smanjenje performansiSistem počinje koristiti swap, latencije naglo rastu, upiti ili zahtjevi koji su prethodno bili brzi postaju beskonačni, a i ostali procesi hosta također pate, iako nisu direktni krivci.

Konačno, pojavljuje se najdramatičniji simptom: neočekivani kvarovi procesa ili sistemaKernel, bez memorije za dodjelu, aktivira Out-of-Memory Killer i prekida procese. Ako je proces koji se ruši izolirani mikroservis, to je i dalje manji problem, ali ako je proces koji se ruši, na primjer, baza podataka ili upravitelj reda čekanja, utjecaj može biti vrlo ozbiljan.

Vrlo efikasan način za identifikaciju ovih slučajeva u produkciji je kombinovanje grafova memorije sa kolekcija sistemskih događajauključujući i one koje generira OOM Killer. Ako na svojim kontrolnim pločama vidite obrazac potrošnje memorije koji se polako povećava, a zatim naglo pada, i u tom tačnom trenutku imate jedan ili više OOM Killer događaja, gotovo sigurno se radi o curenju memorije u tom procesu.

Osnovni monitoring sa top i htop

Za prvi pristup, nema potrebe previše komplikovati stvari: alati poput vrh i iznad svega, htop Savršeni su za pregled u realnom vremenu koji procesi troše vašu memoriju. Oni su poput brze kontrolne ploče za identifikaciju krivaca.

U većini distribucija možete instalirati htop Lako pomoću upravitelja paketa. Na sistemima baziranim na Debianu, nešto poput ovoga bi bilo dovoljno:

sudo apt install htop

Nakon instalacije, kada pokrenete htop Vidjet ćete interaktivni prikaz procesa s bojama, CPU i memorijskim trakama i različitim stupcima. Ključne kolone za otkrivanje curenja To su rezidentna memorija i virtuelna memorija procesa:

- OIE / RSS (Veličina rezidentnog skupa): fizička memorija koju proces trenutno ima u RAM-u.
- VIRT (Virtualna memorija): ukupna virtuelna memorija koju je proces dodijelio (uključuje mapiranu i potencijalno zamijenjenu memoriju).
- %MEM: postotak fizičke RAM memorije koju proces troši od ukupne sistemske RAM memorije.

Ako naručite do RES ili %MEM A ako ostavite htop otvoren neko vrijeme, možete posmatrati kako se procesi razvijaju. Ako jedan od njih Polako se penje uz ove stubove, a nikada se ne vraća dolje.To ukazuje na gubitak pamćenja ili, u najmanju ruku, na njegovu nezdravu upotrebu.

top, iako nešto decentniji, također vam omogućava pregled ovih vrijednosti i njihovo praćenje tokom određenog vremenskog perioda, ali htop znatno olakšava produženo posmatranje i filtriranje specifičnih procesa koji vas zanimaju.

Dublje zalaženje u /proc datotečni sistem

Da bi se prešlo sa površnog pogleda na rafiniraniju analizu, Linux otkriva detaljne informacije o svakom procesu u pseudo-datotečnom sistemu /procSvaki PID ima svoj direktorij unutar /procI tamo možete provjeriti sve vrste metrika, uključujući i one vezane za memoriju.

Klasična ulazna tačka je datoteka /proc//status, gdje ćete pronaći polja kao što su VmRSS, VmSize ili VmDataMožete ih pogledati jednostavnim putem:

cat /proc/<pid>/status

U tom izlazu, najzanimljivija polja za otkrivanje curenja memorije su:

- VmRSSrezidentna memorija (u KB) koju proces trenutno ima u RAM-u.
- VmSizeukupna virtuelna memorija povezana s procesom (uključuje sve što je mapirano).
- VmData: memorija segmenta podataka, gdje se obično nalaze dinamičke strukture i hipovi, područje vrlo sklono curenju memorije.

Praktična ideja je da se ove vrijednosti stalno provjeravaju. u redovnim intervalima (bilo ručno ili putem skripti) i posmatrajte da li prate konzistentan uzlazni trend. Ako vidite da VmRSS i, posebno, VmData rastu bez smanjenja tokom perioda niskog opterećenja, to je prilično jak pokazatelj da aplikacija ima curenje memorije.

Pored toga statusu /proc/ Imate i druge zanimljive datoteke za analizu memorijske mape, kao što su maps o smaps, iako su opširniji i često se koriste u kombinaciji s drugim alatima kao što su pmapa kako bi informacije bile čitljivije.

Analiza mape memorije procesa korištenjem pmap-a

Korisnost pmapa To je vrlo korisna naredba za dobijanje organiziranog pregleda mape memorije određenog procesa. U suštini, ona prikazuje koje raspone adresa je proces mapirao, veličinu svakog raspona, njegove dozvole i kojoj datoteci, biblioteci ili tipu memorije odgovara.

Da biste ga koristili, jednostavno pokrenite:

pmap

U izlazu ćete vidjeti linije sa početnom adresom, veličinom, dozvolama (čitanje, pisanje, izvršavanje) i porijeklom (na primjer, glavna izvršna datoteka, dijeljena biblioteka kao što je libcanonimna područja, gomila itd.). Anonimne memorijske regije i zona hipa Ovo su oni koji obično daju tragove kada dođe do curenja memorije.

Praktičan način praćenja napretka je ponavljanje. pmap s vremena na vrijeme i provjeriti da li su određeni segmenti (posebno anonimni) povezani sa heap-om ne prestaju rastiTakođer možete filtrirati ili sažeti izlaz, na primjer:

pmap <pid> | grep total

Ovo će vam dati sažetak ukupne memorije koju je proces mapirao. Ako taj broj nastavlja rasti i rasti tokom nekoliko sati i ne stabilizira se ili ne smanjuje kada bi trebao, sumnja ponovo ukazuje na curenje memorije ili neefikasno upravljanje internim baferima.

smem: razlikovanje dijeljene memorije i stvarne upotrebe svakog procesa

Alati poput top, htop ili pmap broje svu memoriju na koju se proces poziva, ali ne odvajaju jasno memoriju koja je zaista ekskluzivna za taj proces od memorije koja se dijeli s drugima (na primjer, dijeljene biblioteke). Tu [sljedeće dolazi do izražaja]. smem, specifičan uslužni program koji pruža precizniji prikaz.

Velika prednost smema je što izračunava metrike kao što su USS (Jedinstvena veličina seta), PSS (Proporcionalna veličina seta) i RSSšto omogućava bolje razumijevanje stvarne upotrebe memorije po procesu: koliko memorije je samo vlastito, a koliko se dijeli s drugim procesima koji učitavaju iste biblioteke ili dijele stranice.

Neke od najrelevantnijih metrika koje ćete vidjeti u smem izlazu su:

- USS (Unique Set Size): memorija koju koristi samo taj proces; ako proces nestane, taj dio memorije se potpuno oslobađa.
- PSS (Proporcionalna veličina skupa): raspoređuje dijeljenu memoriju među svim procesima koji je koriste, nudeći prilično pravedan proporcionalan prikaz stvarnog otiska.
- RSS (Veličina rezidentnog skupa): Rezidentna memorija, kao u drugim alatima, ali predstavljena zajedno s gore navedenim radi poređenja.

Prilikom pokretanja nečega poput smem -k Dobit ćete tabelu sa PID-om, korisnikom, naredbom i ovim kolonama za korištenje memorije. Zanimljivo je, u smislu curenja memorije, fokusirati se prvenstveno na USSjer odražava vlastitu memoriju aplikacije, gdje se obično pojavljuju najozbiljnija curenja.

Ako ostavite smem periodično pokrenut (ili ga integrirate u skripte za praćenje) i vidite da USS određenog procesa Nastavlja se povećavati tokom vremenaČak i kada opterećenje ne raste, ponašanje u velikoj mjeri ukazuje na curenje memorije u dijelu procesa koji se odnosi na jednu memoriju.

memleax: automatsko otkrivanje curenja u pokrenutim procesima

Nakon što ste identificirali proces koji izgleda kao da curi memoriju i želite ga riješiti korak dalje bez ponovnog pokretanja, vrlo koristan alat je... memleaxNjegova najveća snaga je u tome što Omogućava vam da u realnom vremenu otkrijete curenje memorije u procesu koji je već pokrenut., bez potrebe za ponovnim kompajliranjem ili ponovnim pokretanjem posebnom naredbom.

Memleax se prvenstveno distribuira u obliku paketa. .rpm y .debDostupan je u nekim repozitorijumima, kao što su oni za Arch Linux i FreeBSD. Na sistemima zasnovanim na Debianu, uobičajeni način instalacije je preuzimanje paketa sa njegovog službenog GitHub repozitorija, a zatim korištenje dpkg Da biste ga instalirali, riješite zavisnosti pomoću upravitelja paketa.

Nakon instalacije, memleax možete priložiti procesu pomoću:

sudo memleax -p

Od tog trenutka nadalje, memleax presreće pozive za alokaciju memorije (kao što su malloc) i zapisuje adrese i veličine koje proces rezerviše. Kada otkrije da alokacija nije ispravno oslobođena, eksplicitno označava kao curenje memorije, navodeći veličinu bloka i odgovornu adresu.

Tipičan izlaz prikazuje linije stila malloc(128) = 0x... nakon čega slijede, kada postoji problem, poruke koje ukazuju na nešto poput Otkriveno curenje memorije za određeni blok. Ova informacija je veoma korisna jer vam govori da, iako je proces još uvijek aktivan i radi, postoje blokovi koji postaju osiroćeni.

memleax je posebno atraktivan za produkcijska ili predprodukcijska okruženja gdje Ne možete si priuštiti ponovno pokretanje usluge sa debuggerom ili sa Valgrindom od nule, ali morate razumjeti šta se dešava unutra u smislu dinamičkog upravljanja memorijom.

Korištenje gdb-a za detaljnu inspekciju memorije procesa

Ako vam je potreban još veći nivo detalja i možete si priuštiti nametljivije otklanjanje grešaka, GNU debugger (gdb) To je vaš saveznik. To je izuzetno moćan alat koji vam omogućava da pridružite se postojećem procesupregledati varijable, stekove poziva i, naravno, stanje hipa.

Za početak, instalirate gdb iz repozitorija vaše distribucije (na primjer, sa sudo apt install gdb (na Debianu/Ubuntuu) a zatim ga prikačite procesu sa:

sudo gdb -p

Jednom kada se nađete unutar gdb sesije, možete koristiti razne naredbe vezane za heap. U nekim okruženjima, naredba je direktno dostupna. heap (ili ekstenzije koje ga pružaju) za popis dinamičkih memorijskih blokova koji se trenutno koriste, s njihovim adresama i veličinama. Izlaz prikazuje nešto poput popisa memorijskih dijelova, svaki s adresom i veličinom, označenih kao u upotrebi.

Nadalje, iz gdb-a možete pozivati ​​libc funkcije kao što su malloc_stats() kroz:

(gdb) call malloc_stats()

Ova vrsta poziva vam daje sažetak stanja alokatora memorije: koliko memorije je alocirano, kako je heap podijeljen itd. To je relativno brz način da se vidi da li memorija koju proces alocira nekontrolirano raste.

Još jedan moćan pristup je postavljanje tačke prekida u funkcijama kao što su malloc o free da se u realnom vremenu posmatra kako se kod ponaša: koliko puta rezerviše, u kojim tačkama oslobađa, koje putanje koda dodeljuju mnogo prostora, ali malo oslobađaju... Iako ovo zahteva više stručnosti u otklanjanju grešaka, to je direktan način da se locira tačan izvor curenja.

Valgrind: klasični profiler memorije u Linuxu

Ako govorimo o detekciji curenja memorije u Linux okruženjima, nemoguće je ne spomenuti valgrindValgrind je više od običnog alata, okvir za otklanjanje grešaka i profiliranje koji uključuje nekoliko modula, od kojih je najpoznatiji i najkorišteniji Memcheck, dizajniran posebno za otkrivanje problema s pamćenjem.

Memcheck funkcioniše tako što pokreće vaš program unutar neke vrste virtuelne mašine koja Presreće i prati sve operacije povezane s memorijom.: alokacije, oslobađanja, pristupi adresama, itd. Osim toga, zamjenjuje standardni alokator memorije u C-u svojim vlastitim, što uvodi dodatne zaštite oko rezerviranih blokova kako bi se otkrili pristupi izvan dometa.

Među vrstama grešaka koje Memcheck može otkriti su: Neinicijalizirana upotreba memorije, čita/piše nakon oslobađanja memorije, ilegalni pristup memorijskim područjima koja ne pripadaju programu i, naravno, curenje memorije različitih tipova (blokovi definitivno izgubljeni, moguće izgubljeni, još uvijek dostupni, itd.).

Njegova osnovna upotreba je relativno jednostavna. Program kompajlira sa simbolima za otklanjanje grešaka (na primjer, sa -g o -gstabs) a zatim ga pokrenete pod Valgrindom s nečim poput:

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

U programu koji dobro upravlja memorijom, izlaz Memchecka će pokazati sažetak grešaka sa nula incidenataTo jest, nema ilegalnih čitanja, nema pisanja izvan raspona i nema bajtova heap memorije u upotrebi kada se program završi. To je obično prvi korak: provjera "čistog" slučaja kako bi se vidjelo kako izgleda čisto izvršenje.

Ako namjerno uvedete malloc bez odgovarajućeg freeili bilo koji drugi obrazac curenja, i ponovo pokrenete binarni fajl sa Valgrind-om, vidjet ćete u izlazu a SAŽETAK HEAP-a što pokazuje koliko memorije ostaje "u upotrebi" nakon zatvaranja aplikacije. U odjeljku SAŽETAK CURENJA Redovi poput „definitivno izgubljeno“ će se pojaviti s bajtovima i blokovima koji nisu oslobođeni.

Osim toga, Memcheck će vam tačno reći gdje se dogodila alokacija koja je uzrokovala curenjeVidjet ćete trag poziva s funkcijama, izvornim datotekama i brojevima linija. Na primjer, može pokazati da je malloc u određenom redu vaše datoteke .c Stvorio je blokadu koja nikada nije otpuštena, odmah bacajući svjetlo na izvor problema.

Valgrind je također vrlo efikasan u otkrivanju drugih klasičnih grešaka: na primjer, ilegalni zapisi u sjećanju (kao što je pisanje na adresu 0 ili izvan granica niza), korištenje neinicijaliziranih varijabli (prikazivanje poruka poput „Uslovni skok ili pomicanje zavisi od neinicijalizirane vrijednosti“) ili netačna izdanja (kako to uraditi free na pokazivaču koji ne dolazi iz mallocili otpustite isti blok dva puta).

U svim ovim slučajevima, Memcheck izvještaj detaljno prikazuje gdje se dogodio pogrešan pristup ili ilegalni slobodan pristup, koja ga je funkcija pokrenula i u kojem dijelu koda je ta varijabla kreirana ili ta memorija rezervirana, što ga čini praktično nezamjenjivim alatom za... temeljito otklanjanje grešaka u upravljanju memorijom u C i C++ programskim jezikima.

Drugi programi za profiliranje memorije: gperftools, Massif i drugi

Iako je Valgrind-Memcheck često prvi izbor, postoje i drugi alati za profiliranje koji vrlo dobro dopunjuju analizu curenja memorije i obrazaca korištenja. Jedan od njih je gperftools (ranije Google Performance Tools), koji uključuje profiler hipa sposoban za snimanje korištenja memorije tokom vremena i generiranje vizualnih izvještaja (na primjer, sa pprof) koji pokazuju koji dijelovi koda rezerviraju više memorije.

Još jedan alat iz porodice Valgrind je Masiv, fokusiran posebno na profiliranje heap memorijeUmjesto fokusiranja isključivo na greške, Massif mjeri veličinu heap-a tokom izvršavanja i generira podatke koje zatim možete vizualizirati kako biste razumjeli u kojim fazama memorija vašeg programa najviše raste i koje su strukture ili funkcije odgovorne.

Općenito, ovi profileri rade presretanjem memorijskih operacija na način sličan Valgrindu ili putem instrumentalnih biblioteka, i Oni bilježe detaljne statistike o alokacijama i izdavanjimaKonačno, oni vam pružaju izvještaje koji uključuju broj alokacija, ukupnu rezerviranu veličinu, specifične lokacije u kodu gdje su napravljene najveće rezervacije i, naravno, blokove koji se nikada ne oslobađaju.

Tipičan tok rada se sastoji od pokrenite program pod profilerom (U okruženju što bližem produkcijskom, ali kontroliranom), reproducirajte radno opterećenje ili slučaj upotrebe za koji sumnjate da uzrokuje curenje, a zatim analizirajte generirane izvještaje pomoću grafičkih alata ili alata komandne linije. Na taj način možete na prvi pogled vidjeti koje putanje koda uzrokuju nekontroliranu upotrebu memorije.

Proaktivne strategije: testiranje opterećenja, ograničenja i najbolje prakse

Sve navedeno pomaže u otkrivanju problema kada već postoje, ali idealna strategija je spriječiti curenje da dođe do proizvodnje Ili ih barem uhvatiti što je prije moguće. Da biste to učinili, preporučljivo je kombinirati nekoliko taktika vezanih za testiranje, konfiguraciju sistema i kvalitet koda.

Prije svega, ima mnogo smisla uraditi testiranje opterećenja i stresa u predprodukcijskim okruženjima koji su što realniji. Alati kao što su Apache JMeter, Locust, stress Slični alati vam omogućavaju simuliranje istovremenih korisnika, intenzivnih zahtjeva ili produženih scenarija. Tokom ovih testova, trebali biste pažljivo pratiti metrike memorije (RSS, heap, itd.) kako biste vidjeli ima li problema. spor, ali kontinuiran rast.

Paralelno s tim, preporučljivo je pratiti ne samo sirove metrike, već i sistemski događaji poput onih OOM KilleraPlatforme za praćenje i uočljivost logova mogu agregirati ove informacije i upozoriti vas kada se, na primjer, OOM događaji akumuliraju na određenom hostu, što obično ukazuje na neispravno funkcioniranje procesa ili nedostatak resursa.

Na nivou konfiguracije sistema, Linux nudi mehanizme za ograničiti uticaj procesa koji "izmiče kontroli". Na primjer, sa ulimit Možete nametnuti ograničenja memorije procesima koje pokreće određeni korisnik, ograničavajući veličinu njihove virtualne memorije. Nešto poput ulimit -v <kilobytes> Ovo će spriječiti da jedan servis potroši svu RAM memoriju hosta.

Za naprednije scenarije, cgrupe (kontrolne grupe) Omogućavaju vam da izolujete i ograničite potrošnju resursa (CPU, memorija, I/O, itd.) od strane grupa procesa. Možete kreirati kontrolnu grupu sa određenim ograničenjem memorije i dodijeliti joj servis, tako da se u slučaju curenja memorije šteta ograniči. inkapsulirano u toj grupi i da ne utiču na cijeli sistem.

Konačno, u smislu razvoja, najbolja odbrana ostaje Napišite kod koji od samog početka dobro upravlja memorijom.U C/C++, ovo podrazumijeva rigoroznost sa svakim malloc/new i njemu odgovara free/delete, koristite RAII obrasce, pametne pokazivače (kao što su std::shared_ptr, std::unique_ptri izbjegavajte nepotrebne reference. Također se možete konsultovati sa Vodič za hrđu Za alternative koje štite memoriju. U jezicima sa sakupljačima smeća (Java, C#, Go, Python, JavaScript, itd.) također je lako uzrokovati pseudo-curenja ako zadržavate aktivne reference na objekte koji vam više nisu potrebni.

Alati od statička analiza kao što je cppcheck, SonarQube Ovi alati i metode pomažu u otkrivanju sumnjivih obrazaca koda tokom razvoja. Dodajte tome pažljive preglede koda, jedinične testove koji provjeravaju ponašanje pod opterećenjem i redovna pokretanja Valgrinda ili drugih profilera u CI okruženjima, i šanse da ozbiljna ranjivost dođe do produkcije su znatno smanjene.

U konačnici, držanje curenja memorije pod kontrolom u Linuxu uključuje kombinovanje kontinuirano praćenje, moćni dijagnostički alati i dobre prakse programiranjaPomoću top, htop, /proc, pmap i smem možete locirati sumnjive procese; pomoću memleax i gdb možete izvršiti inspekcije uživo; pomoću Valgrind, gperftools ili Massif možete temeljito debagirati i profilirati; a uz testiranje opterećenja, sistemska ograničenja i dobro napisan kod, možete spriječiti da problem eksplodira u najgorem mogućem trenutku.