Resource Utilization

Server database tidak hidup sendirian di mesin: proses mongod berbagi CPU, memori, dan disk dengan aplikasi lain, dan hampir semua keluhan performa bermuara pada salah satu dari tiga sumber daya itu. Kabar baiknya, mongod melaporkan pemakaiannya sendiri lewat serverStatus, sehingga kita bisa mencocokkan angka dari dalam server dengan angka dari alat sistem operasi. Chapter ini mempraktikkan pembacaan ketiga sumber daya itu — memori, CPU, dan I/O — lalu menutup dengan tabel interpretasi koneksi dan thread.

Peta materi chapter ini:

Tiga lapis memori: cache WiredTiger, resident proses, page cache OS.
Pola CPU user, system, dan iowait lewat top dan vmstat.
Koneksi dan thread lewat serverStatus.connections.

Memori: Resident, Cache, dan Page Cache #

Ada tiga angka memori yang sering tertukar, padahal maknanya berbeda. Mari ambil semuanya dari server latihan sekaligus:

js
const ss = db.serverStatus()
ss.mem

Output yang Dihasilkan:

text
{
  bits: 64,
  resident: 610,
  virtual: 22973,
  supported: true,
  secureAllocByteCount: 0,
  secureAllocBytesInPages: 4096
}

mem.resident (610 MB) adalah memori fisik yang dipakai proses mongod secara keseluruhan. Komponen terbesarnya adalah cache WiredTiger, yang batasnya bisa dilihat dari bagian yang sama:

js
ss.wiredTiger.cache["bytes currently in the cache"]
ss.wiredTiger.cache["maximum bytes configured"]

Output yang Dihasilkan:

text

148936964
268435456

Cache sedang memuat sekitar 142 MB dari batas 256 MB yang kita set lewat cacheSizeGB: 0.25 (chapter Konfigurasi Server). Susunan tiga lapisnya:

Lapis	Ukuran di mesin latihan	Isinya
Cache WiredTiger	≤ 256 MB (dikonfigurasi)	Data dan index panas dalam bentuk halaman
Resident proses	~610 MB	Cache + koneksi + thread + struktur internal
Page cache OS	~2 GB (dipakai bersama)	Berkas `.wt` yang pernah dibaca OS

Resident yang tumbuh melewati cacheSizeGB plus overhead beberapa ratus MB patut dicurigai — biasanya kebocoran kursor atau jumlah koneksi besar. Di sisi lain, page cache OS yang besar justru menguntungkan: pembacaan berkas yang belum masuk cache WiredTiger tetap dilayani dari RAM. Pembahasan working set dan eviksi ada di chapter Working Set dan Memory.

CPU: Membaca Pola user, system, iowait #

Dari sisi sistem operasi, top menampilkan proses mongod beserta pemakaian CPU-nya:

bash
top -b -n 1 -p $(pidof mongod)

Output yang Dihasilkan:

text
top - 20:11:00 up  7:55,  0 users,  load average: 0.07, 0.21, 0.16
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   4159.6 total,  1205.1 free,  1028.8 used,  2118.5 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   3130.8 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3067 z         20   0   22.4g 624836 163248 S   0.0  14.7   5:01.43 mongod

Angka RES di sini (624836 KB ≈ 610 MB) cocok dengan mem.resident dari serverStatus — pemeriksaan silang yang sehat dilakukan rutin. mongod juga melaporkan akumulasi CPU-nya sendiri, terpisah menjadi waktu user (menjalankan kode MongoDB) dan waktu system (syscall kernel):

js
const e = ss.extra_info
Math.round(e.user_time_us / 6e7)
Math.round(e.system_time_us / 6e7)
e.threads

Output yang Dihasilkan:

text
4
1
Long('112')

Selama tujuh jam lebih, proses menghabiskan sekitar 4 menit waktu user dan 1 menit waktu system dengan 112 thread — server yang benar-benar santai. Tiga pola CPU yang perlu dikenali:

Pola di `top`/`vmstat`	Arti bagi MongoDB
`us` tinggi	Beban query/aggregation — periksa `currentOp` dan index
`sy` tinggi	Banyak syscall: koneksi baru, lock, aktivitas file — curigai terlalu banyak koneksi kecil
`wa` (iowait) tinggi	Disk tidak keburu — cache terlalu kecil atau working set melampaui RAM

Untuk pola ketiga, vmstat 1 3 memberi kolom bi/bo (blok dibaca/ditulis per detik) sebagai konfirmasi arah:

bash
vmstat 1 3

Output yang Dihasilkan:

text
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 1233744  27436 2142332    0    0     0   100 1123   12  3  1 96  0  0  0
 1  0      0 1233548  27436 2142372    0    0     0     0 1058 2155  1  0 99  0  0  0
 1  0      0 1233548  27436 2142372    0    0     0     0  968 1925  1  1 99  0  0  0

Kolom wa yang nol dan bi/bo minim menegaskan disk tidak jadi hambatan saat ini. Di mesin produksi, iostat -xm 2 (paket sysstat) menambah metrik per-device seperti %util dan await untuk mengukur kejenuhan disk secara langsung; htop berfungsi sebagai versi interaktif top yang lebih ramah mata.

Koneksi dan Thread #

Setiap koneksi klien menempati satu thread server dan satu file descriptor. Potret koneksi dari serverStatus:

js
ss.connections.current
ss.connections.available
ss.connections.threaded

Output yang Dihasilkan:

text
5
404
5

Nilai pasti current dan threaded berubah antar sesi — angka di atas berasal dari sesi mdtest yang membuka beberapa koneksi pendek. Tabel interpretasinya:

Field	Pertanyaan	Sinyal bahaya
`current`	Berapa koneksi terbuka sekarang?	Terus naik tanpa turun → kebocoran koneksi aplikasi
`available`	Berapa slot tersisa hingga `maxIncomingConnections`?	Menyusut mendekati nol → naikkan batas atau perbaiki pool
`threaded`	Berapa thread terpakai untuk melayani koneksi?	Selaras `current`; lonjakan = banyak koneksi sibuk bersamaan
`rejected`	Ada koneksi yang ditolak?	Bukan nol → batas sudah tersentuh, klien gagal masuk

Dua angka pertama menunjukkan mesin latihan sedang menampung 5 koneksi dengan 404 slot tersisa — sisa dari batas maxIncomingConnections. Diagnosis lanjutan koneksi — termasuk melihat pemiliknya lewat currentOp — sudah kita bahas di chapter Monitoring Server, dan pengelolaan pool di sisi aplikasi ada di chapter Connection Pooling.

Rangkuman #

Tiga lapis memori berbeda: cache WiredTiger (dibatasi cacheSizeGB), resident proses (cache + overhead), dan page cache OS (dipakai bersama, menguntungkan).
Cocokkan RES dari top/ps dengan mem.resident dari serverStatus sebagai pemeriksaan silang rutin.
Pola CPU: us tinggi = beban query, sy tinggi = syscall/lock, wa tinggi = disk kewalahan — konfirmasi arah dengan vmstat atau iostat -xm.
Koneksi berlebihan memakan thread dan file descriptor; pantau connections.current dan available serta waspadai rejected.