Debugging memori di Linux: alat dan teknik utama

Informatec Digital » Sumber daya » Debugging memori di Linux: alat dan teknik utama

Ketika terjadi kesalahan pada server Linux, penyebabnya seringkali terletak pada bagaimana memori digunakan dan alat debugging , tetapi sampai Anda tahu apa yang harus dicari, semuanya tampak seperti kekacauan angka dan proses yang membingungkan. Memahami apa yang terjadi di RAM, bagaimana program Anda berperilaku, dan bagaimana cara menangkap dump memori adalah kunci untuk menghindari pemecahan masalah secara membabi buta setiap kali muncul kesalahan aneh atau kesalahan segmentasi.

Pada artikel ini, kita akan membahas secara detail dan lugas cara memeriksa memori, men-debug program, dan menganalisis dump di Linux menggunakan perintah sistem (free, vmstat, /proc/meminfo), debugger seperti GDB, penganalisis memori seperti Valgrind, dan utilitas khusus untuk .NET dan lingkungan lainnya. Tujuannya adalah agar Anda memiliki bekal praktis untuk mendiagnosis masalah memori dan CPU di server dan lingkungan pengembangan profesional.

Gambaran Umum: Memori di Linux dan mengapa Anda tidak perlu terlalu terpaku pada 100%

Pada server Linux, RAM bertindak sebagai penyimpanan cepat untuk data dan kode yang perlu digunakan kembali oleh sistem dalam waktu dekat. Mengakses RAM jauh lebih cepat daripada mengakses disk, sehingga kernel memanfaatkan hal ini untuk menggunakannya sebagai cache untuk file, buffer, dan halaman memori yang mungkin dibutuhkan lagi dalam waktu singkat.

Dalam konteks server web yang menjalankan Apache atau Nginx , atau server basis data seperti MySQL atau MariaDB, mengetahui berapa banyak memori yang digunakan, berapa banyak yang tersedia, dan berapa banyak yang di-cache sangat penting untuk menentukan ukuran layanan dengan benar dan memahami namespace dan cgroup . Bahkan, alat optimasi seperti MySQLTuner menggunakan data ini (dan informasi lainnya) untuk menyarankan pengaturan buffer, cache, dan koneksi.

Penting untuk memahami konsep yang sering mengejutkan orang pada awalnya: RAM dirancang untuk digunakan . Melihat penggunaan 90% atau bahkan 100% belum tentu menjadi masalah; Linux mengisi RAM dengan cache disk untuk mempercepat sistem. Yang benar-benar mengkhawatirkan adalah ketika Anda mulai mendapatkan kesalahan kehabisan memori (out-of-memory) , proses yang mengalami crash dengan pesan OOM (Out Of Memory), atau layanan yang membeku, bukan hanya ketika grafik menunjukkan "penggunaan tinggi."

Melakukan optimasi agresif hanya masuk akal jika Anda melihat server menjadi tidak stabil, lambat, atau menghentikan layanan karena penggunaan memori yang berlebihan, atau jika Anda tahu bahwa akan ada lonjakan lalu lintas yang dapat membebani sumber daya yang ada.

Perintah dasar untuk memeriksa memori di Linux

Langkah pertama dalam mengatasi masalah memori adalah memahami total RAM Anda dan bagaimana pembagiannya antara memori yang digunakan, memori bebas, cache, dan swap. Linux menawarkan beberapa utilitas untuk ini, masing-masing dengan tingkat detail yang berbeda.

Perintah bebas: ikhtisar singkat tentang RAM dan swap

Perintah yang paling umum digunakan untuk melihat sekilas adalah gratis, khususnya dengan parameter -h Untuk menampilkan ukuran dalam format yang mudah dibaca: Untuk informasi lebih lanjut tentang interpretasi dan pengoptimalan metrik ini, lihat mengoptimalkan statistik memori.

free -h

Output tipikal akan menunjukkan kepada Anda, dalam beberapa baris, total memori yang digunakan, memori bebas, memori bersama, memori buffer, dan memori cache , baik untuk RAM maupun ruang swap. Anda akan melihat sesuatu seperti ini:

