WPR/WPA dalam praktik — pengantar investigasi performa di seluruh sistem untuk "seluruh PC lambat"

“Mereka bilang seluruh PC menjadi lambat setelah menginstal aplikasi baru. Tetapi ketika saya melihat Task Manager, CPU dan memori keduanya masih longgar.” “Ada satu PC yang butuh 3 menit untuk start. Saya tidak tahu apa yang salah.” — Konsultasi performa memang sering datang dalam bentuk ini. Yang mereka miliki bersama adalah bahwa melihat proses tertentu tidak memberi jawaban.

Alat tingkat proses sudah ada. Akses berkas dan registri dapat dilihat dengan Process Monitor, dan CPU serta GC aplikasi .NET dapat diikuti dengan PerfView. Tetapi gejala seperti “seluruh PC lambat” atau “CPU menganggur dan tetap lambat” dimulai dari bahkan tidak tahu proses mana pelakunya. Aplikasi A mungkin lambat karena pemindaian antivirus, atau karena layanan lain menulis berat ke disk, atau karena rantai lock yang merentang beberapa proses. Yang Anda butuhkan adalah data yang merekam bukan bagian dalam suatu proses melainkan OS secara keseluruhan pada satu linimasa.

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

Ditujukan kepada staf IT di usaha kecil dan menengah serta pengembang aplikasi Windows, artikel ini menata praktik menangkap dengan WPR dan cara membaca WPA — terutama perbedaan antara menyelidiki “ketika CPU tinggi” dan “ketika CPU rendah dan tetap lambat” — berlandaskan sumber primer per Agustus 2026.

1. Kesimpulan lebih dulu

• Pilihan pertama untuk investigasi “seluruh PC lambat” adalah WPR/WPA, yang menangkap dan membaca jejak ETW di seluruh OS. Masalah yang tidak dapat dipaku alat tingkat proses (Task Manager, Procmon, PerfView) dapat diikuti jika Anda melihat setiap proses dan kernel pada satu linimasa.¹²
• Alat tangkap wpr.exe ikut dengan Windows 8.1 dan yang lebih baru. Anda dapat memakainya tanpa instal tambahan. Edisi GUI (WPRUI) dan alat analisis WPA termasuk dalam Windows ADK.¹²
• Prosedur dasarnya tiga baris. Sebagai administrator, wpr -start GeneralProfile -filemode → reproduksi masalah → wpr -stop C:\temp\trace.etl. Ingat hanya itu dan Anda dapat mulai menangkap.³
• Dasar lapangan adalah pembagian “di lingkungan pelanggan, hanya tangkap dengan wpr.exe; membaca adalah WPA pada mesin Anda sendiri”. Anda dapat menangkap bahkan pada server tempat Anda tidak dapat menginstal perangkat lunak. Itu ide yang sama dengan packet capture: “tangkap dengan alat standar, baca di Wireshark”.¹
• Membaca WPA dimulai dengan mengklasifikasi “CPU, tunggu, atau I/O”. Jika CPU terbakar, CPU Usage (Sampled); jika CPU menganggur dan tetap lambat, analisis tunggu di CPU Usage (Precise); jika disk dicurigai, Disk Usage — jalurnya belah di awal.⁴⁵
• CPU Usage (Sampled) menunjukkan “fungsi mana yang memakai CPU” dari sampling kira-kira setiap 1 milidetik. Anda dapat menelusuri rincian “50%” Task Manager dari proses → thread → stack → fungsi.⁶
• CPU Usage (Precise) adalah rekaman lengkap pergantian konteks, dan memberi tahu Anda “siapa yang ditunggu suatu thread”. Menelusuri Waits (waktu tunggu), ReadyingProcess (siapa yang membangunkannya), dan ReadyThreadStack (stack pihak yang membangunkan) adalah teknik yang paling ingin disampaikan artikel ini.⁴⁷
• Membaca stack mensyaratkan konfigurasi simbol. WPA merujuk server simbol publik Microsoft secara bawaan. Untuk melihat nama fungsi di aplikasi Anda sendiri, tambahkan path ke PDB Anda sendiri.⁸
• Berkas ETL berisi informasi internal sistem seperti nama proses dan path berkas. Jaga tangkap pada minimum yang dibutuhkan, dan putuskan bagaimana ia akan ditangani jika keluar dari perusahaan sebelum Anda menangkap.

2. Di mana alat-alat itu duduk — WPR menangkap, WPA membaca

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

• WPR (Windows Performance Recorder) = tangkap. Ia menggabungkan kelompok penyedia ETW ke dalam unit yang disebut “profil”, memulai dan menghentikan rekaman, dan menghasilkan berkas ETL. Edisi baris perintah, wpr.exe, ikut dengan Windows 8.1 dan yang lebih baru, tanpa instal tambahan. Edisi GUI (WPRUI.exe) termasuk dalam ADK.¹
• WPA (Windows Performance Analyzer) = analisis. Ia membuka berkas ETL dan menganalisisnya dalam grafik dan tabel. Instal ADK diperlukan.²

Dengan kata lain, tidak ada yang perlu Anda tempatkan di lingkungan pelanggan. Tangkap dengan wpr.exe standar OS, bawa berkas ETL pulang, dan baca di WPA pada PC Anda sendiri — pembagian yang sama dengan packet capture: “tangkap dengan pktmon, baca di Wireshark” berlaku.

