Pinterest تتخلى عن حديقة المحلّلات المتفرقة لصالح gProfiler المفتوح المصدر من Intel

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

المشكلة: لغات كثيرة وأدوات كثيرة

إليكم أرقام الحجم: 640 مليون مستخدم نشط شهريًا، ومئات الآلاف من نسخ الحوسبة. الخدمات مكتوبة بلغات Java وPython وC++ وGo وNode.js. ولكل لغة كانت لدى المهندسين أداتهم المعتادة: perf للشيفرة الأصلية، وasync-profiler لآلة JVM، وpy-spy للغة Python.

كل أداة منها جيدة بمفردها. لكنها معًا تصنع فوضى. فصيغ البيانات مختلفة، وطرق التشغيل مختلفة، وربط الصورة الكاملة لسلسلة «بوابة Node.js، وخلفية Java، ومكتبة C++» يتم يدويًا. كما أن مقارنة ملف تعريف الخدمة نفسها على أجهزة مختلفة أو في أيام مختلفة ليست سهلة إذا أُخذت اللقطات بأدوات مختلفة.

بالنسبة لفريق البنية التحتية، هذه ليست مشكلة أكاديمية. فالملف الشخصي مطلوب لفهم أين تذهب أموال العتاد، ولاكتشاف التراجع (regression) بعد الإصدار. وإذا كانت البيانات متفرقة، فإن الإجابة عن هذه الأسئلة تكون بطيئة وغير واثقة.

ما الذي فُعل مع gProfiler

أداة gProfiler هي محلّل أداء مفتوح المصدر يعمل بشكل مستمر. يُشغَّل عبر وكيل (agent) على الجهاز ويجمع الملفات الشخصية للغات مختلفة دفعة واحدة، ويعرض النتيجة على شكل مخططات لهب (flame graphs). وقد وسّعت Pinterest بالتعاون مع Intel إمكاناته وأعادت التعديلات إلى المشروع المفتوح. ومن بين التحسينات:

• التحليل الديناميكي. يمكن تفعيل التحليل وضبطه أثناء التشغيل، بدلًا من إبقائه دائمًا على جميع الأجهزة.
• جمع القياس عن بعد على مستوى العتاد. لا يرى المحلّل أين تقضي الشيفرة وقتها فحسب، بل أيضًا بيانات عدّادات المعالج.
• التحليل بزمن الجدار (wall-time). يُظهر أين ينتظر الخيط (thread) فعليًا، وليس فقط أين يحمّل المعالج.
• مخططات لهب مبنية على عدّادات الأداء. بدلًا من محور «زمن CPU» المعتاد، يمكن بناء المخططات بحسب الأحداث العتادية.

يسهل فهم الفرق بين زمن CPU وزمن الجدار بمثال. لنفترض أن نقطة نهاية (endpoint) تستجيب خلال 300 مللي ثانية، لكن ملف CPU يُظهر أن المعالج يعمل 40 مللي ثانية فقط. أين ذهبت الـ260 المتبقية؟ على الأرجح أن الخيط ينتظر ردًا من قاعدة بيانات أو من الشبكة أو من قفل. ملف CPU لن يُظهر هذا الجزء إطلاقًا، أما زمن الجدار فيُظهره فورًا.

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

ما المهم هنا وما الذي لا نعرفه

لا توجد في الرسالة الأصلية أرقام: كم من موارد الحوسبة جرى توفيره، وبكم أصبح اكتشاف التراجعات أسرع، وكم نسخة جرى نقلها بالفعل. لذا من المبكر الحديث عن أثر قابل للقياس. هذا أقرب إلى إعلان عن خيار معماري منه إلى تقرير بالنتائج.

ومع ذلك فإن الخيار نفسه دالّ. كان بوسع شركة بهذا الحجم أن تبني منصتها الخاصة، لكنها فضّلت مشروعًا مفتوحًا وأعادت إليه تحسيناتها. وهذا إيجابي للآخرين: فتحسينات التحليل الديناميكي والتحليل بزمن الجدار ستكون متاحة لكل من يستخدم gProfiler.

ماذا تفعل عمليًا

1. أحصِ حديقتك من الأدوات. إذا كان لديك أكثر من لغتين في بيئة الإنتاج وأكثر من محلّلي أداء مختلفين، فلديك المشكلة نفسها ولكن بحجم أصغر.
2. جرّب gProfiler في بيئة اختبار. إنه مشروع مفتوح، وهو مصمم تحديدًا للتحليل المستمر دون تعديل شيفرة الخدمات.
3. اجعل wall-time عادة. إذا كانت الخدمة «تتباطأ لكن المعالج حر»، فهو ما تحتاجه تحديدًا.
4. تابع المشروع الأصلي (upstream). يُفترض أن تصل تحسينات Pinterest وIntel إلى المستودع الرئيسي، ومن المفيد التحقق مما أصبح متاحًا منها في الإصدارات.

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