WPR/WPA trong thực tế — Dẫn nhập điều tra hiệu năng toàn hệ thống cho "cả PC chậm"

“Họ nói cả PC chậm sau khi cài một ứng dụng mới. Nhưng khi tôi nhìn Task Manager, cả CPU lẫn bộ nhớ đều còn dư.” “Có một PC mất 3 phút để khởi động. Tôi chẳng biết gì sai.” — Tư vấn hiệu năng thật sự hay tới đúng hình dạng này. Điểm chung là nhìn một tiến trình cụ thể không cho câu trả lời.

Các công cụ cấp tiến trình đã có sẵn. Truy cập tệp và registry thấy được bằng Process Monitor, và CPU cùng GC của một ứng dụng .NET theo được bằng PerfView. Nhưng một triệu chứng như “cả PC chậm” hoặc “CPU rảnh mà vẫn chậm” bắt đầu từ việc còn không biết tiến trình nào là thủ phạm. Ứng dụng A có thể chậm vì một lần quét antivirus, hoặc vì một dịch vụ khác đang ghi nặng lên đĩa, hoặc vì một chuỗi lock trải qua vài tiến trình. Thứ bạn cần là dữ liệu đã ghi không phải bên trong một tiến trình mà cả OS trên một dòng thời gian.

Các công cụ để bắt và đọc đó là Windows Performance Recorder (WPR) và Windows Performance Analyzer (WPA). WPR ghi hoạt động toàn OS trên nền ETW (Event Tracing for Windows), và WPA phân tích bản ghi đó bằng đồ thị và bảng. Ai dùng CPU trên stack nào, một thread đang chờ ai, tiến trình nào phát I/O đĩa tới tệp nào — những sự thật thấp hơn Task Manager một hoặc hai bậc đều còn lại, kèm dấu thời gian.

Hướng tới nhân viên IT ở doanh nghiệp vừa và nhỏ cùng các nhà phát triển ứng dụng Windows, bài viết này sắp xếp thực hành bắt với WPR và cách đọc WPA — đặc biệt khác biệt giữa điều tra “khi CPU cao” và “khi CPU thấp mà vẫn chậm” — dựa trên nguồn gốc tính tới tháng 8 năm 2026.

1. Kết luận trước

• Lựa chọn đầu cho một cuộc điều tra “cả PC chậm” là WPR/WPA, thứ bắt và đọc một vết ETW toàn OS. Các vấn đề mà công cụ cấp tiến trình (Task Manager, Procmon, PerfView) không ghim được vẫn theo được nếu bạn nhìn mọi tiến trình và kernel trên một dòng thời gian.¹²
• Công cụ bắt wpr.exe đi kèm Windows 8.1 trở đi. Bạn dùng được mà không cần cài thêm. Bản GUI (WPRUI) và công cụ phân tích WPA nằm trong Windows ADK.¹²
• Quy trình cơ bản là ba dòng. Với quyền quản trị, wpr -start GeneralProfile -filemode → tái hiện sự cố → wpr -stop C:\temp\trace.etl. Nhớ đúng thế là bạn bắt đầu bắt được.³
• Đường cơ sở hiện trường là tách “trong môi trường khách hàng, chỉ bắt bằng wpr.exe; việc đọc là WPA trên máy của bạn”. Bạn bắt được ngay cả trên máy chủ không thể cài phần mềm. Đó cùng ý tưởng với bắt gói: “bắt bằng công cụ chuẩn, đọc trong Wireshark”.¹
• Đọc WPA bắt đầu bằng việc phân loại “CPU, chờ, hay I/O”. Nếu CPU đang cháy, CPU Usage (Sampled); nếu CPU rảnh mà vẫn chậm, phân tích chờ trong CPU Usage (Precise); nếu nghi đĩa, Disk Usage — đường tách ngay từ đầu.⁴⁵
• CPU Usage (Sampled) cho thấy “hàm nào dùng CPU” từ lấy mẫu khoảng mỗi 1 mili giây. Bạn đi được phần tách của “50%” trên Task Manager từ tiến trình → thread → stack → hàm.⁶
• CPU Usage (Precise) là bản ghi đầy đủ các lần chuyển ngữ cảnh, và cho bạn biết “một thread đang chờ ai”. Đi theo Waits (thời gian chờ), ReadyingProcess (ai đánh thức nó), và ReadyThreadStack (stack của bên đánh thức) là kỹ thuật bài viết này muốn truyền nhất.⁴⁷
• Đọc một stack đòi cấu hình ký hiệu. WPA mặc định tham chiếu máy chủ ký hiệu công khai của Microsoft. Để thấy tên hàm trong ứng dụng của bạn, thêm đường dẫn tới PDB của bạn.⁸
• Một tệp ETL chứa thông tin nội bộ hệ thống như tên tiến trình và đường dẫn tệp. Giữ lần bắt ở mức tối thiểu cần, và quyết cách xử lý nếu nó rời khỏi công ty trước khi bạn bắt.

2. Chỗ đứng của các công cụ — WPR bắt, WPA đọc

Windows Performance Toolkit (WPT) là bộ công cụ điều tra hiệu năng nằm trong Windows ADK (Windows Assessment and Deployment Kit); trung tâm là cặp WPR và WPA.² Vai trò tách rõ.

• WPR (Windows Performance Recorder) = bắt. Nó bó các nhóm nhà cung cấp ETW thành đơn vị gọi là “hồ sơ”, bắt đầu và dừng ghi, rồi tạo tệp ETL. Bản dòng lệnh, wpr.exe, đi kèm Windows 8.1 trở đi, không cần cài thêm. Bản GUI (WPRUI.exe) nằm trong ADK.¹
• WPA (Windows Performance Analyzer) = phân tích. Nó mở một tệp ETL và phân tích bằng đồ thị và bảng. Cần cài ADK.²

