200TB+ የላስቲክ ፍለጋ ክላስተር

ብዙ ሰዎች ከ Elasticsearch ጋር ይታገላሉ። ግን ምዝግብ ማስታወሻዎችን "በተለይ ትልቅ መጠን" ለማከማቸት ለመጠቀም ሲፈልጉ ምን ይከሰታል? እና ከበርካታ የመረጃ ማእከሎች ውስጥ የትኛውንም ውድቀት ማየት ህመም የለውም? ምን ዓይነት አርክቴክቸር መስራት አለብህ፣ እና በምን አይነት ወጥመዶች ላይ ትሰናከላለህ?

እኛ Odnoklassniki የሎግ ማኔጅመንትን ጉዳይ ለመፍታት elasticsearchን ለመጠቀም ወስነናል፣ እና አሁን ከሀብር ጋር ያለንን ልምድ እናካፍላለን፡ ስለ አርክቴክቸርም ሆነ ስለ ወጥመዶች።

እኔ Pyotr Zaitsev ነኝ፣ በኦድኖክላሲኒኪ የስርዓት አስተዳዳሪ ሆኜ እሰራለሁ። ከዚያ በፊት፣ እኔ ደግሞ አስተዳዳሪ ነበርኩ፣ ከማንቲኮር ፍለጋ፣ ከስፊንክስ ፍለጋ፣ ከElasticsearch ጋር እሰራ ነበር። ምናልባት፣ ሌላ ... ፍለጋ ከታየ፣ እኔም ከእሱ ጋር እሰራለሁ። እኔም በበጎ ፍቃድ በበርካታ ክፍት ምንጭ ፕሮጀክቶች ላይ እሳተፋለሁ።

ወደ Odnoklassniki ስመጣ በግዴለሽነት በቃለ መጠይቁ ላይ ከElasticsearch ጋር መስራት እንደምችል ተናግሬ ነበር። ስራውን ከጨረስኩ እና ቀላል ስራዎችን ከጨረስኩ በኋላ በዚያን ጊዜ የነበረውን የሎግ ማኔጅመንት ሲስተም የማሻሻል ትልቅ ስራ ተሰጠኝ።

መስፈርቶች

የስርዓት መስፈርቶች እንደሚከተለው ተዘጋጅተዋል-

• ግሬይሎግ እንደ የፊት ግንባር ጥቅም ላይ መዋል ነበረበት። ኩባንያው ይህን ምርት የመጠቀም ልምድ ስላለው ፕሮግራመሮች እና ሞካሪዎች ያውቁታል, ለእነሱ የተለመደ እና ምቹ ነበር.
• የውሂብ መጠን: በአማካይ ከ50-80 ሺህ መልእክቶች በሰከንድ, ነገር ግን አንድ ነገር ከተበላሸ, ትራፊኩ በምንም አይገደብም, በሰከንድ 2-3 ሚሊዮን መስመሮች ሊሆን ይችላል.
• የፍለጋ መጠይቆችን ለሂደቱ ፍጥነት የሚያስፈልጉትን መስፈርቶች ከደንበኞች ጋር ከተነጋገርን ፣ እንዲህ ዓይነቱን ስርዓት የሚጠቀሙበት የተለመደው ንድፍ ይህ መሆኑን ተገነዘብን-ሰዎች ላለፉት ሁለት ቀናት የመተግበሪያቸውን ምዝግብ ማስታወሻዎች እየፈለጉ ነው እና ከአንድ በላይ መጠበቅ አይፈልጉም። ሁለተኛ ለተዘጋጀው ጥያቄ ውጤት።
• አስተዳዳሪዎቹ አሰራሩ እንዴት እንደሚሰራ በጥልቀት እንዲመረምሩ ሳያስፈልግ አስፈላጊ ከሆነ በቀላሉ ሊሰፋ የሚችል እንዲሆን አጥብቀው ጠይቀዋል።
• ስለዚህ እነዚህ ስርዓቶች በየጊዜው የሚያስፈልጋቸው ብቸኛው የጥገና ሥራ አንዳንድ ሃርድዌር መቀየር ነው.
• በተጨማሪም Odnoklassniki በጣም ጥሩ ቴክኒካል ባህል አለው፡ ማንኛውም የምንጀምረው አገልግሎት ከውሂብ ማእከል ውድቀት (በድንገተኛ፣ ያልታቀደ እና በፍጹም በማንኛውም ጊዜ) መትረፍ አለበት።

በዚህ ፕሮጀክት ትግበራ ውስጥ ያለው የመጨረሻው መስፈርት የበለጠ ዋጋ ያስከፍለናል, ይህም በበለጠ ዝርዝር ውስጥ እናገራለሁ.

ረቡዕ

በአራት የመረጃ ማዕከሎች ውስጥ እንሰራለን, የ Elasticsearch ዳታ ኖዶች በሦስት ብቻ ሊቀመጡ ይችላሉ (በተወሰኑ ቴክኒካዊ ያልሆኑ ምክንያቶች).

እነዚህ አራት የመረጃ ማዕከሎች በግምት 18 ሺህ የተለያዩ የምዝግብ ማስታወሻ ምንጮችን ይይዛሉ - ሃርድዌር ፣ ኮንቴይነሮች ፣ ምናባዊ ማሽኖች።

ጠቃሚ ባህሪ: ክላስተር በመያዣዎች ውስጥ ይጀምራል ፖድማን በአካላዊ ማሽኖች ላይ ሳይሆን በ ላይ የራሱ የደመና ምርት አንድ-ደመና. ኮንቴይነሮች ከ 2Ghz v2.0 ጋር የሚመሳሰሉ 4 ኮርሞች ዋስትና ተሰጥቷቸዋል፣ ቀሪዎቹን ኮሮች ስራ ፈት ከሆኑ እንደገና ጥቅም ላይ ሊውሉ ይችላሉ።

በሌላ ቃል:

ቶፖሎጂ

የመፍትሄውን አጠቃላይ ቅርፅ መጀመሪያ ላይ እንደሚከተለው አየሁ።

