Kumpletong tutorial tungkol sa mga memory leak sa Linux

Kung nagkaroon ka na ng gripo sa lababo na unti-unting tumutulo, alam mo kung gaano kalaki ang maaaring maging sanhi ng mga tagas: sa una ay tila hindi naman gaanong kalaki, ngunit sa paglipas ng panahon ay maaari itong magdulot ng malaking problema. Ang mga memory leak sa Linux ay eksaktong pareho.Nagsisimula ang mga ito bilang isang halos hindi mahahalatang patak at nauuwi sa pagbagsak ng isang serbisyo, isang kritikal na microservice, o kahit isang buong server.

Sa isang sistemang dapat laging available (mga server, production container, embedded device, atbp.), ang isang memory leak na walang nagmomonitor ay parang isang time bomb na nagki-tick. Kung hindi mo minomonitor, hindi mo matutukoy at hindi mo itatamaKung hindi, mahaharap ka sa mga prosesong pinapatay ng OOM Killer, mga random na pag-crash, at mga galit na user na hindi lubos na naiintindihan ang nangyari. Sa tutorial na ito, titingnan natin nang detalyado, ngunit gamit ang madaling maunawaang wika, kung paano matukoy at masuri ang mga memory leak sa Linux gamit ang mga pangunahing tool tulad ng tuktok kahit na ang mga advanced profiler tulad ng Valgrind, memleax o gdb, bilang karagdagan sa mga kagamitan tulad ng /proc, pmap o smem.

Ano ang memory leak sa Linux at bakit ito mapanganib?

Nangyayari ang memory leak kapag ang isang programa Inilalaan nito ang memorya ng sistema (heap, mga istruktura, buffer, atbp.) at hindi kailanman inilalabas ito. kapag hindi na ito kailangan. Sa mga wikang tulad ng C o C++, kadalasan itong isinasalin sa mga tawag sa malloc, calloc, new na hindi kasama ng kanilang kaukulang free o deleteo sa mga sanggunian na natigil at ginagawang imposibleng gamitin muli ang memoryang iyon.

Sa pagsasagawa, ang proseso ay patuloy na tumatakbo nang normal, ngunit Unti-unting tumataas ang pagkonsumo ng memorya nito Sa bawat kahilingan, bawat siklo ng trabaho, o bawat bagong gawain, ang paglago na ito ay maaaring maging napakabagal (mga ilang KB o MB bawat araw), na ginagawang lalong mahirap matukoy nang mabilisan nang walang mahusay na pagsubaybay.

Ang mga kahihinatnan ng hindi pagpansin sa problemang ito ay malinaw: pagbaba ng performance, patuloy na pagpapalit, malalaking latencyAt sa isang tiyak na punto, mauubusan ng magagamit na memorya ang sistema. Doon ang Linux Kernel OOM Killer, na pumapatay sa mga prosesong kumukunsumo ng pinakamaraming memorya (o iyong mga itinuturing ng algorithm na pinakamadaling maubos) upang maiwasan ang pag-crash ng buong sistema.

Ang kilos na ito ay karaniwang pinakamahusay na nakikita sa mga graph ng pagsubaybay: ang RSS memory ng isang proseso Unti-unti itong tumataas sa loob ng ilang araw Hanggang sa, bigla na lang itong bumagsak nang wakasan ito ng OOM Killer at muling magsimula ang serbisyo. Kung walang susuri sa mga pangyayaring ito, mananatili ang tagas at uulit ang siklo.

Kaya naman mahalagang maunawaan iyan Ang mga pagtagas ng memorya ay hindi lamang isang problema sa codekundi pati na rin sa operasyon at pagiging mapagmasid: kinakailangang malaman kung paano matukoy ang mga ito sa produksyon, iugnay ang mga ito sa mga kaganapan sa sistema at magkaroon ng mga kagamitan upang suriin ang mga ito kapwa sa mga prosesong tumatakbo na at sa mga kapaligirang pangsubok.

Karaniwang mga sanhi at malinaw na sintomas ng memory leak

