સ્થિતિસ્થાપક શોધ ક્લસ્ટર 200 TB+

ઘણા લોકો Elasticsearch સાથે સંઘર્ષ કરે છે. પરંતુ જ્યારે તમે તેનો ઉપયોગ "ખાસ કરીને મોટા જથ્થામાં" લોગ સ્ટોર કરવા માટે કરવા માંગતા હો ત્યારે શું થાય છે? અને શું કેટલાક ડેટા સેન્ટરોમાંથી કોઈપણની નિષ્ફળતાનો અનુભવ કરવો તે પીડારહિત છે? તમારે કેવા પ્રકારનું આર્કિટેક્ચર બનાવવું જોઈએ, અને તમે કયા મુશ્કેલીઓનો સામનો કરશો?

અમે ઓડનોક્લાસ્નીકી ખાતે લોગ મેનેજમેન્ટના મુદ્દાને ઉકેલવા માટે સ્થિતિસ્થાપક શોધનો ઉપયોગ કરવાનું નક્કી કર્યું, અને હવે અમે અમારો અનુભવ Habr સાથે શેર કરીએ છીએ: આર્કિટેક્ચર અને મુશ્કેલીઓ બંને વિશે.

હું પ્યોત્ર ઝૈત્સેવ છું, હું ઓડનોક્લાસ્નીકીમાં સિસ્ટમ એડમિનિસ્ટ્રેટર તરીકે કામ કરું છું. તે પહેલાં, હું એડમિન પણ હતો, મેંટિકોર સર્ચ, સ્ફિન્ક્સ સર્ચ, ઇલાસ્ટિકસર્ચ સાથે કામ કર્યું હતું. કદાચ, જો બીજી ...શોધ દેખાય, તો હું કદાચ તેની સાથે પણ કામ કરીશ. હું સ્વૈચ્છિક ધોરણે સંખ્યાબંધ ઓપન સોર્સ પ્રોજેક્ટ્સમાં પણ ભાગ લઉં છું.

જ્યારે હું ઓડનોક્લાસ્નીકી આવ્યો, ત્યારે મેં ઇન્ટરવ્યુમાં બેદરકારીથી કહ્યું કે હું ઇલાસ્ટિકસર્ચ સાથે કામ કરી શકું છું. મેં તેને હેંગ કર્યા પછી અને કેટલાક સરળ કાર્યો પૂર્ણ કર્યા પછી, મને તે સમયે અસ્તિત્વમાં રહેલી લોગ મેનેજમેન્ટ સિસ્ટમમાં સુધારો કરવાનું મોટું કાર્ય સોંપવામાં આવ્યું હતું.

જરૂરીયાતો

સિસ્ટમ આવશ્યકતાઓ નીચે પ્રમાણે ઘડવામાં આવી હતી:

• ગ્રેલોગનો ઉપયોગ અગ્રભાગ તરીકે થવાનો હતો. કારણ કે કંપનીને આ ઉત્પાદનનો ઉપયોગ કરવાનો અનુભવ પહેલેથી જ હતો, પ્રોગ્રામરો અને પરીક્ષકો તે જાણતા હતા, તે તેમના માટે પરિચિત અને અનુકૂળ હતું.
• ડેટા વોલ્યુમ: સરેરાશ 50-80 હજાર સંદેશા પ્રતિ સેકન્ડ, પરંતુ જો કંઈક તૂટી જાય, તો ટ્રાફિક કોઈ પણ વસ્તુથી મર્યાદિત નથી, તે પ્રતિ સેકન્ડ 2-3 મિલિયન લાઇન હોઈ શકે છે.
• ગ્રાહકો સાથે શોધ ક્વેરીઝની પ્રક્રિયા કરવાની ઝડપ માટેની આવશ્યકતાઓ અંગે ચર્ચા કર્યા પછી, અમને સમજાયું કે આવી સિસ્ટમનો ઉપયોગ કરવાની લાક્ષણિક પેટર્ન આ છે: લોકો છેલ્લા બે દિવસથી તેમની અરજીના લોગ્સ શોધી રહ્યા છે અને એક કરતાં વધુ રાહ જોવા માંગતા નથી. ફોર્મ્યુલેટેડ ક્વેરીનાં પરિણામ માટે બીજું.
• પ્રબંધકોએ ભારપૂર્વક જણાવ્યું હતું કે જો જરૂરી હોય તો સિસ્ટમ સરળતાથી માપી શકાય તેવી છે, તે કેવી રીતે કાર્ય કરે છે તેની ઊંડાણપૂર્વક તપાસ કરવાની જરૂર વગર.
• જેથી આ સિસ્ટમોને સમયાંતરે જરૂરી જાળવણી કાર્ય માટે અમુક હાર્ડવેર બદલવાનું છે.
• વધુમાં, ઓડનોક્લાસ્નીકી પાસે ઉત્તમ તકનીકી પરંપરા છે: અમે જે પણ સેવા શરૂ કરીએ છીએ તે ડેટા સેન્ટરની નિષ્ફળતા (અચાનક, બિનઆયોજિત અને સંપૂર્ણપણે કોઈપણ સમયે) ટકી રહેવી જોઈએ.

આ પ્રોજેક્ટના અમલીકરણમાં છેલ્લી જરૂરિયાત અમને સૌથી વધુ ખર્ચ કરે છે, જેના વિશે હું વધુ વિગતવાર વાત કરીશ.

પર્યાવરણ

અમે ચાર ડેટા કેન્દ્રોમાં કામ કરીએ છીએ, જ્યારે Elasticsearch ડેટા નોડ્સ માત્ર ત્રણમાં જ સ્થિત હોઈ શકે છે (ઘણા બિન-તકનીકી કારણોસર).

આ ચાર ડેટા સેન્ટર્સમાં આશરે 18 હજાર વિવિધ લોગ સ્ત્રોતો - હાર્ડવેર, કન્ટેનર, વર્ચ્યુઅલ મશીનો છે.

મહત્વપૂર્ણ લક્ષણ: ક્લસ્ટર કન્ટેનરમાં શરૂ થાય છે પોડમેન ભૌતિક મશીનો પર નહીં, પરંતુ ચાલુ પોતાની ક્લાઉડ પ્રોડક્ટ વન-ક્લાઉડ. કન્ટેનરને 2 કોરોની ખાતરી આપવામાં આવે છે, 2.0Ghz v4 ની જેમ, બાકીના કોરો નિષ્ક્રિય હોય તો તેને રિસાયકલ કરવાની શક્યતા સાથે.

બીજા શબ્દો માં:

ટોપોલોજી

મેં શરૂઆતમાં સોલ્યુશનનું સામાન્ય સ્વરૂપ નીચે મુજબ જોયું:

• ગ્રેલોગ ડોમેનના A-રેકોર્ડ પાછળ 3-4 VIPs છે, આ તે સરનામું છે કે જેના પર લોગ મોકલવામાં આવે છે.
• દરેક VIP એ LVS બેલેન્સર છે.
• તે પછી, લોગ્સ ગ્રેલોગ બેટરી પર જાય છે, કેટલાક ડેટા GELF ફોર્મેટમાં છે, કેટલાક syslog ફોર્મેટમાં છે.
• પછી આ બધું ઇલાસ્ટિકસર્ચ કોઓર્ડિનેટર્સની બેટરીમાં મોટા બેચમાં લખાયેલું છે.
• અને તેઓ, બદલામાં, સંબંધિત ડેટા નોડ્સને લખવા અને વાંચવાની વિનંતીઓ મોકલે છે.

પરિભાષા

કદાચ દરેક જણ પરિભાષાને વિગતવાર સમજી શકતા નથી, તેથી હું તેના પર થોડું ધ્યાન આપવા માંગુ છું.

ઇલાસ્ટિકસર્ચમાં ઘણા પ્રકારના નોડ્સ છે - માસ્ટર, કોઓર્ડિનેટર, ડેટા નોડ. વિવિધ લૉગ ટ્રાન્સફોર્મેશન અને વિવિધ ક્લસ્ટરો વચ્ચેના સંચાર માટે અન્ય બે પ્રકારો છે, પરંતુ અમે ફક્ત સૂચિબદ્ધ તેનો ઉપયોગ કર્યો છે.

માસ્ટર
તે ક્લસ્ટરમાં હાજર તમામ નોડ્સને પિંગ કરે છે, અપ-ટૂ-ડેટ ક્લસ્ટર મેપને જાળવી રાખે છે અને તેને નોડ્સ વચ્ચે વિતરિત કરે છે, ઇવેન્ટ લોજિકની પ્રક્રિયા કરે છે અને વિવિધ પ્રકારના ક્લસ્ટર વાઈડ હાઉસકીપિંગ કરે છે.

કોઓર્ડિનેટર
એક જ કાર્ય કરે છે: ક્લાયંટ તરફથી વાંચવા અથવા લખવાની વિનંતીઓ સ્વીકારે છે અને આ ટ્રાફિકને રૂટ કરે છે. જો કોઈ લખવાની વિનંતી હોય, તો સંભવતઃ, તે માસ્ટરને પૂછશે કે તેને સંબંધિત ઇન્ડેક્સના કયા શાર્ડમાં મૂકવું જોઈએ, અને વિનંતીને આગળ રીડાયરેક્ટ કરશે.

ડેટા નોડ
ડેટા સ્ટોર કરે છે, બહારથી આવતા સર્ચ ક્વેરી કરે છે અને તેના પર સ્થિત શાર્ડ્સ પર કામગીરી કરે છે.

ગ્રેલોગ
આ ELK સ્ટેકમાં Logstash સાથે કિબાનાના ફ્યુઝન જેવું કંઈક છે. ગ્રેલોગ UI અને લોગ પ્રોસેસિંગ પાઇપલાઇન બંનેને જોડે છે. હૂડ હેઠળ, ગ્રેલોગ કાફકા અને ઝૂકીપર ચલાવે છે, જે ગ્રેલોગને ક્લસ્ટર તરીકે કનેક્ટિવિટી પ્રદાન કરે છે. Elasticsearch અનુપલબ્ધ હોવાના કિસ્સામાં ગ્રેલોગ લોગ્સ (કાફકા) કેશ કરી શકે છે અને સ્પષ્ટ નિયમો અનુસાર અસફળ વાંચવા અને લખવાની વિનંતીઓ, જૂથ અને માર્ક લોગનું પુનરાવર્તન કરી શકે છે. Logstash ની જેમ, Graylog પાસે પંક્તિઓને Elasticsearch પર લખતા પહેલા તેને સંશોધિત કરવાની કાર્યક્ષમતા છે.

વધુમાં, ગ્રેલોગ પાસે બિલ્ટ-ઇન સર્વિસ ડિસ્કવરી છે જે એક ઉપલબ્ધ ઈલાસ્ટિકસર્ચ નોડના આધારે સમગ્ર ક્લસ્ટર મેપ મેળવવા અને તેને ચોક્કસ ટેગ દ્વારા ફિલ્ટર કરવાની મંજૂરી આપે છે, જે ચોક્કસ કન્ટેનર પર વિનંતીઓ મોકલવાનું શક્ય બનાવે છે.

દૃષ્ટિની રીતે તે કંઈક આના જેવું લાગે છે:

આ ચોક્કસ ઉદાહરણમાંથી સ્ક્રીનશોટ છે. અહીં આપણે શોધ ક્વેરી પર આધારિત હિસ્ટોગ્રામ બનાવીએ છીએ અને સંબંધિત પંક્તિઓ પ્રદર્શિત કરીએ છીએ.

સૂચકાંકો

સિસ્ટમ આર્કિટેક્ચર પર પાછા ફરીને, હું ઇન્ડેક્સ મોડેલ કેવી રીતે બનાવ્યું તેના પર વધુ વિગતવાર ધ્યાન આપવા માંગુ છું જેથી તે બધું યોગ્ય રીતે કાર્ય કરે.

ઉપરના ચિત્રમાં, આ સૌથી નીચું સ્તર છે: સ્થિતિસ્થાપક શોધ ડેટા નોડ્સ.

ઇન્ડેક્સ એ ઇલાસ્ટિકસર્ચ શાર્ડ્સથી બનેલી મોટી વર્ચ્યુઅલ એન્ટિટી છે. પોતે જ, દરેક શાર્ડ લ્યુસીન ઇન્ડેક્સ કરતાં વધુ કંઈ નથી. અને દરેક લ્યુસીન ઇન્ડેક્સ, બદલામાં, એક અથવા વધુ સેગમેન્ટ્સ ધરાવે છે.

ડિઝાઇન કરતી વખતે, અમે વિચાર્યું કે મોટી માત્રામાં ડેટા પર વાંચવાની ઝડપની જરૂરિયાતને પહોંચી વળવા માટે, અમારે આ ડેટાને સમગ્ર ડેટા નોડ્સમાં સમાનરૂપે "સ્પ્રેડ" કરવાની જરૂર છે.

આ હકીકતમાં પરિણમ્યું કે ઇન્ડેક્સ દીઠ શાર્ડ્સની સંખ્યા (પ્રતિકૃતિઓ સાથે) ડેટા નોડ્સની સંખ્યા જેટલી સખત રીતે સમાન હોવી જોઈએ. પ્રથમ, બે સમાન પ્રતિકૃતિ પરિબળને સુનિશ્ચિત કરવા માટે (એટલે ​​​​કે, આપણે ક્લસ્ટરનો અડધો ભાગ ગુમાવી શકીએ છીએ). અને, બીજું, ક્લસ્ટરના ઓછામાં ઓછા અડધા ભાગ પર વિનંતીઓ વાંચવા અને લખવાની પ્રક્રિયા કરવા માટે.

