WPR/WPA عمليّاً ── مدخل إلى تحقيق أداء المنظومة عند «الحاسوب كلّه بطيء»

«قالوا إنّ الحاسوب كلّه صار بطيئاً بعد تثبيت تطبيق جديد. لكن حين أنظر إلى مدير المهام، المعالج والذاكرة فيهما فائض.» «ثمّة حاسوب واحد يستغرق 3 دقائق ليبدأ. لا أدري ما الخطب.» ── استشارات الأداء تأتي فعلاً بهذا الشكل كثيراً. المشترك بينها أنّ النظر إلى عمليّة معيّنة لا يعطيك جواباً.

أدوات مستوى العمليّة موجودة. وصول الملفّات والسجلّ يُرى بـProcess Monitor، ومعالج تطبيق .NET وGC يمكن تتبّعهما بـPerfView. لكنّ عَرَضاً مثل «الحاسوب كلّه بطيء» أو «المعالج خامل وما زال بطيئاً» يبدأ من أنّك لا تعلم حتّى أيّ عمليّة هي الجاني. قد يكون التطبيق أ بطيئاً بسبب فحص مضادّ فيروسات، أو لأنّ خدمة أخرى تكتب بكثافة إلى القرص، أو بسبب سلسلة أقفال تمتدّ عبر عدّة عمليّات. ما تحتاجه هو بيانات سجّلت ليس داخل عمليّة بل نظام التشغيل ككلّ على خطّ زمنيّ واحد.

أداتا التقاط ذلك وقراءته هما Windows Performance Recorder (WPR) وWindows Performance Analyzer (WPA). يسجّل WPR نشاط المنظومة على أساس ETW (Event Tracing for Windows)، ويحلّل WPA ذلك التسجيل في رسوم وجداول. من استخدم المعالج على أيّ مكدّس، ومن كان الخيط ينتظره، وأيّ عمليّة أصدرت دخل/خرج قرص إلى أيّ ملفّ ── حقائق أعمق بدرجة أو درجتين من مدير المهام تبقى كلّها، بطوابع زمنيّة.

موجَّه إلى موظّفي تقنيّة المعلومات في المنشآت الصغيرة والمتوسّطة ومطوِّري تطبيقات Windows، ينظِّم هذا المقال ممارسة الالتقاط بـ WPR وكيفيّة قراءة WPA ── خصوصاً الفرق بين التحقيق «عندما يكون المعالج مرتفعاً» و«عندما يكون المعالج منخفضاً وما زال بطيئاً» ── مستنداً إلى المصادر الأوّليّة حتّى أغسطس 2026.

1. الخلاصة أوّلاً

• الخيار الأوّل لتحقيق «الحاسوب كلّه بطيء» هو WPR/WPA، الذي يلتقط أثر ETW على مستوى نظام التشغيل ويقرأه. المشكلات التي لا تستطيع أدوات مستوى العمليّة (مدير المهام، Procmon، PerfView) تثبيتها يمكن تتبّعها إن نظرت إلى كلّ عمليّة والنواة على خطّ زمنيّ واحد.¹²
• أداة الالتقاط wpr.exe تأتي مع Windows 8.1 وما بعده. يمكنك استخدامها بلا تثبيت إضافيّ. الإصدار الرسوميّ (WPRUI) وأداة التحليل WPA مضمّنان في Windows ADK.¹²
• الإجراء الأساسيّ ثلاثة أسطر. كمسؤول، wpr -start GeneralProfile -filemode ← أعد إنتاج المشكلة ← wpr -stop C:\temp\trace.etl. تذكّر ذلك فحسب ويمكنك البدء بالالتقاط.³
• الأساس الميدانيّ تقسيم «في بيئة العميل، التقط فقط بـ wpr.exe؛ القراءة في WPA على جهازك». يمكنك الالتقاط حتّى على خادم لا تستطيع تثبيت برمجيّات عليه. الفكرة نفسها فكرة التقاط الحزم: «التقط بأداة قياسيّة، اقرأ في Wireshark».¹
• قراءة WPA تبدأ بتصنيف «معالج، انتظار، أم دخل/خرج». إن كان المعالج يحترق فـ CPU Usage (Sampled)؛ إن كان المعالج خاملاً وما زال بطيئاً فتحليل الانتظار في CPU Usage (Precise)؛ إن اشتُبِه بالقرص فـ Disk Usage ── المسار ينقسم من البداية.⁴⁵
• CPU Usage (Sampled) يُظهر «أيّ دالّة استخدمت المعالج» من أخذ عيّنات نحو كلّ 1 مليّ ثانية. يمكنك تتبّع تفصيل «50%» في مدير المهام من عمليّة ← خيط ← مكدّس ← دالّة.⁶
• CPU Usage (Precise) سجلّ كامل لتبديلات السياق، ويخبرك «من كان الخيط ينتظره». تتبّع Waits (زمن الانتظار) وReadyingProcess (من أيقظه) وReadyThreadStack (مكدّس الموقظ) هو التقنيّة التي يريد هذا المقال إيصالها أكثر من غيرها.⁴⁷
• قراءة مكدّس تتطلّب ضبط الرموز. يشير WPA افتراضيّاً إلى خادم رموز مايكروسوفت العلنيّ. لرؤية أسماء الدوالّ في تطبيقك، أضف مسار ملفّات PDB الخاصّة بك.⁸
• ملفّ ETL يحتوي معلومات داخليّة عن النظام كأسماء العمليّات ومسارات الملفّات. أبقِ الالتقاط عند الحدّ الأدنى اللازم، وقرّر كيف سيُعالَج إن خرج من الشركة قبل أن تلتقط.

2. أين تقع الأداتان ── WPR يلتقط، WPA يقرأ

Windows Performance Toolkit (WPT) مجموعة أدوات تحقيق الأداء المضمّنة في Windows ADK (Windows Assessment and Deployment Kit)؛ المركز هو زوج WPR وWPA.² الأدوار منقسمة بوضوح.

• WPR (Windows Performance Recorder) = التقاط. يجمع مجموعات مزوِّدي ETW في وحدة تُدعى «ملفّ تعريف» (profile)، يبدأ التسجيل ويوقفه، وينتج ملفّ ETL. الإصدار سطر الأوامر، wpr.exe، يأتي مع Windows 8.1 وما بعده، بلا تثبيت إضافيّ. الإصدار الرسوميّ (WPRUI.exe) مضمّن في ADK.¹
• WPA (Windows Performance Analyzer) = تحليل. يفتح ملفّ ETL ويحلّله في رسوم وجداول. تثبيت ADK مطلوب.²

