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

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

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

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

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

كيف يختلف هذا عن Process Monitor، الذي يفحص وصول الملفّات والسجلّ، وPerfView، الذي يتتبّع معالج تطبيق .NET وGC، مشروح في الفصل 2.

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

التدفّق الأساسيّ «التقط بـ WPR ← ضيِّق إلى فترة المشكلة في WPA ← اعزل المعالج أو الانتظار أو الإدخال/الإخراج». حتّى مشكلة لا تستطيع عمليّة واحدة تفسيرها يمكن تحقيقها بتتبّع كلّ عمليّة والنواة على الخطّ الزمنيّ نفسه.¹²

افصل أين تلتقط عن أين تقرأ

أداة الالتقاط wpr.exe تأتي مع Windows 8.1 وما بعده، لذا لا حاجة لتثبيت إضافيّ. الإصدار الرسوميّ WPRUI وأداة التحليل WPA مضمّنان في Windows ADK. لأنّك تستطيع تقسيم العمل إلى «التقط فقط بـ wpr.exe في بيئة العميل؛ اقرأه في WPA على جهازك»، يمكنك الالتقاط حتّى على خادم لا تستطيع إضافة برمجيّات إليه.¹²

لمشكلة تستطيع إعادة إنتاجها، الخطوات الثلاث الأساسيّة، بصلاحيّات مسؤول، wpr -start GeneralProfile -filemode ← أعد إنتاج المشكلة ← wpr -stop C:\temp\trace.etl.³ جهِّز مجلّد الوجهة، واحصل على موافقة الالتقاط، وقرِّر كيف سيُعالَج ETL قبل أن تشغِّله. انتظار مشكلة ومشكلات أثناء الإقلاع تستدعي طرائق التقاط مختلفة، لذا انظر الفصل 3 والفصل 8.

أوّل رسم تفتحه في WPA

ضيِّق أوّلاً إلى فترة المشكلة، ثمّ اختر اتّجاه التحقيق من الجدول التالي.⁴⁵

يُظهر Sampled تفصيل زمن المعالج من عيّنات تُؤخَذ نحو كلّ مليّ ثانية.⁶ يتتبّع Precise الانتظارات من سجلّ كامل لتبديلات السياق. تتبّع الطرف الذي حرَّر انتظاراً، باستخدام Waits ← ReadyingProcess ← ReadyThreadStack أدلّة، هي التقنيّة التي يريد هذا المقال إيصالها أكثر من غيرها.⁴⁷

كيف تقرأ هذا المقال حسب الهدف

إن كنت مسؤولاً عن الالتقاط، ابدأ بـ الفصل 2 والفصل 3؛ إن كنت تقرأ ETL التُقط أصلاً، ابدأ بـ الفصل 4. قراءة المكدّسات بأسماء الدوالّ تتطلّب ضبط الرموز، ولتطبيقك تضيف مسار ملفّات PDB الخاصّة به.⁸ عندما تحقّق شيفرة JIT في .NET، أحداث CLR وقت الالتقاط مطلوبة أيضاً، لذا افحص ملاحظات .NET في الفصل 4 قبل الالتقاط.

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 16، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

WPR يلتقط، WPA يحلِّل

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

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

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

الاختيار بين Procmon وPerfView وWPR/WPA

لنرتّب أيضاً أوّلاً كيف يختلف هذا عن أدوات مشابهة.

إن كان Procmon سجلّ تشغيل «ماذا فعل» وPerfView «ماذا حدث داخل .NET»، فإنّ WPA الأداة التي تدقّق «أين ذهب الوقت» عبر كلّ عمليّة.

عندما تريد تسجيل أحداث تطبيقك أيضاً

كيف يعمل ETW نفسه وكيف تضيف أحداث ETW إلى تطبيقك مشروحان في «مدخل إلى سجلّ أحداث Windows وETW». إن أصدر تطبيقك أحداث ETW، تُسجَّل معالمه في الأثر نفسه، ممّا يجعل الربط أسهل بكثير.

