في الآونة الأخيرة ، يعد Elasticsearch 5.4 (ES) إصدارًا جديدًا نسبيًا. هناك العديد من المشكلات أثناء الاستخدام ، وهو صداع ، ولكن تم حل المشكلة أخيرًا.
السؤال 1: Esclient بطيئة في الحصول عليها ، ولا يمكن الحصول على العميل: فشل في إنشاء حلقة حدث للأطفال
نظرًا لأن العمل يحتاج إلى تحميل مجموعة من الملفات دون تحميل فهرس ES ، يجب عليك الحصول على اتصال ثم العمل في كل مرة تضيف فيها فهرسًا. خاصة في الدفعات الكبيرة ، من الواضح أن عدد عمليات الاستحواذ كبيرة جدًا. السبب الرئيسي لهذه المشكلة هو أننا نعمل بشكل متكرر في الحلقات. على سبيل المثال ، نحتاج إلى الحصول على 100 ملف في دفعة. من أجل تقليل وقت الحصول على عميل ES ، اعتمدنا أخيرًا حلًا ، أي تهيئة الاتصال عند بدء الخدمة ، والحصول عليها في وقت واحد ، ثم نسميها مباشرة لاحقًا. بعد تحميل ملف الدُفعة بأكمله ، يتم إضافة فهرس ES أخيرًا ، بدلاً من إضافة ملف واحد في وقت واحد. من الواضح أن هذه الطريقة لا تتطلب كل دفعة للحصول على اتصالات ، مما يحسن إلى حد كبير كفاءة التنفيذ.
أولاً ، عند بدء تشغيل الخدمة ، نهيئة عميل ES الثابت في فئة بدء التشغيل:
private elasticsearchutil elasticsearchutil = new Elasticsearchutil () ؛ عميل TransportClient الثابت العام = Elasticsearchutil.getClient () ؛
ثم نسميها مباشرة عند استخدامها:
عميل العميل = main.client ؛
هذا يمكن أن يقلل بشكل كبير من عدد الاتصالات لعميل ES ، وبالتالي تحسين الكفاءة.
رمز ES كما يلي:
TransportClient GetClient () {string [] iparr = configutil.getValue ("esip"). الانقسام ("،") ؛ الإعدادات = الإعدادات. .PUT (Constants.esclustername ، configutil.getValue ("clustername")). build () ؛ clientclient client = جديد preBuiltTransportClient (الإعدادات) ؛ لـ (string IP: iparr) {transporddress address = new inetsocketTransportAddress (inetaddresses.forstring (IP) ، 9300) ؛ client.addtransportaddresses (address) ؛} عميل الإرجاع ؛}السؤال 2: تدفق الذاكرة: java.lang.outofmemory: غير قادر على إنشاء موضوع أصلي جديد
أثناء عملية تطوير المشروع ، يعد تجاوز الذاكرة أمرًا مزعجًا للغاية. لقد واجهته أثناء استخدام ES ، وكان متكررًا للغاية ، خاصة أثناء اختبارات الإجهاد على نطاق واسع. فكرت في العديد من الطرق لتحسين ذاكرة JVM ، ولكن لم يكن هناك أي تأثير ، ولم تكن المشكلة بعد حلها. أخيرًا ، عند النظر إلى رمز المصدر ، وجدت سببًا. بالاقتران مع استثناءات الإبلاغ عن الخطأ ، وذلك بسبب إنشاء عدد كبير من مؤشرات الترابط تلقائيًا أثناء الاستخدام مع ES ، والذي تجاوز قدرة النظام ، مما أدى إلى تجاوز الذاكرة. عند دراسة التعليمات البرمجية المصدر ، وجدت أنه يمكن التحكم في عدد مؤشرات الترابط التي تم إنشاؤها بواسطة ES من خلال الإعدادات. فيما يلي العدد الافتراضي لمروح إنشاء ES:
thread_pool.generic.core = القيمة الافتراضية --- 4thread_pool.generic.max = القيمة الافتراضية-min (512 ، أقصى (رقم المعالج ، 128)) رقم المعالج = رقم معالج وحدة المعالجة المركزية
وحدة المعالجة المركزية لدينا هي 10 نوى و 40 موضوع
انطلاقًا من نتائج الحساب ، إذا تم استخدام القيمة الافتراضية ، فإن عدد مؤشرات الترابط التي يمكن أن تنشئها ES هي قيمة كبيرة ، والتي تتجاوز بكثير قدرة النظام نفسه. يقوم بشكل أساسي بضبط قيمة الإعداد. بعد التعديل ، نقوم بتغيير القيمة الافتراضية لـ ES على النحو التالي:
إعدادات الإعدادات = الإعدادات. هذه هي الإعدادات السابقة الإعدادات = الإعدادات.
بعد الاختبار ، أنشأت ES عددًا صغيرًا جدًا من الخيوط وتلبية احتياجات التطوير لدينا ، ولم تكن هناك مشكلة في تدفق الذاكرة مرة أخرى.
الملخص أعلاه للأسئلة الشائعة القائمة على Elasticsearch 5.4 هو كل المحتوى الذي أشاركه معك. آمل أن تتمكن من إعطائك مرجعًا وآمل أن تتمكن من دعم wulin.com أكثر.