බොහෝ අය Elasticsearch සමඟ අරගල කරති. නමුත් "විශේෂයෙන් විශාල පරිමාවකින්" ලඝු-සටහන් ගබඩා කිරීම සඳහා එය භාවිතා කිරීමට අවශ්ය වූ විට කුමක් සිදුවේද? තවද දත්ත මධ්‍යස්ථාන කිහිපයකින් එකක අසාර්ථක වීමක් අත්විඳීම වේදනා රහිතද? ඔබ කුමන ආකාරයේ ගෘහ නිර්මාණ ශිල්පයක් සෑදිය යුතුද, ඔබ පැකිළෙන්නේ කුමන උගුල්වලටද?
Odnoklassniki හි අපි ලොග් කළමනාකරණයේ ගැටළුව විසඳීම සඳහා elasticsearch භාවිතා කිරීමට තීරණය කළ අතර දැන් අපි Habr සමඟ අපගේ අත්දැකීම් බෙදා ගනිමු: ගෘහ නිර්මාණ ශිල්පය සහ අන්තරායන් පිළිබඳව.
මම Pyotr Zaitsev, මම Odnoklassniki හි පද්ධති පරිපාලකයෙකු ලෙස සේවය කරමි. ඊට පෙර, මමත් පරිපාලකයෙක්, Manticore Search, Sphinx search, Elasticsearch සමඟ වැඩ කළා. සමහර විට, වෙනත් ... සෙවුමක් දිස්වන්නේ නම්, මමත් බොහෝ විට එය සමඟ වැඩ කරනු ඇත. මම ස්වේච්ඡා පදනමින් විවෘත මූලාශ්‍ර ව්‍යාපෘති ගණනාවකට ද සහභාගී වෙමි.
මම Odnoklassniki වෙත පැමිණි විට, මම සම්මුඛ පරීක්ෂණයේදී නොසැලකිලිමත් ලෙස පැවසුවේ මට Elasticsearch සමඟ වැඩ කළ හැකි බවයි. මම ඒක තේරුම් අරගෙන සරල වැඩ ටිකක් ඉවර කළාට පස්සේ මට ඒ කාලේ තිබුණු ලොග් මැනේජ්මන්ට් සිස්ටම් එක ප්‍රතිසංස්කරණය කරන ලොකු කර්තව්‍යයක් පැවරුණා.
අවශ්යතා
පද්ධති අවශ්යතා පහත පරිදි සකස් කර ඇත:
- ග්‍රේලොග් ඉදිරිපස ලෙස භාවිතා කිරීමට නියමිතව තිබුණි. සමාගමට දැනටමත් මෙම නිෂ්පාදනය භාවිතා කිරීමේ අත්දැකීම් ඇති නිසා, වැඩසටහන්කරුවන් සහ පරීක්ෂකයින් එය දැන සිටි නිසා, එය ඔවුන්ට හුරුපුරුදු සහ පහසු විය.
- දත්ත පරිමාව: සාමාන්‍යයෙන් තත්පරයකට පණිවිඩ 50-80 දහසක්, නමුත් යමක් කැඩී ගියහොත්, ගමනාගමනය කිසිවකින් සීමා නොවේ, එය තත්පරයට පේළි මිලියන 2-3 ක් විය හැකිය
- සෙවුම් විමසුම් සැකසීමේ වේගය සඳහා අවශ්යතා ගැන ගනුදෙනුකරුවන් සමඟ සාකච්ඡා කිරීමෙන් පසු, එවැනි පද්ධතියක් භාවිතා කිරීමේ සාමාන්‍ය රටාව මෙය බව අපට වැටහුණි: මිනිසුන් පසුගිය දින දෙක තුළ ඔවුන්ගේ අයදුම්පත්‍රයේ ලොග් සොයමින් සිටින අතර වැඩි කාලයක් බලා සිටීමට අවශ්ය නැත. සූත්‍රගත විමසුමක ප්‍රතිඵලය සඳහා දෙවැන්න.
- පරිපාලකයින් අවධාරනය කළේ පද්ධතිය ක්‍රියා කරන ආකාරය ගැඹුරින් සොයා බැලීමට අවශ්ය නොවී, අවශ්ය නම් පහසුවෙන් පරිමාණය කළ හැකි බවයි.
- එබැවින් මෙම පද්ධති සඳහා වරින් වර අවශ්ය වන එකම නඩත්තු කාර්යය වන්නේ දෘඪාංග වෙනස් කිරීමයි.
- මීට අමතරව, Odnoklassniki සතුව විශිෂ්ට තාක්ෂණික සම්ප්‍රදායක් ඇත: අප දියත් කරන ඕනෑම සේවාවක් දත්ත මධ්‍යස්ථාන අසමත් වීමකින් බේරිය යුතුය (හදිසි, සැලසුම් නොකළ සහ නියත වශයෙන්ම ඕනෑම වේලාවක).
මෙම ව්‍යාපෘතිය ක්‍රියාත්මක කිරීමේදී අවසාන අවශ්‍යතාවය අපට වඩාත්ම වියදම් විය, එය මම වඩාත් විස්තරාත්මකව කතා කරමි.
බදාදා
අපි දත්ත මධ්‍යස්ථාන හතරක වැඩ කරන අතර, Elasticsearch දත්ත නෝඩ් ස්ථාන තුනක පමණක් (තාක්ෂණික නොවන හේතු ගණනාවක් නිසා) ස්ථානගත කළ හැක.
මෙම දත්ත මධ්‍යස්ථාන හතරේ විවිධ ලඝු-සටහන් මූලාශ්‍ර 18ක් පමණ අඩංගු වේ - දෘඩාංග, බහාලුම්, අතථ්‍ය යන්ත්ර.
වැදගත් අංගය: පොකුර ආරම්භ වන්නේ බහාලුම්වලිනි භෞතික යන්ත්ර මත නොව, නමුත් මත . බහාලුම්වලට 2Ghz v2.0 ට සමාන හර 4 ක් සහතික කර ඇත, ඉතිරි හරයන් අක්‍රිය නම් ඒවා ප්‍රතිචක්‍රීකරණය කිරීමේ හැකියාව ඇත.
වෙනත් විදිහකින්:
ස්ථාන විද්‍යාව
මම මුලින් විසඳුමේ සාමාන්‍ය ස්වරූපය පහත පරිදි දුටුවෙමි:
- ප්‍රභූවරුන් 3-4 දෙනෙක් ග්‍රේලොග් වසමේ A-වාර්තාව පිටුපස සිටිති, මෙය ලඝු-සටහන් යවන ලිපිනයයි.
- සෑම VIP එකක්ම LVS balancer වේ.
- ඊට පසු, ලොග් ග්‍රේලොග් බැටරියට යයි, සමහර දත්ත GELF ආකෘතියෙන්, සමහරක් syslog ආකෘතියෙන්.
- එවිට මේ සියල්ල ඉලාස්ටික්සර්ච් සම්බන්ධීකාරක බැටරියකට විශාල කොටස් වලින් ලියා ඇත.
- ඔවුන් අනෙක් අතට, අදාළ දත්ත නෝඩ් වෙත ලිවීමේ සහ කියවීමේ ඉල්ලීම් යවයි.
පාරිභාෂිතය
සමහර විට සෑම කෙනෙකුම පාරිභාෂිතය විස්තරාත්මකව තේරුම් නොගනී, එබැවින් මම ඒ ගැන ටිකක් වාසය කිරීමට කැමතියි.
Elasticsearch නෝඩ් වර්ග කිහිපයක් ඇත - මාස්ටර්, සම්බන්ධීකාරක, දත්ත නෝඩය. විවිධ ලොග් පරිවර්තන සහ විවිධ පොකුරු අතර සන්නිවේදනය සඳහා තවත් වර්ග දෙකක් ඇත, නමුත් අපි භාවිතා කළේ ලැයිස්තුගත කර ඇති ඒවා පමණි.
මාස්ටර්
එය පොකුරේ ඇති සියලුම නෝඩ් ping කරයි, යාවත්කාලීන පොකුරු සිතියමක් පවත්වාගෙන යයි සහ එය නෝඩ් අතර බෙදා හරියි, සිද්ධි තර්කනය සකසයි, සහ විවිධ ආකාරයේ පොකුරු පුළුල් ගෘහ පාලනයක් සිදු කරයි.
සම්බන්ධීකාරක
එක් කාර්යයක් ඉටු කරයි: සේවාලාභීන්ගෙන් කියවීමට හෝ ලිවීමට ඉල්ලීම් පිළිගෙන මෙම ගමනාගමනයට මඟ පෙන්වයි. ලිඛිත ඉල්ලීමක් තිබේ නම්, බොහෝ දුරට, එය එය තැබිය යුතු අදාළ දර්ශකයේ කුමන කොටසද යන්න ස්වාමියාගෙන් අසනු ඇති අතර, ඉල්ලීම තවදුරටත් හරවා යවනු ඇත.
දත්ත නෝඩය
දත්ත ගබඩා කරයි, පිටතින් පැමිණෙන සෙවුම් විමසුම් සිදු කරයි සහ එය මත පිහිටා ඇති කැබලි මත මෙහෙයුම් සිදු කරයි.
ග්‍රේලොග්
මෙය ELK ස්ටැක් එකක ලොග්ස්ටාෂ් සමඟ කිබානා විලයනයක් වැනි දෙයකි. ග්‍රේලොග් UI සහ ලොග් සැකසුම් නල මාර්ගය යන දෙකම ඒකාබද්ධ කරයි. හුඩ් යටතේ, ග්‍රේලොග් විසින් කෆ්කා සහ සූකීපර් ක්‍රියාත්මක කරයි, එය ග්‍රේලොග් වෙත පොකුරක් ලෙස සම්බන්ධතාවය සපයයි. ග්‍රේලොග් හට ඉලාස්ටික් සෙවුම් නොමැති අවස්ථාවකදී ලොග (කෆ්කා) හැඹිලිගත කළ හැකි අතර අසාර්ථක කියවීම් සහ ලිවීමේ ඉල්ලීම්, කණ්ඩායම් සහ ලකුණු ලොග නිශ්චිත රීතිවලට අනුව නැවත නැවත සිදු කළ හැක. Logstash මෙන්, Graylog හට ඉලාස්ටික් සෙවුම් වෙත ලිවීමට පෙර පේළි වෙනස් කිරීමට ක්‍රියාකාරීත්වයක් ඇත.
මීට අමතරව, ග්‍රේලොග් සතුව පවතින එක් ඉලාස්ටික් සෙවුම් නෝඩයක් මත පදනම්ව සම්පූර්ණ පොකුරු සිතියම ලබා ගැනීමට සහ එය විශේෂිත ටැගයකින් පෙරීමට ඉඩ සලසන බිල්ට් සේවා සොයාගැනීමක් ඇත, එමඟින් නිශ්චිත බහාලුම් වෙත ඉල්ලීම් යොමු කිරීමට හැකි වේ.
දෘශ්යමය වශයෙන් එය මේ වගේ දෙයක් පෙනේ:
මෙය විශේෂිත අවස්ථාවක තිර රුවක්. මෙහිදී අපි සෙවුම් විමසුම මත පදනම්ව හිස්ටෝග්‍රෑම් එකක් ගොඩනඟා අදාළ පේළි පෙන්වමු.
දර්ශක
පද්ධති ගෘහනිර්මාණ ශිල්පය වෙත ආපසු යමින්, එය සියල්ල නිවැරදිව ක්‍රියාත්මක වන පරිදි අපි දර්ශක ආකෘතිය ගොඩනඟා ගත් ආකාරය පිළිබඳව වඩාත් විස්තරාත්මකව වාසය කිරීමට මම කැමැත්තෙමි.
ඉහත රූප සටහනේ, මෙය අඩුම මට්ටමයි: Elasticsearch දත්ත නෝඩ්.
දර්ශකයක් යනු Elasticsearch shards වලින් සැදුම්ලත් විශාල අතථ්‍ය වස්තුවකි. එහිම, එක් එක් කැබලි ලුසීන් දර්ශකයකට වඩා වැඩි දෙයක් නොවේ. තවද සෑම Lucene දර්ශකයක්ම කොටස් එකකින් හෝ වැඩි ගණනකින් සමන්විත වේ.
සැලසුම් කිරීමේදී, විශාල දත්ත ප්‍රමාණයක කියවීමේ වේගයේ අවශ්‍යතාවය සපුරාලීම සඳහා, අපට මෙම දත්ත දත්ත නෝඩ් හරහා ඒකාකාරව “පැතිරීමට” අවශ්ය බව අපට පෙනී ගියේය.
මෙහි ප්‍රතිඵලය වූයේ එක් දර්ශකයකට කැබලි ගණන (අනුපිටපත් සහිත) දත්ත නෝඩ් ගණනට දැඩි ලෙස සමාන විය යුතු බවයි. පළමුව, දෙකකට සමාන අනුවර්තන සාධකයක් සහතික කිරීම සඳහා (එනම්, අපට පොකුරෙන් අඩක් අහිමි විය හැක). සහ, දෙවනුව, පොකුරු අවම වශයෙන් අඩක් මත කියවීම සහ ලිවීමේ ඉල්ලීම් සැකසීම සඳහා.
අපි මුලින්ම ගබඩා කාලය දින 30ක් ලෙස තීරණය කළා.
කැබලි බෙදා හැරීම පහත පරිදි ප්‍රස්ථාරිකව නිරූපණය කළ හැකිය:
සම්පූර්ණ තද අළු සෘජුකෝණාස්රය දර්ශකයකි. එහි වම් රතු චතුරස්රය ප්‍රාථමික ෂාර්ඩ්, දර්ශකයේ පළමුවැන්නයි. තවද නිල් චතුරස්රය අනුරූ කැබැල්ලකි. ඒවා විවිධ දත්ත මධ්‍යස්ථානවල පිහිටා ඇත.
අපි තව shard එකක් දැම්මම ඒක යන්නේ තුන්වෙනි data center එකට. තවද, අවසානයේදී, අපට මෙම ව්‍යුහය ලැබේ, එමඟින් දත්ත අනුකූලතාව නැති නොවී DC නැති කර ගැනීමට හැකි වේ:
දර්ශකවල භ්රමණය, i.e. නව දර්ශකයක් නිර්මාණය කිරීම සහ පැරණිතම එක මකා දැමීම, අපි එය පැය 48 ට සමාන කළෙමු (දර්ශක භාවිතයේ රටාව අනුව: අවසාන පැය 48 බොහෝ විට සොයනු ලැබේ).
මෙම දර්ශක භ්‍රමණ පරතරය පහත හේතු නිසා වේ:
සෙවුම් ඉල්ලීමක් නිශ්චිත දත්ත නෝඩයකට පැමිණෙන විට, කාර්ය සාධන දෘෂ්ටි කෝණයකින්, එහි විශාලත්වය නෝඩයේ උකුලේ ප්‍රමාණයට සැසඳිය හැකි නම්, එක් කැබැල්ලක් විමසන විට එය වඩාත් ලාභදායී වේ. මෙය ඔබට දර්ශකයේ "උණුසුම්" කොටස ගොඩක තබා ගැනීමට සහ ඉක්මනින් ප්රවේශ වීමට ඉඩ සලසයි. "උණුසුම් කොටස්" ගොඩක් ඇති විට, දර්ශක සෙවීමේ වේගය පිරිහී යයි.
නෝඩයක් එක් කැබැල්ලක් මත සෙවුම් විමසුමක් ක්‍රියාත්මක කිරීමට පටන් ගත් විට, එය භෞතික යන්ත්‍රයේ හයිපර් ත්‍රෙඩින් කෝර් ගණනට සමාන නූල් ගණනාවක් වෙන් කරයි. සෙවුම් විමසුමක් විශාල කැබලි ගණනකට බලපාන්නේ නම්, නූල් ගණන සමානුපාතිකව වර්ධනය වේ. මෙය සෙවුම් වේගය කෙරෙහි ඍණාත්මක බලපෑමක් ඇති කරන අතර නව දත්ත සුචිගත කිරීමට සෘණාත්මකව බලපායි.
අවශ්ය සෙවුම් ප්‍රමාදය සැපයීම සඳහා, අපි SSD භාවිතා කිරීමට තීරණය කළෙමු. ඉල්ලීම් ඉක්මනින් ක්‍රියාවට නැංවීමට, මෙම බහාලුම් සත්කාරකත්වය සපයන යන්ත්‍රවලට අවම වශයෙන් මධ්‍ය 56ක්වත් තිබිය යුතුය. ප්‍රත්‍යාස්ථ සෙවීම ක්‍රියාත්මක වන විට උත්පාදනය කරන නූල් සංඛ්‍යාව තීරණය කරන කොන්දේසි සහිත ප්‍රමාණවත් අගයක් ලෙස 56 රූපය තෝරා ගන්නා ලදී. Elasitcsearch හි, බොහෝ නූල් තටාක පරාමිතීන් කෙලින්ම රඳා පවතින්නේ පවතින හර ගණන මත වන අතර, එය “අඩු හර - වැඩි නෝඩ්” මූලධර්මය අනුව පොකුරේ අවශ්ය නෝඩ් ගණනට කෙලින්ම බලපායි.
එහි ප්‍රතිඵලයක් වශයෙන්, සාමාන්‍යයෙන් කැබැල්ලක බර ගිගාබයිට් 20 ක් පමණ වන අතර, එක් දර්ශකයකට කැබලි 1 ක් ඇති බව අපට පෙනී ගියේය. ඒ අනුව, අපි සෑම පැය 360 කට වරක් ඒවා භ්රමණය කළහොත්, අපට ඒවායින් 48 ක් ඇත. සෑම දර්ශකයකම දින 15 ක් සඳහා දත්ත අඩංගු වේ.
දත්ත ලිවීම සහ කියවීමේ පරිපථ
මෙම පද්ධතියේ දත්ත සටහන් කරන්නේ කෙසේදැයි සොයා බලමු.
අපි හිතමු ග්‍රේලොග්ගෙන් යම් ඉල්ලීමක් සම්බන්ධීකාරක වෙත පැමිණෙන බව. උදාහරණයක් ලෙස, අපට පේළි 2-3 දහසක් සුචිගත කිරීමට අවශ්ය වේ.
ග්‍රේලොග්ගෙන් ඉල්ලීමක් ලැබුණු සම්බන්ධීකාරකවරයා ස්වාමියාගෙන් ප්‍රශ්න කරයි: “සුචිගත කිරීමේ ඉල්ලීමේදී, අපි විශේෂයෙන් දර්ශකයක් සඳහන් කළ නමුත් එය ලිවිය යුත්තේ කුමන කොටසෙහිද යන්න සඳහන් කර නැත.”
ස්වාමියා ප්‍රතිචාර දක්වයි: "මෙම තොරතුරු ෂාර්ඩ් අංක 71 වෙත ලියන්න", ඉන්පසු එය ප්‍රාථමික-ෂර්ඩ් අංක 71 පිහිටා ඇති අදාළ දත්ත නෝඩයට කෙලින්ම යවනු ලැබේ.
ඉන් පසුව ගනුදෙනු ලොගය වෙනත් දත්ත මධ්‍යස්ථානයක පිහිටා ඇති අනුරූ ෂාර්ඩ් එකකට ප්‍රතිවර්තනය වේ.
ග්‍රේලොග් වෙතින් සෙවුම් ඉල්ලීමක් සම්බන්ධීකාරක වෙත පැමිණේ. සම්බන්ධීකාරක එය දර්ශකයට අනුව යළි හරවා යවන අතර, Elasticsearch විසින් රවුන්ඩ් රොබින් මූලධර්මය භාවිතයෙන් ප්‍රාථමික-ෂර්ඩ් සහ අනුරූ-ෂර්ඩ් අතර ඉල්ලීම් බෙදා හරිනු ලබයි.
නෝඩ් 180 අසමාන ලෙස ප්‍රතිචාර දක්වන අතර, ඔවුන් ප්‍රතිචාර දක්වන අතරතුර, සම්බන්ධීකාරක විසින් වේගවත් දත්ත නෝඩ් මගින් දැනටමත් "කෙල ගසා ඇති" තොරතුරු රැස් කරයි. මෙයින් පසු, සියලු තොරතුරු පැමිණ ඇති විට, හෝ ඉල්ලීම කල් ඉකුත් වූ විට, එය සේවාදායකයාට කෙලින්ම සියල්ල ලබා දෙයි.
මෙම සමස්ත පද්ධතිය සාමාන්‍යයෙන් පසුගිය පැය 48 සඳහා සෙවුම් විමසුම් 300-400ms වලදී ප්‍රමුඛ පෙළේ කාඩ්පතක් සමඟින් එම විමසුම් ක්‍රියාවට නංවයි.
ඉලාස්ටික් සෙවුම් සහිත මල්: ජාවා සැකසුම
ඒ සියල්ල අපට මුලින් අවශ්ය ආකාරයට ක්‍රියාත්මක කිරීම සඳහා, අපි පොකුරේ විවිධ දේවල් නිදොස් කිරීමට ඉතා දිගු කාලයක් ගත කළෙමු.
සොයාගත් ගැටළු වල පළමු කොටස Elasticsearch හි පෙරනිමියෙන් ජාවා පූර්ව වින්‍යාස කර ඇති ආකාරය හා සම්බන්ධ විය.
ගැටලුව එක
Lucene මට්ටමේදී, පසුබිම් රැකියා ක්‍රියාත්මක වන විට, Lucene කොටස ඒකාබද්ධ කිරීම දෝෂයක් සමඟ අසාර්ථක වන බවට වාර්තා ඉතා විශාල ප්‍රමාණයක් අපි දැක ඇත්තෙමු. ඒ සමගම, මෙය OutOfMemoryError දෝෂයක් බව ලඝු-සටහන් වල පැහැදිලි විය. උකුල නිදහස් බව අපි ටෙලිමෙට්‍රි වලින් දුටුවෙමු, මෙම මෙහෙයුම අසාර්ථක වන්නේ මන්දැයි පැහැදිලි නැත.
ලුසීන් දර්ශකය ඒකාබද්ධ කිරීම උකුලෙන් පිටත සිදුවන බව පෙනී ගියේය. පරිභෝජනය කරන සම්පත් අනුව බහාලුම් දැඩි ලෙස සීමා වේ. මෙම සම්පත් වලට ගැළපෙන්නේ ගොඩට පමණි (heap.size අගය දළ වශයෙන් RAM ට සමාන විය), සහ යම් හේතුවක් නිසා සීමාවට පෙර පැවති ~500MB ට නොගැලපේ නම්, සමහර off-heap මෙහෙයුම් මතක වෙන් කිරීමේ දෝෂයක් සමඟ බිඳ වැටේ.
නිවැරදි කිරීම ඉතා සුළු දෙයක් විය: කන්ටේනරය සඳහා ලබා ගත හැකි RAM ප්රමාණය වැඩි විය, පසුව අපට එවැනි ගැටළු ඇති බව අපට අමතක විය.
ගැටලුව දෙක
පොකුර දියත් කිරීමෙන් දින 4-5 කට පසු, දත්ත නෝඩ් වරින් වර පොකුරෙන් පිටතට වැටීමට පටන් ගෙන තත්පර 10-20 කට පසුව එයට ඇතුළු වන බව අපි දුටුවෙමු.
අපි එය තේරුම් ගැනීමට පටන් ගත් විට, Elasticsearch හි මෙම off-heap මතකය කිසිදු ආකාරයකින් පාලනය නොවන බව පෙනී ගියේය. අපි කන්ටේනරයට වැඩි මතකයක් ලබා දුන් විට, අපට විවිධ තොරතුරු සමඟ සෘජු බෆර සංචිත පිරවීමට හැකි වූ අතර, එය ඉලාස්ටික්සර්ච් වෙතින් පැහැදිලි GC දියත් කිරීමෙන් පසුව පමණි.
සමහර අවස්ථාවලදී, මෙම මෙහෙයුම සෑහෙන කාලයක් ගත වූ අතර, මෙම කාලය තුළ පොකුර මෙම නෝඩය දැනටමත් පිටවී ඇති ලෙස සලකුණු කිරීමට සමත් විය. මෙම ගැටළුව හොඳින් විස්තර කර ඇත .
විසඳුම පහත පරිදි විය: මෙම මෙහෙයුම් සඳහා ගොඩට පිටතින් මතකයේ වැඩි ප්‍රමාණයක් භාවිතා කිරීමට ජාවා සතු හැකියාව අපි සීමා කළෙමු. අපි එය ගිගාබයිට් 16කට (-XX:MaxDirectMemorySize=16g) සීමා කළෙමු, පැහැදිලි GC බොහෝ විට ඇමතීමටත් වඩා වේගයෙන් සකසන බවත්, එමගින් තවදුරටත් පොකුර අස්ථායී නොවන බවත් සහතික කර ගත්තෙමු.
ගැටලුව තුන
"අනපේක්ෂිත මොහොතේ පොකුරෙන් පිටවන නෝඩ්" සමඟ ඇති ගැටළු අවසන් බව ඔබ සිතන්නේ නම්, ඔබ වැරදියි.
අපි දර්ශක සමඟ කාර්යය වින්‍යාස කළ විට, අපි mmapfs සඳහා තෝරා ගත්තෙමු විශාල ඛණ්ඩනයක් සහිත නැවුම් කැබලි මත. මෙය තරමක් වරදක් විය, මක්නිසාද යත් mmapfs භාවිතා කරන විට ගොනුව RAM වෙත සිතියම්ගත කර ඇති අතර පසුව අපි සිතියම්ගත කළ ගොනුව සමඟ වැඩ කරමු. මේ නිසා, GC යෙදුමේ නූල් නැවැත්වීමට උත්සාහ කරන විට, අපි ඉතා දිගු වේලාවක් ආරක්ෂිත ස්ථානයට යන අතර, ඒ සඳහා යන අතරමගදී, යෙදුම ජීවමානද යන්න පිළිබඳ ස්වාමියාගේ ඉල්ලීම්වලට ප්‍රතිචාර දැක්වීම නතර කරයි. . ඒ අනුව, මාස්ටර් විශ්වාස කරන්නේ නෝඩය තවදුරටත් පොකුරේ නොමැති බවයි. මෙයින් පසු, තත්පර 5-10 කට පසු, කසළ එකතු කරන්නා ක්‍රියා කරයි, නෝඩය ජීවයට පැමිණ, නැවත පොකුරට ඇතුළු වී කැබලි ආරම්භ කිරීමට පටන් ගනී. ඒ සියල්ල "අපට ලැබිය යුතු නිෂ්පාදනයක්" ලෙස හැඟී ගිය අතර බැරෑරුම් දෙයකට සුදුසු නොවේ.
මෙම හැසිරීම ඉවත් කිරීම සඳහා, අපි මුලින්ම සම්මත niofs වෙත මාරු වූ අතර, පසුව, අපි Elastic හි පස්වන අනුවාදයේ සිට හයවන දක්වා සංක්රමණය වූ විට, අපි මෙම ගැටළුව ප්රතිනිෂ්පාදනය නොකළ hybridfs උත්සාහ කළෙමු. ගබඩා වර්ග ගැන ඔබට වැඩිදුර කියවිය හැකිය .
ගැටලුව හතර
ඉන්පසුව අපි වාර්තාගත කාලයක් සඳහා ප්රතිකාර කළ තවත් ඉතා රසවත් ගැටලුවක් විය. එහි රටාව සම්පූර්ණයෙන්ම තේරුම්ගත නොහැකි නිසා අපි එය මාස 2-3 ක් අල්ලා ගත්තෙමු.
සමහර විට අපගේ සම්බන්ධීකාරකවරුන් සාමාන්‍යයෙන් දිවා ආහාරයෙන් පසුව, සම්පූර්ණ GC වෙත ගිය අතර, එතැනින් ආපසු නොඑන ලදී. ඒ අතරම, GC ප්‍රමාදය ලොග් කරන විට, එය මේ ආකාරයෙන් පෙනුණි: සෑම දෙයක්ම හොඳින් සිදුවෙමින් පවතී, හොඳයි, හොඳයි, පසුව හදිසියේම සියල්ල ඉතා නරක අතට හැරේ.
මුලදී අපි සිතුවේ සම්බන්ධීකාරකවරයා වැඩ කිරීමේ මාදිලියෙන් ඉවතට තල්ලු කරන යම් ආකාරයක ඉල්ලීමක් දියත් කරන දුෂ්ට පරිශීලකයෙකු අප සතුව ඇති බවයි. අපි ඉතා දිගු කාලයක් ඉල්ලීම් ලොග් කර, සිදුවන්නේ කුමක්දැයි සොයා බැලීමට උත්සාහ කළෙමු.
එහි ප්‍රතිඵලයක් වශයෙන්, පරිශීලකයෙකු විශාල ඉල්ලීමක් දියත් කරන මොහොතේදී සහ එය විශේෂිත ඉලාස්ටික් සෙවුම් සම්බන්ධීකාරක වෙත ලැබෙන විට, සමහර නෝඩ් අනෙක් ඒවාට වඩා දිගු ප්‍රතිචාර දක්වන බව පෙනී ගියේය.
සහ සම්බන්ධීකාරක සියලු නෝඩ් වලින් ප්‍රතිචාරයක් බලාපොරොත්තුවෙන් සිටින අතර, ඔහු දැනටමත් ප්‍රතිචාර දක්වා ඇති නෝඩ් වලින් යවන ලද ප්‍රති results ල රැස් කරයි. GC සඳහා, මෙයින් අදහස් කරන්නේ අපගේ ගොඩ භාවිත රටා ඉතා ඉක්මනින් වෙනස් වන බවයි. අපි භාවිතා කළ GC ට මෙම කාර්යය සමඟ සාර්ථකව කටයුතු කිරීමට නොහැකි විය.
මෙම තත්ත්වය තුළ පොකුරේ හැසිරීම වෙනස් කිරීමට අප සොයාගත් එකම විසඳුම වන්නේ JDK13 වෙත සංක්රමණය වීම සහ Shenandoah කුණු එකතු කරන්නා භාවිතා කිරීමයි. මෙය ගැටළුව විසඳා ඇත, අපගේ සම්බන්ධීකාරකවරුන් වැටීම නතර විය.
මෙතනින් තමයි ජාවා වල ප්‍රශ්න ඉවර වෙලා කලාප පළල ගැටළු පටන් ගත්තේ.
Elasticsearch සමඟ "බෙරි": ප්‍රතිදානය
ප්‍රතිදානය සමඟ ඇති ගැටළු වලින් අදහස් වන්නේ අපගේ පොකුර ස්ථායීව ක්‍රියා කරන බවයි, නමුත් සුචිගත කරන ලද ලේඛන ගණනේ උච්චතම අවස්ථාවන්හිදී සහ උපාමාරු වලදී කාර්ය සාධනය ප්‍රමාණවත් නොවේ.
හමු වූ පළමු රෝග ලක්ෂණය: නිෂ්පාදනයේ සමහර "පිපිරුම්" අතරතුර, ලොග් ඉතා විශාල සංඛ්යාවක් හදිසියේ උත්පාදනය වන විට, සුචිගත කිරීමේ දෝෂය es_rejected_execution Graylog හි නිතර නිතර දැල්වීමට පටන් ගනී.
මෙයට හේතු වූයේ එක් දත්ත නෝඩයක thread_pool.write.queue, සුචිගත කිරීමේ ඉල්ලීම සැකසීමට සහ තැටියේ ඇති ෂාර්ඩ් වෙත තොරතුරු උඩුගත කිරීමට Elasticsearch ට හැකි මොහොත දක්වා, පෙරනිමියෙන් ඉල්ලීම් 200ක් පමණක් හැඹිලිගත කළ හැකි වීමයි. සහ තුළ මෙම පරාමිතිය ගැන පවසන්නේ ඉතා අල්ප වශයෙනි. උපරිම නූල් ගණන සහ පෙරනිමි ප්රමාණය පමණක් දක්වා ඇත.
ඇත්ත වශයෙන්ම, අපි මෙම අගය විකෘති කිරීමට ගොස් පහත සඳහන් දෑ සොයා ගත්තෙමු: විශේෂයෙන්, අපගේ සැකසුම තුළ, ඉල්ලීම් 300 ක් දක්වා ඉතා හොඳින් හැඹිලිගත කර ඇති අතර, අපි නැවත සම්පූර්ණ GC වෙත පියාසර කිරීම සමඟ ඉහළ අගයක් පිරී ඇත.
මීට අමතරව, මේවා එක් ඉල්ලීමක් තුළ ලැබෙන පණිවිඩ කාණ්ඩ බැවින්, එය බොහෝ විට සහ කුඩා කණ්ඩායම් වශයෙන් නොව, විශාල කණ්ඩායම් වශයෙන් හෝ කණ්ඩායම තවමත් සම්පූර්ණ වී නොමැති නම් සෑම තත්පර 3 කට වරක් ලිවීමට ග්‍රේලොග් tweak කිරීමට අවශ්ය විය. මෙම අවස්ථාවෙහිදී, ඉලාස්ටික්සර්ච් හි අප ලියන තොරතුරු ලබා ගත හැක්කේ තත්පර දෙකකින් නොව පහකින් (එය අපට හොඳින් ගැලපේ), නමුත් විශාල ප්‍රමාණයක් හරහා තල්ලු කිරීම සඳහා කළ යුතු නැවත ලබා ගැනීමේ ප්‍රමාණයයි. තොරතුරු තොගය අඩු වේ.
සම්පුර්ණයෙන්ම ස්පෑම් කරන ලද ඉලාස්ටික් ලබා නොගන්නා ලෙස යම් දෙයක් කොතැනක හෝ කඩා වැටී කෝපයෙන් ඒ ගැන වාර්තා කරන අවස්ථා වලදී මෙය විශේෂයෙන් වැදගත් වන අතර ටික වේලාවකට පසු - අවහිර වූ බෆර නිසා ක්‍රියා විරහිත වන ග්‍රේලොග් නෝඩ්.
මීට අමතරව, නිෂ්පාදනයේ දී මෙම පිපිරීම් ඇති වූ විට, ක්රමලේඛකයින් සහ පරීක්ෂකයින්ගෙන් අපට පැමිණිලි ලැබුණි: ඔවුන්ට මෙම ලොග් සැබවින්ම අවශ්ය වූ මොහොතේ, ඔවුන් ඉතා සෙමින් ලබා දෙන ලදී.
ඔවුන් එය තේරුම් ගැනීමට පටන් ගත්හ. එක් අතකින්, සෙවුම් විමසුම් සහ සුචිගත කිරීමේ විමසුම් යන දෙකම එකම භෞතික යන්ත්ර මත සකසන ලද අතර එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් යම් යම් අඩුවීම් ඇති බව පැහැදිලිය.
නමුත් ඉලාස්ටික් සෙර්ච් හි හයවන අනුවාද වල, අහඹු රවුන්ඩ් රොබින් මූලධර්මයට අනුව නොව අදාළ දත්ත නෝඩ් අතර විමසුම් බෙදා හැරීමට ඔබට ඉඩ සලසන ඇල්ගොරිතමයක් දර්ශනය වීම නිසා මෙය අර්ධ වශයෙන් මග හැරිය හැක (සුචිගත කර ප්‍රාථමිකය රඳවා තබා ගන්නා බහාලුම. -shard ඉතා කාර්යබහුල විය හැකිය, ඉක්මනින් ප්‍රතිචාර දැක්වීමට ක්‍රමයක් නොමැත), නමුත් මෙම ඉල්ලීම වඩා වේගයෙන් ප්‍රතිචාර දක්වන අනුරුවක් සහිත අඩු පටවන ලද බහාලුමක් වෙත යොමු කිරීම. වෙනත් වචන වලින් කිවහොත්, අපි use_adaptive_replica_selection වෙත පැමිණියෙමු: true.
කියවීමේ පින්තූරය මේ ආකාරයෙන් පෙනෙන්නට පටන් ගනී:
මෙම ඇල්ගොරිතමයට සංක්රමණය වීම නිසා අපට ලිවීමට විශාල ලඝු ප්‍රවාහයක් තිබූ එම අවස්ථාවන්හි විමසුම් කාලය සැලකිය යුතු ලෙස වැඩිදියුණු කිරීමට හැකි විය.
අවසාන වශයෙන්, ප්රධාන ගැටළුව වූයේ දත්ත මධ්යස්ථානයේ වේදනා රහිතව ඉවත් කිරීමයි.
එක් DC එකක සම්බන්ධතාවය නැති වූ වහාම පොකුරෙන් අපට අවශ්ය දේ:
- අසමත් වූ දත්ත මධ්යස්ථානයේ අපට වත්මන් ප්‍රධානයක් තිබේ නම්, එය නැවත තෝරා වෙනත් DC එකක වෙනත් නෝඩයකට භූමිකාවක් ලෙස ගෙන යනු ඇත.
- ස්වාමියා පොකුරෙන් ප්රවේශ විය නොහැකි සියලුම නෝඩ් ඉක්මනින් ඉවත් කරයි.
- ඉතිරි ඒවා මත පදනම්ව, ඔහු තේරුම් ගනු ඇත: නැතිවූ දත්ත මධ්යස්ථානයේ අපට එවැනි සහ එවැනි ප්‍රාථමික කොටස් තිබුණි, ඔහු ඉතිරි දත්ත මධ්‍යස්ථානවල අනුපූරක අනුරූ කැබලි ඉක්මනින් ප්‍රවර්ධනය කරනු ඇති අතර අපි දත්ත සුචිගත කිරීම දිගටම කරගෙන යන්නෙමු.
- මෙහි ප්‍රතිඵලයක් වශයෙන්, පොකුරු ලිවීමේ සහ කියවීමේ ප්‍රතිදානය ක්‍රමයෙන් පිරිහෙනු ඇත, නමුත් පොදුවේ සෑම දෙයක්ම සෙමින්, නමුත් ස්ථාවරව ක්‍රියාත්මක වනු ඇත.
එය සිදු වූ පරිදි, අපට මෙවැනි දෙයක් අවශ්ය විය:
තවද අපට පහත සඳහන් දෑ ලැබුණි:
මෙය සිදුවූයේ කෙසේ?
ඩේටා සෙන්ටර් එක වැටුනම අපේ ස්වාමියා බෝතලේ උනා.
ඇයි?
කාරණය නම්, ස්වාමියාට TaskBatcher එකක් ඇති අතර, එය පොකුරේ ඇතැම් කාර්යයන් සහ සිදුවීම් බෙදා හැරීම සඳහා වගකිව යුතුය. ඕනෑම නෝඩ් පිටවීම, අනුරුවේ සිට ප්‍රාථමිකය දක්වා කැබැල්ලක් ප්‍රවර්ධනය කිරීම, කොතැනක හෝ කැබැල්ලක් සෑදීමට ඕනෑම කාර්යයක් - මේ සියල්ල පළමුව TaskBatcher වෙත යයි, එහිදී එය අනුක්‍රමිකව සහ එක් නූල් එකකින් සකසනු ලැබේ.
එක් දත්ත මධ්‍යස්ථානයක් ඉවත් කර ගන්නා අවස්ථාවේදී, ඉතිරිව ඇති දත්ත මධ්‍යස්ථානවල සියලුම දත්ත නෝඩ් “අපට එවැනි කැබලි සහ එවැනි දත්ත නෝඩ් නැති වී ඇත” යනුවෙන් ස්වාමියාට දැනුම් දීම ඔවුන්ගේ යුතුකම ලෙස සලකන බව පෙනී ගියේය.
ඒ අතරම, ඉතිරිව ඇති දත්ත නෝඩ් මෙම සියලු තොරතුරු වත්මන් මාස්ටර් වෙත යවා ඔහු එය පිළිගත් බව තහවුරු කිරීම සඳහා බලා සිටීමට උත්සාහ කළේය. ස්වාමියාට පිළිතුරු දීමට වඩා වේගයෙන් කාර්යයන් ලැබුණු බැවින් ඔවුන් මේ සඳහා බලා සිටියේ නැත. නෝඩ් පුනරාවර්තන ඉල්ලීම් කල් ඉකුත් වූ අතර, මේ අවස්ථාවේ ස්වාමියා ඒවාට පිළිතුරු දීමට උත්සාහ නොකළ නමුත් ප්‍රමුඛතාවය අනුව ඉල්ලීම් වර්ග කිරීමේ කාර්යයට සම්පූර්ණයෙන්ම අවශෝෂණය විය.
ටර්මිනල් ආකාරයෙන්, දත්ත නෝඩ් සම්පූර්ණ GC වෙත යන මට්ටමට මාස්ටර් ස්පෑම් කළ බව පෙනී ගියේය. ඊට පසු, අපගේ ප්රධාන භූමිකාව ඊළඟ නෝඩයකට මාරු විය, එයට සිදු වූයේ එකම දෙයයි, එහි ප්‍රතිඵලයක් ලෙස පොකුර සම්පූර්ණයෙන්ම කඩා වැටුණි.
අපි මිනුම් ලබා ගත් අතර, මෙය සවි කර ඇති 6.4.0 අනුවාදයට පෙර, පොකුර සම්පූර්ණයෙන්ම වසා දැමීම සඳහා 10 න් දත්ත නෝඩ් 360 ක් එකවර ප්‍රතිදානය කිරීම අපට ප්‍රමාණවත් විය.
එය මේ වගේ දෙයක් පෙනුණා:
6.4.0 අනුවාදයෙන් පසුව, මෙම භයානක දෝෂය නිරාකරණය කළ විට, දත්ත නෝඩ් ස්වාමියා මරා දැමීම නතර කළේය. නමුත් එය ඔහුව "බුද්ධිමත්" කළේ නැත. එනම්: අපි දත්ත නෝඩ් 2, 3 හෝ 10 (එකක් හැර වෙනත් ඕනෑම අංකයක්) ප්‍රතිදානය කරන විට, ස්වාමියාට නෝඩය A ඉවත්ව ගොස් ඇති බව පවසන පළමු පණිවිඩය ලැබෙන අතර, මේ ගැන node B, node C, node D කියන්නට උත්සාහ කරයි.
මේ මොහොතේ, මෙය සමඟ කටයුතු කළ හැක්කේ තත්පර 20-30 කට සමාන යමක් ගැන යමෙකුට පැවසීමට දරන උත්සාහයන් සඳහා කාල සීමාවක් සැකසීමෙන් පමණක් වන අතර එමඟින් පොකුරෙන් පිටතට යන දත්ත මධ්යස්ථානයේ වේගය පාලනය කරයි.
ප්‍රතිපත්තිමය වශයෙන්, මෙය ව්‍යාපෘතියේ කොටසක් ලෙස අවසාන නිෂ්පාදනයට මුලින් ඉදිරිපත් කරන ලද අවශ්යතා වලට ගැලපේ, නමුත් “පිරිසිදු විද්‍යාවේ” දෘෂ්ටි කෝණයෙන් මෙය දෝෂයකි. එය, 7.2 අනුවාදයේ සංවර්ධකයින් විසින් සාර්ථකව සවි කර ඇත.
එපමනක් නොව, යම් දත්ත නෝඩයක් පිටතට ගිය විට, එහි පිටවීම පිළිබඳ තොරතුරු බෙදා හැරීම සමස්ත පොකුරට එවැනි සහ එවැනි ප්‍රාථමික කැබලි ඇති බව පැවසීමට වඩා වැදගත් බව පෙනී ගියේය (වෙනත් දත්තයක අනුරුවක් ප්‍රවර්ධනය කිරීම සඳහා ප්‍රාථමිකයේ කේන්ද්‍රය, සහ තොරතුරු ඒවා මත ලිවිය හැකිය).
එමනිසා, සෑම දෙයක්ම දැනටමත් මිය ගොස් ඇති විට, නිකුත් කරන ලද දත්ත නෝඩ් ක්ෂණිකව පරණ ලෙස සලකුණු නොකෙරේ. ඒ අනුව, නිකුත් කරන ලද දත්ත නෝඩ් වෙත සියලුම පිං කාලය අවසන් වන තෙක් බලා සිටීමට අපට බල කෙරෙන අතර, ඉන් පසුව පමණක් අපගේ පොකුර අපට කියන්නට පටන් ගන්නේ එහි, එහි සහ එහි දිගටම තොරතුරු පටිගත කළ යුතු බවයි. ඔබට මේ ගැන වැඩිදුර කියවිය හැකිය .
එහි ප්‍රතිඵලයක් ලෙස අද දින දත්ත මධ්‍යස්ථානයක් ඉවත් කර ගැනීමේ ක්‍රියාන්විතය කාර්ය බහුල වේලාවේදී අපට විනාඩි 5ක් පමණ ගත වේ. එවැනි විශාල හා අවුල් සහගත කොලොසස් සඳහා, මෙය ඉතා හොඳ ප්රතිඵලයකි.
එහි ප්‍රතිඵලයක් වශයෙන් අපි පහත තීරණයට එළඹුනෙමු.
- අපට ගිගාබයිට් තැටි 360 ක් සහිත දත්ත නෝඩ් 700 ක් ඇත.
- මෙම දත්ත නෝඩ් හරහා ගමනාගමනය මෙහෙයවීම සඳහා සම්බන්ධීකාරකවරුන් 60ක්.
- 40 ට පෙර අනුවාදවල සිට අප විසින් උරුමයක් ලෙස ඉතිරි කර ඇති ස්වාමිවරුන් 6.4.0 ක් - දත්ත මධ්‍යස්ථානය ඉවත් කර ගැනීමෙන් බේරීම සඳහා, මාස්ටර් ගණපූරණයක් ඇති බවට සහතික වීම සඳහා යන්ත්ර කිහිපයක් අහිමි වීමට අපි මානසිකව සූදානම්ව සිටියෙමු. නරකම අවස්ථාව
- එක් කන්ටේනරයක භූමිකාවන් ඒකාබද්ධ කිරීමට ගන්නා ඕනෑම උත්සාහයක් ඉක්මනින් හෝ පසුව නෝඩය බරින් බිඳ වැටෙනු ඇත.
- මුළු පොකුරම ගිගාබයිට් 31 ක ගොඩක් භාවිතා කරයි: ප්රමාණය අඩු කිරීමට දරන සියලු උත්සාහයන් ප්‍රධානතම වයිල්ඩ්කාඩ් සමඟ අධික සෙවුම් විමසුම්වල සමහර නෝඩ් විනාශ කිරීමට හෝ ප්‍රත්‍යාස්ථ සෙවීමේදීම පරිපථ කඩනය ලබා ගැනීමට හේතු විය.
- ඊට අමතරව, සෙවුම් කාර්ය සාධනය සහතික කිරීම සඳහා, අපි ප්‍රධානියා තුළ ලබා ගත් බාධකයේ හැකි තරම් සිදුවීම් කිහිපයක් සැකසීම සඳහා, පොකුරේ ඇති වස්තූන් සංඛ්‍යාව හැකි තරම් කුඩාව තබා ගැනීමට අපි උත්සාහ කළෙමු.
අවසාන වශයෙන් අධීක්ෂණය ගැන
මේ සියල්ල අපේක්ෂිත පරිදි ක්‍රියාත්මක වන බව සහතික කිරීම සඳහා, අපි පහත සඳහන් දෑ නිරීක්ෂණය කරමු:
- සෑම දත්ත නෝඩයක්ම එය පවතින බව අපගේ වලාකුළට වාර්තා කරයි, එහි එවැනි සහ එවැනි කැබලි තිබේ. අපි කොහේ හරි දෙයක් නිවා දමන විට, පොකුරු තත්පර 2-3 කට පසු වාර්තා කරන්නේ A මධ්‍යයේ අපි 2, 3 සහ 4 නෝඩ් නිවා දැමූ බවයි - මෙයින් අදහස් කරන්නේ වෙනත් දත්ත මධ්‍යස්ථානවල අපට කිසිදු තත්වයක් යටතේ එක කැබැල්ලක් පමණක් ඇති එම නෝඩ් නිවා දැමිය නොහැකි බවයි. අත්හැරියා.
- ස්වාමියාගේ හැසිරීමේ ස්වභාවය දැන ගැනීම, අපි ඉතා ප්රවේශමෙන් අපේක්ෂිත කාර්යයන් ගණන දෙස බලමු. මක්නිසාද යත් එක් සිරවී ඇති කාර්යයක් පවා නියමිත වේලාවට නොපැමිණෙන්නේ නම්, න්‍යායාත්මකව සමහර හදිසි අවස්ථාවන්හිදී, උදාහරණයක් ලෙස, ප්‍රාථමිකයේ අනුපිටපත් කැබැල්ලක් ප්‍රවර්ධනය කිරීම ක්‍රියා නොකිරීමට හේතුව බවට පත්විය හැකිය, ඒ නිසා සුචිගත කිරීම ක්‍රියා කිරීම නවත්වනු ඇත.
- ප්‍රශස්තකරණයේදී අපට දැනටමත් විශාල දුෂ්කරතා ඇති වී ඇති නිසා අපි කුණු එකතු කරන්නන්ගේ ප්‍රමාදයන් පිළිබඳවද ඉතා සමීපව බලමු.
- ත්‍රෙඩ් එකෙන් ප්‍රතික්‍ෂේප කරනවා බෝතල්නෙක් එක කොතනද කියලා කලින්ම තේරුම් ගන්න.
- හොඳයි, ගොඩ, RAM සහ I/O වැනි සම්මත ප්‍රමිතික.
අධීක්ෂණ ගොඩනඟන විට, ඔබ ඉලාස්ටික් සෙවුමේ නූල් සංචිතයේ විශේෂාංග සැලකිල්ලට ගත යුතුය. සෙවුම් සහ සුචිගත කිරීම සඳහා වින්‍යාස කිරීමේ විකල්ප සහ පෙරනිමි අගයන් විස්තර කරයි, නමුත් thread_pool.management ගැන සම්පූර්ණයෙන්ම නිශ්ශබ්ද වේ.මෙම නූල් ක්‍රියාවලි කරයි, විශේෂයෙන්, _cat/shards වැනි විමසුම් සහ අනෙකුත් සමාන ඒවා, අධීක්ෂණය ලිවීමේදී භාවිතා කිරීමට පහසු වේ. පොකුර විශාල වන තරමට, කාල ඒකකයකට එවැනි ඉල්ලීම් ක්‍රියාත්මක වන අතර, ඉහත සඳහන් කළ thread_pool.management නිල ලේඛනවල ඉදිරිපත් නොකරනවා පමණක් නොව, පෙරනිමියෙන් නූල් 5 කට සීමා වේ, එය ඉතා ඉක්මනින් ඉවත් කරනු ලැබේ. කුමන අධීක්ෂණය නිවැරදිව ක්‍රියා කිරීම නවත්වයි.
මට අවසාන වශයෙන් පැවසීමට අවශ්ය දේ: අපි එය කළා! අපගේ ක්‍රමලේඛකයින්ට සහ සංවර්ධකයින්ට ඕනෑම තත්වයක් පාහේ, නිෂ්පාදනයේ සිදුවන දේ පිළිබඳ තොරතුරු ඉක්මනින් සහ විශ්වාසදායක ලෙස ලබා දිය හැකි මෙවලමක් ලබා දීමට අපට හැකි විය.
ඔව්, එය තරමක් සංකීර්ණ වූ නමුත්, කෙසේ වෙතත්, අපගේ කැමැත්ත පවතින නිෂ්පාදනවලට ගැලපීමට අපි සමත් වූ අතර, එය අප විසින්ම ඇලවීමට සහ නැවත ලිවීමට අවශ්ය නොවීය.
මූලාශ්රය: www.habr.com