Share via

استكشاف أخطاء ذاكرة تخزين مؤقت من Azure لزمن انتقال ومهلات Redis وإصلاحها

  • مقالة

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

يناقش هذا القسم استكشاف الأخطاء وإصلاحها لمشكلات زمن الوصول والمهلة التي تحدث عند الاتصال بـ Azure Cache لـ Redis.

إشعار

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

استكشاف الأخطاء وإصلاحها من جانب العميل

فيما يلي استكشاف الأخطاء وإصلاحها من جانب العميل.

انفجار حركة المرور وتكوين تجمع مؤشرات الترابط

يمكن أن تؤدي التدفقات من حركة المرور المقترنة بإعدادات ThreadPool الضعيفة إلى تأخيرات في معالجة البيانات التي تم إرسالها بالفعل بواسطة خادم Redis ولكن لم يتم استهلاكها بعد من جانب العميل. تحقق من مقياس "الأخطاء" (النوع: العملاء غير المستجيبين) للتحقق مما إذا كان بإمكان مضيفي العملاء مواكبة الارتفاع المفاجئ في حركة المرور.

راقب كيف ThreadPool تتغير الإحصاءات بمرور الوقت باستخدام مثال ThreadPoolLogger. يمكنك استخدام TimeoutException الرسائل من StackExchange.Redis لمزيد من التحقيق:

    System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

في الاستثناء السابق، هناك العديد من القضايا المثيرة للاهتمام:

  • لاحظ أنه في قسم IOCP والقسم WORKER لديك قيمة Busy أكبر من قيمة Min. يعني هذا الاختلاف أن إعدادات ThreadPool تحتاج إلى تعديل.
  • يمكنك أيضًا مشاهدة in: 64221. تشير هذه القيمة إلى أنه تم تلقي 64221 بايت في طبقة مأخذ توصيل kernel للعميل ولكن لم يقرأها التطبيق. تشير هذه القيمة إلى أنه تم استلامها 64211 بايت في طبقة مقبس kernel للعميل ولكن لم يقرأها التطبيق.

يمكنك تكوينThreadPool الإعدادات الخاصة بك للتأكد من أن مجموعة سلاسل المحادثات تتطور بسرعة في ظل سيناريوهات التتابع.

قيمة مفتاح كبيرة

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

يمكنك استخدام الأمر redis-cli --bigkeys للتحقق من وجود مفاتيح كبيرة في ذاكرة التخزين المؤقت. لمزيد من المعلومات، راجع redis-cli، واجهة سطر أوامر Redis - Redis .

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

وحدة المعالجة المركزية عالية على مضيفي العميل

يشير الاستخدام العالي لوحدة المعالجة المركزية للعميل إلى أن النظام لا يمكنه مواكبة العمل المعين له. على الرغم من أن ذاكرة التخزين المؤقت أرسلت الاستجابة بسرعة، فقد يفشل العميل في معالجة الاستجابة في الوقت المناسب. توصيتنا هي الحفاظ على وحدة المعالجة المركزية للعميل أقل من 80٪. تحقق من مقياس "الأخطاء" (النوع: UnresponsiveClients) لتحديد ما إذا كان بإمكان مضيفي العميل معالجة الاستجابات من خادم Redis في الوقت المناسب.

راقب استخدام وحدة المعالجة المركزية للعميل على مستوى النظام باستخدام المقاييس المتوفرة في مدخل Azure أو من خلال عدادات الأداء على الجهاز. احذر من مراقبة عملية وحدة المعالجة المركزية لأن عملية واحدة يمكن أن يكون لها استخدام منخفض لوحدة المعالجة المركزية ولكن وحدة المعالجة المركزية على مستوى النظام يمكن أن تكون عالية. راقب الارتفاع في استخدام وحدة المعالجة المركزية الذي يتوافق مع المهلات. قد تتسبب وحدة المعالجة المركزية العالية أيضا في قيم عالية in: XXX في TimeoutException رسائل الخطأ كما هو موضح في قسم [اندفاع حركة المرور].

إشعار

