Elasticsearch / دليل حلول تحريري
تشخيص البحث البطيء ورفض طلبات الذاكرة
صنّف تكلفة الطلب والضغط على الموارد، من دون تعطيل القواطع أو إخفاء أن الاستجابة غير مكتملة.
قاعدة معرفة للقراءة فقط · بلا تعليقات عامة
تعرّف على الأعراض
يزداد زمن البحث في المقتنيات مع التزامن، أو يبلغ تجميع circuit_breaking_exception أوtoo_many_buckets_exception، أو يتلقى العملاء رفض تنفيذ. وقد يعيد الطلب بعض النتائج مع timed_out أو أجزاء فاشلة. التقط فئة الطلب الدقيقة وحد القياس، قبل تسمية كل عرض مهلة خادم.
افهم الأسباب المحتملة
- تتنافس الإزاحات العميقة وحاويات المفاتيح الكثيرة وتوسع nested والسكربتات وجلب مصدر واسع والإدخال المتزامن على موارد محدودة. تحمي القواطع احتياجات ذاكرة مختارة، بينما تعبر طوابير التنفيذ عن ضغط القبول. لا يضيف رفع حد أو حلقة إعادة سريعة سعة للمعالج أو القرص أو الذاكرة.
افصل اكتمال الرد عن سرعته
افحص timed_out وإخفاقات الأجزاء وأخطاء العناصر وrelation في العدد الإجمالي مع الزمن المنقضي. ليست قائمة نتائج غير خالية دليلاً على إجابة كاملة، ولا ينبغي عرض حد أدنى للأعداد كأنه دقيق. حدد هل يقع التأخير في معالجة الخادم أم نقل الشبكة أم فك تسلسل الاستجابة في العميل. احتفظ باستعلام ومعلمات ممثلة لكل فئة حمل، بدلاً من مقارنة طلبات غير مترابطة. احجب نص الزوار وحقول المستندات الحساسة من الأدلة المشتركة. ولا تحتاج معرفة دلالة الطلب المقصودة إلى إجراء اختبار حمل.
أزل ما لا يحتاجه المنتج
راجع عمق الصفحة وحقول المصدر والعد الإجمالي الدقيق واتساع التجميعات المطلوبة. يعيد المثال المحدود المعرّفات والعناوين فقط، ولا يعد النتائج إجمالياً. يصلح ذلك فقط إذا قبلت الواجهة هذا العقد. إذا احتاج المستخدمون كل مفاتيح الفئات، فاستخدم اجتيازاً كاملاً خضع للمراجعة، لا زيادة حجم terms إلى ما لا نهاية. وإذا احتاجوا جانب أهم خمس فئات فقط، فاحتفظ ببيانات التقريب، ولا تصف النتيجة بأنها جرد خضع للتدقيق.
{"size":10,"track_total_hits":false,"query":{"term":{"status":"displayed"}},"_source":["artifact_id","title"],"sort":[{"artifact_id":"asc"}]}هذا عقد استجابة أضيق، وليس إثباتاً لتحسن مقاس. يفترض المثال أن artifact_id وstatus حقلا keyword.
استخدم الرفض دليلاً للضغط العكسي
احتفظ بالسبب التفصيلي للقاطع أو الرفض والقياسات المعتمدة في الوقت نفسه. لا تعطل قاطعاً لمجرد إخفاء الخطأ؛ فالتتبع الذي يقدمه حماية غير كاملة أصلاً. خفّض التزامن المعروض، وأعد العمل المؤهل الذي لا يكرر الأثر فقط مع تأخير محدود. يوضح النموذج المحلي تضاعف الحمولات الموجودة في الوقت نفسه، لكنه يستبعد كل كلفة المحرك الإضافية. ولا يستطيع تحديد حجم عقدة أو تبرير تغيير الكومة. احسب الإدخال والتعافي عند تفسير قياس زمن بحث منفرد.
{"request_payload_mib":6,"in_flight_requests":5,"payload_exposure_mib":30,"excluded":["parsed structures","engine state","responses"]}هذا نموذج ضرب محلي: 6 × 5 = 30 MiB. وليس إعداد Elasticsearch أو قياساً لاستخدام الكومة.
اختر فرضية أداء تدعمها الأدلة
افحص الأدلة المصرح بها عن المعالج وضغط الكومة وجمع الذاكرة والقرص وذاكرة نظام الملفات والانتظار وتوزيع الأجزاء. استخدم Profile لطلبات اصطناعية مختارة فقط عندما يكون ذلك معتمداً، مع تذكر تكلفة التشخيص وحدود نطاقه. يحتاج الاستعلام الثقيل بالسكربتات والاستجابة الضخمة والقرص المشغول بالتعافي إلى علاجات مختلفة. قارن طلبات ممثلة بعد تغيير مبرر واحد، واحفظ صحة الملاءمة والأعداد. لا تنطبق ضوابط عقد النشر الذاتي مباشرة على Serverless، ولا يوجد حجم جزء أو نسبة كومة أو تزامن طلبات صحيح للجميع.
تحقق من نجاح الإصلاح
تحقق من مجتمع الطلبات نفسه وعند حد الملاحظة نفسه، بما يشمل معالجة النتائج الجزئية ومحاسبة رفض كل عنصر. قارن العمل المفيد المقبول، لا إنتاجية المرسل وحدها. أجرى الدليل فحص JSON وحسابات محلية فقط، من دون قياس عنقود أو تغيير إعداد.
امنع تكرار المشكلة
- انشر قوالب استعلام محدودة، وميزانيات للصفحات والتجميع، وسلوكاً صريحاً للنتائج الناقصة، وآلية ضغط عكسي للمنتج. راجع التكلفة والملاءمة معاً كلما وسعت ميزة بحث جديدة مجموعة المرشحين أو حجم الاستجابة.