અમે સૌ પ્રથમ 30 દિવસ તરીકે સંગ્રહ સમય નક્કી કર્યો.

શાર્ડનું વિતરણ નીચે પ્રમાણે ગ્રાફિકલી રીતે રજૂ કરી શકાય છે:

આખો ઘેરો રાખોડી લંબચોરસ ઇન્ડેક્સ છે. તેમાં ડાબો લાલ ચોરસ પ્રાથમિક શાર્ડ છે, જે અનુક્રમણિકામાં પ્રથમ છે. અને વાદળી ચોરસ પ્રતિકૃતિ શાર્ડ છે. તેઓ વિવિધ ડેટા સેન્ટરોમાં સ્થિત છે.

જ્યારે આપણે બીજો શાર્ડ ઉમેરીએ છીએ, ત્યારે તે ત્રીજા ડેટા સેન્ટરમાં જાય છે. અને, અંતે, અમને આ માળખું મળે છે, જે ડેટા સુસંગતતા ગુમાવ્યા વિના DC ગુમાવવાનું શક્ય બનાવે છે:

અનુક્રમણિકાઓનું પરિભ્રમણ, એટલે કે. નવી અનુક્રમણિકા બનાવીને અને સૌથી જૂનીને કાઢી નાખીને, અમે તેને 48 કલાકની બરાબર બનાવી છે (ઇન્ડેક્સના ઉપયોગની પેટર્ન અનુસાર: છેલ્લા 48 કલાકો મોટાભાગે શોધવામાં આવે છે).

આ ઇન્ડેક્સ રોટેશન અંતરાલ નીચેના કારણોસર છે:

જ્યારે શોધ વિનંતી ચોક્કસ ડેટા નોડ પર આવે છે, ત્યારે, પ્રદર્શનના દૃષ્ટિકોણથી, તે વધુ નફાકારક છે જ્યારે એક શાર્ડની પૂછપરછ કરવામાં આવે છે, જો તેનું કદ નોડના હિપના કદ સાથે તુલનાત્મક હોય. આ તમને ઇન્ડેક્સના "ગરમ" ભાગને ઢગલામાં રાખવા અને તેને ઝડપથી ઍક્સેસ કરવાની મંજૂરી આપે છે. જ્યારે ઘણા બધા "ગરમ ભાગો" હોય છે, ત્યારે અનુક્રમણિકા શોધની ઝડપ ઘટે છે.

જ્યારે નોડ એક શાર્ડ પર શોધ ક્વેરી ચલાવવાનું શરૂ કરે છે, ત્યારે તે ભૌતિક મશીનના હાઇપરથ્રેડીંગ કોરોની સંખ્યા જેટલી સંખ્યાબંધ થ્રેડો ફાળવે છે. જો શોધ ક્વેરી મોટી સંખ્યામાં શાર્ડ્સને અસર કરે છે, તો પછી થ્રેડોની સંખ્યા પ્રમાણસર વધે છે. આ શોધ ગતિ પર નકારાત્મક અસર કરે છે અને નવા ડેટાના અનુક્રમણિકાને નકારાત્મક અસર કરે છે.

જરૂરી શોધ લેટન્સી પ્રદાન કરવા માટે, અમે SSD નો ઉપયોગ કરવાનું નક્કી કર્યું. વિનંતીઓ પર ઝડપથી પ્રક્રિયા કરવા માટે, આ કન્ટેનરને હોસ્ટ કરતી મશીનો પાસે ઓછામાં ઓછા 56 કોરો હોવા જોઈએ. 56 નો આંકડો શરતી રીતે પર્યાપ્ત મૂલ્ય તરીકે પસંદ કરવામાં આવ્યો હતો જે ઇલાસ્ટિકસર્ચ ઓપરેશન દરમિયાન જનરેટ કરશે તે થ્રેડોની સંખ્યા નક્કી કરે છે. Elasitcsearch માં, ઘણા થ્રેડ પૂલ પરિમાણો સીધા ઉપલબ્ધ કોરોની સંખ્યા પર આધાર રાખે છે, જે બદલામાં "ઓછા કોરો - વધુ ગાંઠો" ના સિદ્ધાંત અનુસાર ક્લસ્ટરમાં નોડ્સની આવશ્યક સંખ્યાને સીધી અસર કરે છે.

પરિણામે, અમને જાણવા મળ્યું કે સરેરાશ એક શાર્ડનું વજન લગભગ 20 ગીગાબાઇટ્સ છે, અને ઇન્ડેક્સ દીઠ 1 શાર્ડ્સ છે. તદનુસાર, જો આપણે તેમને દર 360 કલાકમાં એકવાર ફેરવીએ, તો આપણી પાસે તેમાંથી 48 છે. દરેક ઇન્ડેક્સમાં 15 દિવસનો ડેટા હોય છે.

ડેટા લેખન અને વાંચન સર્કિટ

ચાલો જાણીએ કે આ સિસ્ટમમાં ડેટા કેવી રીતે રેકોર્ડ થાય છે.

ચાલો કહીએ કે ગ્રેલોગથી સંયોજકને કેટલીક વિનંતી આવે છે. ઉદાહરણ તરીકે, અમે 2-3 હજાર પંક્તિઓને અનુક્રમિત કરવા માંગીએ છીએ.

કોઓર્ડિનેટર, ગ્રેલોગ તરફથી વિનંતી પ્રાપ્ત કર્યા પછી, માસ્ટરને પ્રશ્ન કરે છે: "ઇન્ડેક્સિંગ વિનંતીમાં, અમે ખાસ કરીને એક અનુક્રમણિકાનો ઉલ્લેખ કર્યો છે, પરંતુ તે કયા શાર્ડમાં લખવો તે સ્પષ્ટ નથી."

માસ્ટર જવાબ આપે છે: "આ માહિતીને શાર્ડ નંબર 71 પર લખો," ત્યારબાદ તે સીધી સંબંધિત ડેટા નોડ પર મોકલવામાં આવે છે, જ્યાં પ્રાથમિક-શાર્ડ નંબર 71 સ્થિત છે.

જે પછી ટ્રાન્ઝેક્શન લોગને પ્રતિકૃતિ-શાર્ડ પર પ્રતિકૃતિ કરવામાં આવે છે, જે અન્ય ડેટા સેન્ટરમાં સ્થિત છે.