flowchart TB
    accTitle: Pembagian menangkap dengan WPR dan membaca dengan WPA
    accDescr: Di lingkungan pelanggan, rekam dengan wpr.exe standar OS dan hasilkan berkas ETL; bawa pulang dan analisis di WPA yang diinstal lewat ADK pada PC Anda sendiri
    subgraph customer["PC pelanggan（tanpa instal tambahan）"]
        wpr["wpr start → reproduksi → stop"] --> etl["Berkas ETL"]
    end
    subgraph office["PC Anda（WPA lewat ADK）"]
        wpa["Analisis grafik dan tabel"]
    end
    etl -->|"Bawa pulang"| wpa

Gambar 1: Di lingkungan pelanggan, rekam dengan wpr.exe standar OS dan hasilkan berkas ETL; bawa pulang dan analisis di WPA yang diinstal lewat ADK pada PC Anda sendiri.

Perbedaannya dari alat serupa juga patut ditata lebih dulu.

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

3. Tangkap dalam praktik (WPR) — start, reproduksi, stop

Prosedur dasar di terminal administrator.

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

Yang Anda berikan ke -start adalah profil, bundel penyedia ETW yang dibutuhkan investigasi.³ Mengingat hanya yang sering Anda pakai sudah cukup.⁹

Anda dapat menentukan beberapa profil sekaligus dengan merangkai -start (misalnya wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Alur tangkap WPR dan cara memilih mode
    accDescr: Masalah yang dapat Anda reproduksi di tempat ditangkap singkat dan andal dalam mode file; masalah yang waktunya tidak Anda ketahui ditunggu di ring buffer mode memory bawaan. Masalah selama boot atau logon memakai jejak boot. Dalam setiap kasus prosedur start / reproduksi / stop sama
    q{"Kapan ia terjadi?"}
    q -->|"Di tempat"| file["Mode File: tangkap singkat"]
    q -->|"Waktu tidak diketahui"| mem["Mode Memory: tunggu（3.1）"]
    q -->|"Boot atau logon"| boot["Jejak boot（Bab 8）"]
    file --> s1["start → reproduksi → stop"]
    mem --> s1

Gambar 2: Masalah yang dapat Anda reproduksi di tempat ditangkap singkat dan andal dalam mode file; masalah yang waktunya tidak Anda ketahui ditunggu di ring buffer mode memory bawaan. Masalah selama boot atau logon memakai jejak boot. Dalam setiap kasus prosedur start / reproduksi / stop sama.

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

WPR punya dua mode tujuan rekaman; bawaan adalah mode Memory (buffer sirkular di memori). Itu ring buffer yang menimpa dari event tertua, jadi ia cocok untuk membiarkan tangkap berjalan sementara Anda menunggu masalah yang waktunya tidak Anda ketahui, dan berhenti ketika ia terjadi. Menambah -filemode beralih ke mode File, dan semuanya direkam ke berkas kontinu. Ini tidak ditimpa; satu-satunya plafon adalah ruang disk kosong, dan berkas tumbuh tanpa batas.¹⁰

flowchart TB
    accTitle: Cara mode Memory dan mode File merekam
    accDescr: Mode Memory merekam ke buffer sirkular di memori; event yang lebih lama ditimpa dan hanya yang terbaru tetap, jadi ia cocok untuk menunggu. Mode File menyimpan semuanya dalam berkas, tetapi satu-satunya plafon adalah ruang disk kosong, jadi ia cocok untuk reproduksi singkat yang andal
    ev["Event ETW"] --> ring["Mode Memory: ring buffer"]
    ev --> filem["Mode File: tumbuhkan berkas"]
    ring -.-> use1["Tunggu waktu yang tidak diketahui"]
    filem -.-> use2["Reproduksi singkat yang andal"]

Gambar 3: Mode Memory merekam ke buffer sirkular di memori; event yang lebih lama ditimpa dan hanya yang terbaru tetap, jadi ia cocok untuk menunggu. Mode File menyimpan semuanya dalam berkas, tetapi satu-satunya plafon adalah ruang disk kosong, jadi ia cocok untuk reproduksi singkat yang andal.

Aturan praktis untuk memilih adalah sebagai berikut.

• Dapat direproduksi di tempat → mode File. Mulai tepat sebelum reproduksi, berhenti tepat sesudahnya, dan jaga tangkap dalam beberapa menit
• Waktu tidak diketahui → Tunggu dalam mode Memory (bawaan). Segera setelah ia terjadi, wpr -stop
• Bahkan beberapa menit GeneralProfile dapat menghasilkan ETL kelas ratusan MB hingga GB. Berkas yang terlalu besar dapat menjadi tidak dapat dianalisis di WPA, jadi “semakin lama Anda menangkap, semakin baik” justru kontraproduktif¹⁰¹¹

Untuk menangkap dari GUI, mulai WPRUI, pilih profil dan Logging mode, lalu Start/Save. How-to resmi merangkum prosedurnya.¹¹ Jika Anda meminta kontak di situs pelanggan untuk menangkap, tiga perintah di atas dapat masuk ke prosedur apa adanya.

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

Ketika Anda membuka ETL yang ditangkap di WPA, Graph Explorer di kiri mencantumkan thumbnail grafik dalam kategori seperti System Activity, Computation, Storage, dan Memory.¹² Seret grafik yang ingin Anda lihat ke tab Analysis di kanan, dan grafik muncul di atas serta tabel di bawah. Tiga hal pertama yang harus diserap adalah ini.

1. Aturan emas tabel — urutan kolom memutuskan pengelompokan. Tabel WPA punya dua bilah vertikal, emas dan biru, dan kolom di kiri bilah emas menghierarki (mengelompokkan) data dalam urutan itu, dan kolom di kanan bilah biru adalah agregat.¹³ Susun mereka Process → Stack dan Anda mendapat agregasi stack per proses; Stack → Process dan Anda mendapat agregasi setiap proses yang memakai stack yang sama — menyeret kolom untuk menyusun ulang mereka itu sendiri adalah operasi analisis. Pahami satu poin ini dan setiap tabel WPA dibaca dengan cara yang sama.

flowchart TB
    accTitle: Aturan emas tabel — dua bilah dan peran kolom
    accDescr: Kolom di kiri bilah emas menghierarki data dalam urutan itu; kolom di antara bilah emas dan biru adalah kolom tampilan; kolom di kanan bilah biru adalah agregat. Menyeret kolom untuk menyusun ulang mereka itu sendiri adalah operasi analisis
    left["Kiri emas: pengelompokan"] --> gold["Bilah emas"]
    gold --> mid["Antara bilah: tampilan"]
    mid --> blue["Bilah biru"]
    blue --> right["Kanan biru: agregat"]
    left -.-> op["Seret kolom untuk menganalisis"]

Gambar 4: Kolom di kiri bilah emas menghierarki data dalam urutan itu; kolom di antara bilah emas dan biru adalah kolom tampilan; kolom di kanan bilah biru adalah agregat. Menyeret kolom untuk menyusun ulang mereka itu sendiri adalah operasi analisis.

1. Persempit rentang waktu. Seret pada grafik untuk memilih rentang, lalu klik kanan dan “Zoom”, dan agregasi beralih ke interval itu saja. Investigasi performa selalu, pada prinsipnya, hanya melihat “interval ketika masalah sedang terjadi” (Bab 9).
2. Konfigurasi simbol. Untuk membaca stack menurut nama fungsi, jalankan Trace > Load Symbols dari menu.¹⁴ Secara bawaan ia merujuk server simbol publik Microsoft (msdl.microsoft.com), jadi stack Windows sendiri dapat diselesaikan jika Anda punya koneksi Internet. Untuk melihat nama fungsi di aplikasi Anda sendiri, tambahkan folder PDB aplikasi Anda di Trace > Configure Symbol Paths.⁸ Apa itu PDB, dan mengapa Anda harus selalu menyimpannya bahkan untuk build Release, dirangkum di “Apa itu PDB (Program Database)?”. Untuk citra native NGen .NET Framework, WPR menghasilkan PDB NGen (.ngenpdb) pada waktu tangkap dan menempatkannya di folder di samping jejak, dan WPA merujuknya secara otomatis.⁸ Ini adalah mekanisme hanya untuk citra NGen, dan kode aplikasi .NET JIT biasa milik Anda sendiri di luar cakupan. Pemetaan dari alamat kode JIT ke nama fungsi diselesaikan dari event JIT yang dipancarkan CLR, jadi ketika Anda menyelidiki aplikasi .NET, siapkan profil rekaman (.wprp) yang mengaktifkan penyedia CLR (Microsoft-Windows-DotNETRuntime dan Rundown yang cocok) dan gabungkan dengan cara yang sama seperti penyedia Anda sendiri di Bab 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, agar event CLR termasuk dalam jejak (Anda dapat memeriksa profil bawaan mana yang ditawarkan WPR lokal Anda dengan wpr -profiles). Di atas itu, simpan PDB yang dihasilkan build untuk pemetaan ke baris sumber, dan tambahkan mereka ke path simbol di atas.

flowchart TB
    accTitle: Resolusi simbol untuk membaca stack menurut nama fungsi
    accDescr: Menjalankan Trace Load Symbols menyelesaikan Windows sendiri dari server simbol publik Microsoft, dan aplikasi Anda sendiri dari PDB build yang ditambahkan ke path simbol. Citra NGen memakai PDB NGen yang dihasilkan WPR; kode .NET JIT diselesaikan dari event JIT CLR dalam jejak plus PDB build
    load["Trace > Load Symbols"] --> ms["Windows: simbol publik"]
    load --> own["Aplikasi sendiri: PDB build"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: event CLR + PDB"]

Gambar 5: Menjalankan Trace Load Symbols menyelesaikan Windows sendiri dari server simbol publik Microsoft, dan aplikasi Anda sendiri dari PDB build yang ditambahkan ke path simbol. Citra NGen memakai PDB NGen yang dihasilkan WPR; kode .NET JIT diselesaikan dari event JIT CLR dalam jejak plus PDB build.

Setelah Anda siap, Anda masuk dari cabang berikutnya. Di interval itu, apakah CPU tinggi, atau rendah? Jika tinggi, Bab 5 (Sampled); jika rendah dan tetap lambat, Bab 6 (Precise).

flowchart TB
    accTitle: Cabang untuk memilih grafik WPA dari gejala
    accDescr: Zoom ke interval masalah; jika CPU tinggi pergi ke CPU Usage Sampled; jika rendah dan tetap lambat, periksa pin satu-inti / satu-thread lalu analisis tunggu di CPU Usage Precise; jika disk dicurigai, Disk Usage dan File IO
    zoom["Zoom ke interval masalah"] --> cpu{"CPU di interval itu?"}
    cpu -->|"Tinggi"| sampled["Bab 5: Sampled"]
    cpu -->|"Rendah, tetap lambat"| core{"Pin 1-inti / 1-thread?"}
    core -->|"Ya"| sampled
    core -->|"Tidak"| precise["Bab 6: Precise"]
    cpu -->|"Disk dicurigai"| disk["Bab 7: Disk / File I/O"]

Gambar 6: Zoom ke interval masalah; jika CPU tinggi pergi ke CPU Usage Sampled; jika rendah dan tetap lambat, periksa pin satu-inti / satu-thread lalu analisis tunggu di CPU Usage Precise; jika disk dicurigai, Disk Usage dan File IO.

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

Jika CPU terpaku, yang Anda lihat adalah CPU Usage (Sampled). Ini adalah data sampling yang merekam, kira-kira setiap 1 milidetik pada setiap CPU, “stack proses mana yang sedang berjalan sekarang”, dan rasio jumlah sampel adalah rincian waktu CPU apa adanya.⁶

flowchart TB
    accTitle: Cara kerja CPU Usage Sampled
    accDescr: Kira-kira setiap 1 milidetik, stack yang berjalan pada setiap CPU direkam, dan rasio sampel yang diagregasi adalah rincian waktu CPU. Baca dari proses ke thread, stack, dan fungsi. Aktivitas singkat yang selesai di antara sampel tidak muncul
    tick["Interrupt kira-kira setiap 1 md"] --> snap["Rekam stack yang berjalan"]
    snap --> agg["Rasio sampel = rincian CPU"]
    agg --> drill["Process → Thread → Stack"]
    snap -.-> miss["Aktivitas di antara sampel terlewat"]

Gambar 7: Kira-kira setiap 1 milidetik, stack yang berjalan pada setiap CPU direkam, dan rasio sampel yang diagregasi adalah rincian waktu CPU. Baca dari proses ke thread, stack, dan fungsi. Aktivitas singkat yang selesai di antara sampel tidak muncul.

1. Dari Computation di Graph Explorer, tempatkan CPU Usage (Sampled) pada tab Analysis dan pilih preset Utilization by Process, Stack.⁵
2. Lihat proses dalam urutan menurun Weight (atau Count). Identitas apa yang “50%” di Task Manager menjadi jelas lebih dulu di tingkat proses.
3. Perluas kolom Stack proses pelaku. Stack diagregasi sebagai pohon, dan menelusuri jalur di mana angka tidak turun banyak pada suatu cabang mendaratkan Anda pada fungsi yang membakar CPU. Jika simbol terselesaikan, itu garis lurus ke fungsi mana di kode Anda sendiri.
4. Jika memperluas pohon membosankan, alihkan tampilan grafik ke Flame. Ia digambar dengan lebar = bagian waktu CPU, jadi jalur panggilan mana yang mendominasi jelas sekilas. CPU Usage (Sampled) juga punya preset Flame by Process, Stack.¹³

Ada satu peringatan. Karena ini sampling, aktivitas singkat yang selesai di antara sampel tidak muncul.⁶ Ingat ia sebagai alat untuk melihat “di mana CPU dipakai secara agregat”, bukan alat untuk mengukur durasi persis per pemanggilan.

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

Ini adalah inti artikel. Sebelum Anda lanjut ke analisis tunggu, walaupun, ada satu hal untuk dikonfirmasi. “Penggunaan CPU keseluruhan rendah” tidak berarti “CPU bukan bottleneck”. Pada PC 16-inti, pekerjaan serial yang terpaku pada satu inti (satu thread UI yang berjalan habis-habisan) hanya terlihat sekitar 6% keseluruhan. Pertama periksa di Sampled Bab 5 (atau Utilization by CPU milik CPU Usage (Precise)) bahwa tidak ada pin pada inti atau thread tertentu, dan jika tidak ada, datang ke bab ini — pekerjaannya bukan tidak dapat berjalan, ia menunggu. Yang memberi tahu Anda apa yang ditunggunya adalah CPU Usage (Precise).

Di mana Sampled adalah sampling, Precise adalah rekaman lengkap pergantian konteks (pergantian thread). Thread masuk tunggu, dibangunkan seseorang (Ready), dan mendarat pada CPU — pulang-pergi itu tetap satu baris pada suatu waktu, dan Anda dapat membaca kolom berikut.⁷⁴

flowchart TB
    accTitle: Satu pulang-pergi tunggu dan bagaimana kolomnya bersesuaian
    accDescr: Thread masuk tunggu pada stack yang tetap di NewThreadStack, dan menunggu selama waktu Waits. Ketika seseorang membangunkannya, pihak itu tetap di ReadyingProcess dan ReadyThreadStack; ia menunggu waktu Ready untuk persaingan CPU lalu berjalan lagi
    run1["Berjalan"] -->|"Masuk tunggu"| waitst["Tunggu（Waits us）"]
    waitst -->|"Seseorang membangunkannya"| ready["Ready（persaingan CPU）"]
    ready -->|"Mendarat pada CPU"| run2["Berjalan lagi"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

Gambar 8: Thread masuk tunggu pada stack yang tetap di NewThreadStack, dan menunggu selama waktu Waits. Ketika seseorang membangunkannya, pihak itu tetap di ReadyingProcess dan ReadyThreadStack; ia menunggu waktu Ready untuk persaingan CPU lalu berjalan lagi.

Pola membacanya adalah sebagai berikut.⁴

1. Terapkan preset Utilization by Process, Thread dan tambahkan NewThreadStack serta ReadyThreadStack ke kolom.
2. Pertama identifikasi thread yang sedang mengeksekusi operasi yang tertunda (thread UI, thread yang menangani permintaan yang dimaksud). Hanya melihat dalam urutan menurun total Waits membingungkan, karena thread yang “sengaja menunggu sepanjang waktu”, seperti message pump atau timer, menempati puncak. Setelah Anda menemukan thread sasaran, jika CPU Usage (ms)-nya besar itu masalah CPU Bab 5; jika Waits mendominasi itu masalah tunggu.
3. Perluas NewThreadStack dan lihat apa yang dilakukannya ketika ia berhenti. WaitForSingleObject atau EnterCriticalSection adalah tunggu lock; di dalam I/O sinkron seperti ReadFile itu tunggu I/O; di dalam terima soket itu menunggu peer merespons.
4. Berikutnya lihat siapa yang melepaskan tunggu. Perluas ReadyThreadStack dan periksa ReadyingProcess / ReadyingThreadId. Jika ia dibangunkan dari KiTimerExpiration kernel itu timer (= ia tidur sampai timeout); jika ia dibangunkan dari penanganan penyelesaian I/O, itu mengonfirmasi ia tunggu I/O.⁴
5. Jika pihak yang membangunkannya adalah thread lain atau proses lain, selidiki thread itu dengan prosedur yang sama. “A menunggu B melepaskan lock, B menunggu respons RPC C, C menunggu I/O disk” — yang Anda miliki ketika Anda telah menelusuri rantai ini ke akar adalah critical path penundaan.⁷

flowchart TB
    accTitle: Rantai critical-path yang Anda telusuri dalam analisis tunggu
    accDescr: Lihat di NewThreadStack thread A yang tertunda apa yang dilakukannya ketika ia berhenti, identifikasi pihak yang membangunkan B dari ReadyThreadStack dan ReadyingProcess, dan selidiki B dengan prosedur yang sama sampai ke I/O disk di akar
    a["Thread A（pekerjaan tertunda）"] -->|"Tunggu lock"| b["Thread B（memegang lock）"]
    b -->|"Tunggu RPC"| c["Proses C"]
    c -->|"Tunggu I/O sinkron"| d["I/O disk（akar）"]
    d -.->|"Penyelesaian membangunkan C"| c
    c -.->|"Respons membangunkan B"| b
    b -.->|"Pelepasan lock membangunkan A"| a

Gambar 9: Lihat di NewThreadStack thread A yang tertunda apa yang dilakukannya ketika ia berhenti, identifikasi pihak yang membangunkan B dari ReadyThreadStack dan ReadyingProcess, dan selidiki B dengan prosedur yang sama sampai ke I/O disk di akar.

Dalam kasus seperti “kita multithread-kan dan ia tidak menjadi lebih cepat”, prosedur ini menunjukkan setiap worker berbaris pada satu lock apa adanya. Menghindari persaingan lock lewat desain dibahas di “Praktik terbaik multithreading praktis: edisi .NET”, dan mekanisme Windows yang berjalan pada notifikasi penyelesaian alih-alih menunggu di I/O sinkron dibahas di “I/O Completion Ports (IOCP) dan .NET Thread Pool”. Memaku “siapa yang ditunggunya” di WPA dan memperbaikinya dengan argumen desain itu adalah satu alur berkelanjutan.

7. Disk dan I/O berkas — mengidentifikasi “seseorang memindai disk”

Pelaku klasik “seluruh PC lambat” bukan CPU melainkan disk. Anda menyelidiki dengan Disk Usage dan File I/O di kategori Storage.¹⁵

Disk Usage adalah rekaman I/O disk, dan dua kolom penting. Disk Service Time adalah waktu perangkat disk benar-benar habiskan untuk memproses I/O itu; IO Time adalah waktu dari I/O masuk antrean OS sampai selesai. IO Time selalu setidaknya Service Time sebesar jumlah antrean, jadi jika IO Time jauh lebih lama dari Service Time, I/O itu “menunggu di antrean”.⁶ Itu saja, walaupun, tidak memutuskan apakah pelaku yang membuat antrean adalah proses lain, atau hanya I/O berat proses itu sendiri yang berbaris pada perangkat lambat. Jangan tarik kesimpulan di sini; selesaikan dengan Service Time (respons perangkat sendiri) dan rincian berikutnya menurut proses, path, dan stack.

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

• Antivirus memindai setiap berkas. Di jendela ketika aplikasi lambat start, proses antivirus terlihat mengeluarkan volume besar baca. Nama proses, path, dan volume adalah bukti apa adanya untuk diskusi pengecualian.
• Proses lain menulis berat. Cadangan, pengindeks, log yang ditulis terlalu banyak, dan semacamnya. Kapan suatu tulis mencapai disk melibatkan cache manager, jadi fakta bahwa “saat Anda menulis” dan “saat disk sibuk” dapat menyimpang juga dibahas di “Cache Manager — kapan WriteFile Anda benar-benar mencapai disk?”.

File I/O satu lapisan di atas, rekaman operasi berkas yang dikeluarkan aplikasi (Create/Read/Write dan semacamnya), dan preset seperti Duration by Process, Thread, Type dapat mengagregasi waktu per nama berkas dan per operasi.¹⁵ Kasus yang menghabiskan waktu di sistem berkas atau filter driver sebelum mencapai disk tidak muncul di Disk Usage, jadi ketidakcocokan itu sendiri — “Disk Usage damai tetapi File I/O lambat” — adalah petunjuk. Jika Anda ingin mulai dari mekanika I/O sinkron dan asinkron, lihat “I/O sinkron dan asinkron — apa arti OVERLAPPED yang sungguhan”.

flowchart TB
    accTitle: Lapisan berbeda yang dilihat File IO dan Disk Usage
    accDescr: Operasi berkas aplikasi berjalan melalui sistem berkas dan filter driver dari antrean I/O OS ke perangkat disk. File IO merekam operasi di lapisan atas; Disk Usage merekam I/O yang mencapai disk; selisih antara IO Time dan Disk Service Time adalah waktu antrean
    app["Aplikasi: ReadFile / WriteFile"] --> fio["FS dan filter（File I/O）"]
    fio --> queue["Antrean I/O OS"]
    queue --> dev["Perangkat disk（Disk Usage）"]
    fio -.-> n1["Terlewat oleh Disk Usage"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = perangkat"]

Gambar 10: Operasi berkas aplikasi berjalan melalui sistem berkas dan filter driver dari antrean I/O OS ke perangkat disk. File IO merekam operasi di lapisan atas; Disk Usage merekam I/O yang mencapai disk; selisih antara IO Time dan Disk Service Time adalah waktu antrean.

Garis pikir “mungkin kekurangan memori dan swapping” dapat diberi isolasi pertama di Task Manager dan Resource Monitor sebelum Anda pergi ke WPA. Jangan, walaupun, menolaknya dari committed memory saja — bahkan dengan headroom commit, situasi di mana tekanan memori fisik memangkas working set dan hard fault berlanjut dimungkinkan. Juga periksa memori fisik tersedia dan “Hard Faults/sec” Resource Monitor. Cara membacanya ada di “Apa arti "penggunaan memori" Windows yang sungguhan?”.

8. Boot dan logon lambat — pintu masuk jejak boot

Jenis “butuh 3 menit untuk start” selesai sebelum Anda dapat menjalankan wpr -start secara manual. WPR punya jejak boot, dan Anda dapat mengatur agar OS mulai merekam secara otomatis pada boot berikutnya.³

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: Alur jejak boot
    accDescr: Setelah Anda mengatur rekaman otomatis pada boot berikutnya dengan addboot dan restart, OS mulai merekam secara otomatis saat boot. Menyimpan dengan stopboot setelah logon juga mengosongkan pengaturan. Untuk meninggalkan, kosongkan dengan cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["Restart（boot lambat）"]
    rebootpc --> auto["OS merekam saat boot"]
    auto --> stop2["Setelah logon: -stopboot"]
    add -.-> cancel["Tinggalkan: -cancelboot"]

Gambar 11: Setelah Anda mengatur rekaman otomatis pada boot berikutnya dengan addboot dan restart, OS mulai merekam secara otomatis saat boot. Menyimpan dengan stopboot setelah logon juga mengosongkan pengaturan. Untuk meninggalkan, kosongkan dengan cancelboot.

Pengukuran boot dan shutdown yang dulu dimiliki xbootmgr juga dapat dijalankan di WPR saat ini dengan opsi seperti -onoffscenario Boot.³ Jejak yang ditangkap dibaca dengan perangkat yang sama seperti bab sebelumnya. Lihat proses mana lahir kapan pada linimasa di grafik Processes, zoom ke jendela di mana boot macet, dan klasifikasi CPU, tunggu, atau disk — aplikasi startup yang menunggu sesuatu secara berurutan, start layanan yang macet pada I/O tertentu, dan semacamnya menjadi terlihat. Analisis boot adalah spesialisasi dalam sendiri, jadi artikel ini hanya sampai pintu masuk: “masalah yang tidak dapat Anda tangkap secara manual tetap dapat ditangkap dengan WPR”. Mulai dengan menangkap gambaran keseluruhan dengan jejak boot GeneralProfile.

9. Pola kerja — klasifikasi → zoom → stack, diulang

Sekarang alat-alatnya jelas, berikut pola untuk investigasi secara keseluruhan.

1. Paku waktu fenomena. Bukan “ia lambat”, melainkan “10:23:40–10:24:10 lambat”. Log aplikasi, event log, catatan dari orang yang mengoperasikannya — apa pun boleh. Jika aplikasi Anda sendiri menulis titik pemeriksaan ke ETW atau event log, event di dalam jejak menjadi tiang waktu apa adanya.
2. Zoom ke interval itu saja. Agregasi seluruh jejak dirata-ratakan, dan anomali yang penting diencerkan. Analisis WPA selalu perbandingan “interval yang abnormal” versus “interval yang normal”.
3. Klasifikasi “CPU, tunggu, atau I/O” lebih dulu. Lihat CPU Usage (Sampled); jika terbakar, Bab 5. Jika tidak terbakar, Waits di CPU Usage (Precise) (Bab 6). Jika Disk Usage IO Time menggembung, Bab 7. Mengambil cabang tiga arah ini lebih dulu menjaga Anda dari tersesat.
4. Ulangi hipotesis → zoom → stack. Jika Anda pikir “antivirus?”, persempit ke proses itu dan dukung dengan stack. Jika tidak bertahan, hipotesis berikutnya. Tidak menarik kesimpulan sebelum Anda menelusuri ke stack dan mendukungnya adalah disiplin investigasi semacam ini.

flowchart TB
    accTitle: Loop iteratif investigasi performa
    accDescr: Paku waktu fenomena, zoom ke interval, klasifikasi CPU / tunggu / I/O, bentuk hipotesis dan persempit, dan dukung dengan stack. Jika bertahan, penyebab dikonfirmasi; jika tidak, ulangi dengan hipotesis berikutnya
    time["Paku waktu"] --> zoomstep["Zoom ke interval itu"]
    zoomstep --> triage["Klasifikasi CPU / tunggu / I/O"]
    triage --> hypo["Hipotesis dan persempit"]
    hypo --> stack["Dukung dengan stack"]
    stack -->|"Bertahan"| fix["Penyebab dikonfirmasi"]
    stack -->|"Tidak"| hypo

Gambar 12: Paku waktu fenomena, zoom ke interval, klasifikasi CPU / tunggu / I/O, bentuk hipotesis dan persempit, dan dukung dengan stack. Jika bertahan, penyebab dikonfirmasi; jika tidak, ulangi dengan hipotesis berikutnya.

Akhirnya, penanganan berkas tangkap. Berkas ETL secara luas mencerminkan bagian dalam sistem: nama setiap proses, path berkas yang dibuka, modul yang dimuat, dan (tergantung profil) nama kunci registri. Tangkap GeneralProfile standar tidak menyertakan tubuh data seperti isi komunikasi, tetapi jika Anda mengaktifkan penyedia kustom, payload event itu (string yang direkam aplikasi, dan semacamnya) masuk apa adanya. Setelah mengonfirmasi apa yang dipancarkan penyedia yang Anda aktifkan, perlakukan sebagai berkas yang cukup rahasia untuk keluar dari perusahaan. Seperti packet capture, lipat tangkap minimum yang dibutuhkan, kesepakatan dengan pihak yang Anda serahkan, serta masa retensi dan penghapusan ke dalam prosedur.

flowchart TB
    accTitle: Apa yang dicerminkan berkas ETL, dan cara menanganinya
    accDescr: ETL mencerminkan setiap nama proses, path berkas yang dibuka, modul, dan tergantung profil nama kunci registri; mengaktifkan penyedia kustom juga menyertakan payload-nya. Perlakukan sebagai rahasia: tangkap minimum yang dibutuhkan, kesepakatan dengan pihak lain, serta masa retensi dan penghapusan
    etl["Berkas ETL"] --> a1["Nama, path, modul"]
    a1 --> a2["Kunci registri（sebagian）"]
    a2 --> a3["Payload kustom"]
    a3 -.-> rule["Perlakukan sebagai rahasia"]

Gambar 13: ETL mencerminkan setiap nama proses, path berkas yang dibuka, modul, dan tergantung profil nama kunci registri; mengaktifkan penyedia kustom juga menyertakan payload-nya. Perlakukan sebagai rahasia: tangkap minimum yang dibutuhkan, kesepakatan dengan pihak lain, serta masa retensi dan penghapusan.

10. Ringkasan

• “Seluruh PC lambat” yang tidak dapat dijelaskan Task Manager diselidiki dengan jejak ETW di seluruh OS — tangkap dengan WPR, baca dengan WPA. wpr.exe ikut dengan Windows 8.1 dan yang lebih baru, jadi pembagian menangkap di lingkungan pelanggan, membawa ETL pulang, dan membacanya di WPA pada mesin Anda sendiri berlaku.
• Tangkap adalah tiga langkah wpr -start GeneralProfile -filemode → reproduksi → wpr -stop trace.etl. Jika Anda dapat mereproduksi, mode File dalam beberapa menit; jika Anda menunggu, mode Memory (ring buffer). Lebih lama tidak lebih baik.
• WPA dapat dimulai setelah Anda menyerap tiga poin: aturan emas tabel (kiri bilah emas = pengelompokan), zoom rentang waktu, dan konfigurasi simbol (aplikasi Anda sendiri membutuhkan PDB).
• Jika CPU tinggi, telusuri proses → stack → fungsi di CPU Usage (Sampled). Jika CPU rendah dan tetap lambat, telusuri rantai NewThreadStack (apa yang dilakukannya ketika ia berhenti) → Waits (berapa lama ia menunggu) → ReadyingProcess dan ReadyThreadStack (siapa yang membangunkannya) ke akar di CPU Usage (Precise).
• Untuk disk, lihat “waktu yang dihabiskan di antrean” dari selisih antara Disk Usage IO Time dan Service Time, dan identifikasi penyebab (apakah perangkat itu sendiri lambat, atau siapa yang membuat antrean) dari Service Time dan rincian menurut proses, path, dan stack. Boot lambat dapat ditangkap dengan wpr -boottrace.
• Pola kerjanya adalah (1) paku waktu (2) zoom ke interval (3) klasifikasi CPU, tunggu, atau I/O (4) ulangi hipotesis → zoom → stack. Perlakukan ETL sebagai rahasia karena berisi informasi internal.

Layar WPA menakutkan, dan semua orang tersesat di jam pertama. Setelah dua tulang punggung — “kiri bilah emas adalah pengelompokan” dan “Sampled adalah di mana ia terbakar, Precise adalah siapa yang ditunggunya” — sudah masuk, sisanya adalah operasi yang sama diulang. Kali berikutnya konsultasi datang bahwa “CPU masih longgar dan tetap lambat”, tutup Task Manager dan tangkap jejak.

Artikel terkait

• Memaku “lambat” dengan PerfView dan dotnet-trace — pengantar praktis investigasi performa .NET
• Panduan praktis Process Monitor (ProcMon) — memaku “pengaturan tidak diterapkan” dan “ACCESS DENIED” dalam 10 menit
• Pengantar Windows Event Log dan ETW — menaruh log aplikasi bisnis Anda pada mekanisme standar OS
• Apa arti “penggunaan memori” Windows yang sungguhan? — 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

KomuraSoft LLC menangani investigasi masalah performa di seluruh sistem seperti “seluruh PC menjadi lambat dan saya tidak tahu mengapa”, “CPU masih longgar dan aplikasi tetap lambat”, dan “hanya lingkungan tertentu yang sangat lambat start”. Kami menangani sebagai satu keterlibatan berkelanjutan desain tangkap dengan WPR/WPA (di lingkungan mana, profil mana, berapa banyak ditangkap), analisis jejak, dan perbaikan yang dihasilkan di sisi aplikasi serta di sisi pengaturan.

• 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.

Di mana saya mendapatkan WPR dan WPA? Bisakah saya memakainya di lingkungan pelanggan tempat saya tidak dapat menginstal perangkat lunak?

Alat tangkap wpr.exe (edisi baris perintah) ikut dengan Windows 8.1 dan yang lebih baru, jadi Anda dapat memakainya tanpa instal tambahan. Edisi GUI, WPRUI, dan alat analisis WPA (Windows Performance Analyzer) termasuk dalam Windows ADK (Windows Assessment and Deployment Kit) dan memang memerlukan instal terpisah. Dalam praktik, jika Anda membagi pekerjaan sebagai "di lingkungan pelanggan tangkap berkas ETL hanya dengan wpr.exe standar OS, bawa pulang, dan analisis di WPA pada mesin Anda sendiri", Anda dapat menyelidiki performa di seluruh sistem bahkan di situs tempat Anda tidak dapat menambah perangkat lunak.

Mengapa lambat ketika Task Manager menunjukkan CPU masih longgar? Apa yang dapat saya lihat di WPA?

Ketika penggunaan CPU rendah dan tetap lambat, pekerjaannya bukan tidak dapat memakai CPU — ia berhenti "menunggu sesuatu". Persaingan lock, menunggu I/O sinkron selesai, dan menunggu proses lain merespons adalah yang khas. Task Manager hanya menunjukkan hasil, yaitu penggunaan; CPU Usage (Precise) milik WPA menunjukkan, dari rekaman per-pergantian-konteks, di mana thread mulai menunggu (NewThreadStack), berapa lama ia menunggu (Waits), dan siapa yang membangunkannya (ReadyingProcess, ReadyThreadStack). Dengan menelusuri pihak yang membuatnya menunggu, Anda dapat mengidentifikasi "pelaku kelambatan" sampai ke fungsi.

Berapa lama saya harus menangkap jejak? Bukankah berkasnya akan menjadi sangat besar?

Jika Anda dapat mereproduksi masalah, dasarnya adalah mulai tepat sebelum reproduksi, berhenti tepat sesudahnya, dan menjaganya dalam beberapa menit. Bawaan WPR adalah mode Memory, yang merekam ke buffer sirkular di memori; event yang lebih lama ditimpa, jadi ia cocok untuk menunggu masalah yang waktunya tidak Anda ketahui. Mode File, dengan -filemode, menyimpan semuanya dalam berkas kontinu, tetapi satu-satunya plafon adalah ruang disk kosong, dan berkas yang terlalu besar dapat menjadi tidak dapat dianalisis di WPA. Pakai mode Memory untuk tunggu yang panjang, mode File untuk reproduksi singkat yang andal.

Bagaimana saya harus memilih antara PerfView dan WPA?

Kedua alat menangani jejak ETW, tetapi kekuatannya berbeda. PerfView memahami runtime .NET secara mendalam dan kuat pada investigasi khas aplikasi terkelola 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 adalah pilihan pertama ketika "bukan aplikasi tertentu yang lambat melainkan seluruh PC", "beberapa proses terlibat", atau "sesuatu di luar aplikasi (antivirus, driver, proses lain) dicurigai". Aturan praktisnya adalah PerfView untuk kelambatan aplikasi .NET Anda sendiri saja, WPR/WPA untuk kelambatan seluruh sistem.

Apakah tidak apa-apa menjalankan WPR di lingkungan produksi pelanggan?

Tangkap singkat biasa dalam praktik, tetapi tidak aman tanpa syarat. ETW ringan, tetapi merekam volume event yang besar beserta stack memang mengonsumsi sejumlah CPU dan memori. Lipat pertimbangan seperti mulai tepat sebelum langkah reproduksi dan berhenti tepat sesudahnya, menjaga tangkap dalam beberapa menit, dan menjalankannya pada waktu dengan dampak bisnis kecil ke dalam proses persetujuan yang sama seperti perubahan biasa. Juga, berkas ETL berisi informasi internal sistem seperti nama proses, path berkas, dan informasi executable, jadi Anda harus memutuskan di muka bagaimana ia akan ditangani jika keluar dari perusahaan (minimalisasi, masa retensi, penghapusan).

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.