أفضل الممارسات للحصول على الأداء الأمثل في Azure Managed Instance ل Apache Cassandra

Azure Managed Instance ل Apache Cassandra هي خدمة مدارة بالكامل لمجموعات Apache Cassandra مفتوحة المصدر فقط. تسمح الخدمة أيضا بتجاوز التكوينات، اعتمادا على الاحتياجات المحددة لكل حمل عمل. تسمح هذه الميزة بأقصى قدر من المرونة والتحكم عند الحاجة. توفر هذه المقالة تلميحات حول كيفية تحسين الأداء.

الإعداد والتكوين الأمثل

عامل النسخ المتماثل، وعدد الأقراص، وعدد العقد، طبقات المنتج

يدعم Azure ثلاث مناطق توفر في معظم المناطق. يعين Azure Managed Instance ل Apache Cassandra مناطق التوفر إلى الرفوف. نوصي باختيار مفتاح قسم ذي علاقة أساسية عالية لتجنب الأقسام الساخنة. للحصول على أفضل مستوى من الموثوقية والتسامح مع الخطأ، نوصي بشدة بتكوين عامل النسخ المتماثل من 3. نوصي أيضا بتحديد مضاعف لعامل النسخ المتماثل كعدد العقد. على سبيل المثال، استخدم 3 و6 و9 وما إلى ذلك.

يستخدم Azure RAID 0 على عدد الأقراص التي تقوم بتوفيرها. للحصول على عمليات الإدخال/معدل الإدخال الأمثل في الثانية (IOPS)، تحقق من الحد الأقصى لعمليات الإدخال والإخراج في الثانية (IOPS) على مستوى المنتج الذي اخترته مع IOPS لقرص P30. على سبيل المثال، Standard_DS14_v2 يدعم مستوى المنتج 51,200 IOPS غير المخزن مؤقتا. يحتوي قرص P30 واحد على أداء أساسي يبلغ 5000 عملية IOPS. أربعة أقراص تؤدي إلى 20,000 IOPS، وهو ما يقل كثيرا عن حدود الجهاز.

نوصي بشدة بإجراء قياس واسع النطاق لحمل العمل الخاص بك مقابل مستوى المنتج وعدد الأقراص. يعد قياس الأداء مهما بشكل خاص لمستويات المنتجات التي تحتوي على ثمانية ذاكرات أساسية فقط. تظهر أبحاثنا أن وحدات المعالجة المركزية الثمانية الأساسية تعمل فقط لأحمال العمل الأقل تطلبا. تحتاج معظم أحمال العمل إلى 16 نواة كحد أدنى لأداءها بشكل صحيح.

أحمال العمل التحليلية مقابل أحمال العمل الخاصة بالمعاملات

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

• واحد محسن لزمن انتقال منخفض.
• واحد محسن لأحمال العمل التحليلية.

تحسين أحمال العمل التحليلية

نوصي بتطبيق الإعدادات التالية cassandra.yaml لأحمال العمل التحليلية. لمزيد من المعلومات حول كيفية تطبيق هذه الإعدادات، راجع تحديث تكوين Cassandra.

المهلات

قيمة	Cassandra MI الافتراضي	التوصية لحمل العمل التحليلي
read_request_timeout_in_ms	5,000	10,000
range_request_timeout_in_ms	10,000	20,000
counter_write_request_timeout_in_ms	5,000	10,000
cas_contention_timeout_in_ms	1,000	2,000
truncate_request_timeout_in_ms	60,000	120,000
slow_query_log_timeout_in_ms	500	1,000
roles_validity_in_ms	2,000	120,000
permissions_validity_in_ms	2,000	120,000

ذاكرة تخزين مؤقتة

قيمة	Cassandra MI الافتراضي	التوصية لحمل العمل التحليلي
file_cache_size_in_mb	2,048	6,144

المزيد من التوصيات

قيمة	Cassandra MI الافتراضي	التوصية لحمل العمل التحليلي
commitlog_total_space_in_mb	8,192	16,384
column_index_size_in_kb	64	16
compaction_throughput_mb_per_sec	128	256

