لطالما تم إلقاء اللوم على Windows بسبب بطء عمليات الملفات وإنشاء العمليات. هل حاولت أن تجعلهم أبطأ؟ ستعرض هذه المقالة تقنية كيفية الإبطاء التدريجي لإنشاء العمليات في Windows (ad infinitum) بشكل غير مرئي لمعظم المستخدمين!
وبالطبع ، ستخبرك المقالة أيضًا بكيفية اكتشاف هذه المشكلة وتجنبها.
هذه مشكلة حقيقية واجهتها في بداية العام ، ويشرح المقال كيف اكتشفتها ووجدت حلاً لها. مقالات سابقة حول إبطاء ويندوز:
هناك خطأ ما
أنا لا أبحث عن مشكلة ، ولكن أعتقد أنني وجدتها. ربما لأنني أجمع Chrome من المصدر مئات المرات خلال عطلة نهاية الأسبوع ، أو أنني لست محظوظًا في الحياة. أعتقد أننا لن نعرف أبدا. بطريقة أو بأخرى ، توضح هذه المقالة المشكلة الخطيرة
الخامسة التي واجهتها في Windows عند إنشاء Chrome.
- تسلسل غير مخطط له ، مما يؤدي إلى واجهة مستخدم معلقة كاملة: "معالج 24 نواة ، ولكن لا يمكنني تحريك المؤشر . "
- تسرب واصف عملية في أحد وظائف Microsoft الإضافية لنظام التشغيل Windows: "عمليات Zombie تلتهم ذاكرتك . "
- خطأ تصحيح طويل الأمد في ذاكرة التخزين المؤقت لملف Windows: "خطأ مترجم؟ خطأ رابط؟ خطأ في Windows kernel. "
- فشل في الأداء عند استخدام إشعارات الملفات بشكل غير صحيح: "إبطاء Windows ، الجزء 1: الوصول إلى الملفات . "
- وهذا: حل معماري غريب يبطئ إنشاء العمليات بمرور الوقت.
تتبع تحطم نادر
يجب أن تكون أجهزة الكمبيوتر موثوقة ويمكن التنبؤ بها ، وهناك شيء آخر يزعجني. إذا قمت ببناء Chrome عدة مئات من المرات على التوالي ، أود أن أرى كل تجميع ناجحًا. لذلك ، عندما تتعطل عملية الترجمة الموزعة (gomacc.exe) في بعض الأحيان ، أريد التحقيق في ذلك. لقد قمت بإعداد
التسجيل التلقائي لمخلفات الأعطال ، لذا أرى أن الأعطال تحدث عند اكتشاف تلف الكومة. طريقة سهلة للتحقق هي تمكين كومة الصفحة بحيث يضع كومة الذاكرة المؤقتة Windows كل تخصيص الذاكرة على صفحة منفصلة. وهذا يعني أن فيض الاستخدامات بعد الاستخدام المجاني والمخزن المؤقت يؤدي إلى فشل فوري بدلاً من التلف الذي يصعب تشخيصه. سبق لي أن كتبت عن
تمكين كومة الصفحة باستخدام App Verifier .
يعمل App Verifier على إبطاء البرنامج لسببين: يتم إبطاء عمليات تخصيص الذاكرة ، وتقوم عمليات تخصيص محاذاة الصفحة بإلغاء تنشيط ذاكرة التخزين المؤقت للمعالج. وبالتالي ، كان التباطؤ الطفيف في التجميع متوقعًا ، وحدث ذلك.
ولكن عندما جئت لاحقًا ، بدا أن التجمع توقف تمامًا. بعد
حوالي 7000 خطوة تجميع ، لم يكن هناك تقدم ملحوظ.
عادةً ما يكون O (n ^ 2) ليس جيدًا
تبين يحب تطبيق التحقق من إنشاء ملفات السجل. وبغض النظر عن عدم وجود أي شخص يراقب هذه الملفات ، فإنه يقوم بإنشائها فقط في حالة. ويجب أن تحمل هذه الملفات أسماء فريدة. أنا متأكد من أنها فكرة جيدة أن أعطي السجلات أسماء رقمية في ترتيب تصاعدي ، مثل gomacc.exe.0.dat ، gomacc.exe.1.dat ، وما إلى ذلك.
للحصول على أسماء رقمية بترتيب تصاعدي ، تحتاج إلى تحديد الرقم الذي ستستخدمه بعد ذلك. أسهل طريقة هي
تجربة أسماء / أرقام محتملة حتى تجد اسمًا لم يتم استخدامه بعد. أي ، حاول إنشاء ملف جديد يسمى gomacc.exe.0.dat ، وإذا كان موجودًا بالفعل ، فجرّب gomacc.exe.1.dat وما إلى ذلك.
ما الخطأ الذي قد يحدث؟
في الواقع ، في أسوأ الحالات ، كل شيء سيئ جدًا
اتضح أنه إذا قمت بإجراء بحث خطي عن اسم ملف غير مستخدم عند إنشاء عملية ، فإن بدء عمليات N يتطلب عمليات
O (N ^ 2) . يفرض المنطق السليم أن خوارزميات O (N ^ 2) بطيئة جدًا إذا لم تتمكن من ضمان بقاء N دائمًا صغيرة نسبيًا.
يعتمد مدى سوء الوضع على الوقت الذي يستغرقه التحقق من وجود الملف. لقد أجريت قياسات ووجدت أنه على نظام Windows يستغرق حوالي 80 ميكروثانية (80 ميكرومتر أو 0.08 مللي ثانية). بدء العملية الأولى سريع ، لكن بدء العملية 1000 يتطلب فحص 1000 ملفات سجل تم إنشاؤها بالفعل. يستغرق 80 مللي ثانية ، ثم أكثر.
يتطلب التصميم النموذجي لمتصفح Chrome أن يعمل المترجم حوالي 30،000 مرة. يتطلب كل تشغيل للمترجم مسح ملفات N التي تم إنشاؤها مسبقًا ، 0.08 مللي ثانية لفحص كل ملف. يعني البحث الخطي عن اسم ملف السجل المتاح التالي أن تشغيل عمليات N يتطلب (N ^ 2) / 2 التحقق من وجود الملف ، أي 30،000 * 30،000 / 2 ، أي 450 مليون. نظرًا لأن كل عملية تحقق من وجود ملف تستغرق 0.08 مللي ثانية ، فإن هذا يمثل 36 مليون مللي ثانية ، أو 36000 ثانية. أي أن وقت بناء Chrome ، الذي عادة ما يكون من خمس إلى عشر دقائق ، سيزيد بمقدار عشر ساعات أخرى.
لعنة.
عند كتابة هذا المقال ، قمت بإعادة إنتاج الخطأ عن طريق تشغيل ملف قابل للتنفيذ فارغ حوالي 7000 مرة - ورأيت منحنى O (n ^ 2) واضح مثل هذا:
ومن الغريب ، إذا أخذنا تتبع ETW ونظرنا في متوسط وقت المكالمة إلى CreateFile ، فإن النتيجة بالنسبة لجميع الملفات تقريبًا أقل من خمسة ميكروثانية (بمعدل 4.386 ميكرومتر في المثال أدناه):
يبدو أن هذا يظهر فقط قيود ETW على تتبع ملف الإدخال / الإخراج. تتتبع أحداث الإدخال / الإخراج للملف المستوى الأدنى فقط من نظام الملفات ، وفوق Ntfs.sys هناك العديد من المستويات الأخرى ، بما في ذلك FLTMGR.SYS و ntoskrnl.exe. ومع ذلك ، لا يمكن إخفاء التباطؤ تمامًا - يظهر استخدام CPU على الرسم البياني لاستخدام CPU. توضح لقطة الشاشة أدناه الفترة الزمنية التي تبلغ 548 مللي ثانية ، والتي تمثل إنشاء عملية واحدة. بشكل أساسي ، كل الوقت الذي يستغرقه فحص حوالي 6850 اسم ملف سجل ممكن:
هل سيساعد القرص الأكثر إنتاجية؟
لا.
كمية البيانات التي تمت معالجتها صغيرة ، ومقدار الكتابة على القرص أقل. خلال اختباراتي لإعادة إنتاج خطأ ، كان القرص خاملاً تمامًا تقريبًا. ترتبط هذه المشكلة بوحدة المعالجة المركزية لأن جميع بيانات القرص ذات الصلة مخزنة مؤقتًا. وحتى إذا تم تخفيض التكاليف العامة بأمر من الحجم ، فستظل كبيرة جدًا. لا يمكنك تحسين خوارزمية O (N ^ 2).
الاكتشاف
يمكن الكشف عن هذه المشكلة بالبحث عن٪ userprofile٪ \ appverifierlogs لملفات .dat.
بشكل عام ، يمكنك اكتشاف تباطؤ في إنشاء العملية من خلال فحص تتبع ETW ، والآن تعرف ما الذي تبحث عنه.
الحل
الحل الأسهل هو إيقاف التسجيل. سيؤدي هذا أيضًا إلى إيقاف ملء القرص بسعة غيغابايت من السجلات. تم تعطيله بواسطة الأمر التالي:
appverif.exe -logtofile disableبعد تعطيل التسجيل ، وجدت أن عملياتي بدأت أسرع بثلاث مرات تقريبًا (!) من بداية الاختبار ، واختفى التباطؤ تمامًا. يتم إنشاء عمليات 7000 مراقب تطبيق مراقب في 1.5 دقيقة ، وليس 40 دقيقة. باستخدام ملفي الدفعي البسيط للاختبارات والعملية البسيطة ، أرى سرعات إنشاء العملية التالية:
- عادة 200 في الثانية (5 مللي ثانية لكل عملية)
- 75 في الثانية مع تمكين Application Verifier ولكن تم تعطيل التسجيل (13 مللي ثانية لكل عملية)
- 40 في الثانية مع تشغيل Application Verifier وتشغيل التسجيل ، في البداية ... (25 مللي ثانية لكل عملية ، يزداد الوقت تدريجيًا إلى ما لا نهاية)
- 0.4 في الثانية بعد بناء Chrome واحد
يمكن لـ Microsoft إصلاح هذه المشكلة عن طريق التخلي عن الزيادة الرتيبة في عدد ملفات السجل. إذا استخدموا التاريخ والوقت الحاليين كاسم ملف (حتى ميلي ثانية أو بدقة أعلى) ، فسيحصلون على أسماء ذات معنى أكثر دلالة للسجلات التي يتم إنشاؤها بسرعة كبيرة دون أي منطق بحث لملف فريد.
لكن Application Verifier لم يعد مدعومًا ، وملفات السجل عديمة الفائدة على أي حال ، لذا قم بتعطيلها فقط.
المعلومات الداعمة
يمكن العثور على الملفات الدفعية والنص البرمجي لإعادة إنشاء الخطأ بعد تمكين Application Verifier لـ blank.exe
هنا .
تتبع ETW من حوالي نهاية التجربة
هنا .
روابط أخرى:
بيانات التوقيت الأولية المستخدمة لإنشاء مخطط.مناقشة حول Redditمناقشة في أخبار هاكرللحصول على أمثلة لخوارزميات O (n ^ 2) الأخرى التي يتم الترويج لها ، راجع
Accidentally Quadraticللتمتع بمزيد من الدنيوية ، شاهد تجميعًا للفيديو يضم
19 طريقة مختلفة للوصول إلى العمل في سبتمبر - كنت مشغولًا جدًا لمواصلة التجربة هذا الشهر.