مشاركة عبر

تشخيص واستكشاف استثناءات أخطاء طلبات Azure Cosmos DB ذات معدل كبير(429)

  • مقالة

ينطبق على: NoSQL

تحتوي هذه المقالة على الأسباب والحلول المعروفة لمختلف أخطاء رمز الحالة 429 لواجهة برمجة التطبيقات ل NoSQL. إذا كنت تستخدم واجهة برمجة التطبيقات لـ MongoDB، فراجع مقالة استكشاف المشكلات الشائعة في واجهة برمجة تطبيقات MongoDB وإصلاحها للتعرف على كيفية تصحيح أخطاء رمز الحالة 16500.

يشير استثناء "Request rate too large" المعروف أيضًا باسم رمز الخطأ 429 إلى أن طلباتك مقابل Azure Cosmos DB محدودة المعدل.

عند استخدام معدل النقل المقدم، يمكنك تعيين الإنتاجية التي تقاس في وحدات الطلب في الثانية (RU/s) المطلوبة لعبء العمل الخاص بك. تستهلك عمليات قاعدة البيانات مقابل الخدمة مثل القراءات والكتابة والاستعلامات بعض وحدات الطلب (RUs). تعرَّف على المزيد حول وحدات الطلب.

في ثانية معينة، إذا كانت العمليات تستهلك أكثر من وحدات الطلب المقدمة، سيقوم Azure Cosmos DB بإرجاع استثناء 429. يتم في كل ثانية إعادة تعيين عدد وحدات الطلبات المتوفرة للاستخدام.

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

تلميح

تنطبق الإرشادات الواردة في هذه المقالة على قواعد البيانات والحاويات التي تستخدم معدل نقل البيانات المقدم - سواء معدل النقل التلقائي أو اليدوي.

توجد رسائل خطأ مختلفة تتوافق مع أنواع مختلفة من 429 استثناءً:

معدل الطلب كبير

هذا هو السيناريو المعروف. يحدث عندما تتجاوز وحدات الطلب المستهلكة بواسطة العمليات على البيانات العدد المخصص لـ RU / s. إذا كنت تستخدم معدل نقل يدوي، فسيحدث هذا عندما تستهلك RU / s أكثر من الإنتاجية اليدوية المتوفرة. إذا كنت تستخدم التحجيم التلقائي، فسيحدث هذا عندما تستهلك أكثر من الحد الأقصى لـ RU / s المتوفرة. على سبيل المثال، إذا كان لديك مورد مزود بمعدل نقل يدوي يبلغ 400 وحدة طلب/ثانية، فسترى 429 عند استهلاك أكثر من 400 وحدة طلب في ثانية واحدة. إذا كان لديك مورد مزود بوحدة طلب/ثانية بحد أقصى للمقياس التلقائي يبلغ 4000 وحدة طلب/ثانية (يتدرج بين 400 وحدة طلب/ثانية - 4000 وحدة طلب/ثانية)، فسترى 429 استجابة عندما تستهلك أكثر من 4000 وحدة طلب في ثانية واحدة.

تلميح

يتم فرض رسوم على جميع العمليات استنادا إلى عدد الموارد التي تستهلكها. يتم قياس هذه الرسوم في وحدات الطلب. تتضمن هذه الرسوم الطلبات التي لم تكتمل بنجاح بسبب أخطاء التطبيق مثل 400و 412449و وما إلى ذلك. أثناء النظر إلى التقييد أو الاستخدام، من الجيد التحقق مما إذا كان هناك نمط ما قد تغير في استخدامك مما قد يؤدي إلى زيادة هذه العمليات. على وجه التحديد، تحقق من وجود علامات 412 أو 449 (تعارض فعلي).

لمزيد من المعلومات حول معدل النقل المقدم، راجع معدل النقل المقدم في Azure Cosmos DB.

