الفوائد المفاجئة وغير المفاجئة للأجيال في Z Garbage Collector.
بقلم داني توماس، فريق النظام البيئي JVM
يوفر أحدث إصدار دعم طويل المدى لـ JDK دعمًا للأجيال لـ Z Garbage Collector.
يتم الآن تشغيل أكثر من نصف خدمات بث الفيديو المهمة لدينا على JDK 21 مع Generational ZGC، لذا فهو الوقت المناسب للحديث عن تجربتنا والفوائد التي رأيناها. إذا كنت مهتمًا بكيفية استخدامنا لـ Java في Netflix، فإن حديث Paul Bakker حول “كيف تستخدم Netflix حقًا Java”، يعد مكانًا رائعًا للبدء.
في كل من خدمات GRPC وDGS Framework، تعد عمليات إيقاف GC مؤقتًا مصدرًا مهمًا لزمن الاستجابة. وينطبق هذا بشكل خاص على عملاء وخوادم GRPC لدينا، حيث تتفاعل عمليات إلغاء الطلبات بسبب انتهاء المهلات مع ميزات الموثوقية مثل عمليات إعادة المحاولة والتحوط والاحتياطيات. كل خطأ من هذه الأخطاء عبارة عن طلب ملغى يؤدي إلى إعادة المحاولة، لذا فإن هذا التخفيض يقلل بشكل أكبر من إجمالي حركة الخدمة بهذا المعدل:
تتيح لنا إزالة ضجيج التوقف المؤقت أيضًا تحديد المصادر الفعلية لوقت الاستجابة من طرف إلى طرف، والتي قد تكون مخفية في الضجيج، حيث يمكن أن تكون القيم المتطرفة القصوى لوقت التوقف المؤقت كبيرة:
حتى بعد أن رأينا نتائج واعدة للغاية في تقييمنا، توقعنا أن يكون اعتماد ZGC بمثابة مقايضة: إنتاجية أقل قليلاً للتطبيق، بسبب حواجز التخزين والتحميل، والعمل المنجز في مصافحة الخيط المحلية، وتنافس GC مع التطبيق للموارد. لقد اعتبرنا أن هذه مقايضة مقبولة، حيث أن تجنب التوقف المؤقت يوفر فوائد تفوق تلك النفقات العامة.
في الواقع، لقد وجدنا أنه بالنسبة لخدماتنا وتصميمنا، لا يوجد مثل هذه المقايضة. بالنسبة لهدف استخدام وحدة المعالجة المركزية المحدد، تعمل ZGC على تحسين زمن الوصول المتوسط وP99 مع استخدام وحدة المعالجة المركزية بشكل متساوٍ أو أفضل مقارنةً بـ G1.
من المؤكد أن الاتساق في معدلات الطلب وأنماط الطلب ووقت الاستجابة ومعدلات التخصيص التي نراها في العديد من خدماتنا يساعد ZGC، ولكننا وجدنا أنها قادرة أيضًا على التعامل مع أعباء العمل الأقل اتساقًا (مع استثناءات بالطبع؛ المزيد عن ذلك أدناه).
غالبًا ما يتواصل معنا مالكو الخدمة لطرح أسئلة حول أوقات التوقف المفرطة وللمساعدة في الضبط. لدينا العديد من أطر العمل التي تعمل بشكل دوري على تحديث كميات كبيرة من البيانات الموجودة على الكومة لتجنب مكالمات الخدمة الخارجية لتحقيق الكفاءة. تعد هذه التحديثات الدورية للبيانات الموجودة على الكومة رائعة في مفاجأة G1، مما يؤدي إلى قيم متطرفة لوقت الإيقاف المؤقت تتجاوز بكثير هدف وقت الإيقاف المؤقت الافتراضي.
كانت هذه البيانات الطويلة الأمد على الكومة هي المساهم الرئيسي في عدم اعتماد ZGC غير الأجيال سابقًا. في أسوأ الحالات التي قمنا بتقييمها، تسببت ZGC غير الجيلية في استخدام وحدة المعالجة المركزية بنسبة 36% أكثر من G1 لنفس حمل العمل. لقد أصبح ذلك تحسنًا بنسبة 10٪ تقريبًا مع أجيال ZGC.
نصف جميع الخدمات المطلوبة لدفق الفيديو تستخدم مكتبة Hollow الخاصة بنا للبيانات التعريفية الموجودة على الكومة. سمحت لنا إزالة التوقفات المؤقتة باعتبارها أحد المخاوف بإزالة عوامل تخفيف تجميع المصفوفات، مما أدى إلى تحرير مئات الميجابايت من الذاكرة للتخصيصات.
تنبع البساطة التشغيلية أيضًا من الاستدلالات والافتراضيات الخاصة بشركة ZGC. ولم يكن هناك حاجة إلى ضبط واضح لتحقيق هذه النتائج. تعد أكشاك التخصيص نادرة، وتتزامن عادةً مع ارتفاعات غير طبيعية في معدلات التخصيص، وهي أقصر من متوسط أوقات التوقف المؤقت التي شهدناها مع G1.
لقد توقعنا أن فقدان المراجع المضغوطة في أكوام أقل من 32 جيجا، بسبب المؤشرات الملونة التي تتطلب مؤشرات كائنات 64 بت، سيكون عاملاً رئيسيًا في اختيار أداة تجميع البيانات المهملة.
لقد وجدنا أنه على الرغم من أن هذا اعتبار مهم بالنسبة إلى GCs التي توقف العالم، فإن هذا ليس هو الحال بالنسبة لـ ZGC حيث حتى في الأكوام الصغيرة، يتم إطفاء الزيادة في معدل التخصيص من خلال الكفاءة والتحسينات التشغيلية. نتقدم بالشكر إلى Erik Österlund في Oracle لشرح الفوائد الأقل سهولة للمؤشرات الملونة عندما يتعلق الأمر بجامعي البيانات المهملة المتزامنين، مما يقودنا إلى تقييم ZGC على نطاق أوسع مما كان مخططًا له في البداية.
في معظم الحالات، تكون ZGC أيضًا قادرة على توفير المزيد من الذاكرة للتطبيق باستمرار:
لدى ZGC حمل ثابت بنسبة 3% من حجم الكومة، مما يتطلب ذاكرة أصلية أكبر من ذاكرة G1. باستثناء بعض الحالات، لم تكن هناك حاجة لخفض الحد الأقصى لحجم الكومة للسماح بمساحة أكبر، وكانت تلك الخدمات ذات احتياجات ذاكرة أصلية أكبر من المتوسط.
يتم أيضًا تنفيذ المعالجة المرجعية فقط في المجموعات الرئيسية باستخدام ZGC. لقد أولينا اهتمامًا خاصًا بإلغاء تخصيص المخازن المؤقتة للبايت المباشر، لكننا لم نر أي تأثير حتى الآن. تسبب هذا الاختلاف في معالجة المرجع في حدوث مشكلة في الأداء مع دعم تفريغ مؤشر ترابط JSON، ولكن هذا موقف غير عادي ناتج عن إنشاء إطار عمل عن طريق الخطأ لمثيل ExecutorService غير مستخدم لكل طلب.
حتى إذا كنت لا تستخدم ZGC، فمن المحتمل أن تستخدم صفحات ضخمة، والصفحات الضخمة الشفافة هي الطريقة الأكثر ملاءمة لاستخدامها.
تستخدم ZGC الذاكرة المشتركة للكومة والعديد من توزيعات Linux تقوم بتكوين shmem_enabled عليها أبداً، والذي يمنع ZGC بصمت من استخدام صفحات ضخمة مع -XX:+UseTransparentHugePages.
لدينا هنا خدمة منتشرة دون أي تغيير آخر ولكن shmem_enabled ينتقل من عدم تقديم المشورة مطلقًا، مما يقلل من استخدام وحدة المعالجة المركزية بشكل كبير:
التكوين الافتراضي لدينا:
- يضبط الحد الأدنى والحد الأقصى للحجم على نفس الحجم
- تكوين -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch
- يستخدم التكوين الشفاف التالي للصفحة:
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo advise | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
echo defer | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
echo 1 | sudo tee /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
لا يوجد أفضل جامع للقمامة. يقوم كل منها بمقايضة إنتاجية المجموعة وزمن وصول التطبيق واستخدام الموارد اعتمادًا على هدف أداة تجميع البيانات المهملة.
بالنسبة لأحمال العمل التي كان أداؤها أفضل مع G1 مقابل ZGC، وجدنا أنها تميل إلى أن تكون أكثر توجهاً نحو الإنتاجية، مع معدلات تخصيص شديدة للغاية ومهام طويلة الأمد تحتفظ بالكائنات لفترات غير متوقعة.
ومن الأمثلة البارزة على ذلك الخدمة التي كانت فيها معدلات التخصيص شديدة الارتفاع وأعداد كبيرة من الكائنات طويلة العمر، والتي تصادف أنها مناسبة بشكل خاص لهدف وقت التوقف المؤقت لـ G1 والاستدلالات الخاصة بتجميع المنطقة القديمة. لقد سمح لـ G1 بتجنب العمل غير المنتج في دورات GC والذي لم تتمكن ZGC من القيام به.
لقد أتاح التحول إلى ZGC افتراضيًا فرصة مثالية لأصحاب التطبيقات للتفكير في اختيارهم لأداة تجميع البيانات المهملة. كانت العديد من حالات الدُفعات/الحوسبة المسبقة تستخدم G1 افتراضيًا، حيث كانت ستشهد إنتاجية أفضل من المجمع المتوازي. في أحد أحمال عمل الحوسبة المسبقة الكبيرة، شهدنا تحسنًا بنسبة 6-8% في إنتاجية التطبيق، مما أدى إلى تقليل وقت الدفعة لمدة ساعة، مقابل G1.
إذا تركت الافتراضات والتوقعات دون أدنى شك، فقد تكون قد تسببت في تفويت أحد أكثر التغييرات تأثيرًا التي أجريناها على الإعدادات الافتراضية التشغيلية لدينا خلال عقد من الزمن. نحن نشجعك على تجربة أجيال ZGC بنفسك. قد يفاجئك بقدر ما فاجأنا.