Nói cách khác, không có gì bạn cần đặt vào môi trường khách hàng. Bắt bằng wpr.exe chuẩn của OS, mang tệp ETL về, và đọc trong WPA trên PC của bạn — cùng cách tách như bắt gói: “bắt bằng pktmon, đọc trong Wireshark” vẫn đứng.

flowchart TB
    accTitle: Tách việc bắt bằng WPR và đọc bằng WPA
    accDescr: Trong môi trường khách hàng, ghi bằng wpr.exe chuẩn của OS và tạo tệp ETL; mang về và phân tích trong WPA cài qua ADK trên PC của bạn
    subgraph customer["PC khách hàng（không cài thêm）"]
        wpr["wpr start → tái hiện → stop"] --> etl["Tệp ETL"]
    end
    subgraph office["PC của bạn（WPA qua ADK）"]
        wpa["Phân tích đồ thị và bảng"]
    end
    etl -->|"Mang về"| wpa

Hình 1: Trong môi trường khách hàng, ghi bằng wpr.exe chuẩn của OS và tạo tệp ETL; mang về và phân tích trong WPA cài qua ADK trên PC của bạn.

Khác với các công cụ tương tự cũng đáng sắp trước.

Nếu Procmon là nhật ký thao tác “nó đã làm gì” và PerfView là “điều gì xảy ra bên trong .NET”, WPA là công cụ kiểm toán “thời gian biến mất ở đâu” xuyên mọi tiến trình. Cơ chế của chính ETW, và cách gắn công cụ vào ứng dụng của bạn bằng ETW, nằm trong “Dẫn nhập Windows Event Log và ETW”. Nếu ứng dụng của bạn phát sự kiện ETW, các mốc của ứng dụng được ghi trong cùng vết và việc xếp chúng trở nên dễ hơn nhiều. Tuy nhiên WPR chỉ ghi sự kiện từ các nhà cung cấp được hồ sơ ghi bạn chọn bật. GeneralProfile không gồm nhà cung cấp của bạn, nên nếu muốn trộn vào, hãy chuẩn bị một hồ sơ ghi tùy chỉnh (.wprp) bật nhà cung cấp của bạn và kết hợp thành wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, chỉ tên hồ sơ bên trong tệp .wprp bằng !³.

3. Bắt trong thực tế (WPR) — start, tái hiện, stop

Quy trình cơ bản trong một terminal quản trị.

:: 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

Thứ bạn truyền cho -start là một hồ sơ, bó các nhà cung cấp ETW mà cuộc điều tra cần.³ Chỉ nhớ những cái bạn dùng thường xuyên là đủ.⁹

