Praktik WPR/WPA — pengantar investigasi performa di seluruh sistem untuk gejala "seluruh PC terasa berat"

“Setelah aplikasi baru diinstal, seluruh PC terasa berat. Namun di Task Manager, CPU maupun memori masih longgar.” “Ada satu PC yang butuh 3 menit untuk startup. Sama sekali tidak jelas apa yang salah.” — Konsultasi terkait performa memang sering datang dalam bentuk ini. Yang sama di semua kasus: melihat proses tertentu tidak memberi jawaban.

Alat tingkat proses sudah tersedia. Akses ke berkas dan registri bisa dilihat dengan Process Monitor, dan CPU serta GC aplikasi .NET bisa dilacak dengan PerfView. Namun gejala “seluruh PC terasa berat” atau “CPU menganggur tetapi tetap lambat” dimulai dari bahkan tidak tahu proses mana pelakunya. Aplikasi A mungkin lambat karena pemindaian antivirus, atau karena layanan lain menulis ke disk dalam volume besar, atau karena rantai lock yang merentang beberapa proses. Yang dibutuhkan adalah data yang merekam bukan bagian dalam suatu proses, melainkan seluruh OS pada satu sumbu waktu.

Alat untuk merekam dan membacanya adalah Windows Performance Recorder (WPR) dan Windows Performance Analyzer (WPA). WPR merekam pergerakan seluruh OS berbasis ETW (Event Tracing for Windows), dan WPA menganalisis rekaman itu lewat grafik dan tabel. Siapa memakai CPU pada stack mana, thread menunggu siapa, proses mana yang mengeluarkan I/O disk ke berkas mana — fakta satu atau dua tingkat di bawah Task Manager semuanya tersimpan, lengkap dengan stempel waktu.

Artikel ini ditujukan kepada staf IT di usaha kecil dan menengah serta pengembang aplikasi Windows. Isinya menata praktik pengambilan dengan WPR dan cara membaca WPA — terutama perbedaan cara menyelidiki “ketika CPU tinggi” dan “ketika CPU rendah tetapi tetap lambat” — berdasarkan sumber primer per Agustus 2026.

1. Kesimpulan di awal

• Pilihan utama untuk investigasi “seluruh PC terasa berat” adalah WPR/WPA: merekam jejak ETW seluruh OS lalu membacanya. Masalah yang tidak bisa dipaku alat tingkat proses (Task Manager, Procmon, PerfView) tetap bisa ditelusuri jika semua proses dan kernel dilihat pada satu sumbu waktu.¹²
• Alat pengambilan wpr.exe sudah disertakan di Windows 8.1 dan yang lebih baru. Tidak perlu instalasi tambahan. Versi GUI (WPRUI) dan alat analisis WPA termasuk dalam Windows ADK.¹²
• Prosedur dasarnya tiga baris. Dengan hak administrator, wpr -start GeneralProfile -filemode → reproduksi gejala → wpr -stop C:\temp\trace.etl. Ingat hanya itu, pengambilan sudah bisa dimulai.³
• Bentuk dasar di lapangan adalah pembagian “di lingkungan pelanggan hanya merekam dengan wpr.exe; membaca dilakukan di WPA pada mesin sendiri”. Pengambilan tetap bisa dilakukan di server yang tidak boleh diinstal perangkat lunak. Ide yang sama dengan packet capture: “ambil dengan alat standar, baca di Wireshark”.¹
• Membaca WPA dimulai dengan klasifikasi “CPU, waktu tunggu, atau I/O”. Jika CPU penuh, CPU Usage (Sampled); jika CPU menganggur tetapi tetap lambat, analisis tunggu di CPU Usage (Precise); jika disk yang dicurigai, Disk Usage — jalur sudah belah di awal.⁴⁵
• CPU Usage (Sampled) menunjukkan “fungsi mana yang memakai CPU” dari sampling kira-kira setiap 1 milidetik. Rincian “50%” di Task Manager bisa diturunkan dari proses → thread → stack → fungsi.⁶
• CPU Usage (Precise) adalah rekaman lengkap context switch, dan menunjukkan “siapa yang ditunggu suatu thread”. Menelusuri Waits (waktu tunggu), ReadyingProcess (pihak yang membangunkan), dan ReadyThreadStack (stack pihak yang membangunkan) adalah teknik yang paling ingin disampaikan artikel ini.⁴⁷
• Membaca stack mensyaratkan konfigurasi simbol. WPA secara bawaan merujuk server simbol publik Microsoft. Untuk melihat nama fungsi di aplikasi sendiri, tambahkan path PDB perusahaan.⁸
• Berkas ETL berisi informasi internal sistem seperti nama proses dan path berkas. Jaga pengambilan pada minimum yang dibutuhkan, dan putuskan cara penanganan jika berkas dibawa ke luar perusahaan sebelum merekam.

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 16, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Posisi alat — WPR merekam, WPA membaca

Windows Performance Toolkit (WPT) adalah kumpulan alat investigasi performa yang termasuk dalam Windows ADK (Windows Assessment and Deployment Kit); intinya adalah pasangan WPR dan WPA.² Perannya terbagi jelas.

• WPR (Windows Performance Recorder) = pengambilan. Menggabungkan kelompok provider ETW ke dalam unit yang disebut “profil”, memulai dan menghentikan rekaman, lalu menghasilkan berkas ETL. Versi baris perintah, wpr.exe, sudah disertakan di Windows 8.1 dan yang lebih baru, tanpa instalasi tambahan. Versi GUI (WPRUI.exe) termasuk dalam ADK.¹
• WPA (Windows Performance Analyzer) = analisis. Membuka berkas ETL dan menganalisisnya lewat grafik dan tabel. Instalasi ADK diperlukan.²