Mula sa perspektibo ng pag-unlad, ang mga pinakakaraniwang sanhi ng mga pagkawala ng memorya ay karaniwang mga pagkakamali sa programming at mahinang kasanayan sa pamamahala ng mapagkukunanKabilang sa mga pinakakaraniwang dahilan ay: paglimot sa pagpapalaya ng memorya, pagpapanatili ng mga istruktura ng memorya na hindi kailanman pinuputol, hindi pagsasara ng mga descriptor na may kaugnay na buffer, o paggamit ng mga third-party na library na may mga internal na bug.

Sa mga pangmatagalang aplikasyon, tulad ng mga daemon, web service, o mga batch process na hindi kailanman nagre-restart, lumalala ang mga problema dahil Ang anumang maliit na tagas ay naiipon sa paglipas ng panahonKahit ang isang bihirang bug na nangyayari lamang sa isang partikular na edge case ay maaaring maubusan ng RAM kung ang proseso ay mananatiling aktibo sa loob ng ilang buwan.

Ang mga sintomas na dapat mag-alerto sa iyo ay madaling makikilala kung alam mo kung ano ang hahanapin. Ang pinakahalata ay ang makita kung paano Ang memorya ng isang proseso (RES/RSS) ay patuloy na lumalaki kahit na nananatiling matatag ang workload. Para itong panonood sa pagbaba ng fuel gauge sa isang nakaparadang kotse.

Isa pang tipikal na epekto ay ang progresibong pagbaba ng pagganapNagsisimulang gumamit ng swap ang system, tumataas nang husto ang mga latency, nagiging walang katapusan ang mga query o request na dating mabilis, at nagdurusa rin ang iba pang proseso ng host, kahit na hindi naman sila ang direktang salarin.

Sa wakas, lumilitaw ang pinaka-dramatikong sintomas: hindi inaasahang proseso o pagkabigo ng sistemaAng kernel, na walang memory na ilalaan, ay nag-a-activate ng Out-of-Memory Killer at tinatapos ang mga proseso. Kung ang prosesong nagka-crash ay isang isolated microservice, ito ay isang maliit na isyu pa rin, ngunit kung ang prosesong namamatay ay, halimbawa, ang database o ang queue manager, ang epekto ay maaaring maging napakalubha.

Isang napaka-epektibong paraan upang matukoy ang mga kasong ito sa produksyon ay ang pagsamahin ang mga memory graph sa koleksyon ng kaganapan sa sistemakasama na ang mga nalilikha ng OOM Killer. Kung makakita ka ng pattern ng pagkonsumo ng memorya sa iyong mga dashboard na unti-unting tumataas, pagkatapos ay biglang bumababa, at sa eksaktong sandaling iyon ay mayroon kang isa o higit pang mga kaganapan sa OOM Killer, halos tiyak na nahaharap ka sa isang memory leak sa prosesong iyon.

Pangunahing pagsubaybay gamit ang top at htop

Para sa unang paraan, hindi na kailangang gawing kumplikado ang mga bagay-bagay: mga kagamitang tulad ng tuktok at higit sa lahat, htop Perpekto ang mga ito para makita nang real time kung aling mga proseso ang kumukunsumo ng iyong memorya. Para silang isang mabilis na control panel para matukoy ang mga salarin.

Sa karamihan ng mga distribusyon, maaari mong i-install ang htop Madaling gamitin gamit ang package manager. Sa mga sistemang nakabase sa Debian, sapat na ang ganito:

sudo apt install htop

Kapag na-install na, kapag pinatakbo mo na htop Makakakita ka ng interactive na view ng mga proseso na may mga kulay, CPU at memory bar, at iba't ibang column. Ang mga pangunahing kolum para sa pagtukoy ng mga tagas Sila ang resident memory at ang virtual memory ng proseso:

- RES / RSS (Laki ng Set ng Residente): pisikal na memorya na kasalukuyang nasa RAM ng proseso.
- VIRT (Virtual Memory): kabuuang virtual memory na inilaan ng proseso (kasama ang naka-map at posibleng ipinagpalit na memorya).
- %MEM: porsyento ng pisikal na RAM na kinokonsumo ng proseso mula sa kabuuang RAM ng sistema.

Kung mag-oorder ka ng RES o %MEM At kung iiwan mong bukas ang htop nang ilang sandali, mapapanood mo kung paano umuunlad ang mga proseso. Kung isa sa mga ito Patuloy itong dahan-dahang umaakyat sa mga haliging ito nang hindi na bumababa muli.Ipinahihiwatig nito ang pagkawala ng memorya o, kahit papaano, isang hindi malusog na paggamit nito.

Ang top, bagama't mas simple, ay nagbibigay-daan din sa iyo na tingnan ang mga halagang ito at subaybayan ang mga ito sa loob ng isang panahon, ngunit ang htop ay ginagawang mas madali ang matagal na pagmamasid at pagsala ng mga partikular na proseso na interesado ka.

Pagsisiyasat nang mas malalim sa /proc file system

Upang lumipat mula sa isang mababaw na pananaw patungo sa isang mas pinong pagsusuri, inilalantad ng Linux detalyadong impormasyon tungkol sa bawat proseso sa pseudo filesystem /procAng bawat PID ay may sariling direktoryo sa loob /procAt doon mo masusuri ang lahat ng uri ng sukatan, kabilang ang mga nauugnay sa memorya.

Ang isang klasikong entry point ay ang file /proc//status, kung saan makikita mo ang mga patlang tulad ng VmRSS, VmSize o VmDataMaaari mong tingnan ang mga ito sa pamamagitan ng isang simpleng halimbawa:

cat /proc/<pid>/status

Sa output na iyon, ang mga pinaka-interesante na field para sa pag-detect ng memory leak ay:

- VmRSS: resident memory (sa KB) na mayroon ang proseso sa RAM sa sandaling iyon.
- Sukat ng Vm: kabuuang virtual memory na nauugnay sa proseso (kasama ang lahat ng na-map).
- VmData: memorya ng segment ng data, kung saan karaniwang matatagpuan ang mga dynamic na istruktura at tambak, isang lugar na madaling kapitan ng pagtagas ng memorya.

Ang praktikal na ideya ay patuloy na suriin ang mga halagang ito. sa mga regular na pagitan (manu-mano man o sa pamamagitan ng mga script) at obserbahan kung sumusunod ang mga ito sa isang pare-parehong pataas na trend. Kung nakikita mong tumataas ang VmRSS at, lalo na, ang VmData nang hindi bumababa sa mga panahong mababa ang load, ito ay isang medyo malakas na indikasyon na ang application ay may tagas ng memorya.

At statusSa /proc/ Mayroon kang iba pang mga kawili-wiling file upang suriin ang mapa ng memorya, tulad ng maps o smaps, bagama't mas masinsinan ang mga ito at kadalasang ginagamit kasabay ng iba pang mga kagamitan tulad ng pmap upang mas madaling mabasa ang impormasyon.

Pagsusuri ng mapa ng memorya ng isang proseso gamit ang pmap

Kagamitan pmap Isa itong napaka-kapaki-pakinabang na utos para sa pagkuha ng organisadong pagtingin sa mapa ng memorya ng isang partikular na proseso. Sa esensya, ipinapakita nito kung aling mga saklaw ng address ang na-map ng proseso, ang laki ng bawat saklaw, ang mga pahintulot nito, at kung aling file, library, o uri ng memorya ang katumbas nito.

Para magamit ito, ilunsad lamang ang:

pmap

Sa output, makakakita ka ng mga linya na may panimulang address, laki, mga pahintulot (basahin, isulat, isagawa), at pinagmulan (halimbawa, ang pangunahing executable, isang shared library tulad ng libcmga hindi kilalang lugar, ang tambak, atbp.). Mga rehiyon ng memorya na hindi nagpapakilala at ang heap zone Ito ang mga karaniwang nagbibigay ng mga pahiwatig kapag may mga memory leak.