• 3-4 ቪ.አይ.ፒ.ዎች ከግራይሎግ ጎራ A-መዝገብ ጀርባ ናቸው፣ ይህ ምዝግብ ማስታወሻዎቹ የሚላኩበት አድራሻ ነው።
• እያንዳንዱ ቪአይፒ የኤልቪኤስ ሚዛናዊ ነው።
• ከእሱ በኋላ, ምዝግቦቹ ወደ ግሬይሎግ ባትሪ ይሄዳሉ, አንዳንድ መረጃዎች በ GELF ቅርጸት, አንዳንዶቹ በ syslog ቅርጸት ናቸው.
• ከዚያ ይህ ሁሉ በ Elasticsearch አስተባባሪዎች ባትሪ ላይ በትልልቅ ስብስቦች ተጽፏል.
• እና እነሱ, በተራው, ወደ ተዛማጅ የውሂብ አንጓዎች ጥያቄዎችን ይፃፉ እና ያንብቡ.

ቃላት ትርጓሜ

ምናልባት ሁሉም ሰው የቃላቶቹን ዝርዝር በዝርዝር አይረዳውም, ስለዚህ ትንሽ ላቆይበት እፈልጋለሁ.

Elasticsearch በርካታ አይነት አንጓዎች አሉት - ዋና, አስተባባሪ, የውሂብ ኖድ. ለተለያዩ የሎግ ትራንስፎርሜሽን እና በተለያዩ ዘለላዎች መካከል ግንኙነት ለማድረግ ሌሎች ሁለት ዓይነቶች አሉ ነገርግን የተጠቀምነው የተዘረዘሩትን ብቻ ነው።

ባለቤት
በክላስተር ውስጥ ያሉትን ሁሉንም አንጓዎች ፒንግ ያደርጋል፣ ወቅታዊ የክላስተር ካርታ ይይዛል እና በአንጓዎች መካከል ያሰራጫል፣ የክስተት አመክንዮ ያስኬዳል፣ እና የተለያዩ አይነት የክላስተር ሰፊ የቤት አያያዝ ስራዎችን ይሰራል።

አስተባባሪ
አንድ ነጠላ ተግባር ያከናውናል፡ የደንበኞችን የማንበብ ወይም የመጻፍ ጥያቄዎችን ይቀበላል እና ይህንን ትራፊክ ያካሂዳል። የመጻፍ ጥያቄ ካለ፣ ምናልባት፣ የትኛውን ተዛማጅ መረጃ ጠቋሚ ውስጥ ማስገባት እንዳለበት ጌታን ይጠይቃል እና ጥያቄውን የበለጠ ያዞራል።

የውሂብ አንጓ
መረጃን ያከማቻል፣ ከውጭ የሚመጡ የፍለጋ መጠይቆችን ያከናውናል እና በላዩ ላይ በሚገኙ ፍርስራሾች ላይ ስራዎችን ያከናውናል።

ሽበት
ይህ በኤልኬ ቁልል ውስጥ የኪባና ከሎግስታሽ ጋር እንደ ውህደት ያለ ነገር ነው። ግሬይሎግ ሁለቱንም UI እና የሎግ ማቀነባበሪያ ቧንቧን ያጣምራል። በመከለያው ስር፣ ግሬይሎግ ከግሬሎግ ጋር እንደ ክላስተር ግንኙነት የሚሰጡትን Kafka እና Zookeeperን ያካሂዳል። Elasticsearch የማይገኝ ከሆነ ግራይሎግ መሸጎጫ (ካፍካ) ይችላል እና ያልተሳካ የማንበብ እና የመፃፍ ጥያቄዎችን ይደግማል፣ ቡድን ይመድባል እና ምዝግብ ማስታወሻዎችን በተገለጹ ህጎች መሰረት ምልክት ያድርጉ። ልክ እንደ ሎግስታሽ፣ ግሬይሎግ ረድፎችን ወደ Elasticsearch ከመጻፍዎ በፊት የመቀየር ተግባር አለው።

በተጨማሪም ግሬይሎግ በአንድ የElasticsearch node ላይ በመመስረት ሙሉውን ክላስተር ካርታ ለማግኘት እና በተለየ መለያ ለማጣራት የሚያስችል አብሮ የተሰራ የአገልግሎት ግኝት አለው፣ ይህም ጥያቄዎችን ወደ ተወሰኑ ኮንቴይነሮች ለመምራት ያስችላል።

በእይታ እንደዚህ ያለ ነገር ይመስላል።

ይህ የአንድ የተወሰነ ምሳሌ ቅጽበታዊ ገጽ እይታ ነው። እዚህ በፍለጋ መጠይቁ ላይ በመመስረት ሂስቶግራም እንገነባለን እና ተዛማጅ ረድፎችን እናሳያለን።

ማውጫዎች

ወደ ስርዓቱ አርክቴክቸር ስንመለስ፣ ሁሉም በትክክል እንዲሰራ የኢንዴክስ ሞዴሉን እንዴት እንደገነባን በበለጠ ዝርዝር ውስጥ ማስቀመጥ እፈልጋለሁ።

ከላይ ባለው ሥዕል፣ ይህ ዝቅተኛው ደረጃ ነው፡ Elasticsearch data nodes።

መረጃ ጠቋሚ Elasticsearch shards የተሰራ ትልቅ ምናባዊ አካል ነው። በእራሱ ውስጥ, እያንዳንዱ ሾጣጣዎች ከሉሴን ኢንዴክስ አይበልጥም. እና እያንዳንዱ የሉሴን ኢንዴክስ በተራው አንድ ወይም ከዚያ በላይ ክፍሎችን ያካትታል.

ንድፍ በሚሠራበት ጊዜ የንባብ ፍጥነትን በከፍተኛ መጠን ለማሟላት የሚያስፈልገውን መስፈርት በመረጃ ኖዶች ላይ "ማሰራጨት" እንደሚያስፈልገን አስበው ነበር.

ይህ በመረጃ ጠቋሚ (በቅጂዎች) የሻርዶች ቁጥር ከውሂብ አንጓዎች ቁጥር ጋር በጥብቅ እኩል መሆን አለበት. በመጀመሪያ፣ ከሁለት ጋር እኩል የሆነ የማባዛት ሁኔታን ለማረጋገጥ (ይህም የክላስተር ግማሹን ልናጣ እንችላለን)። እና፣ ሁለተኛ፣ ቢያንስ በግማሽ ክላስተር ላይ የማንበብ እና የመፃፍ ጥያቄዎችን ለማስኬድ።