Dengan kata lain, tidak ada yang perlu diletakkan di lingkungan pelanggan. Rekam dengan wpr.exe bawaan OS, bawa berkas ETL pulang, lalu baca di WPA pada PC sendiri — pembagian yang sama dengan packet capture: “ambil dengan pktmon, baca di Wireshark”.

flowchart LR
    accTitle: Pembagian merekam dengan WPR dan membaca dengan WPA
    accDescr: Di lingkungan pelanggan, rekam dengan wpr.exe bawaan OS dan hasilkan berkas ETL, bawa pulang, lalu analisis di WPA yang sudah diinstal lewat ADK pada PC sendiri
    subgraph customer["Lingkungan pelanggan (tanpa instalasi tambahan)"]
        wpr["wpr -start → reproduksi gejala → wpr -stop"] --> etl["Berkas ETL"]
    end
    subgraph office["PC sendiri (WPA sudah diinstal lewat ADK)"]
        wpa["Analisis grafik dan tabel di WPA"]
    end
    etl -->|"dibawa pulang"| wpa

Pembedaan dari alat serupa juga ditata lebih dulu.

Jika Procmon adalah log operasi “apa yang dilakukan” dan PerfView adalah “apa yang terjadi di dalam .NET”, WPA adalah alat yang mengaudit secara lintas proses “ke mana waktu menghilang”. Mekanisme ETW itu sendiri, dan cara menginstrumentasi aplikasi sendiri dengan ETW, dibahas di “Pengantar Windows Event Log dan ETW”. Jika aplikasi sendiri memancarkan event ETW, titik pemeriksaan aplikasi ikut tercatat dalam jejak yang sama, dan pencocokan menjadi jauh lebih mudah. Namun WPR hanya merekam event dari provider yang diaktifkan oleh profil rekaman yang dipilih. GeneralProfile tidak menyertakan provider sendiri, jadi jika ingin mencampurnya, siapkan profil rekaman kustom (.wprp) yang mengaktifkan provider itu, lalu gabungkan seperti wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, dengan menyebutkan nama profil di dalam berkas .wprp memakai !³.

3. Praktik pengambilan (WPR) — start, reproduksi, stop

Prosedur dasar di terminal dengan hak administrator.

:: Daftar profil bawaan yang bisa dipakai
wpr -profiles

:: 1. Mulai pengambilan (profil serbaguna, mode file)
wpr -start GeneralProfile -filemode

:: 2. Reproduksi gejala (status pengambilan: wpr -status)

:: 3. Hentikan dan simpan (deskripsi masalah bisa dilampirkan).
::    Buat folder tujuan lebih dulu (tanpa folder, -stop gagal menyimpan)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Mereproduksi gejala seluruh PC terasa berat saat memulai aplikasi X"

:: Jika ingin berhenti di tengah tanpa menyimpan, buang rekaman
wpr -cancel

Yang diberikan ke -start adalah profil, bundel provider ETW yang dibutuhkan investigasi.³ Mengingat yang sering dipakai sudah cukup.⁹

