Apa yang sebenarnya diukur "pemakaian memori" Windows — membaca Working Set, Private Bytes, Commit, dan page file dengan benar

Di Task Manager, "Memory" suatu proses tampil 1.2GB. Namun di Process Explorer, Working Set-nya 1.5GB dan Private Bytes 2.4GB, sementara Size di VMMap lebih besar lagi. Jika melihat sistem secara keseluruhan, tertulis "Committed 19.6/31.8GB".

Jadi, pada akhirnya, berapa GB memori yang dipakai aplikasi ini?

Jawabannya: angka yang harus dilihat berubah tergantung apa yang ingin diketahui. Metrik yang dipakai berbeda, tergantung apakah yang ingin diketahui adalah jumlah yang saat ini ada di RAM, jumlah alokasi yang khusus milik proses itu, jumlah yang dijanjikan sistem untuk tetap ditopang ke depan, atau sekadar rentang alamat virtual yang sudah dicadangkan.

Metrik memori Windows sulit karena semuanya ditampilkan dengan kata yang sama, "memori", padahal sebenarnya mengukur sumbu-sumbu terpisah berikut.

• Seberapa banyak ruang alamat yang terpakai
• Seberapa banyak commit yang sudah dikonsumsi
• Apakah saat ini residen di RAM fisik
• Apakah halaman itu khusus milik proses, atau dapat dibagi
• Seberapa banyak alokasi lagi yang masih dapat ditopang sistem secara keseluruhan

Artikel ini ditujukan bagi siapa pun yang menyelidiki pertumbuhan memori aplikasi atau kekurangan memori di seluruh sistem pada Windows 10/11 dan Windows Server terkini, dan merangkai dalam satu gambaran hubungan Working Set, Private Working Set, Private Bytes, Commit, Virtual Bytes, page file, Available, dan page fault.

Prosedur menelusuri mengapa objek .NET tidak dikumpulkan dibahas secara rinci di "Membedakan menunggu GC dan memory leak di .NET", dan operasi konkret VMMap serta Process Explorer dibahas di "Process Explorer / Handle / VMMap dalam praktik". Artikel ini berfokus pada prasyarat keduanya: cara membaca angka di sisi OS Windows.

1. Kesimpulan lebih dulu

• Working Set adalah halaman yang saat ini residen di RAM. Ia mencakup bukan hanya halaman privat proses, tetapi juga halaman yang dapat dibagi dengan proses lain, seperti kode DLL dan berkas yang dipetakan ke memori.¹
• Private Working Set adalah bagian Working Set yang saat ini hanya milik proses itu. Berguna sebagai perkiraan "RAM yang saat ini ditempati secara khusus oleh proses ini", tetapi bukan total yang dialokasikan aplikasi.²
• Private Bytes adalah jumlah commit yang privat bagi proses itu. Ini metrik terpisah dari apakah memori saat ini ada di RAM. Bidang PagefileUsage dalam struktur API Win32 juga, pada Windows terkini, secara efektif mewakili Commit Charge yang sama, dan bukan jumlah byte yang benar-benar ditulis ke page file.²
• "Committed X/Y" di Task Manager menampilkan X sebagai jumlah commit sistem saat ini dan Y sebagai batas commit. X bukan pemakaian page file. Y kira-kira ditentukan oleh jumlah RAM plus page file.³
• Reserve dan Commit adalah hal yang berbeda. Sekadar mereservasi rentang alamat virtual hanya menyisihkan rentang itu untuk pemakaian di masa depan; ia tidak mengonsumsi jumlah yang sama dari RAM maupun batas commit.⁴⁵
• Page fault tidak selalu berarti I/O disk. Ada soft fault, yang dapat diselesaikan di dalam RAM, dan hard fault, yang membaca dari page file, berkas executable, berkas yang dipetakan ke memori, dan semacamnya.¹⁶
• Kebocoran memori dinilai bukan dari satu bacaan, melainkan dari kemiringan saat beban yang sama diulang. Khususnya, perhatikan apakah Private Bytes dan rinciannya terus naik selangkah demi selangkah bahkan setelah pemrosesan selesai, tanpa kembali ke keadaan mantap yang sama.

Dalam satu kalimat: Working Set adalah "jumlah yang saat ini di RAM", Private Bytes adalah "jumlah yang dijanjikan khusus untuk proses ini", dan Commit adalah "jumlah yang dijanjikan sistem secara keseluruhan".

flowchart TB
    accTitle: Memilih metrik memori Windows yang tepat
    accDescr: Metrik yang dilihat berubah tergantung apakah yang ingin diketahui jumlah residen di RAM, commit privat proses, commit seluruh sistem, atau rentang alamat virtual
    question["Apa yang ingin diketahui tentang \"pemakaian memori\""]
    question -->|jumlah saat ini di RAM| workingSet["Working Set"]
    question -->|jumlah yang dijanjikan privat proses| privateBytes["Private Bytes"]
    question -->|jumlah yang dijanjikan seluruh sistem| systemCommit["System Commit"]
    question -->|rentang alamat yang dicadangkan| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["Residen di RAM fisik"]
    privateBytes --> privateCommit["Commit privat proses"]
    systemCommit --> commitLimit["Bandingkan dengan Commit Limit"]
    virtualBytes --> addressSpace["Ruang alamat virtual"]

Gambar 1: Uraikan dulu pengamatan "memori tinggi" menjadi empat pertanyaan terpisah.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 18, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Memecah “pemakaian memori” menjadi empat sumbu

Pertama-tama, pikirkan memori Windows bukan sebagai “satu batang”, melainkan sepanjang empat sumbu.