إعدادات العميل

نوصي بزيادة مهلات برنامج تشغيل عميل Cassandra وفقا للمهلات المطبقة على الخادم.

تحسين زمن الانتقال المنخفض

إعداداتنا الافتراضية مناسبة بالفعل لأحمال العمل ذات زمن الانتقال المنخفض. لضمان أفضل أداء لأواخر الاستجابة، نوصي بشدة باستخدام برنامج تشغيل عميل يدعم التنفيذ التخميني وأن تقوم بتكوين العميل وفقا لذلك. بالنسبة لبرنامج تشغيل Java V4، يوضح العرض التوضيحي كيفية عمل هذه العملية وكيفية تمكين النهج في هذه العينة.

مراقبة اختناقات الأداء

أداء وحدة المعالجة المركزية

مثل كل نظام قاعدة بيانات، يعمل Cassandra بشكل أفضل إذا كان استخدام وحدة المعالجة المركزية حوالي 50٪ ولا يحصل أبدا على أعلى من 80٪. لعرض مقاييس وحدة المعالجة المركزية، من مدخل Microsoft Azure، ضمن قسم Monitoring ، افتح علامة التبويب Metrics .

للحصول على طريقة عرض واقعية لوحدة المعالجة المركزية، أضف عامل تصفية واستخدم Usage kind=usage_idle لتقسيم الخاصية. إذا كانت هذه القيمة أقل من 20%، فطبق التقسيم للحصول على الاستخدام من قبل جميع أنواع الاستخدام.

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

• قم بالتحجيم عموديا إلى مستوى منتج مع المزيد من الذاكرات الأساسية لوحدة المعالجة المركزية، خاصة إذا كانت الذاكرات الأساسية 8 أو أقل فقط.
• تحجيم أفقيا عن طريق إضافة المزيد من العقد. كما ذكرنا سابقا، يجب أن يكون عدد العقد مضاعفا لعامل النسخ المتماثل.

إذا كانت وحدة المعالجة المركزية عالية لعدد قليل فقط من العقد، ولكنها منخفضة للعقد الأخرى، فإنه يشير إلى قسم ساخن. يحتاج هذا السيناريو إلى مزيد من التحقيق.

يتم دعم تغيير مستوى المنتج باستخدام مدخل Microsoft Azure ونشر قالب Azure CLI وAzure Resource Manager (قالب ARM). يمكنك نشر قالب ARM أو تحريره واستبدال طبقة المنتج بإحدى القيم التالية:

• Standard_E8s_v4
• Standard_E16s_v4
• Standard_E20s_v4
• Standard_E32s_v4
• Standard_DS13_v2
• Standard_DS14_v2
• Standard_D8s_v4
• Standard_D16s_v4
• Standard_D32s_v4
• Standard_L8s_v3
• Standard_L16s_v3
• Standard_L32s_v3
• Standard_L8as_v3
• Standard_L16as_v3
• Standard_L32as_v3

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

أداء القرص

تعمل الخدمة على أقراص Azure P30 المدارة، والتي تسمح باندفاع IOPS. المراقبة الدقيقة مطلوبة عندما يتعلق الأمر باختناقات الأداء المتعلقة بالقرص. في هذه الحالة، من المهم مراجعة مقاييس IOPS.

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

• مقاييسك أعلى باستمرار من أو تساوي IOPS الأساسي. تذكر ضرب 5000 عملية IOPS في عدد الأقراص لكل عقدة للحصول على الرقم.
• المقاييس الخاصة بك أعلى باستمرار من أو تساوي الحد الأقصى المسموح به لعمليات الإدخال والإخراج في الإخراج في الخدمة لمستوى المنتج للكتابات.
• يدعم مستوى المنتج التخزين المخزن مؤقتا (ذاكرة التخزين المؤقت للكتابة)، وهذا الرقم أصغر من IOPS من الأقراص المدارة. هذه القيمة هي الحد الأعلى ل IOPS للقراءة.

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

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