መጀመሪያ የማከማቻ ጊዜውን እንደ 30 ቀናት ወስነናል።

የሻርዶች ስርጭት በስዕላዊ መልኩ እንደሚከተለው ሊወከል ይችላል.

ሙሉው ጥቁር ግራጫ ሬክታንግል መረጃ ጠቋሚ ነው። በእሱ ውስጥ ያለው የግራ ቀይ ካሬ ቀዳሚው ሸርተቴ ነው, በመረጃ ጠቋሚ ውስጥ የመጀመሪያው. እና ሰማያዊው ካሬ የተባዛ ሸርተቴ ነው. በተለያዩ የመረጃ ማዕከሎች ውስጥ ይገኛሉ.

ሌላ ሸርተቴ ስንጨምር ወደ ሶስተኛው የመረጃ ማዕከል ይሄዳል። እና ፣ በመጨረሻ ፣ ይህንን መዋቅር እናገኛለን ፣ ይህም የውሂብ ወጥነት ሳያጠፋ ዲሲን ማጣት ያስችላል።

የኢንዴክሶች ሽክርክሪት, ማለትም. አዲስ ኢንዴክስ በመፍጠር እና በጣም የቆየውን መሰረዝ ከ 48 ሰአታት ጋር እኩል አደረግን (በመረጃ ጠቋሚ አጠቃቀሙ ንድፍ መሠረት የመጨረሻዎቹ 48 ሰዓታት በጣም ብዙ ጊዜ ይፈለጋሉ)።

ይህ የመረጃ ጠቋሚ የማዞሪያ ክፍተት በሚከተሉት ምክንያቶች የተነሳ ነው.

የፍለጋ ጥያቄ በአንድ የተወሰነ የውሂብ መስቀለኛ መንገድ ላይ ሲደርስ፣ ከአፈጻጸም እይታ አንጻር ሲታይ፣ መጠኑ ከኖድ ሂፕ መጠን ጋር የሚወዳደር ከሆነ፣ አንድ ሸርተቴ ሲጠየቅ የበለጠ ትርፋማ ይሆናል። ይህ የመረጃ ጠቋሚውን "ሙቅ" ክፍል በክምር ውስጥ እንዲቆዩ እና በፍጥነት እንዲደርሱበት ያስችልዎታል. ብዙ "ሙቅ ክፍሎች" ሲኖሩ, የመረጃ ጠቋሚ ፍለጋ ፍጥነት ይቀንሳል.

አንድ መስቀለኛ መንገድ የፍለጋ መጠይቁን በአንድ ሻርድ ላይ ማከናወን ሲጀምር፣ ከአካላዊው ማሽን ሃይፐርትሬዲንግ ኮሮች ጋር እኩል የሆኑ በርካታ ክሮች ይመድባል። የፍለጋ መጠይቅ ብዙ ቁጥር ያላቸውን ሻርዶች ላይ ተጽእኖ ካደረገ, ከዚያም የክሮች ብዛት በተመጣጣኝ መጠን ያድጋል. ይህ በፍለጋ ፍጥነት ላይ አሉታዊ ተጽእኖ ያሳድራል እና የአዳዲስ መረጃዎችን መረጃ ጠቋሚ ላይ አሉታዊ ተጽዕኖ ያሳርፋል.

አስፈላጊውን የፍለጋ መዘግየት ለማቅረብ, ኤስኤስዲ ለመጠቀም ወሰንን. ጥያቄዎችን በፍጥነት ለማስኬድ እነዚህን ኮንቴይነሮች የሚያስተናግዱ ማሽኖች ቢያንስ 56 ኮሮች ሊኖራቸው ይገባል። የ56 አኃዝ Elasticsearch በሚሠራበት ጊዜ የሚያመነጨውን የክሮች ብዛት የሚወስን እንደ ሁኔታዊ በቂ እሴት ተመርጧል። በ Elasitcsearch ውስጥ ፣ ብዙ የክር ገንዳ መለኪያዎች በቀጥታ በተገኙት ኮሮች ብዛት ላይ ይወሰናሉ ፣ ይህ ደግሞ “ትንሽ ኮሮች - ብዙ አንጓዎች” በሚለው መርህ በክላስተር ውስጥ የሚፈለጉትን የአንጓዎች ብዛት በቀጥታ ይነካል ።

በውጤቱም, በአማካይ አንድ ሻርድ ወደ 20 ጊጋባይት ይመዝናል, እና በአንድ ኢንዴክስ 1 ሼዶች አሉ. በዚህ መሠረት በየ 360 ሰዓቱ አንድ ጊዜ ካዞርናቸው 48 ቱ አሉን ማለት ነው። እያንዳንዱ መረጃ ጠቋሚ ለ 15 ቀናት ውሂብ ይዟል.

የውሂብ መፃፍ እና የንባብ ወረዳዎች

በዚህ ስርዓት ውስጥ ውሂብ እንዴት እንደሚመዘገብ እንወቅ።

አንዳንድ ጥያቄ ከግሬይሎግ ወደ አስተባባሪው ደረሰ እንበል። ለምሳሌ, 2-3 ሺህ ረድፎችን ለመጠቆም እንፈልጋለን.

አስተባባሪው፣ ከግሬይሎግ የቀረበለትን ጥያቄ ጌታውን እንዲህ ሲል ጠየቀው፡- “በመረጃ ጠቋሚ ጥያቄው ላይ በተለይ ኢንዴክስ ጠቁመን ነበር፣ ነገር ግን የትኛው ሻርድ እንደሚፃፍ አልተገለጸም” ሲል ጌታውን ጠየቀው።

ጌታው “ይህን መረጃ ወደ ሻርድ ቁጥር 71 ፃፈው” ሲል ምላሽ ይሰጣል ፣ ከዚያ በኋላ በቀጥታ ወደ ሚመለከተው የመረጃ መስቀለኛ መንገድ ይላካል ፣ ዋናው-shard ቁጥር 71 ወደሚገኝበት።