Beberapa profil bisa ditentukan sekaligus dengan merangkai -start (contoh: wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Alur pengambilan WPR dan cara memilih mode
    accDescr: Gejala yang bisa direproduksi di tempat diambil singkat dan andal dalam mode file; gejala yang waktunya tidak diketahui ditunggu di ring buffer mode memory bawaan. Gejala selama startup atau logon memakai jejak boot. Dalam semua kasus prosedur mulai, reproduksi, dan berhenti sama
    q{"Kapan gejala terjadi?"}
    q -->|"bisa direproduksi di tempat"| file["Ambil singkat dan andal dengan -filemode"]
    q -->|"waktunya tidak diketahui"| mem["Tunggu dengan mode Memory (bawaan, ring buffer) (bagian 3.1)"]
    q -->|"saat startup atau logon"| boot["Jejak boot (bab 8)"]
    file --> s1["wpr -start → reproduksi/kejadian gejala → wpr -stop"]
    mem --> s1

3.1. Mode Memory dan mode File — mereproduksi, atau menunggu

Tujuan rekaman WPR punya dua mode; bawaan adalah mode Memory (buffer sirkular di memori). Itu ring buffer yang menimpa dari event tertua, jadi cocok untuk membiarkan pengambilan berjalan sambil menunggu gejala yang waktunya tidak diketahui, lalu berhenti ketika terjadi. Menambah -filemode beralih ke mode File, dan semuanya direkam ke berkas kontinu. Di sini tidak ada penimpaan; satu-satunya batas atas adalah ruang disk kosong, dan berkas tumbuh tanpa batas.¹⁰

flowchart LR
    accTitle: Cara mode Memory dan mode File merekam
    accDescr: Mode Memory merekam ke buffer sirkular di memori; event lama ditimpa sehingga hanya yang terbaru tersisa, cocok untuk menunggu. Mode File menyimpan semuanya ke berkas, tetapi batas atas hanya ruang disk kosong, cocok untuk reproduksi singkat yang andal
    ev["Aliran event ETW"] --> ring["Mode Memory: buffer sirkular (ditimpa dari yang lama → hanya yang terbaru tersisa)"]
    ev --> filem["Mode File: semua tersimpan ke berkas (batas atas = ruang disk kosong)"]
    ring -.-> use1["Cocok menunggu gejala yang waktunya tidak diketahui"]
    filem -.-> use2["Cocok untuk gejala yang bisa direproduksi andal dalam waktu singkat"]

Patokan pemakaiannya sebagai berikut.

• Bisa direproduksi di tempat → mode File. Mulai tepat sebelum reproduksi, berhenti tepat sesudahnya, dan selesaikan pengambilan dalam beberapa menit
• Waktunya tidak diketahui → tunggu dengan mode Memory (bawaan). Begitu terjadi, segera wpr -stop
• Bahkan GeneralProfile beberapa menit bisa menghasilkan ETL ratusan MB sampai kelas GB. Berkas yang terlalu besar kadang tidak bisa dianalisis di WPA, jadi “semakin lama diambil semakin baik” justru kontraproduktif¹⁰¹¹

Jika mengambil lewat GUI, cukup jalankan WPRUI, pilih profil dan Logging mode, lalu Start/Save. Rincian prosedurnya dirangkum di How-to resmi.¹¹ Jika staf di sisi pelanggan diminta mengambil, tiga perintah di atas bisa langsung dijadikan prosedur.

4. Dasar cara membaca WPA — grafik, aturan emas tabel, dan pemfokusan waktu

Saat ETL yang sudah diambil dibuka di WPA, Graph Explorer di kiri menampilkan thumbnail grafik dalam kategori seperti System Activity, Computation, Storage, dan Memory.¹² Seret grafik yang ingin dilihat ke tab Analysis di kanan, maka grafik tampil di atas dan tabel di bawah. Yang perlu dikuasai di awal hanya tiga hal.

1. Aturan emas tabel — urutan kolom menentukan pengelompokan. Tabel WPA punya dua batang vertikal, emas dan biru. Data dihierarkikan (dikelompokkan) menurut urutan kolom di kiri batang emas, dan kolom di kanan batang biru menjadi nilai agregat.¹³ Jika diurutkan “Process → Stack”, yang didapat adalah agregat stack per proses; jika “Stack → Process”, agregat semua proses yang memakai stack yang sama. Menggeser kolom dengan drag itu sendiri adalah operasi analisis. Setelah satu poin ini dipahami, semua tabel WPA dibaca dengan cara yang sama.

flowchart LR
    accTitle: Aturan emas tabel — peran dua batang dan kolom
    accDescr: Data dihierarkikan menurut urutan kolom di kiri batang emas; kolom di antara batang emas dan biru adalah kolom tampilan; kolom di kanan batang biru adalah nilai agregat. Menggeser kolom dengan drag itu sendiri menjadi operasi analisis
    left["Kiri batang emas: kolom pengelompokan (urutan = hierarki)"] --> gold["Batang emas"]
    gold --> mid["Di antara batang: kolom tampilan"]
    mid --> blue["Batang biru"]
    blue --> right["Kanan batang biru: nilai agregat (Sum, %, dll.)"]
    left -.-> op["Drag kolom = operasi analisis (Process→Stack menghasilkan agregat stack per proses)"]

1. Persempit rentang waktu. Seret di grafik untuk memilih rentang, lalu klik kanan dan pilih “Zoom” agar agregat beralih ke interval itu saja. Investigasi performa selalu berprinsip hanya melihat “interval saat gejala terjadi” (bab 9).
2. Atur simbol. Untuk membaca stack sebagai nama fungsi, jalankan Trace > Load Symbols di menu.¹⁴ Secara bawaan WPA merujuk server simbol publik Microsoft (msdl.microsoft.com), jadi stack Windows sendiri bisa diselesaikan jika ada koneksi internet. Untuk melihat nama fungsi di aplikasi sendiri, tambahkan folder PDB aplikasi di Trace > Configure Symbol Paths.⁸ Apa itu PDB, dan mengapa harus selalu disimpan meski pada build rilis, dirangkum di “Apa itu PDB (program database)”. Untuk image native NGen di .NET Framework, WPR saat pengambilan menghasilkan PDB khusus NGen (.ngenpdb) di folder di samping jejak, dan WPA merujuknya secara otomatis.⁸ Ini mekanisme khusus image NGen, dan kode sendiri pada aplikasi .NET biasa yang berjalan lewat JIT tidak termasuk. Korespondensi alamat kode JIT dengan nama fungsi diselesaikan dari event JIT yang dikeluarkan CLR, jadi ketika menyelidiki aplikasi .NET, siapkan profil rekaman (.wprp) yang mengaktifkan provider CLR (Microsoft-Windows-DotNETRuntime dan Rundown-nya), lalu gabungkan dengan cara yang sama seperti provider sendiri di bab 3, dalam bentuk wpr -start GeneralProfile -start MyDotNet.wprp!nama-profil, agar event CLR masuk ke jejak (profil bawaan yang bisa dipakai WPR di mesin itu bisa dicek dengan wpr -profiles). Setelah itu, simpan PDB yang dihasilkan build untuk korespondensi ke baris sumber, dan tambahkan ke path simbol di atas.

flowchart TB
    accTitle: Penyelesaian simbol agar stack terbaca sebagai nama fungsi
    accDescr: Menjalankan Trace Load Symbols menyelesaikan Windows sendiri dari server simbol publik Microsoft, dan aplikasi sendiri dari PDB hasil build yang ditambahkan ke path simbol. Image NGen memakai PDB khusus NGen yang dihasilkan WPR; kode .NET JIT memakai event CLR JIT dalam jejak plus PDB hasil build
    load["Trace > Load Symbols"] --> ms["Windows sendiri: server simbol publik (msdl)"]
    load --> own["Aplikasi sendiri: PDB hasil build yang ditambahkan di Configure Symbol Paths"]
    load --> ngen["Image NGen .NET Framework: .ngenpdb yang dihasilkan WPR"]
    load --> jit["Kode .NET JIT: event CLR JIT dalam jejak + PDB hasil build"]

Setelah persiapan selesai, masuk dari cabang berikut. Pada interval itu, CPU tinggi atau rendah? Jika tinggi, ke bab 5 (Sampled); jika rendah tetapi tetap lambat, ke bab 6 (Precise).

flowchart TB
    accTitle: Cabang memilih grafik WPA dari gejala
    accDescr: Zoom ke interval gejala; jika CPU tinggi ke CPU Usage Sampled; jika rendah tetapi tetap lambat, cek apakah ada inti yang menempel lalu ke analisis tunggu CPU Usage Precise; jika disk dicurigai ke Disk Usage dan File IO
    zoom["Zoom ke interval gejala"] --> cpu{"CPU pada interval itu?"}
    cpu -->|"tinggi"| sampled["Bab 5: CPU Usage (Sampled) untuk \"siapa menghabiskan CPU di fungsi mana\""]
    cpu -->|"rendah tetapi tetap lambat"| core{"Ada inti atau thread yang menempel?"}
    core -->|"ada"| sampled
    core -->|"tidak"| precise["Bab 6: CPU Usage (Precise) untuk \"apa yang ditunggu\""]
    cpu -->|"disk dicurigai"| disk["Bab 7: Disk Usage / File I/O untuk mengidentifikasi pelaku"]

5. Ketika CPU tinggi — “siapa menghabiskan CPU di fungsi mana” dengan CPU Usage (Sampled)

Jika CPU menempel, yang dilihat adalah CPU Usage (Sampled). Ini data sampling yang kira-kira setiap 1 milidetik merekam, di semua CPU, “stack proses mana yang sedang dieksekusi sekarang”; rasio jumlah sampel langsung menjadi rincian waktu CPU.⁶

flowchart LR
    accTitle: Mekanisme CPU Usage Sampled
    accDescr: Kira-kira setiap 1 milidetik, stack yang sedang dieksekusi direkam di semua CPU, lalu sampel diagregat dan rasionya menjadi rincian waktu CPU. Baca dari proses ke thread, stack, lalu fungsi. Aktivitas singkat yang selesai di sela sampel tidak terekam
    tick["Interrupt kira-kira setiap 1 ms"] --> snap["Rekam 「stack yang sedang dieksekusi sekarang」 di semua CPU"]
    snap --> agg["Agregat sampel (rasio = rincian waktu CPU)"]
    agg --> drill["Turun Process → Thread → Stack → fungsi"]
    snap -.-> miss["Aktivitas singkat yang selesai di sela sampel tidak terekam"]

1. Dari Computation di Graph Explorer, letakkan CPU Usage (Sampled) ke tab Analysis, lalu pilih preset Utilization by Process, Stack.⁵
2. Lihat proses menurut Weight (atau Count) dari yang terbesar. Identitas “50%” di Task Manager pertama-tama terlihat per proses.
3. Perluas kolom Stack pada proses pelaku. Stack diagregat sebagai pohon; turun di cabang yang angkanya tidak turun tajam sampai tiba di fungsi yang menghabiskan CPU. Jika simbol sudah terselesaikan, jalur lurus sampai fungsi mana di kode sendiri.
4. Jika memperluas pohon terasa ribet, alihkan tampilan grafik ke Flame (grafik api). Digambar dengan lebar = porsi waktu CPU, jadi jalur pemanggilan mana yang dominan langsung terlihat. CPU Usage (Sampled) juga punya preset Flame by Process, Stack.¹³

Ada satu catatan. Karena ini sampling, aktivitas singkat yang selesai di sela sampel tidak terekam.⁶ Ingat bahwa ini alat untuk melihat “secara total, di mana CPU terpakai”, bukan alat untuk mengukur waktu eksekusi yang akurat per satu kali jalan.

6. Ketika CPU rendah tetapi tetap lambat — CPU Usage (Precise) dan analisis tunggu

Inti artikel ini ada di sini. Namun sebelum masuk ke analisis tunggu, ada satu hal yang perlu dicek. “Penggunaan CPU keseluruhan rendah” tidak berarti “CPU bukan bottleneck”. Di PC 16 inti, pemrosesan serial yang menempel di satu inti (satu thread UI yang berputar penuh) hanya terlihat sekitar 6% secara keseluruhan. Pertama, pastikan di Sampled bab 5 (atau Utilization by CPU pada CPU Usage (Precise)) tidak ada inti atau thread tertentu yang menempel; jika tidak ada, baru ke bab ini — pemrosesan bukan tidak bisa bergerak, melainkan sedang menunggu. Yang memberitahu apa yang ditunggu adalah CPU Usage (Precise).

Jika Sampled adalah sampling, Precise adalah rekaman lengkap context switch (pergantian thread). Thread masuk ke tunggu, dibangunkan seseorang (Ready), lalu naik ke CPU — bolak-balik ini tersisa per baris, dan kolom berikut bisa dibaca.⁷⁴

flowchart LR
    accTitle: Satu putaran tunggu dan korespondensi tiap kolom
    accDescr: Thread masuk ke tunggu pada stack yang tersisa di NewThreadStack, menunggu selama waktu Waits. Ketika seseorang membangunkannya, pihak itu tersisa di ReadyingProcess dan ReadyThreadStack; setelah menunggu perebutan CPU selama waktu Ready, thread dieksekusi lagi
    run1["Sedang dieksekusi"] -->|"masuk ke tunggu (tersisa di NewThreadStack)"| waitst["Tunggu (Waits (us))"]
    waitst -->|"seseorang membangunkan (ReadyingProcess / ReadyThreadStack)"| ready["Ready (menunggu perebutan CPU)"]
    ready -->|"naik ke CPU"| run2["Dieksekusi lagi"]

Pola membacanya seperti ini.⁴

1. Terapkan preset Utilization by Process, Thread, lalu tambahkan kolom NewThreadStack dan ReadyThreadStack.
2. Pertama, identifikasi thread yang menjalankan operasi yang terlambat (thread UI, thread pemrosesan permintaan yang relevan). Hanya melihat dari total Waits terbesar akan membingungkan, karena thread yang “sengaja menunggu terus” seperti message pump atau timer menduduki urutan atas. Setelah thread sasaran ditemukan, jika CPU Usage (ms)-nya besar itu masalah CPU bab 5; jika Waits yang dominan, itu masalah tunggu.
3. Perluas NewThreadStack dan lihat sedang melakukan apa ketika berhenti. WaitForSingleObject atau EnterCriticalSection berarti menunggu lock, di dalam I/O sinkron seperti ReadFile berarti menunggu I/O, di dalam penerimaan socket berarti menunggu respons lawan.
4. Berikutnya lihat siapa yang melepaskan tunggu. Perluas ReadyThreadStack, dan periksa ReadyingProcess / ReadyingThreadId. Jika dibangunkan dari KiTimerExpiration kernel, itu timer (= tidur sampai timeout); jika dari pemrosesan selesai I/O, itu mengonfirmasi bahwa yang terjadi adalah tunggu I/O.⁴
5. Jika pihak yang membangunkan adalah thread lain atau proses lain, kini selidiki thread itu dengan prosedur yang sama. “A menunggu pelepasan lock B, B menunggu respons RPC C, C menunggu I/O disk” — rantai yang ditelusuri sampai ke akar inilah critical path dari penundaan.⁷

flowchart LR
    accTitle: Rantai critical path yang ditelusuri dalam analisis tunggu
    accDescr: Lihat di NewThreadStack thread A yang terlambat sedang melakukan apa ketika berhenti, identifikasi pihak B yang membangunkan lewat ReadyThreadStack dan ReadyingProcess, lalu selidiki B dengan prosedur yang sama sampai ke I/O disk di akar
    a["Thread A (operasi yang terlambat)"] -->|"NewThreadStack: berhenti karena menunggu lock"| b["Thread B (sedang memegang lock)"]
    b -->|"NewThreadStack: menunggu respons RPC"| c["Proses C"]
    c -->|"NewThreadStack: menunggu I/O sinkron"| d["I/O disk (akar)"]
    d -.->|"selesai membangunkan C"| c
    c -.->|"respons membangunkan B"| b
    b -.->|"pelepasan lock membangunkan A (muncul di ReadyThreadStack)"| a

Misalnya pada kasus “sudah multithread tetapi tidak menjadi lebih cepat”, prosedur ini langsung menunjukkan semua worker mengantri pada satu lock. Menghindari persaingan lock lewat desain dibahas di “Praktik terbaik multithreading, edisi .NET”, dan mekanisme Windows yang berputar pada notifikasi selesai alih-alih menunggu I/O sinkron dibahas di “I/O completion port (IOCP) dan thread pool .NET”. Menemukan “siapa yang ditunggu” di WPA, lalu memperbaikinya dengan teori desain itu, adalah satu alur yang berkesinambungan.

7. Disk dan I/O berkas — mengidentifikasi “ada proses yang membebani disk”

Pelaku klasik “seluruh PC terasa berat” bukan CPU, melainkan disk. Selidiki dengan Disk Usage dan File I/O di kategori Storage.¹⁵

Disk Usage adalah rekaman I/O disk, dan ada dua kolom penting. Disk Service Time adalah waktu yang benar-benar dipakai perangkat disk untuk memproses I/O itu; IO Time adalah waktu dari I/O masuk antrean OS sampai selesai. IO Time selalu lebih besar atau sama dengan Service Time sebesar waktu antrean, jadi jika IO Time jauh lebih panjang daripada Service Time, I/O itu “sedang menunggu di antrean”. ⁶ Namun hanya dengan itu, belum bisa diputuskan apakah pelaku yang membentuk antrean adalah proses lain, atau I/O masif milik sendiri yang mengantri di perangkat yang lambat. Jangan simpulkan di sini; pastikan dengan Service Time (respons perangkat itu sendiri) dan rincian per proses, path, serta stack berikutnya.

Dari situ, dengan preset Utilization by Process, Path Name, Stack, lihat proses mana, ke berkas mana, dari stack mana yang mengeluarkan I/O, diurutkan dari IO Time atau Size terbesar.¹⁵ Jawaban yang sering muncul di lapangan adalah dua ini.

• Antivirus sedang memindai semua berkas. Terlihat sebagai proses antivirus yang mengeluarkan pembacaan masif pada rentang waktu ketika startup aplikasi lambat. Nama proses, path, dan volume langsung menjadi bukti untuk diskusi pengaturan pengecualian.
• Proses lain sedang menulis dalam volume besar. Cadangan, indexer, log yang berlebihan, dan semacamnya. Kapan penulisan sampai ke disk melibatkan cache manager, jadi pergeseran antara “saat ditulis” dan “saat disk sibuk” juga dibahas di “Cache Manager — kapan WriteFile Anda sampai ke disk”.

File I/O adalah lapisan satu tingkat di atas, yaitu rekaman operasi berkas yang dikeluarkan aplikasi (Create/Read/Write, dll.); preset seperti Duration by Process, Thread, Type bisa mengagregat waktu per nama berkas dan per operasi.¹⁵ Kasus yang menghabiskan waktu di file system atau filter driver sebelum sampai ke disk tidak muncul di Disk Usage, jadi ketidakcocokan “Disk Usage tenang tetapi File I/O lambat” itu sendiri menjadi petunjuk. Untuk memahami dari mekanisme I/O sinkron dan asinkron, lihat “I/O sinkron dan I/O asinkron — arti sebenarnya OVERLAPPED”.

flowchart TB
    accTitle: Perbedaan lapisan yang dilihat File IO dan Disk Usage
    accDescr: Operasi berkas aplikasi sampai ke perangkat disk lewat file system dan filter driver lalu antrean IO OS. File IO merekam operasi di lapisan atas; Disk Usage merekam IO yang sampai ke disk; selisih IO Time dan Disk Service Time menunjukkan waktu antrean
    app["Aplikasi: ReadFile / WriteFile"] --> fio["File system dan filter driver (lapisan yang dilihat File I/O)"]
    fio --> queue["Antrean I/O OS"]
    queue --> dev["Perangkat disk (lapisan yang dilihat Disk Usage)"]
    fio -.-> n1["Jika waktu dihabiskan di sini, tidak muncul di Disk Usage"]
    queue -.-> n2["IO Time − Disk Service Time = waktu antrean"]
    dev -.-> n3["Disk Service Time = waktu pemrosesan perangkat"]

Jalur “mungkin kekurangan memori lalu swap” bisa dipilah dulu di Task Manager dan Resource Monitor sebelum maju ke WPA. Namun jangan menolak hanya karena melihat committed memory — meski committed masih longgar, situasi hard fault berlanjut karena working set terpotong akibat desakan memori fisik tetap mungkin. Periksa juga memori fisik yang tersedia dan “Hard Faults/detik” di Resource Monitor. Cara membacanya ada di “Apa yang diwakili "penggunaan memori" Windows”.

8. Startup dan logon lambat — pintu masuk jejak boot

Tipe “startup butuh 3 menit” sudah selesai sebelum sempat menjalankan wpr -start secara manual. WPR punya jejak boot, yang bisa disiapkan agar OS otomatis mulai merekam pada startup berikutnya.³

:: 1. Siapkan rekaman otomatis pada startup berikutnya
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduksi kelambatan startup)

