Sekitar sekali seminggu, tetapi kadang-kadang bahkan beberapa kali sehari setelah berjalan baik selama berhari-hari, mesin virtual EC2 saya menjadi tidak responsif. Grafik memori Munin menceritakan kisah yang sangat mudah: memori yang dialokasikan untuk "aplikasi" mulai tumbuh dan tidak berhenti sampai swap sepenuhnya digunakan dan instance secara efektif diturunkan hingga ke lutut. Grafik kustom lain menunjukkan bahwa proses yang terus berkembang adalah apache2.
Saya menjalankan setup Apache prefork standar dengan mod_php dan beberapa skrip PHP. Seperti yang dapat Anda lihat pada grafik di bawah ini, terjadi sesuatu yang memicu proses apache2 untuk mulai menggunakan lebih banyak memori. Lonjakan hijau pertama yang saya ingat waktu dan restart Apache sebelum semuanya keluar dari tangan. Lonjakan kedua menjadi sedikit lebih jauh dan instans harus reboot langsung.
Yang saya ingin tahu adalah bagaimana cara terbaik men-debug ini. Kurang menyiapkan PHP dengan FastCGI dan menjalankannya dalam prosesnya sendiri, apa cara yang baik untuk mengetahui apakah itu Apache atau kombinasi PHP dan kode saya yang menyebabkan penggunaan memori yang berlebihan? Langkah apa yang akan kalian lakukan untuk melacak masalah ini?
UPDATE: Saya bisa melacak kebocoran setelah terlibat, seperti yang disarankan Matt di bawah ini.
Setelah menemukan proses apache2 yang secara bertahap dan terus tumbuh dalam memori, saya menambahkan beberapa error_log () panggilan ke skrip PHP saya yang mencetak jumlah total RSS yang digunakan di berbagai titik dalam pelaksanaannya (menggunakan output ps). Namun itu ternyata menyesatkan - sementara tampaknya RSS melonjak hanya setelah skrip saya selesai dieksekusi, kemudian debugging mengungkapkan bahwa bukan itu masalahnya. Hati-hati!
Untungnya, semua panggilan error_log () ini ternyata bermanfaat pada akhirnya. Ketika saya menjalankan strace ( strace -p <pid> -tt -o trace.log -s 256), saya melihat bahwa untuk setiap permintaan, proses mengalokasikan sekitar 400k memori (mencari panggilan sistem 'brk' dan mengurangi parameter panggilan pertama dari panggilan terakhir - beberapa biasanya datang dalam satu setelah yang lainnya). Saya kemudian mencari panggilan sistem 'tulis' terbaru yang berisi pesan error_log () saya, yang memberi tahu saya pada titik mana dalam skrip memori yang dialokasikan. Dengan beberapa panggilan error_log () yang ditempatkan lebih strategis untuk menentukan lokasi dengan lebih akurat, akhirnya saya menemukan pelakunya.
Memori bocor ketika kami memanggil curl_exec () dari skrip PHP kami. Beberapa kode ikal yang terkait dengan penanganan koneksi SSL melakukan kesalahan - kebocoran hilang ketika saya beralih ke HTTP. Curel's changelog mereferensikan beberapa kebocoran memori SSL yang diperbaiki pada 7.19.5 (kami menggunakan 7.18.2) jadi saya akan mencobanya nanti.
Sementara itu, saya menjalankan dengan MaxRequestsPerChild yang sangat rendah yang menjaga Apache dalam batas yang wajar. Terimakasih semuanya!