لاحظ مع ذلك أنّ WPR يسجّل فقط أحداث الموفّرين الذين يفعّلهم ملفّ التسجيل الذي اخترته. GeneralProfile لا يتضمّن موفّرك. لتسجيلها معاً، جهِّز ملفّ تسجيل مخصَّصاً (.wprp) يفعِّل موفّرك واجمعه كـ wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile، محدِّداً اسم ملفّ التعريف داخل ملفّ .wprp بعد !³.

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

ما تقرِّره قبل التشغيل

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

إن استطعت إعادة إنتاج المشكلة، ابدأ قبيلها مباشرةً، توقّف بعدها مباشرةً، وأبقها ضمن دقائق قليلة. جهِّز مجلّد الوجهة، وقرِّر مسبقاً من يستلم ETL، وكم يُحتفَظ به، وكيف يُحذَف. تحذيرات محتوياته في الفصل 9.

التالي مثال التقاط مشكلة تستطيع إعادة إنتاجها في المكان في وضع File. لمشكلة لا يُعرَف توقيتها، اذهب إلى وضع Memory في القسم 3.1؛ لمشكلات أثناء الإقلاع أو تسجيل الدخول، اذهب إلى الفصل 8.

الالتقاط العاديّ «start ← أعد الإنتاج ← stop»

شغِّل هذه في موجه أوامر مفتوح كمسؤول. -profiles يسرد ملفّات التعريف المتاحة مسبقاً، و-status يفحص الحالة أثناء الالتقاط. الـ -cancel في النهاية يُستخدَم فقط للإجهاض في المنتصف والإهمال؛ ليس جزءاً من إجراء الحفظ العاديّ.

:: قائمة ملفّات التعريف المدمجة المتاحة
wpr -profiles

:: 1. ابدأ الالتقاط (ملفّ تعريف عام، وضع ملف)
wpr -start GeneralProfile -filemode

:: 2. أعد إنتاج المشكلة (افحص حالة الالتقاط بـ wpr -status)

:: 3. أوقف واحفظ (يمكنك إرفاق وصف للمشكلة).
::    أنشئ مجلّد الوجهة مسبقاً (بدونه يفشل -stop في الحفظ)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "إعادة إنتاج ظاهرة بطء الحاسوب بالكامل أثناء بدء التطبيق X"

:: للإجهاض في المنتصف، أهمل دون حفظ
wpr -cancel

اختر ما تسجّله بملفّ تعريف

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

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

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

3.1. وضع Memory ووضع File ── هل تستطيع إعادة الإنتاج، أم تنتظر؟

لدى WPR وضعان لوجهة التسجيل، والافتراضيّ وضع Memory (مخزن دائريّ في الذاكرة).

وضع Memory لانتظار حدوث مشكلة. لأنّه مخزن حلقيّ يكتب فوق الأحداث الأقدم أوّلاً، يناسب ترك الالتقاط يعمل وأنت تنتظر مشكلة لا يُعرَف توقيتها، والتوقّف متى حدثت.

وضع File لمشكلات تستطيع إعادة إنتاجها بموثوقيّة في وقت قصير. إضافة -filemode تبدّل إلى وضع File، ويُسجَّل كلّ شيء في ملفّ مستمرّ. لا شيء يُفقَد بالكتابة فوقه، لكن في المقابل السقف الوحيد المساحة الحرّة على القرص، وينمو الملفّ بلا حدّ.¹⁰

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

قاعدة الإبهام للاختيار كما يلي.

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

الالتقاط من الواجهة الرسوميّة

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

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

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

الأشياء الثلاثة لإتقانها هي ترتيب الأعمدة، وتضييق النطاق الزمنيّ، وضبط الرموز. بدل إعادة تعلّم العمليّات لكلّ رسم، ابدأ من طريقة القراءة المشتركة هذه.

4.1. ترتيب الأعمدة يقرِّر كيف تُجمَّع البيانات

لجدول WPA شريطان عموديّان، ذهبيّ وأزرق: الأعمدة يسار الشريط الذهبيّ تُهرِّم (تجمِّع) البيانات بذلك الترتيب، والأعمدة يمين الشريط الأزرق مجاميع.¹³

