في .NET Core 3.0 ، نقدم مجموعة من الأدوات التي تستفيد من الميزات الجديدة لبيئة وقت تشغيل .NET والتي تعمل على تبسيط تشخيص مشاكل الأداء وحلها.
ستساعدك هذه الميزات في الإجابة على بعض الأسئلة التشخيصية الشائعة التي قد تكون لديك:
- هل عملي قيد التشغيل؟
- لماذا طلبي لديه سلوك غير طبيعي؟
- لماذا يتعطل طلبي؟
هل عملي قيد التشغيل؟
بمرور الوقت ، قد يحدث تسرب للذاكرة في التطبيق ، مما يؤدي في النهاية إلى OutOfMemoryException. في حالات أخرى ، قد تؤدي بعض التعليمات البرمجية المشكّلة إلى قفزة في تحميل المعالج. هذه مجرد بعض المشكلات التي يمكنك تحديدها بنشاط باستخدام
المقاييس .
المقاييس
المقاييس هي بيانات القياس على مدى فترة من الزمن. تتيح لك هذه المقاييس مراقبة حالة النظام لديك على مستوى عالٍ. بخلاف .NET Framework على نظام Windows ، لا يقوم .NET Core بإنشاء عدادات للأداء. بدلاً من ذلك ، قدمنا طريقة جديدة لإنشاء مقاييس في .NET Core من خلال
EventCounter API.
تقدم EventCounters تحسينًا على عدادات أداء Windows ، حيث يتم استخدامها الآن على جميع أنظمة التشغيل التي تدعم .NET Core. بالإضافة إلى ذلك ، على عكس عدادات الأداء ، يمكن استخدامها أيضًا في بيئات منخفضة الامتياز (على سبيل المثال ، عند نشر xcopy). لسوء الحظ ، فإن عدم وجود أداة مثل Performance Monitor (perfmon) يجعل من الصعب عرض هذه المؤشرات في الوقت الفعلي.
DOTNET-عداداتفي الإصدار 3.0-preview5 ، نقدم أداة سطر أوامر جديدة لمراقبة المقاييس الناتجة عن تطبيقات .NET Core في الوقت الفعلي.
يمكنك تثبيت هذه الأداة عن طريق تشغيل الأمر التالي
dotnet tool install --global dotnet-counters --version 1.0.3-preview5.19251.2
في المثال أدناه ، نرى أن تحميل وحدة المعالجة المركزية وذاكرة تطبيقنا يزدادان عندما نبدأ التحميل على تطبيق الويب الخاص بنا.
للحصول على إرشادات مفصلة حول كيفية استخدام هذه الأداة ، راجع
ملف الملف التمهيدي في المشروع باستخدام عدادات dotnet . لمعرفة القيود المعروفة في عدادات dotnet ، انظر إلى
المشكلات المفتوحة على GitHub .
لماذا طلبي لديه سلوك غير طبيعي؟
بينما تساعد المقاييس في تحديد حدوث سلوك غير طبيعي ، إلا أنها لا تقدم سوى القليل من الفهم لما حدث من خطأ. للإجابة على السؤال الخاص بسلوك غير طبيعي للتطبيق الخاص بك ، تحتاج إلى جمع معلومات إضافية من خلال التتبعات. على سبيل المثال ، يمكن أن تساعدك ملفات تعريف وحدة المعالجة المركزية التي تم تجميعها باستخدام التتبع في تحديد المسار السريع في التعليمات البرمجية الخاصة بك.
تتبع
تتبعات ثابتة سجلات الأحداث المنفصلة ختمها الوقت. تتبعات تحتوي على سياق محلي يسمح لك بتحديد أفضل مصير النظام. بشكل تقليدي ، قام .NET Framework (والأطر مثل ASP.NET) بإنشاء آثار تشخيصية حول مكوناتها الداخلية باستخدام تتبع الأحداث لـ Windows (ETW). في .NET Core ، تم تسجيل هذه التتبعات في ETW لـ Windows و LTTng لنظام التشغيل Linux.
DOTNET-التتبعفي الإصدار 3.0-preview5 ، يفتح كل تطبيق .NET Core قناة مزدوجة باسم EventPipe (مقبس مجال Unix في * nix أو توجيه إخراج مسمى في Windows) يمكن من خلالها إرسال الأحداث. بينما لا نزال نعمل على بروتوكول التحكم ، يقوم تتبع dotnet بتطبيق نسخة أولية من هذا البروتوكول.
يمكنك تثبيت هذه الأداة عن طريق تشغيل الأمر التالي
dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2
في المثال أعلاه ، أقوم بتشغيل تتبع dotnet مع ملف تعريف افتراضي يتضمن أحداث منشئ ملفات التعريف CPU وأحداث .NET وقت التشغيل.
بالإضافة إلى الأحداث الافتراضية ، يمكنك تمكين موفرين
إضافيين بناءً على الدراسة التي تحاول تنفيذها.
نتيجة تشغيل تتبع dotnet ، ستحصل على ملف .netperf. يحتوي هذا الملف على وقت تشغيل وأحداث تكديس وحدة المعالجة المركزية التي يمكن تصورها في مستوى
الكمال . سيضيف التحديث التالي لبرنامج Visual Studio (16.1) أيضًا دعمًا لتصور هذه الآثار.
إذا كنت تقوم بتشغيل OS X أو Linux ، فيمكنك تحويل ملفات .netperf إلى ملفات .speedscope.json التي يمكن تقديمها باستخدام
Speedscope.app عند تسجيل الآثار
.يمكنك تحويل تتبع موجود عن طريق تشغيل الأمر التالي:
dotnet trace convert <input-netperf-file>
تُظهر الصورة أدناه مخططًا يوضح الأثر الذي تلقيناه للتو.
للحصول على إرشادات مفصلة حول كيفية استخدام هذه الأداة ، راجع
ملف الملف التمهيدي . لمعرفة القيود المعروفة مع تتبع dotnet ، انظر إلى
المشكلات المفتوحة على GitHub .
لماذا يتعطل طلبي؟
في بعض الحالات ، لا يمكن إثبات سبب السلوك غير الطبيعي من خلال مراقبة العملية ببساطة. في حالة فشل العملية أو المواقف التي قد نحتاج فيها إلى معلومات إضافية ، مثل الوصول إلى كومة العملية بأكملها ، قد يكون تفريغ العملية أكثر ملاءمة للتحليل.
تحليل تفريغ
التفريغ هو عبارة عن سجل لحالة الذاكرة الافتراضية للعملية ، وعادة ما يتم التقاطها عند إنهاؤها بشكل غير متوقع. تستخدم تشخيصات تفريغ Kernel بشكل شائع لتحديد أسباب تعطل التطبيق أو السلوك غير المتوقع.
تقليديًا ، كنت تعتمد على نظام التشغيل الخاص بك لتلقي ملف تفريغ عند تعطل أحد التطبيقات (على سبيل المثال ، تقارير أخطاء Windows) أو استخدام أداة مثل
procdump لالتقاط ملف تفريغ عند استيفاء معايير تشغيل معينة.
حتى الآن ، كانت مشكلة تفريغ التفريغ باستخدام .NET على Linux هي أن تفريغ التفريغ باستخدام gcore أو المصحح قد أدى إلى تفريغ كبير جدًا ، لأن الأدوات الموجودة لم تعرف صفحات الذاكرة الظاهرية التي يجب قطعها في عملية .NET Core.
بالإضافة إلى ذلك ، كان من الصعب تحليل هذه المقالب حتى بعد جمعها ، لأنه كان عليك شراء مصحح أخطاء وتكوينه لتحميل sos ، وهو ملحق مصحح أخطاء لـ .NET.
DOTNET تفريغفي الإصدار 3.0.0-preview5 ، نقدم أداة جديدة تتيح لك جمع وتحليل مقالب العمليات في كل من Windows و Linux.
لا يزال dotnet-dump قيد التطوير النشط ، ويبين الجدول أدناه الميزات التي يتم دعمها حاليًا على أنظمة التشغيل.
يمكنك تثبيت هذه الأداة عن طريق تشغيل الأمر التالي
dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2
بعد تثبيت dotnet-dump ، يمكنك التقاط تفريغ العملية عن طريق تشغيل الأمر التالي
sudo $HOME/.dotnet/tools/dotnet-dump collect -p <pid>
على نظام Linux ، يمكن تحليل التفريغ الناتج عن طريق تحميل التفريغ الناتج باستخدام الأمر التالي
dotnet dump analyze <dump-name>
في المثال التالي ، أحاول تحديد ملف تفريغ بيئة استضافة ASP.NET Core
للحصول على إرشادات مفصلة حول كيفية استخدام هذه الأداة ، راجع
ملف الملف التمهيدي. لمعرفة القيود المعروفة مع dotnet-dump ، انظر إلى
المشكلات المفتوحة على GitHub .
استنتاج
شكرًا لاختبار أدوات التشخيص الجديدة في .NET Core 3.0. يرجى الاستمرار في تقديم ملاحظات لنا ، إما في التعليقات أو على
GitHub . نستمع بعناية وسنجري تغييرات بناءً على تعليقاتك.