الخطوة 1: تحقق من المقاييس لتحديد النسبة المئوية للطلبات التي بها خطأ 429

لا تعني رؤية 429 رسالة خطأ بالضرورة وجود مشكلة في قاعدة البيانات أو الحاوية. نسبة صغيرة من 429 استجابة أمر طبيعي سواء كنت تستخدم معدل النقل اليدوي أو التلقائي، وهي علامة على أنك تعظيم RU/s التي قمت بتوفيرها.

طريقة التحقق

حدد النسبة المئوية لطلباتك إلى قاعدة البيانات أو الحاوية التي نتج عنها 429 استجابة، مقارنة بالعدد الإجمالي للطلبات الناجحة. من حساب Azure Cosmos DB الخاص بك، انتقل إلى Insights>Requests Total Requests>by Status Code. قم بتصفية إلى قاعدة بيانات وحاوية معينة.

بشكل افتراضي، تعيد مجموعات SDK الخاصة بعميل Azure Cosmos DB وأدوات استيراد البيانات مثل Azure Data Factory ومكتبة المنفذ المجمع الطلبات تلقائيًا على 429 ثانية. يعيدون المحاولة عادةً ما يصل إلى تسع مرات. ونتيجة لذلك، بينما قد ترى 429 استجابة في المقاييس، قد لا تكون هذه الأخطاء قد تم إرجاعها إلى التطبيق الخاص بك.

إجمالي الطلبات حسب مخطط رمز الحالة الذي يعرض عدد طلبات 429 و2xx.

بشكل عام، بالنسبة لحمل عمل الإنتاج، إذا رأيت ما بين 1-5٪ من الطلبات مع 429 استجابة، وكان زمن الانتقال من النهاية إلى النهاية مقبولا، فهذه علامة صحية على أن وحدات الطلب/ الثانية يتم استخدامها بالكامل. لا توجد أية إجراءات مطلوبة. وإلا، فانتقل إلى خطوات استكشاف الأخطاء وإصلاحها التالية.

هام

يفترض هذا النطاق 1-5٪ أن أقسام حسابك موزعة بالتساوي. إذا لم يتم توزيع أقسامك بالتساوي، فقد يرجع قسم المشكلة كمية كبيرة من الأخطاء 429 بينما قد يكون المعدل الإجمالي منخفضا.

إذا كنت تستخدم مقياسا تلقائيا، فمن الممكن رؤية 429 استجابة على قاعدة البيانات أو الحاوية، حتى إذا لم يتم تحجيم RU/s إلى الحد الأقصى ل RU/s. راجع قسم معدل الطلب كبير باستخدام تحجيم تلقائي للحصول على شرح.

أحد الأسئلة الشائعة التي تنشأ هو، "لماذا أرى 429 استجابة في مقاييس Azure Monitor، ولكن لا شيء في مراقبة التطبيق الخاص بي؟" إذا أظهرت مقاييس Azure Monitor أن لديك 429 استجابة، ولكنك لم تشاهد أي استجابة في التطبيق الخاص بك، فهذا لأن بشكل افتراضي، نجحت مجموعات SDK automatically retried internally on the 429 responses لعميل Azure Cosmos DB والطلب في عمليات إعادة المحاولة اللاحقة. ونتيجة لذلك، لا يتم إرجاع رمز الحالة 429 إلى التطبيق. في هذه الحالات، يكون المعدل الإجمالي ل 429 استجابة عادة ضئيلا ويمكن تجاهله بأمان، على افتراض أن المعدل الإجمالي بين 1-5٪ وزمن الانتقال من النهاية إلى النهاية مقبول للتطبيق الخاص بك.

الخطوة 2: حدد ما إذا كان هناك قسم ساخن