ترتيبها «Process ← Stack» يعطي تجميع مكدّس لكلّ عمليّة؛ «Stack ← Process» يعطي تجميعاً عبر كلّ عمليّة تستخدم المكدّس نفسه. سحب الأعمدة لإعادة ترتيبها هو نفسه عمليّة التحليل. متى فهمت هذه النقطة الواحدة، يُقرأ كلّ جدول WPA بالطريقة نفسها.

flowchart LR
    accTitle: القاعدة الذهبيّة للجداول ── الشريطان وأدوار الأعمدة
    accDescr: ترتيب الأعمدة يسار الشريط الذهبيّ يُهرِّم البيانات، والأعمدة بين الشريطين أعمدة عرض، والأعمدة يمين الشريط الأزرق مجاميع. سحب الأعمدة لإعادة ترتيبها هو نفسه عمليّة التحليل
    left["يسار الشريط الذهبيّ: أعمدة التجميع (الترتيب = التسلسل الهرميّ)"] --> gold["الشريط الذهبيّ"]
    gold --> mid["بين الشريطين: أعمدة العرض"]
    mid --> blue["الشريط الأزرق"]
    blue --> right["يمين الشريط الأزرق: مجاميع (Sum و% وما شابه)"]
    left -.-> op["سحب عمود = عمليّة تحليل (Process ← Stack يعطي تجميع مكدّس لكلّ عمليّة)"]

4.2. ضيِّق إلى الفترة التي حدثت فيها المشكلة

اسحب على الرسم لتحديد نطاق، ثمّ انقر بالزرّ الأيمن واختر «Zoom»، فيتبدّل التجميع إلى تلك الفترة فقط. مبدأ تحقيق الأداء النظر دائماً فقط إلى «الفترة التي كانت المشكلة تحدث فيها» (الفصل 9).

4.3. حمِّل الرموز واعرض المكدّسات بأسماء الدوالّ

لقراءة المكدّسات بأسماء الدوالّ، شغِّل Trace > Load Symbols من القائمة.¹⁴ افتراضيّاً يشير إلى خادم رموز مايكروسوفت العلنيّ (msdl.microsoft.com)، لذا تُحلَّ مكدّسات Windows نفسه ما دمت متّصلاً بالإنترنت.

لرؤية أسماء الدوالّ في تطبيقك أيضاً، أضف المجلّد الذي يحوي ملفّات PDB لتطبيقك في Trace > Configure Symbol Paths.⁸ ما هو PDB، ولماذا ينبغي أن تحتفظ دائماً بواحد حتّى لبناءات الإصدار، ملخَّص في «PDB (قاعدة بيانات البرنامج) ما هي؟».

لـ .NET، عامل صور NGen وشيفرة JIT منفصلين

لـ صور NGen الأصليّة في .NET Framework، يولِّد WPR ملفّات NGen PDB (.ngenpdb) وقت الالتقاط، ويضعها في مجلّد بجانب الأثر، ويشير إليها WPA تلقائيّاً.⁸ هذه الآليّة خاصّة بصور NGen؛ شيفرتك في تطبيق .NET عاديّ يعمل تحت JIT ليست مشمولة.

تعيين عناوين شيفرة JIT إلى أسماء الدوالّ يُحلّ من أحداث JIT التي يصدرها CLR. لذا عندما تحقّق تطبيقاً .NET، جهِّز ملفّ تسجيل (.wprp) يفعِّل موفّري CLR (Microsoft-Windows-DotNETRuntime ونظيره Rundown)، واجمعه بالشكل wpr -start GeneralProfile -start MyDotNet.wprp!ProfileName، تماماً كما مع موفّرك في الفصل 2، كي تُدرَج أحداث CLR في الأثر (يمكنك فحص أيّ ملفّات تعريف مضمَّنة يعرضها WPR المحلّيّ بـ wpr -profiles).

فوق ذلك، احتفظ بملفّات PDB التي يولّدها البناء لتعيين أسطر المصدر، وأضفها إلى مسار الرموز الموصوف أعلاه.

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

4.4. قرِّر ما إذا تحقّق المعالج أو الانتظار أو الإدخال/الإخراج