يتضمن StackExchange.Redis 1.1.603 والإصدارات الأحدث مقياسًا local-cpu في رسائل الخطأ TimeoutException. تأكد من أنك تستخدم أحدث إصدار من حزمة StackExchange.Redis NuGet. يتم إصلاح الأخطاء بانتظام في التعليمات البرمجية لجعلها أكثر قوة للمهلة. الحصول على أحدث إصدار مهم.

للتخفيف من ارتفاع استخدام وحدة المعالجة المركزية للعميل:

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

قيود النطاق الترددي للشبكة على مضيفي العميل

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

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

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

إعدادات TCP لتطبيقات العميل المستندة إلى Linux

بسبب إعدادات TCP المتفائلة في Linux، قد تواجه تطبيقات العميل المستضافة على Linux مشكلات في الاتصال. لمزيد من المعلومات، راجع إعدادات TCP لتطبيقات العميل المستضافة على Linux

انتهت مهلة إعادة المحاولة RedisSessionStateProvider

إذا كنت تستخدم RedisSessionStateProvider، فتأكد من تعيين مهلة إعادة المحاولة بشكل صحيح. يجب أن تكون قيمة retryTimeoutInMilliseconds أعلى من قيمة operationTimeoutInMilliseconds. وبخلاف ذلك، لا تحدث عمليات إعادة المحاولة. في المثال التالي، تم تعيين retryTimeoutInMilliseconds على 3000. لمزيد من المعلومات، راجع موفر حالة جلسة ASP.NET لـ Azure Cache لـ Redis وكيفية استخدام معلمات التكوين لموفر حالة الجلسة وموفر ذاكرة التخزين المؤقت للإخراج.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

استكشاف الأخطاء وإصلاحها من جانب الخادم

فيما يلي استكشاف الأخطاء وإصلاحها من جانب الخادم.

صيانة الخادم

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

لمزيد من المعلومات، راجع هذه الأقسام الأخرى:

للتحقق مما إذا كانت ذاكرة التخزين المؤقت Azure لـ Redis قد حدث تجاوز فشل أثناء حدوث المهلة، تحقق من المقياس الأخطاء. في قائمة الموارد في مدخل Azure، حدد المقاييس. ثم أنشئ مخططًا جديدًا يقيس Errors المقياس، مقسومًا على ErrorType. بمجرد إنشاء هذا المخطط، سترى عدد تجاوز الفشل.

لمزيد من المعلومات حول تجاوزات الفشل، راجع تجاوز الفشل والتصحيح لذاكرة التخزين المؤقت Azure لـ Redis.

تحميل مرتفع من الخادم

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

مقاييس المراقبة مثل تحميل الخادم. راقب الارتفاع في استخدام Server Load الذي يتوافق مع المهلات. أنشئ تنبيهات بشأن المقاييس عند تحميل الخادم لإعلامك مبكرًا بالتأثيرات المحتملة.

هناك العديد من التغييرات التي يمكنك إجراؤها للتخفيف من الحمل الكبير على الخادم:

  • تحقق مما يسبب تحميلا عاليا للخادم مثل الأوامر طويلة الأمد، المذكورة في هذه المقالة، بسبب ضغط الذاكرة العالي.
  • توسيع نطاق إلى المزيد من الأجزاء لتوزيع الحمل عبر عمليات Redis المتعددة أو الارتقاء إلى حجم ذاكرة تخزين مؤقت أكبر مع عدد أكبر من أنوية وحدة المعالجة المركزية. لمزيد من المعلومات، راجع الأسئلة المتداولة حول تخطيط Azure Cache for Redis.
  • إذا تأثر حمل عمل الإنتاج الخاص بك على ذاكرة التخزين المؤقت C1 سلبا لزمن انتقال إضافي من فحص الفيروسات، يمكنك تقليل التأثير عن طريق الدفع مقابل عرض مستوى أعلى مع عدة ذاكرات أساسية لوحدة المعالجة المركزية، مثل C2.

الارتفاعات الحادة في تحميل الخادم

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