Total memori terpakai, bebas, bersama, buffer, di-cache: 2.0G 1.5G 470M 300M 0B 414M -/+ buffer/cache: 1.1G 885M Swap: 0B 0B 0B

Line -/+ buffers/cache Ini sangat berguna karena menunjukkan memori yang sebenarnya digunakan oleh proses (tidak termasuk buffer/cache) dan memori yang berpotensi tersedia untuk aplikasi baru. Banyak orang melihat sedikit "memori bebas" pada baris pertama dan merasa khawatir, padahal kenyataannya sebagian besar hanya berupa cache dan dapat digunakan. digunakan kembali tanpa drama.

vmstat: memori aktif, memori idle, dan metrik sistem

Saat Anda membutuhkan sesuatu yang lebih detail, vmstat memberikan gambaran sistem yang lebih teknis. Dengan:

vmstat -s -S M

Anda akan mendapatkan daftar yang berisi total memori, memori terpakai, memori bebas, memori aktif, memori tidak aktif, buffer, memori swap, dll. Misalnya:

Memori total 2048 M, memori terpakai 1582 M, memori aktif 1124 M, memori tidak aktif 406 M, memori bebas 465 M, memori buffer 0 M, cache swap 407 M, total swap 0 M, swap terpakai 0 M, swap bebas 0 M

Konsep memori idle sangat menarik: ini adalah memori yang dianggap sedang digunakan tetapi tidak terkait dengan proses aktif, sehingga untuk tujuan praktisnya berperilaku seperti memori yang dapat dipulihkan oleh sistem . Hal ini membantu menjelaskan mengapa Linux mungkin tampak "menggunakan semua ruang" tetapi, pada kenyataannya, memiliki ruang untuk dibebaskan saat dibutuhkan.

/proc/meminfo: detail kernel mentah

Jika Anda menginginkan semua detail yang ditangani kernel, Anda selalu dapat melihat file /proc/meminfo :

cat /proc/meminfo

File ini berisi puluhan field yang terkait dengan manajemen memori internal : total memori, memori bebas, buffer, cache, slab, hugepages, memori yang tersedia, dll. File ini sangat berguna untuk alat otomatis dan skrip pemantauan, meskipun membacanya secara langsung agak kurang ramah pengguna dibandingkan dengan `free` atau `vmstat` dan membutuhkan pemahaman menyeluruh tentang arti setiap field.

Panel kontrol dan “realitas paralelnya”

Jika Anda mengelola server dengan panel kontrol seperti cPanel, Plesk, VestaCP, atau Webmin , Anda akan melihat bahwa panel-panel tersebut biasanya menampilkan grafik memori yang digunakan, memori bebas, dan memori yang di-cache melalui antarmuka web. Data ini memang praktis, tetapi perlu diingat bahwa data tersebut diperbarui secara berkala dan terkadang tidak mencerminkan status waktu nyata yang sebenarnya. Untuk diagnostik dan penyempurnaan yang menyeluruh, selalu lebih baik menggunakan terminal dan perintah bawaannya.

Melakukan debugging proses dan memori dengan alat sistem.

Setelah mengetahui berapa banyak memori yang tersedia dan bagaimana penggunaannya secara umum, langkah selanjutnya adalah menemukan proses mana yang mengonsumsi sumber daya secara tidak normal dan menganalisis perilakunya. Di sinilah utilitas klasik seperti ps, top, htop, strace, dan ltrace berperan, serta perintah jaringan dan disk yang membantu menghilangkan hambatan.

ps, top dan htop: analisis mendalam terhadap proses dan CPU

Perintah `ps` menampilkan proses yang sedang aktif. Dikombinasikan dengan filter dan pengurutan, perintah ini memungkinkan Anda untuk dengan cepat menemukan proses mana yang memakan CPU.

ps aux --sort=-%cpu | head

Ini menunjukkan proses yang diurutkan berdasarkan persentase penggunaan CPU , beserta penggunaan memori, pengguna, dan perintah. Ini ideal sebagai gambaran singkat untuk mengidentifikasi penyebab utama ketika server kekurangan sumber daya; menguasai terminal membantu Anda bertindak cepat.