ينشأ القسم الساخن عندما يستهلك مفتاح واحد أو عدد قليل من مفاتيح الأقسام المنطقية قدرًا غير متناسب من إجمالي RU / s بسبب زيادة حجم الطلب. يمكن أن يحدث هذا بسبب تصميم مفتاح القسم الذي لا يوزع الطلبات بالتساوي. ينتج عن ذلك توجيه العديد من الطلبات إلى مجموعة فرعية صغيرة من الأقسام المنطقية (التي تعني فعليا) التي تصبح "ساخنة". نظرا لأن جميع البيانات الخاصة بقسم منطقي موجودة على قسم فعلي واحد ويتم توزيع إجمالي وحدات الطلب/ الثانية بالتساوي بين الأقسام المادية، يمكن أن يؤدي القسم الساخن إلى 429 استجابة واستخدام غير فعال لمعدل النقل.

فيما يلي بعض الأمثلة على استراتيجيات التقسيم التي تؤدي إلى الأقسام الساخنة:

  • لديك حاوية تخزن بيانات جهاز إنترنت الأشياء لحمل عمل كثيف الكتابة مقسم حسب date. ستوجد جميع البيانات الخاصة بتاريخ واحد على نفس القسم المنطقي والمادي. نظرًا إلى أن جميع البيانات المكتوبة يوميًا لها نفس التاريخ، فقد ينتج عن ذلك قسم ساخن كل يوم.
    • بدلاً من ذلك، بالنسبة لهذا السيناريو، فإن مفتاح القسم مثل id (إما GUID أو معرِّف الجهاز)، أو مفتاح قسم تركيبي يجمع id و date سينتج عنه عدد أكبر من القيم وأفضل توزيع حجم الطلب.
  • لديك سيناريو متعدد المستأجرين مع حاوية مقسمة حسب tenantId. إذا كان أحد المستأجرين أكثر نشاطًا من الآخرين، فسيؤدي ذلك إلى قسم ساخن. على سبيل المثال، إذا كان أكبر مستأجر لديه 100000 مستخدم، ولكن معظم المستأجرين لديهم أقل من 10 مستخدمين، سيكون لديك قسم ساخن عند تقسيمه بواسطة tenantID.
    • بالنسبة إلى هذا السيناريو السابق، ضع في اعتبارك وجود حاوية مخصصة لأكبر مستأجر، مقسمة بواسطة خاصية أكثر دقة مثل UserId.

طريقة تحديد القسم الساخن

للتحقق مما إذا كان هناك قسم فعال، انتقل إلى Insights > معدل النقل > استهلاك RU الطبيعي (٪) بواسطة PartitionKeyRangeID . قم بتصفية إلى قاعدة بيانات وحاوية معينة.

يتم تعيين كل معرف نطاق رئيسي للقسم إلى قسم مادي واحد. في حالة وجود PartitionKeyRangeId واحد يحتوي على معدل استهلاك RU أعلى بكثير من غيره (على سبيل المثال، واحد ثابت بنسبة 100٪، والبعض الآخر بنسبة 30٪ أو أقل)، يمكن أن يكون هذا علامة على وجود قسم ساخن. تعرف على المزيد حول مقياس استهلاك RU الطبيعي .

معدل استهلاك RU من خلال مخطط PartitionKeyRangeId مع قسم سريع.

لمعرفة مفاتيح الأقسام المنطقية التي تستهلك معظم RU / s، استخدم سجلات تشخيص Azure . يلخص هذا الاستعلام النموذجي إجمالي وحدات الطلب المستهلكة في الثانية على كل مفتاح قسم منطقي.

هام

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

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

يوضح هذا النموذج الناتج أنه في دقيقة معينة، استهلك مفتاح القسم المنطقي بقيمة "Contoso" حوالي 12000 RU / ثانية، بينما استهلك مفتاح القسم المنطقي بقيمة "Fabrikam" أقل من 600 RU / ثانية. إذا كان هذا النمط ثابتًا خلال الفترة الزمنية التي حدث فيها تقييد السرعة، فإن هذا يشير إلى وجود قسم ساخن.

