Apa arti "pemakaian memori" Windows sebenarnya? — Membaca Working Set, Private Bytes, Commit, dan page file dengan benar

Task Manager menampilkan “Memory” suatu proses sebagai 1,2GB. Namun Process Explorer menampilkan Working Set 1,5GB dan Private Bytes 2,4GB, dan Size di VMMap lebih besar lagi. Melihat sistem secara keseluruhan, tertulis “Committed 19,6/31,8GB”.

Jadi, pada akhirnya, berapa gigabyte memori yang sungguh-sungguh dipakai aplikasi ini?

Jawabannya: angka mana yang harus Anda lihat bergantung pada apa yang sebenarnya ingin Anda ketahui. Metrik yang dipakai berbeda tergantung apakah Anda ingin tahu jumlah yang saat ini residensial di RAM, jumlah yang dialokasikan khusus untuk proses itu, jumlah yang dijanjikan sistem untuk tetap ditopang di masa depan, atau sekadar rentang alamat virtual yang telah direservasi.

Yang membuat metrik memori Windows membingungkan adalah semuanya ditampilkan di bawah kata yang sama, “memori”, padahal sebenarnya mengukur sumbu-sumbu terpisah berikut.

• Seberapa banyak ruang alamat yang terpakai
• Seberapa banyak commit yang telah dikonsumsi
• Apakah saat ini residensial di RAM fisik
• Apakah halaman itu privat bagi proses, atau dapat dibagi
• Seberapa banyak alokasi lagi yang masih dapat ditopang sistem secara keseluruhan

