قام بريندان جريج، أحد مطوري DTrace، والذي يقوم حاليًا بتطوير أدوات تحليل الأداء المستندة إلى BPF في Linux kernel، بتلخيص الخبرة المكتسبة من تحليل مشكلات الأداء التي واجهتها Netflix عند ترحيل Cassandra DBMS من CentOS إلى Ubuntu. سحابة Amazon EC2 المبنية على Xen. بعد الترحيل، زاد حمل وحدة المعالجة المركزية بنسبة 30% وزاد التأخير أثناء عمليات الكتابة بنفس المقدار تقريبًا. وكما تبين، فإن أداء التطبيقات التي تطلب معلومات الوقت بشكل مكثف يعتمد إلى حد كبير على مصدر الوقت المحدد المحدد في النظام.
في البداية، لم يكن سبب انخفاض الأداء واضحًا وبدأ التشخيص بمراقبة التأثير المحتمل لعمليات النظام كثيفة الاستخدام للموارد قيد التشغيل باستمرار أو التي يتم إطلاقها بشكل دوري باستخدام الأدوات المساعدة العليا وexecsnoop. لكن كل شيء يشير إلى أن استهلاك الموارد قد زاد على وجه التحديد في نظام Cassandra DBMS المكتوب بلغة Java. أظهرت مقارنة مقاييس التوصيف لعمليتي Cassandra اللتين تعملان بالتوازي على CentOS وUbuntu، ومعالجة نفس الاستعلامات، أن حوالي 32% من إجمالي الوقت تم إنفاقه في الاتصال بـ os::javaTimeMillis()، والذي يُستخدم للحصول على معلومات حول الوقت الحالي .
بعد ذلك، تم إجراء تجربة تم فيها كتابة تطبيق Java بسيط يسمى طريقة System.currentTimeMillis() مائة مليون مرة في الحلقة. أظهر تشغيل التطبيق أن الأمر استغرق 13 ثانية لإكماله على CentOS، وحوالي 68 ثانية على Ubuntu، أي. 5 مرات أبطأ. تمت كتابة برنامج مماثل في لغة C، والذي دعا الدالة gettimeofday() مائة مليون مرة، ولكن عند تنفيذها، تم الحصول على نتائج مماثلة.
وبما أنه أصبح من الواضح أن مصدر المشكلة هو وظيفة إرجاع الوقت الحالي، فقد تحول الاهتمام إلى التغيرات في المؤشرات عند اختيار مصادر مختلفة للوقت المحدد في النظام. انطلاقًا من محتويات "/sys/devices/system/clocksource/clocksource0/current_clocksource"، تم استخدام المؤقت "xen" افتراضيًا عند تشغيل Linux في نظام الضيف. بعد تغيير مصدر الوقت إلى "tsc"، انخفض وقت تنفيذ تطبيق الاختبار في Ubuntu من 68 إلى 3.3 ثانية، أي. أصبح أسرع 20 مرة. بالإضافة إلى ذلك، تم إجراء اختبار أداء لمصدر وقت ساعة kvm، والذي أظهر زيادة في التأخير بنسبة 20% مقارنة بـ TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench حقيقي 1m8.300s مستخدم 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ الوقت java TimeBench الحقيقي 0m3.370s المستخدم 0m3.353s sys 0m0.026s
للحصول على الوقت عند تحديد مصدر TSC، يتم استخدام تعليمات معالج RDTSC، والتي لا يتطلب تنفيذها استدعاء النظام (لا تتطلب التعليمات امتيازات مرتفعة وتنتج قيمة من عداد الوقت المدمج في وحدة المعالجة المركزية). بشكل افتراضي، لا يتم تنشيط TSC لأنه في الأيام القديمة لم يكن هذا المصدر يستبعد الانحراف التدريجي للوقت، والذي يتم ضبطه في المعالجات الأخرى بواسطة البرنامج لتحقيق قراءات أكثر دقة. ووفقا لمهندس متخصص في تطوير المعالجات، فإن المخاوف بشأن التحولات الزمنية عند استخدام TSC غير صحيحة منذ فترة طويلة وفي المعالجات الحديثة يمكن أن ينتج هذا المصدر قراءات مستقرة لسنوات.
أدى تحويل خوادم الإنتاج في Netflix إلى مصدر TSC إلى تقليل زمن استجابة الكتابة بنسبة 43% وحقق نتائج باستخدام Ubuntu كانت أسرع 4 مرات من التكوينات التي تعمل بنظام CentOS مع مصدر زمني "xen". تم نقل نتائج الدراسة إلى Amazon، التي أوصت رسميًا باستخدام مصدر وقت TSC الافتراضي في بيئات AWS EC2 المستندة إلى برنامج Hypervisor Xen (يظل kvm-clock موصى به في البيئات المستندة إلى برنامج Hypervisor Nitro).
المصدر: opennet.ru