بعبارة أخرى، لا شيء تحتاج إلى وضعه في بيئة العميل. التقط بـ wpr.exe القياسيّ في نظام التشغيل، خذ ملفّ ETL إلى مكتبك، واقرأه في WPA على حاسوبك ── التقسيم نفسه الذي في التقاط الحزم «التقط بـ pktmon، اقرأ في Wireshark» يصمد.

flowchart TB
    accTitle: تقسيم الالتقاط بـ WPR والقراءة بـ WPA
    accDescr: في بيئة العميل سجّل بـ wpr.exe القياسيّ في نظام التشغيل وأنتِج ملفّ ETL؛ خذه إلى مكتبك وحلّله في WPA المثبَّت عبر ADK على حاسوبك
    subgraph customer["حاسوب العميل（بلا تثبيت إضافيّ）"]
        wpr["wpr start ← أعد الإنتاج ← stop"] --> etl["ملفّ ETL"]
    end
    subgraph office["حاسوبك（WPA عبر ADK）"]
        wpa["حلّل الرسوم والجداول"]
    end
    etl -->|"خذه إلى المكتب"| wpa

الشكل 1: في بيئة العميل سجّل بـ wpr.exe القياسيّ في نظام التشغيل وأنتِج ملفّ ETL؛ خذه إلى مكتبك وحلّله في WPA المثبَّت عبر ADK على حاسوبك.

كيف يختلف عن أدوات مشابهة يستحقّ التنظيم أوّلاً أيضاً.

إن كان Procmon سجلّ عمليّات «ماذا فعل» وPerfView «ماذا حدث داخل .NET»، فإنّ WPA أداة تدقّق «أين اختفى الوقت» عبر كلّ عمليّة. آليّة ETW نفسها، وكيفيّة تجهيز تطبيقك بـ ETW، مشمولتان في «مدخل إلى سجلّ أحداث Windows وETW». إن أصدر تطبيقك أحداث ETW، تُسجَّل نقاط التحقّق في تطبيقك في الأثر نفسه ويصبح صفّها أسهل بكثير. غير أنّ WPR يسجّل فقط أحداث المزوِّدين الذين يفعّلهم ملفّ تعريف التسجيل الذي اخترته. GeneralProfile لا يتضمّن مزوِّديك، لذا إن أردتها مخلوطة، جهّز ملفّ تعريف تسجيل مخصّصاً (.wprp) يفعّل مزوِّديك واجمعه كـ wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile، محدِّداً اسم ملفّ التعريف داخل ملفّ .wprp بـ !³.

3. الالتقاط عمليّاً (WPR) ── start، أعد الإنتاج، stop

الإجراء الأساسيّ في طرفيّة مسؤول.

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

ما تمرّره إلى -start هو ملفّ تعريف، حزمة مزوِّدي ETW التي يحتاجها التحقيق.³ تذكّر فقط تلك التي تستخدمها كثيراً يكفي.⁹