متى انتهيت من الإعداد، انظر إلى ما إذا كان المعالج مرتفعاً أو منخفضاً أثناء فترة المشكلة. إن كان مرتفعاً، اذهب إلى Sampled في الفصل 5. إن كان منخفضاً، افحص أوّلاً ما إذا كانت نواة معيّنة أو خيط معيّن مثبتاً؛ إن لم يكن، تتبّع الانتظارات بـ Precise في الفصل 6. إن اشتُبِه بالقرص، اذهب إلى الفصل 7.

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

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

ما يبحث عنه هذا الفصل هو مسار الاستدعاء الذي يستخدم حصّة كبيرة من زمن المعالج.

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

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

انزل من العمليّة إلى المكدّس إلى الدالّة

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.¹³

Sampled لا يستطيع قياس المدّة الدقيقة لتشغيل واحد

لأنّه عيّنات، النشاط القصير الذي ينتهي بين العيّنات لا يُلتقَط.⁶ تذكّر أنّه أداة لرؤية «أين استُخدم المعالج إجمالاً»، لا أداة لقياس زمن التنفيذ الدقيق لكلّ تشغيل فرديّ.

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

6.1. قبل تحليل الانتظار، افحص نواة واحدة مثبتة

«استخدام المعالج الكلّيّ منخفض» لا يعني «المعالج ليس عنق الزجاجة». على حاسوب بـ 16 نواة، عمل تسلسليّ مثبت على نواة واحدة (خيط واجهة واحد يعمل بأقصى سرعة) يظهر كنحو 6% فقط إجمالاً.

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

6.2. افصل «الزمن المقضي في الانتظار» عن «انتظار معالج بعد الاستيقاظ»

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

flowchart LR
    accTitle: ذهاب وإياب انتظار واحد والأعمدة المقابلة
    accDescr: يدخل خيط انتظاراً على المكدّس المحفوظ في NewThreadStack وينتظر زمن Waits. عندما يوقظه أحد، يُحفَظ ذلك الطرف في ReadyingProcess وReadyThreadStack، وينتظر الخيط زمن Ready لتنازع المعالج قبل أن يعمل مرّة أخرى
    run1["يعمل"] -->|"يدخل انتظاراً (محفوظ في NewThreadStack)"| waitst["ينتظر (Waits (us))"]
    waitst -->|"يوقظه أحد (ReadyingProcess / ReadyThreadStack)"| ready["Ready (ينتظر تنازع المعالج)"]
    ready -->|"يحصل على معالج"| run2["يعمل مرّة أخرى"]

6.3. من الخيط المتأخّر، تتبّع كلّ موقظ بالدور

ترتيب القراءة كما يلي.⁴

1. أعد الرسم والأعمدة

طبِّق الإعداد المسبق Utilization by Process, Thread وأضف NewThreadStack وReadyThreadStack إلى الأعمدة.

2. اختر خيط العمليّة المتأخّرة

حدِّد أوّلاً الخيط الذي كان ينفِّذ العمليّة المتأخّرة، كخيط الواجهة أو الخيط الذي يعالج الطلب المعنيّ. إن نظرت فقط بترتيب إجماليّ Waits تنازليّ، تخرج في المقدّمة خيوط سليمة تنتظر عن قصد، كمضخّة رسائل أو مؤقّت.

إن كان CPU Usage (ms) للخيط المستهدَف كبيراً، فهي مشكلة معالج من الفصل 5؛ إن هيمن Waits، فهي مشكلة انتظار.

3. انظر «ماذا كان يفعل عندما توقّف» في NewThreadStack

وسِّع NewThreadStack. WaitForSingleObject أو EnterCriticalSection يعني انتظار قفل؛ داخل إدخال/إخراج متزامن مثل ReadFile، انتظار إدخال/إخراج؛ داخل استقبال مقبس، انتظار ردّ الطرف.

4. انظر «من حرَّر الانتظار» في ReadyThreadStack

وسِّع ReadyThreadStack وافحص ReadyingProcess / ReadyingThreadId. إن أُوقِظ من KiTimerExpiration في النواة، كان مؤقّتاً (نام حتّى المهلة)؛ إن أُوقِظ من معالجة اكتمال إدخال/إخراج، يؤكّد ذلك أنّه انتظار إدخال/إخراج.⁴

5. كرِّر التحقيق نفسه على الموقظ