:: 3. Setelah startup, hentikan rekaman dan simpan (persiapan juga dilepas)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Gejala startup butuh 3 menit"

flowchart LR
    accTitle: Alur jejak boot
    accDescr: Siapkan rekaman otomatis startup berikutnya dengan addboot lalu restart, maka OS otomatis mulai merekam saat startup. Setelah logon, simpan dengan stopboot dan persiapan ikut dilepas. Untuk membatalkan, lepas dengan cancelboot
    add["Siapkan dengan wpr -boottrace -addboot"] --> rebootpc["Restart (reproduksi kelambatan startup)"]
    rebootpc --> auto["Saat startup, OS otomatis mulai merekam"]
    auto --> stop2["Setelah logon, simpan dengan -stopboot (persiapan ikut dilepas)"]
    add -.-> cancel["Jika membatalkan, -cancelboot"]

Pengukuran startup dan shutdown yang dulu diemban xbootmgr kini juga bisa dijalankan di WPR dengan opsi seperti -onoffscenario Boot.³ Jejak yang didapat dibaca dengan perangkat yang sama seperti bab sebelumnya. Lihat secara kronologis proses mana lahir kapan di grafik Processes, zoom ke rentang waktu ketika startup macet, lalu klasifikasikan CPU, waktu tunggu, atau disk — bentuk seperti aplikasi startup yang menunggu sesuatu secara serial, atau start layanan yang berhenti pada I/O tertentu, akan terlihat. Analisis boot sendiri adalah bidang khusus yang dalam, jadi artikel ini hanya sampai pintu masuk: “gejala yang tidak sempat diambil secara manual tetap bisa direkam dengan WPR”. Mulailah dari menangkap gambaran keseluruhan dengan jejak boot GeneralProfile.