يمكنك تحديد عدّة ملفّات تعريف دفعةً بصفّ -start (مثلاً wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: تدفّق التقاط WPR وكيفيّة اختيار الوضع
    accDescr: مشكلة يمكن إعادة إنتاجها في الحال تُلتقَط قصيرة وموثوقة في وضع الملفّ؛ مشكلة لا تعرف توقيتها تُنتظَر في مخزن الحلقة الافتراضيّ لوضع الذاكرة. مشكلة أثناء الإقلاع أو تسجيل الدخول تستخدم أثر إقلاع. في كلّ الحالات إجراء start / أعد الإنتاج / stop واحد
    q{"متى تحدث؟"}
    q -->|"في الحال"| file["وضع الملفّ: التقاط قصير"]
    q -->|"التوقيت مجهول"| mem["وضع الذاكرة: انتظر（3.1）"]
    q -->|"إقلاع أو تسجيل دخول"| boot["أثر إقلاع（الفصل 8）"]
    file --> s1["start ← أعد الإنتاج ← stop"]
    mem --> s1

الشكل 2: مشكلة يمكن إعادة إنتاجها في الحال تُلتقَط قصيرة وموثوقة في وضع الملفّ؛ مشكلة لا تعرف توقيتها تُنتظَر في مخزن الحلقة الافتراضيّ لوضع الذاكرة. مشكلة أثناء الإقلاع أو تسجيل الدخول تستخدم أثر إقلاع. في كلّ الحالات إجراء start / أعد الإنتاج / stop واحد.

3.1. وضع الذاكرة ووضع الملفّ ── هل تعيد الإنتاج، أم تنتظر

لـ WPR وضعان لوجهة التسجيل؛ الافتراضيّ وضع الذاكرة (مخزن دائريّ في الذاكرة). هو مخزن حلقيّ يكتب فوق الأحداث الأقدم، لذا يناسب ترك الالتقاط شغّالاً بينما تنتظر مشكلة لا تعرف توقيتها، والتوقّف عندما تحدث. إضافة -filemode تبدّل إلى وضع الملفّ، ويُسجَّل كلّ شيء في ملفّ مستمرّ. هذا لا يُكتَب فوقه؛ السقف الوحيد هو المساحة الحرّة على القرص، والملفّ ينمو بلا حدّ.¹⁰

flowchart TB
    accTitle: كيف يسجّل وضع الذاكرة ووضع الملفّ
    accDescr: وضع الذاكرة يسجّل في مخزن دائريّ في الذاكرة؛ تُكتَب الأحداث الأقدم فوقها ولا يبقى إلا الأحدث، لذا يناسب الانتظار. وضع الملفّ يحتفظ بكلّ شيء في ملفّ، لكنّ السقف الوحيد هو المساحة الحرّة على القرص، لذا يناسب إعادة إنتاج قصيرة موثوقة
    ev["أحداث ETW"] --> ring["وضع الذاكرة: مخزن حلقيّ"]
    ev --> filem["وضع الملفّ: أنمِ ملفّاً"]
    ring -.-> use1["انتظر توقيتاً مجهولاً"]
    filem -.-> use2["أعد إنتاجاً قصيراً موثوقاً"]

الشكل 3: وضع الذاكرة يسجّل في مخزن دائريّ في الذاكرة؛ تُكتَب الأحداث الأقدم فوقها ولا يبقى إلا الأحدث، لذا يناسب الانتظار. وضع الملفّ يحتفظ بكلّ شيء في ملفّ، لكنّ السقف الوحيد هو المساحة الحرّة على القرص، لذا يناسب إعادة إنتاج قصيرة موثوقة.

قاعدة عمليّة للاختيار كما يلي.

• قابلة لإعادة الإنتاج في الحال ← وضع الملفّ. ابدأ قبيل إعادة الإنتاج، توقّف بعدها مباشرةً، وأبقِ الالتقاط ضمن دقائق قليلة
• التوقيت مجهول ← انتظر في وضع الذاكرة (الافتراضيّ). فور حدوثها، wpr -stop
• حتّى دقائق قليلة من GeneralProfile يمكن أن تنتج ETL بمئات الميغابايت إلى فئة الغيغابايت. ملفّ أكبر ممّا ينبغي قد يصبح غير قابل للتحليل في WPA، لذا «كلّما أطلت الالتقاط كان أفضل» يأتي بنتيجة عكسيّة¹⁰¹¹

للالتقاط من الواجهة الرسوميّة، ابدأ WPRUI، اختر ملفّ تعريف ووضع تسجيل (Logging mode)، ثمّ Start/Save. الدليل الرسميّ How-to يلخّص الإجراء.¹¹ إن طلبت من جهة اتّصال في موقع العميل الالتقاط، الأوامر الثلاثة أعلاه يمكن أن تدخل في إجراء كما هي.

4. أساسيّات قراءة WPA ── الرسوم، القاعدة الذهبيّة للجداول، وتضييق الوقت

عندما تفتح ETL ملتقَطاً في WPA، يسرد Graph Explorer على اليسار مصغّرات الرسوم في فئات مثل System Activity وComputation وStorage وMemory.¹² اسحب رسماً تريد رؤيته إلى علامة تبويب Analysis على اليمين، فيظهر رسم أعلاه وجدول أدناه. أوّل ثلاثة أمور تستوعبها هي هذه.

1. القاعدة الذهبيّة للجداول ── ترتيب الأعمدة يقرّر التجميع. لجدول WPA شريطان عموديّان، ذهبيّ وأزرق، والأعمدة يسار الشريط الذهبيّ تهرِّم (تجمّع) البيانات بذلك الترتيب، والأعمدة يمين الشريط الأزرق مجاميع.¹³ رتّبها Process ← Stack فتحصل على تجميع مكدّس لكلّ عمليّة؛ Stack ← Process فتحصل على تجميع لكلّ عمليّة تستخدم المكدّس نفسه ── سحب الأعمدة لإعادة ترتيبها هو نفسه عمليّة تحليل. افهم هذه النقطة وكلّ جدول WPA يُقرأ بالطريقة نفسها.

flowchart TB
    accTitle: القاعدة الذهبيّة للجداول ── الشريطان ودور الأعمدة
    accDescr: الأعمدة يسار الشريط الذهبيّ تهرِّم البيانات بذلك الترتيب؛ الأعمدة بين الذهبيّ والأزرق أعمدة عرض؛ الأعمدة يمين الشريط الأزرق مجاميع. سحب الأعمدة لإعادة ترتيبها هو نفسه عمليّة تحليل
    left["يسار الذهبيّ: تجميع"] --> gold["الشريط الذهبيّ"]
    gold --> mid["بين الشريطين: عرض"]
    mid --> blue["الشريط الأزرق"]
    blue --> right["يمين الأزرق: مجاميع"]
    left -.-> op["اسحب الأعمدة للتحليل"]

الشكل 4: الأعمدة يسار الشريط الذهبيّ تهرِّم البيانات بذلك الترتيب؛ الأعمدة بين الذهبيّ والأزرق أعمدة عرض؛ الأعمدة يمين الشريط الأزرق مجاميع. سحب الأعمدة لإعادة ترتيبها هو نفسه عمليّة تحليل.

1. ضيِّق نطاق الوقت. اسحب على الرسم لتحديد نطاق، ثمّ انقر باليمين و«Zoom»، فيتبدّل التجميع إلى ذلك الفاصل فقط. تحقيق الأداء دائماً، من حيث المبدأ، ينظر فقط إلى «الفاصل الذي كانت المشكلة تحدث فيه» (الفصل 9).
2. اضبط الرموز. لقراءة مكدّس باسم الدالّة، نفِّذ Trace > Load Symbols من القائمة.¹⁴ افتراضيّاً يشير إلى خادم رموز مايكروسوفت العلنيّ (msdl.microsoft.com)، لذا يمكن حلّ مكدّسات Windows نفسها إن كان لديك اتّصال بالإنترنت. لرؤية أسماء الدوالّ في تطبيقك، أضف مجلّد ملفّات PDB لتطبيقك في Trace > Configure Symbol Paths.⁸ ما هو PDB، ولماذا ينبغي أن تبقيه دائماً حتّى لبناء Release، ملخّص في «ما هو PDB (قاعدة بيانات البرنامج)؟». لصور NGen الأصليّة في .NET Framework، يولِّد WPR ملفّات NGen PDB ‏(.ngenpdb) وقت الالتقاط ويضعها في مجلّد بجانب الأثر، ويشير إليها WPA تلقائيّاً.⁸ هذه آليّة لصور NGen فقط، وشيفرة تطبيق .NET العاديّة بـ JIT الخاصّة بك خارج النطاق. الربط من عنوان شيفرة JIT إلى اسم دالّة يُحلّ من أحداث JIT التي يصدرها CLR، لذا عندما تحقّق في تطبيق .NET، جهّز ملفّ تعريف تسجيل (.wprp) يفعّل مزوِّدي CLR ‏(Microsoft-Windows-DotNETRuntime وRundown المطابق) واجمعه بالطريقة نفسها لمزوِّديك في الفصل 3، wpr -start GeneralProfile -start MyDotNet.wprp!profile-name، حتّى تُدرَج أحداث CLR في الأثر (يمكنك التحقّق من ملفّات التعريف المضمّنة التي يقدّمها WPR المحلّيّ بـ wpr -profiles). فوق ذلك، احتفظ بملفّات PDB التي يولّدها البناء للربط إلى أسطر المصدر، وأضفها إلى مسار الرموز أعلاه.

flowchart TB
    accTitle: حلّ الرموز لقراءة مكدّس باسم الدالّة
    accDescr: تشغيل Trace Load Symbols يحلّ Windows نفسه من خادم رموز مايكروسوفت العلنيّ، وتطبيقك من ملفّات PDB البناء المضافة إلى مسار الرموز. صور NGen تستخدم ملفّات NGen PDB التي يولّدها WPR؛ شيفرة .NET بـ JIT تُحلّ من أحداث CLR JIT في الأثر زائد ملفّات PDB البناء
    load["Trace > Load Symbols"] --> ms["Windows: رموز علنيّة"]
    load --> own["تطبيقك: ملفّات PDB البناء"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: أحداث CLR + PDB"]

الشكل 5: تشغيل Trace Load Symbols يحلّ Windows نفسه من خادم رموز مايكروسوفت العلنيّ، وتطبيقك من ملفّات PDB البناء المضافة إلى مسار الرموز. صور NGen تستخدم ملفّات NGen PDB التي يولّدها WPR؛ شيفرة .NET بـ JIT تُحلّ من أحداث CLR JIT في الأثر زائد ملفّات PDB البناء.

بعد أن تستعدّ، تدخل من الفرع التالي. في ذلك الفاصل، أكان المعالج مرتفعاً، أم منخفضاً؟ إن كان مرتفعاً، الفصل 5 (Sampled)؛ إن كان منخفضاً وما زال بطيئاً، الفصل 6 (Precise).

flowchart TB
    accTitle: فرع اختيار رسم WPA من العَرَض
    accDescr: قرِّب إلى فاصل المشكلة؛ إن كان المعالج مرتفعاً اذهب إلى CPU Usage Sampled؛ إن كان منخفضاً وما زال بطيئاً، تحقّق من تثبيت نواة واحدة / خيط واحد ثمّ تحليل الانتظار في CPU Usage Precise؛ إن اشتُبِه بالقرص فـ Disk Usage وFile IO
    zoom["قرِّب إلى فاصل المشكلة"] --> cpu{"المعالج في ذلك الفاصل؟"}
    cpu -->|"مرتفع"| sampled["الفصل 5: Sampled"]
    cpu -->|"منخفض، ما زال بطيئاً"| core{"تثبيت نواة / خيط واحد؟"}
    core -->|"نعم"| sampled
    core -->|"لا"| precise["الفصل 6: Precise"]
    cpu -->|"اشتباه بالقرص"| disk["الفصل 7: القرص / دخل/خرج الملفّات"]

الشكل 6: قرِّب إلى فاصل المشكلة؛ إن كان المعالج مرتفعاً اذهب إلى CPU Usage Sampled؛ إن كان منخفضاً وما زال بطيئاً، تحقّق من تثبيت نواة واحدة / خيط واحد ثمّ تحليل الانتظار في CPU Usage Precise؛ إن اشتُبِه بالقرص فـ Disk Usage وFile IO.

5. عندما يكون المعالج مرتفعاً ── «من يحرق أيّ دالّة» بـ CPU Usage (Sampled)

إن كان المعالج مثبتاً، ما تنظر إليه هو CPU Usage (Sampled). هذه بيانات أخذ عيّنات سجّلت، نحو كلّ 1 مليّ ثانية على كلّ معالج، «مكدّس أيّ عمليّة يعمل الآن»، ونسبة أعداد العيّنات هي تفصيل زمن المعالج كما هي.⁶

flowchart TB
    accTitle: كيف يعمل CPU Usage Sampled
    accDescr: نحو كلّ 1 مليّ ثانية يُسجَّل المكدّس العامل على كلّ معالج، ونسبة العيّنات المجمَّعة هي تفصيل زمن المعالج. اقرأ من عمليّة إلى خيط ومكدّس ودالّة. نشاط قصير ينتهي بين العيّنات لا يظهر
    tick["مقاطعة نحو كلّ 1 مليّ ثانية"] --> snap["سجّل المكدّس العامل"]
    snap --> agg["نسبة العيّنات = تفصيل المعالج"]
    agg --> drill["عمليّة ← خيط ← مكدّس"]
    snap -.-> miss["النشاط بين العيّنات يُفوَّت"]

الشكل 7: نحو كلّ 1 مليّ ثانية يُسجَّل المكدّس العامل على كلّ معالج، ونسبة العيّنات المجمَّعة هي تفصيل زمن المعالج. اقرأ من عمليّة إلى خيط ومكدّس ودالّة. نشاط قصير ينتهي بين العيّنات لا يظهر.

1. من Computation في Graph Explorer، ضع CPU Usage (Sampled) على علامة تبويب Analysis واختر الإعداد المسبق Utilization by Process, Stack.⁵
2. انظر إلى العمليّات تنازليّاً حسب Weight (أو Count). هويّة ما كان «50%» في مدير المهام تتّضح أوّلاً على مستوى العمليّة.
3. وسِّع عمود Stack للعمليّة الجانية. تُجمَّع المكدّسات كشجرة، وتتبّع المسار الذي لا ينخفض فيه الرقم كثيراً عند فرع يهبط بك إلى الدالّة التي تحرق المعالج. إن حُلَّت الرموز، فهو خطّ مستقيم إلى أيّ دالّة في شيفرتك.
4. إن كان توسيع الشجرة مملاً، بدِّل عرض الرسم إلى Flame. يُرسَم بالعرض = حصّة زمن المعالج، لذا أيّ مسار استدعاء يهيمن واضح بنظرة. لـ CPU Usage (Sampled) أيضاً إعداد مسبق Flame by Process, Stack.¹³

ثمّة تحذير واحد. لأنّه أخذ عيّنات، نشاط قصير ينتهي بين العيّنات لا يظهر.⁶ تذكّره أداةً لرؤية «أين استُخدم المعالج إجمالاً»، لا أداةً لقياس المدّة الدقيقة لكلّ استدعاء.

6. عندما يكون المعالج منخفضاً وما زال بطيئاً ── CPU Usage (Precise) وتحليل الانتظار

هذا جوهر المقال. قبل أن تمضي إلى تحليل الانتظار، غير أنّ ثمّة أمراً تؤكّده. «استخدام المعالج الإجماليّ منخفض» لا يعني «المعالج ليس عنق الزجاجة». على حاسوب بـ 16 نواة، عمل تسلسليّ مثبت على نواة واحدة (خيط واجهة مستخدم يعمل بأقصى طاقة) يبدو نحو 6% فقط إجمالاً. تحقّق أوّلاً في Sampled بالفصل 5 (أو Utilization by CPU في CPU Usage (Precise)) أنّه لا تثبيت على نواة أو خيط معيّن، وإن لم يكن، تعال إلى هذا الفصل ── العمل ليس عاجزاً عن التشغيل، بل ينتظر. ما يخبرك بما ينتظره هو CPU Usage (Precise).

حيث Sampled أخذ عيّنات، Precise سجلّ كامل لتبديلات السياق (تبديلات الخيوط). يدخل خيط انتظاراً، يوقظه أحد (Ready)، ويهبط على معالج ── تلك الجولة ذهاباً وإياباً تبقى صفّاً صفّاً، ويمكنك قراءة الأعمدة التالية.⁷⁴

flowchart TB
    accTitle: جولة انتظار واحدة وكيف تتوافق الأعمدة
    accDescr: يدخل خيط انتظاراً على المكدّس الذي يبقى في NewThreadStack، وينتظر زمن Waits. عندما يوقظه أحد، يبقى ذلك الطرف في ReadyingProcess وReadyThreadStack؛ ينتظر زمن Ready لتنازع المعالج ثمّ يعمل مجدّداً
    run1["يعمل"] -->|"ادخل انتظاراً"| waitst["انتظار（Waits us）"]
    waitst -->|"أحد يوقظه"| ready["Ready（تنازع المعالج）"]
    ready -->|"يهبط على معالج"| run2["يعمل مجدّداً"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

الشكل 8: يدخل خيط انتظاراً على المكدّس الذي يبقى في NewThreadStack، وينتظر زمن Waits. عندما يوقظه أحد، يبقى ذلك الطرف في ReadyingProcess وReadyThreadStack؛ ينتظر زمن Ready لتنازع المعالج ثمّ يعمل مجدّداً.

نمط القراءة كما يلي.⁴

1. طبِّق الإعداد المسبق Utilization by Process, Thread وأضف NewThreadStack وReadyThreadStack إلى الأعمدة.
2. حدِّد أوّلاً الخيط الذي كان ينفّذ العمليّة المتأخّرة (خيط الواجهة، الخيط الذي يعالج الطلب المعنيّ). النظر فقط تنازليّاً حسب مجموع Waits مربك، لأنّ خيوطاً «تنتظر عمداً طوال الوقت»، كمضخّة رسائل أو مؤقِّت، تحتلّ القمّة. بعد أن تجد الخيط المستهدف، إن كان CPU Usage (ms) كبيراً فهي مشكلة معالج في الفصل 5؛ إن هيمنت Waits فهي مشكلة انتظار.
3. وسِّع NewThreadStack وانظر ماذا كان يفعل عندما توقّف. WaitForSingleObject أو EnterCriticalSection انتظار قفل؛ داخل دخل/خرج متزامن مثل ReadFile انتظار دخل/خرج؛ داخل استقبال مقبس انتظار ردّ النظير.
4. ثمّ انظر من أفرج الانتظار. وسِّع ReadyThreadStack وتحقّق من ReadyingProcess / ReadyingThreadId. إن أُيقظ من KiTimerExpiration في النواة فهو مؤقِّت (= نام حتّى مهلة)؛ إن أُيقظ من معالجة اكتمال دخل/خرج، فذلك يؤكّد أنّه انتظار دخل/خرج.⁴
5. إن كان الطرف الذي أيقظه خيطاً آخر أو عمليّة أخرى، حقِّق في ذلك الخيط بالإجراء نفسه. «أ كان ينتظر أن يفرج ب قفلاً، ب كان ينتظر ردّ RPC من ج، ج كان ينتظر دخل/خرج قرص» ── ما لديك عندما تتبّعت هذه السلسلة إلى الجذر هو المسار الحرج للتأخير.⁷

flowchart TB
    accTitle: سلسلة المسار الحرج التي تتتبّعها في تحليل الانتظار
    accDescr: انظر في NewThreadStack للخيط أ المتأخّر ماذا كان يفعل عندما توقّف، حدِّد الموقظ ب من ReadyThreadStack وReadyingProcess، وحقِّق في ب بالإجراء نفسه حتّى دخل/خرج القرص الجذريّ
    a["الخيط أ（عمل متأخّر）"] -->|"انتظار قفل"| b["الخيط ب（يمسك القفل）"]
    b -->|"انتظار RPC"| c["العمليّة ج"]
    c -->|"انتظار دخل/خرج متزامن"| d["دخل/خرج القرص（الجذر）"]
    d -.->|"الاكتمال يوقظ ج"| c
    c -.->|"الردّ يوقظ ب"| b
    b -.->|"إفراج القفل يوقظ أ"| a

الشكل 9: انظر في NewThreadStack للخيط أ المتأخّر ماذا كان يفعل عندما توقّف، حدِّد الموقظ ب من ReadyThreadStack وReadyingProcess، وحقِّق في ب بالإجراء نفسه حتّى دخل/خرج القرص الجذريّ.

في حالة مثل «جعلناه متعدّد الخيوط ولم يزد سرعة»، يُظهر هذا الإجراء كلّ عامل مصطفاً على قفل واحد كما هو. تجنّب تنازع الأقفال بالتصميم مشمول في «أفضل ممارسات تعدّد الخيوط عمليّاً: إصدار .NET»، وآليّة Windows التي تعمل على إشعار اكتمال بدل الانتظار في دخل/خرج متزامن مشمولة في «منافذ اكتمال الدخل/الخرج (IOCP) ومجمّع خيوط .NET». تثبيت «من كان ينتظره» في WPA وإصلاحه بتلك حجج التصميم تدفّق واحد مستمرّ.

7. القرص ودخل/خرج الملفّات ── تحديد «أحد يمسح القرص»

الجاني الكلاسيكيّ لـ «الحاسوب كلّه بطيء» ليس المعالج بل القرص. تحقّق بـ Disk Usage وFile I/O في فئة Storage.¹⁵

Disk Usage سجلّ دخل/خرج القرص، وعمودان مهمّان. Disk Service Time زمن قضاء جهاز القرص فعليّاً في معالجة ذلك الدخل/الخرج؛ IO Time الزمن من دخول الدخل/الخرج طابور نظام التشغيل حتّى اكتماله. IO Time دائماً على الأقلّ Service Time بمقدار الاصطفاف، لذا إن كان IO Time أطول بكثير من Service Time، فذلك الدخل/الخرج كان «ينتظر في الطابور».⁶ غير أنّ ذلك وحده لا يقرّر ما إذا كان الجاني الذي صنع الطابور عمليّة أخرى، أم فقط دخل/خرج ثقيل لتلك العمليّة نفسها مصطفاً على جهاز بطيء. لا تستخلص النتيجة هنا؛ احسمها بـ Service Time (استجابة الجهاز نفسه) والتفصيل التالي حسب العمليّة والمسار والمكدّس.

ثمّ، بالإعداد المسبق Utilization by Process, Path Name, Stack، انظر أيّ عمليّة أصدرت دخل/خرج إلى أيّ ملفّ من أيّ مكدّس، تنازليّاً حسب IO Time أو Size.¹⁵ الإجابات التي تأتي كثيراً في الميدان هاتان.

• مضادّ فيروسات كان يمسح كلّ ملفّ. في النافذة التي كان التطبيق بطيء البدء فيها، تُرى عمليّة مضادّ الفيروسات تُصدر حجماً كبيراً من القراءات. اسم العمليّة والمسار والحجم دليل كما هو لنقاش الاستثناءات.
• عمليّة أخرى كانت تكتب بكثافة. نسخ احتياطيّ، المفهرس، سجلّات كُتبت أكثر ممّا ينبغي، وما شابه. متى تصل كتابة إلى القرص يتورّط فيه مدير الذاكرة المؤقّتة، لذا حقيقة أنّ «لحظة كتابتك» و«لحظة انشغال القرص» يمكن أن تتباعدا مشمولة أيضاً في «مدير الذاكرة المؤقّتة ── متى يصل WriteFile فعليّاً إلى القرص؟».

File I/O طبقة أعلى، سجلّ عمليّات الملفّات التي أصدرها التطبيق (Create/Read/Write وما شابه)، وإعدادات مسبقة مثل Duration by Process, Thread, Type يمكنها تجميع الزمن لكلّ اسم ملفّ ولكلّ عمليّة.¹⁵ حالة تقضي وقتاً في نظام الملفّات أو تعريف مرشِّح قبل بلوغ القرص لا تظهر في Disk Usage، لذا عدم التطابق نفسه ── «Disk Usage هادئ لكنّ File I/O بطيء» ── دليل. إن أردت أن تبدأ من آليّة الدخل/الخرج المتزامن وغير المتزامن، انظر «الدخل/الخرج المتزامن وغير المتزامن ── ما الذي يعنيه OVERLAPPED حقّاً».

flowchart TB
    accTitle: الطبقات المختلفة التي يراها File IO وDisk Usage
    accDescr: عمليّة ملفّ التطبيق تسير عبر نظام الملفّات وتعريفات المرشِّح من طابور دخل/خرج نظام التشغيل إلى جهاز القرص. File IO يسجّل العمليّات في الطبقة العليا؛ Disk Usage يسجّل الدخل/الخرج الذي بلغ القرص؛ الفرق بين IO Time وDisk Service Time هو زمن الطابور
    app["التطبيق: ReadFile / WriteFile"] --> fio["نظام الملفّات والمرشِّحات（File I/O）"]
    fio --> queue["طابور دخل/خرج نظام التشغيل"]
    queue --> dev["جهاز القرص（Disk Usage）"]
    fio -.-> n1["يفوّته Disk Usage"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = الجهاز"]

الشكل 10: عمليّة ملفّ التطبيق تسير عبر نظام الملفّات وتعريفات المرشِّح من طابور دخل/خرج نظام التشغيل إلى جهاز القرص. File IO يسجّل العمليّات في الطبقة العليا؛ Disk Usage يسجّل الدخل/الخرج الذي بلغ القرص؛ الفرق بين IO Time وDisk Service Time هو زمن الطابور.

خطّ التفكير «ربّما ينقصه ذاكرة ويتبادل» يمكن إعطاؤه عزلاً أوّليّاً في مدير المهام وResource Monitor قبل أن تذهب إلى WPA. غير أنّك لا ترفضه من الذاكرة الملتزم بها وحدها ── حتّى مع فائض التزام، وضع يضغط فيه ضغط الذاكرة الفيزيائيّة مجموعة العمل وتستمرّ الأعطال الصلبة ممكن. تحقّق أيضاً من الذاكرة الفيزيائيّة المتاحة و«Hard Faults/sec» في Resource Monitor. كيفيّة قراءتها في «ماذا يعني «استخدام الذاكرة» في Windows فعليّاً؟».

8. إقلاع وتسجيل دخول بطيئان ── مدخل أثر الإقلاع

نوع «يستغرق 3 دقائق ليبدأ» ينتهي قبل أن تتمكّن من تشغيل wpr -start يدوياً. لدى WPR أثر إقلاع، ويمكنك الترتيب ليبدأ نظام التشغيل التسجيل تلقائيّاً في الإقلاع التالي.³

:: 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: تدفّق أثر الإقلاع
    accDescr: بعد أن ترتّب تسجيلاً تلقائيّاً في الإقلاع التالي بـ addboot وتعيد التشغيل، يبدأ نظام التشغيل التسجيل تلقائيّاً عند الإقلاع. الحفظ بـ stopboot بعد تسجيل الدخول يمسح الترتيب أيضاً. للتخلّي، امسحه بـ cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["أعد التشغيل（إقلاع بطيء）"]
    rebootpc --> auto["نظام التشغيل يسجّل عند الإقلاع"]
    auto --> stop2["بعد تسجيل الدخول: -stopboot"]
    add -.-> cancel["تخلَّ: -cancelboot"]

الشكل 11: بعد أن ترتّب تسجيلاً تلقائيّاً في الإقلاع التالي بـ addboot وتعيد التشغيل، يبدأ نظام التشغيل التسجيل تلقائيّاً عند الإقلاع. الحفظ بـ stopboot بعد تسجيل الدخول يمسح الترتيب أيضاً. للتخلّي، امسحه بـ cancelboot.

قياس الإقلاع والإغلاق الذي كان يملكه xbootmgr يمكن تشغيله أيضاً في WPR الحاليّ بخيارات مثل -onoffscenario Boot.³ أثر ملتقَط يُقرأ بأدوات الفصول السابقة نفسها. انظر أيّ عمليّة وُلدت متى على خطّ زمنيّ في رسم Processes، قرِّب إلى النافذة التي علق فيها الإقلاع، وصنِّف معالجاً أو انتظاراً أو قرصاً ── تطبيق بدء ينتظر شيئاً على التوالي، وبدء خدمة عالق على دخل/خرج معيّن، وما شابه تصبح مرئيّة. تحليل الإقلاع تخصّص عميق بحدّ ذاته، لذا يذهب هذا المقال فقط إلى المدخل: «مشكلة لا تستطيع التقاطها يدوياً ما زال يمكن التقاطها بـ WPR». ابدأ باستيعاب الصورة الكلّيّة بأثر إقلاع GeneralProfile.

9. نمط عمل ── صنِّف ← قرِّب ← مكدّس، كرِّر

الآن وقد اتّضحت الأدوات، إليك نمط التحقيق ككلّ.

1. ثبِّت زمن الظاهرة. ليس «كان بطيئاً»، بل «10:23:40–10:24:10 كان بطيئاً». سجلّات التطبيق، سجلّ الأحداث، ملاحظة ممّن شغّله ── أيّ شيء يكفي. إن كتب تطبيقك نقاط تحقّق إلى ETW أو سجلّ الأحداث، تصبح الأحداث داخل الأثر أوتاد وقت كما هي.
2. قرِّب إلى ذلك الفاصل فقط. تجميع الأثر كلّه يُوسَّط، والشذوذ المهمّ يُخفَّف. تحليل WPA دائماً مقارنة «الفاصل الذي كان شاذاً» مقابل «الفاصل الذي كان عاديّاً».
3. صنِّف «معالج، انتظار، أم دخل/خرج» أوّلاً. انظر إلى CPU Usage (Sampled)؛ إن كان يحترق، الفصل 5. إن لم يكن يحترق، Waits في CPU Usage (Precise) (الفصل 6). إن تضخّم Disk Usage IO Time، الفصل 7. أخذ هذا التفرع الثلاثيّ أوّلاً يمنعك من الضياع.
4. كرِّر فرضيّة ← تقريب ← مكدّس. إن ظننت «مضادّ فيروسات؟»، ضيِّق إلى تلك العمليّة وادعمها بالمكدّس. إن لم تصمد، الفرضيّة التالية. عدم استخلاص نتيجة قبل أن تتتبّع إلى المكدّس وتدعمها هو انضباط هذا النوع من التحقيق.

flowchart TB
    accTitle: حلقة التكرار في تحقيق الأداء
    accDescr: ثبِّت زمن الظاهرة، قرِّب إلى الفاصل، صنِّف معالجاً / انتظاراً / دخل/خرج، كوِّن فرضيّة وضيِّق، وادعمها بالمكدّس. إن صمدت، السبب مؤكَّد؛ إن لم تصمد، كرِّر بالفرضيّة التالية
    time["ثبِّت الزمن"] --> zoomstep["قرِّب إلى ذلك الفاصل"]
    zoomstep --> triage["صنِّف معالجاً / انتظاراً / دخل/خرج"]
    triage --> hypo["فرضيّة وتضييق"]
    hypo --> stack["ادعمها بالمكدّس"]
    stack -->|"تصمد"| fix["السبب مؤكَّد"]
    stack -->|"لا تصمد"| hypo

الشكل 12: ثبِّت زمن الظاهرة، قرِّب إلى الفاصل، صنِّف معالجاً / انتظاراً / دخل/خرج، كوِّن فرضيّة وضيِّق، وادعمها بالمكدّس. إن صمدت، السبب مؤكَّد؛ إن لم تصمد، كرِّر بالفرضيّة التالية.

أخيراً، معالجة ملفّ الالتقاط. ملفّ ETL يعكس داخل النظام على نطاق واسع: أسماء كلّ عمليّة، مسارات ملفّات فُتحت، وحدات حُمِّلت، و(حسب ملفّ التعريف) أسماء مفاتيح السجلّ. التقاط GeneralProfile قياسيّ لا يتضمّن أجسام بيانات كمحتويات الاتّصال، لكنّ إن فعّلت مزوِّداً مخصّصاً، حمولة ذلك الحدث (سلاسل سجّلها التطبيق، وما شابه) تدخل كما هي. بعد تأكيد ما يصدره المزوِّدون الذين فعّلتهم، عامله ملفّاً سرّيّاً بما يكفي ليخرج من الشركة. كما في التقاط الحزم، أدخل الحدّ الأدنى اللازم من الالتقاط، والاتّفاق مع الطرف الذي تسلّمه إليه، ومدّة احتفاظ وحذف في الإجراء.

flowchart TB
    accTitle: ما يعكسه ملفّ ETL، وكيف تعالجه
    accDescr: يعكس ETL كلّ اسم عمليّة، ومسارات ملفّات فُتحت، ووحدات، وحسب ملفّ التعريف أسماء مفاتيح السجلّ؛ تفعيل مزوِّد مخصّص يتضمّن أيضاً حمولته. عامله سرّيّاً: الحدّ الأدنى اللازم من الالتقاط، والاتّفاق مع الطرف الآخر، ومدّة احتفاظ وحذف
    etl["ملفّ ETL"] --> a1["أسماء، مسارات، وحدات"]
    a1 --> a2["مفاتيح السجلّ（بعضها）"]
    a2 --> a3["حمولة مخصّصة"]
    a3 -.-> rule["عامله سرّيّاً"]

الشكل 13: يعكس ETL كلّ اسم عمليّة، ومسارات ملفّات فُتحت، ووحدات، وحسب ملفّ التعريف أسماء مفاتيح السجلّ؛ تفعيل مزوِّد مخصّص يتضمّن أيضاً حمولته. عامله سرّيّاً: الحدّ الأدنى اللازم من الالتقاط، والاتّفاق مع الطرف الآخر، ومدّة احتفاظ وحذف.

10. الخلاصة

• «الحاسوب كلّه بطيء» الذي لا يستطيع مدير المهام تفسيره يُحقَّق بأثر ETW على مستوى نظام التشغيل ── التقاط بـ WPR، قراءة بـ WPA. يأتي wpr.exe مع Windows 8.1 وما بعده، لذا يصمد تقسيم الالتقاط في بيئة العميل، وأخذ ETL إلى المكتب، وقراءته في WPA على جهازك.
• الالتقاط ثلاث خطوات wpr -start GeneralProfile -filemode ← أعد الإنتاج ← wpr -stop trace.etl. إن استطعت إعادة الإنتاج، وضع الملفّ ضمن دقائق قليلة؛ إن انتظرت، وضع الذاكرة (مخزن حلقيّ). الأطول ليس أفضل.
• يمكن بدء WPA بعد أن تستوعب ثلاث نقاط: القاعدة الذهبيّة للجداول (يسار الشريط الذهبيّ = تجميع)، وتقريب نطاق الوقت، وضبط الرموز (تطبيقك يحتاج ملفّات PDB).
• إن كان المعالج مرتفعاً، تتبّع عمليّة ← مكدّس ← دالّة في CPU Usage (Sampled). إن كان المعالج منخفضاً وما زال بطيئاً، تتبّع السلسلة NewThreadStack (ماذا كان يفعل عندما توقّف) ← Waits (كم انتظر) ← ReadyingProcess وReadyThreadStack (من أيقظه) إلى الجذر في CPU Usage (Precise).
• للقرص، انظر «زمناً قُضي في الطابور» من الفرق بين Disk Usage IO Time وService Time، وحدِّد السبب (هل الجهاز نفسه بطيء، أم من صنع الطابور) من Service Time والتفصيل حسب العمليّة والمسار والمكدّس. الإقلاع البطيء يمكن التقاطه بـ wpr -boottrace.
• نمط العمل هو (1) ثبِّت الزمن (2) قرِّب إلى الفاصل (3) صنِّف معالجاً أو انتظاراً أو دخل/خرج (4) كرِّر فرضيّة ← تقريب ← مكدّس. عامل ETL سرّيّاً لأنّه يحتوي معلومات داخليّة.

شاشة WPA مرهبة، والجميع يضيع في الساعة الأولى. غير أنّه متى دخل العمودان الفقريّان ── «يسار الشريط الذهبيّ تجميع» و«Sampled أين احترق، Precise من انتظره» ── فالباقي العمليّة نفسها مكرَّرة. في المرّة التالية التي تأتي فيها استشارة أنّ «المعالج فيه فائض وما زال بطيئاً»، أغلق مدير المهام والتقط أثراً.

مقالات ذات صلة

• تحديد سبب «البطء» باستخدام PerfView وdotnet-trace ── مدخل عمليّ لتحقيق أداء .NET
• دليل عملي لأداة Process Monitor (ProcMon) — تحديد سبب «عدم قراءة الإعدادات» و«ACCESS DENIED» خلال 10 دقائق
• مدخل إلى سجلّ أحداث Windows وETW ── وضع سجلّات تطبيق الأعمال على آليّة نظام التشغيل القياسيّة
• ماذا يعني «استخدام الذاكرة» في Windows فعليّاً؟ ── قراءة مجموعة العمل وPrivate Bytes والالتزام وملفّ الصفحات قراءة صحيحة
• ما الذي يغيّره فعلاً «Processor scheduling» على Windows بالنسبة إلى الخدمات في الخلفيّة وأطوال الـ quantum و P-cores / E-cores
• PDB (قاعدة بيانات البرنامج) ما هي؟ ── فهم معلومات التصحيح والرموز (symbols) وSource Link

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تحقيق مشكلات أداء المنظومة من قبيل «الحاسوب كلّه صار بطيئاً ولا أدري لماذا»، و«المعالج فيه فائض والتطبيق ما زال بطيئاً»، و«بيئة معيّنة فقط بطيئة جدّاً في البدء». نعالج كارتباط واحد مستمرّ تصميم الالتقاط بـ WPR/WPA (في أيّ بيئة، أيّ ملفّ تعريف، كم نلتقط)، وتحليل الأثر، والإصلاح الناتج في جانب التطبيق وجانب الإعدادات.

• تطوير تطبيقات Windows
• التحقيق في الأخطاء وتحليل الأسباب الجذريّة
• الاستشارة التقنيّة ومراجعة التصميم
• تواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

من أين أحصل على WPR وWPA؟ هل يمكن استخدامهما في بيئة عميل لا أستطيع تثبيت برمجيّات فيها؟

أداة الالتقاط wpr.exe (الإصدار سطر الأوامر) تأتي مع Windows 8.1 وما بعده، لذا يمكنك استخدامها بلا تثبيت إضافيّ. الإصدار الرسوميّ WPRUI وأداة التحليل WPA (Windows Performance Analyzer) مضمّنان في Windows ADK (Windows Assessment and Deployment Kit) ويتطلّبان تثبيتاً منفصلاً. عمليّاً، إن قسّمت العمل إلى «في بيئة العميل التقط ملف ETL بـ wpr.exe القياسيّ في نظام التشغيل فقط، خذه إلى مكتبك، وحلّله في WPA على جهازك»، يمكنك تحقيق أداء المنظومة حتّى في موقع لا تستطيع إضافة برمجيّات إليه.

لماذا يكون بطيئاً بينما مدير المهام يُظهر فائضاً في المعالج؟ ماذا أرى في WPA؟

عندما يكون استخدام المعالج منخفضاً وما زال بطيئاً، فالعمل ليس عاجزاً عن استخدام المعالج ── بل متوقّفاً «بانتظار شيء ما». تنازع الأقفال، وانتظار اكتمال دخل/خرج متزامن، وانتظار ردّ عمليّة أخرى، أمثلة نمطيّة. مدير المهام يعرض النتيجة فقط، أي الاستخدام؛ أمّا CPU Usage (Precise) في WPA فيُظهر، من سجلّ لكلّ تبديل سياق، أين بدأ الخيط الانتظار (NewThreadStack)، وكم انتظر (Waits)، ومن أيقظه (ReadyingProcess، ReadyThreadStack). بتتبّع الطرف الذي جعله ينتظر، يمكنك تحديد «الجاني وراء البطء» حتّى مستوى الدالّة.

كم يجب أن أطيل التقاط الأثر؟ ألن يصبح الملفّ ضخماً؟

إن استطعت إعادة إنتاج المشكلة، فالأساس أن تبدأ قبيل إعادة الإنتاج مباشرةً، وتتوقّف بعدها مباشرةً، وتُبقي الالتقاط ضمن دقائق قليلة. الوضع الافتراضيّ لـ WPR هو وضع الذاكرة (Memory mode)، الذي يسجّل في مخزن دائريّ في الذاكرة؛ تُكتَب الأحداث الأقدم فوقها، لذا يناسب انتظار مشكلة لا تعرف توقيتها. وضع الملفّ (File mode) بـ -filemode يحتفظ بكلّ شيء في ملفّ مستمرّ، لكنّ السقف الوحيد هو المساحة الحرّة على القرص، وملفّ أكبر ممّا ينبغي قد يصبح غير قابل للتحليل في WPA. استخدم وضع الذاكرة لانتظار طويل، ووضع الملفّ لإعادة إنتاج قصيرة موثوقة.

كيف أختار بين PerfView وWPA؟

كلتا الأداتين تتعاملان مع آثار ETW، لكنّ نقاط قوّتهما تختلف. PerfView يفهم وقت تشغيل .NET بعمق ويتفوّق في تحقيق يخصّ التطبيقات المُدارة كـ GC والتخصيص وJIT. WPA يناسب قراءة المعالج والقرص ودخل/خرج الملفّات والطاقة وما شابه على مستوى نظام التشغيل عبر رسوم وجداول، وهو الخيار الأوّل عندما «ليس تطبيقاً معيّناً بل الحاسوب كلّه بطيء»، أو «عدّة عمليّات متورّطة»، أو «يُشتبَه بشيء خارج التطبيق (مضادّ فيروسات، تعريف، عمليّة أخرى)». قاعدة عمليّة: PerfView لبطء تطبيق .NET الخاصّ بك وحده، وWPR/WPA لبطء المنظومة كلّها.

هل يصحّ تشغيل WPR في بيئة إنتاج لدى العميل؟

التقاط قصير شائع في الممارسة، لكنّه ليس آمناً بلا قيد. ETW خفيف، لكنّ تسجيل حجم كبير من الأحداث مع المكدّسات يستهلك قدراً من المعالج والذاكرة. أدخل اعتبارات مثل البدء قبيل خطوة إعادة الإنتاج والتوقّف بعدها مباشرةً، وإبقاء الالتقاط ضمن دقائق قليلة، وتشغيله في وقت قليل الأثر على العمل، في مسار الموافقة نفسه لأيّ تغيير عاديّ. كذلك يحتوي ملفّ ETL معلومات داخليّة عن النظام كأسماء العمليّات ومسارات الملفّات ومعلومات التنفيذيّات، لذا قرّر مسبقاً كيف سيُعالَج إن خرج من الشركة (تقليل، مدّة احتفاظ، حذف).

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.