ከዚያ በኋላ የግብይት ምዝግብ ማስታወሻው በሌላ የውሂብ ማእከል ውስጥ ወደሚገኘው ቅጂ-ሻርድ ይደገማል።

የፍለጋ ጥያቄ ከግሬይሎግ ወደ አስተባባሪው ይደርሳል። አስተባባሪው በመረጃ ጠቋሚው መሰረት አቅጣጫውን ያዞረዋል፣ Elasticsearch ደግሞ የዙር-ሮቢን መርህ በመጠቀም በአንደኛ ደረጃ-shard እና replica-shard መካከል ጥያቄዎችን ያሰራጫል።

የ 180 ኖዶች እኩል ያልሆነ ምላሽ ይሰጣሉ, እና ምላሽ በሚሰጡበት ጊዜ አስተባባሪው ቀደም ሲል በፈጣን የውሂብ ኖዶች "የተተፉ" መረጃዎችን እያከማቸ ነው. ከዚህ በኋላ, ሁሉም መረጃዎች ሲደርሱ, ወይም ጥያቄው የጊዜ ማብቂያ ላይ ሲደርስ, ሁሉንም ነገር በቀጥታ ለደንበኛው ይሰጣል.

ይህ አጠቃላይ ስርዓት በአማካኝ ላለፉት 48 ሰአታት የፍለጋ መጠይቆችን በ300-400ሚሴ ውስጥ ያስኬዳል፣ እነዚያን መጠይቆች ከዋና ምልክት ጋር ሳያካትት።

Elasticsearch ያላቸው አበቦች፡ ጃቫ ማዋቀር

ሁሉም ነገር መጀመሪያ በምንፈልገው መንገድ እንዲሰራ፣ በክላስተር ውስጥ ያሉትን የተለያዩ ነገሮችን በማረም በጣም ረጅም ጊዜ አሳልፈናል።

የተገኙት የችግሮች የመጀመሪያ ክፍል በElasticsearch ውስጥ ጃቫ በነባሪ ከተዋቀረበት መንገድ ጋር የተያያዘ ነው።

ችግር አንድ
በጣም ብዙ ሪፖርቶችን አይተናል በሉሴን ደረጃ፣ የበስተጀርባ ስራዎች በሚሰሩበት ጊዜ፣ የሉሴን ክፍል ውህደቶች በስህተት ይወድቃሉ። በተመሳሳይ ጊዜ, ይህ OutOfMemoryError ስህተት መሆኑን በምዝግብ ማስታወሻዎች ውስጥ ግልጽ ነበር. ከቴሌሜትሪ እንደተመለከትነው ዳሌው ነፃ ነው፣ እና ይህ ቀዶ ጥገና ለምን እንዳልተሳካ ግልጽ አልነበረም።

የሉሴን ኢንዴክስ ውህደቶች ከዳሌው ውጭ መከሰታቸው ታወቀ። እና ኮንቴይነሮች ከሚጠቀሙት ሀብቶች አንፃር በጣም የተገደቡ ናቸው። ከእነዚህ ሃብቶች ውስጥ ክምር ብቻ ሊገባ ይችላል (የሂፕ መጠን ዋጋው በግምት ከ RAM ጋር እኩል ነበር) እና አንዳንድ ከቁልል ውጪ የሚሰሩ ስራዎች በማህደረ ትውስታ ድልድል ስህተት ምክንያት ከገደቡ በፊት ከ ~ 500ሜባ ጋር የማይጣጣሙ ከሆነ ወድቀዋል።

ማስተካከያው በጣም ቀላል ነበር: ለመያዣው ያለው የ RAM መጠን ጨምሯል, ከዚያ በኋላ እንደዚህ አይነት ችግሮች እንኳን እንደነበሩ ረሳን.

ችግር ሁለት
ክላስተር ከተጀመረ ከ4-5 ቀናት በኋላ የመረጃ ኖዶች በየጊዜው ከጥቅሉ ውስጥ መውደቅ እና ከ10-20 ሰከንድ በኋላ ማስገባት እንደጀመሩ አስተውለናል።

ማጣራት ስንጀምር፣ በ Elasticsearch ውስጥ ያለው ይህ ከቁልል ውጪ ያለው ማህደረ ትውስታ በምንም መንገድ ቁጥጥር እንደማይደረግ ታወቀ። ለኮንቴይነር ተጨማሪ ማህደረ ትውስታን ስንሰጥ, ቀጥታ ማጠራቀሚያ ገንዳዎችን በተለያዩ መረጃዎች መሙላት የቻልነው እና ግልጽ የሆነው ጂሲ ከ Elasticsearch ከተጀመረ በኋላ ነው.

በአንዳንድ አጋጣሚዎች ይህ ክዋኔ በጣም ረጅም ጊዜ የፈጀ ሲሆን በዚህ ጊዜ ክላስተር ይህንን መስቀለኛ መንገድ እንደ ወጣ ምልክት ማድረግ ችሏል። ይህ ችግር በደንብ ይገለጻል እዚህ.

መፍትሄው እንደሚከተለው ነበር፡ ለነዚህ ኦፕሬሽኖች የጃቫን ከፍተኛ ማህደረ ትውስታን ከቁልል ውጭ የመጠቀም አቅሙን ገድበናል። በ16 ጊጋባይት (-XX:MaxDirectMemorySize=16g) ገድበነዋል፣ ይህም ግልጽ ጂሲ ብዙ ጊዜ መጠራቱን እና በጣም በፍጥነት መሰራቱን፣ በዚህም ክላስተርን አለመረጋጋት አያመጣም።

ችግር ሶስት
"በጣም ባልተጠበቀ ጊዜ ክላስተርን ለቀው የሚወጡ አንጓዎች" ችግሮች አብቅተዋል ብለው ካሰቡ ተሳስተሃል።