ગ્રેલોગથી કોઓર્ડિનેટરને શોધ વિનંતી આવે છે. સંયોજક તેને અનુક્રમણિકા અનુસાર રીડાયરેક્ટ કરે છે, જ્યારે Elasticsearch રાઉન્ડ-રોબિન સિદ્ધાંતનો ઉપયોગ કરીને પ્રાથમિક-શાર્ડ અને પ્રતિકૃતિ-શાર્ડ વચ્ચે વિનંતીઓનું વિતરણ કરે છે.

180 નોડ્સ અસમાન રીતે પ્રતિસાદ આપે છે, અને જ્યારે તેઓ પ્રતિસાદ આપી રહ્યા હોય, ત્યારે કોઓર્ડિનેટર માહિતી એકઠા કરી રહ્યા છે જે પહેલાથી જ ઝડપી ડેટા નોડ્સ દ્વારા "થૂંકી દેવામાં આવી" છે. આ પછી, જ્યારે કાં તો બધી માહિતી આવી જાય છે, અથવા વિનંતી સમય સમાપ્ત થઈ જાય છે, ત્યારે તે બધું સીધું ક્લાયન્ટને આપે છે.

આ સમગ્ર સિસ્ટમ સરેરાશ છેલ્લા 48 કલાક માટે 300-400ms માં શોધ ક્વેરી પર પ્રક્રિયા કરે છે, જેમાં અગ્રણી વાઇલ્ડકાર્ડ સાથેની તે ક્વેરીઝને બાદ કરતાં.

Elasticsearch સાથે ફૂલો: Java સેટઅપ

અમે મૂળ રીતે ઇચ્છીએ છીએ તે રીતે તે બધું કાર્ય કરવા માટે, અમે ક્લસ્ટરમાં વિવિધ પ્રકારની વસ્તુઓને ડીબગ કરવામાં ઘણો લાંબો સમય પસાર કર્યો.

શોધાયેલ સમસ્યાઓનો પ્રથમ ભાગ ઇલાસ્ટિકસર્ચમાં ડિફોલ્ટ રૂપે જાવા જે રીતે પૂર્વ-રૂપરેખાંકિત છે તેનાથી સંબંધિત હતો.

સમસ્યા એક
અમે ખૂબ મોટી સંખ્યામાં અહેવાલો જોયા છે કે લ્યુસીન સ્તરે, જ્યારે પૃષ્ઠભૂમિ જોબ્સ ચાલી રહી હોય, ત્યારે લ્યુસીન સેગમેન્ટ ભૂલ સાથે નિષ્ફળ જાય છે. તે જ સમયે, તે લોગમાં સ્પષ્ટ હતું કે આ એક OutOfMemoryError ભૂલ હતી. અમે ટેલિમેટ્રીથી જોયું કે હિપ મફત છે, અને આ ઓપરેશન કેમ નિષ્ફળ રહ્યું હતું તે સ્પષ્ટ ન હતું.

તે બહાર આવ્યું છે કે લ્યુસીન ઇન્ડેક્સ મર્જ હિપની બહાર થાય છે. અને કન્ટેનર વપરાશના સંસાધનોની દ્રષ્ટિએ તદ્દન સખત મર્યાદિત છે. આ સંસાધનોમાં માત્ર ઢગલો જ ફિટ થઈ શકે છે (heap.size મૂલ્ય લગભગ RAM ની બરાબર હતું), અને અમુક ઑફ-હીપ ઑપરેશન્સ મેમરી ફાળવણીની ભૂલ સાથે ક્રેશ થઈ જાય છે જો કોઈ કારણોસર તેઓ ~500MB જે મર્યાદા પહેલાં રહી ગયા હતા તેમાં ફિટ ન થયા.

ફિક્સ એકદમ તુચ્છ હતું: કન્ટેનર માટે ઉપલબ્ધ RAM ની માત્રામાં વધારો કરવામાં આવ્યો હતો, જેના પછી અમે ભૂલી ગયા કે અમને આવી સમસ્યાઓ પણ છે.

સમસ્યા બે
ક્લસ્ટર શરૂ થયાના 4-5 દિવસ પછી, અમે નોંધ્યું કે ડેટા નોડ્સ સમયાંતરે ક્લસ્ટરમાંથી બહાર આવવા લાગ્યા અને 10-20 સેકન્ડ પછી તેમાં દાખલ થવા લાગ્યા.

જ્યારે અમે તેને શોધવાનું શરૂ કર્યું, ત્યારે તે બહાર આવ્યું કે Elasticsearch માં આ ઓફ-હીપ મેમરી કોઈપણ રીતે નિયંત્રિત નથી. જ્યારે અમે કન્ટેનરને વધુ મેમરી આપી, ત્યારે અમે વિવિધ માહિતી સાથે ડાયરેક્ટ બફર પૂલ ભરવામાં સક્ષમ હતા, અને ઇલાસ્ટિકસર્ચમાંથી સ્પષ્ટ GC લોંચ કર્યા પછી જ તે સાફ થઈ ગયું.

કેટલાક કિસ્સાઓમાં, આ કામગીરીમાં ઘણો લાંબો સમય લાગ્યો, અને આ સમય દરમિયાન ક્લસ્ટર આ નોડને પહેલેથી જ બહાર નીકળી ગયેલ તરીકે ચિહ્નિત કરવામાં વ્યવસ્થાપિત થયું. આ સમસ્યા સારી રીતે વર્ણવેલ છે અહીં.

ઉકેલ નીચે મુજબ હતો: અમે આ ઓપરેશન્સ માટે ઢગલા બહાર મેમરીનો મોટો ભાગ વાપરવાની જાવાની ક્ષમતાને મર્યાદિત કરી છે. અમે તેને 16 ગીગાબાઈટ્સ (-XX:MaxDirectMemorySize=16g) સુધી મર્યાદિત કર્યું છે, તેની ખાતરી કરીને કે સ્પષ્ટ GC ને ઘણી વાર બોલાવવામાં આવે છે અને વધુ ઝડપથી પ્રક્રિયા કરવામાં આવે છે, જેનાથી ક્લસ્ટરને અસ્થિર થતું નથી.

સમસ્યા ત્રણ
જો તમને લાગે છે કે "સૌથી અણધારી ક્ષણે ક્લસ્ટર છોડતા નોડ્સ" ની સમસ્યાઓ સમાપ્ત થઈ ગઈ છે, તો તમે ભૂલથી છો.