Di sisi lain, `top` dan variannya yang lebih visual `htop` menawarkan tampilan waktu nyata dari proses, penggunaan CPU, penggunaan memori, status (R, S, D, dll.), dan rata-rata beban . Memulai `top` dengan:

top -o %CPU

Anda dapat fokus pada proses mana yang paling banyak menggunakan CPU. Di luar angka-angka tersebut, penting untuk mencari pola :

• Proses dalam keadaan R (berjalan) yang tetap tersangkut di bagian atas untuk waktu yang lama.
• Perubahan mendadak pada rata-rata beban yang menunjukkan lonjakan beban baru-baru ini.
• Alokasi CPU dalam %us, %sy dan %wa (waktu pengguna, waktu sistem, dan waktu tunggu I/O).
• Jika proses yang bermasalah adalah layanan sistem, pengguna tertentu, atau daemon.
• Jika konsumsi stabil atau Angkanya naik turun secara tersentak-sentak., yang mungkin mengindikasikan tugas batch atau lalu lintas yang tidak teratur.

Nilai %wa (I/O wait) yang sangat tinggi merupakan petunjuk bahwa hambatan mungkin bukan terletak pada CPU, tetapi pada subsistem disk atau penyimpanan.

Meninjau thread dalam suatu proses: top -H

Untuk aplikasi multithread (Java, Python, Node, dll.), tidak cukup hanya mengetahui proses mana yang mengonsumsi CPU; Anda perlu melihat thread spesifik mana yang berjalan di luar kendali . Dengan:

top -H -p PID

Anda mendapatkan detail setiap thread dalam proses tersebut. Jika salah satu thread menunjukkan penggunaan 100% dan yang lainnya menganggur, kemungkinan ada loop tak terbatas, masalah pemblokiran yang aneh, atau bagian kritis yang dirancang dengan buruk di bagian kode tersebut.

Prioritas proses: nice dan renice

Jika suatu proses yang membutuhkan banyak sumber daya memang sah tetapi Anda ingin mencegahnya membebani sistem secara berlebihan, Anda dapat menyesuaikan prioritasnya (niceness) . Perintah `nice` dan `renice` memungkinkan Anda untuk memulai proses dengan prioritas lebih rendah atau menyesuaikan prioritas proses yang sudah ada, sehingga kernel mengalokasikan lebih sedikit waktu CPU untuk proses tersebut dibandingkan dengan tugas-tugas penting lainnya.

Perintah penting lainnya: pidof, kill, strace, dan ltrace

Ketika sistem berada di bawah tekanan, akan sangat berguna untuk dapat dengan cepat menemukan dan mengendalikan proses:

• pidof: memperoleh PID suatu proses dari namanya, sangat cocok untuk skrip atau intervensi cepat.
• membunuh: mengirimkan sinyal ke proses (TERM, KILL, dll.), baik untuk mematikan proses secara teratur atau untuk mempersingkat pekerjaan jika proses tersebut mengalami kemacetan.
• jejak: menunjukkan panggilan sistem yang menjalankan suatu proses; ideal untuk melihat apa yang sedang dikerjakan (pembacaan disk, soket, dll.).
• jejakMirip dengan strace, tetapi berfokus pada panggilan ke toko buku, berguna untuk mendebug masalah penggunaan API bersama.

Alat-alat ini tidak hanya berguna untuk mencari kebocoran memori atau kerusakan, tetapi juga banyak digunakan dalam keamanan siber, analisis forensik, dan debugging perilaku biner yang aneh.

Perintah untuk file dan disk: lsof, df, du, locate

Saat Anda mencurigai ada yang salah dengan penyimpanan (misalnya, banyak file yang terbuka atau disk penuh), perintah lain akan berperan:

• lsof: daftar berkas yang dibuka oleh suatu proses, berguna untuk menemukan kebocoran deskriptor atau file yang mencegah sistem file dilepas (unmount).
• df: menunjukkan ruang disk kosong dengan sistem file, penting untuk mengesampingkan 100% disk yang menyebabkan kegagalan berantai.
• du: menghitung ruang yang digunakan oleh direktori, sangat berguna untuk menemukan folder yang ukurannya terus bertambah tanpa terkendali (log, cadangan, dll.).
• menemukan: memungkinkan Anda mencari file berdasarkan nama menggunakan basis data terindeks, lebih cepat daripada fungsi find dalam banyak situasi.