ስራውን በመረጃ ጠቋሚዎች ስናዋቅር ኤምኤምፒኤፍን መረጥን። የፍለጋ ጊዜን ይቀንሱ ከትልቅ ክፍልፋይ ጋር ትኩስ ሻርዶች ላይ. ይህ በጣም ስህተት ነበር፣ ምክንያቱም mmapfs ን ሲጠቀሙ ፋይሉ ወደ RAM ይገለጻል እና ከዚያ ከተሰራው ፋይል ጋር እንሰራለን። በዚህ ምክንያት ጂሲ በማመልከቻው ውስጥ ያሉትን ክሮች ለማቆም ሲሞክር ወደ ሴፍኑ ቦታ ለረጅም ጊዜ እንሄዳለን እና ወደ እሱ በሚወስደው መንገድ ላይ አፕሊኬሽኑ በሕይወት ስለመኖሩ ጌታው ላቀረበው ጥያቄ ምላሽ መስጠቱን ያቆማል ። . በዚህ መሠረት, ጌታው መስቀለኛ መንገድ ከአሁን በኋላ በክላስተር ውስጥ እንደሌለ ያምናል. ከዚህ በኋላ, ከ5-10 ሰከንድ በኋላ, የቆሻሻ አሰባሳቢው ይሠራል, መስቀለኛ መንገድ ወደ ህይወት ይመጣል, እንደገና ወደ ክላስተር ውስጥ ይገባል እና ሸርቆችን መጀመር ይጀምራል. ሁሉም ነገር ልክ እንደ “እኛ የሚገባን ምርት” ተሰምቶት ነበር እናም ለከባድ ነገር ተስማሚ አልነበረም።

ይህንን ባህሪ ለማስወገድ መጀመሪያ ወደ መደበኛ ኒዮፍስ ቀይረናል፣ እና ከአምስተኛው የላስቲክ ስሪቶች ወደ ስድስተኛው ስንሸጋገር፣ ይህ ችግር እንደገና ያልዳበረበትን ጅብሪድፍስ ሞክረናል። ስለ ማከማቻ ዓይነቶች የበለጠ ማንበብ ይችላሉ። እዚህ.

ችግር አራት
ከዚያም ለሪከርድ ጊዜ የታከምነው ሌላ በጣም አስደሳች ችግር ነበር። ለ2-3 ወራት ያህል ያዝነው ምክንያቱም ንድፉ ሙሉ በሙሉ ለመረዳት የማይቻል ነበር።

አንዳንድ ጊዜ አስተባባሪዎቻችን አብዛኛውን ጊዜ ከምሳ በኋላ ወደ ሙሉ ጂሲ ይሄዱ ነበር እና ከዚያ አይመለሱም። በተመሳሳይ ጊዜ, የጂ.ሲ.ሲ መዘግየትን በሚመዘግብበት ጊዜ, እንደዚህ ይመስላል: ሁሉም ነገር በጥሩ ሁኔታ, ደህና, ደህና, እና በድንገት ሁሉም ነገር በጣም መጥፎ እየሆነ ነው.

መጀመሪያ ላይ አስተባባሪውን ከስራ ሁነታ የሚያወጣውን አይነት ጥያቄ የሚያስነሳ ክፉ ተጠቃሚ እንዳለን አሰብን። ምን እየተፈጠረ እንዳለ ለማወቅ በመሞከር ለረጅም ጊዜ ጥያቄዎችን አስገብተናል።

በዚህ ምክንያት አንድ ተጠቃሚ ትልቅ ጥያቄ ባቀረበበት ጊዜ እና ወደ አንድ የተወሰነ የላስቲክ ፍለጋ አስተባባሪ ሲደርስ አንዳንድ አንጓዎች ከሌሎቹ የበለጠ ረዘም ላለ ጊዜ ምላሽ ይሰጣሉ።

እና አስተባባሪው ከሁሉም አንጓዎች ምላሽ እየጠበቀ ሳለ, ቀደም ሲል ምላሽ ከሰጡ አንጓዎች የተላኩትን ውጤቶች ይሰበስባል. ለጂሲ፣ ይህ ማለት የእኛ የቁልል አጠቃቀም ዘይቤዎች በፍጥነት ይቀየራሉ ማለት ነው። እና የተጠቀምንበት GC ይህንን ተግባር መቋቋም አልቻለም.

በዚህ ሁኔታ ውስጥ የክላስተርን ባህሪ ለመለወጥ ያገኘነው ብቸኛው ማስተካከያ ወደ JDK13 ፍልሰት እና የሸንዶዋ ቆሻሻ ሰብሳቢ አጠቃቀም ነው። ይህም ችግሩን ፈታው፣ አስተባባሪዎቻችን መውደቅ አቆሙ።

የጃቫ ችግሮች ያበቁበት እና የመተላለፊያ ይዘት ችግሮች የጀመሩት እዚህ ነው።

"ቤሪ" ከ Elasticsearch ጋር፡ መተላለፍ

ከውጤት ጋር የተያያዙ ችግሮች ማለት የእኛ ክላስተር በተረጋጋ ሁኔታ ይሰራል ነገር ግን በመረጃ ጠቋሚ ሰነዶች ብዛት እና በሚንቀሳቀስበት ጊዜ አፈፃፀም በቂ አይደለም.

የመጀመሪያው ምልክት አጋጥሞታል፡- በምርት ላይ ባሉ አንዳንድ “ፍንዳታዎች” ወቅት፣ በጣም ብዙ ቁጥር ያላቸው ምዝግብ ማስታወሻዎች በድንገት ሲፈጠሩ፣ የኢንዴክስ አመልካች ስህተት es_rejected_execution በግሬሎግ ውስጥ በተደጋጋሚ መብረቅ ይጀምራል።

ይህ የሆነበት ምክንያት thread_pool.write.queue በአንድ ዳታ መስቀለኛ መንገድ ላይ፣ Elasticsearch የመረጃ ጠቋሚ ጥያቄውን ማካሄድ እስካልቻለ እና መረጃውን በዲስክ ላይ ወደ shard እስከሚሰቀልበት ጊዜ ድረስ፣ በነባሪነት 200 ጥያቄዎችን ብቻ መሸጎጥ በመቻሉ ነው። እና ውስጥ Elasticsearch ሰነድ ስለዚህ ግቤት በጣም ጥቂት ይባላል። ከፍተኛው የክሮች ብዛት እና ነባሪው መጠን ብቻ ተጠቁሟል።

