Belajar RabbitMQ - Memory & Resource Management

#Pendahuluan

Setiap proses yang tidak mengelola memorinya akan mati oleh memorinya sendiri — dan RabbitMQ tidak terkecuali. Jika pesan menumpuk dan memori melampaui batas, node akan crash. Jika disk penuh, node berhenti memproses. Mengelola resource bukan pilihan, melainkan bagian tak terpisahkan dari mengoperasikan broker.

Episode ini membahas dua alarm utama yang melindungi RabbitMQ: memory alarm dan disk alarm. Kalian akan memahami cara menghitung memori node, kapan pesan di-paging ke disk, bagaimana lazy queue bekerja, lalu menutup dengan limit-limit resource yang bisa dipasang per node maupun per vhost.

Ini adalah episode yang penting untuk operasional: tanpa memahami alarm ini, kalian tidak akan bisa membaca gejala broker yang sekarat di bawah beban.

#Memory Management

#Memory Alarms dan Threshold

RabbitMQ memantau penggunaan memori node. Saat melewati high watermark, semua connection yang mem-publish diblokir (seperti di episode 14). Nilai defaultnya 0.4 — 40 persen memori total:

vm_memory_high_watermark.relative = 0.6

Menaikkan nilai memberi ruang queue lebih besar, tapi menambah risiko OOM. Menurunkannya membuat broker lebih aman dengan mengorbankan kapasitas buffer.

#Strategi Perhitungan Memori dan Paging

RabbitMQ menghitung memori dari beberapa sumber: queue messages, proses Erlang, connection, channel, dan buffer lainnya. Ada strategi perhitungan berbeda (rss vs allocated), tapi default-nya sudah cukup baik untuk sebagian besar kasus.

Strategi rss memakai ukuran resident set dari proses Erlang, sedangkan allocated memperkirakan memori dari alokasi yang dilaporkan runtime. allocated biasanya memberi sinyal lebih awal, sementara rss lebih akurat mendekati kondisi OOM yang nyata. Ubah strategi hanya jika kalian punya alasan terukur — misalnya memori cenderung melonjak cepat tanpa pemicu yang terlihat.

Saat memori mendekati batas, node mulai paging pesan queue ke disk untuk meredakan tekanan memori:

vm_memory_high_watermark_paging_ratio = 0.5

vm_memory_high_watermark_paging_ratio 0.5 berarti paging mulai pada 50 persen high watermark — sebelum alarm penuh memblokir publisher. Paging menjaga node tetap hidup tapi menambah beban disk.

#Memantau Penggunaan Memori dan Paging

Untuk melihat seberapa banyak pesan yang sudah di-page ke disk, bandingkan kolom messages dengan messages_paged_out:

rabbitmqctl list_queues name messages messages_paged_out

messages_paged_out menampilkan pesan yang ditulis ke disk karena tekanan memori. Jika angkanya terus naik seiring beban, node sedang menekan memori — indikasi awal untuk menurunkan high watermark atau memperpendek queue. Pantau juga bagian memori pada rabbitmqctl status untuk melihat sumber penggunaan per komponen.

#Lazy Queues

#Memindahkan Pesan ke Disk Lebih Awal

Lazy queue adalah classic queue yang menulis pesan ke disk segera saat diterima, alih-alih menahan di memori dulu. Konsekuensinya: memori node jauh lebih aman untuk antrean besar, dengan pengorbanan latency yang sedikit lebih tinggi karena setiap publish menyentuh disk.

rabbitmqadmin declare queue name=ingest \
  arguments='{"x-queue-type":"classic","x-queue-mode":"lazy"}'

#Use Cases dan Implikasi Performa

Lazy queue cocok untuk antrean yang terus-menerus besar: ingest data massal, buffer log, atau queue yang consumer-nya sering tertinggal. Trade-off: throughput publish menurun dibanding mode default, dan konsumsi tetap bekerja normal. Jika queue biasanya pendek dan cepat dikosongkan, mode default lebih baik.

#Resource Limits

#Limit Connection, Channel, dan Queue

Node bisa dibatasi resource-nya dengan rabbitmqctl set_node_limits, dan per vhost dengan set_vhost_limits (yang sudah kita lihat di episode 13):

rabbitmqctl set_vhost_limits -p tenant_b '{"max-connections":50,"max-queues":200}'

Batasan max-connections dan max-queues di atas memproteksi node dari satu tenant yang terlalu rakus. Untuk channel, batas per connection default 2047.

#Per-Vhost dan File Descriptor Limits

Selain memori dan disk, file descriptor adalah resource yang sering diabaikan: setiap connection memakai beberapa FD. Naikkan ulimit -n sesuai perkiraan jumlah connection, dan pasang limit connection per vhost untuk menjaga keadilan antar tenant.

#Menetapkan Limit untuk Seluruh Node

Selain per vhost, limit juga bisa dipasang di level node untuk melindungi broker dari keseluruhan beban:

rabbitmqctl set_node_limits '{"max-connections":1000,"max-queues":5000}'

set_node_limits membatasi total connection dan queue di seluruh node. Kombinasikan dengan limit per vhost: limit node adalah jaring pengaman terakhir, sementara limit per vhost memastikan setiap tenant mendapat jatah yang adil. Alarm low_connection dan low_queue_count akan muncul di Management UI saat mendekati batas.

#Disk Management

#Disk Space Alarms

Jika ruang disk turun di bawah disk free limit, node berhenti memproses pesan untuk mencegah kehabisan disk total. Defaultnya relatif — 50 MB atau persentase tertentu:

disk_free_limit.absolute = 2GB

disk_free_limit.absolute = 2GB memastikan broker selalu menyisakan minimal 2 GB ruang disk bebas.

#Rotasi Log dan Kompaksi Message Store

Log RabbitMQ tumbuh terus; atur rotasi agar tidak memenuhi disk. Message store juga mengelola segmen file yang berisi pesan yang sudah di-ack — segmen lama dihapus atau dikompaksi otomatis seiring waktu. Pantau penggunaan disk di Management UI dan beri alert sebelum menyentuh disk alarm.

#Penutup

Di episode 23 ini kalian sudah mengelola alarm memori dan disk, strategi perhitungan memori dan paging, lazy queues, limit connection dan queue per vhost, serta rotasi log dan kompaksi message store.

Inti yang harus dibawa pulang:

• Memory alarm memblokir publisher saat memori melewati high watermark.
• Paging menulis pesan queue ke disk untuk meredakan tekanan memori.
• Lazy queue menulis pesan ke disk lebih awal untuk antrean besar.
• Batasi connection dan queue per vhost untuk keadilan antar tenant.
• File descriptor membatasi kapasitas connection node.
• Disk alarm menghentikan pemrosesan saat disk hampir penuh.
• Rotasi log dan kompaksi store menjaga disk tetap sehat.

Di episode 24 selanjutnya kita akan membangun monitoring dan observability — membaca metrik dari Management UI dan HTTP API, memakai rabbitmqadmin dan rabbitmqctl, mengintegrasikan Prometheus dengan endpoint metrik, menyusun dashboard Grafana, serta mengelola log dengan level, lokasi, dan agregasi terpusat. Sekarang broker kalian akan bisa "bicara"!