જ્યારે અમે અનુક્રમણિકાઓ સાથે કાર્યને ગોઠવ્યું, ત્યારે અમે mmapfs પસંદ કર્યું શોધ સમય ઘટાડો મહાન વિભાજન સાથે તાજા શાર્ડ્સ પર. આ એકદમ ભૂલ હતી, કારણ કે mmapfs નો ઉપયોગ કરતી વખતે ફાઇલને RAM માં મેપ કરવામાં આવે છે, અને પછી અમે મેપ કરેલી ફાઇલ સાથે કામ કરીએ છીએ. આના કારણે, તે તારણ આપે છે કે જ્યારે GC એપ્લીકેશનમાં થ્રેડોને રોકવાનો પ્રયાસ કરે છે, ત્યારે અમે ખૂબ લાંબા સમય માટે સેફપોઇન્ટ પર જઈએ છીએ, અને તેના માર્ગ પર, એપ્લિકેશન તે જીવંત છે કે કેમ તે વિશે માસ્ટરની વિનંતીઓનો જવાબ આપવાનું બંધ કરે છે. . તદનુસાર, માસ્ટર માને છે કે નોડ હવે ક્લસ્ટરમાં હાજર નથી. આ પછી, 5-10 સેકંડ પછી, કચરો એકત્ર કરે છે, નોડ જીવંત થાય છે, ફરીથી ક્લસ્ટરમાં પ્રવેશ કરે છે અને શાર્ડ્સ શરૂ કરવાનું શરૂ કરે છે. તે બધું "અમે લાયક ઉત્પાદન" જેવું લાગ્યું અને ગંભીર કંઈપણ માટે યોગ્ય ન હતું.

આ વર્તણૂકમાંથી છુટકારો મેળવવા માટે, અમે પ્રથમ પ્રમાણભૂત niofs પર સ્વિચ કર્યું, અને પછી, જ્યારે અમે સ્થિતિસ્થાપકના પાંચમા સંસ્કરણથી છઠ્ઠા સંસ્કરણ પર સ્થળાંતર કર્યું, ત્યારે અમે હાઇબ્રિડફ્સનો પ્રયાસ કર્યો, જ્યાં આ સમસ્યાનું પુનઃઉત્પાદન થયું ન હતું. તમે સ્ટોરેજ પ્રકારો વિશે વધુ વાંચી શકો છો અહીં.

સમસ્યા ચાર
પછી બીજી ખૂબ જ રસપ્રદ સમસ્યા હતી જેનો અમે રેકોર્ડ સમય માટે સારવાર કરી. અમે તેને 2-3 મહિના સુધી પકડ્યો કારણ કે તેની પેટર્ન એકદમ અગમ્ય હતી.

કેટલીકવાર અમારા સંયોજકો ફુલ જીસીમાં જતા, સામાન્ય રીતે બપોરના ભોજન પછી, અને ત્યાંથી ક્યારેય પાછા ફર્યા નહીં. તે જ સમયે, જ્યારે GC વિલંબને લૉગિંગ કરતી વખતે, તે આના જેવું દેખાતું હતું: બધું સારું થઈ રહ્યું છે, સારું, સારું, અને પછી અચાનક બધું ખૂબ જ ખરાબ થઈ રહ્યું છે.

પહેલા અમે વિચાર્યું કે અમારી પાસે એક દુષ્ટ વપરાશકર્તા છે જે કોઈ પ્રકારની વિનંતી શરૂ કરી રહ્યો હતો જેણે સંયોજકને કાર્યકારી મોડમાંથી બહાર કાઢ્યો. શું થઈ રહ્યું છે તે શોધવાનો પ્રયાસ કરીને અમે ખૂબ લાંબા સમય સુધી વિનંતીઓ લૉગ કરી.

પરિણામે, તે બહાર આવ્યું છે કે તે ક્ષણે જ્યારે વપરાશકર્તા એક વિશાળ વિનંતી શરૂ કરે છે, અને તે ચોક્કસ ઇલાસ્ટિકસર્ચ કોઓર્ડિનેટરને મળે છે, ત્યારે કેટલાક નોડ્સ અન્ય કરતા વધુ સમય સુધી પ્રતિસાદ આપે છે.

અને જ્યારે કોઓર્ડિનેટર તમામ ગાંઠોમાંથી પ્રતિસાદની રાહ જોઈ રહ્યો હોય, ત્યારે તે પહેલાથી જ પ્રતિસાદ આપી ચૂકેલા ગાંઠોમાંથી મોકલેલા પરિણામોને એકઠા કરે છે. GC માટે, આનો અર્થ એ છે કે અમારી હીપ વપરાશ પેટર્ન ખૂબ જ ઝડપથી બદલાય છે. અને અમે ઉપયોગમાં લીધેલ GC આ કાર્યનો સામનો કરી શક્યું નથી.

આ પરિસ્થિતિમાં ક્લસ્ટરની વર્તણૂકને બદલવા માટે અમને એકમાત્ર સુધારો મળ્યો છે તે JDK13 પર સ્થળાંતર અને શેનાન્ડોહ ગાર્બેજ કલેક્ટરનો ઉપયોગ છે. આનાથી સમસ્યા હલ થઈ, અમારા સંયોજકોએ પડવાનું બંધ કર્યું.

આ તે છે જ્યાં જાવા સાથેની સમસ્યાઓનો અંત આવ્યો અને બેન્ડવિડ્થ સમસ્યાઓ શરૂ થઈ.

Elasticsearch સાથે "બેરી": થ્રુપુટ

થ્રુપુટ સાથેની સમસ્યાઓનો અર્થ એ છે કે અમારું ક્લસ્ટર સ્થિર રીતે કાર્ય કરે છે, પરંતુ અનુક્રમિત દસ્તાવેજોની સંખ્યામાં ટોચ પર અને દાવપેચ દરમિયાન, કામગીરી અપૂરતી છે.

પ્રથમ લક્ષણ સામે આવ્યું: ઉત્પાદનમાં કેટલાક "વિસ્ફોટો" દરમિયાન, જ્યારે ખૂબ મોટી સંખ્યામાં લોગ્સ અચાનક જનરેટ થાય છે, ત્યારે ગ્રેલોગમાં અનુક્રમણિકા ભૂલ es_rejected_execution વારંવાર ફ્લેશ થવા લાગે છે.

આ એ હકીકતને કારણે હતું કે એક ડેટા નોડ પર thread_pool.write.queue, જ્યાં સુધી Elasticsearch અનુક્રમણિકા વિનંતી પર પ્રક્રિયા કરવામાં અને ડિસ્ક પરના શાર્ડ પર માહિતી અપલોડ કરવામાં સક્ષમ ન હોય ત્યાં સુધી, ડિફૉલ્ટ રૂપે માત્ર 200 વિનંતીઓને કૅશ કરવામાં સક્ષમ છે. અને માં સ્થિતિસ્થાપક શોધ દસ્તાવેજીકરણ આ પરિમાણ વિશે બહુ ઓછું કહેવાય છે. માત્ર થ્રેડોની મહત્તમ સંખ્યા અને ડિફોલ્ટ કદ સૂચવવામાં આવે છે.