በእርግጥ ይህንን እሴት ለማጣመም ሄድን እና የሚከተለውን አገኘን-በተለይ ፣ በእኛ ማዋቀር ውስጥ ፣ እስከ 300 የሚደርሱ ጥያቄዎች በጥሩ ሁኔታ ተሸፍነዋል ፣ እና ከፍ ያለ ዋጋ እንደገና ወደ ሙሉ GC በመብረር የተሞላ ነው።

በተጨማሪም እነዚህ በአንድ ጥያቄ ውስጥ የሚደርሱ የመልእክት ስብስቦች በመሆናቸው ግሬይሎግን ብዙ ጊዜ እና በትንንሽ ደብተሮች እንዲጽፍ ማድረግ አስፈላጊ ነበር, ነገር ግን በትላልቅ ስብስቦች ወይም በ 3 ሴኮንድ አንድ ጊዜ ቡድኑ አሁንም ካልተጠናቀቀ. በዚህ ሁኔታ ፣ በ Elasticsearch ውስጥ የምንጽፈው መረጃ የሚገኘው በሁለት ሴኮንዶች ውስጥ ሳይሆን በአምስት (በጥሩ ሁኔታ የሚስማማን) ነው ፣ ግን ትልቅ በሆነ መንገድ ለመግፋት መደረግ ያለባቸው የመልሶ ማግኛዎች ብዛት። የመረጃ ቁልል ቀንሷል።

ይህ በተለይ የሆነ ነገር የሆነ ቦታ ሲበላሽ እና ስለእሱ በንዴት ሲዘግብ፣ ሙሉ በሙሉ አይፈለጌ መልእክት ያለው ላስቲክ እንዳያገኙ እና ከተወሰነ ጊዜ በኋላ - በተዘጋጉ ቋቶች ምክንያት የማይሰሩ ግሬይሎግ ኖዶች በእነዚያ ጊዜያት በጣም አስፈላጊ ነው።

በተጨማሪም ፣ በምርት ውስጥ እነዚህ ተመሳሳይ ፍንዳታዎች ሲኖሩን ፣ ከፕሮግራም አውጪዎች እና ሞካሪዎች ቅሬታ ደርሰውናል-እነዚህን ምዝግቦች በእውነት በሚያስፈልጋቸው ጊዜ ፣ ​​በጣም በቀስታ ተሰጥቷቸዋል።

ማጣራት ጀመሩ። በአንድ በኩል፣ ሁለቱም የፍለጋ መጠይቆች እና የመረጃ ጠቋሚ መጠይቆች፣ በመሠረቱ፣ በተመሳሳዩ ፊዚካል ማሽኖች ላይ፣ እና በአንድ ወይም በሌላ መንገድ የተወሰኑ ድክመቶች እንደሚኖሩ ግልጽ ነበር።

ነገር ግን በስድስተኛው የElasticsearch እትሞች ውስጥ በዘፈቀደ ዙር-ሮቢን መርህ (መረጃ ጠቋሚ የሚያደርግ እና ዋናውን የሚይዝ መያዣ) በሚመለከታቸው የውሂብ አንጓዎች መካከል መጠይቆችን ለማሰራጨት የሚያስችል ስልተ ቀመር በመታየቱ ይህ በከፊል ሊታለፍ ይችላል። ሻርድ በጣም ስራ ሊበዛበት ይችላል, በፍጥነት ምላሽ ለመስጠት ምንም አይነት መንገድ አይኖርም), ነገር ግን ይህን ጥያቄ ወደ ትንሽ የተጫነ ኮንቴይነር ቅጂ-ሻርድ ለማስተላለፍ, ይህም በጣም ፈጣን ምላሽ ይሰጣል. በሌላ አነጋገር የአጠቃቀም_አዳፕቲቭ_replica_selection ላይ ደርሰናል፡ እውነት።

የንባብ ሥዕሉ ይህን ይመስላል።

ወደዚህ አልጎሪዝም የተደረገው ሽግግር ብዙ የምዝግብ ማስታወሻዎች በነበረንባቸው ጊዜያት የመጠይቅ ጊዜን በእጅጉ ለማሻሻል አስችሎታል።

በመጨረሻም ዋናው ችግር የመረጃ ማእከሉን ያለምንም ህመም ማስወገድ ነበር.

ከአንድ ዲሲ ጋር ግንኙነት ከጠፋ በኋላ ወዲያውኑ ከክላስተር የምንፈልገው፡-

• ባልተሳካው የውሂብ ማዕከል ውስጥ የአሁኑ ማስተር ካለን, ከዚያም እንደገና ተመርጦ በሌላ ዲሲ ውስጥ ወደ ሌላ መስቀለኛ መንገድ ይንቀሳቀሳል.
• ጌታው ሁሉንም የማይደረስባቸውን አንጓዎች ከጥቅል ውስጥ በፍጥነት ያስወግዳል።
• በቀሪዎቹ ላይ በመመስረት እሱ ይገነዘባል-በጠፋው የመረጃ ማእከል ውስጥ እንደዚህ ያሉ እና እንደዚህ ያሉ የመጀመሪያ ደረጃ ሻርዶች ነበሩን ፣ በቀሪዎቹ የመረጃ ቋቶች ውስጥ ተጓዳኝ ቅጂዎችን በፍጥነት ያስተዋውቃል እና መረጃውን ማመላከታችንን እንቀጥላለን።
• በዚህ ምክንያት የክላስተር አጻጻፍ እና የንባብ ፍሰት ቀስ በቀስ እየቀነሰ ይሄዳል, ነገር ግን በአጠቃላይ ሁሉም ነገር በቀስታ ቢሆንም, ግን በተረጋጋ ሁኔታ ይሰራል.

እንደ ተለወጠ ፣ እንደዚህ ያለ ነገር እንፈልጋለን

እና የሚከተለውን አግኝተናል።

ይህ እንዴት ሊሆን ቻለ?

ዳታ ሴንተር ሲወድቅ ጌታችን ማነቆ ሆነ።

ለምን?