flowchart TB
    accTitle: Empat sumbu independen untuk mengklasifikasi satu halaman
    accDescr: Periksa secara terpisah keadaan alamat virtual, backing halaman yang dikomit, keberadaan di RAM fisik, dan kemungkinan berbagi dengan proses lain
    page["Lihat satu halaman sepanjang empat sumbu"]
    page --> address["Keadaan alamat"]
    address --> addressValues["Free / Reserved / Committed"]
    page --> backing["Backing"]
    backing --> backingValues["Page-file-backed / File-backed"]
    page --> residentAxis["Residen RAM"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["Kemungkinan berbagi"]
    sharing --> sharingValues["Private / Shareable"]

Gambar 2: Bahkan untuk satu halaman, keadaan alamat, backing, keberadaan di RAM, dan kemungkinan berbagi masing-masing ditentukan secara terpisah.

Mapped bukan keadaan alamat yang setara dengan Free, Reserved, dan Committed — ia adalah jenis wilayah. Halaman dalam view yang dipetakan juga dapat menjadi Committed. Demikian pula, Private bukan media backing, melainkan klasifikasi kemungkinan berbagi. Karena itu, backing dibaca sebagai Page-file-backed atau File-backed, dan kemungkinan berbagi sebagai Private atau Shareable, secara terpisah.

Menggabungkan keempat sumbu ini memberi hubungan metrik perwakilan sebagai berikut.

flowchart TB
    accTitle: Pemetaan jenis halaman ke metrik memori utama
    accDescr: Menunjukkan metrik mana yang mencakup halaman privat residen, halaman privat nonresiden, halaman bersama residen, dan rentang hanya-reservasi
    privateResident["Privat, dikomit, residen RAM"]
    privateNonresident["Privat, dikomit, tidak residen RAM"]
    sharedResident["Halaman bersama, residen RAM"]
    reservedOnly["Reserved, belum Commit"]
    workingSet["Working Set"]
    privateWorkingSet["Private Working Set"]
    privateBytes["Private Bytes"]
    virtualBytes["Keluarga Virtual Bytes"]
    privateResident --> workingSet
    privateResident --> privateWorkingSet
    privateResident --> privateBytes
    privateResident --> virtualBytes
    privateNonresident --> privateBytes
    privateNonresident --> virtualBytes
    sharedResident --> workingSet
    sharedResident --> virtualBytes
    reservedOnly --> virtualBytes

Gambar 3: Working Set dan Private Bytes menghitung himpunan halaman yang berbeda, sehingga tidak membentuk relasi inklusi yang sederhana.

Yang penting di sini: Working Set dan Private Bytes bukan relasi inklusi yang sederhana.

Private Bytes mencakup halaman yang privat bagi proses tetapi saat ini tidak residen di RAM. Sebaliknya, Working Set mencakup halaman bersama — seperti kode DLL dan memori bersama — yang tidak dihitung dalam Private Bytes. Karena itu, tergantung proses dan momen pengukurannya, Working Set bisa lebih besar dari Private Bytes, atau sebaliknya.

Selain itu, jika Working Set beberapa proses dijumlahkan secara mentah, halaman fisik yang sama — misalnya DLL bersama — bisa dihitung berkali-kali. “Jumlah Working Set tiap proses = RAM yang sedang dipakai” tidak selalu benar.

3. Ruang alamat virtual — Reserve dan Commit adalah hal yang berbeda

3.1. Alamat virtual bukan alamat RAM fisik

Setiap proses memiliki ruang alamat virtual sendiri. Pointer yang ditangani aplikasi tidak langsung menunjukkan posisi RAM fisik; Windows memakai page table untuk memetakan alamat virtual ke halaman fisik atau data di berkas.⁷

Karena itu, bahkan di PC dengan 64GB RAM, ruang alamat virtual yang dapat dipakai suatu proses 32-bit biasanya jauh lebih kecil. Sebaliknya, proses 64-bit yang ruang alamat virtualnya lebih besar daripada RAM fisik juga biasa.

3.2. Reserved hanya “memegang alamat”

MEM_RESERVE pada VirtualAlloc mencadangkan rentang alamat virtual yang berurutan untuk pemakaian di masa depan. Pada tahap ini, penyimpanan fisik belum dikaitkan ke halaman, dan rentang itu tidak dapat dibaca atau ditulis.⁴⁵

Misalnya, meski basis data atau runtime mereservasi rentang alamat 8GB untuk pertumbuhan di kemudian hari, itu saja tidak berarti 8GB RAM atau 8GB Private Bytes sudah dikonsumsi.

3.3. Committed adalah janji “akan ditopang ketika dibutuhkan”

MEM_COMMIT mengubah halaman virtual itu menjadi keadaan Committed, dan merupakan operasi yang menjanjikan bahwa Windows akan menyediakan backing yang dibutuhkan. Apakah baca, tulis, atau eksekusi benar-benar diizinkan ditentukan terpisah oleh proteksi halaman seperti PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, dan PAGE_NOACCESS; fakta bahwa halaman sudah dikomit tidak berarti “dapat dibaca-tulis”. Pada saat commit, jumlah itu dicatat ke Commit Charge sistem, tetapi halaman fisik sebenarnya mungkin belum dialokasikan sampai akses pertama. Halaman yang baru pertama kali disentuh diinisialisasi dengan nol, lalu masuk Working Set melalui Demand-zero fault.⁵¹

Jadi, meski sama-sama disebut “mengamankan”, ada tiga tahap berikut.

flowchart TB
    accTitle: Tiga tahap dari Reserve ke Commit dan residen RAM
    accDescr: Menunjukkan alur mereservasi alamat virtual, mengomit halaman, lalu pada akses pertama mengalokasikan halaman fisik dan memasukkannya ke Working Set
    reserve["MEM_RESERVE: cadangkan rentang alamat"]
    reserve -.-> virtualMetric["Tercermin pada keluarga Virtual Bytes"]
    reserve -->|MEM_COMMIT| committed["Sudah Commit: akses sesuai proteksi halaman"]
    committed -.-> commitMetric["Tercermin pada Private Bytes / System Commit"]
    committed -->|Akses pertama / Demand-zero fault| resident["Alokasikan halaman fisik, residen RAM"]
    resident -.-> workingSetMetric["Tercermin pada Working Set"]
    committed -.->|Jika belum diakses| nonresident["Sudah Commit tetapi belum residen"]

Gambar 4: Reserve, Commit, dan akses pertama adalah peristiwa yang berbeda, dan masing-masing menggerakkan metrik yang berbeda.

Ketiga tahap ini masing-masing menggerakkan angka keluarga Virtual Bytes, Private Bytes, dan Working Set secara terpisah.

3.4. Mengapa OutOfMemory bisa terjadi meskipun ada RAM kosong

Keberhasilan alokasi memori tidak ditentukan hanya oleh RAM kosong.

• Ruang alamat virtual proses sudah habis
• Tidak ada rentang alamat kosong yang berurutan dengan ukuran yang dibutuhkan
• Commit Charge seluruh sistem mencapai Commit Limit
• Job Object, kontainer, runtime, atau pustaka punya batas sendiri
• Prosesnya 32-bit
• Heap native terfragmentasi

Bahkan di Windows 64-bit, ruang alamat virtual mode pengguna proses 32-bit biasanya 2GB jika IMAGE_FILE_LARGE_ADDRESS_AWARE nonaktif. Aplikasi 32-bit yang flag itu aktif dapat memakai hingga 4GB di Windows 64-bit.⁸

Karena itu, “PC masih punya 20GB RAM kosong, tetapi aplikasi 32-bit gagal di sekitar 1.6GB” bukan kontradiksi. Kemungkinannya bukan masalah RAM, melainkan fragmentasi atau batas ruang alamat.

4. Working Set — halaman yang saat ini ada di RAM

Working Set adalah himpunan halaman dalam ruang alamat virtual proses yang saat ini residen di RAM fisik.¹

Di dalamnya tercampur hal-hal berikut.

• Heap dan stack yang privat bagi proses
• Kode dan data hanya-baca dari EXE dan DLL
• Berkas yang dipetakan ke memori
• Memori bersama
• Halaman yang menjadi privat bagi proses itu setelah Copy-on-write
• Halaman yang disentuh runtime dan berbagai pustaka

4.1. Naiknya Working Set tidak selalu berarti alokasi bertambah

Jika halaman yang sudah dikomit diakses untuk pertama kali, Working Set saja dapat naik tanpa Private Bytes berubah. Ketika berkas besar dipetakan ke memori lalu dibaca berurutan, halaman yang berasal dari berkas itu masuk Working Set, sementara Private Bytes hampir tidak naik.

Sebaliknya, jika Windows merespons tekanan memori dengan Trim Working Set, Working Set saja turun meskipun aplikasi secara logis masih memegang memori yang sama. Jika halaman itu disentuh lagi, ia kembali melalui page fault.

Jadi, turunnya Working Set tidak selalu berarti “aplikasi sudah melepaskan”, dan naiknya tidak selalu berarti “aplikasi baru saja mengalokasikan”.

flowchart TB
    accTitle: Alur khas ketika hanya Working Set yang naik-turun
    accDescr: Halaman Commit yang sama masuk RAM pada akses pertama, menjadi nonresiden karena Trim, lalu kembali pada akses ulang, sementara Private Bytes tetap dicatat
    committed["Halaman yang sama, sudah Commit"]
    committed -->|Akses pertama| resident["Residen RAM"]
    resident -->|Trim karena tekanan memori| nonresident["Nonresiden"]
    nonresident -->|Page Fault pada akses ulang| resident
    resident -.-> inWorkingSet["Termasuk dalam Working Set"]
    nonresident -.-> outsideWorkingSet["Tidak termasuk dalam Working Set"]
    committed -.-> privateBytes["Selama masih Commit, dicatat ke Private Bytes"]

Gambar 5: Working Set naik-turun mengikuti keadaan residen, tetapi selama Commit halaman yang sama tetap ada, Private Bytes tidak turun.

4.2. Working Set mencakup halaman bersama

Jika 10 proses berbagi halaman kode DLL yang sama, halaman itu dapat tampak di Working Set masing-masing proses, tetapi di RAM fisik mungkin hanya ada satu salinan. Working Set yang dijumlahkan melebihi RAM terpasang tidak serta-merta abnormal.

Jika ingin mendekati “RAM yang saat ini ditempati secara khusus oleh proses ini saja”, lihat Private Working Set. Namun ini pun bukan “seluruh memori yang dialokasikan proses itu”; ia hanya halaman Private yang saat ini residen.

4.3. Mengecilkan Working Set secara paksa tidak memperbaiki kebocoran

EmptyWorkingSet atau SetProcessWorkingSetSize dapat mengusir halaman dari Working Set proses. Namun ini bukan operasi yang melepaskan commit atau referensi di heap. Private Bytes bisa tetap, pemakaian RAM yang tampak turun, lalu page fault bertambah pada akses berikutnya.⁹

Jika angka Task Manager mengecil hanya segera setelah tombol pengurangan memori ditekan, lalu cepat kembali ketika operasi dilanjutkan, mungkin itu bukan “pelepasan”, melainkan hanya Trim Working Set.

5. Private Bytes — jumlah commit yang privat bagi proses

Private Bytes adalah jumlah memori virtual yang dikomit secara khusus untuk proses itu. Ia menyatakan Commit Charge yang tidak dapat dibagi dengan proses lain, terlepas dari apakah saat ini residen di RAM. Pada PROCESS_MEMORY_COUNTERS_EX milik Microsoft, PrivateUsage sesuai dengan nilai ini.¹⁰²

API Win32 juga punya nama bidang yang menyesatkan, PagefileUsage, tetapi dokumentasi terkini mendefinisikannya sebagai “Commit Charge proses itu” dan menjelaskan bahwa nilainya sama dengan PrivateUsage. Jadi, Private Bytes 2GB tidak berarti “2GB ditulis ke pagefile.sys”.²

Private Bytes, secara khas, dipengaruhi oleh hal-hal berikut.

• Commit heap native yang dipakai HeapAlloc, malloc, new, dan semacamnya
• Private Data yang dikomit langsung dengan VirtualAlloc
• Wilayah heap GC .NET yang sudah dikomit
• Bagian thread stack yang benar-benar dikomit
• Commit Charge untuk seluruh view yang dicadangkan saat memetakan view Copy-on-write (FILE_MAP_COPY)
• Buffer privat yang dipegang secara internal oleh pustaka atau SDK perangkat

Pada view Copy-on-write yang dibuat dengan FILE_MAP_COPY, setiap halaman dapat menjadi Private di kemudian hari, sehingga Windows pada saat pemetaan mencadangkan Commit Charge agar seluruh view dapat ditopang oleh page file. Karena itu, bahkan sebelum ada penulisan yang membuat salinan Private, System Commit dan Commit Charge proses (Private Bytes) dapat naik sebesar seluruh view.¹¹

5.1. Mengapa Private Bytes tidak turun setelah free atau GC

Bahkan jika dari sudut pandang aplikasi memori sudah “dilepas”, runtime atau heap allocator kadang tidak Decommit wilayah itu ke OS, melainkan menahannya untuk dipakai ulang. Dalam kasus itu, di dalam aplikasi wilayah itu sudah dapat dipakai ulang, tetapi Private Bytes tetap tinggi.

Nilai juga bisa bertahan tinggi karena hanya sebagian wilayah besar yang masih hidup, karena fragmentasi, atau karena cache dan pool sudah “panas” sampai batasnya.

Jadi, Private Bytes yang tinggi saja tidak membuktikan kebocoran. Yang perlu dilihat adalah perbandingan selisih waktu berikut.

1. Ulangi pemrosesan yang sama dengan jumlah yang sama
2. Setelah pemrosesan, tunggu selama waktu yang sama
3. Apakah Private Bytes kembali ke tingkat yang sama, atau berhenti di suatu nilai
4. Dengan VMMap atau heap dump, konfirmasikan wilayah atau tipe mana yang bertambah

flowchart TB
    accTitle: Mengapa Private Bytes tidak turun setelah free atau GC
    accDescr: Perubahan Private Bytes berbeda jika allocator mengembalikan wilayah yang tidak lagi dibutuhkan aplikasi ke OS, atau menahannya untuk dipakai ulang
    release["Aplikasi menandai tidak dibutuhkan lewat free / GC"]
    release --> decision{"Apakah allocator mengembalikan ke OS"}
    decision -->|Decommit / Release| returned["Commit Charge berkurang"]
    returned --> lower["Private Bytes turun"]
    decision -->|Ditahan untuk dipakai ulang| retained["Wilayah tetap sudah Commit"]
    retained --> high["Private Bytes bertahan tinggi"]
    retained --> reasons["Pool, cache, fragmentasi"]

Gambar 6: Bisa dipakai ulang di dalam aplikasi tidak sama dengan mengembalikan Commit ke OS.

5.2. Bentuk yang kuat sebagai kandidat kebocoran

Peningkatan “bertangga” yang dasarnya naik setiap kali ada beban, seperti berikut, perlu diwaspadai.

Private Bytes
  ^
  |                    ________
  |             ______|
  |      ______|
  |_____|
  +----------------------------> pengulangan pemrosesan yang sama

Namun, bahkan jika bertangga, nilainya kadang naik hanya beberapa kali karena JIT pertama, font, decoder gambar, connection pool, atau pemanasan cache, lalu stabil. Yang penting bukan sedang naik, melainkan tidak konvergen ke keadaan mantap.

6. System Commit — apa sebenarnya “Committed X/Y”

“Committed X/Y” di [Performance] → [Memory] pada Task Manager adalah metrik seluruh sistem.

• X: System Commit Charge
  Memori yang saat ini dijanjikan Windows untuk ditopang di seluruh sistem
• Y: System Commit Limit
  Batas atas jumlah commit yang dapat ditopang sistem

Commit Limit kira-kira ditentukan oleh jumlah RAM fisik plus semua page file. Jika tidak ada page file, nilainya sedikit lebih kecil daripada RAM terpasang.³⁶

flowchart TB
    accTitle: Hubungan System Commit Charge dan Commit Limit
    accDescr: Commit privat proses, shared section, dan kernel membentuk nilai saat ini X; RAM fisik dan page file menopang batas Y
    processCommit["Private Commit tiap proses"] --> charge["System Commit Charge: X"]
    sharedCommit["Commit shared section yang ditopang page file"] --> charge
    kernelCommit["Commit kernel"] --> charge
    physicalRam["RAM fisik"] --> limit["System Commit Limit: Y"]
    pageFiles["Page file"] --> limit
    charge -->|X tidak dapat melebihi Y| limit

Gambar 7: X adalah jumlah yang saat ini dijanjikan, Y adalah batas yang dapat menopang janji itu; ini bukan tampilan pemakaian page file.

System Commit Charge tidak hanya jumlah Private Bytes tiap proses, tetapi juga mencakup Commit shared section yang ditopang page file, serta Commit yang dikonsumsi kernel. Karena itu, jumlah Private Bytes per proses saja tidak menjelaskan X secara lengkap.

6.1. Commit Charge bukan pemakaian page file

Bayangkan sistem dengan RAM 16GB, page file 16GB, dan Committed 20/31GB.

20GB ini tidak berarti “20GB ditulis ke page file”. 20GB adalah total yang dijanjikan Windows: untuk halaman privat yang dapat diubah dan semacamnya, backing di RAM atau page file akan disiapkan ketika dibutuhkan.

Pada saat itu, keadaan berikut tercampur.

• Banyak yang residen di RAM
• Sebagian diusir ke page file
• Sudah dikomit tetapi belum pernah diakses pertama kali
• Dikonsumsi sebagai commit di sisi kernel

Jika ingin melihat pemakaian nyata page file, periksa Paging File(*)\% Usage terpisah dari Commit. Namun, bahkan dalam dokumentasi Microsoft, pemakaian page file yang tinggi saja tidak otomatis berarti masalah kinerja; penilaian dilakukan bersama pencapaian Commit Limit, Modified Page List, dan I/O paging yang sebenarnya.⁶

6.2. Apa yang terjadi ketika mendekati Commit Limit

Jika System Commit Charge mencapai Commit Limit, permintaan commit baru tidak dapat ditopang. Ini dapat berujung pada kegagalan alokasi memori proses, crash aplikasi, atau sistem yang tidak dapat dioperasikan.³

Di sini, X/Y Commit lebih penting daripada “RAM kosong”. Meski Working Set di-Trim untuk membuat RAM kosong, pencapaian Commit Limit tidak teratasi jika Commit Charge itu sendiri tidak berkurang.

6.3. Tiga peran page file

Page file terutama punya peran berikut.

1. Memperluas Commit Limit
2. Memungkinkan halaman yang sudah diubah dan jarang dipakai diusir dari RAM
3. Menopang crash dump sistem sesuai konfigurasi

Menonaktifkan page file tidak punya hubungan sederhana bahwa I/O disk pasti berkurang lalu sistem menjadi lebih cepat. Justru batas commit turun, halaman yang sudah diubah tetapi untuk sementara tidak dipakai lebih mudah tertinggal di RAM, dan dump yang dibutuhkan saat crash mungkin tidak dapat diambil.³⁶

Ukuran page file yang tepat tidak ditentukan oleh RAM terpasang saja. Microsoft juga menjelaskan bahwa puncak System Commit Charge dan jenis crash dump yang dibutuhkan berbeda per sistem, sehingga tidak dapat digeneralisasi.⁶

7. Rincian RAM fisik — jangan menilai hanya karena Available rendah

RAM fisik tidak hanya dipakai Working Set proses pengguna.

• Working Set tiap proses
• Cache berkas sistem
• Daftar halaman seperti Standby, Modified, Free, Zeroed
• Paged Pool / Nonpaged Pool kernel
• Memori yang dipegang device driver
• Store kompresi memori
• Wilayah yang dibagi atau dicadangkan bersama GPU dan perangkat
• Reservasi perangkat keras

7.1. Available juga mencakup cache yang dapat dipakai ulang

Available MBytes Windows bukan sekadar RAM yang sama sekali tidak terpakai. Ia mencakup Free dan Zeroed, plus halaman Standby yang dapat dipakai ulang jika diperlukan.¹²

• Free: halaman yang saat ini tidak dialokasikan untuk keperluan apa pun
• Zeroed: halaman yang sudah di-nol-kan agar aman diserahkan ke proses lain
• Standby: halaman yang keluar dari Working Set, tetapi isinya masih di-cache di RAM
• Modified: halaman yang isinya berubah, dan sebelum dipakai ulang harus ditulis kembali ke backing yang sesuai

flowchart TB
    accTitle: Perpindahan antara Working Set dan daftar halaman
    accDescr: Halaman yang sedang dipakai pindah ke Standby jika tidak diubah, ke Modified jika sudah diubah, lalu melalui akses ulang, penulisan kembali, atau pemakaian ulang
    workingSet["Working Set: sedang dipakai"]
    workingSet -->|Keluarkan halaman yang tidak diubah| standby["Standby: kandidat dipakai ulang, isi tetap"]
    workingSet -->|Keluarkan halaman yang sudah diubah| modified["Modified: menunggu penulisan kembali"]
    modified -->|Penulisan kembali selesai| standby
    standby -->|Akses ulang| workingSet
    standby -->|Dipakai ulang untuk keperluan lain| reused["Dialokasikan ke keperluan lain"]
    free["Free: tidak terpakai"] -->|Di-nol-kan| zeroed["Zeroed: siap alokasi baru"]
    zeroed -->|Akses setelah alokasi| workingSet
    standby -.-> available["Termasuk dalam Available"]
    free -.-> available
    zeroed -.-> available

Gambar 8: Available mencakup bukan hanya kekosongan penuh, tetapi juga Standby yang dapat dipakai ulang jika diperlukan.

“Membuang seluruh cache agar RAM kosong bertambah” tidak selalu menguntungkan. Jika data yang dibutuhkan masih ada di Standby, pada akses ulang ia dapat dikembalikan cepat ke Working Set tanpa membaca disk.

Jadi, meski Free di Task Manager sedikit, jika Available cukup dan hard page fault maupun tunggu disk tidak menjadi masalah, Windows mungkin hanya memakai RAM secara efektif sebagai cache.

7.2. Ketika RAM berkurang tanpa proses besar

Konsumsi memori yang tidak terjelaskan meskipun Private Working Set tiap proses dijumlahkan bukan hal langka.

• Cache berkas atau berkas yang dipetakan ke memori
• Nonpaged Pool / Paged Pool
• Halaman yang dikunci driver
• Halaman bersama
• Kompresi memori
• Alokasi terkait virtualisasi atau GPU

Dalam kasus itu, daripada terus memandang daftar proses, periksa Use Counts, Processes, Priority Summary, dan File Summary di RAMMap Sysinternals. RAMMap adalah alat resmi untuk mengurai memori fisik per keperluan, per daftar halaman, dan per berkas.¹³

Jika yang terus naik hanya Nonpaged Pool, tahap berikutnya adalah mencurigai kebocoran di sisi driver atau kernel, bukan Private Bytes aplikasi mode pengguna.

8. Page Fault — banyak saja belum tentu abnormal

Ketika proses mengakses halaman yang saat ini tidak ada di Working Set, terjadi Page Fault. Namanya mengandung “Fault”, tetapi ini bukan kerusakan yang luar biasa, melainkan mekanisme biasa yang menggerakkan memori virtual.¹

8.1. Soft page fault

Yang dapat diselesaikan tanpa membaca disk.

• Halaman masih ada di Standby atau Transition
• Proses lain punya halaman bersama yang sama di Working Set-nya
• Halaman yang sudah dikomit diakses pertama kali, lalu halaman nol dialokasikan
• Halaman sudah ada di RAM karena prefetch memory manager

Karena itu, meski \Memory\Page Faults/sec besar, I/O disk atau latensi tidak selalu terjadi.

8.2. Hard page fault

Yang memerlukan pembacaan isi dari Backing Store di disk. Sumber bacaan tidak terbatas pada page file.

• Kode dan data .exe atau .dll
• Berkas yang dipetakan ke memori
• Page file

flowchart TB
    accTitle: Percabangan soft page fault dan hard page fault
    accDescr: Ketika halaman di luar Working Set diakses, diproses sebagai soft page fault jika I/O penyimpanan tidak perlu, atau hard page fault jika perlu
    access["Akses ke halaman yang tidak ada di Working Set"] --> storageIo{"Apakah I/O penyimpanan diperlukan"}
    storageIo -->|Tidak: Standby, bersama, Demand-zero, dll.| soft["Soft page fault"]
    soft --> resident["Masuk Working Set tanpa membaca disk"]
    storageIo -->|Ya| hard["Hard page fault"]
    hard --> source{"Dibaca dari mana"}
    source --> image["EXE / DLL"]
    source --> mapped["Berkas yang dipetakan ke memori"]
    source --> pagefile["Page file"]
    image --> loaded["Setelah dimuat, masuk Working Set"]
    mapped --> loaded
    pagefile --> loaded

Gambar 9: Nama Page Fault saja tidak cukup untuk menentukan ada-tidaknya I/O disk.

Microsoft menyebutkan \Memory\Pages/sec, \Memory\Page Reads/sec, \Memory\Pages Input/sec, dan semacamnya sebagai counter untuk mengukur hard fault. Tingginya nilai ini pun tidak selalu berarti memori rendah, sehingga dikorelasikan dengan Available MBytes, latensi disk, dan waktu respons yang sebenarnya.⁶

8.3. Jangan memasang ambang yang seragam

Nilai tetap seperti “abnormal jika Page Faults/sec melebihi 1000” berubah artinya tergantung penyimpanan, ukuran halaman, workload, dan lokalitas akses.

Dalam praktik, susun yang berikut pada sumbu waktu yang sama.

• Memory\Available MBytes
• Memory\Pages Input/sec
• Memory\Page Reads/sec
• Read latency / Queue disk yang terkait
• Working Set dan Private Bytes proses sasaran
• Waktu pemrosesan aplikasi, timeout, respons UI

Jika Available turun bersamaan dengan naiknya beban, Pages Input/sec dan tunggu disk naik, dan waktu pemrosesan juga memburuk, maka bukti untuk mencurigai paging akibat tekanan memori fisik sudah terkumpul.

9. Layar dan alat mana yang melihat apa

flowchart TB
    accTitle: Memilih alat investigasi memori Windows
    accDescr: Pilih alat berdasarkan apakah sasarannya satu proses atau seluruh sistem, satu titik waktu atau deret waktu, dan apakah perlu menelusuri sampai ke dalam runtime
    question["Apa yang ingin diisolasi"]
    question --> processScope{"Sasarannya satu proses"}
    processScope -->|Ya| processTime{"Satu titik waktu atau deret waktu"}
    processTime -->|Rincian satu titik waktu| vmmap["VMMap"]
    processTime -->|Deret waktu| perfmon["PerfMon / PowerShell"]
    processScope -->|Seluruh sistem| systemView{"Rincian RAM fisik atau sumbu waktu"}
    systemView -->|Rincian RAM fisik| rammap["RAMMap"]
    systemView -->|Sumbu waktu termasuk CPU, I/O, tunggu| wpa["WPR / WPA"]
    question --> runtime{"Apakah menelusuri sampai yang dipegang di dalam runtime"}
    runtime -->|Heap .NET| dotnet["dotnet-dump / PerfView"]
    runtime -->|Heap native| native["WinDbg / Application Verifier"]

Gambar 10: Jika lingkup sasaran dan sumbu waktu diputuskan lebih dulu, alat yang dibutuhkan dapat dipilih tanpa kekurangan atau kelebihan.

9.1. Task Manager

Di Task Manager, lihat layar secara terpisah.

• [Processes] atau [Details]: keluarga Working Set dan keluarga Commit Size per proses
• [Performance] → [Memory]: In use, Available, Committed, Cached, Paged pool, Non-paged pool seluruh sistem

Jangan menilai hanya dari nama kolom “Memory”. Klik kanan judul kolom di tab [Details], lalu tambahkan kolom yang dibutuhkan seperti Working Set, Peak Working Set, dan Commit Size. Nama kolom sedikit berbeda tergantung versi Windows dan bahasa tampilan, jadi catat setelah mengonfirmasi arti kolom.

9.2. Mengambil deret waktu dengan PowerShell

Jika ID proses sasaran sudah diketahui, Get-Process dapat mengambil kemiringan Working Set, Private Bytes, dan Virtual Bytes secara bersamaan.

param(
    [Parameter(Mandatory)]
    [int]$ProcessId,

    [int]$IntervalSeconds = 5,
    [int]$SampleCount = 60
)

$samples = for ($i = 0; $i -lt $SampleCount; $i++) {
    $process = Get-Process -Id $ProcessId -ErrorAction Stop

    [pscustomobject]@{
        Timestamp      = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
        ProcessId      = $process.Id
        WorkingSetMB   = [math]::Round($process.WorkingSet64 / 1MB, 1)
        PrivateBytesMB = [math]::Round($process.PrivateMemorySize64 / 1MB, 1)
        VirtualBytesMB = [math]::Round($process.VirtualMemorySize64 / 1MB, 1)
        Handles        = $process.HandleCount
        Threads        = $process.Threads.Count
    }

    Start-Sleep -Seconds $IntervalSeconds
}

$samples | Format-Table -AutoSize
$samples | Export-Csv .\memory-samples.csv -NoTypeInformation -Encoding utf8

Process.WorkingSet64 .NET sesuai Working Set, PrivateMemorySize64 sesuai Private Bytes, dan VirtualMemorySize64 sesuai Virtual Bytes.¹⁴¹⁵¹⁶

Untuk aplikasi dengan beberapa instans, telusuri dengan PID, bukan nama. Pada pemantauan jangka panjang yang PID-nya berubah karena mulai ulang, perlu rancangan yang mencatat waktu mulai atau nama layanan agar sasaran tidak tertukar.

9.3. Menyatukan sistem dan proses pada sumbu waktu yang sama dengan PerfMon

Paling tidak, mencatat yang berikut secara bersamaan memudahkan isolasi masalah.

\Process(<sasaran>)\ID Process
\Process(<sasaran>)\Working Set
\Process(<sasaran>)\Working Set - Private
\Process(<sasaran>)\Private Bytes
\Process(<sasaran>)\Virtual Bytes

\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Commit Limit
\Memory\Pages Input/sec
\Memory\Page Reads/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes

Jika ada beberapa proses bernama sama, atau jika proses mulai ulang selama pemantauan, nama instans Process(name) atau Process(name#N) saja tidak dapat mengunci sasaran. Catat juga ID Process pada setiap sampel, dan hanya pakai instans yang nilainya cocok dengan PID yang dilacak. Jika melewati mulai ulang yang mengubah PID, catat juga waktu peralihannya secara terpisah.

Nama counter kinerja Windows kadang dilokalkan menurut bahasa tampilan. Jika nama bahasa Inggris yang langsung ditentukan di PowerShell tidak ditemukan, tambahkan dari GUI PerfMon, atau konfirmasikan nama di lingkungan lokal dengan Get-Counter -ListSet *.

9.4. Jangan mencampur peran VMMap dan RAMMap

• VMMap: mengurai memori virtual dan Working Set satu proses ke Heap, Image, Mapped File, Private Data, Managed Heap, dan semacamnya
• RAMMap: mengurai RAM fisik seluruh sistem ke keperluan, daftar halaman, proses, dan berkas

“Apa yang membuat Private Bytes proses ini naik” adalah VMMap; “RAM yang tidak terjelaskan dari daftar proses dipakai untuk apa” adalah RAMMap.¹⁷¹³

10. Membaca gejala dari kombinasi angka

Yang paling penting dari tabel ini: baca dari kombinasi, bukan dari nilai tunggal.

11. Prosedur praktis investigasi kebocoran memori

11.1. Tentukan dulu kondisi reproduksi dan titik mantap

“Naik dalam beberapa hari” saja tidak dapat dibandingkan.

• Sejauh mana pemanasan setelah mulai dimasukkan
• Isi operasi satu siklus
• Berapa detik menunggu setelah satu siklus
• Berapa kali diperlukan sampai batas cache tercapai
• Apakah input yang sama dapat dipakai pada versi normal dan versi bermasalah

tetapkan itu.

11.2. Catat proses dan sistem secara bersamaan

Paling tidak, sisakan yang berikut pada waktu yang sama.

• Working Set sasaran
• Private Bytes sasaran
• Virtual Bytes sasaran
• Committed Bytes / Commit Limit sistem
• Available MBytes
• Pages Input/sec
• Jumlah handle, jumlah thread
• Jumlah operasi atau jumlah pemrosesan

Jika Private Bytes proses stabil tetapi hanya Commit sistem yang naik, perlu memperluas pandangan ke proses lain, kernel, driver, shared section, dan semacamnya.

11.3. Tentukan dulu “dimensi” yang sedang naik

• Hanya Working Set: halaman residen, berasal dari bersama/berkas, Trim dan pemuatan ulang
• Private Bytes: commit privat proses
• Hanya Virtual Bytes: Reserve, pemetaan, fragmentasi ruang alamat
• Hanya System Commit: termasuk proses lain dan sisi kernel
• Nonpaged Pool: sisi driver/kernel
• Handles / GDI / USER: kebocoran sumber daya selain memori

Jika urutan ini dilewati dan dump langsung diambil, yang dibaca adalah informasi dalam jumlah besar dengan sasaran yang salah.

11.4. Maju ke rincian

• Proses native: VMMap, WinDbg, Application Verifier, heap trace
• .NET: dotnet-counters, dotnet-gcdump, dotnet-dump, PerfView
• Seluruh sistem: RAMMap, PerfMon, WPR/WPA
• Pool kernel: PoolMon, WinDbg

VMMap menampilkan memori virtual yang sudah dikomit suatu proses, plus Working Set yang dialokasikan ke masing-masing, per jenis. Sejauh mana kenaikan Private Bytes dapat dipersempit ke “Heap”, “Private Data”, “Managed Heap”, atau “Mapped File” sangat mengubah biaya investigasi berikutnya.¹⁷

11.5. Setelah perbaikan, bandingkan kemiringan pada kondisi yang sama

Hanya berbeda nilai puncak sebelum dan sesudah perbaikan tidak cukup. Jika nilai awal berbeda, urutan mudah terbalik.

• Keadaan mulai yang sama
• Input yang sama
• Jumlah operasi yang sama
• Waktu tunggu yang sama
• Interval sampling yang sama

bandingkan nilai dasar setelah tiap siklus dan kemiringannya. Bukti perbaikan kebocoran bukan “nilai maksimum menjadi lebih kecil”, melainkan kenaikan menjadi konvergen meski beban yang sama diulang.

12. Mengatakan ulang kesalahpahaman yang sering muncul

Kesalahpahaman 1: memori di Task Manager = seluruh jumlah yang dialokasikan aplikasi

Dengan kata lain: Konfirmasikan kolom mana. Jika keluarga Working Set, itu jumlah yang saat ini residen di RAM; jika keluarga Commit Size, itu jumlah commit privat proses.

Kesalahpahaman 2: Private Bytes = jumlah byte di page file

Dengan kata lain: Private Bytes adalah Commit Charge privat. Ini jumlah janji logis yang mencakup halaman yang ada di RAM maupun halaman yang, jika perlu, dapat ditopang page file.

Kesalahpahaman 3: Commit X/Y = pemakaian page file / kapasitas page file

Dengan kata lain: X adalah Commit Charge seluruh sistem, Y adalah Commit Limit. Page file memperluas Y, tetapi X tidak otomatis menjadi pemakaian di disk.

Kesalahpahaman 4: Page Faults/sec tinggi = sedang swap ke disk

Dengan kata lain: Soft fault juga termasuk. Apakah ada I/O disk dikonfirmasi dengan Pages Input/sec atau Page Reads/sec plus latensi disk.

Kesalahpahaman 5: Free RAM sedikit = kekurangan memori

Dengan kata lain: Lihat Available, Standby, hard paging, dan waktu respons. Mengisi RAM dengan cache yang dapat dipakai ulang adalah normal.

Kesalahpahaman 6: Working Set berhasil dikecilkan = kebocoran memori sudah diperbaiki

Dengan kata lain: Mungkin hanya halaman yang diusir dari RAM. Konfirmasikan apakah Private Bytes dan yang dipegang di dalam heap berkurang.

Kesalahpahaman 7: Private Bytes naik = kebocoran sudah pasti

Dengan kata lain: Baru dapat dinilai setelah mengonfirmasi apakah konvergen ketika workload yang sama diulang, jenis memori mana yang bertambah, dan apakah itu cache yang dapat dilepas.

13. Ringkasan

• “Pemakaian memori” Windows bukan satu angka. Pisahkan ruang alamat, commit, keberadaan di RAM, dan kemungkinan berbagi.
• Working Set adalah halaman yang saat ini ada di RAM, mencakup Private dan Shared. Private Working Set adalah halaman residen privat proses di antaranya.
• Private Bytes adalah Commit Charge privat proses; bukan jumlah yang saat ini di RAM, dan bukan jumlah yang benar-benar ditulis ke page file.
• Committed X/Y adalah Commit Charge / Commit Limit seluruh sistem. Page file terutama menopang Commit Limit, pengusiran halaman yang sudah diubah, dan crash dump.
• Alamat virtual yang di-Reserve, halaman yang di-Commit, dan halaman yang benar-benar disentuh lalu masuk Working Set adalah tahap yang berbeda.
• Page Fault adalah operasi biasa; soft fault tidak membaca disk. Hard fault pun tidak hanya dari page file, tetapi juga dari EXE, DLL, dan berkas terpetakan.
• Kebocoran memori dibuktikan bukan dari ukuran pada satu titik waktu, melainkan dari nilai dasar dan kemiringan setelah beban yang sama, plus rinciannya.
• Rincian proses individual: VMMap; RAM fisik seluruh sistem: RAMMap; deret waktu: PerfMon; bagian dalam runtime: alat dump khusus — itu pola dasarnya.

Berikutnya, jika menyadari “memori sedang naik” di Task Manager, tanyakan ulang dulu seperti ini.

Yang naik itu Working Set, Private Bytes, Virtual Bytes, atau System Commit?

Hanya dengan pertanyaan ini, pintu masuk investigasi menjadi jauh lebih tepat.

Artikel terkait

• Membedakan menunggu GC dan memory leak di .NET — prosedur praktis mengamati, membandingkan, dan membuktikan pertumbuhan memori
• Process Explorer / Handle / VMMap dalam praktik — menelusuri hang, kebocoran, dan “berkas sedang dipakai” dari keadaan saat ini
• Jebakan shared memory dan praktik terbaik — merancang berbagi antarproses di Windows dengan aman
• Delayed write Cache Manager Windows — dari WriteFile sampai tiba di disk
• Penyebab dan penanganan crash setelah operasi jangka panjang akibat kebocoran handle di aplikasi Windows

Area konsultasi terkait

Di Komura Soft LLC, kami menangani investigasi penyebab pertumbuhan memori aplikasi Windows, penurunan kinerja setelah operasi jangka panjang, OutOfMemory proses 32-bit, dan kekurangan memori yang hanya muncul di lingkungan pelanggan, dengan kombinasi PerfMon, VMMap, RAMMap, WinDbg, dan alat diagnostik .NET. Kami tidak berhenti pada “memorinya banyak”, melainkan mengisolasi wilayah mana, pada operasi mana, mengapa naik, dan dari mana masih direferensikan atau ditahan.

• Pengembangan aplikasi Windows
• Investigasi gangguan dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Kontak

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apakah kolom "Memory" di Task Manager adalah seluruh memori yang dialokasikan aplikasi?

Tidak. Task Manager punya beberapa kolom memori — keluarga Working Set, keluarga Private Working Set, Commit Size, dan lainnya — dan artinya berubah tergantung layar serta kolom yang dilihat. Working Set adalah halaman yang saat ini ada di RAM; Private Bytes atau Commit Size adalah jumlah commit yang khusus milik proses itu. Jangan menafsirkan satu kolom "Memory" sebagai total kapasitas yang dialokasikan aplikasi, atau sebagai ukuran kebocoran.

Apa perbedaan Working Set dan Private Bytes?

Working Set adalah jumlah halaman yang terlihat oleh proses itu dan saat ini residen di RAM fisik, termasuk halaman yang dapat dibagi seperti kode DLL dan berkas yang dipetakan ke memori. Private Bytes adalah jumlah memori yang sudah dikomit secara eksklusif untuk proses itu, terlepas dari apakah saat ini residen di RAM. Karena itu keduanya tidak menjadi nilai yang sama, dan juga bukan hubungan lebih besar/lebih kecil yang sederhana.

Apakah "Committed 18/32GB" di Task Manager berarti 18GB ditulis ke page file?

Bukan. Angka kiri adalah jumlah commit yang saat ini dijanjikan seluruh sistem; angka kanan adalah batas commit yang dapat ditopang sistem. Batas itu kira-kira ditentukan oleh jumlah RAM plus page file, tetapi seluruh angka kiri tidak berada di page file. Banyak halaman yang sudah dikomit ada di RAM, dan ada pula halaman yang belum pernah mendapat halaman fisik sama sekali. Di sisi lain, halaman yang dapat dimuat ulang dari berkas asalnya — seperti EXE, DLL, dan berkas yang dipetakan ke memori — tidak selalu menaikkan Commit privat sebesar kenaikan Working Set-nya.

Bisakah OutOfMemory terjadi meskipun masih ada RAM kosong?

Bisa. Selain RAM fisik, alokasi dapat gagal karena ruang alamat virtual proses 32-bit habis, tidak ada rentang alamat kosong yang berurutan, batas commit sistem, atau batas khusus Job Object maupun runtime. Khususnya, proses 32-bit di Windows 64-bit biasanya hanya punya ruang alamat virtual mode pengguna 2GB, kecuali ia Large Address Aware.

Apakah menonaktifkan page file membuat Windows lebih cepat?

Secara umum, tidak bisa dipastikan bahwa sistem menjadi lebih cepat. Menonaktifkan page file menurunkan batas commit sistem, mempersulit pengusiran halaman yang sudah diubah tetapi tidak terpakai dari RAM, dan memengaruhi konfigurasi crash dump. Ukuran page file harus diputuskan setelah mengukur commit puncak dan crash dump yang dibutuhkan — ini bukan pengaturan untuk dinonaktifkan tanpa dasar.

Apakah Page Faults/sec yang tinggi berarti sistem kekurangan memori?

Itu saja tidak cukup untuk menilainya. Page fault mencakup soft fault, yang dapat diselesaikan dari halaman Standby di RAM atau halaman yang dibagi dengan proses lain, dan hard fault, yang membaca dari disk. Jangan melihat Page Faults/sec sendirian; periksa Pages Input/sec, Page Reads/sec, Available MBytes, latensi disk, dan waktu pemrosesan pada sumbu waktu yang sama.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.