9. Pola praktis — iterasi klasifikasi → zoom → stack

Setelah alatnya dipahami, rangkum pola investigasi secara keseluruhan.

1. Pastikan waktu gejala. Bukan “terasa berat”, melainkan kencangkan sampai “10:23:40–10:24:10 yang berat”. Log aplikasi, event log, catatan orang yang mengoperasikan, apa saja. Jika aplikasi sendiri menulis titik pemeriksaan ke ETW atau event log, event di dalam jejak langsung menjadi patok waktu.
2. Zoom hanya ke interval itu. Agregat seluruh jejak diratakan oleh rata-rata, dan anomali yang penting menjadi pudar. Analisis WPA selalu perbandingan “interval yang abnormal” versus “interval yang normal”.
3. Klasifikasikan dulu “CPU, waktu tunggu, atau I/O”. Lihat CPU Usage (Sampled); jika CPU penuh, ke bab 5. Jika tidak, ke Waits di CPU Usage (Precise) (bab 6). Jika IO Time di Disk Usage menggelembung, ke bab 7. Melewati persimpangan tiga arah ini di awal mencegah tersesat.
4. Ulangi hipotesis → zoom → stack. Jika curiga antivirus, sempitkan ke proses itu dan konfirmasi di stack. Jika salah, ke hipotesis berikutnya. Jangan simpulkan sebelum turun ke stack dan mengonfirmasi — itu disiplin investigasi jenis ini.