እውነታው ግን ጌታው TaskBatcher አለው, እሱም በክላስተር ውስጥ የተወሰኑ ስራዎችን እና ክስተቶችን የማሰራጨት ሃላፊነት አለበት. ማንኛውም የመስቀለኛ መንገድ መውጣት፣ ማንኛውም የሸርተቴ ማስታወቂያ ከቅጅ ወደ አንደኛ ደረጃ፣ የሆነ ቦታ ላይ ሸርጣን ለመፍጠር ማንኛውም ተግባር - ይህ ሁሉ መጀመሪያ ወደ TaskBatcher ይሄዳል፣ እሱም በቅደም ተከተል እና በአንድ ክር ውስጥ ይከናወናል።

አንድ የመረጃ ማእከል በሚወጣበት ጊዜ በሕይወት ባሉ የመረጃ ማዕከሎች ውስጥ ያሉ ሁሉም የመረጃ ቋቶች “እንዲህ ያሉ እና እንደዚህ ያሉ ቁርጥራጮች እና እንደዚህ ያሉ የመረጃ አንጓዎች አጥተናል” በማለት ጌታውን የማሳወቅ ግዴታ አድርገው ይመለከቱት እንደነበር ለማወቅ ተችሏል።

በተመሳሳይ ጊዜ, የተረፉት የውሂብ አንጓዎች ይህንን ሁሉ መረጃ ለአሁኑ ጌታ ልከው መቀበሉን ማረጋገጫ ለመጠበቅ ሞክረዋል. ጌታው ሊመልስ ከሚችለው በላይ ስራዎችን ስለተቀበለ እነሱ ይህን አልጠበቁም. መስቀለኛ መንገዶቹ ጥያቄዎችን መድገም ጊዜያቸውን ጨርሰዋል፣ እና ጌታው በዚህ ጊዜ እነሱን ለመመለስ እንኳን አልሞከረም ፣ ግን ጥያቄዎችን በቅድሚያ የመደርደር ተግባር ውስጥ ሙሉ በሙሉ ተጠምቋል።

በተርሚናል መልክ፣ የመረጃ መስቀለኛ መንገዶች ጌታውን ወደ ሙሉ ጂሲ እስኪገባ ድረስ አይፈለጌ መልዕክት እንዳደረጉት ለማወቅ ተችሏል። ከዚያ በኋላ፣ የእኛ ዋና ሚና ወደ ቀጣዩ መስቀለኛ መንገድ ተዛወረ፣ ፍፁም ተመሳሳይ ነገር ደረሰበት፣ እናም በዚህ ምክንያት ክላስተር ሙሉ በሙሉ ወድቋል።

መለኪያዎችን ወስደናል, እና ይህ ከተስተካከለበት ስሪት 6.4.0 በፊት, ክላስተር ሙሉ በሙሉ ለመዝጋት ከ 10 ውስጥ 360 የውሂብ ኖዶችን በአንድ ጊዜ ለማውጣት በቂ ነበር.

ይህን ይመስላል።

ከስሪት 6.4.0 በኋላ፣ ይህ አስከፊ ስህተት ከተስተካከለበት፣ የውሂብ ኖዶች ጌታውን መግደል አቁመዋል። ይህ ግን “ብልህ” አላደረገውም። ይኸውም፡- 2፣ 3 ወይም 10 (ከአንድ ሌላ ማንኛውም ቁጥር) ዳታ ኖዶችን ስናወጣ ጌታው መስቀለኛ መንገድ A ለቋል የሚል የመጀመሪያ መልእክት ይደርሰዋል እና በዚህ ጉዳይ ላይ መስቀለኛ B፣ node C፣ node D ለመንገር ይሞክራል።

እና በአሁኑ ጊዜ፣ ይህንን መቋቋም የሚቻለው ለአንድ ሰው ስለ አንድ ነገር ለመንገር የሚደረጉ ሙከራዎች ጊዜ ማብቂያ ጊዜን በማዘጋጀት ብቻ ነው ፣ ይህም ከ20-30 ሰከንድ ያህል ነው ፣ እናም የውሂብ ማእከሉ ከክላስተር የሚወጣበትን ፍጥነት ይቆጣጠሩ።

በመርህ ደረጃ, ይህ እንደ የፕሮጀክቱ አካል በመጀመሪያ ለመጨረሻው ምርት ከቀረቡት መስፈርቶች ጋር ይጣጣማል, ነገር ግን ከ "ንጹህ ሳይንስ" እይታ ይህ ስህተት ነው. በነገራችን ላይ በስሪት 7.2 ውስጥ በገንቢዎች በተሳካ ሁኔታ የተስተካከለው.

ከዚህም በላይ፣ የተወሰነ የመረጃ መስቀለኛ መንገድ ሲወጣ፣ ስለ መውጣቱ መረጃ ማሰራጨት ለሁሉም ክላስተር እንደዚህ ያሉ እና እንደዚህ ያሉ የመጀመሪያ ደረጃ-ሻርዶች በላዩ ላይ እንዳሉ ከመንገር የበለጠ አስፈላጊ እንደሆነ ታወቀ (በሌላ ውሂብ ውስጥ ቅጂ-shard ለማስተዋወቅ) በአንደኛ ደረጃ ማእከል ፣ እና በመረጃ ላይ በእነሱ ላይ ሊፃፍ ይችላል።

ስለዚህ, ሁሉም ነገር ቀድሞውኑ ሲሞት, የተለቀቁት የውሂብ አንጓዎች ወዲያውኑ እንደ አሮጌ ምልክት አይደረግባቸውም. በዚህ መሠረት ሁሉም ፒንግዎች ለተለቀቁት የመረጃ ቋቶች ጊዜያቸውን እስኪጨርሱ ድረስ ለመጠበቅ እንገደዳለን እና ከዚያ በኋላ ብቻ የእኛ ስብስብ እዚያ ፣ እዚያ እና እዚያ መረጃ መመዝገብ እንዳለብን ይነግረናል ። ስለዚህ ጉዳይ የበለጠ ማንበብ ይችላሉ እዚህ.

በዚህ ምክንያት የመረጃ ማእከልን ዛሬ የማውጣት ክዋኔው በሚበዛበት ሰዓት 5 ደቂቃ ያህል ይወስዳል። ለእንደዚህ ዓይነቱ ትልቅ እና የተዘበራረቀ ኮሎሲስ ይህ በጣም ጥሩ ውጤት ነው.