تستهلك مفاتيح الأقسام المنطقية معظم وحدات الطلبات في الثانية.

تلميح

في أي عبء عمل، سيكون هناك تباين طبيعي في حجم الطلب عبر الأقسام المنطقية. يجب عليك تحديد ما إذا كان القسم الساخن ناتجًا عن انحراف أساسي بسبب اختيار مفتاح القسم (الذي قد يتطلب تغيير المفتاح) أو ارتفاع مؤقت بسبب التباين الطبيعي في أنماط عبء العمل.

راجع الإرشادات حول كيفية اختيار مفتاح تقسيم جيد .

إذا كانت هناك نسبة عالية من الطلبات محدودة السعر ولا يوجد قسم مكدس:

إذا كانت هناك نسبة عالية من الطلبات محدودة السعر وكان يوجد تقسيم مكدس:

  • على المدى الطويل، للحصول على أفضل تكلفة وأداء، ضع في اعتبارك تغيير مفتاح القسم . لا يمكن تحديث مفتاح القسم في مكانه، لذلك يتطلب ذلك ترحيل البيانات إلى حاوية جديدة باستخدام مفتاح قسم مختلف. يدعم Azure Cosmos DB أداة ترحيل البيانات المباشرة لهذا الغرض.
  • على المدى القصير، يمكنك زيادة وحدات الطلب/ الثانية الإجمالية للمورد مؤقتا للسماح بمزيد من معدل النقل إلى القسم الساخن. لا يُنصح بهذا كإستراتيجية طويلة المدى؛ لأنه يؤدي إلى زيادة توفير RU / s وتكلفة أعلى.
  • على المدى القصير، يمكنك استخدام إعادة توزيع معدل النقل عبر ميزة الأقسام (معاينة) لتعيين المزيد من RU/s إلى القسم الفعلي الساخن. يوصى بذلك فقط عندما يكون القسم المادي الساخن قابلا للتنبؤ به ومتسقا.

تلميح

عند زيادة معدل النقل، ستكتمل عملية توسيع النطاق إما على الفور أو تتطلب ما يصل إلى 5-6 ساعات لتكتمل، اعتمادًا على عدد وحدات RU / s التي تريد توسيع نطاقها إليها. إذا كنت تريد معرفة أكبر عدد من وحدات RU / s التي يمكنك تعيينها دون تشغيل عملية التوسع غير المتزامن (والتي تتطلب Azure Cosmos DB لتوفير المزيد من الأقسام المادية)، فاضرب عدد PartitionKeyRangeIds المميز في 100000 رو / ثانية. على سبيل المثال، إذا كان لديك 30.000 وحدة RU / ثانية موفرة و5 أقسام مادية (6000 وحدة RU / ثانية مخصصة لكل قسم مادي)، يمكنك الزيادة إلى 50000 RU / ثانية (10000 RU / ثانية لكل قسم مادي) في عملية توسيع فورية. تتطلب الزيادة إلى > 50000 RU / ثانية عملية توسيع غير متزامنة. تعرف على المزيد حول أفضل الممارسات لتوسيع نطاق معدل النقل المقدم (RU / s) .

الخطوة 3: تحديد الطلبات التي ترجع 429 استجابة

كيفية التحقيق في الطلبات مع 429 استجابة

استخدم سجلات تشخيص Azure لتحديد الطلبات التي ترجع 429 استجابة وعدد وحدات الطلب التي استهلكتها. يتم تجميع نموذج الاستعلام هذا على مستوى الدقيقة.

هام

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

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

على سبيل المثال، يُظهر هذا الناتج النموذجي أنه في كل دقيقة، كانت نسبة 30٪ من طلبات إنشاء مستند محدودة، حيث يستهلك كل طلب في المتوسط 17 وحدة RU. الطلبات التي تُرجع رسالة الخطأ 429 في سجلات التشخيص.