flowchart LR
    accTitle: Loop iterasi investigasi performa
    accDescr: Pastikan waktu gejala, zoom ke interval, klasifikasikan CPU atau tunggu atau IO, buat hipotesis lalu sempitkan, konfirmasi di stack. Jika terkonfirmasi, penyebab pasti; jika salah, ulangi dengan hipotesis berikutnya
    time["Pastikan waktu gejala"] --> zoomstep["Zoom ke interval itu"]
    zoomstep --> triage["Klasifikasikan CPU, waktu tunggu, atau I/O"]
    triage --> hypo["Buat hipotesis lalu sempitkan"]
    hypo --> stack["Konfirmasi di stack"]
    stack -->|"terkonfirmasi"| fix["Penyebab pasti → ke penanganan"]
    stack -->|"salah"| hypo

Terakhir, penanganan berkas pengambilan. Berkas ETL memuat bagian dalam sistem secara luas: nama semua proses, path berkas yang dibuka, modul yang dimuat, dan (tergantung profil) nama kunci registri. Pengambilan standar GeneralProfile tidak menyertakan isi data seperti muatan komunikasi, tetapi jika provider kustom diaktifkan, payload event itu (string yang dicatat aplikasi, dll.) masuk utuh. Setelah memastikan apa yang dikeluarkan provider yang diaktifkan, perlakukan sebagai berkas yang cukup rahasia untuk dibawa ke luar perusahaan. Sama seperti packet capture, masukkan ke prosedur pengambilan seminimal mungkin, kesepakatan dengan pihak yang menerima, masa retensi, dan penghapusan.