በውጤቱም, ወደሚከተለው ውሳኔ ደርሰናል.

• ከ 360 ጊጋባይት ዲስኮች ጋር 700 የውሂብ አንጓዎች አለን።
• በእነዚህ ተመሳሳይ የውሂብ ኖዶች ውስጥ ትራፊክን ለመምራት 60 አስተባባሪዎች።
• ከ40 በፊት ከነበሩት ስሪቶች ጀምሮ እንደ ቅርስ የተውናቸው 6.4.0 ጌቶች - ከመረጃ ማዕከሉ መውጣት ለመትረፍ በአእምሯችን ውስጥ እንኳን የጌቶች ምልአተ ጉባኤ እንዲኖረን ብዙ ማሽኖችን ለማጣት በአእምሮ ተዘጋጅተናል። በጣም መጥፎው ሁኔታ
• በአንድ ኮንቴይነር ላይ ሚናዎችን ለማጣመር የተደረጉ ማንኛቸውም ሙከራዎች ፈጥኖም ይሁን ዘግይቶ መስቀለኛ መንገዱ በጭነት ውስጥ ስለሚሰበር ነው።
• ሙሉው ክላስተር የ31 ጊጋባይት ክምር ይጠቀማል፡ መጠኑን ለመቀነስ የተደረገው ሙከራ ሁሉ አንዳንድ አንጓዎችን በከባድ የፍለጋ መጠይቆች ላይ ከዋናው ዋይልድ ካርድ ጋር ገድሎ ወይም የወረዳ ሰባሪው በራሱ Elasticsearch ውስጥ እንዲገኝ አድርጓል።
• በተጨማሪም የፍለጋ አፈጻጸምን ለማረጋገጥ በጌታው ውስጥ በደረስንበት ማነቆ ውስጥ በተቻለ መጠን ጥቂት ክንውኖችን ለማስኬድ በክላስተር ውስጥ ያሉትን ነገሮች በተቻለ መጠን ትንሽ ለማድረግ ሞክረናል።

በመጨረሻም ስለ ክትትል

ይህ ሁሉ እንደታሰበው መስራቱን ለማረጋገጥ የሚከተሉትን እንከታተላለን፡-

• እያንዳንዱ የመረጃ መስቀለኛ መንገድ እንዳለ ለደመናችን ሪፖርት ያደርጋል፣ እና በእሱ ላይ እንደዚህ ያሉ እና እንደዚህ ያሉ ቁርጥራጮች አሉ። የሆነ ነገር ስናጠፋ ክላስተር ከ2-3 ሰከንድ በኋላ እንደዘገበው በመሀል ሀ 2፣ 3 እና 4 ኖዶችን አጥተናል - ይህ ማለት በሌሎች የመረጃ ቋቶች ውስጥ እኛ በምንም አይነት ሁኔታ አንድ ቁራጭ ብቻ ያሉባቸውን አንጓዎች ማጥፋት አንችልም። ግራ.
• የጌታውን ባህሪ ባህሪ ማወቅ, በመጠባበቅ ላይ ያሉ ስራዎችን ብዛት በጥንቃቄ እንመለከታለን. ምክንያቱም አንድ የተቀረቀረ ተግባር እንኳን በጊዜው ካላለፈ፣ በንድፈ ሀሳብ በአንዳንድ የአደጋ ጊዜ ሁኔታዎች ለምሳሌ በዋና ደረጃ የብዜት ሸርተቴ ማስተዋወቅ የማይሰራበት ምክንያት ሊሆን ይችላል፣ ለዚህም ነው መረጃ ጠቋሚ መስራት ያቆማል።
• የቆሻሻ አሰባሳቢ መዘግየቶችንም በቅርበት እንመለከታለን፣ ምክንያቱም በማመቻቸት ወቅት በዚህ ጉዳይ ላይ ብዙ ችግሮች አጋጥመውናል።
• ማነቆው የት እንዳለ አስቀድሞ ለመረዳት በክር አይቀበልም።
• ደህና፣ እንደ ክምር፣ RAM እና I/O ያሉ መደበኛ መለኪያዎች።

ክትትልን በሚገነቡበት ጊዜ በ Elasticsearch ውስጥ ያለውን የ Thread Pool ባህሪያትን ግምት ውስጥ ማስገባት አለብዎት. የላስቲክ ፍለጋ ሰነድ ለፍለጋ እና መረጃ ጠቋሚ የውቅረት አማራጮችን እና ነባሪ እሴቶችን ይገልፃል ፣ ግን ስለ thread_pool.management ሙሉ በሙሉ ፀጥ ይላል ። እነዚህ ክሮች ሂደት በተለይም እንደ _cat/shards እና ሌሎች ተመሳሳይ መጠይቆች ክትትል በሚጽፉበት ጊዜ ለመጠቀም ምቹ ናቸው። ክላስተር በትልቁ፣ እንደዚህ አይነት ጥያቄዎች በአንድ ጊዜ ይፈጸማሉ፣ እና ከላይ የተጠቀሰው thread_pool.አስተዳደር በይፋዊ ሰነዶች ላይ አለመቅረብ ብቻ ሳይሆን በነባሪነት በ 5 ክሮች የተገደበ ነው ፣ እሱም በፍጥነት ይወገዳል ፣ በኋላ የትኛው ክትትል በትክክል መስራት ያቆማል.

በማጠቃለያው ማለት የምፈልገው፡- አደረግነው! ለፕሮግራመሮቻችን እና ገንቢዎቻችን በማንኛውም ሁኔታ ውስጥ በፍጥነት እና በአስተማማኝ ሁኔታ በምርት ላይ ስላለው ነገር መረጃ የሚሰጥ መሳሪያ መስጠት ችለናል።

አዎ ፣ እሱ በጣም የተወሳሰበ ሆነ ፣ ግን ፣ ሆኖም ፣ ምኞቶቻችንን አሁን ካሉት ምርቶች ጋር ለማስማማት ችለናል ፣ እኛ ለራሳችን መለጠፍ እና እንደገና መጻፍ አያስፈልገንም።

ምንጭ: hab.com