• أضف المزيد من العقد لتوسيع نطاق مراكز البيانات.

إذا وصل IOPS إلى الحد الأعلى الذي يدعمه مستوى المنتج الخاص بك، يمكنك:

• توسيع نطاق إلى مستوى منتج مختلف يدعم المزيد من عمليات الإدخال والإخراج في الخدمة.
• أضف المزيد من العقد لتوسيع نطاق مراكز البيانات.

لمزيد من المعلومات، راجع أداء الجهاز الظاهري والقرص.

أداء الشبكة

عادة ما يكون أداء الشبكة كافيا. إذا كنت تقوم ببث البيانات بشكل متكرر، مثل التحجيم الأفقي المتكرر لأعلى/تقليص الحجم، أو كانت هناك حركات بيانات دخول/خروج ضخمة، يمكن أن يصبح هذا الأداء مشكلة. قد تحتاج إلى تقييم أداء الشبكة لمستوى المنتج الخاص بك. على سبيل المثال، Standard_DS14_v2 يدعم مستوى المنتج 12000 ميغابايت/ثانية. قارن هذه القيمة بالبايت في/خارج في المقاييس.

إذا رأيت الشبكة مرتفعة لبضع عقد فقط، فقد يكون لديك قسم ساخن. راجع أنماط توزيع البيانات والوصول للحصول على انحراف محتمل.

• توسيع النطاق عموديا إلى مستوى منتج مختلف عن طريق دعم المزيد من عمليات الإدخال/الإخراج للشبكة.
• توسيع نطاق المجموعة أفقيا عن طريق إضافة المزيد من العقد.

عدد كبير جدا من العملاء المتصلين

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

مساحة القرص

في معظم الحالات، هناك مساحة كافية على القرص. يتم تحسين عمليات النشر الافتراضية ل IOPS، ما يؤدي إلى استخدام منخفض للقرص. ومع ذلك، نوصي بمراجعة مقاييس مساحة القرص أحيانا. تقوم Cassandra بتجميع العديد من الأقراص ثم تقليلها عند تشغيل الضغط. من المهم مراجعة استخدام القرص على مدى فترات أطول لتحديد الاتجاهات، مثل عندما يكون الضغط غير قادر على إعادة حساب المساحة.

إشعار

لضمان المساحة المتوفرة للضغط، حافظ على استخدام القرص إلى حوالي 50%.

إذا رأيت هذا السلوك لعدد قليل من العقد، فقد يكون لديك قسم ساخن. راجع أنماط توزيع البيانات والوصول للحصول على انحراف محتمل.

• أضف المزيد من الأقراص، ولكن ضع في اعتبارك حدود IOPS التي يفرضها مستوى المنتج الخاص بك.
• توسيع نطاق نظام المجموعة أفقيا.

ذاكرة JVM

تعين الصيغة الافتراضية نصف ذاكرة الجهاز الظاهري إلى جهاز Java الظاهري (JVM) بحد أعلى يبلغ 31 غيغابايت. في معظم الحالات، يعد هذا النهج توازنا جيدا بين الأداء والذاكرة. قد تواجه بعض أحمال العمل، خاصة تلك التي تحتوي على عمليات قراءة متكررة عبر الأقسام أو عمليات فحص النطاق، تحديا للذاكرة.

في معظم الحالات، يتم استعادة الذاكرة بشكل فعال من قبل جامع البيانات المهملة Java. إذا كان CPU غالبا أعلى من 80%، فلا توجد دورات CPU كافية لجامع البيانات المهملة المتبقية. معالجة مشاكل أداء وحدة المعالجة المركزية قبل التحقق من أي مشاكل في الذاكرة.