استخدام مرتفع للذاكرة

تم نقل هذا القسم. لمزيد من المعلومات، راجع استخدام مرتفع للذاكرة.

أوامر طويلة الأمد

بعض أوامر Redis أغلى من تنفيذ أوامر أخرى. توضح وثائق أوامر Redis مدى التعقيد الزمني لكل أمر. تتم معالجة أوامر Redis بخيوط مفردة. أي أمر يستغرق وقتًا طويلاً للتشغيل يمكن أن يحجب جميع الأوامر الأخرى التي تأتي بعده.

راجع الأوامر التي تصدرها لخادم Redis لفهم تأثيرات أدائها. على سبيل المثال، غالبًا ما يتم استخدام الأمر KEYS دون معرفة أنها عملية O (N). يمكنك تجنب KEYS باستخدام SCAN لتقليل ارتفاعات وحدة المعالجة المركزية.

باستخدام الأمر SLOWLOG GET، يمكنك قياس الأوامر باهظة الثمن التي يتم تنفيذها على الخادم.

يمكن للعملاء استخدام وحدة تحكم لتشغيل أوامر Redis هذه للتحقيق في الأوامر طويلة الأمد والمكلفة.

  • يتم استخدام SLOWLOG لقراءة وإعادة تعيين سجل استعلامات Redis البطيئة. يمكن استخدامه لفحص الأوامر التي تعمل لفترة طويلة من جانب العميل. إن Redis Slow Log هو نظام لتسجيل الاستعلامات التي تجاوزت وقت التنفيذ المحدد. لا يتضمن وقت التنفيذ عمليات الإدخال/الإخراج مثل التحدث مع العميل وإرسال الرد وما إلى ذلك، ولكن فقط الوقت اللازم لتنفيذ الأمر فعليا. يمكن للعملاء قياس/تسجيل الأوامر باهظة الثمن التي يتم تنفيذها على خادم Redis الخاص بهم باستخدام SLOWLOG الأمر .
  • MONITOR هو أمر تصحيح أخطاء يقوم ببث كل أمر تمت معالجته بواسطة خادم Redis. يمكن أن يساعد في فهم ما يحدث لقاعدة البيانات. هذا الأمر متطلب ويمكن أن يؤثر سلبًا على الأداء. يمكن أن يؤدي إلى تدهور الأداء.
  • INFO - يعرض الأمر معلومات وإحصاءات حول الخادم بتنسيق يسهل تحليله بواسطة أجهزة الكمبيوتر ويسهل قراءته بواسطة البشر. في هذه الحالة، قد يكون قسم وحدة المعالجة المركزية مفيدًا للتحقق من استخدام وحدة المعالجة المركزية. يشير تحميل الخادم الذي يبلغ 100 (الحد الأقصى للقيمة) إلى أن خادم Redis كان مشغولا طوال الوقت ولم يكن خاملا أبدا عند معالجة الطلبات.

عينة الإخراج:

# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1
  • قائمة العملاء - تعرض معلومات وإحصاءات حول خادم اتصالات العميل بتنسيق يمكن للبشر قراءته في الغالب.

قيود النطاق الترددي للشبكة

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

يمكن استخدام مقاييس "قراءة ذاكرة التخزين المؤقت" و"كتابة ذاكرة التخزين المؤقت" لمعرفة مقدار النطاق الترددي المستخدم من جانب الخادم. يمكنك عرض هذه المقاييس في المدخل. أنشئ تنبيهات بشأن مقاييس مثل قراءة ذاكرة التخزين المؤقت أو كتابة ذاكرة التخزين المؤقت ليتم إعلامك مبكرًا بالتأثيرات المحتملة.

للتخفيف من المواقف التي يكون فيها استخدام النطاق الترددي للشبكة قريبًا من السعة القصوى:

استثناءات مهلة StackExchange.Redis

لمزيدٍ من المعلومات المحددة لمعالجة المهلات عند استخدام StackExchange.Redis، راجع التحقيق في استثناءات المهلة في StackExchange.Redis.

المحتوى ذو الصلة