flowchart LR
    accTitle: Apa yang terekam di berkas ETL dan cara menanganinya
    accDescr: ETL memuat nama semua proses, path berkas yang dibuka, modul, dan tergantung profil nama kunci registri; jika provider kustom diaktifkan, payload-nya juga masuk. Perlakukan sebagai berkas rahasia: pengambilan seminimal mungkin, kesepakatan dengan pihak penerima, masa retensi dan penghapusan
    etl["Berkas ETL"] --> a1["Nama semua proses, path berkas, modul"]
    etl --> a2["(tergantung profil) nama kunci registri"]
    etl --> a3["Payload provider kustom (string yang dicatat aplikasi)"]
    a1 -.-> rule["Perlakukan sebagai rahasia: pengambilan seminimal mungkin, kesepakatan dengan pihak penerima, masa retensi dan penghapusan"]
    a2 -.-> rule
    a3 -.-> rule

10. Ringkasan

• “Seluruh PC terasa berat” yang tidak bisa dijelaskan Task Manager diselidiki dengan jejak ETW seluruh OS — direkam dengan WPR, dibaca dengan WPA. wpr.exe sudah disertakan di Windows 8.1 dan yang lebih baru, jadi pembagian merekam di lingkungan pelanggan, membawa ETL pulang, dan membaca di WPA sendiri bisa dijalankan.
• Pengambilan adalah tiga langkah: wpr -start GeneralProfile -filemode → reproduksi → wpr -stop trace.etl. Jika bisa direproduksi, mode File dalam beberapa menit; jika menunggu, mode Memory (ring buffer). Bukan semakin lama diambil semakin baik.
• WPA bisa mulai dibaca setelah tiga poin dikuasai: aturan emas tabel (kiri batang emas = pengelompokan), zoom rentang waktu, dan konfigurasi simbol (aplikasi sendiri memakai PDB).
• Jika CPU tinggi, turun proses → stack → fungsi di CPU Usage (Sampled). Jika CPU rendah tetapi tetap lambat, telusuri rantai NewThreadStack (sedang melakukan apa ketika berhenti) → Waits (berapa lama menunggu) → ReadyingProcess dan ReadyThreadStack (siapa yang membangunkan) sampai ke akar di CPU Usage (Precise).
• Pada disk, lihat “waktu di antrean” dari selisih IO Time dan Service Time di Disk Usage, lalu identifikasi penyebabnya (perangkat itu sendiri yang lambat, atau siapa yang membentuk antrean) dari Service Time dan rincian per proses, path, serta stack. Kelambatan startup bisa diambil dengan wpr -boottrace.
• Pola praktis: (1) pastikan waktu, (2) zoom interval, (3) klasifikasikan CPU, waktu tunggu, atau I/O, (4) iterasi hipotesis → zoom → stack. Perlakukan ETL sebagai berkas rahasia yang berisi informasi internal.

Layar WPA terkesan keras, dan siapa pun tersesat di satu jam pertama. Namun begitu dua tulang punggung masuk — “kiri batang emas adalah pengelompokan” dan “Sampled adalah tempat CPU dihabiskan, Precise adalah pihak yang ditunggu” — sisanya hanya pengulangan operasi yang sama. Lain kali ada konsultasi “CPU masih longgar tetapi tetap lambat”, tutup Task Manager dan coba ambil jejak.

Artikel terkait