إذا مرر وحدة المعالجة المركزية مؤشر الماوس إلى أقل من 70% ولم تتمكن مجموعة البيانات المهملة من استعادة الذاكرة، فقد تحتاج إلى المزيد من ذاكرة JVM. قد يكون من الضروري وجود المزيد من ذاكرة JVM إذا كنت تستخدم طبقة منتج ذات ذاكرة محدودة. في معظم الحالات، تحتاج إلى مراجعة الاستعلامات وإعدادات العميل وتقليلها fetch_size مع ما تم اختياره في limit استعلام لغة استعلام Cassandra (CQL).

إذا كنت بحاجة إلى مزيد من الذاكرة، يمكنك:

• قم بالتحجيم عموديا إلى مستوى منتج يحتوي على ذاكرة أكبر متوفرة.

شواهد القبور

نقوم بتشغيل الإصلاحات كل سبعة أيام مع برنامج ريبر، والذي يزيل الصفوف التي انتهت صلاحية مدة البقاء (TTL). تسمى هذه الصفوف علامات المقابر. تحذف بعض أحمال العمل بشكل متكرر وتظهر تحذيرات كما هو الحال Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) في سجلات Cassandra. تشير بعض الأخطاء إلى أنه تعذر تنفيذ استعلام بسبب علامات العلامات الزائدة.

التخفيف على المدى القصير إذا لم يتم تنفيذ الاستعلامات هو زيادة tombstone_failure_threshold القيمة في تكوين Cassandra من 100,000 الافتراضي إلى قيمة أعلى.

نوصي أيضا بمراجعة TTL على مساحة المفاتيح ومن المحتمل أن تقوم بتشغيل الإصلاحات يوميا لمسح المزيد من علامات المقابر. إذا كانت TTLs قصيرة (على سبيل المثال، أقل من يومين)، وتدفق البيانات وحذفها بسرعة، نوصي بمراجعة استراتيجية الضغط وتفضيل Leveled Compaction Strategy. في بعض الحالات، قد تشير هذه الإجراءات إلى أن مراجعة نموذج البيانات مطلوبة.

تحذيرات الدفعات

قد تواجه التحذير التالي في CassandraLogs والفشل المحتمل ذي الصلة:

Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.

راجع استعلاماتك للبقاء دون حجم الدفعة الموصى به. في حالات نادرة وكتخفيف قصير الأجل، قم بزيادة batch_size_fail_threshold_in_kbتكوين Cassandra من الافتراضي 50 إلى قيمة أعلى.

تحذير قسم كبير

قد تواجه التحذير التالي في CassandraLogs:

Writing large partition <table> (105.426MiB) to sstable <file>

تشير هذه الرسالة إلى وجود مشكلة في نموذج البيانات. لمزيد من المعلومات، راجع مقالة تجاوز مكدس الذاكرة المؤقتة هذه. يمكن أن تتسبب هذه المشكلة في حدوث مشكلات شديدة في الأداء ويجب معالجتها.

تحسينات متخصصة

الضغط

يسمح Cassandra بتحديد خوارزمية ضغط مناسبة عند إنشاء جدول. الإعداد الافتراضي هو LZ4، وهو ممتاز لمعدل النقل وCPU ولكنه يستهلك مساحة أكبر على القرص. يوفر استخدام Zstandard (Cassandra 4.0 وما فوق) حوالي 12% مساحة بأقل حمل لوحدة المعالجة المركزية.

تحسين مساحة كومة الذاكرة المؤقتة memtable

الافتراضي هو استخدام ربع كومة الذاكرة المؤقتة JVM memtable_heap_space في cassandra.yaml الملف. بالنسبة للتطبيقات الموجهة للكتابة أو على مستويات المنتج ذات كميات صغيرة من الذاكرة، يمكن أن تؤدي هذه المشكلة إلى المسح المتكرر والتجزئة sstables، والتي تتطلب ضغطا أكبر. قد تكون الزيادة إلى 4048 على الأقل جيدة. يتطلب هذا الأسلوب قياسا دقيقا للتأكد من عدم تأثر العمليات الأخرى (على سبيل المثال، القراءات).

الخطوة التالية

تكوين نظام المجموعة باستخدام مدخل Azure