చాలామంది వ్యక్తులు సాగే శోధనతో పోరాడుతున్నారు. "ముఖ్యంగా పెద్ద వాల్యూమ్‌లో" లాగ్‌లను నిల్వ చేయడానికి మీరు దీన్ని ఉపయోగించాలనుకున్నప్పుడు ఏమి జరుగుతుంది? మరియు అనేక డేటా సెంటర్లలో ఏదైనా వైఫల్యాన్ని అనుభవించడం కూడా నొప్పిలేకుండా ఉందా? మీరు ఎలాంటి వాస్తును తయారు చేయాలి మరియు మీరు ఎలాంటి ఆపదలను ఎదుర్కొంటారు?
Odnoklassniki వద్ద మేము లాగ్ మేనేజ్‌మెంట్ సమస్యను పరిష్కరించడానికి సాగే శోధనను ఉపయోగించాలని నిర్ణయించుకున్నాము మరియు ఇప్పుడు మేము మా అనుభవాన్ని Habrతో పంచుకుంటాము: ఆర్కిటెక్చర్ మరియు ఆపదల గురించి.
నేను ప్యోటర్ జైట్సేవ్, నేను ఓడ్నోక్లాస్నికిలో సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా పని చేస్తున్నాను. దీనికి ముందు, నేను కూడా నిర్వాహకుడిని, మాంటికోర్ శోధన, సింహిక శోధన, సాగే శోధనతో పనిచేశాను. బహుశా, మరొక ... శోధన కనిపించినట్లయితే, నేను దానితో కూడా పని చేస్తాను. నేను స్వచ్ఛంద ప్రాతిపదికన అనేక ఓపెన్ సోర్స్ ప్రాజెక్ట్‌లలో కూడా పాల్గొంటాను.
నేను Odnoklassnikiకి వచ్చినప్పుడు, నేను ఎలాస్టిక్‌సెర్చ్‌తో పని చేయగలనని ఇంటర్వ్యూలో నిర్లక్ష్యంగా చెప్పాను. నేను దానిని హ్యాంగ్ చేసి, కొన్ని సాధారణ పనులను పూర్తి చేసిన తర్వాత, ఆ సమయంలో ఉన్న లాగ్ మేనేజ్‌మెంట్ సిస్టమ్‌ను సంస్కరించే పెద్ద పని నాకు ఇవ్వబడింది.
అవసరాలు
సిస్టమ్ అవసరాలు క్రింది విధంగా రూపొందించబడ్డాయి:
- గ్రేలాగ్‌ను ఫ్రంటెండ్‌గా ఉపయోగించాలి. కంపెనీకి ఇప్పటికే ఈ ఉత్పత్తిని ఉపయోగించిన అనుభవం ఉన్నందున, ప్రోగ్రామర్లు మరియు పరీక్షకులకు ఇది తెలుసు, ఇది వారికి సుపరిచితం మరియు అనుకూలమైనది.
- డేటా వాల్యూమ్: సెకనుకు సగటున 50-80 వేల సందేశాలు, కానీ ఏదైనా విచ్ఛిన్నమైతే, ట్రాఫిక్ దేనికీ పరిమితం కాదు, ఇది సెకనుకు 2-3 మిలియన్ లైన్లు కావచ్చు
- శోధన ప్రశ్నలను ప్రాసెస్ చేసే వేగానికి సంబంధించిన అవసరాల గురించి కస్టమర్‌లతో చర్చించిన తరువాత, అటువంటి సిస్టమ్‌ను ఉపయోగించడం యొక్క సాధారణ నమూనా ఇది అని మేము గ్రహించాము: వ్యక్తులు గత రెండు రోజులుగా వారి అప్లికేషన్ యొక్క లాగ్‌ల కోసం వెతుకుతున్నారు మరియు ఒక కంటే ఎక్కువ వేచి ఉండకూడదనుకుంటున్నారు. సూత్రీకరించిన ప్రశ్న ఫలితం కోసం రెండవది.
- సిస్టమ్ ఎలా పనిచేస్తుందో లోతుగా పరిశోధించాల్సిన అవసరం లేకుండా, అవసరమైతే, సిస్టమ్ సులభంగా కొలవగలదని నిర్వాహకులు పట్టుబట్టారు.
- కాబట్టి ఈ సిస్టమ్‌లకు కాలానుగుణంగా అవసరమయ్యే ఏకైక నిర్వహణ పని కొంత హార్డ్‌వేర్‌ను మార్చడం.
- అదనంగా, Odnoklassniki అద్భుతమైన సాంకేతిక సంప్రదాయాన్ని కలిగి ఉంది: మేము ప్రారంభించే ఏదైనా సేవ తప్పనిసరిగా డేటా సెంటర్ వైఫల్యాన్ని తట్టుకోవాలి (ఆకస్మికంగా, ప్రణాళిక లేనిది మరియు ఖచ్చితంగా ఎప్పుడైనా).
ఈ ప్రాజెక్ట్ అమలులో చివరి అవసరం మాకు చాలా ఖర్చు అవుతుంది, నేను మరింత వివరంగా మాట్లాడతాను.
పర్యావరణ
మేము నాలుగు డేటా సెంటర్లలో పని చేస్తాము, అయితే ఎలాస్టిక్‌సెర్చ్ డేటా నోడ్‌లు కేవలం మూడింటిలో మాత్రమే ఉంటాయి (అనేక సాంకేతికేతర కారణాల వల్ల).
ఈ నాలుగు డేటా సెంటర్లలో దాదాపు 18 వేల విభిన్న లాగ్ సోర్స్‌లు ఉన్నాయి - హార్డ్‌వేర్, కంటైనర్లు, వర్చువల్ మిషన్లు.
ముఖ్యమైన లక్షణం: క్లస్టర్ కంటైనర్‌లలో ప్రారంభమవుతుంది భౌతిక యంత్రాలపై కాదు, కానీ . కంటైనర్‌లకు 2Ghz v2.0 మాదిరిగానే 4 కోర్లు హామీ ఇవ్వబడతాయి, మిగిలిన కోర్లు పనిలేకుండా ఉంటే వాటిని రీసైక్లింగ్ చేసే అవకాశం ఉంటుంది.
వేరే పదాల్లో:
టోపాలజీ
నేను మొదట్లో ఈ క్రింది విధంగా పరిష్కారం యొక్క సాధారణ రూపాన్ని చూశాను:
- గ్రేలాగ్ డొమైన్ యొక్క A-రికార్డ్ వెనుక 3-4 VIPలు ఉన్నారు, ఇది లాగ్‌లు పంపబడే చిరునామా.
- ప్రతి VIP ఒక LVS బ్యాలెన్సర్.
- దాని తర్వాత, లాగ్‌లు గ్రేలాగ్ బ్యాటరీకి వెళ్తాయి, కొన్ని డేటా GELF ఆకృతిలో, కొన్ని syslog ఆకృతిలో ఉన్నాయి.
- అప్పుడు ఇవన్నీ పెద్ద బ్యాచ్‌లలో ఎలాస్టిక్‌సెర్చ్ కోఆర్డినేటర్‌ల బ్యాటరీకి వ్రాయబడతాయి.
- మరియు వారు, సంబంధిత డేటా నోడ్‌లకు వ్రాయడం మరియు చదవడం అభ్యర్థనలను పంపుతారు.
పదజాలం
బహుశా ప్రతి ఒక్కరూ పరిభాషను వివరంగా అర్థం చేసుకోలేరు, కాబట్టి నేను దానిపై కొంచెం నివసించాలనుకుంటున్నాను.
ఎలాస్టిక్‌సెర్చ్‌లో అనేక రకాల నోడ్‌లు ఉన్నాయి - మాస్టర్, కోఆర్డినేటర్, డేటా నోడ్. విభిన్న లాగ్ పరివర్తనలు మరియు విభిన్న క్లస్టర్‌ల మధ్య కమ్యూనికేషన్ కోసం మరో రెండు రకాలు ఉన్నాయి, కానీ మేము జాబితా చేయబడిన వాటిని మాత్రమే ఉపయోగించాము.
మాస్టర్
ఇది క్లస్టర్‌లో ఉన్న అన్ని నోడ్‌లను పింగ్ చేస్తుంది, తాజా క్లస్టర్ మ్యాప్‌ను నిర్వహిస్తుంది మరియు నోడ్‌ల మధ్య పంపిణీ చేస్తుంది, ఈవెంట్ లాజిక్‌ను ప్రాసెస్ చేస్తుంది మరియు వివిధ రకాల క్లస్టర్ వైడ్ హౌస్‌కీపింగ్‌ను నిర్వహిస్తుంది.
సమన్వయకర్త
ఒకే పనిని అమలు చేస్తుంది: క్లయింట్‌ల నుండి రీడ్ లేదా రైట్ అభ్యర్థనలను అంగీకరిస్తుంది మరియు ఈ ట్రాఫిక్‌ను రూట్ చేస్తుంది. వ్రాత అభ్యర్థన ఉన్నట్లయితే, చాలా మటుకు, అది సంబంధిత ఇండెక్స్‌లో ఏ భాగాన్ని ఉంచాలో మాస్టర్‌ను అడుగుతుంది మరియు అభ్యర్థనను మరింత మళ్లిస్తుంది.
డేటా నోడ్
డేటాను నిల్వ చేస్తుంది, బయటి నుండి వచ్చే శోధన ప్రశ్నలను నిర్వహిస్తుంది మరియు దానిపై ఉన్న ముక్కలపై కార్యకలాపాలను నిర్వహిస్తుంది.
గ్రేలాగ్
ఇది ELK స్టాక్‌లో లాగ్‌స్టాష్‌తో కిబానా కలయిక లాంటిది. గ్రేలాగ్ UI మరియు లాగ్ ప్రాసెసింగ్ పైప్‌లైన్ రెండింటినీ మిళితం చేస్తుంది. హుడ్ కింద, గ్రేలాగ్ కాఫ్కా మరియు జూకీపర్‌ని నడుపుతుంది, ఇది గ్రేలాగ్‌కు క్లస్టర్‌గా కనెక్టివిటీని అందిస్తుంది. గ్రేలాగ్ ఎలాస్టిక్ సెర్చ్ అందుబాటులో లేకుంటే లాగ్‌లను (కాఫ్కా) కాష్ చేయగలదు మరియు విఫలమైన రీడ్ అండ్ రైట్ రిక్వెస్ట్‌లు, గ్రూప్ మరియు మార్క్ లాగ్‌లను పేర్కొన్న నిబంధనల ప్రకారం పునరావృతం చేయవచ్చు. లాగ్‌స్టాష్ వలె, గ్రేలాగ్ వరుసలను ఎలాస్టిక్‌సెర్చ్‌కి వ్రాయడానికి ముందు వాటిని సవరించడానికి కార్యాచరణను కలిగి ఉంది.
అదనంగా, గ్రేలాగ్ అంతర్నిర్మిత సేవా ఆవిష్కరణను కలిగి ఉంది, ఇది అందుబాటులో ఉన్న ఒక సాగే శోధన నోడ్ ఆధారంగా మొత్తం క్లస్టర్ మ్యాప్‌ను పొందేందుకు మరియు నిర్దిష్ట ట్యాగ్ ద్వారా ఫిల్టర్ చేయడానికి అనుమతిస్తుంది, ఇది నిర్దిష్ట కంటైనర్‌లకు నేరుగా అభ్యర్థనలను సాధ్యం చేస్తుంది.
దృశ్యమానంగా ఇది ఇలా కనిపిస్తుంది:
ఇది ఒక నిర్దిష్ట ఉదాహరణ నుండి తీసిన స్క్రీన్‌షాట్. ఇక్కడ మేము శోధన ప్రశ్న ఆధారంగా హిస్టోగ్రామ్‌ను రూపొందిస్తాము మరియు సంబంధిత అడ్డు వరుసలను ప్రదర్శిస్తాము.
సూచికలు
సిస్టమ్ ఆర్కిటెక్చర్‌కు తిరిగి వస్తున్నప్పుడు, మేము ఇండెక్స్ మోడల్‌ను ఎలా నిర్మించాము అనే దానిపై మరింత వివరంగా నివసించాలనుకుంటున్నాను, తద్వారా ఇది సరిగ్గా పని చేస్తుంది.
పై రేఖాచిత్రంలో, ఇది అత్యల్ప స్థాయి: సాగే శోధన డేటా నోడ్‌లు.
సూచిక అనేది సాగే శోధన ముక్కలతో రూపొందించబడిన పెద్ద వర్చువల్ ఎంటిటీ. స్వతహాగా, ప్రతి ముక్కలూ లూసీన్ సూచిక తప్ప మరేమీ కాదు. మరియు ప్రతి Lucene సూచిక, క్రమంగా, ఒకటి లేదా అంతకంటే ఎక్కువ విభాగాలను కలిగి ఉంటుంది.
రూపకల్పన చేస్తున్నప్పుడు, పెద్ద మొత్తంలో డేటాపై పఠన వేగం యొక్క ఆవశ్యకతను తీర్చడానికి, మేము ఈ డేటాను డేటా నోడ్‌లలో సమానంగా "విస్తరించడం" అవసరమని మేము గుర్తించాము.
దీని ఫలితంగా ఒక్కో ఇండెక్స్‌కి (ప్రతిరూపాలతో కూడిన) షార్డ్‌ల సంఖ్య ఖచ్చితంగా డేటా నోడ్‌ల సంఖ్యకు సమానంగా ఉండాలి. ముందుగా, రెంటికీ సమానమైన రెప్లికేషన్ ఫ్యాక్టర్‌ని నిర్ధారించడానికి (అంటే, మనం క్లస్టర్‌లో సగం కోల్పోవచ్చు). మరియు, రెండవది, క్లస్టర్‌లో కనీసం సగంలో చదవడం మరియు వ్రాయడం అభ్యర్థనలను ప్రాసెస్ చేయడానికి.
మేము మొదట నిల్వ సమయాన్ని 30 రోజులుగా నిర్ణయించాము.
ముక్కల పంపిణీని గ్రాఫికల్‌గా ఈ క్రింది విధంగా సూచించవచ్చు:
మొత్తం ముదురు బూడిద దీర్ఘ చతురస్రం ఒక సూచిక. దానిలోని ఎడమ ఎరుపు చతురస్రం ప్రాథమిక ముక్క, సూచికలో మొదటిది. మరియు నీలి చతురస్రం ఒక ప్రతిరూపం ముక్క. అవి వేర్వేరు డేటా సెంటర్లలో ఉన్నాయి.
మేము మరొక భాగాన్ని జోడించినప్పుడు, అది మూడవ డేటా కేంద్రానికి వెళుతుంది. మరియు, చివరికి, మేము ఈ నిర్మాణాన్ని పొందుతాము, ఇది డేటా స్థిరత్వాన్ని కోల్పోకుండా DCని కోల్పోయేలా చేస్తుంది:
సూచికల భ్రమణం, అనగా. కొత్త సూచికను సృష్టించడం మరియు పాతదాన్ని తొలగించడం, మేము దానిని 48 గంటలకు సమానంగా చేసాము (సూచిక వినియోగం యొక్క నమూనా ప్రకారం: చివరి 48 గంటలు చాలా తరచుగా శోధించబడతాయి).
ఈ సూచిక భ్రమణ విరామం క్రింది కారణాల వల్ల ఏర్పడింది:
శోధన అభ్యర్థన నిర్దిష్ట డేటా నోడ్‌కు వచ్చినప్పుడు, పనితీరు దృక్కోణం నుండి, ఒక ముక్కను ప్రశ్నించినప్పుడు, దాని పరిమాణం నోడ్ యొక్క హిప్ పరిమాణంతో పోల్చబడినట్లయితే, అది మరింత లాభదాయకంగా ఉంటుంది. ఇండెక్స్ యొక్క "హాట్" భాగాన్ని ఒక కుప్పలో ఉంచడానికి మరియు దానిని త్వరగా యాక్సెస్ చేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. "హాట్ పార్ట్స్" చాలా ఉన్నప్పుడు, ఇండెక్స్ శోధన వేగం క్షీణిస్తుంది.
నోడ్ ఒక షార్డ్‌పై శోధన ప్రశ్నను అమలు చేయడం ప్రారంభించినప్పుడు, అది భౌతిక యంత్రం యొక్క హైపర్‌థ్రెడింగ్ కోర్ల సంఖ్యకు సమానమైన అనేక థ్రెడ్‌లను కేటాయిస్తుంది. శోధన ప్రశ్న పెద్ద సంఖ్యలో ముక్కలను ప్రభావితం చేస్తే, దారాల సంఖ్య దామాషా ప్రకారం పెరుగుతుంది. ఇది శోధన వేగంపై ప్రతికూల ప్రభావాన్ని చూపుతుంది మరియు కొత్త డేటా యొక్క ఇండెక్సింగ్‌ను ప్రతికూలంగా ప్రభావితం చేస్తుంది.
అవసరమైన శోధన జాప్యాన్ని అందించడానికి, మేము SSDని ఉపయోగించాలని నిర్ణయించుకున్నాము. అభ్యర్థనలను త్వరగా ప్రాసెస్ చేయడానికి, ఈ కంటైనర్‌లను హోస్ట్ చేసిన మెషీన్‌లు కనీసం 56 కోర్లను కలిగి ఉండాలి. 56 యొక్క సంఖ్య షరతులతో సరిపోయే విలువగా ఎంపిక చేయబడింది, ఇది ఆపరేషన్ సమయంలో సాగే శోధన ఉత్పత్తి చేసే థ్రెడ్‌ల సంఖ్యను నిర్ణయిస్తుంది. Elasitcsearchలో, అనేక థ్రెడ్ పూల్ పారామితులు నేరుగా అందుబాటులో ఉన్న కోర్ల సంఖ్యపై ఆధారపడి ఉంటాయి, ఇది "తక్కువ కోర్లు - ఎక్కువ నోడ్స్" సూత్రం ప్రకారం క్లస్టర్‌లోని అవసరమైన నోడ్‌ల సంఖ్యను నేరుగా ప్రభావితం చేస్తుంది.
ఫలితంగా, సగటున ఒక ముక్క 20 గిగాబైట్ల బరువు ఉంటుందని మరియు ఒక్కో ఇండెక్స్‌కు 1 షార్డ్‌లు ఉన్నాయని మేము కనుగొన్నాము. దీని ప్రకారం, మేము వాటిని ప్రతి 360 గంటలకు ఒకసారి తిప్పితే, మనకు వాటిలో 48 ఉన్నాయి. ప్రతి సూచిక 15 రోజుల డేటాను కలిగి ఉంటుంది.
డేటా రైటింగ్ మరియు రీడింగ్ సర్క్యూట్‌లు
ఈ సిస్టమ్‌లో డేటా ఎలా రికార్డ్ చేయబడిందో తెలుసుకుందాం.
గ్రేలాగ్ నుండి కోఆర్డినేటర్‌కి కొంత అభ్యర్థన వచ్చిందని చెప్పండి. ఉదాహరణకు, మేము 2-3 వేల వరుసలను ఇండెక్స్ చేయాలనుకుంటున్నాము.
కోఆర్డినేటర్, గ్రేలాగ్ నుండి అభ్యర్థనను స్వీకరించి, మాస్టర్‌ను ఇలా ప్రశ్నిస్తాడు: "ఇండెక్సింగ్ అభ్యర్థనలో, మేము ప్రత్యేకంగా ఒక సూచికను పేర్కొన్నాము, కానీ దానిని ఏ షార్డ్‌లో వ్రాయాలో పేర్కొనబడలేదు."
మాస్టర్ స్పందిస్తారు: "ఈ సమాచారాన్ని షార్డ్ నంబర్ 71కి వ్రాయండి," ఆ తర్వాత అది నేరుగా సంబంధిత డేటా నోడ్‌కు పంపబడుతుంది, ఇక్కడ ప్రాథమిక-షార్డ్ నంబర్ 71 ఉంది.
ఆ తర్వాత లావాదేవీ లాగ్ మరొక డేటా సెంటర్‌లో ఉన్న రెప్లికా-షార్డ్‌కి ప్రతిరూపం చేయబడుతుంది.
గ్రేలాగ్ నుండి కోఆర్డినేటర్‌కు శోధన అభ్యర్థన వస్తుంది. కోఆర్డినేటర్ దానిని సూచిక ప్రకారం దారి మళ్లిస్తుంది, అయితే Elasticsearch రౌండ్-రాబిన్ సూత్రాన్ని ఉపయోగించి ప్రైమరీ-షార్డ్ మరియు రెప్లికా-షార్డ్ మధ్య అభ్యర్థనలను పంపిణీ చేస్తుంది.
180 నోడ్‌లు అసమానంగా ప్రతిస్పందిస్తాయి మరియు అవి ప్రతిస్పందిస్తున్నప్పుడు, కోఆర్డినేటర్ ఇప్పటికే వేగవంతమైన డేటా నోడ్‌ల ద్వారా "ఉమ్మివేయబడిన" సమాచారాన్ని సేకరిస్తున్నారు. దీని తర్వాత, మొత్తం సమాచారం వచ్చినప్పుడు లేదా అభ్యర్థన గడువు ముగిసినప్పుడు, అది నేరుగా క్లయింట్‌కు ప్రతిదీ ఇస్తుంది.
ఈ మొత్తం సిస్టమ్ సగటున గత 48 గంటలపాటు శోధన ప్రశ్నలను 300-400మి.లలో ప్రాసెస్ చేస్తుంది, ప్రముఖ వైల్డ్‌కార్డ్‌తో ఉన్న ప్రశ్నలను మినహాయించి.
సాగే శోధనతో పువ్వులు: జావా సెటప్
మేము మొదట కోరుకున్న విధంగా అన్నింటినీ పని చేయడానికి, మేము క్లస్టర్‌లోని అనేక రకాల విషయాలను డీబగ్ చేయడానికి చాలా కాలం గడిపాము.
కనుగొనబడిన సమస్యలలో మొదటి భాగం ఎలాస్టిక్‌సెర్చ్‌లో డిఫాల్ట్‌గా జావా ముందుగా కాన్ఫిగర్ చేయబడిన విధానానికి సంబంధించినది.
సమస్య ఒకటి
లూసీన్ స్థాయిలో, బ్యాక్‌గ్రౌండ్ జాబ్‌లు నడుస్తున్నప్పుడు, లూసీన్ సెగ్మెంట్ విలీనం లోపంతో విఫలమవుతుందని మేము చాలా పెద్ద సంఖ్యలో నివేదికలను చూశాము. అదే సమయంలో, ఇది OutOfMemoryError లోపం అని లాగ్‌లలో స్పష్టంగా ఉంది. మేము టెలిమెట్రీ నుండి హిప్ ఉచితమని చూశాము మరియు ఈ ఆపరేషన్ ఎందుకు విఫలమైందో స్పష్టంగా తెలియలేదు.
లూసీన్ ఇండెక్స్ విలీనాలు హిప్ వెలుపల జరుగుతాయని తేలింది. మరియు వినియోగించే వనరుల పరంగా కంటైనర్లు చాలా ఖచ్చితంగా పరిమితం చేయబడ్డాయి. ఈ వనరులకు హీప్ మాత్రమే సరిపోతుంది (heap.size విలువ దాదాపు RAMకి సమానంగా ఉంటుంది), మరియు కొన్ని ఆఫ్-హీప్ ఆపరేషన్‌లు కొన్ని కారణాల వల్ల పరిమితి కంటే ముందు ఉన్న ~500MBకి సరిపోకపోతే మెమరీ కేటాయింపు లోపంతో క్రాష్ అవుతాయి.
పరిష్కారం చాలా చిన్నవిషయం: కంటైనర్ కోసం అందుబాటులో ఉన్న RAM మొత్తం పెరిగింది, ఆ తర్వాత మేము అలాంటి సమస్యలను కూడా కలిగి ఉన్నామని మర్చిపోయాము.
సమస్య రెండు
క్లస్టర్ ప్రారంభించిన 4-5 రోజుల తర్వాత, డేటా నోడ్‌లు క్రమానుగతంగా క్లస్టర్ నుండి బయటకు రావడం మరియు 10-20 సెకన్ల తర్వాత దానిని నమోదు చేయడం ప్రారంభించినట్లు మేము గమనించాము.
మేము దానిని గుర్తించడం ప్రారంభించినప్పుడు, సాగే శోధనలోని ఈ ఆఫ్-హీప్ మెమరీ ఏ విధంగానూ నియంత్రించబడలేదని తేలింది. మేము కంటైనర్‌కు మరింత మెమరీని అందించినప్పుడు, మేము వివిధ సమాచారంతో డైరెక్ట్ బఫర్ పూల్‌లను పూరించగలిగాము మరియు ఎలాస్టిక్‌సెర్చ్ నుండి స్పష్టమైన GC ప్రారంభించబడిన తర్వాత మాత్రమే అది క్లియర్ చేయబడింది.
కొన్ని సందర్భాల్లో, ఈ ఆపరేషన్ చాలా సమయం పట్టింది మరియు ఈ సమయంలో క్లస్టర్ ఈ నోడ్‌ను ఇప్పటికే నిష్క్రమించినట్లు గుర్తించగలిగింది. ఈ సమస్య బాగా వివరించబడింది .
పరిష్కారం క్రింది విధంగా ఉంది: ఈ ఆపరేషన్ల కోసం కుప్ప వెలుపల మెమరీలో ఎక్కువ భాగాన్ని ఉపయోగించగల జావా సామర్థ్యాన్ని మేము పరిమితం చేసాము. మేము దానిని 16 గిగాబైట్‌లకు (-XX:MaxDirectMemorySize=16g) పరిమితం చేసాము, స్పష్టమైన GC చాలా తరచుగా పిలువబడుతుందని మరియు చాలా వేగంగా ప్రాసెస్ చేయబడుతుందని నిర్ధారిస్తాము, తద్వారా ఇకపై క్లస్టర్‌ని అస్థిరపరచదు.
సమస్య మూడు
"అత్యంత ఊహించని క్షణంలో క్లస్టర్ నుండి నిష్క్రమించే నోడ్స్"తో సమస్యలు ముగిసిపోయాయని మీరు అనుకుంటే, మీరు పొరబడుతున్నారు.
మేము ఇండెక్స్‌లతో పనిని కాన్ఫిగర్ చేసినప్పుడు, మేము mmapfsని ఎంచుకున్నాము గొప్ప విభజనతో తాజా ముక్కలపై. ఇది చాలా తప్పు, ఎందుకంటే mmapf లను ఉపయోగిస్తున్నప్పుడు ఫైల్ RAM లోకి మ్యాప్ చేయబడుతుంది, ఆపై మేము మ్యాప్ చేసిన ఫైల్‌తో పని చేస్తాము. దీని కారణంగా, GC అప్లికేషన్‌లోని థ్రెడ్‌లను ఆపడానికి ప్రయత్నించినప్పుడు, మేము చాలా కాలం పాటు సేఫ్‌పాయింట్‌కి వెళ్తాము మరియు దానికి వెళ్లే మార్గంలో, అప్లికేషన్ సజీవంగా ఉందా లేదా అనే దాని గురించి మాస్టర్ యొక్క అభ్యర్థనలకు ప్రతిస్పందించడం ఆపివేస్తుంది. . దీని ప్రకారం, క్లస్టర్‌లో నోడ్ ఇకపై లేదని మాస్టర్ విశ్వసిస్తారు. దీని తరువాత, 5-10 సెకన్ల తర్వాత, చెత్త కలెక్టర్ పని చేస్తుంది, నోడ్ ప్రాణం పోసుకుంటుంది, మళ్లీ క్లస్టర్‌లోకి ప్రవేశిస్తుంది మరియు షార్డ్‌లను ప్రారంభించడం ప్రారంభమవుతుంది. ఇది చాలా "మనకు అర్హమైన ఉత్పత్తి" లాగా అనిపించింది మరియు తీవ్రమైన దేనికీ తగినది కాదు.
ఈ ప్రవర్తనను వదిలించుకోవడానికి, మేము మొదట ప్రామాణిక నియోఫ్‌లకు మారాము, ఆపై, మేము ఎలాస్టిక్ యొక్క ఐదవ వెర్షన్‌ల నుండి ఆరవ వెర్షన్‌కు మారినప్పుడు, మేము హైబ్రిడ్‌లను ప్రయత్నించాము, అక్కడ ఈ సమస్య పునరుత్పత్తి చేయబడదు. మీరు నిల్వ రకాల గురించి మరింత చదువుకోవచ్చు .
సమస్య నాలుగు
మేము రికార్డ్ సమయం కోసం చికిత్స చేసిన మరొక ఆసక్తికరమైన సమస్య ఉంది. మేము దానిని 2-3 నెలలు పట్టుకున్నాము ఎందుకంటే దాని నమూనా పూర్తిగా అపారమయినది.
కొన్నిసార్లు మా కోఆర్డినేటర్లు పూర్తి GCకి వెళ్ళారు, సాధారణంగా కొంత సమయం భోజనం తర్వాత, మరియు అక్కడి నుండి తిరిగిరాలేదు. అదే సమయంలో, GC ఆలస్యాన్ని లాగ్ చేస్తున్నప్పుడు, ఇది ఇలా కనిపించింది: అంతా బాగానే ఉంది, బాగానే ఉంది, ఆపై అకస్మాత్తుగా ప్రతిదీ చాలా ఘోరంగా జరుగుతోంది.
వర్కింగ్ మోడ్ నుండి కోఆర్డినేటర్‌ను పడగొట్టే రకమైన అభ్యర్థనను ప్రారంభించే దుష్ట వినియోగదారు మాకు ఉన్నారని మొదట మేము అనుకున్నాము. మేము చాలా కాలం నుండి అభ్యర్థనలను లాగిన్ చేసాము, ఏమి జరుగుతుందో గుర్తించడానికి ప్రయత్నిస్తున్నాము.
తత్ఫలితంగా, వినియోగదారు భారీ అభ్యర్థనను ప్రారంభించినప్పుడు మరియు అది నిర్దిష్ట సాగే శోధన సమన్వయకర్తకు వచ్చినప్పుడు, కొన్ని నోడ్‌లు ఇతరులకన్నా ఎక్కువ కాలం స్పందిస్తాయని తేలింది.
మరియు సమన్వయకర్త అన్ని నోడ్‌ల నుండి ప్రతిస్పందన కోసం ఎదురు చూస్తున్నప్పుడు, అతను ఇప్పటికే స్పందించిన నోడ్‌ల నుండి పంపిన ఫలితాలను సంచితం చేస్తాడు. GC కోసం, మా హీప్ వినియోగ నమూనాలు చాలా త్వరగా మారుతాయని దీని అర్థం. మరియు మేము ఉపయోగించిన GC ఈ పనిని ఎదుర్కోలేకపోయింది.
ఈ పరిస్థితిలో క్లస్టర్ యొక్క ప్రవర్తనను మార్చడానికి మేము కనుగొన్న ఏకైక పరిష్కారం JDK13కి తరలింపు మరియు షెనాండోహ్ చెత్త కలెక్టర్‌ను ఉపయోగించడం. ఇది సమస్యను పరిష్కరించింది, మా కోఆర్డినేటర్లు పడిపోవడం మానేశారు.
ఇక్కడే జావాతో సమస్యలు ముగిశాయి మరియు బ్యాండ్‌విడ్త్ సమస్యలు ప్రారంభమయ్యాయి.
సాగే శోధనతో "బెర్రీస్": నిర్గమాంశ
నిర్గమాంశతో సమస్యలు అంటే మా క్లస్టర్ స్థిరంగా పని చేస్తుంది, అయితే ఇండెక్స్ చేయబడిన డాక్యుమెంట్‌ల సంఖ్యలో గరిష్ట స్థాయిలలో మరియు యుక్తుల సమయంలో పనితీరు సరిపోదు.
ఎదుర్కొన్న మొదటి లక్షణం: ఉత్పత్తిలో కొన్ని "పేలుళ్లు" సమయంలో, చాలా పెద్ద సంఖ్యలో లాగ్‌లు అకస్మాత్తుగా ఉత్పత్తి చేయబడినప్పుడు, ఇండెక్సింగ్ లోపం es_rejected_execution గ్రేలాగ్‌లో తరచుగా ఫ్లాష్ చేయడం ప్రారంభమవుతుంది.
ఇది ఒక డేటా నోడ్‌లో thread_pool.write.queue అనే వాస్తవం కారణంగా, Elasticsearch ఇండెక్సింగ్ అభ్యర్థనను ప్రాసెస్ చేయగలిగిన క్షణం వరకు మరియు డిస్క్‌లోని షార్డ్‌కు సమాచారాన్ని అప్‌లోడ్ చేయగలదు, డిఫాల్ట్‌గా 200 అభ్యర్థనలను మాత్రమే కాష్ చేయగలదు. మరియు లోపల ఈ పరామితి గురించి చాలా తక్కువగా చెప్పబడింది. థ్రెడ్‌ల గరిష్ట సంఖ్య మరియు డిఫాల్ట్ పరిమాణం మాత్రమే సూచించబడతాయి.
వాస్తవానికి, మేము ఈ విలువను ట్విస్ట్ చేయడానికి వెళ్లి ఈ క్రింది వాటిని కనుగొన్నాము: ప్రత్యేకంగా, మా సెటప్‌లో, 300 వరకు అభ్యర్థనలు చాలా బాగా కాష్ చేయబడ్డాయి మరియు మేము మళ్లీ పూర్తి GCకి ఎగురుతున్నందున అధిక విలువ నిండి ఉంది.
అదనంగా, ఇవి ఒక అభ్యర్థనలో వచ్చే సందేశాల బ్యాచ్‌లు కాబట్టి, ఇది తరచుగా మరియు చిన్న బ్యాచ్‌లలో కాకుండా భారీ బ్యాచ్‌లలో లేదా బ్యాచ్ ఇంకా పూర్తి కానట్లయితే ప్రతి 3 సెకన్లకు ఒకసారి వ్రాయబడేలా గ్రేలాగ్‌ను సర్దుబాటు చేయడం అవసరం. ఈ సందర్భంలో, ఎలాస్టిక్‌సెర్చ్‌లో మనం వ్రాసే సమాచారం రెండు సెకన్లలో కాకుండా ఐదు సెకన్లలో (ఇది మాకు బాగా సరిపోతుంది) అందుబాటులోకి వస్తుంది, అయితే పెద్ద మొత్తంలో పుష్ చేయడానికి రిట్రేల సంఖ్యను తయారు చేయాలి. సమాచారం యొక్క స్టాక్ తగ్గింది.
ఎక్కడో ఎక్కడో క్రాష్ అయినప్పుడు మరియు దాని గురించి ఆవేశంగా నివేదించినప్పుడు ఇది చాలా ముఖ్యమైనది, తద్వారా పూర్తిగా స్పామ్ చేయబడిన సాగే, మరియు కొంత సమయం తర్వాత - అడ్డుపడే బఫర్‌ల కారణంగా పనిచేయని గ్రేలాగ్ నోడ్‌లు.
అదనంగా, మేము ఉత్పత్తిలో ఇదే పేలుళ్లను కలిగి ఉన్నప్పుడు, మేము ప్రోగ్రామర్లు మరియు టెస్టర్ల నుండి ఫిర్యాదులను అందుకున్నాము: వారికి నిజంగా ఈ లాగ్‌లు అవసరమైనప్పుడు, వారికి చాలా నెమ్మదిగా ఇవ్వబడ్డాయి.
వారు దానిని గుర్తించడం ప్రారంభించారు. ఒక వైపు, శోధన ప్రశ్నలు మరియు ఇండెక్సింగ్ ప్రశ్నలు రెండూ ఒకే భౌతిక యంత్రాలపై ప్రాసెస్ చేయబడతాయని మరియు ఒక విధంగా లేదా మరొక విధంగా నిర్దిష్ట డ్రాడౌన్‌లు ఉంటాయని స్పష్టమైంది.
అయితే, ఎలాస్టిక్‌సెర్చ్ యొక్క ఆరవ వెర్షన్‌లలో, యాదృచ్ఛిక రౌండ్-రాబిన్ సూత్రం ప్రకారం కాకుండా సంబంధిత డేటా నోడ్‌ల మధ్య ప్రశ్నలను పంపిణీ చేయడానికి మిమ్మల్ని అనుమతించే ఒక అల్గోరిథం కనిపించినందున ఇది పాక్షికంగా తప్పించుకోబడుతుంది (ఇండెక్సింగ్ చేసే మరియు ప్రైమరీని కలిగి ఉండే కంటైనర్. -shard చాలా బిజీగా ఉండవచ్చు, త్వరగా ప్రతిస్పందించడానికి మార్గం ఉండదు), కానీ ఈ అభ్యర్థనను ప్రతిరూప-షార్డ్‌తో తక్కువ లోడ్ చేయబడిన కంటైనర్‌కు ఫార్వార్డ్ చేయండి, ఇది చాలా వేగంగా ప్రతిస్పందిస్తుంది. మరో మాటలో చెప్పాలంటే, మేము use_adaptive_replica_selectionకి వచ్చాము: true.
పఠన చిత్రం ఇలా కనిపించడం ప్రారంభమవుతుంది:
ఈ అల్గారిథమ్‌కి మారడం వల్ల ఆ క్షణాల్లో మేము వ్రాయడానికి లాగ్‌ల యొక్క పెద్ద ప్రవాహం ఉన్నప్పుడు ప్రశ్న సమయాన్ని గణనీయంగా మెరుగుపరచడం సాధ్యమైంది.
చివరగా, ప్రధాన సమస్య డేటా సెంటర్ యొక్క నొప్పిలేకుండా తొలగించడం.
ఒక DCతో కనెక్షన్ కోల్పోయిన వెంటనే క్లస్టర్ నుండి మనం కోరుకున్నది:
- విఫలమైన డేటా సెంటర్‌లో మనకు ప్రస్తుత మాస్టర్ ఉంటే, అది మళ్లీ ఎంపిక చేయబడుతుంది మరియు మరొక DCలోని మరొక నోడ్‌కు రోల్‌గా తరలించబడుతుంది.
- మాస్టర్ క్లస్టర్ నుండి యాక్సెస్ చేయలేని అన్ని నోడ్‌లను త్వరగా తొలగిస్తుంది.
- మిగిలిన వాటి ఆధారంగా, అతను అర్థం చేసుకుంటాడు: కోల్పోయిన డేటా సెంటర్‌లో మనకు అలాంటి మరియు అలాంటి ప్రాథమిక ముక్కలు ఉన్నాయి, అతను మిగిలిన డేటా సెంటర్లలో కాంప్లిమెంటరీ రెప్లికా షార్డ్‌లను త్వరగా ప్రమోట్ చేస్తాడు మరియు మేము డేటాను ఇండెక్స్ చేయడం కొనసాగిస్తాము.
- దీని ఫలితంగా, క్లస్టర్ యొక్క వ్రాత మరియు పఠన నిర్గమాంశ క్రమంగా క్షీణిస్తుంది, కానీ సాధారణంగా ప్రతిదీ నెమ్మదిగా, కానీ స్థిరంగా పని చేస్తుంది.
అది ముగిసినప్పుడు, మేము ఇలాంటివి కోరుకుంటున్నాము:
మరియు మేము ఈ క్రింది వాటిని పొందాము:
ఇది ఎలా జరిగింది?
డేటా సెంటర్ పడిపోయినప్పుడు, మా మాస్టారు అడ్డంకి అయ్యారు.
ఎందుకు?
వాస్తవం ఏమిటంటే, మాస్టర్‌కు టాస్క్‌బ్యాచర్ ఉంది, ఇది క్లస్టర్‌లోని కొన్ని పనులు మరియు ఈవెంట్‌లను పంపిణీ చేయడానికి బాధ్యత వహిస్తుంది. ఏదైనా నోడ్ ఎగ్జిట్, రెప్లికా నుండి ప్రైమరీకి షార్డ్ యొక్క ఏదైనా ప్రమోషన్, ఎక్కడో ఒక షార్డ్‌ను సృష్టించడానికి ఏదైనా పని - ఇవన్నీ మొదట టాస్క్‌బ్యాచర్‌కు వెళతాయి, ఇక్కడ ఇది వరుసగా మరియు ఒక థ్రెడ్‌లో ప్రాసెస్ చేయబడుతుంది.
ఒక డేటా సెంటర్ ఉపసంహరణ సమయంలో, మనుగడలో ఉన్న డేటా సెంటర్‌లలోని అన్ని డేటా నోడ్‌లు మాస్టర్‌కు "మేము అలాంటి మరియు అలాంటి షార్డ్‌లను మరియు అలాంటి డేటా నోడ్‌లను కోల్పోయాము" అని తెలియజేయడం తమ కర్తవ్యంగా భావించినట్లు తేలింది.
అదే సమయంలో, మనుగడలో ఉన్న డేటా నోడ్‌లు ఈ సమాచారాన్ని ప్రస్తుత మాస్టర్‌కు పంపాయి మరియు అతను దానిని అంగీకరించినట్లు నిర్ధారణ కోసం వేచి ఉండటానికి ప్రయత్నించాయి. మాస్టర్ సమాధానం చెప్పగలిగే దానికంటే వేగంగా పనులను అందుకున్నందున వారు దీని కోసం వేచి ఉండలేదు. నోడ్‌లు పునరావృతమయ్యే అభ్యర్థనలను ముగించాయి మరియు ఈ సమయంలో మాస్టర్ వాటికి సమాధానం ఇవ్వడానికి కూడా ప్రయత్నించలేదు, కానీ ప్రాధాన్యత ప్రకారం అభ్యర్థనలను క్రమబద్ధీకరించే పనిలో పూర్తిగా మునిగిపోయారు.
టెర్మినల్ రూపంలో, డేటా నోడ్‌లు మాస్టర్‌ను పూర్తి 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 వంటి ప్రామాణిక కొలమానాలు.
పర్యవేక్షణను నిర్మించేటప్పుడు, మీరు సాగే శోధనలో థ్రెడ్ పూల్ యొక్క లక్షణాలను తప్పనిసరిగా పరిగణనలోకి తీసుకోవాలి. శోధన మరియు ఇండెక్సింగ్ కోసం కాన్ఫిగరేషన్ ఎంపికలు మరియు డిఫాల్ట్ విలువలను వివరిస్తుంది, కానీ thread_pool.management గురించి పూర్తిగా నిశ్శబ్దంగా ఉంటుంది.ఈ థ్రెడ్‌లు ప్రత్యేకించి, _cat/shards మరియు ఇతర సారూప్య ప్రశ్నలను ప్రాసెస్ చేస్తాయి, ఇవి పర్యవేక్షణను వ్రాసేటప్పుడు ఉపయోగించడానికి సౌకర్యంగా ఉంటాయి. క్లస్టర్ ఎంత పెద్దదైతే, అటువంటి అభ్యర్థనలు యూనిట్ సమయానికి అమలు చేయబడతాయి మరియు పైన పేర్కొన్న thread_pool.management అధికారిక డాక్యుమెంటేషన్‌లో ప్రదర్శించబడడమే కాకుండా, డిఫాల్ట్‌గా 5 థ్రెడ్‌లకు పరిమితం చేయబడింది, ఇది చాలా త్వరగా పారవేయబడుతుంది, తర్వాత, ఏ పర్యవేక్షణ సరిగ్గా పనిచేయడం ఆపివేస్తుంది.
ముగింపులో నేను ఏమి చెప్పాలనుకుంటున్నాను: మేము చేసాము! మేము మా ప్రోగ్రామర్లు మరియు డెవలపర్‌లకు దాదాపు ఏ పరిస్థితిలోనైనా, ఉత్పత్తిలో ఏమి జరుగుతోందనే దాని గురించి త్వరగా మరియు విశ్వసనీయంగా సమాచారాన్ని అందించగల సాధనాన్ని అందించగలిగాము.
అవును, ఇది చాలా క్లిష్టంగా మారింది, అయినప్పటికీ, మేము మా కోరికలను ఇప్పటికే ఉన్న ఉత్పత్తులకు సరిపోయేలా నిర్వహించగలిగాము, దానిని మనం అతుక్కొని తిరిగి వ్రాయవలసిన అవసరం లేదు.
మూలం: www.habr.com