Perintah jaringan untuk diagnostik: nc, netstat, ab, tcpdump, wireshark, nmap

Seringkali, masalah kinerja dan memori disertai dengan hambatan jaringan atau serangan , jadi ada baiknya memiliki beberapa alat dasar yang siap digunakan:

• nc (netcat): sebuah alat serbaguna layaknya pisau Swiss Army dalam dunia jaringan; membuka soket, mengirim dan menerima data, memungkinkan pengujian layanan, bahkan terowongan improvisasi.
• netstatMenampilkan koneksi aktif, soket yang mendengarkan, dan statistik jaringan, berguna untuk melihat apakah ada banyak koneksi ke port tertentu.
• ab (Apache Benchmark): Menghasilkan beban pada server web untuk mengukur waktu respons dan perilaku di bawah tekanan.
• tcpdump dan WiresharkMereka menangkap paket jaringan untuk menganalisis lalu lintas secara mendalamtcpdump di konsol, Wireshark dengan antarmuka grafis.
• nmapPemindai port dan layanan, banyak digunakan untuk audit keamanan dan pemeriksaan. permukaan paparan server.

GDB: debugger klasik untuk kesalahan memori dan kerusakan saat runtime.

Ketika sebuah program Linux mengalami crash dengan kesalahan segmentasi atau kesalahan besar lainnya, langkah logis selanjutnya adalah menggunakan debugger yang baik. Alat andalan di dunia GNU adalah GDB (GNU Debugger) , yang memungkinkan Anda untuk memeriksa keadaan internal program, menghentikannya di mana pun Anda inginkan, melihat variabel dan penggunaan memori, serta mengikuti eksekusi langkah demi langkah.

GDB awalnya dirancang untuk program C dan C++, tetapi telah diperluas ke bahasa lain seperti Rust dan bahkan Assembly , serta untuk menangani jalur pustaka seperti LD_LIBRARY_PATH . GDB sangat penting dalam pengembangan perangkat lunak, tetapi juga dalam keamanan siber, di mana ia digunakan untuk rekayasa balik, menemukan kerentanan, dan mengembangkan atau men-debug eksploitasi.

Mulai GDB dan jalankan sebuah program.

Untuk menggunakan GDB dengan file executable, disarankan untuk mengkompilasi program tersebut dengan informasi debugging menggunakan opsi -g dari GCC:

gcc -g -Wall programa.c -o programa

Kemudian Anda menjalankannya dengan:

gdb programa

Di dalam GDB, program tersebut belum berjalan. Anda dapat memulainya dengan:

• menjalankanJalankan program dengan argumen apa pun yang Anda inginkan.
• awal: sama seperti run, tetapi berhenti di awal fungsi main.

Jika Anda memiliki file yang dapat dieksekusi bernama, misalnya, Suma Dan jika Anda ingin melihat bagaimana ia memproses argumennya, Anda dapat masuk ke GDB dan kemudian menggunakan run 3 5 untuk menjalankannya dengan parameter tersebut dari debugger.

Breakpoint dan watchpoint: menghentikan sementara program di tempat yang dibutuhkan.

Breakpoint adalah titik berhenti dalam kode sumber: ketika eksekusi mencapai titik tersebut, program akan berhenti sementara dan Anda dapat memeriksa keadaan internalnya. Di GDB, breakpoint didefinisikan dengan perintah :

break lugar

di mana “lokasi” dapat berupa nama fungsi, nomor baris, atau file:baris . Contoh tipikalnya adalah:

break main

sehingga GDB berhenti tepat saat memasuki fungsi utama. Ketika program berhenti di breakpoint, Anda dapat melihat kode dengan l (list), memeriksa variabel, dan menavigasi tumpukan panggilan.