Artikel ini ditujukan bagi siapa pun yang menyelidiki memori aplikasi yang tumbuh atau kekurangan memori di seluruh sistem pada Windows 10/11 dan Windows Server terkini, dan merangkai, dalam satu gambar, hubungan antara 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 jeda GC dari kebocoran memori 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 kumpulan halaman yang saat ini residensial 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 proses ini sendiri”, tetapi bukan total yang dialokasikan aplikasi.²
• Private Bytes adalah jumlah commit yang privat bagi proses itu. Ini metrik terpisah dari apakah memori saat ini residensial 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 total commit sistem saat ini dan Y sebagai plafon commit. X bukan pemakaian page file. Y ditentukan kira-kira oleh 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 plafon 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 tren ketika beban yang sama diulang. Khususnya, perhatikan apakah Private Bytes dan rinciannya terus merangkak 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 bergantung pada apakah Anda ingin tahu residensi RAM, commit privat proses, commit seluruh sistem, atau rentang alamat virtual
    question["Apa yang ingin Anda ketahui tentang pemakaian memori"]
    question -->|jumlah saat ini di RAM| workingSet["Working Set"]
    question -->|jumlah dijanjikan privat proses| privateBytes["Private Bytes"]
    question -->|jumlah dijanjikan seluruh sistem| systemCommit["System Commit"]
    question -->|rentang alamat yang direservasi| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["Residensi 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.

2. Memecah “pemakaian memori” menjadi empat sumbu

Sebagai permulaan, pikirkan memori Windows bukan sebagai “satu batang”, melainkan sepanjang empat sumbu.

flowchart TB
    accTitle: Empat sumbu independen untuk mengklasifikasi satu halaman
    accDescr: Periksa keadaan alamat virtual, backing halaman yang dikomit, residensi di RAM fisik, dan kemampuan dibagi dengan proses lain secara terpisah
    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["Residensi RAM"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["Kemampuan dibagi"]
    sharing --> sharingValues["Private / Shareable"]

Gambar 2: Bahkan untuk satu halaman, keadaan alamat, backing, residensi, dan kemampuan dibagi masing-masing ditentukan secara independen.

Mapped bukan keadaan alamat di samping Free, Reserved, dan Committed — ia adalah kategori wilayah. Halaman dalam view yang dipetakan juga dapat Committed. Demikian pula, Private bukan media backing melainkan klasifikasi kemampuan dibagi. Jadi baca backing sebagai Page-file-backed atau File-backed, dan kemampuan dibagi sebagai Private atau Shareable, secara terpisah.

Menggabungkan keempat sumbu ini memberi hubungan antara metrik perwakilan sebagai berikut.

flowchart TB
    accTitle: Pemetaan jenis halaman ke metrik memori utama
    accDescr: Menunjukkan metrik mana yang mencakup halaman privat residensial, halaman privat nonresidensial, halaman bersama residensial, dan rentang hanya-reservasi
    privateResident["Privat, dikomit, residensial RAM"]
    privateNonresident["Privat, dikomit, tidak residensial RAM"]
    sharedResident["Halaman bersama, residensial RAM"]
    reservedOnly["Direservasi, tidak dikomit"]
    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 kumpulan halaman yang berbeda, jadi keduanya tidak dalam hubungan penahanan sederhana.

Poin pentingnya di sini: Working Set dan Private Bytes tidak dalam hubungan penahanan sederhana.

Private Bytes mencakup halaman yang privat bagi proses tetapi saat ini tidak residensial di RAM. Working Set, di sisi lain, mencakup halaman bersama — seperti kode DLL dan memori bersama — yang sama sekali tidak dihitung Private Bytes. Jadi tergantung proses dan momen waktunya, Working Set dapat lebih besar dari Private Bytes, atau sebaliknya.

Juga, sekadar menjumlahkan Working Set beberapa proses dapat menghitung halaman fisik yang sama — misalnya DLL bersama — lebih dari sekali. “Jumlah Working Set tiap proses sama dengan RAM yang terpakai” tidak selalu berlaku.

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

3.1. Alamat virtual bukan alamat RAM fisik

Setiap proses punya ruang alamat virtual privat sendiri. Pointer yang dikerjakan aplikasi tidak langsung menunjukkan lokasi di RAM fisik; Windows memakai tabel halaman untuk memetakan alamat virtual ke halaman fisik atau ke data pada berkas.⁷

Akibatnya, bahkan di PC dengan 64GB RAM terpasang, ruang alamat virtual yang dapat dipakai suatu proses 32-bit biasanya jauh lebih kecil dari itu. Sebaliknya, wajar juga bagi proses 64-bit untuk punya ruang alamat virtual yang lebih besar dari RAM fisik.

3.2. Reserved hanya berarti “alamatnya sudah dipatok”

MEM_RESERVE milik VirtualAlloc mereservasi rentang alamat virtual berurutan untuk pemakaian di masa depan. Pada tahap ini tidak ada penyimpanan fisik yang diasosiasikan dengan halaman, dan rentang itu tidak dapat dibaca atau ditulis.⁴⁵

Misalnya, meski basis data atau runtime mereservasi rentang alamat 8GB untuk pertumbuhan di masa depan, itu saja tidak mengonsumsi 8GB RAM atau 8GB Private Bytes.

3.3. Committed adalah janji untuk “menopangnya ketika dibutuhkan”

MEM_COMMIT adalah operasi yang menempatkan halaman virtual ke keadaan Committed dan membuat Windows berjanji menyediakan backing yang diperlukan. Apakah membaca, menulis, atau eksekusi benar-benar diizinkan diputuskan secara terpisah oleh proteksi halaman — PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, PAGE_NOACCESS, dan sebagainya — jadi Committed sendiri tidak berarti “dapat dibaca dan ditulis”. Saat dikomit, ia dihitung ke Commit Charge sistem, tetapi halaman fisik aktual mungkin belum ditetapkan sampai akses pertama. Halaman yang disentuh pertama kali diinisialisasi nol, melalui demand-zero fault, dan masuk Working Set.⁵¹

Jadi meski kita menyebutnya “dialokasikan” dalam kedua kasus, sebenarnya ada tiga tahap berikut.

flowchart TB
    accTitle: Tiga tahap dari Reserve melalui Commit hingga residensi RAM
    accDescr: Menunjukkan alur mereservasi alamat virtual, mengomit halaman, dan akses pertama yang menetapkan halaman fisik lalu masuk Working Set
    reserve["MEM_RESERVE - reservasi rentang alamat"]
    reserve -.-> virtualMetric["Tercermin di keluarga Virtual Bytes"]
    reserve -->|MEM_COMMIT| committed["Committed - dapat diakses sesuai proteksi halaman"]
    committed -.-> commitMetric["Tercermin di Private Bytes / System Commit"]
    committed -->|akses pertama, demand-zero fault| resident["Halaman fisik ditetapkan, residensial RAM"]
    resident -.-> workingSetMetric["Tercermin di Working Set"]
    committed -.->|jika tidak pernah diakses| nonresident["Dikomit tetapi tidak residensial"]

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

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

3.4. Mengapa OutOfMemory dapat terjadi meski masih ada RAM kosong

Keberhasilan alokasi memori tidak ditentukan oleh RAM kosong saja.

• Proses telah menghabiskan ruang alamat virtualnya
• Tidak ada rentang alamat kosong berukuran yang dibutuhkan yang berurutan
• Commit Charge seluruh sistem telah mencapai Commit Limit
• Job Object, kontainer, runtime, atau pustaka punya batas sendiri
• Itu proses 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 tidak disetel. Aplikasi 32-bit dengan bendera itu dapat memakai hingga 4GB di Windows 64-bit.⁸

Jadi “PC punya 20GB RAM kosong, namun aplikasi 32-bit gagal di sekitar 1,6GB” bukan kontradiksi. Itu mungkin sama sekali bukan masalah RAM, melainkan fragmentasi ruang alamat atau batas keras yang terantuk.

4. Working Set — halaman yang saat ini di RAM

Working Set adalah kumpulan halaman, di dalam ruang alamat virtual suatu proses, yang saat ini residensial di RAM fisik.¹

Kumpulan ini adalah campuran dari yang berikut.

• Heap dan stack milik proses itu sendiri
• Kode dan data hanya-baca EXE serta 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. Working Set yang tumbuh tidak selalu berarti lebih banyak yang dialokasikan

Mengakses halaman yang sudah dikomit untuk pertama kali dapat menaikkan Working Set saja sementara Private Bytes tetap. Demikian pula, ketika berkas besar dipetakan ke memori dan dibaca berurutan, halaman yang ditopang berkas masuk Working Set sementara Private Bytes hampir tidak naik.

Sebaliknya, ketika Windows merapikan (Trim) Working Set sebagai respons terhadap tekanan memori, Working Set saja menyusut sementara aplikasi secara logis masih menahan memori yang sama. Menyentuhnya lagi nanti mengembalikannya melalui page fault.

Jadi penurunan Working Set tidak selalu berarti “aplikasi membebaskannya”, dan kenaikan tidak selalu berarti “aplikasi baru saja mengalokasikannya”.

flowchart TB
    accTitle: Alur khas di mana hanya Working Set yang naik dan turun
    accDescr: Halaman yang sama yang dikomit masuk RAM pada akses pertama, menjadi nonresidensial saat Trim, dan kembali pada akses ulang, sementara Private Bytes tetap dihitung sepanjang waktu
    committed["Halaman yang sama yang dikomit"]
    committed -->|akses pertama| resident["Residensial RAM"]
    resident -->|Trim di bawah tekanan memori| nonresident["Tidak residensial"]
    nonresident -->|page fault pada akses ulang| resident
    resident -.-> inWorkingSet["Termasuk di Working Set"]
    nonresident -.-> outsideWorkingSet["Tidak termasuk di Working Set"]
    committed -.-> privateBytes["Dihitung di Private Bytes selama dikomit"]

Gambar 5: Working Set naik-turun bersama residensi, tetapi Private Bytes tidak turun selama commit pada halaman yang sama tetap ada.

4.2. Working Set mencakup halaman bersama

Jika 10 proses membagi halaman kode DLL yang sama, halaman itu dapat muncul di Working Set tiap proses, meski hanya satu salinan yang ada di RAM fisik. Jumlah Working Set yang melebihi RAM terpasang bukan segera tanda masalah.

Jika Anda ingin mendekati “RAM yang saat ini ditempati proses ini sendiri”, lihat Private Working Set. Meski begitu, ini juga bukan “semua memori yang telah dialokasikan proses itu” — ia secara ketat halaman privat yang saat ini residensial.

4.3. Memaksa Working Set turun tidak memperbaiki kebocoran

Anda dapat memakai EmptyWorkingSet atau SetProcessWorkingSetSize untuk mengusir halaman dari Working Set suatu proses. Tetapi ini bukan operasi yang membebaskan commit atau melepas referensi di heap. Pemakaian RAM yang tampak turun sementara Private Bytes tetap, dan akses berikutnya dapat memicu ledakan page fault.⁹

Jika angka Task Manager menyusut hanya tepat setelah Anda menekan tombol “kurangi memori”, dan segera naik kembali begitu Anda kembali bekerja, itu mungkin hanya Trim Working Set, bukan “pelepasan” yang sungguhan.

5. Private Bytes — jumlah commit yang privat bagi suatu proses

Private Bytes adalah jumlah memori virtual yang dikomit secara eksklusif untuk proses itu. Ia mewakili Commit Charge yang tidak dapat dibagi dengan proses lain, dan tidak peduli apakah saat ini residensial di RAM. Dalam PROCESS_MEMORY_COUNTERS_EX milik Microsoft, PrivateUsage sesuai dengan nilai ini.¹⁰²

API Win32 juga punya bidang bernama membingungkan, PagefileUsage, tetapi dokumentasi terkini mendefinisikannya sebagai “Commit Charge proses itu” dan menyatakan ia nilai yang sama dengan PrivateUsage. Dengan kata lain, Private Bytes 2GB tidak berarti “2GB telah ditulis ke pagefile.sys”.²

Private Bytes biasanya dipengaruhi oleh yang berikut.

• Commit heap native yang dipakai HeapAlloc, malloc, new, dan semacamnya
• Private Data yang dikomit langsung dengan VirtualAlloc
• Wilayah yang dikomit dari heap GC .NET
• Bagian tumpukan thread yang benar-benar telah dikomit
• Commit Charge untuk seluruh view yang direservasi ketika view copy-on-write (FILE_MAP_COPY) dipetakan
• Buffer privat yang ditahan secara internal oleh pustaka dan SDK perangkat

Dalam view copy-on-write yang dibuat dengan FILE_MAP_COPY, setiap halaman pada akhirnya dapat menjadi privat, jadi pada saat pemetaan Windows mereservasi cukup Commit Charge untuk menopang seluruh view dengan page file. Karena itu, System Commit dan Commit Charge proses (Private Bytes) dapat naik sebesar ukuran seluruh view bahkan sebelum ada tulis yang benar-benar membuat salinan privat.¹¹

5.1. Mengapa Private Bytes tidak turun setelah free atau GC

Bahkan ketika memori “dibebaskan” dari sudut pandang aplikasi, runtime atau pengalokasi heap mungkin tidak mendekomit wilayah itu kembali ke OS, dan justru menahannya untuk dipakai ulang di masa depan. Dalam kasus itu, Private Bytes tetap tinggi meski wilayah itu dapat dipakai ulang secara internal di dalam aplikasi.

Ia juga dapat tetap tinggi karena alasan seperti hanya sebagian dari wilayah besar yang masih hidup, fragmentasi, atau cache atau pool yang telah memanas hingga plafonnya.

Jadi Private Bytes yang tinggi saja tidak membuktikan kebocoran. Yang harus Anda lihat adalah perbandingan sepanjang waktu:

1. Ulangi pemrosesan yang sama sebanyak jumlah yang sama
2. Tunggu sejumlah waktu yang sama setelah pemrosesan
3. Periksa apakah Private Bytes kembali ke tingkat yang sama, atau datar pada nilai tetap
4. Pakai VMMap atau dump heap untuk memeriksa wilayah atau tipe mana yang tumbuh

flowchart TB
    accTitle: Mengapa Private Bytes tidak turun setelah free atau GC
    accDescr: Private Bytes berubah berbeda tergantung apakah pengalokasi mengembalikan ke OS wilayah yang tidak lagi dibutuhkan aplikasi, atau menahannya untuk dipakai ulang
    release["Aplikasi membebaskan wilayah lewat free / GC"]
    release --> decision{"Apakah pengalokasi mengembalikannya ke OS"}
    decision -->|Decommit / Release| returned["Commit Charge menurun"]
    returned --> lower["Private Bytes turun"]
    decision -->|ditahan untuk dipakai ulang| retained["Wilayah tetap dikomit"]
    retained --> high["Private Bytes datar tinggi"]
    retained --> reasons["Pool, cache, fragmentasi"]

Gambar 6: Wilayah yang menjadi dapat dipakai ulang di dalam aplikasi tidak sama dengan Commit-nya dikembalikan ke OS.

5.2. Pola kandidat kuat untuk kebocoran

Kenaikan seperti berikut, di mana lantai merangkak naik setiap putaran beban dalam pola “tangga”, patut diperhatikan.

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

Meski begitu, bahkan bentuk tangga dapat hanya beberapa putaran pertumbuhan dari kompilasi JIT pertama, font, decoder gambar, pool koneksi, atau pemanasan cache, setelah itu ia stabil. Yang penting bukan bahwa ia meningkat, melainkan bahwa ia gagal konvergen ke keadaan mantap.

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

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

• X: System Commit Charge — memori yang dikomit yang saat ini dijanjikan Windows untuk ditopang di seluruh sistem
• Y: System Commit Limit — plafon commit yang dapat ditopang sistem

Commit Limit ditentukan kira-kira oleh RAM fisik plus total semua page file. Tanpa page file, ia keluar sedikit lebih kecil dari RAM terpasang.³⁶

flowchart TB
    accTitle: Hubungan antara System Commit Charge dan Commit Limit
    accDescr: Commit per proses, bagian bersama, dan kernel membentuk nilai saat ini X, sementara RAM fisik dan page file menopang plafon Y
    processCommit["Private Commit tiap proses"] --> charge["System Commit Charge - X"]
    sharedCommit["Commit bagian bersama 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 dijanjikan saat ini dan Y adalah plafon yang dapat menopang janji itu — ini bukan tampilan pemakaian page file.

System Commit Charge mencakup bukan hanya jumlah Private Bytes tiap proses, tetapi juga Commit bagian bersama yang ditopang page file dan Commit yang dikonsumsi kernel. Jadi jumlah Private Bytes per proses saja tidak dapat sepenuhnya menjelaskan X.

6.1. Commit Charge bukan pemakaian page file

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

20GB itu tidak berarti “20GB telah ditulis ke page file”. Itu adalah total yang dijanjikan Windows untuk menyediakan backing RAM atau page file, kapan pun dibutuhkan, bagi halaman privat yang dapat ditulis dan semacamnya.

Pada saat itu, campuran keadaan berikut dapat berlaku:

• Sebagian besar residensial di RAM
• Sebagian telah dipaging-out ke page file
• Sebagian dikomit tetapi belum mendapat akses pertama
• Sebagian dikonsumsi sebagai commit di sisi kernel

Jika Anda ingin melihat pemakaian page file aktual, periksa Paging File(*)\% Usage secara terpisah dari Commit. Bahkan materi Microsoft sendiri menjelaskan bahwa pemakaian page file yang tinggi saja tidak selalu menandakan masalah kinerja, dan bahwa ia harus dinilai bersama dengan mencapai Commit Limit, Modified Page List, dan I/O paging aktual.⁶

6.2. Apa yang terjadi saat Anda mendekati Commit Limit

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

Di sini, X/Y Commit lebih penting daripada “RAM kosong”. Meski Anda merapikan Working Set untuk membebaskan RAM, mencapai Commit Limit tidak terselesaikan kecuali Commit Charge itu sendiri menurun.

6.3. Tiga peran page file

Page file terutama melayani peran berikut.

1. Memperluas Commit Limit
2. Memungkinkan halaman yang diubah dan jarang dipakai dipaging-out dari RAM
3. Menopang crash dump sistem, tergantung konfigurasi

Menonaktifkan page file bukan kasus sederhana “I/O disk selalu turun dan semuanya menjadi lebih cepat”. Justru, ia menurunkan Commit Limit, membuat lebih mungkin halaman yang diubah tetapi saat ini tidak dibutuhkan tetap di RAM, dan dapat membuat mustahil menangkap dump yang Anda butuhkan ketika terjadi crash.³⁶

Ukuran page file yang tepat tidak dapat diputuskan dari RAM terpasang saja. Microsoft sendiri menjelaskan bahwa ini tidak dapat digeneralisasi, karena puncak System Commit Charge dan jenis crash dump yang dibutuhkan berbeda dari sistem ke sistem.⁶

7. Rincian RAM fisik — jangan menilai dari Available yang rendah saja

RAM fisik tidak dipakai semata-mata oleh Working Set proses pengguna.

• Working Set tiap proses
• Cache berkas sistem
• Daftar halaman seperti Standby, Modified, Free, dan Zeroed
• Paged Pool / Nonpaged Pool kernel
• Memori yang ditahan driver perangkat
• Toko kompresi memori
• Wilayah yang dibagi dengan atau direservasi untuk GPU dan perangkat lain
• Memori yang direservasi perangkat keras

7.1. Available mencakup cache yang dapat dipakai ulang juga

Available MBytes Windows bukan sekadar RAM yang sama sekali tidak terpakai. Ia adalah metrik yang, bersama Free dan Zeroed, juga mencakup halaman Standby yang dapat dipakai ulang jika dibutuhkan.¹²

• Free: halaman yang saat ini tidak dialokasikan untuk tujuan apa pun
• Zeroed: halaman yang telah diisi nol agar aman diserahkan ke proses lain
• Standby: halaman yang telah meninggalkan Working Set tetapi isinya masih di-cache di RAM
• Modified: halaman yang isinya telah berubah dan perlu ditulis kembali ke backing yang sesuai sebelum dipakai ulang

flowchart TB
    accTitle: Pergerakan antara Working Set dan daftar halaman
    accDescr: Menunjukkan halaman yang tidak diubah pergi ke Standby dan halaman yang diubah pergi ke Modified, lalu akses ulang, tulis-balik, dan pemakaian ulang
    workingSet["Working Set - sedang dipakai"]
    workingSet -->|halaman tidak diubah dilepas| standby["Standby - kandidat pakai ulang dengan isi dipertahankan"]
    workingSet -->|halaman diubah dilepas| modified["Modified - menunggu tulis-balik"]
    modified -->|tulis-balik selesai| standby
    standby -->|akses ulang| workingSet
    standby -->|dipakai ulang untuk tujuan lain| reused["Dialokasikan ke tujuan lain"]
    free["Free - tidak terpakai"] -->|diisi nol| zeroed["Zeroed - tersedia untuk alokasi baru"]
    zeroed -->|diakses setelah alokasi| workingSet
    standby -.-> available["Termasuk di Available"]
    free -.-> available
    zeroed -.-> available

Gambar 8: Available mencakup bukan hanya memori yang sepenuhnya kosong tetapi juga Standby, yang dapat dipakai ulang jika dibutuhkan.

“Membuang semua cache untuk menambah RAM kosong” tidak selalu menang. Jika data yang Anda butuhkan masih duduk di Standby, mengaksesnya ulang dapat mengembalikannya ke Working Set dengan cepat tanpa membaca dari disk.

Jadi meski Free rendah di Task Manager, jika Available cukup dan hard page fault atau tunggu disk tidak menimbulkan masalah, Windows mungkin sekadar memakai RAM secara efektif sebagai cache.

7.2. Ketika RAM menyusut tanpa ada proses besar

Tidak jarang konsumsi memori tidak dapat dijelaskan bahkan setelah menjumlahkan Private Working Set setiap proses.

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

Dalam kasus ini, alih-alih terus menatap daftar proses, periksa Use Counts, Processes, Priority Summary, dan File Summary di RAMMap Sysinternals. RAMMap adalah alat resmi untuk menguraikan memori fisik menurut tujuan, daftar halaman, dan berkas.¹³

Jika hanya Nonpaged Pool yang terus tumbuh, itu saatnya mencurigai kebocoran di sisi driver atau kernel, bukan Private Bytes aplikasi mode pengguna.

8. Page fault — jumlah tinggi saja belum tentu abnormal

Page Fault terjadi ketika suatu proses mengakses halaman yang saat ini tidak ada di Working Set-nya. Meski ada kata “Fault” dalam namanya, ini bukan kegagalan luar biasa — ini mekanisme normal yang menggerakkan memori virtual.¹

8.1. Soft page fault

Ini diselesaikan tanpa membaca dari disk.

• Halaman masih di Standby atau Transition
• Halaman bersama yang sama sudah ada di Working Set proses lain
• Halaman yang dikomit diakses pertama kali dan halaman nol ditetapkan
• Baca-depan manajer memori sudah membawanya ke RAM

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

8.2. Hard page fault

Ini membutuhkan membaca isi dari Backing Store di disk. Sumbernya tidak terbatas pada page file.

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

flowchart TB
    accTitle: Percabangan antara soft dan hard page fault
    accDescr: Ketika mengakses halaman yang tidak di Working Set, ditangani sebagai soft page fault jika I/O penyimpanan tidak perlu, atau hard page fault jika perlu
    access["Akses halaman yang tidak 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{"Dari mana dibaca"}
    source --> image["EXE / DLL"]
    source --> mapped["Berkas yang dipetakan ke memori"]
    source --> pagefile["Page file"]
    image --> loaded["Masuk Working Set setelah dimuat"]
    mapped --> loaded
    pagefile --> loaded

Gambar 9: Nama “Page Fault” saja tidak dapat memberi tahu apakah I/O disk terjadi.

Microsoft mencantumkan \Memory\Pages/sec, \Memory\Page Reads/sec, dan \Memory\Pages Input/sec di antara penghitung untuk mengukur hard fault. Karena tingginya ini tidak selalu berarti memori rendah, korelasikan dengan Available MBytes, latensi disk, dan waktu respons aktual.⁶

8.3. Jangan menetapkan satu ambang selimut

Nilai tetap seperti “apa pun di atas 1000 Page Faults/sec adalah abnormal” berubah artinya tergantung penyimpanan, ukuran halaman, beban kerja, dan lokalitas akses.

Dalam praktik, sejajarkan yang berikut pada linimasa yang sama.

• Memory\Available MBytes
• Memory\Pages Input/sec
• Memory\Page Reads/sec
• Latensi baca / antrean pada disk sasaran
• Working Set dan Private Bytes proses sasaran
• Waktu pemrosesan aplikasi, timeout, dan responsivitas UI

Jika Available turun bersamaan dengan naiknya beban, Pages Input/sec dan tunggu disk naik, dan waktu pemrosesan juga memburuk, itu memberi Anda dasar untuk mencurigai paging yang disebabkan tekanan memori fisik.

9. Layar atau alat mana yang diperiksa untuk apa

flowchart TB
    accTitle: Memilih alat investigasi memori Windows
    accDescr: Alat yang dipakai bergantung pada apakah sasaran satu proses atau seluruh sistem, satu titik waktu atau deret waktu, dan apakah Anda perlu menelusuri penahanan di dalam runtime
    question["Apa yang ingin Anda isolasi"]
    question --> processScope{"Apakah sasaran satu proses"}
    processScope -->|ya| processTime{"Satu titik waktu atau deret waktu"}
    processTime -->|rincian satu titik| vmmap["VMMap"]
    processTime -->|deret waktu| perfmon["PerfMon / PowerShell"]
    processScope -->|seluruh sistem| systemView{"Rincian RAM fisik atau linimasa"}
    systemView -->|rincian RAM fisik| rammap["RAMMap"]
    systemView -->|linimasa termasuk CPU, I/O, dan tunggu| wpa["WPR / WPA"]
    question --> runtime{"Perlu menelusuri penahanan di dalam runtime"}
    runtime -->|heap .NET| dotnet["dotnet-dump / PerfView"]
    runtime -->|heap native| native["WinDbg / Application Verifier"]

Gambar 10: Memutuskan cakupan dan linimasa lebih dulu memungkinkan Anda memilih tepat alat yang dibutuhkan, tidak lebih dan tidak kurang.

9.1. Task Manager

Di Task Manager, lihat layar-layarnya secara terpisah.

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

Jangan menilai dari kolom bernama “Memory” saja — klik kanan header kolom di tab [Details] dan tambahkan kolom yang Anda butuhkan, seperti Working Set, Peak Working Set, dan Commit Size. Nama kolom sedikit berbeda menurut versi Windows dan bahasa tampilan, jadi pastikan apa arti kolom sebelum Anda mencatatnya.

9.2. Menangkap deret waktu dengan PowerShell

Jika Anda tahu ID proses sasaran, Anda dapat menangkap tren Working Set, Private Bytes, dan Virtual Bytes bersama dengan Get-Process.

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 dengan Working Set, PrivateMemorySize64 dengan Private Bytes, dan VirtualMemorySize64 dengan Virtual Bytes.¹⁴¹⁵¹⁶

Untuk aplikasi dengan beberapa instans, lacak menurut PID, bukan menurut nama. Untuk pemantauan jangka panjang di mana mulai ulang mengubah PID, rancang pengumpulan agar mencatat waktu mulai, nama layanan, dan semacamnya, agar sasaran tidak pernah tertukar.

9.3. Menempatkan sistem dan suatu proses pada linimasa yang sama dengan PerfMon

Mencatat setidaknya yang berikut bersama membuat isolasi jauh lebih mudah.

\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

Ketika beberapa proses berbagi nama yang sama, atau mulai ulang terjadi selama pemantauan, nama instans saja — Process(name) atau Process(name#N) — tidak dapat memaku sasaran. Catat juga ID Process untuk tiap sampel, dan adopsi hanya instans yang nilainya cocok dengan PID yang Anda lacak. Ketika Anda mencakup mulai ulang yang mengubah PID, catat juga waktu peralihannya secara terpisah.

Nama penghitung kinerja Windows dapat dilokalkan tergantung bahasa tampilan. Jika menyebutkan nama Inggris secara langsung di PowerShell gagal menemukannya, tambahkan penghitung lewat GUI PerfMon, atau periksa nama di lingkungan lokal Anda dengan Get-Counter -ListSet *.

9.4. Jangan mencampuradukkan peran VMMap dan RAMMap

• VMMap: menguraikan memori virtual dan Working Set satu proses menjadi Heap, Image, Mapped File, Private Data, Managed Heap, dan semacamnya
• RAMMap: menguraikan RAM fisik seluruh sistem menurut tujuan, daftar halaman, proses, dan berkas

“Apa yang membuat Private Bytes proses ini tumbuh” adalah pekerjaan VMMap; “untuk apa RAM yang tidak dapat dijelaskan daftar proses dipakai” adalah pekerjaan RAMMap.¹⁷¹³

10. Membaca gejala dari kombinasi angka

Hal terpenting dari tabel ini adalah membacanya dalam kombinasi, bukan dari satu nilai saja.

11. Prosedur praktis menyelidiki kebocoran memori

11.1. Putuskan dulu kondisi reproduksi dan titik mantap

“Ia tumbuh selama beberapa hari” saja tidak dapat dibandingkan.

• Seberapa banyak pemanasan pasca-start yang disertakan
• Apa yang terdiri dari satu siklus operasi
• Berapa detik menunggu setelah satu siklus
• Berapa putaran yang dibutuhkan untuk mencapai plafon cache
• Apakah input yang sama dapat dipakai untuk build yang sehat dan yang bermasalah

Putuskan semuanya.

11.2. Catat proses dan sistem secara bersamaan

Minimal, biarkan yang berikut tercatat pada cap 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 item yang diproses

Jika Private Bytes proses stabil sementara Commit sistem terus tumbuh, Anda perlu memperluas cakupan ke proses lain, kernel, driver, dan bagian bersama.

11.3. Putuskan dulu “dimensi” mana yang tumbuh

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

Lewati urutan ini dan langsung mengambil dump, dan Anda berakhir membaca gunung informasi sambil menargetkan hal yang salah.

11.4. Lanjut ke rincian

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

VMMap menampilkan memori virtual yang dikomit suatu proses, dan Working Set yang dialokasikan ke tiap bagiannya, diuraikan menurut jenis. Seberapa jauh Anda dapat mempersempit pertumbuhan Private Bytes ke Heap, Private Data, Managed Heap, atau Mapped File membuat perbedaan besar pada biaya investigasi yang mengikuti.¹⁷

11.5. Setelah perbaikan, bandingkan tren di bawah kondisi yang sama

Tidak cukup puncaknya berbeda sebelum dan sesudah perbaikan. Jika nilai awal berbeda, perbandingan mudah terbalik.

• Keadaan start yang sama
• Input yang sama
• Jumlah operasi yang sama
• Waktu tunggu yang sama
• Interval sampel yang sama

— dan bandingkan nilai lantai serta tren setelah tiap siklus. Membuktikan perbaikan kebocoran bukan “maksimumnya menjadi lebih kecil”, melainkan bahwa pertumbuhan kini konvergen bahkan ketika beban yang sama diulang.

12. Mengungkapkan ulang kesalahpahaman umum

Kesalahpahaman 1: Memory di Task Manager sama dengan total yang dialokasikan aplikasi

Diungkapkan ulang: Periksa kolom mana. Untuk keluarga Working Set ia adalah jumlah yang saat ini residensial di RAM; untuk keluarga Commit Size ia adalah commit yang privat bagi proses itu.

Kesalahpahaman 2: Private Bytes sama dengan byte di page file

Diungkapkan ulang: Private Bytes adalah Commit Charge privat. Ia adalah jumlah yang dijanjikan secara logis yang mencakup baik halaman yang saat ini di RAM maupun halaman yang akan ditopang page file jika dan ketika dibutuhkan.

Kesalahpahaman 3: Commit X/Y sama dengan pemakaian page file / kapasitas page file

Diungkapkan ulang: X adalah Commit Charge seluruh sistem, dan Y adalah Commit Limit. Page file memperluas Y, tetapi X tidak langsung diterjemahkan menjadi pemakaian di disk.

Kesalahpahaman 4: Page Faults/sec tinggi berarti ia sedang menukar ke disk

Diungkapkan ulang: Ini mencakup soft fault juga. Periksa Pages Input/sec, Page Reads/sec, dan latensi disk untuk melihat apakah I/O disk benar-benar terlibat.

Kesalahpahaman 5: RAM Free rendah berarti memori kurang

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

Kesalahpahaman 6: Menyusutkan Working Set berarti kebocoran memori telah diperbaiki

Diungkapkan ulang: Anda mungkin hanya mengusir halaman dari RAM. Periksa apakah Private Bytes dan apa yang ditahan di dalam heap benar-benar menurun.

Kesalahpahaman 7: Kenaikan Private Bytes mengonfirmasi kebocoran

Diungkapkan ulang: Anda hanya dapat menilai ini setelah memeriksa apakah ia konvergen ketika beban kerja yang sama diulang, jenis memori mana yang tumbuh, dan apakah itu cache yang dapat dilepas.

13. Ringkasan

• “Pemakaian memori” Windows bukan satu angka. Pikirkan ruang alamat, commit, residensi RAM, dan kemampuan dibagi secara terpisah.
• Working Set adalah halaman yang saat ini di RAM, termasuk baik Private maupun Shared. Private Working Set adalah halaman residensial privat proses di dalamnya.
• Private Bytes adalah Commit Charge privat proses; ia bukan jumlah yang saat ini di RAM maupun 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 diubah, dan crash dump.
• Alamat virtual yang direservasi, halaman yang dikomit, dan halaman yang benar-benar disentuh lalu masuk Working Set adalah tahap terpisah.
• Page Fault adalah operasi normal, dan soft fault tidak membaca dari disk. Hard fault, juga, dapat terjadi bukan hanya dari page file tetapi dari EXE, DLL, atau berkas terpetakan.
• Kebocoran memori dibuktikan bukan oleh ukurannya pada satu titik waktu, melainkan oleh nilai lantai dan tren setelah beban yang sama, bersama dengan rinciannya.
• Jalur dasarnya: VMMap untuk rincian proses individu, RAMMap untuk RAM fisik seluruh sistem, PerfMon untuk deret waktu, dan alat dump khusus untuk apa yang terjadi di dalam runtime.

Berikutnya kali Anda memperhatikan di Task Manager bahwa “memori sedang tumbuh”, mulailah dengan menanyakan ini pada diri sendiri.

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

Pertanyaan itu saja membuat titik masuk investigasi Anda jauh lebih akurat.

Artikel terkait

• Membedakan jeda GC dari kebocoran memori di .NET — prosedur praktis untuk mengamati, membandingkan, dan membuktikan pertumbuhan memori
• Process Explorer / Handle / VMMap dalam praktik — mengejar hang, kebocoran, dan “berkas sedang dipakai” dari state saat ini
• Jebakan memori bersama dan praktik terbaik praktis
• Kedalaman I/O Windows (Bagian 4) — Cache Manager: kapan WriteFile Anda benar-benar mencapai disk?
• Menyelidiki crash setelah operasi jangka panjang pada aplikasi kamera industri - kebocoran handle (Bagian 1)

Area konsultasi terkait

KomuraSoft LLC menangani investigasi akar masalah yang menggabungkan PerfMon, VMMap, RAMMap, WinDbg, dan alat diagnostik .NET untuk pertumbuhan memori aplikasi Windows, penurunan kinerja setelah operasi jangka panjang, OutOfMemory pada proses 32-bit, dan kekurangan memori yang hanya terjadi di lingkungan pelanggan. Kami tidak berhenti pada sekadar “memori tinggi” — kami mengisolasi wilayah mana yang tumbuh, melalui operasi mana, mengapa, dan dari mana ia direferensikan atau ditahan.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

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 menunjukkan total memori yang dialokasikan aplikasi?

Tidak. Task Manager punya beberapa kolom memori — keluarga Working Set, keluarga Private Working Set, Commit Size, dan lainnya — dan artinya bergantung pada layar serta kolom yang Anda lihat. Working Set adalah halaman yang saat ini residensial di RAM; Private Bytes atau Commit Size adalah jumlah commit milik proses itu sendiri. Jangan membaca 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 residensial di RAM fisik, termasuk halaman yang dapat dibagi seperti kode DLL dan berkas yang dipetakan ke memori. Private Bytes adalah jumlah memori yang dikomit secara eksklusif untuk proses itu, terlepas dari apakah saat ini residensial di RAM. Keduanya karenanya tidak pernah sama, dan tidak ada yang secara konsisten lebih besar dari yang lain.

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

Tidak. Angka kiri adalah total commit yang saat ini dijanjikan seluruh sistem; angka kanan adalah plafon commit yang dapat ditopang sistem. Plafon ditentukan kira-kira oleh RAM plus page file, tetapi tidak semua total kiri benar-benar duduk di page file. Sebagian besar halaman yang dikomit ada di RAM, dan sebagian halaman yang dikomit belum pernah mendapat halaman fisik sama sekali. Sementara itu, halaman yang dapat dimuat ulang dari berkas asalnya — seperti EXE, DLL, dan berkas yang dipetakan ke memori — tidak selalu menaikkan Commit privat sebesar yang mereka naikkan Working Set.

Bisakah OutOfMemory terjadi meski masih ada RAM kosong?

Ya. Alokasi dapat gagal karena alasan selain RAM fisik, termasuk proses 32-bit yang kehabisan ruang alamat virtual, kekurangan rentang alamat kosong yang berurutan, plafon commit sistem, atau batas khusus Job Object atau runtime. Khususnya, proses 32-bit di Windows 64-bit biasanya dibatasi 2GB ruang alamat virtual mode pengguna kecuali ia Large Address Aware.

Apakah menonaktifkan page file membuat Windows lebih cepat?

Anda tidak dapat mengasumsikannya sebagai aturan umum. Menonaktifkan page file menurunkan plafon commit sistem, mempersulit pengusiran halaman yang diubah tetapi tidak terpakai dari RAM, dan memengaruhi bagaimana crash dump dapat dikonfigurasi. Ukuran page file harus diputuskan dengan mengukur puncak commit charge dan crash dump yang Anda butuhkan — ini bukan pengaturan untuk dinonaktifkan tanpa alasan.

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

Itu saja tidak cukup untuk menentukan. 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. Alih-alih melihat Page Faults/sec secara terpisah, periksa Pages Input/sec, Page Reads/sec, Available MBytes, latensi disk, dan waktu pemrosesan bersama pada linimasa 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.