અલબત્ત, અમે આ મૂલ્યને ટ્વિસ્ટ કરવા ગયા અને નીચેની બાબતો શોધી કાઢી: ખાસ કરીને, અમારા સેટઅપમાં, 300 સુધીની વિનંતીઓ ખૂબ સારી રીતે કેશ કરવામાં આવી છે, અને ઉચ્ચ મૂલ્ય એ હકીકતથી ભરપૂર છે કે અમે ફરીથી સંપૂર્ણ GC માં ઉડાન ભરીએ છીએ.

વધુમાં, કારણ કે આ સંદેશાઓની બેચ છે જે એક વિનંતીમાં આવે છે, તેથી ગ્રેલોગને ટ્વિક કરવું જરૂરી હતું જેથી કરીને તે વારંવાર અને નાના બેચમાં નહીં, પરંતુ વિશાળ બેચમાં અથવા જો બેચ હજી પૂર્ણ ન હોય તો દર 3 સેકન્ડમાં એકવાર લખે. આ કિસ્સામાં, તે તારણ આપે છે કે અમે જે માહિતી ઇલાસ્ટિકસર્ચમાં લખીએ છીએ તે બે સેકન્ડમાં નહીં, પરંતુ પાંચમાં ઉપલબ્ધ થાય છે (જે અમને ખૂબ અનુકૂળ છે), પરંતુ મોટી સંખ્યામાં આગળ ધકેલવા માટે રિટ્રેની સંખ્યા કરવી પડશે. માહિતીનો સ્ટૅક ઓછો થયો છે.

આ તે ક્ષણોમાં ખાસ કરીને મહત્વપૂર્ણ છે જ્યારે કંઈક ક્યાંક ક્રેશ થયું હોય અને તેના વિશે ગુસ્સે થઈને અહેવાલ આપે છે, જેથી સંપૂર્ણપણે સ્પામ કરેલ સ્થિતિસ્થાપક ન મળે, અને થોડા સમય પછી - ગ્રેલોગ નોડ્સ કે જે ભરાયેલા બફરને કારણે બિનકાર્યક્ષમ છે.

વધુમાં, જ્યારે અમારી પાસે ઉત્પાદનમાં આ જ વિસ્ફોટો હતા, ત્યારે અમને પ્રોગ્રામરો અને પરીક્ષકો તરફથી ફરિયાદો મળી હતી: આ ક્ષણે જ્યારે તેઓને ખરેખર આ લોગની જરૂર હતી, ત્યારે તેઓ તેમને ખૂબ જ ધીરે ધીરે આપવામાં આવ્યા હતા.

તેઓએ તેને શોધવાનું શરૂ કર્યું. એક તરફ, તે સ્પષ્ટ હતું કે શોધ ક્વેરી અને ઇન્ડેક્સીંગ ક્વેરી બંને પર પ્રક્રિયા કરવામાં આવી હતી, આવશ્યકપણે, સમાન ભૌતિક મશીનો પર, અને એક યા બીજી રીતે ચોક્કસ ડ્રોડાઉન્સ હશે.

પરંતુ આને આંશિક રીતે અટકાવી શકાય છે કારણ કે ઇલાસ્ટિકસર્ચના છઠ્ઠા સંસ્કરણોમાં એક અલ્ગોરિધમ દેખાય છે જે તમને રેન્ડમ રાઉન્ડ-રોબિન સિદ્ધાંત (એક કન્ટેનર કે જે ઇન્ડેક્સીંગ કરે છે અને પ્રાથમિક-પ્રાથમિક-કન્ટેનર ધરાવે છે) અનુસાર સંબંધિત ડેટા નોડ્સ વચ્ચે પ્રશ્નોનું વિતરણ કરવાની મંજૂરી આપે છે. શાર્ડ ખૂબ વ્યસ્ત હોઈ શકે છે, ઝડપથી જવાબ આપવાનો કોઈ રસ્તો હશે નહીં), પરંતુ આ વિનંતીને પ્રતિકૃતિ-શાર્ડ સાથે ઓછા લોડવાળા કન્ટેનર પર ફોરવર્ડ કરવા માટે, જે ખૂબ ઝડપથી પ્રતિસાદ આપશે. બીજા શબ્દોમાં કહીએ તો, અમે use_adaptive_replica_selection પર પહોંચ્યા: true.

વાંચન ચિત્ર આના જેવું દેખાવાનું શરૂ કરે છે:

આ અલ્ગોરિધમના સંક્રમણથી તે ક્ષણોમાં ક્વેરી સમયને નોંધપાત્ર રીતે સુધારવાનું શક્ય બન્યું જ્યારે અમારી પાસે લખવા માટે લોગનો મોટો પ્રવાહ હતો.

છેલ્લે, મુખ્ય સમસ્યા ડેટા સેન્ટરને પીડારહિત દૂર કરવાની હતી.

એક ડીસી સાથે કનેક્શન ગુમાવ્યા પછી તરત જ ક્લસ્ટરમાંથી અમને શું જોઈતું હતું:

• જો અમારી પાસે નિષ્ફળ ડેટા સેન્ટરમાં વર્તમાન માસ્ટર છે, તો તે ફરીથી પસંદ કરવામાં આવશે અને અન્ય ડીસીમાં અન્ય નોડમાં ભૂમિકા તરીકે ખસેડવામાં આવશે.
• માસ્ટર ક્લસ્ટરમાંથી તમામ અપ્રાપ્ય નોડ્સને ઝડપથી દૂર કરશે.
• બાકીના ડેટાના આધારે, તે સમજશે: ખોવાયેલા ડેટા સેન્ટરમાં અમારી પાસે આવા અને આવા પ્રાથમિક શાર્ડ્સ હતા, તે ઝડપથી બાકીના ડેટા કેન્દ્રોમાં પૂરક પ્રતિકૃતિ શાર્ડ્સને પ્રોત્સાહન આપશે, અને અમે ડેટાને અનુક્રમિત કરવાનું ચાલુ રાખીશું.
• આના પરિણામે, ક્લસ્ટરનું લેખન અને વાંચન થ્રુપુટ ધીમે ધીમે અધોગતિ પામશે, પરંતુ સામાન્ય રીતે બધું કામ કરશે, જોકે ધીમે ધીમે, પરંતુ સ્થિર રીતે.

તે બહાર આવ્યું તેમ, અમે આના જેવું કંઈક ઇચ્છીએ છીએ:

અને અમને નીચેના મળ્યા:

આ કેવી રીતે થયું?

જ્યારે ડેટા સેન્ટર પડી ગયું, ત્યારે અમારો માસ્ટર અડચણ બની ગયો.

શા માટે?