إن كان الموقظ خيطاً آخر أو عمليّة أخرى، حقِّق ذلك الخيط تالياً بالإجراء نفسه.

مثلاً، سلسلة مثل A كان ينتظر أن يحرِّر B قفلاً، وB كان ينتظر ردّ RPC من C، وC كان ينتظر إدخال/إخراج قرص. تتبّع هذه السلسلة إلى جذرها يعطيك المسار الحرج للتأخير.⁷

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

حوِّل سبب الانتظار إلى مراجعة تصميم

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

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

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

7.1. افصل «معالجة الجهاز» عن «الاصطفاف» في Disk Usage

Disk Usage سجلّ دخل/خرج القرص. ابدأ بتمييز العمودين التاليين.⁶

IO Time دائماً على الأقلّ Service Time، والفرق الزمن المقضي في الطابور. إن كان IO Time أطول بكثير من Service Time، فإنّ ذلك الإدخال/الإخراج كان ينتظر في الطابور.⁶

غير أنّك لا تستنتج السبب من فرق الزمن وحده. ما إذا بنت عمليّة أخرى الطابور، أو اصطفّ إدخال/إخراج التطبيق نفسه الثقيل على جهاز بطيء، لم يُقرَّر بعد. انظر إلى استجابة الجهاز نفسه في Service Time، ثمّ احسمه بتفصيل العمليّة والمسار والمكدّس.

7.2. أيّ عمليّة أصدرت إدخالاً/إخراجاً إلى أيّ ملفّ

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

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

7.3. انظر البطء قبل القرص بـ File I/O

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 − Disk Service Time = الزمن في الطابور"]
    dev -.-> n3["Disk Service Time = زمن معالجة الجهاز"]

7.4. عندما تشتبه في نقص ذاكرة، افحص الذاكرة الفيزيائيّة أيضاً

خطّ الاستدلال «ربّما ينقصه ذاكرة ويتبادل» يمكن إعطاؤه فرز أوّل في مدير المهام وResource Monitor قبل الانتقال إلى WPA.

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

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

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

أعد التسجيل للإقلاع التالي، ثمّ احفظ بعد إعادة التشغيل

كما في الفصل 3، قرِّر موافقة الالتقاط ومعالجة ETL، ثمّ اعمل من موجه أوامر مفتوح كمسؤول.

:: 1. أعدّ التسجيل التلقائي في الإقلاع التالي
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. أعد التشغيل (أعد إنتاج الإقلاع البطيء)

:: 3. بعد الإقلاع، أوقف التسجيل واحفظ (يُمسَح الإعداد أيضاً)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "ظاهرة يستغرق فيها الإقلاع 3 دقائق"