استخدم مخطط سعة قاعدة بيانات Azure Cosmos

يمكنك استخدام مخطط سعة Azure Cosmos DB للتعرف على أفضل معدل نقل يتم توفيره بناءً على حجم العمل (حجم ونوع العمليات وحجم المستندات). يمكنك تخصيص الحسابات بشكل أكبر من خلال توفير بيانات نموذجية للحصول على تقدير أكثر دقة.

429 استجابة حول إنشاء طلبات المستندات أو استبدالها أو رفعها
  • بشكل افتراضي، في واجهة برمجة التطبيقات ل NoSQL، تتم فهرسة جميع الخصائص بشكل افتراضي. قم بضبط سياسة الفهرسة لفهرسة الخصائص المطلوبة فقط. سيؤدي ذلك إلى خفض وحدات الطلب المطلوبة لكل عملية إنشاء مستند، ما يقلل من احتمالية رؤية 429 استجابة أو يسمح لك بتحقيق عمليات أعلى في الثانية لنفس المقدار من RU/s المقدمة.
429 استجابة على طلبات مستند الاستعلام
429 استجابة حول تنفيذ الإجراءات المخزنة
  • الإجراءات المخزنة مخصصة للعمليات التي تتطلب معاملات كتابة عبر قيمة مفتاح القسم. لا ينصح باستخدام الإجراءات المخزنة لعدد كبير من عمليات القراءة أو الاستعلام. للحصول على أفضل أداء، يجب إجراء عمليات القراءة أو الاستعلام هذه من جانب العميل، باستخدام Azure Cosmos DB SDKs.

معدل الطلب كبير مع تحجيم تلقائي

تنطبق جميع الإرشادات الواردة في هذه المقالة على كل من معدل النقل اليدوي والتحجيم التلقائي.

عند استخدام التحجيم التلقائي، فإن السؤال الشائع الذي ينشأ هو، "هل لا يزال من الممكن رؤية 429 ردا باستخدام التحجيم التلقائي؟"

نعم. هناك سيناريوهان رئيسيان حيث يمكن أن يحدث هذا.

سيناريو 1 : عندما يتجاوز إجمالي RU / s المستهلكة الحد الأقصى لـ RU / s لقاعدة البيانات أو الحاوية، ستقلل الخدمة الطلبات وفقًا لذلك. هذا مشابه لتجاوز معدل النقل الإجمالي المتوفر يدويًّا لقاعدة البيانات أو الحاوية.

السيناريو 2: إذا كان هناك قسم ساخن، أي قيمة مفتاح القسم المنطقية التي تحتوي على كمية أعلى بشكل غير متناسب من الطلبات مقارنة بقيم مفتاح القسم الأخرى، فمن الممكن أن يتجاوز القسم المادي الأساسي ميزانيته RU/s. كأفضل ممارسة، لتجنب الأقسام المزدحمة، اختر مفتاح تقسيم جيدينتج عنه توزيع متساوٍ من التخزين ومعدل النقل على حدٍ سواء. هذا يشبه عندما يكون هناك قسم ساخن عند استخدام معدل النقل اليدوي.

على سبيل المثال، إذا حددت خيار الحد الأقصى لمعدل النقل 20000 RU / s ولديك 200 جيجابايت من التخزين مع أربعة أقسام فعلية، فيمكن قياس كل قسم مادي تلقائيًّا حتى 5000 RU / s. إذا كان هناك قسم ساخن على مفتاح قسم منطقي معين، فسترى 429 استجابة عندما يتجاوز القسم المادي الأساسي الموجود فيه 5000 RU/s، أي يتجاوز الاستخدام العادي بنسبة 100٪.

اتبع الإرشادات الواردة في الخطوة 1 و الخطوة 2 و الخطوة 3 لتصحيح هذه السيناريوهات.