Ang isang praktikal na paraan upang subaybayan ang progreso ay ang pag-uulit. pmap paminsan-minsan at suriin kung ang ilang mga segment (lalo na ang mga hindi nagpapakilala ay nauugnay sa heap) hindi sila tumitigil sa paglakiMaaari mo ring i-filter o ibuod ang output, halimbawa:

pmap <pid> | grep total

Ito ay magbibigay sa iyo ng buod ng kabuuang memorya na na-map ng proseso. Kung ang bilang na iyon ay patuloy na tumataas nang tumataas sa loob ng ilang oras at hindi tumataas o bumababa kung kailan ito dapat, ang hinala ay muling tumutukoy sa isang memory leak o hindi mahusay na pamamahala ng mga internal buffer.

smem: pag-iiba-iba ng shared memory at aktwal na paggamit ng bawat proseso

Ang mga tool tulad ng top, htop, o pmap ay binibilang ang lahat ng memory na tinutukoy ng isang proseso, ngunit hindi nila malinaw na pinaghihiwalay ang memory na tunay na eksklusibo sa prosesong iyon mula sa memory na ibinahagi sa iba (halimbawa, mga shared library). Doon pumapasok ang [mga sumusunod]. smem, isang partikular na utility upang makapagbigay ng mas tumpak na view.

Ang malaking bentahe ng smem ay kinakalkula nito ang mga sukatan tulad ng USS (Natatanging Laki ng Set), PSS (Proporsyonal na Laki ng Set) at RSSna nagbibigay-daan sa mas mahusay na pag-unawa sa aktwal na paggamit ng memorya sa bawat proseso: kung gaano karaming memorya ang sarili lamang nito at kung gaano karami ang ibinabahagi sa iba pang mga prosesong naglo-load ng parehong mga library o nagbabahagi ng mga pahina.

Ilan sa mga pinaka-kaugnay na sukatan na makikita mo sa output ng smem ay:

- USS (Natatanging Laki ng Set): memorya na ginagamit lamang ng prosesong iyon; kung mawala ang proseso, ang bahaging iyon ng memorya ay ganap na mapapalaya.
- PSS (Proporsyonal na Laki ng Set): ipinamamahagi ang ibinahaging memorya sa lahat ng mga prosesong gumagamit nito, na nag-aalok ng medyo patas na proporsyonal na pagtingin sa aktwal na bakas ng paa.
- RSS (Laki ng Set ng Residente): Memorya ng residente, tulad ng sa ibang mga kagamitan, ngunit ipinakita kasama ng mga nasa itaas para sa paghahambing.

Kapag nagpapatakbo ng isang bagay tulad ng smem -k Makakakuha ka ng talahanayan na may PID, user, command, at mga kolum na ito ng paggamit ng memorya. Ang interesante, pagdating sa mga memory leak, ay ang pangunahing pagtuunan ng pansin ang USSdahil ipinapakita nito ang sariling memorya ng application, kung saan karaniwang lumalabas ang mga pinakamalalang tagas.

Kung hahayaan mong tumatakbo ang smem nang pana-panahon (o isasama ito sa mga monitoring script) at makikita mo na ang USS ng isang partikular na proseso Patuloy itong tumataas sa paglipas ng panahonKahit na hindi lumaki ang load nito, ang pag-uugali ay lubos na nagpapahiwatig ng isang memory leak sa iisang bahagi ng memorya ng prosesong iyon.

memleax: awtomatikong pagtuklas ng tagas sa mga tumatakbong proseso

Kapag natukoy mo na ang isang proseso na tila naglalabas ng memorya at gusto mo itong gawin nang mas maaga nang hindi ito muling nire-restart, isang napaka-kapaki-pakinabang na tool ang... memleaxAng pinakamalaking kalakasan nito ay Pinapayagan ka nitong makita ang mga tagas ng memorya nang real time sa isang prosesong tumatakbo na., nang hindi na kailangang i-recompile ito o ilunsad muli gamit ang isang espesyal na utos.