Watchpoint bekerja secara berbeda: alih-alih berhenti pada titik tertentu dalam kode, watchpoint berhenti ketika nilai suatu variabel berubah . Watchpoint sangat berguna untuk mendeteksi kerusakan memori atau modifikasi tak terduga pada struktur penting tanpa harus membanjiri kode dengan pernyataan print.

Kontrol alur yang presisi: langkah, selanjutnya, lanjutkan, selesai

Setelah program dihentikan pada titik henti (breakpoint), Anda memiliki beberapa cara untuk melanjutkan:

• langkah: mengeksekusi baris berikut dan memasuki fungsi yang dipanggil.
• berikutnya: mengeksekusi baris berikut tanpa memasuki fungsi (menjalankan semuanya "sekaligus").
• terus: melanjutkan eksekusi hingga titik henti berikutnya atau hingga program berakhir.
• menyelesaikan: berlanjut hingga fungsi saat ini selesai dijalankan dan kembali ke titik awal pemanggilannya.

Ini memungkinkan Anda untuk memeriksa kode yang mencurigakan langkah demi langkah, tanpa harus "menelan" seluruh program. Trik yang berguna: di GDB, Menekan Enter akan mengulangi perintah terakhir.ideal untuk membuat banyak next o step diikuti dengan lebih sedikit mengetik.

Tumpukan panggilan dan bingkai: lihat bagaimana kita sampai di sini

Untuk memahami mengapa kegagalan terjadi pada titik tertentu, sangat penting untuk melihat fungsi mana yang dipanggil sebelum titik tersebut. Struktur yang menyimpan informasi ini adalah tumpukan panggilan (call stack ). GDB menawarkan beberapa perintah untuk mengelolanya:

• bt (backtrace): menampilkan tumpukan lengkap, dengan daftar fungsi bersarang dan nomor frame.
• up: bergerak naik satu tingkat dalam tumpukan, ke titik yang memanggil fungsi saat ini.
• turun: turun satu tingkat, ke fungsi yang sedang berjalan.
• fr (frame): menampilkan frame saat ini atau memungkinkan Anda untuk beralih ke frame lain dengan menunjukkan nomornya.

Ini memungkinkan Anda untuk memposisikan diri di berbagai tingkatan panggilan (misalnya, melompat dari fungsi internal ke fungsi utama ) dan melihat bagaimana variabel berada di setiap tempat.

Interaksi dengan memori: set, return, backtrace yx

Salah satu keunggulan utama GDB adalah kemampuannya untuk membaca dan memodifikasi memori saat program dihentikan. Beberapa operasi yang berguna meliputi:

• set: mengubah nilai variabel selama eksekusi, ideal untuk skenario pengujian tanpa kompilasi ulang.
• nilai kembalian: memaksa fungsi saat ini untuk mengembalikan nilai yang ditentukan, tanpa melanjutkan eksekusi kodenya.
• mundur: sudah terlihat, untuk menampilkan tumpukan panggilan saat ini.
• x: memeriksa isi memori mulai dari suatu alamat, dengan berbagai format dan ukuran (misalnya, x/4xw 0x7fffffffe000 (untuk melihat empat kata dalam format heksadesimal).

Dengan opsi-opsi ini, Anda dapat mereplikasi kesalahan, memeriksa apakah input berbahaya menyebabkan overflow, atau memeriksa struktur data kompleks pada stack atau heap.

Debugging pasca-mortem dengan core dump.

Linux dapat menghasilkan file core ketika suatu proses mengalami crash karena sinyal seperti SIGSEGV. File ini berisi status lengkap proses pada saat crash: memori, register, stack, dll. Untuk mengaktifkannya dalam sebuah sesi, cukup lakukan hal berikut:

ulimit -c unlimited

Untuk mengaktifkannya secara permanen bagi pengguna, Anda dapat mengedit /etc/security/limits.conf dan menambahkan baris seperti ini:

* soft core unlimited

Ketika sebuah program mengalami crash, program tersebut akan menghasilkan sebuah file yang biasanya bernama "core" di direktori kerja. Anda kemudian dapat menganalisisnya dengan GDB seperti ini:

gdb ejecutable core

Hal ini memungkinkan Anda untuk melakukan analisis post-mortem seolah-olah program tersebut masih berjalan, ideal ketika kegagalan tidak mudah direproduksi sesuai permintaan.

Valgrind: berburu kebocoran memori dan kesalahan

Untuk banyak masalah memori di C/C++ (dan bahasa serupa), GDB tidak memadai karena tidak dirancang untuk secara otomatis mendeteksi pembacaan ilegal, kebocoran memori, atau penggunaan memori yang belum diinisialisasi . Di sinilah Valgrind berperan — sebuah sistem debugging dan profiling yang meniru prosesor dan memantau setiap akses memori.

Valgrind menyertakan beberapa alat, tetapi yang paling banyak digunakan adalah Memcheck , yang menggantikan pengelola memori standar C dengan pengelola memorinya sendiri, yang memiliki zona perlindungan di sekitar blok yang dialokasikan . Hal ini memungkinkan Valgrind untuk mendeteksi:

• Penggunaan memori yang belum diinisialisasi (variabel yang digunakan sebelum diberi nilai).
• Membaca/menulis setelah melakukan kegiatan bebas (dapat digunakan setelah masa berlaku habis).
• Akses di luar batas dari sebuah blok memori.
• Kebocoran memori (malloc tanpa free, pointer hilang, dll.).

Contoh tanpa kesalahan: program "bersih" di bawah Memcheck

Misalkan Anda mengkompilasi program "hello world" kecil dengan informasi debugging:

gcc -Wall -gstabs valgrind_hello_good.c -o valgrind_hello_good

Jika Anda menjalankannya di bawah Valgrind dengan:

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

Anda akan mendapatkan jejak di mana, pada akhirnya, RINGKASAN KESALAHAN menunjukkan 0 kesalahan dan tidak ada kebocoran yang dilaporkan. Ini memvalidasi bahwa, setidaknya dari sudut pandang Memcheck, program tersebut tidak menunjukkan anomali memori.

Mendeteksi kebocoran memori

Jika Anda memodifikasi kode untuk melakukan malloc tanpa membebaskan memori (misalnya, dengan memesan satu byte dan tidak pernah membebaskannya) dan mengkompilasi ulang:

gcc -Wall -gstabs valgrind_hello_bad.c -o valgrind_hello_bad

saat dijalankan:

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

Valgrind akan menampilkan HEAP SUMMARY dengan nilai "in use at exit" yang bukan nol, yang menunjukkan jumlah memori yang belum dilepaskan. Selain itu, bagian "definitely lost" akan menunjukkan jumlah byte dan blok yang bocor, beserta jejak panggilan yang menyebabkan kebocoran (fungsi, file, dan baris kode).

Untuk kasus yang lebih kompleks, di mana filter digunakan, misalnya, 100 byte dalam fungsi leak()Jalan keluar dari Valgrind akan dengan jelas mengarahkan Anda ke malloc bermasalah, memungkinkan penambahan free Sesuai dan kemudian verifikasi bahwa ringkasan tersebut kembali ke nol kebocoran.

Akta ilegal dan akses di luar jangkauan

Kesalahan umum lain yang dideteksi oleh Memcheck adalah penulisan ke alamat yang tidak valid , misalnya, penulisan ke lokasi memori 0 (NULL) atau melampaui akhir array. Jika Anda mengkompilasi program yang melakukan penulisan ilegal:

gcc -gstabs -Wall valgrind_illegal_read_write.c -o valgrind_illegal_read_write

dan Anda menjalankannya dengan:

valgrind -v ./valgrind_illegal_read_write

Anda akan melihat pesan seperti:

Penulisan tidak valid dengan ukuran 4 di 0x80483C4: main (valgrind_illegal_read_write.c:8) Alamat 0x0 tidak berada di stack, dialokasikan dengan malloc, atau (baru-baru ini) dibebaskan

Ini memberi tahu Anda secara tepat di mana penulisan ilegal itu terjadi dan seberapa besar ukurannya, sesuatu yang dalam eksekusi normal biasanya hanya berupa "Kesalahan Segmentasi" tanpa petunjuk lebih lanjut.

Variabel yang belum diinisialisasi dan ketergantungan nilainya

Memcheck juga memberi tahu Anda ketika sebuah Keputusan kontrol bergantung pada variabel yang belum diinisialisasi.Jika Anda mengkompilasi program dengan variabel lokal yang tidak pernah diinisialisasi dan digunakan dalam if:

gcc -gstabs -Wall valgrind_unitialized.c -o valgrind_unitialized

dan Anda menjalankannya dengan:

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

Outputnya akan berisi sesuatu seperti:

Lompatan atau perpindahan bersyarat bergantung pada nilai yang belum diinisialisasi di 0x80483F2: main (valgrind_unitialized.c:9) Nilai yang belum diinisialisasi dibuat oleh alokasi tumpukan di 0x80483EA: main (valgrind_unitialized.c:7)

Parameter –track-origins=yes membantu menemukan di mana variabel yang belum diinisialisasi pertama kali dibuat, yang sangat mempercepat koreksi kode.

Penyalahgunaan memori bebas dan deteksi kesalahan di heap.

Valgrind juga memverifikasi bahwa Fungsi `free` hanya dipanggil pada pointer yang valid.Jika Anda mencoba membebaskan memori yang tidak berasal dari mallocAtau jika Anda mengklik dua kali pada blok yang sama, Anda akan mendapatkan pesan seperti ini:

Fungsi free() / delete / delete[] / realloc() tidak valid pada 0x402B06C: free (...) oleh 0x8048449: main (valgrind_illegal_free.c:11)

Dalam banyak kasus, bahkan akan memberi tahu Anda alamat tempat Anda menelepon. free Letaknya tepat setelah blok yang sudah dibebaskan, sehingga memungkinkan identifikasi. kesalahan perhitungan penunjuk atau pelepasan ganda.

Singkatnya, Valgrind adalah alat penting ketika Anda mencurigai adanya kebocoran memori, penggunaan memori setelah dibebaskan (use-after-free), atau kerusakan memori dalam program native, dan penggunaannya yang dikombinasikan dengan GDB memberikan pandangan yang sangat kuat tentang keadaan internal aplikasi.

Core dump dan analisisnya di Linux dan Windows

Dalam aplikasi modern, terutama di .NET Core , menganalisis masalah memori atau kinerja yang kompleks seringkali melibatkan pengambilan dump memori untuk analisis cermat di mesin lain. Dump ini membekukan status proses pada titik waktu tertentu, sama seperti core dump tradisional.

Menganalisis dump .NET di Linux dengan dotnet-dump dan LLDB

Di lingkungan .NET Core pada Linux, salah satu alat yang direkomendasikan adalah dotnet-dump . Setelah mendapatkan dump, Anda dapat memulai analisis dengan:

dotnet-dump analyze <dump-file>

Penting untuk melakukan analisis pada mesin dengan arsitektur dan distribusi Linux yang sama dengan lingkungan tempat dump dihasilkan. dotnet-dump ditujukan untuk kode .NET terkelola; untuk menganalisis kode asli (C/C++), lebih tepat menggunakan LLDB bersama dengan ekstensi SOS.

LLDB memungkinkan Anda untuk melakukan debug baik kode terkelola maupun kode asli, dan dengan bantuan dotnet-sos Anda dapat menginstal ekstensi SOS, yang menyediakan perintah khusus untuk .NET. Untuk memuat dump .NET Core dengan benar, LLDB dan SOS memerlukan biner tertentu dari lingkungan tempat dump tersebut dibuat:

1. libmscordaccore.so
2. libcoreclr.so
3. dotnet (host yang digunakan untuk memulai aplikasi)

File biner ini biasanya dapat diunduh menggunakan alat dotnet-symbol . Jika itu adalah build pribadi atau tidak ada di server simbol, Anda selalu dapat menyalinnya dari mesin aslinya. Jika file biner tidak disertakan dengan file dump, Anda dapat menggunakan perintah berikut di LLDB/SOS:

• setclrpath <ruta> untuk menunjukkan lokasi file biner .NET Core.
• setsymbolserver -directory <ruta> untuk menentukan lokasi simbol-simbol tersebut.

Setelah Anda memiliki semua yang dibutuhkan, muat dump ke dalam LLDB, dengan menentukan host dotnet sebagai executable yang akan di-debug:

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

Di sini Ini adalah rute menuju tempat pembuangan sampah dan Biasanya berupa biner. dotnet, kecuali jika itu adalah aplikasi mandiri, dalam hal ini akan menjadi file eksekusi aplikasi itu sendiri (tanpa ekstensi .dll).

Di dalam LLDB, seringkali perlu untuk mengkonfigurasi server simbol yang benar dengan setsymbolserver -ms untuk menggunakan server Microsoft, atau setsymbolserver -directory <ruta> untuk direktori lokal, dan jalankan loadsymbols untuk memuat simbol asli. Dari situ, Anda dapat menggunakan perintah SOS biasa untuk menganalisis heap terkelola, thread, pengecualian, dll.

Analisis dump Linux dari Windows

File dump yang dihasilkan di Linux tidak terbatas hanya untuk dianalisis pada sistem yang sama; file tersebut juga dapat dibuka dari Windows dengan alat seperti Visual Studio, WinDbg, atau dotnet-dump. Kemampuannya bervariasi:

• Visual Studio: memungkinkan pembersihan tempat pembuangan sampah dengan campuran kode asli dan terkeloladengan antarmuka grafis yang sangat ramah pengguna. Disarankan untuk meninjau panduan khusus untuk Mendebug dump memori Visual Studio.
• anginDukungan tingkat lanjut untuk data hasil dump pengguna, termasuk Linux dumps dengan alur kerja yang mirip dengan Windows. Anda harus menggunakan versi x64 dari WinDbg untuk dump dari lingkungan Linux x64 atau Arm64, dan versi x86 untuk dump x86.
• dotnet-dump Di Windows: cara penggunaannya sama seperti di Linux, yaitu dengan dotnet-dump analyzeIngatlah untuk memilih versi x64 atau x86 dari alat tersebut sesuai dengan arsitektur data yang di-dump.

Diagnosis profesional terhadap penggunaan CPU dan memori yang tinggi.

Selain alat-alat khusus, membersihkan memori di Linux biasanya melibatkan alur kerja terstruktur untuk menghindari tindakan sembarangan. Skema praktis untuk server adalah sebagai berikut:

• Melihat puncak untuk mendeteksi pola dan proses pemuatan yang mencurigakan.
• Konfirmasikan dengan ps Proses-proses yang menggunakan CPU dan memori paling banyak.
• Periksa apakah konsumsi tersebut logis (kompilasi, batch, terindeks) atau terkesan sebagai perilaku anomali.
• Analisis utas dengan atas -H -p PID ketika berbicara tentang proses multi-threaded.
• Untuk meninjau log layanan dengan journalctl atau tail.
• Periksa apakah masalahnya benar-benar terkait dengan CPU atau tersembunyi di... Input/Output Disk menggunakan iostat.

Untuk menentukan apakah hambatan (bottleneck) ada di CPU atau disk, perintah iostat -xz 1 3 sangat membantu: jika Anda melihat disk dengan utilisasi tinggi dan waktu tunggu yang lama, bersamaan dengan %wa yang tinggi di top , masalahnya mungkin bukan pada CPU tetapi pada penyimpanan.

Dengan menerapkan alur kerja ini, diagnosis kasus seperti:

• Bot atau lalu lintas berbahaya Memicu proses php-fpm dan membebani server web.
• Un Layanan mikro Java dengan thread yang terjebak dalam perulangan tak terbatas. Mengonsumsi seluruh inti prosesor.
• Sebuah proses Python yang tampaknya terbebani CPU tetapi sebenarnya terkunci menunggu disk dalam setiap iterasi sebuah loop.

Dengan menggabungkan alat sistem (ps, top, vmstat, free), debugger (GDB, LLDB, dotnet-dump), penganalisis memori (Valgrind), dan perintah jaringan dan disk, Anda dapat menciptakan cara kerja di mana masalah memori dan kinerja di Linux tidak lagi menjadi kotak hitam , tetapi menjadi sesuatu yang, dengan metode dan kesabaran, dapat diidentifikasi dan diperbaiki dengan akurasi yang cukup tinggi.