هناك سؤال شائع آخر يطرح نفسه وهو، لماذا تمت تسوية استهلاك RU بنسبة 100٪، لكن المقياس التلقائي لم يتسع إلى الحد الأقصى لـ RU / s؟

يحدث هذا عادةً لأحمال العمل التي لها فترات استخدام مؤقتة أو متقطعة. عند استخدام التحجيم التلقائي، يقوم Azure Cosmos DB فقط بتحجيم RU/s إلى الحد الأقصى لمعدل النقل عندما يكون استهلاك وحدة الطلب التي تمت تسويتها 100٪ لفترة زمنية مستمرة ومستمرة في فاصل زمني مدته 5 ثوان. يتم ذلك للتأكد من أن منطق القياس سهل التكلفة للمستخدم، لأنه يضمن أن الارتفاعات اللحظية الفردية لا تؤدي إلى توسيع غير ضروري وتكلفة أعلى. عندما تكون هناك ارتفاعات مؤقتة، يتدرج النظام عادةً إلى قيمة أعلى من القيمة التي تم تحجيمها سابقًا إلى RU / s، ولكن أقل من الحد الأقصى لـ RU / s. تعرف على المزيد حول طريقة تفسير مقياس استهلاك RU المعياري باستخدام مقياس تلقائي .

معدل الحد على طلبات بيانات التعريف

يمكن أن يحدث تحديد معدل بيانات التعريف عند تنفيذ حجم كبير من عمليات بيانات التعريف على قواعد البيانات و/أو الحاويات. تشمل عمليات بيانات التعريف ما يلي:

  • إعداد حاوية أو قاعدة بيانات أو قراءتها أو تحديثها أو حذفها
  • سرد قواعد البيانات أو الحاويات في حساب Azure Cosmos DB
  • استعلام عن العروض لمعرفة معدل النقل الحالي المتوفر

هناك حد RU محجوز من قبل النظام لهذه العمليات، لذا فإن زيادة RU / s المتوفرة لقاعدة البيانات أو الحاوية لن يكون لها أي تأثير ولا يوصى بها. راجع حدود خدمة وحدة التحكم.

طريقة التحقق

انتقل إلى Insights > النظام > طلبات بيانات التعريف حسب رمز الحالة . قم بالتصفية إلى قاعدة بيانات وحاوية محددة إذا رغبت في ذلك.

طلبات بيانات التعريف حسب مخطط رمز الحالة في Insights.

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

  • استخدم مثيلات عميل Azure Cosmos DB الثابتة. عند تهيئة DocumentClient أو CosmosClient، يجلب Azure Cosmos DB SDK بيانات التعريف حول الحساب، بما في ذلك معلومات حول مستوى التناسق وقواعد البيانات والحاويات والأقسام والعروض. قد تستهلك هذه التهيئة عددًا كبيرًا من وحدات RU، ويجب إجراؤها بشكل غير منتظم. استخدم مثيل DocumentClient واحدًا واستخدمه طوال عمر تطبيقك.

  • تخزين أسماء خاصة بقواعد البيانات والحاويات. استرد أسماء قواعد البيانات والحاويات من التكوين أو خزِّنها مؤقتًا في البداية. ستؤدي مكالمات مثل ReadDatabaseAsync / ReadDocumentCollectionAsync أو CreateDatabaseQuery / CreateDocumentCollectionQuery إلى استدعاءات بيانات التعريف إلى الخدمة، والتي تستهلك من حد RU المحجوز في النظام. يجب إجراء هذه العمليات بشكل غير منتظم.

تحديد المعدل بسبب خطأ خدمة عابر

يتم إرجاع هذا الخطأ 429 عندما يواجه الطلب خطأ خدمة عابر. زيادة RU / s في قاعدة البيانات أو الحاوية لن يكون لها أي تأثير ولا يوصى بها.

إعادة محاولة الطلب. إذا استمر الخطأ لعدة دقائق، فأرسل بطاقة دعم من مدخل Microsoft Azure.

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