Ang memleax ay pangunahing ipinamamahagi sa anyo ng mga pakete. .rpm y .debIto ay makukuha sa ilang mga repositoryo, tulad ng mga para sa Arch Linux at FreeBSD. Sa mga sistemang nakabatay sa Debian, ang isang karaniwang paraan upang i-install ito ay ang pag-download ng pakete mula sa opisyal nitong repositoryo sa GitHub at pagkatapos ay gamitin ang dpkg Para mai-install ito, ayusin ang mga dependency gamit ang iyong package manager.

Kapag na-install na, maaari mong ikabit ang memleax sa isang proseso gamit ang:

sudo memleax -p

Mula sa puntong iyon, hinaharangan ng memleax ang mga tawag sa paglalaan ng memorya (tulad ng malloc) at itinatala ang mga address at laki na inilalaan ng proseso. Kapag natukoy nito na ang isang alokasyon ay hindi nailabas nang tama, tahasang minamarkahan ito bilang isang memory leak, na nagpapahiwatig ng laki ng block at ang responsableng address.

Ang karaniwang output ay nagpapakita ng mga linya ng estilo malloc(128) = 0x... sinusundan, kapag may problema, ng mga mensaheng nagpapahiwatig ng isang bagay tulad ng natukoy ang pagtagas ng memorya para sa isang partikular na bloke. Ang impormasyong ito ay lubhang kapaki-pakinabang dahil sinasabi nito sa iyo na, habang ang proseso ay aktibo at gumagana pa rin, may mga bloke na nagiging ulila.

Ang memleax ay lalong kaakit-akit para sa mga kapaligiran ng produksyon o pre-production kung saan Hindi mo kayang i-restart ang serbisyo gamit ang isang debugger o gamit ang Valgrind mula sa simula, ngunit kailangan mong maunawaan kung ano ang nangyayari sa loob pagdating sa dynamic memory management.

Paggamit ng gdb upang masusing suriin ang memorya ng isang proseso

Kung kailangan mo ng mas detalyadong detalye at kayang bayaran ang mas mapanghimasok na pag-debug, ang GNU Debugger (gdb) Ito ang iyong kakampi. Ito ay isang napakalakas na kasangkapan na nagbibigay-daan sa iyo upang sumali sa isang umiiral na prosesosiyasatin ang mga variable, tawagin ang mga stack, at siyempre, ang heap state.