હકીકત એ છે કે માસ્ટર પાસે ટાસ્કબેચર છે, જે ક્લસ્ટરમાં ચોક્કસ કાર્યો અને ઇવેન્ટ્સનું વિતરણ કરવા માટે જવાબદાર છે. કોઈપણ નોડ બહાર નીકળો, પ્રતિકૃતિથી પ્રાથમિક સુધી શાર્ડનું કોઈપણ પ્રમોશન, ક્યાંક શાર્ડ બનાવવા માટેનું કોઈપણ કાર્ય - આ બધું પ્રથમ ટાસ્કબેચર પર જાય છે, જ્યાં તે ક્રમિક રીતે અને એક થ્રેડમાં પ્રક્રિયા કરવામાં આવે છે.

એક ડેટા સેન્ટર ઉપાડતી વખતે, એવું બહાર આવ્યું કે હયાત ડેટા સેન્ટર્સમાંના તમામ ડેટા નોડ્સ માસ્ટરને જાણ કરવાની તેમની ફરજ માનતા હતા "અમે આવા અને આવા શાર્ડ્સ અને આવા અને આવા ડેટા નોડ્સ ગુમાવ્યા છે."

તે જ સમયે, બચી ગયેલા ડેટા નોડ્સે આ બધી માહિતી વર્તમાન માસ્ટરને મોકલી અને પુષ્ટિ માટે રાહ જોવાનો પ્રયાસ કર્યો કે તેણે તે સ્વીકાર્યું. તેઓએ આની રાહ જોવી ન હતી, કારણ કે માસ્ટરને તે જવાબ આપી શકે તેના કરતા ઝડપથી કાર્યો પ્રાપ્ત કરે છે. નોડ્સ પુનરાવર્તિત વિનંતીઓનો સમય સમાપ્ત થયો, અને આ સમયે માસ્ટરએ તેમને જવાબ આપવાનો પ્રયાસ પણ કર્યો ન હતો, પરંતુ અગ્રતા દ્વારા વિનંતીઓને સૉર્ટ કરવાના કાર્યમાં સંપૂર્ણપણે સમાઈ ગયા હતા.

ટર્મિનલ સ્વરૂપમાં, તે બહાર આવ્યું છે કે ડેટા નોડ્સ માસ્ટરને ત્યાં સુધી સ્પામ કરે છે કે તે સંપૂર્ણ GC પર જાય છે. તે પછી, અમારી મુખ્ય ભૂમિકા આગળના કેટલાક નોડ પર ખસેડવામાં આવી, તેની સાથે પણ તે જ થયું, અને પરિણામે ક્લસ્ટર સંપૂર્ણપણે તૂટી ગયું.

અમે માપ લીધા, અને સંસ્કરણ 6.4.0 પહેલાં, જ્યાં આ નિશ્ચિત કરવામાં આવ્યું હતું, ક્લસ્ટરને સંપૂર્ણપણે બંધ કરવા માટે અમારા માટે એકસાથે 10 માંથી માત્ર 360 ડેટા નોડ્સ આઉટપુટ કરવા માટે તે પૂરતું હતું.

તે કંઈક આના જેવું દેખાતું હતું:

સંસ્કરણ 6.4.0 પછી, જ્યાં આ ભયંકર ભૂલ સુધારાઈ હતી, ડેટા નોડ્સે માસ્ટરને મારવાનું બંધ કર્યું. પરંતુ તે તેને "સ્માર્ટ" બનાવ્યો નહીં. જેમ કે: જ્યારે આપણે 2, 3 અથવા 10 (એક સિવાયની કોઈપણ સંખ્યા) ડેટા નોડ્સ આઉટપુટ કરીએ છીએ, ત્યારે માસ્ટરને પ્રથમ સંદેશ પ્રાપ્ત થાય છે જે કહે છે કે નોડ A છોડી ગયો છે, અને નોડ B, નોડ C આ વિશે, નોડ D કહેવાનો પ્રયાસ કરે છે.

અને આ ક્ષણે, આનો સામનો ફક્ત 20-30 સેકંડ જેટલો સમય, કોઈને કંઈક વિશે કહેવાના પ્રયાસો માટે સમયસમાપ્તિ સેટ કરીને અને આ રીતે ક્લસ્ટરની બહાર જતા ડેટા સેન્ટરની ગતિને નિયંત્રિત કરીને કરી શકાય છે.

સૈદ્ધાંતિક રીતે, આ તે જરૂરિયાતોમાં બંધબેસે છે જે પ્રોજેક્ટના ભાગ રૂપે અંતિમ ઉત્પાદન માટે શરૂઆતમાં રજૂ કરવામાં આવી હતી, પરંતુ "શુદ્ધ વિજ્ઞાન" ના દૃષ્ટિકોણથી આ એક ભૂલ છે. જે, માર્ગ દ્વારા, સંસ્કરણ 7.2 માં વિકાસકર્તાઓ દ્વારા સફળતાપૂર્વક નિશ્ચિત કરવામાં આવ્યું હતું.

તદુપરાંત, જ્યારે ચોક્કસ ડેટા નોડ બહાર ગયો, ત્યારે તે બહાર આવ્યું કે તેના બહાર નીકળવા વિશેની માહિતીનો પ્રસાર કરવો એ સમગ્ર ક્લસ્ટરને કહેવા કરતાં વધુ મહત્વપૂર્ણ છે કે તેના પર આવા અને આવા પ્રાથમિક-શાર્ડ્સ છે (અન્ય ડેટામાં પ્રતિકૃતિ-શાર્ડને પ્રોત્સાહન આપવા માટે. પ્રાથમિકમાં કેન્દ્ર, અને માહિતીમાં તેમના પર લખી શકાય છે).

તેથી, જ્યારે બધું પહેલેથી જ મરી ગયું હોય, ત્યારે પ્રકાશિત ડેટા નોડ્સ તરત જ વાસી તરીકે ચિહ્નિત થતા નથી. તદનુસાર, અમને તમામ પિંગ્સ રીલીઝ થયેલ ડેટા નોડ્સ પર સમય સમાપ્ત ન થાય ત્યાં સુધી રાહ જોવાની ફરજ પાડવામાં આવે છે, અને તે પછી જ અમારું ક્લસ્ટર અમને કહેવાનું શરૂ કરે છે કે ત્યાં, ત્યાં અને ત્યાં આપણે માહિતી રેકોર્ડ કરવાનું ચાલુ રાખવાની જરૂર છે. તમે આ વિશે વધુ વાંચી શકો છો અહીં.

પરિણામે, આજે ડેટા સેન્ટર ઉપાડવાની કામગીરી અમને ધસારાના સમયે લગભગ 5 મિનિટ લે છે. આવા મોટા અને અણઘડ કોલોસસ માટે, આ એક ખૂબ સારું પરિણામ છે.

પરિણામે, અમે નીચેના નિર્ણય પર આવ્યા:

• અમારી પાસે 360 ગીગાબાઈટ ડિસ્ક સાથે 700 ડેટા નોડ્સ છે.
• આ જ ડેટા નોડ્સ દ્વારા ટ્રાફિકને રૂટીંગ કરવા માટે 60 કોઓર્ડિનેટર.
• 40 માસ્ટર્સ કે જે અમે 6.4.0 પહેલાના સંસ્કરણોથી એક પ્રકારની વારસા તરીકે છોડી દીધા છે - ડેટા સેન્ટરના ઉપાડથી બચવા માટે, અમે ઘણા મશીનો ગુમાવવા માટે માનસિક રીતે તૈયાર હતા જેથી કરીને માસ્ટર્સનો કોરમ હોય તેની ખાતરી આપવામાં આવે. સૌથી ખરાબ પરિસ્થિતિ
• એક કન્ટેનર પર ભૂમિકાઓને જોડવાના કોઈપણ પ્રયાસો એ હકીકત સાથે મળ્યા હતા કે વહેલા કે પછી નોડ લોડ હેઠળ તૂટી જશે.
• આખું ક્લસ્ટર 31 ગીગાબાઈટ્સના heap.sizeનો ઉપયોગ કરે છે: કદ ઘટાડવાના તમામ પ્રયાસોના પરિણામે કાં તો અગ્રણી વાઈલ્ડકાર્ડ સાથે ભારે સર્ચ ક્વેરીઝ પર કેટલાક નોડ્સને મારી નાખવામાં આવે છે અથવા ઈલાસ્ટિકસર્ચમાં જ સર્કિટ બ્રેકર મળે છે.
• વધુમાં, શોધ કાર્યક્ષમતા સુનિશ્ચિત કરવા માટે, અમે ક્લસ્ટરમાં ઑબ્જેક્ટની સંખ્યાને શક્ય તેટલી નાની રાખવાનો પ્રયાસ કર્યો, જેથી અમને માસ્ટરમાં મળેલી અડચણમાં શક્ય તેટલી ઓછી ઘટનાઓ પર પ્રક્રિયા કરી શકાય.

છેલ્લે મોનીટરીંગ વિશે

ખાતરી કરવા માટે કે આ બધું હેતુ મુજબ કાર્ય કરે છે, અમે નીચેનાનું નિરીક્ષણ કરીએ છીએ:

• દરેક ડેટા નોડ અમારા ક્લાઉડને જાણ કરે છે કે તે અસ્તિત્વમાં છે, અને તેના પર આવા અને આવા શાર્ડ્સ છે. જ્યારે આપણે ક્યાંક કંઈક ઓલવીએ છીએ, ત્યારે ક્લસ્ટર 2-3 સેકન્ડ પછી અહેવાલ આપે છે કે કેન્દ્ર Aમાં અમે ગાંઠો 2, 3 અને 4 બુઝાવી દીધા છે - આનો અર્થ એ છે કે અન્ય ડેટા કેન્દ્રોમાં આપણે કોઈ પણ સંજોગોમાં તે ગાંઠોને બુઝાવી શકતા નથી કે જેના પર માત્ર એક જ શાર્ડ હોય. બાકી
• માસ્ટરની વર્તણૂકની પ્રકૃતિને જાણીને, અમે બાકી રહેલા કાર્યોની સંખ્યાને ખૂબ જ કાળજીપૂર્વક જોઈએ છીએ. કારણ કે એક અટકેલું કાર્ય પણ, જો તે સમયસર સમાપ્ત ન થાય, તો સૈદ્ધાંતિક રીતે કેટલીક કટોકટીની પરિસ્થિતિમાં કારણ બની શકે છે, ઉદાહરણ તરીકે, પ્રાથમિકમાં પ્રતિકૃતિ શાર્ડનું પ્રમોશન કામ કરતું નથી, જેના કારણે ઇન્ડેક્સીંગ કામ કરવાનું બંધ કરશે.
• અમે ગાર્બેજ કલેક્ટર વિલંબને પણ ખૂબ જ નજીકથી જોઈએ છીએ, કારણ કે ઑપ્ટિમાઇઝેશન દરમિયાન અમને આની સાથે ઘણી મુશ્કેલીઓ આવી છે.
• અડચણ ક્યાં છે તે અગાઉથી સમજવા માટે થ્રેડ દ્વારા અસ્વીકાર.
• સારું, પ્રમાણભૂત મેટ્રિક્સ જેમ કે ઢગલો, RAM અને I/O.

મોનિટરિંગ બનાવતી વખતે, તમારે Elasticsearch માં થ્રેડ પૂલની સુવિધાઓ ધ્યાનમાં લેવી આવશ્યક છે. સ્થિતિસ્થાપક શોધ દસ્તાવેજીકરણ શોધ અને અનુક્રમણિકા માટે રૂપરેખાંકન વિકલ્પો અને ડિફૉલ્ટ મૂલ્યોનું વર્ણન કરે છે, પરંતુ thread_pool.management વિશે સંપૂર્ણપણે મૌન છે. આ થ્રેડો પ્રક્રિયા કરે છે, ખાસ કરીને, _cat/shards અને અન્ય સમાન પ્રશ્નો, જે મોનિટરિંગ લખતી વખતે વાપરવા માટે અનુકૂળ હોય છે. ક્લસ્ટર જેટલું મોટું છે, તેટલી વધુ વિનંતીઓ સમયના એકમ દીઠ એક્ઝિક્યુટ કરવામાં આવે છે, અને ઉપરોક્ત thread_pool.management માત્ર સત્તાવાર દસ્તાવેજોમાં જ રજૂ કરવામાં આવતું નથી, પરંતુ તે ડિફોલ્ટ રૂપે 5 થ્રેડો સુધી મર્યાદિત છે, જેનો ખૂબ જ ઝડપથી નિકાલ થાય છે. જે મોનિટરિંગ યોગ્ય રીતે કામ કરવાનું બંધ કરે છે.

હું નિષ્કર્ષમાં શું કહેવા માંગુ છું: અમે તે કર્યું! અમે અમારા પ્રોગ્રામરો અને વિકાસકર્તાઓને એક એવું સાધન આપવામાં સક્ષમ હતા જે લગભગ કોઈપણ પરિસ્થિતિમાં, ઉત્પાદનમાં શું થઈ રહ્યું છે તે વિશે ઝડપથી અને વિશ્વસનીય રીતે માહિતી પ્રદાન કરી શકે છે.

હા, તે એકદમ જટિલ હોવાનું બહાર આવ્યું, પરંતુ, તેમ છતાં, અમે અમારી ઇચ્છાઓને હાલના ઉત્પાદનોમાં ફિટ કરવામાં વ્યવસ્થાપિત થયા, જેને અમારે પોતાને માટે પેચ અને ફરીથી લખવાની જરૂર નહોતી.

સોર્સ: www.habr.com