Bạn có thể chỉ định vài hồ sơ cùng lúc bằng cách xếp -start (ví dụ wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Luồng bắt WPR và cách chọn chế độ
    accDescr: Một sự cố tái hiện được tại chỗ được bắt ngắn và chắc ở chế độ file; một sự cố không biết lúc nào xảy ra được chờ trong bộ đệm vòng chế độ memory mặc định. Sự cố lúc khởi động hoặc đăng nhập dùng vết khởi động. Trong mọi trường hợp quy trình start / tái hiện / stop giống nhau
    q{"Nó xảy ra khi nào?"}
    q -->|"Tại chỗ"| file["Chế độ File: bắt ngắn"]
    q -->|"Không biết lúc nào"| mem["Chế độ Memory: chờ（3.1）"]
    q -->|"Khởi động hoặc đăng nhập"| boot["Vết khởi động（Ch. 8）"]
    file --> s1["start → tái hiện → stop"]
    mem --> s1

Hình 2: Một sự cố tái hiện được tại chỗ được bắt ngắn và chắc ở chế độ file; một sự cố không biết lúc nào xảy ra được chờ trong bộ đệm vòng chế độ memory mặc định. Sự cố lúc khởi động hoặc đăng nhập dùng vết khởi động. Trong mọi trường hợp quy trình start / tái hiện / stop giống nhau.

3.1. Chế độ Memory và chế độ File — bạn tái hiện được, hay bạn chờ

WPR có hai chế độ đích ghi; mặc định là chế độ Memory (bộ đệm vòng trong bộ nhớ). Đó là bộ đệm vòng ghi đè từ sự kiện cũ nhất, nên phù hợp để để lần bắt chạy trong lúc bạn chờ một sự cố không biết lúc nào xảy ra, rồi dừng khi nó xảy ra. Thêm -filemode chuyển sang chế độ File, và mọi thứ được ghi vào một tệp liên tục. Cái này không bị ghi đè mất; trần duy nhất là dung lượng đĩa trống, và tệp lớn lên không giới hạn.¹⁰

flowchart TB
    accTitle: Cách chế độ Memory và chế độ File ghi
    accDescr: Chế độ Memory ghi vào bộ đệm vòng trong bộ nhớ; sự kiện cũ hơn bị ghi đè và chỉ những cái mới nhất còn lại, nên phù hợp để chờ. Chế độ File giữ mọi thứ trong một tệp, nhưng trần duy nhất là dung lượng đĩa trống, nên phù hợp cho lần tái hiện ngắn, chắc
    ev["Sự kiện ETW"] --> ring["Chế độ Memory: bộ đệm vòng"]
    ev --> filem["Chế độ File: phình một tệp"]
    ring -.-> use1["Chờ lúc không biết"]
    filem -.-> use2["Tái hiện ngắn, chắc"]

Hình 3: Chế độ Memory ghi vào bộ đệm vòng trong bộ nhớ; sự kiện cũ hơn bị ghi đè và chỉ những cái mới nhất còn lại, nên phù hợp để chờ. Chế độ File giữ mọi thứ trong một tệp, nhưng trần duy nhất là dung lượng đĩa trống, nên phù hợp cho lần tái hiện ngắn, chắc.

Quy tắc ngón tay cái để chọn như sau.

• Tái hiện được tại chỗ → chế độ File. Bắt ngay trước khi tái hiện, dừng ngay sau, và giữ lần bắt trong vài phút
• Không biết lúc nào → Chờ ở chế độ Memory (mặc định). Ngay khi nó xảy ra, wpr -stop
• Ngay cả vài phút GeneralProfile cũng có thể tạo ETL lớp hàng trăm MB tới GB. Một tệp quá lớn có thể trở nên không phân tích được trong WPA, nên “bắt càng lâu càng tốt” phản tác dụng¹⁰¹¹

Để bắt từ GUI, khởi động WPRUI, chọn hồ sơ và Logging mode, rồi Start/Save. How-to chính thức tóm tắt quy trình.¹¹ Nếu bạn nhờ một đầu mối tại hiện trường khách hàng bắt, ba lệnh trên có thể vào quy trình nguyên si.

4. Nền tảng đọc WPA — Đồ thị, quy tắc vàng của bảng, và thu hẹp thời gian

Khi bạn mở một ETL đã bắt trong WPA, Graph Explorer bên trái liệt kê hình thu nhỏ đồ thị theo các mục như System Activity, Computation, Storage và Memory.¹² Kéo một đồ thị bạn muốn xem vào tab Analysis bên phải, và một đồ thị hiện phía trên cùng một bảng phía dưới. Ba điều đầu tiên cần tiếp nhận là những điều này.

1. Quy tắc vàng của bảng — thứ tự cột quyết định nhóm. Một bảng WPA có hai thanh dọc, vàng và xanh, và các cột bên trái thanh vàng phân cấp (nhóm) dữ liệu theo thứ tự đó, còn các cột bên phải thanh xanh là tổng hợp.¹³ Xếp chúng Process → Stack và bạn được tổng hợp stack theo tiến trình; Stack → Process và bạn được tổng hợp mọi tiến trình dùng cùng stack — kéo cột để sắp lại chính là một thao tác phân tích. Hiểu một điểm này và mọi bảng WPA được đọc cùng một cách.

flowchart TB
    accTitle: Quy tắc vàng của bảng — hai thanh và vai trò của cột
    accDescr: Các cột bên trái thanh vàng phân cấp dữ liệu theo thứ tự đó; các cột giữa thanh vàng và xanh là cột hiển thị; các cột bên phải thanh xanh là tổng hợp. Kéo cột để sắp lại chính là một thao tác phân tích
    left["Trái vàng: nhóm"] --> gold["Thanh vàng"]
    gold --> mid["Giữa các thanh: hiển thị"]
    mid --> blue["Thanh xanh"]
    blue --> right["Phải xanh: tổng hợp"]
    left -.-> op["Kéo cột để phân tích"]

Hình 4: Các cột bên trái thanh vàng phân cấp dữ liệu theo thứ tự đó; các cột giữa thanh vàng và xanh là cột hiển thị; các cột bên phải thanh xanh là tổng hợp. Kéo cột để sắp lại chính là một thao tác phân tích.

1. Thu hẹp khoảng thời gian. Kéo trên đồ thị để chọn một khoảng, rồi chuột phải và “Zoom”, và tổng hợp chuyển sang chỉ khoảng đó. Điều tra hiệu năng luôn, về nguyên tắc, chỉ nhìn “khoảng lúc sự cố đang xảy ra” (Chương 9).
2. Cấu hình ký hiệu. Để đọc stack theo tên hàm, chạy Trace > Load Symbols từ menu.¹⁴ Mặc định nó tham chiếu máy chủ ký hiệu công khai của Microsoft (msdl.microsoft.com), nên các stack của chính Windows giải được nếu bạn có kết nối Internet. Để thấy tên hàm trong ứng dụng của bạn, thêm thư mục PDB của ứng dụng trong Trace > Configure Symbol Paths.⁸ PDB là gì, và vì sao bạn luôn nên giữ nó ngay cả với bản dựng Release, được tóm trong “PDB (Program Database) là gì?”. Với ảnh native NGen của .NET Framework, WPR tạo PDB NGen (.ngenpdb) lúc bắt và đặt chúng vào một thư mục cạnh vết, và WPA tham chiếu chúng tự động.⁸ Đây là cơ chế chỉ cho ảnh NGen, và mã ứng dụng .NET JIT thông thường của bạn nằm ngoài phạm vi. Ánh xạ từ địa chỉ mã JIT tới tên hàm được giải từ sự kiện JIT mà CLR phát, nên khi điều tra một ứng dụng .NET, hãy chuẩn bị một hồ sơ ghi (.wprp) bật các nhà cung cấp CLR (Microsoft-Windows-DotNETRuntime và Rundown tương ứng) và kết hợp cùng cách như nhà cung cấp của bạn ở Chương 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, để sự kiện CLR nằm trong vết (bạn kiểm tra hồ sơ dựng sẵn nào WPR cục bộ cung cấp bằng wpr -profiles). Trên đó, giữ các PDB do bản dựng tạo để ánh xạ tới dòng nguồn, và thêm chúng vào đường dẫn ký hiệu ở trên.

flowchart TB
    accTitle: Giải ký hiệu để đọc stack theo tên hàm
    accDescr: Chạy Trace Load Symbols giải chính Windows từ máy chủ ký hiệu công khai của Microsoft, và ứng dụng của bạn từ PDB bản dựng đã thêm vào đường dẫn ký hiệu. Ảnh NGen dùng PDB NGen do WPR tạo; mã .NET JIT được giải từ sự kiện JIT CLR trong vết cộng PDB bản dựng
    load["Trace > Load Symbols"] --> ms["Windows: ký hiệu công khai"]
    load --> own["Ứng dụng của bạn: PDB bản dựng"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: sự kiện CLR + PDB"]

Hình 5: Chạy Trace Load Symbols giải chính Windows từ máy chủ ký hiệu công khai của Microsoft, và ứng dụng của bạn từ PDB bản dựng đã thêm vào đường dẫn ký hiệu. Ảnh NGen dùng PDB NGen do WPR tạo; mã .NET JIT được giải từ sự kiện JIT CLR trong vết cộng PDB bản dựng.

Khi đã sẵn, bạn vào từ nhánh tiếp. Trong khoảng đó, CPU cao hay thấp? Nếu cao, Chương 5 (Sampled); nếu thấp mà vẫn chậm, Chương 6 (Precise).

flowchart TB
    accTitle: Nhánh chọn đồ thị WPA từ triệu chứng
    accDescr: Zoom tới khoảng sự cố; nếu CPU cao đi tới CPU Usage Sampled; nếu thấp mà vẫn chậm, kiểm tra ghim một nhân / một thread rồi phân tích chờ trong CPU Usage Precise; nếu nghi đĩa, Disk Usage và File IO
    zoom["Zoom tới khoảng sự cố"] --> cpu{"CPU trong khoảng đó?"}
    cpu -->|"Cao"| sampled["Ch. 5: Sampled"]
    cpu -->|"Thấp, vẫn chậm"| core{"Ghim 1 nhân / 1 thread?"}
    core -->|"Có"| sampled
    core -->|"Không"| precise["Ch. 6: Precise"]
    cpu -->|"Nghi đĩa"| disk["Ch. 7: Đĩa / File I/O"]

Hình 6: Zoom tới khoảng sự cố; nếu CPU cao đi tới CPU Usage Sampled; nếu thấp mà vẫn chậm, kiểm tra ghim một nhân / một thread rồi phân tích chờ trong CPU Usage Precise; nếu nghi đĩa, Disk Usage và File IO.

5. Khi CPU cao — “Ai đang đốt hàm nào” với CPU Usage (Sampled)

Nếu CPU bị ghim, thứ bạn nhìn là CPU Usage (Sampled). Đây là dữ liệu lấy mẫu đã ghi, khoảng mỗi 1 mili giây trên mọi CPU, “stack của tiến trình nào đang chạy lúc này”, và tỷ lệ số mẫu chính là phần tách thời gian CPU nguyên si.⁶

flowchart TB
    accTitle: Cách CPU Usage Sampled hoạt động
    accDescr: Khoảng mỗi 1 mili giây, stack đang chạy trên mọi CPU được ghi, và tỷ lệ mẫu đã tổng hợp là phần tách thời gian CPU. Đọc từ tiến trình tới thread, stack và hàm. Hoạt động ngắn kết thúc giữa các mẫu không xuất hiện
    tick["Ngắt khoảng mỗi 1 ms"] --> snap["Ghi stack đang chạy"]
    snap --> agg["Tỷ lệ mẫu = phần tách CPU"]
    agg --> drill["Process → Thread → Stack"]
    snap -.-> miss["Hoạt động giữa các mẫu bị bỏ"]

Hình 7: Khoảng mỗi 1 mili giây, stack đang chạy trên mọi CPU được ghi, và tỷ lệ mẫu đã tổng hợp là phần tách thời gian CPU. Đọc từ tiến trình tới thread, stack và hàm. Hoạt động ngắn kết thúc giữa các mẫu không xuất hiện.

1. Từ Computation của Graph Explorer, đặt CPU Usage (Sampled) lên tab Analysis và chọn preset Utilization by Process, Stack.⁵
2. Nhìn các tiến trình theo thứ tự giảm dần Weight (hoặc Count). Danh tính của thứ từng là “50%” trên Task Manager rõ trước hết ở cấp tiến trình.
3. Mở cột Stack của tiến trình thủ phạm. Stack được tổng hợp thành cây, và đi theo đường mà con số không giảm nhiều ở một nhánh đưa bạn tới hàm đang đốt CPU. Nếu ký hiệu đã giải, đó là đường thẳng tới hàm nào trong mã của bạn.
4. Nếu mở cây mệt, chuyển hiển thị đồ thị sang Flame. Nó vẽ với chiều rộng = phần thời gian CPU, nên đường gọi nào chiếm ưu thế lộ ngay. CPU Usage (Sampled) cũng có preset Flame by Process, Stack.¹³

Có một lưu ý. Vì đây là lấy mẫu, hoạt động ngắn kết thúc giữa các mẫu không xuất hiện.⁶ Hãy nhớ nó như công cụ để thấy “CPU được dùng ở đâu theo tổng”, không phải công cụ đo đúng thời lượng từng lần gọi.

6. Khi CPU thấp mà vẫn chậm — CPU Usage (Precise) và phân tích chờ

Đây là lõi của bài. Trước khi sang phân tích chờ, tuy nhiên, có một điều cần xác nhận. “Mức dùng CPU tổng thấp” không nghĩa “CPU không phải nút thắt”. Trên PC 16 nhân, việc tuần tự bị ghim vào một nhân (một thread UI chạy hết sức) chỉ trông như khoảng 6% tổng. Trước hết kiểm tra trong Sampled của Chương 5 (hoặc Utilization by CPU của CPU Usage (Precise)) rằng không có ghim trên một nhân hay thread cụ thể, và nếu không có thì tới chương này — việc không phải không chạy được, nó đang chờ. Thứ cho bạn biết nó chờ gì là CPU Usage (Precise).

Nơi Sampled là lấy mẫu, Precise là bản ghi đầy đủ các lần chuyển ngữ cảnh (chuyển thread). Một thread vào chờ, được ai đó đánh thức (Ready), rồi đáp xuống một CPU — khứ hồi đó còn lại từng hàng, và bạn đọc được các cột sau.⁷⁴

flowchart TB
    accTitle: Một khứ hồi chờ và cách các cột tương ứng
    accDescr: Một thread vào chờ trên stack còn lại trong NewThreadStack, và chờ trong thời gian Waits. Khi ai đó đánh thức nó, bên đó còn lại trong ReadyingProcess và ReadyThreadStack; nó chờ thời gian Ready vì tranh CPU rồi chạy lại
    run1["Đang chạy"] -->|"Vào chờ"| waitst["Chờ（Waits us）"]
    waitst -->|"Ai đó đánh thức"| ready["Ready（tranh CPU）"]
    ready -->|"Đáp xuống một CPU"| run2["Chạy lại"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

Hình 8: Một thread vào chờ trên stack còn lại trong NewThreadStack, và chờ trong thời gian Waits. Khi ai đó đánh thức nó, bên đó còn lại trong ReadyingProcess và ReadyThreadStack; nó chờ thời gian Ready vì tranh CPU rồi chạy lại.

Mẫu đọc như sau.⁴

1. Áp preset Utilization by Process, Thread và thêm NewThreadStack cùng ReadyThreadStack vào các cột.
2. Trước hết xác định thread đang thực thi thao tác bị trễ (thread UI, thread xử lý yêu cầu đang bàn). Chỉ nhìn theo thứ tự giảm dần tổng Waits sẽ rối, vì các thread “cố ý chờ suốt”, như bơm thông điệp hoặc bộ hẹn giờ, chiếm đỉnh. Khi đã tìm thấy thread đích, nếu CPU Usage (ms) của nó lớn thì đó là vấn đề CPU Chương 5; nếu Waits chiếm ưu thế thì đó là vấn đề chờ.
3. Mở NewThreadStack và xem nó đang làm gì khi dừng. WaitForSingleObject hoặc EnterCriticalSection là chờ lock; bên trong I/O đồng bộ như ReadFile là chờ I/O; bên trong nhận socket là chờ bên kia trả lời.
4. Tiếp theo xem ai đã giải chờ. Mở ReadyThreadStack và kiểm ReadyingProcess / ReadyingThreadId. Nếu nó bị đánh thức từ KiTimerExpiration của kernel thì đó là bộ hẹn giờ (= nó ngủ tới hết thời gian chờ); nếu bị đánh thức từ xử lý hoàn tất I/O, điều đó xác nhận đó là chờ I/O.⁴
5. Nếu bên đánh thức là một thread khác hoặc tiến trình khác, điều tra thread đó bằng cùng quy trình. “A đang chờ B giải lock, B đang chờ phản hồi RPC của C, C đang chờ I/O đĩa” — thứ bạn có khi đã đi chuỗi này tới gốc là đường găng của độ trễ.⁷

flowchart TB
    accTitle: Chuỗi đường găng bạn đi trong phân tích chờ
    accDescr: Xem trong NewThreadStack của thread A bị trễ nó đang làm gì khi dừng, xác định bên đánh thức B từ ReadyThreadStack và ReadyingProcess, rồi điều tra B bằng cùng quy trình xuống tới I/O đĩa gốc
    a["Thread A（việc bị trễ）"] -->|"Chờ lock"| b["Thread B（giữ lock）"]
    b -->|"Chờ RPC"| c["Tiến trình C"]
    c -->|"Chờ I/O đồng bộ"| d["I/O đĩa（gốc）"]
    d -.->|"Hoàn tất đánh thức C"| c
    c -.->|"Phản hồi đánh thức B"| b
    b -.->|"Giải lock đánh thức A"| a

Hình 9: Xem trong NewThreadStack của thread A bị trễ nó đang làm gì khi dừng, xác định bên đánh thức B từ ReadyThreadStack và ReadyingProcess, rồi điều tra B bằng cùng quy trình xuống tới I/O đĩa gốc.

Trong một vụ như “chúng tôi đa luồng mà không nhanh hơn”, quy trình này cho thấy mọi worker xếp hàng trên một lock nguyên si. Tránh tranh lock bằng thiết kế nằm trong “Thực hành đa luồng tốt nhất: bản .NET”, và cơ chế Windows chạy trên thông báo hoàn tất thay vì chờ trong I/O đồng bộ nằm trong “I/O Completion Ports (IOCP) và .NET Thread Pool”. Ghim “nó đang chờ ai” trong WPA rồi sửa bằng những luận điểm thiết kế đó là một dòng liên tục.

7. Đĩa và I/O tệp — Xác định “ai đó đang quét đĩa”

Một thủ phạm kinh điển của “cả PC chậm” không phải CPU mà là đĩa. Bạn điều tra bằng Disk Usage và File I/O trong mục Storage.¹⁵

Disk Usage là bản ghi I/O đĩa, và hai cột quan trọng. Disk Service Time là thời gian thiết bị đĩa thực sự dành để xử lý I/O đó; IO Time là thời gian từ lúc I/O vào hàng đợi OS tới khi xong. IO Time luôn ít nhất bằng Service Time đúng phần xếp hàng, nên nếu IO Time dài hơn Service Time nhiều, I/O đó đang “chờ trong hàng”.⁶ Chỉ thế, tuy nhiên, không quyết được thủ phạm tạo hàng là tiến trình khác, hay chỉ I/O nặng của chính tiến trình đó xếp trên một thiết bị chậm. Đừng kết luận ở đây; chốt bằng Service Time (phản hồi của chính thiết bị) và phần tách tiếp theo theo tiến trình, đường dẫn, và stack.

Rồi, với preset Utilization by Process, Path Name, Stack, nhìn tiến trình nào phát I/O tới tệp nào từ stack nào, theo thứ tự giảm dần IO Time hoặc Size.¹⁵ Các câu trả lời hay gặp hiện trường là hai cái này.

• Antivirus đang quét mọi tệp. Trong cửa sổ lúc ứng dụng khởi động chậm, tiến trình antivirus được thấy phát một khối lượng lớn lần đọc. Tên tiến trình, đường dẫn, và khối lượng là bằng chứng nguyên si cho một cuộc thảo luận loại trừ.
• Một tiến trình khác đang ghi nặng. Sao lưu, trình lập chỉ mục, nhật ký ghi quá nhiều, và tương tự. Khi một lần ghi tới đĩa liên quan cache manager, nên sự thật rằng “lúc bạn ghi” và “lúc đĩa bận” có thể lệch cũng nằm trong “Cache Manager — WriteFile của bạn thực sự tới đĩa khi nào?”.

File I/O là một tầng trên, bản ghi các thao tác tệp ứng dụng phát (Create/Read/Write và tương tự), và các preset như Duration by Process, Thread, Type có thể tổng hợp thời gian theo tên tệp và theo thao tác.¹⁵ Một vụ tiêu thời gian trong hệ thống tệp hoặc một driver lọc trước khi tới đĩa không xuất hiện trong Disk Usage, nên chính sự lệch — “Disk Usage yên mà File I/O chậm” — là manh mối. Nếu muốn bắt đầu từ cơ chế I/O đồng bộ và không đồng bộ, xem “I/O đồng bộ và không đồng bộ — OVERLAPPED thực sự nghĩa gì”.

flowchart TB
    accTitle: Các tầng khác nhau mà File IO và Disk Usage thấy
    accDescr: Thao tác tệp của ứng dụng đi qua hệ thống tệp và các driver lọc từ hàng đợi I/O của OS tới thiết bị đĩa. File IO ghi thao tác ở tầng trên; Disk Usage ghi I/O đã tới đĩa; hiệu giữa IO Time và Disk Service Time là thời gian hàng đợi
    app["Ứng dụng: ReadFile / WriteFile"] --> fio["FS và bộ lọc（File I/O）"]
    fio --> queue["Hàng đợi I/O OS"]
    queue --> dev["Thiết bị đĩa（Disk Usage）"]
    fio -.-> n1["Disk Usage bỏ sót"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = thiết bị"]

Hình 10: Thao tác tệp của ứng dụng đi qua hệ thống tệp và các driver lọc từ hàng đợi I/O của OS tới thiết bị đĩa. File IO ghi thao tác ở tầng trên; Disk Usage ghi I/O đã tới đĩa; hiệu giữa IO Time và Disk Service Time là thời gian hàng đợi.

Dòng nghĩ “có lẽ thiếu bộ nhớ và đang hoán trang” có thể được cô lập lần đầu trong Task Manager và Resource Monitor trước khi bạn tới WPA. Đừng, tuy nhiên, bác bỏ chỉ từ bộ nhớ đã cam kết — ngay cả khi còn dư commit, một tình huống áp lực bộ nhớ vật lý cắt working set và hard fault tiếp diễn vẫn có thể. Cũng kiểm bộ nhớ vật lý khả dụng và “Hard Faults/sec” của Resource Monitor. Cách đọc chúng nằm trong “"Mức dùng bộ nhớ" của Windows thực sự nghĩa gì?”.

8. Khởi động và đăng nhập chậm — Cửa vào một vết khởi động

Một kiểu “mất 3 phút để khởi động” kết thúc trước khi bạn kịp chạy tay wpr -start. WPR có một vết khởi động, và bạn có thể sắp để OS bắt đầu ghi tự động ở lần khởi động tiếp.³

:: 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: Luồng vết khởi động
    accDescr: Sau khi bạn sắp ghi tự động ở lần khởi động tiếp bằng addboot rồi khởi động lại, OS bắt đầu ghi tự động lúc khởi động. Lưu bằng stopboot sau đăng nhập cũng gỡ sắp xếp. Để bỏ, gỡ bằng cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["Khởi động lại（khởi động chậm）"]
    rebootpc --> auto["OS ghi lúc khởi động"]
    auto --> stop2["Sau đăng nhập: -stopboot"]
    add -.-> cancel["Bỏ: -cancelboot"]

Hình 11: Sau khi bạn sắp ghi tự động ở lần khởi động tiếp bằng addboot rồi khởi động lại, OS bắt đầu ghi tự động lúc khởi động. Lưu bằng stopboot sau đăng nhập cũng gỡ sắp xếp. Để bỏ, gỡ bằng cancelboot.

Phép đo khởi động và tắt máy từng thuộc xbootmgr cũng chạy được trong WPR hiện tại với các tùy chọn như -onoffscenario Boot.³ Một vết đã bắt được đọc bằng cùng bộ công cụ như các chương trước. Nhìn tiến trình nào sinh khi nào trên dòng thời gian trong đồ thị Processes, zoom tới cửa sổ lúc khởi động kẹt, rồi phân loại CPU, chờ, hay đĩa — một ứng dụng khởi động đang chờ thứ gì đó nối tiếp, một lần khởi động dịch vụ kẹt trên một I/O cụ thể, và tương tự lộ ra. Phân tích khởi động là một chuyên môn sâu riêng, nên bài viết này chỉ tới cửa vào: “một sự cố bạn không bắt được bằng tay vẫn bắt được bằng WPR”. Bắt đầu bằng nắm toàn cảnh với một vết khởi động GeneralProfile.

9. Một mẫu làm việc — Phân loại → Zoom → Stack, lặp lại

Khi các công cụ đã rõ, đây là mẫu cho cuộc điều tra nói chung.

1. Ghim thời điểm của hiện tượng. Không phải “nó chậm”, mà “10:23:40–10:24:10 chậm”. Nhật ký ứng dụng, nhật ký sự kiện, ghi chú của người đã thao tác — gì cũng được. Nếu ứng dụng của bạn ghi các mốc vào ETW hoặc nhật ký sự kiện, các sự kiện trong vết trở thành cọc thời gian nguyên si.
2. Zoom chỉ tới khoảng đó. Một tổng hợp của cả vết bị làm trung bình, và dị thường quan trọng bị pha loãng. Phân tích WPA luôn là so sánh “khoảng bất thường” với “khoảng bình thường”.
3. Phân loại “CPU, chờ, hay I/O” trước. Nhìn CPU Usage (Sampled); nếu đang cháy, Chương 5. Nếu không cháy, Waits trong CPU Usage (Precise) (Chương 6). Nếu IO Time của Disk Usage phình, Chương 7. Lấy ngã ba này trước giữ bạn khỏi lạc.
4. Lặp giả thuyết → zoom → stack. Nếu nghĩ “antivirus?”, thu hẹp tới tiến trình đó và chống bằng stack. Nếu không đứng, giả thuyết tiếp. Không kết luận trước khi đã đi tới stack và chống được là kỷ luật của kiểu điều tra này.

flowchart TB
    accTitle: Vòng lặp của một cuộc điều tra hiệu năng
    accDescr: Ghim thời điểm của hiện tượng, zoom tới khoảng, phân loại CPU / chờ / I/O, lập giả thuyết và thu hẹp, rồi chống bằng stack. Nếu đứng, nguyên nhân được xác nhận; nếu không, lặp với giả thuyết tiếp
    time["Ghim thời điểm"] --> zoomstep["Zoom tới khoảng đó"]
    zoomstep --> triage["Phân loại CPU / chờ / I/O"]
    triage --> hypo["Giả thuyết và thu hẹp"]
    hypo --> stack["Chống bằng stack"]
    stack -->|"Đứng"| fix["Nguyên nhân được xác nhận"]
    stack -->|"Không"| hypo

Hình 12: Ghim thời điểm của hiện tượng, zoom tới khoảng, phân loại CPU / chờ / I/O, lập giả thuyết và thu hẹp, rồi chống bằng stack. Nếu đứng, nguyên nhân được xác nhận; nếu không, lặp với giả thuyết tiếp.

Cuối cùng, xử lý tệp bắt. Một tệp ETL phản ánh rộng bên trong hệ thống: tên mọi tiến trình, đường dẫn các tệp đã mở, các mô-đun đã nạp, và (tùy hồ sơ) tên khóa registry. Một lần bắt GeneralProfile chuẩn không gồm thân dữ liệu như nội dung giao tiếp, nhưng nếu bạn bật một nhà cung cấp tùy chỉnh, payload của sự kiện đó (chuỗi ứng dụng đã ghi, và tương tự) vào nguyên si. Sau khi xác nhận nhà cung cấp bạn bật phát gì, hãy coi nó như một tệp đủ mật để rời khỏi công ty. Như bắt gói, hãy gói lần bắt tối thiểu cần, thỏa thuận với bên bạn giao, cùng thời hạn lưu và xóa vào quy trình.

flowchart TB
    accTitle: Tệp ETL phản ánh gì, và cách xử lý
    accDescr: Một ETL phản ánh mọi tên tiến trình, đường dẫn các tệp đã mở, mô-đun, và tùy hồ sơ tên khóa registry; bật một nhà cung cấp tùy chỉnh cũng gồm payload của nó. Coi như mật: lần bắt tối thiểu cần, thỏa thuận với bên kia, cùng thời hạn lưu và xóa
    etl["Tệp ETL"] --> a1["Tên, đường dẫn, mô-đun"]
    a1 --> a2["Khóa registry（một số）"]
    a2 --> a3["Payload tùy chỉnh"]
    a3 -.-> rule["Coi như mật"]

Hình 13: Một ETL phản ánh mọi tên tiến trình, đường dẫn các tệp đã mở, mô-đun, và tùy hồ sơ tên khóa registry; bật một nhà cung cấp tùy chỉnh cũng gồm payload của nó. Coi như mật: lần bắt tối thiểu cần, thỏa thuận với bên kia, cùng thời hạn lưu và xóa.

10. Tóm tắt

• Một vụ “cả PC chậm” mà Task Manager không giải thích được được điều tra bằng một vết ETW toàn OS — bắt bằng WPR, đọc bằng WPA. wpr.exe đi kèm Windows 8.1 trở đi, nên cách tách bắt trong môi trường khách hàng, mang ETL về, và đọc trong WPA trên máy của bạn đứng vững.
• Bắt là ba bước wpr -start GeneralProfile -filemode → tái hiện → wpr -stop trace.etl. Nếu tái hiện được, chế độ File trong vài phút; nếu chờ, chế độ Memory (bộ đệm vòng). Dài hơn không tốt hơn.
• WPA bắt đầu được khi bạn đã tiếp nhận ba điểm: quy tắc vàng của bảng (trái thanh vàng = nhóm), zoom khoảng thời gian, và cấu hình ký hiệu (ứng dụng của bạn cần PDB).
• Nếu CPU cao, đi tiến trình → stack → hàm trong CPU Usage (Sampled). Nếu CPU thấp mà vẫn chậm, đi chuỗi NewThreadStack (nó đang làm gì khi dừng) → Waits (chờ bao lâu) → ReadyingProcess và ReadyThreadStack (ai đánh thức nó) tới gốc trong CPU Usage (Precise).
• Với đĩa, xem “thời gian nằm trong hàng” từ hiệu giữa IO Time và Service Time của Disk Usage, và xác định nguyên nhân (thiết bị tự chậm, hay ai tạo hàng) từ Service Time và phần tách theo tiến trình, đường dẫn, và stack. Khởi động chậm bắt được bằng wpr -boottrace.
• Mẫu làm việc là (1) ghim thời điểm (2) zoom tới khoảng (3) phân loại CPU, chờ, hay I/O (4) lặp giả thuyết → zoom → stack. Coi ETL như mật vì nó chứa thông tin nội bộ.

Màn hình WPA đáng sợ, và ai cũng lạc trong giờ đầu. Khi hai xương sống — “trái thanh vàng là nhóm” và “Sampled là chỗ nó cháy, Precise là nó chờ ai” — đã vào, phần còn lại là cùng thao tác lặp lại. Lần tới một cuộc tư vấn tới rằng “CPU còn dư mà vẫn chậm”, hãy đóng Task Manager và bắt một vết.

Bài viết liên quan

• Ghim “chậm” bằng PerfView và dotnet-trace — Dẫn nhập thực hành điều tra hiệu năng .NET
• Hướng dẫn thực hành Process Monitor (ProcMon) — Ghim “thiết lập không áp dụng” và “ACCESS DENIED” trong 10 phút
• Dẫn nhập Windows Event Log và ETW — Đặt nhật ký ứng dụng nghiệp vụ của bạn lên các cơ chế chuẩn của OS
• “Mức dùng bộ nhớ” của Windows thực sự nghĩa gì? — Đọc đúng Working Set, Private Bytes, Commit, và Page File
• Thiết lập lập lịch bộ xử lý Windows — Dịch vụ nền và nhân P/E
• PDB (Program Database) là gì? — Hiểu thông tin gỡ lỗi, ký hiệu, và Source Link

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận điều tra các vấn đề hiệu năng toàn hệ thống như “cả PC chậm mà tôi không biết vì sao”, “CPU còn dư mà ứng dụng vẫn chậm”, và “chỉ một môi trường cụ thể khởi động cực chậm”. Chúng tôi đảm nhận như một hợp đồng liên tục việc thiết kế bắt với WPR/WPA (môi trường nào, hồ sơ nào, bắt bao nhiêu), phân tích vết, và bản sửa kết quả ở phía ứng dụng cùng phía thiết lập.

• Phát triển ứng dụng Windows
• Điều tra lỗi và phân tích nguyên nhân gốc rễ
• Tư vấn kỹ thuật và rà soát thiết kế
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Tôi lấy WPR và WPA ở đâu? Có dùng được trong môi trường khách hàng nơi tôi không thể cài phần mềm không?

Công cụ bắt wpr.exe (bản dòng lệnh) đi kèm Windows 8.1 trở đi, nên bạn dùng được mà không cần cài thêm. Bản GUI, WPRUI, và công cụ phân tích WPA (Windows Performance Analyzer) nằm trong Windows ADK (Windows Assessment and Deployment Kit) và đúng là cần cài riêng. Trong thực tế, nếu bạn tách việc thành "trong môi trường khách hàng chỉ bắt tệp ETL bằng wpr.exe chuẩn của OS, mang về, rồi phân tích trong WPA trên máy của mình", bạn có thể điều tra hiệu năng toàn hệ thống ngay cả tại nơi không thể thêm phần mềm.

Vì sao vẫn chậm khi Task Manager cho thấy CPU còn dư? Tôi thấy gì trong WPA?

Khi mức dùng CPU thấp mà vẫn chậm, việc không phải không dùng được CPU — nó đang dừng "chờ một thứ gì đó". Tranh lock, chờ I/O đồng bộ xong, và chờ tiến trình khác trả lời là điển hình. Task Manager chỉ cho kết quả, tức mức dùng; CPU Usage (Precise) của WPA cho thấy, từ bản ghi từng lần chuyển ngữ cảnh, thread bắt đầu chờ ở đâu (NewThreadStack), chờ bao lâu (Waits), và ai đánh thức nó (ReadyingProcess, ReadyThreadStack). Đi theo bên đã làm nó chờ, bạn xác định được "thủ phạm của sự chậm" tới tận hàm.

Tôi nên bắt vết bao lâu? Tệp sẽ không phình quá lớn chứ?

Nếu tái hiện được sự cố, đường cơ sở là bắt ngay trước khi tái hiện, dừng ngay sau, và giữ trong vài phút. Mặc định của WPR là chế độ Memory, ghi vào bộ đệm vòng trong bộ nhớ; sự kiện cũ hơn bị ghi đè, nên phù hợp để chờ một sự cố mà bạn không biết lúc nào xảy ra. Chế độ File, với -filemode, giữ mọi thứ trong một tệp liên tục, nhưng trần duy nhất là dung lượng đĩa trống, và tệp quá lớn có thể trở nên không phân tích được trong WPA. Dùng chế độ Memory cho lần chờ dài, chế độ File cho lần tái hiện ngắn, chắc.

Tôi nên chọn PerfView hay WPA?

Cả hai công cụ xử lý vết ETW, nhưng thế mạnh khác nhau. PerfView hiểu sâu runtime .NET và mạnh ở điều tra đặc thù ứng dụng managed như GC, cấp phát, và JIT. WPA phù hợp để đọc CPU, đĩa, I/O tệp, nguồn, và tương tự trên toàn OS qua đồ thị và bảng, và là lựa chọn đầu khi "không phải một ứng dụng cụ thể mà cả PC chậm", "nhiều tiến trình liên quan", hoặc "nghi thứ gì ngoài ứng dụng (antivirus, driver, tiến trình khác)". Quy tắc ngón tay cái là PerfView cho sự chậm của riêng ứng dụng .NET của bạn, WPR/WPA cho sự chậm của cả hệ thống.

Chạy WPR trong môi trường sản xuất của khách hàng có ổn không?

Một lần bắt ngắn là thực tế thường gặp, nhưng không vô điều kiện an toàn. ETW nhẹ, nhưng ghi một khối lượng lớn sự kiện kèm stack vẫn tiêu một lượng CPU và bộ nhớ nhất định. Gói các cân nhắc như bắt ngay trước bước tái hiện và dừng ngay sau, giữ lần bắt trong vài phút, và chạy vào lúc ít tác động nghiệp vụ vào cùng quy trình phê duyệt như mọi thay đổi thông thường. Ngoài ra, tệp ETL chứa thông tin nội bộ hệ thống như tên tiến trình, đường dẫn tệp, và thông tin executable, nên bạn nên quyết trước cách xử lý nếu nó rời khỏi công ty (tối thiểu hóa, thời hạn lưu, xóa).

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.