Para magsimula, i-install mo ang gdb mula sa mga repository ng iyong distribution (halimbawa, gamit ang sudo apt install gdb (sa Debian/Ubuntu) at pagkatapos ay ilakip ito sa isang proseso gamit ang:

sudo gdb -p

Kapag nasa loob na ng gdb session, maaari kang gumamit ng iba't ibang command na may kaugnayan sa heap. Sa ilang mga kapaligiran, ang command ay direktang magagamit. heap (o mga extension na nagbibigay nito) upang ilista ang mga dynamic memory block na kasalukuyang ginagamit, kasama ang kanilang mga address at laki. Ang output ay nagpapakita ng parang isang listahan ng mga memory chunks, bawat isa ay may address at laki, na minarkahan bilang sa paggamit.

Bukod pa rito, mula sa gdb maaari mong gamitin ang mga libc function tulad ng malloc_stats() sa pamamagitan ng:

(gdb) call malloc_stats()

Ang ganitong uri ng tawag ay nagbibigay sa iyo ng buod ng estado ng memory allocator: kung gaano karaming memorya ang naitalaga, kung paano hinati ang heap, atbp. Ito ay isang medyo mabilis na paraan upang makita kung ang memoryang inilaan ng proseso ay lumalaki nang hindi mapigilan.

Isa pang mabisang paraan ay ang paglalagay mga breakpoint sa mga function tulad ng malloc o free upang obserbahan sa totoong oras kung paano kumikilos ang code: kung gaano karaming beses ito nagrereserba, sa anong mga punto ito naglalabas, kung aling mga code path ang gumagawa ng maraming alokasyon ngunit kakaunti ang mga libreng code... Bagama't nangangailangan ito ng higit na kadalubhasaan sa pag-debug, ito ay isang direktang paraan upang mahanap ang eksaktong pinagmumulan ng mga tagas.

Valgrind: ang klasikong memory profiler sa Linux

Kung pinag-uusapan natin ang pagtuklas ng memory leak sa mga kapaligirang Linux, imposibleng hindi banggitin valgrindHigit pa sa isang kagamitan, ang Valgrind ay isang balangkas ng pag-debug at pag-profile na kinabibilangan ng ilang mga modyul, ang pinakakilala at ginagamit ay ang Memcheck, na partikular na idinisenyo upang matukoy ang mga problema sa memorya.

Gumagana ang Memcheck sa pamamagitan ng pagpapatakbo ng iyong programa sa loob ng isang uri ng virtual machine na Hinaharang at sinusubaybayan nito ang lahat ng operasyon na may kaugnayan sa memorya.: mga alokasyon, paglabas, pag-access sa address, atbp. Bukod pa rito, pinapalitan nito ang karaniwang memory allocator ng C ng sarili nitong, na nagpapakilala ng mga karagdagang proteksyon sa paligid ng mga nakareserbang bloke upang matukoy ang mga out-of-range na access.

Kabilang sa mga uri ng error na maaaring matukoy ng Memcheck ay: Hindi pa nasimulang paggamit ng memorya, binabasa/sinusulat pagkatapos ilabas ang memorya, ilegal na pag-access sa mga lugar ng memorya na hindi kabilang sa programa at, siyempre, iba't ibang uri ng pagtagas ng memorya (mga bloke na tiyak na nawala, posibleng nawala, maaabot pa rin, atbp.).

Ang pangunahing gamit nito ay medyo simple. Kino-compile mo ang iyong programa gamit ang mga debugging symbol (halimbawa, gamit ang -g o -gstabs) at pagkatapos ay patakbuhin mo ito sa ilalim ng Valgrind na may katulad na:

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

Sa isang programang mahusay na namamahala sa memorya, ang output ng Memcheck ay magpapakita ng isang buod ng mga error na walang insidenteIbig sabihin, walang ilegal na pagbasa, walang out-of-range na pagsulat, at walang heap bytes na ginagamit kapag lumabas ang programa. Kadalasan, iyon ang unang hakbang: pag-verify ng isang "malinis" na kaso upang makita kung ano ang hitsura ng isang malinis na pagpapatupad.

Kung sinasadya mong magpakilala ng malloc nang walang kaukulang libreo anumang iba pang leak pattern, at patakbuhin mo ulit ang binary gamit ang Valgrind, makikita mo sa output ang isang BUOD NG HEAP na nagpapahiwatig kung gaano karaming memorya ang nananatiling "ginagamit" pagkatapos magsara ang application. Sa ilalim ng seksyon BUOD NG PAGTAAS Ang mga linyang tulad ng "tiyak na nawala" ay lilitaw kasama ng mga byte at block na hindi pa nailalabas.

Bukod pa rito, sasabihin sa iyo ng Memcheck nang eksakto kung saan naganap ang alokasyon na naging sanhi ng tagasMakakakita ka ng trace ng tawag na may mga function, source file, at numero ng linya. Halimbawa, maaaring ipakita nito na ang isang malloc sa isang partikular na linya ng iyong file .c Lumikha ito ng isang bloke na hindi pa kailanman nailalabas, na agad na nagbibigay-liwanag sa pinagmumulan ng problema.

Ang Valgrind ay napakaepektibo rin sa pagtukoy ng iba pang mga klasikong error: halimbawa, mga ilegal na sulatin sa alaala (tulad ng pagsulat sa address na 0 o sa labas ng mga hangganan ng isang array), paggamit ng mga hindi pa nasisimulang baryabol (pagpapakita ng mga mensahe tulad ng "Ang kondisyonal na pagtalon o paglipat ay depende sa hindi pa nasisimulang halaga(mga)") o mga maling paglabas (paano gawin free sa isang pointer na hindi nagmumula sa malloc, o bitawan ang parehong bloke nang dalawang beses).

Sa lahat ng mga kasong ito, idinedetalye ng ulat ng Memcheck kung saan naganap ang maling pag-access o ilegal na libreng pag-access, kung saang function nagmula ito, at kung saang bahagi ng code nilikha ang variable na iyon o nakalaan ang memorya na iyon, na ginagawa itong halos kailangang-kailangan na tool para sa upang lubusang i-debug ang pamamahala ng memorya sa C at C++.

Iba pang mga memory profiler: gperftools, Massif, at iba pa

Bagama't ang Valgrind-Memcheck ang kadalasang unang pagpipilian, may iba pang mga tool sa pag-profile na mahusay na nakakatulong sa pagsusuri ng memory leak at usage pattern. Isa na rito ang gperftools (dating Google Performance Tools), na kinabibilangan ng profiler ng tambak may kakayahang magtala ng paggamit ng memorya sa paglipas ng panahon at makabuo ng mga visual na ulat (halimbawa, gamit ang pprof) na nagpapakita kung aling mga bahagi ng code ang nagrereserba ng mas maraming memorya.

Isa pang kagamitan mula sa pamilyang Valgrind ay Malaki at mabigat, partikular na nakatuon sa pag-profile ng memorya ng heapSa halip na magtuon lamang sa mga error, sinusukat ng Massif ang laki ng heap sa buong pagpapatupad at bumubuo ng data na maaari mong mailarawan upang maunawaan kung aling mga yugto ng memorya ng iyong programa ang pinakamalaki ang paglaki at kung aling mga istruktura o function ang responsable.

Sa pangkalahatan, ang mga profiler na ito ay gumagana sa pamamagitan ng pag-intercept sa mga operasyon ng memorya sa paraang katulad ng sa Valgrind o sa pamamagitan ng mga instrumentation library, at Itinatala nila ang mga detalyadong istatistika sa mga alokasyon at paglabasPanghuli, binibigyan ka nila ng mga ulat na kinabibilangan ng bilang ng mga alokasyon, ang kabuuang laki na nakalaan, mga partikular na lokasyon sa code kung saan ginawa ang pinakamabigat na reserbasyon, at, siyempre, mga bloke na hindi kailanman inilalabas.

Ang karaniwang daloy ng trabaho ay binubuo ng patakbuhin ang programa sa ilalim ng profiler (Sa isang kapaligirang malapit sa produksyon hangga't maaari, ngunit kontrolado), kopyahin ang workload o use case na pinaghihinalaan mong sanhi ng leak at pagkatapos ay suriin ang mga nabuong ulat gamit ang mga graphical o command-line tool. Sa ganitong paraan, makikita mo sa isang sulyap kung aling mga code path ang nagdudulot ng hindi kontroladong paggamit ng memorya.

Mga proaktibong estratehiya: pagsubok ng load, mga limitasyon, at mga pinakamahusay na kasanayan

Ang lahat ng nabanggit ay nakakatulong upang matukoy ang mga problema kapag umiiral na ang mga ito, ngunit ang mainam na estratehiya ay maiwasan ang mga tagas na makarating sa produksyon O kahit man lang mahuli sila sa lalong madaling panahon. Para magawa ito, ipinapayong pagsamahin ang ilang taktika na may kaugnayan sa pagsubok, pag-configure ng sistema, at kalidad ng code.

Una sa lahat, makatuwiran na gawin ito pagsubok ng karga at stress sa mga kapaligirang pre-production na makatotohanan hangga't maaari. Mga kagamitan tulad ng Apache JMeter, Locust, stress Nagbibigay-daan sa iyo ang mga katulad na tool na gayahin ang mga sabay-sabay na user, masinsinang mga kahilingan, o matagalang mga senaryo. Sa mga pagsubok na ito, dapat mong maingat na subaybayan ang mga sukatan ng memorya (RSS, heap, atbp.) upang makita kung mayroong anumang mga isyu. mabagal ngunit patuloy na paglago.

Kasabay nito, ipinapayong subaybayan hindi lamang ang mga hilaw na sukatan, kundi pati na rin mga kaganapan sa sistema tulad ng mga nasa OOM KillerMaaaring pagsama-samahin ng mga platform ng pagsubaybay sa log at observability ang impormasyong ito at alertuhan ka kapag, halimbawa, naiipon ang mga kaganapan sa OOM sa isang partikular na host, na karaniwang tumutukoy sa mga prosesong hindi gumagana nang maayos o kakulangan ng mga mapagkukunan.

Sa antas ng pagsasaayos ng sistema, nag-aalok ang Linux ng mga mekanismo para sa limitahan ang epekto ng isang prosesong "lumalabas na sa kontrol". Halimbawa, kasama ang ulimit Maaari kang magpataw ng mga limitasyon sa memorya sa mga prosesong inilunsad ng isang partikular na gumagamit, na naglilimita sa laki ng kanilang virtual memory. Isang bagay tulad ng ulimit -v <kilobytes> Pipigilan nito ang isang serbisyo na ubusin ang lahat ng RAM ng host.

Para sa mas advanced na mga senaryo, ang mga cgroup (mga control group) Pinapayagan ka nitong ihiwalay at limitahan ang pagkonsumo ng mga mapagkukunan (CPU, memorya, I/O, atbp.) ayon sa mga grupo ng mga proseso. Maaari kang lumikha ng isang cgroup na may isang tiyak na limitasyon sa memorya at magtalaga ng isang serbisyo dito, upang kung mayroong memory leak, ang pinsala ay mapigilan. nakapaloob sa grupong iyon at hindi nakakaapekto sa buong sistema.

Panghuli, sa usapin ng pag-unlad, nananatili ang pinakamahusay na depensa Sumulat ng code na mahusay na namamahala sa memorya mula sa simula.Sa C/C++, ipinahihiwatig nito ang pagiging mahigpit sa bawat malloc/new at kaukulang ito free/delete, gumamit ng mga pattern ng RAII, mga smart pointer (tulad ng std::shared_ptr, std::unique_ptrat iwasan ang pag-iingat ng mga hindi kinakailangang sanggunian. Maaari ka ring kumonsulta sa isang Tutorial sa kalawang Para sa mga alternatibong ligtas sa memorya. Sa mga wikang may mga garbage collector (Java, C#, Go, Python, JavaScript, atbp.) madali ring magdulot ng pseudo-leaks kung magpapanatili ka ng mga live na reference sa mga bagay na hindi mo na kailangan.

Mga tool ng estatikong pagsusuri tulad ng cppcheck, SonarQube Ang mga kagamitan at pamamaraang ito ay nakakatulong sa pagtuklas ng mga kahina-hinalang pattern ng code habang binubuo. Idagdag pa rito ang maingat na pagsusuri ng code, mga unit test na nagpapatunay sa pag-uugali sa ilalim ng load, at mga regular na pagpapatakbo ng Valgrind o iba pang profiler sa mga CI environment, at ang posibilidad na ang isang malubhang kahinaan ay umabot sa produksyon ay lubhang nababawasan.

Sa huli, ang pagpapanatili ng kontrol sa mga pagtagas ng memorya sa Linux ay kinabibilangan ng pagsasama-sama ng patuloy na pagsubaybay, makapangyarihang mga kagamitan sa pag-diagnose, at mahusay na mga kasanayan sa programmingGamit ang top, htop, /proc, pmap, at smem, mahahanap mo ang mga kahina-hinalang proseso; gamit ang memleax at gdb, maaari kang magsagawa ng mga live na inspeksyon; gamit ang Valgrind, gperftools, o Massif, maaari mong lubusang i-debug at i-profile; at gamit ang load testing, mga limitasyon ng system, at mahusay na pagkakasulat ng code, mapipigilan mo ang pagsabog ng problema sa pinakamasamang posibleng sandali.