Elixir dalam Manajemen Memori

Elixir dalam Manajemen Memori – Setiap bahasa pemrograman memiliki batasan dan kekurangannya masing-masing. Kebocoran memori atau kebocoran sumber daya menyebabkan masalah kinerja dan memori. Dalam beberapa hari terakhir, saya menemukan masalah yang sama dengan Elixir, mungkin itu adalah bug pengkodean pengembang atau mungkin modul jahat yang bertindak gila. Hari ini, kita akan membahas kedua masalah tersebut.

Elixir dalam Manajemen Memori

elixir-memory – Pertama-tama, Elixir ada di atas BEAM. Dimana BEAM sendiri bertindak seperti OS. Ini memiliki manajer tugas dan manajemen memori. Dan sebagian besar modul inti Elixir dibangun di jalur yang sama seperti supervisor dinamis.

Kami memiliki masalah besar pada aplikasi kami (kami mewarisi aplikasi ini), sysadmin kami menunjukkan kepada kami bahwa aplikasi tersebut mengambil sumber daya yang sangat besar untuk komputasi dan ram 32 Gb. Tetapi menurut analisis kami, seharusnya tidak pernah melewati 1 Gb.

Baca Juga : Memantau Penggunaan Memori untuk Aplikasi Erlang dan Elixir

Masalah di atas ini menyebabkan aplikasi macet. Dan jelas kerugian finansial . Kami mulai menyelidiki masalah aneh ini. Kami mulai dengan level kode, inisialnya adalah tabel ETS. Itulah satu-satunya tempat kami menyimpan data dalam aplikasi untuk beberapa komponen. Setelah beberapa aplikasi stress test, yang tidak pernah melewati 100 MB, ketika dalam kapasitas puncak. Jadi, kami mengesampingkan masalah tingkat pengkodean.

Sekarang kita mulai pendekatan bedah. Kami harus memeriksa server langsung (server produksi), untuk menyudutkan masalah. Tidak mengherankan, Beam bertindak seperti Mini OS-nya sendiri. Dan kami mulai memasuki dunia, kami tidak menemukan kesulitan untuk terhubung ke mesin Beam yang sedang berjalan.

Kita dapat menghubungkan salah satu node, tanpa me-restart/mendistribusikan kode run time, dengan kode di atas. Pertama dan terpenting untuk memeriksa tabel ETS: :erlang.memory memberi kita gambaran sekilas tentang distribusi memori di ekosistem Beam. Kami mengenal proses dan ETS memakan banyak sekali ram. Mulai men-debug tabel ETS terlebih dahulu,

Ditemukan bahwa modul ex_statd digunakan untuk mentransfer data dari Erlang ke DataDog. Ini adalah caching data, tanpa membilasnya. Melihat modul itu sudah usang beberapa tahun yang lalu dan masalah di GitHub disebutkan tentang kebocoran memori. Dan mencari alternatif, mengamati bahwa bahkan alternatif tersebut memiliki masalah kebocoran memori.

Kebocoran memori umum, kami mengamati dalam kedua kasus, ketika sebuah paket dikirim ke modul, ia mencoba mengirim data ke port sistem, jika port tidak tersedia atau tidak merespons saat ini. Paket akan disimpan di ETS stable dan mencoba mengirim ulang.

Nah, itu niat yang sangat baik untuk mencoba lagi. Tapi menangkap data ketika tidak ada batas ambang batas yang ditetapkan untuk menyiram data. Saat kami meningkatkan aplikasi dari beberapa Kb ke Gb, itu membebani sumber daya.

Sekarang datang tantangan nyata, kebocoran memori proses debug.

Beam menarik salah satu fungsinya dari topi ajaibnya. Ini memiliki daftar proses dan kami memulai jejak darinya. Pernah bertanya-tanya, bagaimana proses dapat memiliki memori, dalam bahasa fungsional — memori harus dilepaskan setelah fungsi dijalankan, pikirkan saja sekali, sebelum turun. Di bawah ini adalah contoh praktik pengkodean yang buruk sampai ke intinya.

Genserver adalah alat yang hebat, alat yang hebat dalam ekosistem elixir dan memberikan beberapa aplikasi hebat, seperti kutipan Linux `kekuatan besar datang tanggung jawab besar`. Ketika kita menyalahgunakan, itu merusak aplikasi. Genserver bertindak gila-gilaan, bukan karena bug, pengembang mengubah fitur hebat menjadi bug serius.

Genserver memiliki status, di mana kita dapat menahan status genserver untuk digunakan kembali/menyimpan beberapa muatan untuk proses selanjutnya guna memanfaatkannya. Kode ditulis dengan cara, data di dalam status dinyatakan untuk ditambahkan ketika proses selanjutnya masuk. Ya, tambahkan . Yang bukan cara menganggur untuk menanganinya.

Kedua masalah tersebut menghambat aplikasi secara keseluruhan, membawa kerugian finansial bagi perusahaan. Ini adalah pembuka mata bagi kami, berhati-hatilah dengan modul yang ada di dalam aplikasi Anda. Sekarang setelah proyek bertambah besar, kami memulai latihan untuk mengawasi modul. Ini adalah pengalaman kami dalam menangani kebocoran memori di Erlang dan tolong bagikan pengalaman Anda jika Anda mengalami hal serupa.

Upaya kami untuk menggunakan sumber daya minimal masih berlangsung, segmen berikutnya adalah perang terhadap parser khususnya JSON dan XML, tetapi kami akan mengujinya dengan cara uji pertempuran geser. Karena kami memiliki beban sekitar 5 MB/detik untuk diproses, dan peningkatan fraksional apa pun akan bagus untuk kami.