flowchart LR
    accTitle: تدفّق أثر الإقلاع
    accDescr: أعد تسجيلاً تلقائيّاً في الإقلاع التالي بـ addboot، ثمّ أعد التشغيل؛ يبدأ نظام التشغيل التسجيل تلقائيّاً عند الإقلاع. الحفظ بـ stopboot بعد تسجيل الدخول يمسح الإعداد أيضاً. للتخلي عنه، امسحه بـ cancelboot
    add["أعد بـ wpr -boottrace -addboot"] --> rebootpc["أعد التشغيل (أعد إنتاج الإقلاع البطيء)"]
    rebootpc --> auto["يبدأ نظام التشغيل التسجيل تلقائيّاً عند الإقلاع"]
    auto --> stop2["احفظ بـ -stopboot بعد تسجيل الدخول (يمسح الإعداد أيضاً)"]
    add -.-> cancel["للتخلي، -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). إن تضخّم IO Time في Disk Usage، اذهب إلى الفصل 7. المرور بهذا الفرع الثلاثيّ أوّلاً يبقيك من الضياع.
4. كرِّر فرضيّة ← تقريب ← مكدّس. إن ظننت «مضادّ فيروسات؟»، ضيِّق إلى تلك العمليّة وأكِّدها بالمكدّس. إن لم تصمد، انتقل إلى الفرضيّة التالية. عدم استخلاص استنتاج قبل أن تنزل إلى المكدّس وتؤكّده هو انضباط هذا النوع من التحقيق.

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

قرِّر كيف تعالج ETL قبل الالتقاط

ملفّ ETL يلتقط رؤية واسعة لداخل النظام: أسماء كلّ عمليّة، ومسارات الملفّات التي فُتحت، والوحدات التي حُمِّلت، و(بحسب ملفّ التعريف) أسماء مفاتيح السجلّ.

التقاط GeneralProfile قياسيّ لا يتضمّن أجسام بيانات كمحتويات الاتّصال، لكنّ إن فعَّلت موفّراً مخصَّصاً، تدخل حمولة أحداثه (كسلاسل سجّلها التطبيق) كما هي.

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

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

10. الخلاصة

يمكن تنظيم تحقيق WPR/WPA في المراحل الثلاث التالية.

1. التقط الفترة التي تحتاجها. التقط بـ wpr.exe، الذي يأتي مع Windows 8.1 وما بعده، واقرأ ETL في WPA على جهازك. الأساسيّات wpr -start GeneralProfile -filemode ← أعد الإنتاج ← wpr -stop trace.etl. إن استطعت إعادة الإنتاج، وضع File ضمن دقائق قليلة؛ إن انتظرت، وضع Memory. لبطء أثناء الإقلاع، استخدم wpr -boottrace. الأطول ليس أفضل، والمعلومات الداخليّة في ETL تُعامَل كسرّيّة.
2. ضيِّق النطاق الزمنيّ واختر اتّجاه التحقيق. في WPA، يسار الشريط الذهبيّ تجميع ويمين الشريط الأزرق مجاميع. أتقن ترتيب الأعمدة والتقريب إلى الفترة وضبط الرموز، ثمّ اعزل المعالج أو الانتظار أو الإدخال/الإخراج. وفِّر ملفّات PDB لتطبيقك، ولشيفرة JIT في .NET افحص أحداث CLR وقت الالتقاط أيضاً.
3. تتبّع نزولاً إلى المكدّس وتحقّق من الفرضيّة. إن كان المعالج مرتفعاً، انزل من العمليّة إلى الدالّة في Sampled. حتّى إن كان المعالج الكلّيّ منخفضاً، افحص أوّلاً نواة أو خيطاً واحداً مثبتاً، وإن لم يكن ثمّة، تتبّع الانتظارات في Precise. للقرص، لا تقرِّر السبب من فرق الزمن وحده؛ انظر إلى استجابة الجهاز وتفصيل من أصدر الإدخال/الإخراج.

ما تتتبّعه في تحليل الانتظار هو NewThreadStack (ماذا كان يفعل عندما توقّف) ← Waits (كم انتظر) ← ReadyingProcess وReadyThreadStack (من أيقظه). حقِّق الموقظ بالطريقة نفسها، وتستطيع تتبّع سلسلة التأخيرات إلى جذرها.

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

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

• تحديد سبب «البطء» بـ PerfView وdotnet-trace ── مدخل عملي لتحقيق أداء .NET
• دليل عملي لـ Process Monitor (ProcMon) ── تحديد «الإعدادات لا تُقرأ» وACCESS DENIED خلال 10 دقائق
• مدخل إلى سجلّ أحداث Windows وETW ── وضع سجلّات تطبيق الأعمال على آليّة نظام التشغيل القياسيّة
• ماذا تعني «استخدام الذاكرة» في Windows فعليّاً ── قراءة Working Set وPrivate Bytes وCommit وملفّ الصفحات قراءة صحيحة
• إعداد Processor scheduling في Windows: خدمات الخلفية وأنوية P/E
• 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، الذي يسجّل في مخزن دائريّ في الذاكرة؛ تُكتَب الأحداث الأقدم فوقها أوّلاً، لذا يناسب انتظار مشكلة لا يُعرَف توقيتها. وضع File، المفعَّل بـ -filemode، يحتفظ بكلّ شيء في ملفّ مستمرّ، لكنّ سقفه الوحيد المساحة الحرّة على القرص، وملفّ أكبر ممّا ينبغي قد يصبح غير قابل للتحليل في WPA. استخدم وضع Memory لانتظار طويل، ووضع File لإعادة إنتاج قصيرة موثوقة.

متى أستخدم PerfView ومتى WPA؟

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

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

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

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

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

غو كومورا

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

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