• Mengidentifikasi “lambat” dengan PerfView dan dotnet-trace — pengantar praktis investigasi performa .NET
• Panduan praktis Process Monitor (ProcMon) — mengidentifikasi “pengaturan tidak dibaca” dan “ACCESS DENIED” dalam 10 menit
• Pengantar Windows Event Log dan ETW — menaruh log aplikasi bisnis pada mekanisme bawaan OS
• Apa yang diwakili “penggunaan memori” Windows — membaca Working Set, Private Bytes, Commit, dan page file dengan benar
• Pengaturan penjadwalan prosesor Windows — layanan latar belakang dan inti P/E
• Apa itu PDB (program database) — memahami informasi debug, simbol, dan Source Link

Area konsultasi terkait

Di Komura Soft (合同会社小村ソフト), investigasi masalah performa seluruh sistem ditangani, misalnya “seluruh PC menjadi berat tetapi penyebabnya tidak diketahui”, “CPU masih longgar tetapi aplikasi lambat”, atau “hanya di lingkungan tertentu startup sangat lambat”. Dari perancangan pengambilan WPR/WPA (di lingkungan mana, profil mana, berapa lama) sampai analisis jejak dan perbaikan di sisi aplikasi maupun pengaturan yang menjadi penyebab, ditangani sebagai satu rangkaian.

• Pengembangan aplikasi Windows
• Investigasi gangguan dan analisis penyebab
• 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.

Di mana WPR dan WPA bisa diperoleh? Bisakah dipakai di lingkungan pelanggan yang tidak mengizinkan instalasi?

Alat pengambilan wpr.exe (versi baris perintah) sudah disertakan di Windows 8.1 dan yang lebih baru, jadi tidak perlu instalasi tambahan. Versi GUI, WPRUI, serta alat analisis WPA (Windows Performance Analyzer) termasuk dalam Windows ADK (Windows Assessment and Deployment Kit) dan perlu diinstal terpisah. Di lapangan, pembagian kerja yang dipakai adalah: di lingkungan pelanggan, ambil berkas ETL hanya dengan wpr.exe bawaan OS, bawa pulang, lalu analisis di WPA pada mesin sendiri. Dengan cara itu, investigasi performa seluruh sistem tetap bisa dilakukan di situs yang tidak boleh menambah perangkat lunak.

Mengapa tetap lambat padahal Task Manager menunjukkan CPU masih longgar? Apa yang terlihat di WPA?

Jika penggunaan CPU rendah tetapi sistem tetap lambat, pekerjaannya bukan karena tidak bisa memakai CPU — prosesnya berhenti karena "menunggu sesuatu". Persaingan lock, menunggu selesainya I/O sinkron, dan menunggu respons proses lain adalah pola yang khas. Task Manager hanya menampilkan hasil berupa penggunaan; CPU Usage (Precise) di WPA, dari rekaman per context switch, menunjukkan di stack mana thread mulai menunggu (NewThreadStack), berapa lama menunggu (Waits), dan siapa yang membangunkannya (ReadyingProcess, ReadyThreadStack). Dengan menelusuri pihak yang membuatnya menunggu, "pelaku kelambatan" bisa diidentifikasi sampai ke tingkat fungsi.

Jejak perlu diambil berapa lama? Apakah berkasnya tidak menjadi sangat besar?

Jika masalah bisa direproduksi, dasarnya adalah mulai tepat sebelum reproduksi, berhenti tepat sesudahnya, dan selesaikan dalam beberapa menit. Bawaan WPR adalah mode Memory, yang merekam ke buffer sirkular di memori; event lama ditimpa, sehingga cocok untuk menunggu kejadian yang waktunya tidak diketahui. Mode File, dengan -filemode, menyimpan semuanya ke berkas kontinu, tetapi satu-satunya batas atas adalah ruang disk kosong, dan berkas yang terlalu besar kadang tidak bisa dianalisis di WPA. Pakai mode Memory untuk penantian yang panjang, mode File untuk reproduksi singkat yang andal.

Bagaimana membedakan pemakaian PerfView dan WPA?

Keduanya menangani jejak ETW, tetapi bidang yang dikuasai berbeda. PerfView memahami runtime .NET secara mendalam dan kuat untuk investigasi khas aplikasi managed seperti GC, alokasi, dan JIT. WPA cocok untuk membaca CPU, disk, I/O berkas, daya, dan semacamnya di seluruh OS lewat grafik dan tabel, dan menjadi pilihan utama ketika yang lambat bukan aplikasi tertentu melainkan seluruh PC, ketika beberapa proses terlibat, atau ketika yang dicurigai ada di luar aplikasi (antivirus, driver, proses lain). Patokannya: PerfView untuk kelambatan aplikasi .NET sendiri, WPR/WPA untuk kelambatan seluruh sistem.

Apakah aman menjalankan WPR di lingkungan produksi pelanggan?

Pengambilan singkat memang sering dilakukan di lapangan, tetapi tidak aman tanpa syarat. ETW ringan, tetapi merekam volume event yang besar beserta stack tetap mengonsumsi CPU dan memori dalam jumlah tertentu. Mulai tepat sebelum langkah reproduksi dan berhenti tepat sesudahnya, selesaikan pengambilan dalam beberapa menit, dan jalankan pada waktu dengan dampak bisnis kecil — pertimbangan semacam itu harus dimasukkan ke proses persetujuan yang sama seperti perubahan biasa. Selain itu, berkas ETL berisi informasi internal sistem seperti nama proses, path berkas, dan informasi executable, jadi cara penanganan jika dibawa ke luar perusahaan (minimalisasi, masa retensi, penghapusan) perlu diputuskan lebih dulu.

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.