పోస్ట్‌గ్రెస్‌క్యూల్‌లో బ్లోట్‌కు దారితీసే అప్లికేషన్‌లలోని సాధారణ లోపాలు. ఆండ్రీ సాల్నికోవ్

ఆండ్రీ సాల్నికోవ్ "postgresql లో ఉబ్బరానికి దారితీసే అప్లికేషన్‌లలో విలక్షణమైన లోపాలు" 2016 ప్రారంభం నుండి నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ను చదవమని నేను మీకు సూచిస్తున్నాను.

ఈ నివేదికలో, అప్లికేషన్ కోడ్ రూపకల్పన మరియు వ్రాసే దశలో ఉత్పన్నమయ్యే అనువర్తనాల్లోని ప్రధాన లోపాలను నేను విశ్లేషిస్తాను. మరియు నేను Postgresql లో ఉబ్బడానికి దారితీసే ఆ లోపాలను మాత్రమే తీసుకుంటాను. నియమం ప్రకారం, ఇది మొత్తంగా మీ సిస్టమ్ యొక్క పనితీరు యొక్క ముగింపు ప్రారంభం, అయితే ప్రారంభంలో దీనికి ఎటువంటి ముందస్తు అవసరాలు కనిపించలేదు.

అందరినీ స్వాగతిస్తున్నందుకు సంతోషం! ఈ నివేదిక నా సహోద్యోగి నుండి మునుపటి నివేదిక వలె సాంకేతికంగా లేదు. ఈ నివేదిక ప్రధానంగా బ్యాకెండ్ సిస్టమ్ డెవలపర్‌లను లక్ష్యంగా చేసుకుంది ఎందుకంటే మాకు చాలా పెద్ద సంఖ్యలో క్లయింట్లు ఉన్నారు. మరియు వారందరూ అదే తప్పులు చేస్తారు. వాటి గురించి నేను మీకు చెప్తాను. ఈ తప్పులు ఏ ప్రాణాంతకమైన మరియు చెడు విషయాలకు దారితీస్తాయో నేను వివరిస్తాను.

తప్పులు ఎందుకు చేస్తారు? అవి రెండు కారణాల వల్ల జరుగుతాయి: యాదృచ్ఛికంగా, ఇది పని చేస్తుంది మరియు డేటాబేస్ మరియు అప్లికేషన్ మధ్య స్థాయిలో అలాగే డేటాబేస్‌లో జరిగే కొన్ని మెకానిజమ్‌ల అజ్ఞానం వల్ల కావచ్చు.

నేను మీకు మూడు ఉదాహరణలు ఇస్తాను భయంకరమైన చిత్రాలు ఎంత చెడ్డవి చేశాయో. అక్కడ జరిగే మెకానిజం గురించి క్లుప్తంగా చెబుతాను. మరియు వాటిని ఎలా ఎదుర్కోవాలి, అవి ఎప్పుడు జరిగాయి మరియు తప్పులను నివారించడానికి ఏ నివారణ పద్ధతులను ఉపయోగించాలి. నేను మీకు సహాయక సాధనాల గురించి చెబుతాను మరియు ఉపయోగకరమైన లింక్‌లను అందిస్తాను.

నేను రెండు పట్టికలను కలిగి ఉన్న పరీక్ష డేటాబేస్‌ను ఉపయోగించాను. కస్టమర్ ఖాతాలతో ఒక ప్లేట్, ఈ ఖాతాలపై లావాదేవీలతో మరొకటి. మరియు కొంత ఫ్రీక్వెన్సీతో మేము ఈ ఖాతాలలోని బ్యాలెన్స్‌లను అప్‌డేట్ చేస్తాము.

ప్లేట్ యొక్క ప్రారంభ డేటా: ఇది చాలా చిన్నది, 2 MB. డేటాబేస్ మరియు ప్రత్యేకంగా సైన్ కోసం ప్రతిస్పందన సమయం కూడా చాలా బాగుంది. మరియు చాలా మంచి లోడ్ - ప్లేట్ ప్రకారం సెకనుకు 2 ఆపరేషన్లు.

మరియు ఈ నివేదిక ద్వారా నేను మీకు గ్రాఫ్‌లను చూపుతాను, తద్వారా మీరు ఏమి జరుగుతుందో స్పష్టంగా అర్థం చేసుకోవచ్చు. గ్రాఫ్‌లతో ఎల్లప్పుడూ 2 స్లయిడ్‌లు ఉంటాయి. సర్వర్‌లో సాధారణంగా ఏమి జరుగుతుందో మొదటి స్లయిడ్.

మరియు ఈ పరిస్థితిలో, మనకు నిజంగా ఒక చిన్న సంకేతం ఉందని మనం చూస్తాము. సూచిక 2 MB వద్ద చిన్నది. ఇది ఎడమ వైపున ఉన్న మొదటి గ్రాఫ్.

సర్వర్‌లో సగటు ప్రతిస్పందన సమయం కూడా స్థిరంగా మరియు తక్కువగా ఉంటుంది. ఇది ఎగువ కుడి గ్రాఫ్.

దిగువ ఎడమవైపు ఉన్న గ్రాఫ్ పొడవైన లావాదేవీలను చూపుతుంది. లావాదేవీలు త్వరగా పూర్తయ్యేలా చూస్తున్నాం. మరియు ఆటోవాక్యూమ్ ఇక్కడ ఇంకా పని చేయదు, ఎందుకంటే ఇది ప్రారంభ పరీక్ష. ఇది పని చేస్తూనే ఉంటుంది మరియు మాకు ఉపయోగకరంగా ఉంటుంది.

రెండవ స్లయిడ్ ఎల్లప్పుడూ పరీక్షించబడుతున్న ప్లేట్‌కు అంకితం చేయబడుతుంది. ఈ పరిస్థితిలో, మేము క్లయింట్ ఖాతా బ్యాలెన్స్‌లను నిరంతరం అప్‌డేట్ చేస్తాము. మరియు నవీకరణ ఆపరేషన్ కోసం సగటు ప్రతిస్పందన సమయం మిల్లీసెకన్ కంటే తక్కువగా ఉందని మేము చూస్తాము. ప్రాసెసర్ వనరులు (ఇది ఎగువ కుడి గ్రాఫ్) కూడా సమానంగా మరియు చాలా తక్కువగా వినియోగించబడుతుందని మేము చూస్తాము.

దిగువ కుడి గ్రాఫ్ అప్‌డేట్ చేయడానికి ముందు మనకు కావలసిన లైన్ కోసం ఎంత ఆపరేటింగ్ మరియు డిస్క్ మెమరీని వెతుకుతున్నామో చూపిస్తుంది. మరియు సంకేతం ప్రకారం ఆపరేషన్ల సంఖ్య సెకనుకు 2, నేను ప్రారంభంలో చెప్పినట్లుగా.

మరియు ఇప్పుడు మనకు ఒక విషాదం ఉంది. కొన్ని కారణాల వల్ల చాలా కాలంగా మరచిపోయిన లావాదేవీ ఉంది. కారణాలు సాధారణంగా అన్ని సామాన్యమైనవి:

• అత్యంత సాధారణమైన వాటిలో ఒకటి, మేము అప్లికేషన్ కోడ్‌లో బాహ్య సేవను యాక్సెస్ చేయడం ప్రారంభించాము. మరియు ఈ సేవ మాకు సమాధానం ఇవ్వదు. అంటే, మేము లావాదేవీని తెరిచాము, డేటాబేస్‌లో మార్పు చేసాము మరియు అప్లికేషన్ నుండి మెయిల్ చదవడానికి లేదా మా ఇన్‌ఫ్రాస్ట్రక్చర్‌లోని మరొక సేవకు వెళ్లాము మరియు కొన్ని కారణాల వల్ల అది మాకు ప్రతిస్పందించదు. మరి అది ఎప్పుడు పరిష్కారమవుతుందో తెలియని స్థితిలో మా సెషన్ ఇరుక్కుపోయింది.
• కొన్ని కారణాల వల్ల మా కోడ్‌లో మినహాయింపు సంభవించినప్పుడు రెండవ పరిస్థితి. మరియు మినహాయింపులో మేము లావాదేవీ ముగింపుని ప్రాసెస్ చేయలేదు. మరియు మేము బహిరంగ లావాదేవీతో హ్యాంగింగ్ సెషన్‌తో ముగించాము.
• మరియు చివరిది కూడా చాలా సాధారణ కేసు. ఇది తక్కువ నాణ్యత కోడ్. కొన్ని ఫ్రేమ్‌వర్క్‌లు లావాదేవీని తెరుస్తాయి. ఇది వేలాడుతోంది మరియు మీరు దానిని వేలాడుతున్నట్లు అప్లికేషన్‌లో మీకు తెలియకపోవచ్చు.

ఇలాంటివి ఎక్కడికి దారితీస్తాయి?

మా పట్టికలు మరియు సూచికలు నాటకీయంగా ఉబ్బడం ప్రారంభమయ్యే స్థాయికి. ఇది సరిగ్గా అదే ఉబ్బు ప్రభావం. డేటాబేస్ కోసం, డేటాబేస్ ప్రతిస్పందన సమయం చాలా తీవ్రంగా పెరుగుతుంది మరియు డేటాబేస్ సర్వర్‌పై లోడ్ పెరుగుతుంది. మరియు ఫలితంగా, మా అప్లికేషన్ దెబ్బతింటుంది. ఎందుకంటే మీరు డేటాబేస్‌కు చేసిన అభ్యర్థనపై మీ కోడ్‌లో 10 మిల్లీసెకన్లు, మీ లాజిక్‌పై 10 మిల్లీసెకన్లు గడిపినట్లయితే, మీ ఫంక్షన్ పూర్తి కావడానికి 20 మిల్లీసెకన్లు పట్టింది. మరియు ఇప్పుడు మీ పరిస్థితి పూర్తిగా విచారంగా ఉంటుంది.

మరి ఏం జరుగుతుందో చూడాలి. దిగువ ఎడమవైపు ఉన్న గ్రాఫ్ మనకు సుదీర్ఘ లావాదేవీని కలిగి ఉందని చూపిస్తుంది. మరియు మేము ఎగువ ఎడమ గ్రాఫ్‌ను పరిశీలిస్తే, మన టేబుల్ పరిమాణం అకస్మాత్తుగా రెండు మెగాబైట్ల నుండి 300 మెగాబైట్‌లకు పెరిగింది. అదే సమయంలో, పట్టికలోని డేటా మొత్తం మారలేదు, అనగా అక్కడ చాలా పెద్ద మొత్తంలో చెత్త ఉంది.

సగటు సర్వర్ ప్రతిస్పందన సమయానికి సంబంధించిన సాధారణ పరిస్థితి కూడా అనేక ఆర్డర్‌ల పరిమాణంతో మార్చబడింది. అంటే, సర్వర్‌లోని అన్ని అభ్యర్థనలు పూర్తిగా వదలడం ప్రారంభించాయి. మరియు అదే సమయంలో, అంతర్గత పోస్ట్‌గ్రెస్ ప్రక్రియలు ఆటోవాక్యూమ్ రూపంలో ప్రారంభించబడ్డాయి, ఇవి ఏదైనా చేయడానికి ప్రయత్నిస్తున్నాయి మరియు వనరులను వినియోగిస్తాయి.

మా గుర్తుతో ఏమి జరుగుతోంది? అదే. సంకేతం ప్రకారం మా సగటు ప్రతిస్పందన సమయం అనేక ఆర్డర్‌ల పరిమాణంలో పెరిగింది. ప్రత్యేకంగా వినియోగించే వనరుల పరంగా, ప్రాసెసర్‌పై లోడ్ బాగా పెరిగిందని మేము చూస్తాము. ఇది ఎగువ కుడి గ్రాఫ్. మరియు ఇది పెరిగింది ఎందుకంటే ప్రాసెసర్ అవసరమైన వాటిని వెతకడానికి పనికిరాని పంక్తుల సమూహం ద్వారా క్రమబద్ధీకరించాలి. ఇది దిగువ కుడి గ్రాఫ్. మరియు ఫలితంగా, సెకనుకు మా కాల్‌ల సంఖ్య చాలా గణనీయంగా తగ్గడం ప్రారంభమైంది, ఎందుకంటే డేటాబేస్ అదే సంఖ్యలో అభ్యర్థనలను ప్రాసెస్ చేయడానికి సమయం లేదు.

మనం తిరిగి జీవితంలోకి రావాలి. మేము ఆన్‌లైన్‌కి వెళ్తాము మరియు సుదీర్ఘ లావాదేవీలు సమస్యలకు దారితీస్తాయని కనుగొంటాము. మేము ఈ లావాదేవీని కనుగొని చంపుతాము. మరియు ప్రతిదీ మాకు సాధారణ మారింది. ప్రతిదీ తప్పక పని చేస్తుంది.

మేము శాంతించాము, కానీ కొంతకాలం తర్వాత మేము ఎమర్జెన్సీకి ముందు మాదిరిగానే అప్లికేషన్ పనిచేయదని గమనించడం ప్రారంభిస్తాము. అభ్యర్థనలు ఇప్పటికీ నెమ్మదిగా ప్రాసెస్ చేయబడతాయి మరియు గణనీయంగా నెమ్మదిగా ఉంటాయి. నా ఉదాహరణలో ప్రత్యేకంగా ఒకటిన్నర నుండి రెండు రెట్లు నెమ్మదిగా. ప్రమాదానికి ముందు కంటే సర్వర్‌పై లోడ్ కూడా ఎక్కువగా ఉంది.

మరియు ప్రశ్న: "ఈ సమయంలో స్థావరానికి ఏమి జరుగుతోంది?" మరియు కింది పరిస్థితి ఆధారంతో సంభవిస్తుంది. లావాదేవీ చార్ట్‌లో అది ఆగిపోయిందని మరియు నిజంగా దీర్ఘకాలిక లావాదేవీలు లేవని మీరు చూడవచ్చు. కానీ ప్రమాదం సమయంలో గుర్తు పరిమాణం ఘోరంగా పెరిగింది. మరియు అప్పటి నుండి అవి తగ్గలేదు. బేస్ మీద సగటు సమయం స్థిరీకరించబడింది. మరియు సమాధానాలు మనకు ఆమోదయోగ్యమైన వేగంతో తగినంతగా వస్తున్నాయి. ఆటోవాక్యూమ్ మరింత చురుకుగా మారింది మరియు సంకేతంతో ఏదైనా చేయడం ప్రారంభించింది, ఎందుకంటే ఇది మరింత డేటా ద్వారా జల్లెడ పట్టాల్సిన అవసరం ఉంది.

ప్రత్యేకంగా, ఖాతాలతో ఉన్న టెస్ట్ ప్లేట్ ప్రకారం, మేము బ్యాలెన్స్‌లను మారుస్తాము: అభ్యర్థనకు ప్రతిస్పందన సమయం సాధారణ స్థితికి వచ్చినట్లు కనిపిస్తోంది. కానీ వాస్తవానికి ఇది ఒకటిన్నర రెట్లు ఎక్కువ.

మరియు ప్రాసెసర్‌లోని లోడ్ నుండి, క్రాష్‌కు ముందు ప్రాసెసర్‌పై లోడ్ అవసరమైన విలువకు తిరిగి రాలేదని మేము చూస్తాము. మరియు కారణాలు ఖచ్చితంగా దిగువ కుడి గ్రాఫ్‌లో ఉన్నాయి. అక్కడ కొంత మొత్తంలో మెమరీని వెతకడం గమనించవచ్చు. అంటే, అవసరమైన లైన్‌ను కనుగొనడానికి, పనికిరాని డేటా ద్వారా క్రమబద్ధీకరించేటప్పుడు మేము డేటాబేస్ సర్వర్ యొక్క వనరులను వృధా చేస్తాము. సెకనుకు లావాదేవీల సంఖ్య స్థిరీకరించబడింది.

మొత్తానికి బాగానే ఉంది కానీ పరిస్థితి ఇంతకంటే దారుణంగా ఉంది. ఈ డేటాబేస్‌తో పనిచేసే మా అప్లికేషన్ యొక్క పర్యవసానంగా డేటాబేస్ క్షీణతను క్లియర్ చేయండి.

మరియు అక్కడ ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి, మీరు మునుపటి నివేదికలో లేకుంటే, ఇప్పుడు ఒక చిన్న సిద్ధాంతాన్ని పొందండి. అంతర్గత ప్రక్రియ గురించి సిద్ధాంతం. కారు వాక్యూమ్ ఎందుకు మరియు అది ఏమి చేస్తుంది?

అర్థం చేసుకోవడానికి సాహిత్యపరంగా క్లుప్తంగా. ఏదో ఒక సమయంలో మనకు టేబుల్ ఉంటుంది. మేము పట్టికలో వరుసలను కలిగి ఉన్నాము. ఈ పంక్తులు యాక్టివ్‌గా, సజీవంగా ఉంటాయి మరియు ఇప్పుడు మనకు అవసరమైనవిగా ఉంటాయి. అవి చిత్రంలో ఆకుపచ్చ రంగులో గుర్తించబడ్డాయి. మరియు ఇప్పటికే పని చేసిన డెడ్ లైన్లు ఉన్నాయి, నవీకరించబడ్డాయి మరియు వాటిపై కొత్త ఎంట్రీలు కనిపించాయి. మరియు అవి డేటాబేస్‌కు ఇకపై ఆసక్తికరంగా లేవని గుర్తించబడతాయి. కానీ పోస్ట్‌గ్రెస్ ఫీచర్ కారణంగా అవి పట్టికలో ఉన్నాయి.

మీకు కారు వాక్యూమ్ ఎందుకు అవసరం? ఏదో ఒక సమయంలో, ఆటోవాక్యూమ్ వచ్చి, డేటాబేస్‌ను యాక్సెస్ చేసి, దానిని అడుగుతుంది: "దయచేసి ప్రస్తుతం డేటాబేస్‌లో తెరిచిన పురాతన లావాదేవీ యొక్క IDని నాకు ఇవ్వండి." డేటాబేస్ ఈ ఐడిని అందిస్తుంది. మరియు ఆటోవాక్యూమ్, దానిపై ఆధారపడి, పట్టికలోని పంక్తుల ద్వారా క్రమబద్ధీకరించబడుతుంది. మరియు చాలా పాత లావాదేవీల ద్వారా కొన్ని పంక్తులు మార్చబడినట్లు అతను చూసినట్లయితే, అక్కడ కొత్త డేటాను వ్రాయడం ద్వారా భవిష్యత్తులో మనం మళ్లీ ఉపయోగించగల పంక్తులుగా వాటిని గుర్తించడానికి అతనికి హక్కు ఉంటుంది. ఇది నేపథ్య ప్రక్రియ.

ఈ సమయంలో, మేము డేటాబేస్తో పని చేస్తూనే ఉంటాము మరియు పట్టికలో కొన్ని మార్పులను కొనసాగిస్తాము. మరియు ఈ పంక్తులలో, మనం మళ్లీ ఉపయోగించుకోవచ్చు, మేము కొత్త డేటాను వ్రాస్తాము. మరియు ఆ విధంగా మనకు ఒక సైకిల్ వస్తుంది, అంటే అక్కడ కొన్ని చనిపోయిన పాత పంక్తులు కనిపిస్తాయి, వాటికి బదులుగా మనకు అవసరమైన కొత్త పంక్తులను వ్రాస్తాము. మరియు ఇది PostgreSQL పని చేయడానికి సాధారణ స్థితి.

ప్రమాదం సమయంలో ఏం జరిగింది? అక్కడ ఈ ప్రక్రియ ఎలా జరిగింది?

మాకు కొన్ని కండిషన్‌లో సైన్ ఉంది, కొన్ని లైవ్, కొన్ని డెడ్ లైన్‌లు ఉన్నాయి. కారు వాక్యూమ్ వచ్చింది. అతను డేటాబేస్‌ను మా పురాతన లావాదేవీ ఏమిటి మరియు దాని ఐడి ఏమిటి అని అడిగాడు. నేను ఈ ఐడిని అందుకున్నాను, ఇది చాలా గంటల క్రితం కావచ్చు, బహుశా పది నిమిషాల క్రితం కావచ్చు. ఇది మీ డేటాబేస్‌పై ఎంత భారాన్ని కలిగి ఉందో దానిపై ఆధారపడి ఉంటుంది. మరియు అతను మళ్లీ ఉపయోగించినట్లు గుర్తించగల పంక్తుల కోసం వెతుకుతున్నాడు. మరియు నేను మా పట్టికలో అలాంటి పంక్తులను కనుగొనలేదు.

కానీ ఈ సమయంలో మేము పట్టికతో పనిని కొనసాగిస్తాము. మేము దానిలో ఏదైనా చేస్తాము, దానిని నవీకరించండి, డేటాను మారుస్తాము. ఈ సమయంలో డేటాబేస్ ఏమి చేయాలి? ఇప్పటికే ఉన్న పట్టిక చివర కొత్త పంక్తులను జోడించడం తప్ప ఆమెకు వేరే మార్గం లేదు. అందువలన మా టేబుల్ పరిమాణం ఉబ్బడం ప్రారంభమవుతుంది.

వాస్తవానికి, పని చేయడానికి మాకు ఆకుపచ్చ గీతలు అవసరం. కానీ అటువంటి సమస్య సమయంలో, మొత్తం పట్టికలో ఆకుపచ్చ గీతల శాతం చాలా తక్కువగా ఉందని తేలింది.

మరియు మేము ప్రశ్నను అమలు చేసినప్పుడు, డేటాబేస్ అన్ని లైన్ల ద్వారా వెళ్లాలి: ఎరుపు మరియు ఆకుపచ్చ రెండూ, కావలసిన లైన్‌ను కనుగొనడానికి. మరియు పనికిరాని డేటాతో టేబుల్‌ను ఉబ్బడం యొక్క ప్రభావాన్ని "బ్లోట్" అని పిలుస్తారు, ఇది మన డిస్క్ స్థలాన్ని కూడా తింటుంది. గుర్తుంచుకోండి, అది 2 MB, అది 300 MB అయింది? ఇప్పుడు మెగాబైట్‌లను గిగాబైట్‌లకు మార్చండి మరియు మీరు మీ అన్ని డిస్క్ వనరులను త్వరగా కోల్పోతారు.

మనకు ఎలాంటి పరిణామాలు ఉండవచ్చు?

• నా ఉదాహరణలో, టేబుల్ మరియు ఇండెక్స్ 150 రెట్లు పెరిగాయి. మా క్లయింట్‌లలో కొందరు డిస్క్ స్థలం అయిపోవడం ప్రారంభించినప్పుడు ఎక్కువ ప్రాణాంతకమైన కేసులను కలిగి ఉన్నారు.
• పట్టికల పరిమాణం ఎప్పటికీ తగ్గదు. ఆటోవాక్యూమ్ కొన్ని సందర్భాల్లో డెడ్ లైన్లు మాత్రమే ఉన్నట్లయితే టేబుల్ యొక్క తోకను కత్తిరించవచ్చు. కానీ స్థిరమైన భ్రమణం ఉన్నందున, ఒక ఆకుపచ్చ గీత చివరిలో స్తంభింపజేయవచ్చు మరియు నవీకరించబడదు, మిగిలినవన్నీ ప్లేట్ ప్రారంభంలో ఎక్కడో వ్రాయబడతాయి. కానీ ఇది మీ పట్టిక పరిమాణంలో తగ్గిపోయే అవకాశం లేని సంఘటన, కాబట్టి మీరు దాని కోసం ఆశించకూడదు.
• డేటాబేస్ మొత్తం పనికిరాని పంక్తుల ద్వారా క్రమబద్ధీకరించాలి. మరియు మేము డిస్క్ వనరులను వృధా చేస్తాము, ప్రాసెసర్ వనరులు మరియు విద్యుత్తును వృధా చేస్తాము.
• మరియు ఇది మా అప్లికేషన్‌ను నేరుగా ప్రభావితం చేస్తుంది, ఎందుకంటే ప్రారంభంలో మేము అభ్యర్థనపై 10 మిల్లీసెకన్లు, మా కోడ్‌పై 10 మిల్లీసెకన్లు గడిపినట్లయితే, క్రాష్ సమయంలో మేము అభ్యర్థనపై సెకను మరియు 10 మిల్లీసెకన్లు కోడ్‌పై ఖర్చు చేయడం ప్రారంభించాము, అంటే ఆర్డర్ అప్లికేషన్ పనితీరులో పరిమాణం తగ్గింది. మరియు ప్రమాదం పరిష్కరించబడినప్పుడు, మేము అభ్యర్థనపై 20 మిల్లీసెకన్లు, కోడ్‌పై 10 మిల్లీసెకన్లు ఖర్చు చేయడం ప్రారంభించాము. అంటే మేము ఇంకా ఉత్పాదకతలో ఒకటిన్నర రెట్లు పడిపోయాము. మరియు ఇదంతా ఒక లావాదేవీ కారణంగా స్తంభించిపోయింది, బహుశా మన తప్పు వల్ల కావచ్చు.
• మరియు ప్రశ్న: "మేము ప్రతిదీ ఎలా తిరిగి పొందగలం?" తద్వారా ప్రతిదీ మాతో బాగానే ఉంది మరియు ప్రమాదానికి ముందు త్వరగా అభ్యర్థనలు వస్తాయి.

ఈ ప్రయోజనం కోసం నిర్వహించబడే పని యొక్క నిర్దిష్ట చక్రం ఉంది.

మొదట మనం ఉబ్బిన సమస్యాత్మక పట్టికలను కనుగొనాలి. కొన్ని టేబుల్‌లలో రికార్డింగ్ మరింత యాక్టివ్‌గా ఉందని, మరికొన్నింటిలో తక్కువ యాక్టివ్‌గా ఉందని మేము అర్థం చేసుకున్నాము. మరియు దీని కోసం మేము పొడిగింపును ఉపయోగిస్తాము pgstattuple. ఈ పొడిగింపును ఇన్‌స్టాల్ చేయడం ద్వారా, మీరు చాలా ఉబ్బిన పట్టికలను కనుగొనడంలో మీకు సహాయపడే ప్రశ్నలను వ్రాయవచ్చు.

మీరు ఈ పట్టికలను కనుగొన్న తర్వాత, మీరు వాటిని కుదించవలసి ఉంటుంది. దీని కోసం ఇప్పటికే సాధనాలు ఉన్నాయి. మా కంపెనీలో మేము మూడు సాధనాలను ఉపయోగిస్తాము. మొదటిది అంతర్నిర్మిత VACUUM FULL. అతను క్రూరమైన, కఠినమైన మరియు కనికరం లేనివాడు, కానీ కొన్నిసార్లు అతను చాలా ఉపయోగకరంగా ఉంటాడు. Pg_repack и pgcompactable - ఇవి పట్టికలను కంప్రెస్ చేయడానికి మూడవ పక్షం యుటిలిటీలు. మరియు వారు డేటాబేస్ను మరింత జాగ్రత్తగా చూస్తారు.

అవి మీకు మరింత సౌకర్యవంతంగా ఉండే వాటిపై ఆధారపడి ఉపయోగించబడతాయి. అయితే దీని గురించి చివర్లో చెబుతాను. ప్రధాన విషయం ఏమిటంటే మూడు ఉపకరణాలు ఉన్నాయి. ఎంచుకోవడానికి పుష్కలంగా ఉన్నాయి.

మేము ప్రతిదీ సరిదిద్దిన తర్వాత మరియు ప్రతిదీ సరిగ్గా ఉందని నిర్ధారించుకున్న తర్వాత, భవిష్యత్తులో ఈ పరిస్థితిని ఎలా నిరోధించాలో మనం తెలుసుకోవాలి:

• దీనిని చాలా సులభంగా నివారించవచ్చు. మీరు మాస్టర్ సర్వర్‌లో సెషన్‌ల వ్యవధిని పర్యవేక్షించాలి. లావాదేవీ స్థితిలో నిష్క్రియంగా ఉన్న ముఖ్యంగా ప్రమాదకరమైన సెషన్‌లు. వీరు ఇప్పుడే లావాదేవీని తెరిచి, ఏదైనా చేసి వెళ్లిపోయినవారు లేదా వేలాడదీసిన వారు కోడ్‌లో తప్పిపోయారు.
• మరియు మీ కోసం, డెవలపర్‌లుగా, ఈ పరిస్థితులు తలెత్తినప్పుడు మీ కోడ్‌ని పరీక్షించడం చాలా ముఖ్యం. చేయడం కష్టం కాదు. ఇది ఉపయోగకరమైన చెక్ అవుతుంది. మీరు సుదీర్ఘ లావాదేవీలతో సంబంధం ఉన్న పెద్ద సంఖ్యలో "పిల్లల" సమస్యలను నివారిస్తారు.

ఈ గ్రాఫ్‌లలో, నేను ఈ సందర్భంలో VACUUM FULLతో సంకేతం ద్వారా వెళ్ళిన తర్వాత డేటాబేస్ యొక్క సైన్ మరియు ప్రవర్తన ఎలా మారిందో మీకు చూపించాలనుకుంటున్నాను. ఇది నాకు ప్రొడక్షన్ కాదు.

పట్టిక పరిమాణం వెంటనే రెండు మెగాబైట్‌ల సాధారణ ఆపరేటింగ్ స్థితికి తిరిగి వచ్చింది. ఇది సర్వర్ యొక్క సగటు ప్రతిస్పందన సమయాన్ని పెద్దగా ప్రభావితం చేయలేదు.

కానీ ప్రత్యేకంగా మా పరీక్ష గుర్తు కోసం, మేము ఖాతా బ్యాలెన్స్‌లను అప్‌డేట్ చేసిన చోట, సైన్‌లోని డేటాను అప్‌డేట్ చేయాలనే అభ్యర్థనకు సగటు ప్రతిస్పందన సమయం ప్రీ-ఎమర్జెన్సీ స్థాయిలకు తగ్గించబడిందని మేము చూస్తాము. ఈ అభ్యర్థనను పూర్తి చేయడానికి ప్రాసెసర్ వినియోగించే వనరులు కూడా ప్రీ-క్రాష్ స్థాయిలకు పడిపోయాయి. మరియు దిగువ కుడి గ్రాఫ్ ఇప్పుడు మనకు అవసరమైన పంక్తిని సరిగ్గా కనుగొంటుందని చూపిస్తుంది, టేబుల్ కంప్రెస్ చేయడానికి ముందు ఉన్న డెడ్ లైన్ల పైల్స్ ద్వారా వెళ్లకుండా. మరియు సగటు అభ్యర్థన సమయం దాదాపు అదే స్థాయిలో ఉంది. కానీ ఇక్కడ నా హార్డ్‌వేర్‌లో లోపం ఉంది.

ఇక్కడితో మొదటి కథ ముగుస్తుంది. ఇది సర్వసాధారణం. క్లయింట్ యొక్క అనుభవం మరియు ప్రోగ్రామర్లు ఎంత అర్హత కలిగి ఉన్నారనే దానితో సంబంధం లేకుండా ప్రతి ఒక్కరికీ ఇది జరుగుతుంది. ముందుగానే లేదా తరువాత ఇది జరుగుతుంది.

రెండవ కథనం, దీనిలో మేము లోడ్‌ను పంపిణీ చేస్తాము మరియు సర్వర్ వనరులను ఆప్టిమైజ్ చేస్తాము

• మేము ఇప్పటికే పెరిగాము మరియు తీవ్రమైన అబ్బాయిలుగా మారాము. మరియు మాకు ప్రతిరూపం ఉందని మేము అర్థం చేసుకున్నాము మరియు లోడ్‌ను సమతుల్యం చేయడం మాకు మంచిది: మాస్టర్‌కు వ్రాయండి మరియు ప్రతిరూపం నుండి చదవండి. మరియు సాధారణంగా మేము కొన్ని నివేదికలు లేదా ETLని సిద్ధం చేయాలనుకున్నప్పుడు ఈ పరిస్థితి తలెత్తుతుంది. మరియు వ్యాపారం దీని గురించి చాలా సంతోషంగా ఉంది. అతను నిజంగా చాలా క్లిష్టమైన విశ్లేషణలతో విభిన్న నివేదికలను కోరుకుంటున్నాడు.
• నివేదికలు చాలా గంటలు పడుతుంది, ఎందుకంటే సంక్లిష్ట విశ్లేషణలను మిల్లీసెకన్లలో గణించడం సాధ్యం కాదు. మేము, ధైర్యవంతుల వలె, కోడ్ వ్రాస్తాము. చొప్పించే అప్లికేషన్‌లో మేము మాస్టర్‌పై రికార్డింగ్ చేస్తాము మరియు ప్రతిరూపంపై నివేదికలను అమలు చేస్తాము.
• లోడ్ పంపిణీ.
• ప్రతిదీ ఖచ్చితంగా పనిచేస్తుంది. మేం గొప్పవాళ్లం.

మరి ఈ పరిస్థితి ఎలా ఉంది? ప్రత్యేకంగా ఈ గ్రాఫ్‌లలో, నేను లావాదేవీ వ్యవధి కోసం ప్రతిరూపం నుండి లావాదేవీల వ్యవధిని కూడా జోడించాను. అన్ని ఇతర గ్రాఫ్‌లు మాస్టర్ సర్వర్‌ను మాత్రమే సూచిస్తాయి.

ఈ సమయానికి, నా నివేదిక బోర్డు పెరిగింది. వాటిలో మరిన్ని ఉన్నాయి. సగటు సర్వర్ ప్రతిస్పందన సమయం స్థిరంగా ఉన్నట్లు మేము చూస్తాము. మేము ప్రతిరూపంలో 2 గంటలపాటు నడిచే దీర్ఘకాల లావాదేవీని కలిగి ఉన్నాము. మేము ఆటోవాక్యూమ్ యొక్క నిశ్శబ్ద ఆపరేషన్ను చూస్తాము, ఇది డెడ్ లైన్లను ప్రాసెస్ చేస్తుంది. మరియు మాతో ప్రతిదీ బాగానే ఉంది.

ప్రత్యేకంగా, పరీక్షించిన ప్లేట్ ప్రకారం, మేము అక్కడ ఖాతా నిల్వలను నవీకరించడాన్ని కొనసాగిస్తాము. మరియు మేము అభ్యర్థనల కోసం స్థిరమైన ప్రతిస్పందన సమయం, స్థిరమైన వనరుల వినియోగం కూడా కలిగి ఉన్నాము. మాతో అంతా బాగానే ఉంది.

రెప్లికేషన్‌తో వైరుధ్యం కారణంగా ఈ నివేదికలు మళ్లీ కాల్పులు జరపడం ప్రారంభించే వరకు అంతా బాగానే ఉంది. మరియు వారు రెగ్యులర్ వ్యవధిలో తిరిగి కాల్పులు జరుపుతారు.

మేము ఆన్‌లైన్‌కి వెళ్లి ఇది ఎందుకు జరుగుతుందో చదవడం ప్రారంభిస్తాము. మరియు మేము ఒక పరిష్కారాన్ని కనుగొంటాము.

మొదటి పరిష్కారం ప్రతిరూపణ జాప్యాన్ని పెంచడం. మా నివేదిక 3 గంటల పాటు నడుస్తుందని మాకు తెలుసు. మేము ప్రతిరూపణ ఆలస్యాన్ని 3 గంటలకు సెట్ చేసాము. మేము అన్నింటినీ ప్రారంభిస్తున్నాము, కానీ కొన్నిసార్లు నివేదికలు రద్దు చేయబడటంతో మేము ఇప్పటికీ సమస్యలను ఎదుర్కొంటూనే ఉన్నాము.

ప్రతిదీ పరిపూర్ణంగా ఉండాలని మేము కోరుకుంటున్నాము. మేము మరింత ఎక్కుతాము. మరియు మేము ఇంటర్నెట్‌లో చక్కని సెట్టింగ్‌ని కనుగొన్నాము - hot_standby_feedback. దాన్ని ఆన్ చేద్దాం. Hot_standby_feedback మమ్మల్ని మాస్టర్‌లో ఆటోవాక్యూమ్‌ని ఆపడానికి అనుమతిస్తుంది. అందువలన, మేము పూర్తిగా ప్రతిరూపణ వైరుధ్యాలను వదిలించుకుంటాము. మరియు నివేదికలతో మాకు ప్రతిదీ బాగా పని చేస్తుంది.

మరియు ఈ సమయంలో మాస్టర్ సర్వర్‌తో ఏమి జరుగుతోంది? మరియు మేము మాస్టర్ సర్వర్‌తో పూర్తిగా సమస్యలో ఉన్నాము. నేను ఈ రెండు సెట్టింగ్‌లను ప్రారంభించినప్పుడు ఇప్పుడు మనం గ్రాఫ్‌లను చూస్తున్నాము. మరియు మా ప్రతిరూపంపై సెషన్ ఏదో ఒకవిధంగా మాస్టర్ సర్వర్‌లోని పరిస్థితిని ప్రభావితం చేయడం ప్రారంభించిందని మేము చూస్తాము. ఆమె ఆటోవాక్యూమ్‌ను పాజ్ చేసినందున ఆమె ప్రభావం చూపుతుంది, ఇది డెడ్ లైన్‌లను క్లియర్ చేస్తుంది. మా టేబుల్ సైజు మళ్లీ విపరీతంగా పెరిగింది. మొత్తం డేటాబేస్‌లో సగటు ప్రశ్న అమలు సమయం కూడా ఆకాశాన్ని తాకింది. ఆటోవాక్యూమ్‌లు కొంచెం బిగించాయి.

ప్రత్యేకంగా, మా ప్లేట్ నుండి, దానిపై డేటా అప్‌డేట్ కూడా ఆకాశానికి ఎగరడం చూస్తాము. CPU వినియోగం అదేవిధంగా బాగా పెరిగింది. మేము మళ్ళీ పెద్ద సంఖ్యలో చనిపోయిన, పనికిరాని లైన్ల గుండా వెళుతున్నాము. మరియు ఈ గుర్తుకు ప్రతిస్పందన సమయం మరియు లావాదేవీల సంఖ్య తగ్గింది.

నేను ఇంతకు ముందు ఏమి మాట్లాడుతున్నానో మనకు తెలియకపోతే అది ఎలా ఉంటుంది?

• మేము సమస్యల కోసం వెతకడం ప్రారంభిస్తాము. మేము మొదటి భాగంలో సమస్యలను ఎదుర్కొన్నట్లయితే, ఇది సుదీర్ఘ లావాదేవీ కారణంగా జరిగిందని మాకు తెలుసు మరియు మాస్టర్ వద్దకు వెళ్లండి. మాస్టర్‌పై మాకు సమస్య ఉంది. అతనికి సాసేజ్‌లు. ఇది వేడెక్కుతుంది, దాని లోడ్ సగటు వంద.
• అక్కడ అభ్యర్థనలు నెమ్మదిగా ఉన్నాయి, కానీ మాకు అక్కడ దీర్ఘకాలిక లావాదేవీలు కనిపించవు. మరియు విషయం ఏమిటో మాకు అర్థం కాలేదు. ఎక్కడ చూడాలో అర్థం కావడం లేదు.
• మేము సర్వర్ పరికరాలను తనిఖీ చేస్తాము. బహుశా మా దాడి క్రాష్ అయి ఉండవచ్చు. బహుశా మన మెమరీ స్టిక్ కాలిపోయి ఉండవచ్చు. అవును, ఏదైనా జరగవచ్చు. కానీ లేదు, సర్వర్లు కొత్తవి, ప్రతిదీ బాగానే పని చేస్తుంది.
• అందరూ నడుస్తున్నారు: నిర్వాహకులు, డెవలపర్లు మరియు డైరెక్టర్. ఏమీ సహాయపడదు.
• మరియు ఏదో ఒక సమయంలో ప్రతిదీ అకస్మాత్తుగా సరిదిద్దడం ప్రారంభమవుతుంది.

ఈ సమయంలో, మా ప్రతిరూపంపై అభ్యర్థన ప్రాసెస్ చేయబడింది మరియు వదిలివేయబడింది. మాకు నివేదిక అందింది. వ్యాపారం ఇంకా సంతోషంగా ఉంది. మీరు గమనిస్తే, మా గుర్తు మళ్లీ పెరిగింది మరియు కుదించబడదు. సెషన్‌లతో కూడిన గ్రాఫ్‌లో, నేను ప్రతిరూపం నుండి ఈ సుదీర్ఘ లావాదేవీ యొక్క భాగాన్ని వదిలివేసాను, తద్వారా పరిస్థితి స్థిరీకరించబడే వరకు ఎంత సమయం పడుతుందో మీరు అంచనా వేయవచ్చు.

సెషన్ ముగిసింది. మరియు కొంత సమయం తర్వాత మాత్రమే సర్వర్ ఎక్కువ లేదా తక్కువ క్రమంలో వస్తుంది. మరియు మాస్టర్ సర్వర్‌లో అభ్యర్థనలకు సగటు ప్రతిస్పందన సమయం సాధారణ స్థితికి చేరుకుంటుంది. ఎందుకంటే, చివరకు, ఆటోవాక్యూమ్‌కు ఈ డెడ్ లైన్‌లను శుభ్రం చేయడానికి మరియు గుర్తించడానికి అవకాశం ఉంది. మరియు అతను తన పనిని చేయడం ప్రారంభించాడు. మరియు అతను ఎంత త్వరగా చేస్తాడో, అంత త్వరగా మేము క్రమంలో పొందుతాము.

పరీక్షించిన టాబ్లెట్ ప్రకారం, మేము ఖాతా బ్యాలెన్స్‌లను అప్‌డేట్ చేసే చోట, మేము సరిగ్గా అదే చిత్రాన్ని చూస్తాము. సగటు ఖాతా నవీకరణ సమయం కూడా క్రమంగా సాధారణీకరించబడుతోంది. ప్రాసెసర్ వినియోగించే వనరులు కూడా తగ్గుతాయి. మరియు సెకనుకు లావాదేవీల సంఖ్య సాధారణ స్థితికి వస్తుంది. అయితే మళ్లీ ప్రమాదానికి ముందు ఉన్నట్టు కాకుండా సాధారణ స్థితికి చేరుకున్నాం.

ఏదైనా సందర్భంలో, మేము మొదటి సందర్భంలో వలె, ఒకటిన్నర నుండి రెండు సార్లు మరియు కొన్నిసార్లు ఎక్కువ పనితీరును పొందుతాము.

మేము ప్రతిదీ సరిగ్గా చేసినట్లు అనిపిస్తుంది. లోడ్ పంపిణీ చేయండి. పరికరాలు ఖాళీగా లేవు. మేము మా మనస్సుల ప్రకారం అభ్యర్థనలను విభజించాము, కానీ ఇప్పటికీ ప్రతిదీ చెడుగా మారింది.

• hot_standby_feedbackని ప్రారంభించకూడదా? అవును, ప్రత్యేకించి బలమైన కారణాలు లేకుండా దాన్ని ఆన్ చేయడానికి ఇది సిఫార్సు చేయబడదు. ఎందుకంటే ఈ ట్విస్ట్ నేరుగా మాస్టర్ సర్వర్‌ని ప్రభావితం చేస్తుంది మరియు అక్కడ ఆటోవాక్యూమ్ యొక్క ఆపరేషన్‌ను సస్పెండ్ చేస్తుంది. కొన్ని ప్రతిరూపంలో దీన్ని ప్రారంభించడం ద్వారా మరియు దాని గురించి మరచిపోవడం ద్వారా, మీరు మాస్టర్‌ను చంపవచ్చు మరియు అప్లికేషన్‌తో పెద్ద సమస్యలను పొందవచ్చు.
• max_standby_streaming_delayని పెంచాలా? అవును, నివేదికల కోసం ఇది నిజం. మీరు మూడు గంటల నివేదికను కలిగి ఉంటే మరియు ప్రతిరూపణ వైరుధ్యాల కారణంగా అది క్రాష్ అవ్వకూడదనుకుంటే, ఆలస్యాన్ని పెంచండి. దీర్ఘకాలిక నివేదికకు ప్రస్తుతం డేటాబేస్‌లో వచ్చిన డేటా అవసరం లేదు. మీరు దీన్ని మూడు గంటల పాటు కలిగి ఉంటే, మీరు దాన్ని కొంత పాత డేటా వ్యవధిలో అమలు చేస్తున్నారు. మరియు మీ కోసం, మూడు గంటల ఆలస్యమైనా లేదా ఆరు గంటల ఆలస్యమైనా ఎటువంటి తేడాను కలిగించదు, కానీ మీరు స్థిరంగా నివేదికలను స్వీకరిస్తారు మరియు అవి పడిపోవడంతో ఎటువంటి సమస్యలు ఉండవు.
• సహజంగానే, మీరు ప్రతిరూపాలపై సుదీర్ఘ సెషన్‌లను నియంత్రించాలి, ప్రత్యేకించి మీరు ప్రతిరూపంపై hot_standby_feedbackని ప్రారంభించాలని నిర్ణయించుకుంటే. ఎందుకంటే ఏదైనా జరగవచ్చు. మేము ఈ ప్రతిరూపాన్ని డెవలపర్‌కి అందించాము, తద్వారా అతను అభ్యర్థనలను పరీక్షించవచ్చు. అతను ఒక క్రేజీ రిక్వెస్ట్ రాశాడు. అతను దానిని ప్రారంభించాడు మరియు టీ తాగడానికి బయలుదేరాడు మరియు మేము స్థాపించబడిన మాస్టర్‌ని పొందాము. లేదా అక్కడ తప్పు అప్లికేషన్ పెట్టవచ్చు. పరిస్థితులు వైవిధ్యంగా ఉంటాయి. ప్రతిరూపాలపై సెషన్‌లను మాస్టర్‌లో వలె జాగ్రత్తగా పర్యవేక్షించాలి.
• మరియు మీరు ప్రతిరూపాలపై వేగవంతమైన మరియు సుదీర్ఘమైన ప్రశ్నలను కలిగి ఉంటే, ఈ సందర్భంలో లోడ్ను పంపిణీ చేయడానికి వాటిని విభజించడం మంచిది. ఇది streaming_delayకి లింక్. వేగవంతమైన వాటి కోసం, చిన్న రెప్లికేషన్ ఆలస్యంతో ఒక ప్రతిరూపాన్ని కలిగి ఉండండి. దీర్ఘకాలిక రిపోర్టింగ్ అభ్యర్థనల కోసం, 6 గంటలు లేదా ఒక రోజు ఆలస్యంగా ఉండే ప్రతిరూపాన్ని కలిగి ఉండండి. ఇది పూర్తిగా సాధారణ పరిస్థితి.

మేము అదే విధంగా పరిణామాలను తొలగిస్తాము:

• మేము ఉబ్బిన పట్టికలను కనుగొంటాము.
• మరియు మేము దానిని మాకు సరిపోయే అత్యంత అనుకూలమైన సాధనంతో కంప్రెస్ చేస్తాము.

రెండవ కథ ఇక్కడితో ముగుస్తుంది. ఇక మూడో కథకి వెళ్దాం.

అలాగే మనం వలసలు వెళ్లడం చాలా సాధారణం.

• ఏదైనా సాఫ్ట్‌వేర్ ఉత్పత్తి పెరుగుతోంది. దాని అవసరాలు మారుతున్నాయి. ఏదైనా సందర్భంలో, మేము అభివృద్ధి చేయాలనుకుంటున్నాము. మరియు మేము మా అభివృద్ధిలో భాగంగా పరిచయం చేస్తున్న కొత్త కార్యాచరణ కోసం మా మైగ్రేషన్ పరంగా అప్‌డేట్‌ను అమలు చేయడానికి, పట్టికలోని డేటాను నవీకరించాల్సిన అవసరం ఉంది.
• పాత డేటా ఫార్మాట్ సంతృప్తికరంగా లేదు. ఇప్పుడు మనం ఈ ఖాతాలపై లావాదేవీలను కలిగి ఉన్న రెండవ టేబుల్‌కి వెళ్లాలని అనుకుందాం. మరియు అవి రూబిళ్లలో ఉన్నాయని చెప్పండి మరియు మేము ఖచ్చితత్వాన్ని పెంచాలని మరియు కోపెక్స్‌లో చేయాలని నిర్ణయించుకున్నాము. మరియు దీని కోసం మనం అప్‌డేట్ చేయాలి: లావాదేవీ మొత్తంతో ఫీల్డ్‌ను వందతో గుణించండి.
• నేటి ప్రపంచంలో, మేము ఆటోమేటెడ్ డేటాబేస్ వెర్షన్ నియంత్రణ సాధనాలను ఉపయోగిస్తాము. అనుకుందాం లిక్విబేస్. మేము మా వలసలను అక్కడ నమోదు చేస్తాము. మేము దానిని మా పరీక్ష ఆధారంగా పరీక్షిస్తాము. అంతా బాగానే ఉంది. నవీకరణ జరుగుతోంది. ఇది కొంతకాలం పనిని బ్లాక్ చేస్తుంది, కానీ మేము నవీకరించబడిన డేటాను పొందుతాము. మరియు మేము దీనిపై కొత్త కార్యాచరణను ప్రారంభించవచ్చు. ప్రతిదీ పరీక్షించబడింది మరియు తనిఖీ చేయబడింది. అంతా ధృవీకరించబడింది.
• ప్రణాళికాబద్ధంగా పనులు చేపట్టి వలసలు వెళ్లాం.

మీ ముందు అందించిన నవీకరణతో మైగ్రేషన్ ఇక్కడ ఉంది. ఇవి నా ఖాతా లావాదేవీలు కాబట్టి, ప్లేట్ 15 GB. మరియు మేము ప్రతి పంక్తిని అప్‌డేట్ చేసినందున, మేము అప్‌డేట్‌తో పట్టిక పరిమాణాన్ని రెట్టింపు చేసాము, ఎందుకంటే మేము ప్రతి పంక్తిని తిరిగి వ్రాసాము.

మైగ్రేషన్ సమయంలో, మేము ఈ ప్లేట్‌తో ఏమీ చేయలేకపోయాము, ఎందుకంటే దీనికి అన్ని అభ్యర్థనలు క్యూలో ఉంచబడ్డాయి మరియు ఈ నవీకరణ పూర్తయ్యే వరకు వేచి ఉన్నాయి. కానీ ఇక్కడ నేను నిలువు అక్షం మీద ఉన్న సంఖ్యలకు మీ దృష్టిని ఆకర్షించాలనుకుంటున్నాను. అంటే, సుమారు 5 మిల్లీసెకన్ల మైగ్రేషన్ మరియు ప్రాసెసర్ లోడ్ ముందు మేము సగటు అభ్యర్థన సమయం కలిగి ఉన్నాము, డిస్క్ మెమరీని చదవడానికి బ్లాక్ ఆపరేషన్ల సంఖ్య 7,5 కంటే తక్కువగా ఉంటుంది.

మేము వలసలను నిర్వహించాము మరియు మళ్లీ సమస్యలను ఎదుర్కొన్నాము.

వలస విజయవంతమైంది, కానీ:

• పాత ఫంక్షనాలిటీ ఇప్పుడు పూర్తి కావడానికి ఎక్కువ సమయం పడుతుంది.
• టేబుల్ మళ్లీ పరిమాణం పెరిగింది.
• సర్వర్‌పై మళ్లీ లోడ్ మునుపటి కంటే ఎక్కువైంది.
• మరియు, వాస్తవానికి, మేము ఇంకా బాగా పనిచేసిన కార్యాచరణతో టింకర్ చేస్తున్నాము, మేము దానిని కొద్దిగా మెరుగుపరిచాము.

మరియు ఇది మళ్ళీ ఉబ్బరం, ఇది మళ్ళీ మన జీవితాలను నాశనం చేస్తుంది.

మునుపటి రెండు కేసుల మాదిరిగానే టేబుల్ దాని మునుపటి పరిమాణాలకు తిరిగి రాదని ఇక్కడ నేను ప్రదర్శించాను. సగటు సర్వర్ లోడ్ సరిపోతుందనిపిస్తోంది.

మరియు మేము ఖాతాలతో పట్టికకు మారినట్లయితే, ఈ పట్టిక కోసం సగటు అభ్యర్థన సమయం రెట్టింపు అయినట్లు మేము చూస్తాము. ప్రాసెసర్‌పై లోడ్ మరియు మెమరీలో క్రమబద్ధీకరించబడిన లైన్‌ల సంఖ్య 7,5 కంటే ఎక్కువ పెరిగింది, కానీ తక్కువగా ఉంది. మరియు ఇది ప్రాసెసర్ల విషయంలో 2 సార్లు, బ్లాక్ ఆపరేషన్ల విషయంలో 1,5 రెట్లు పెరిగింది, అనగా సర్వర్ పనితీరులో మాకు క్షీణత వచ్చింది. మరియు ఫలితంగా - మా అప్లికేషన్ యొక్క పనితీరు క్షీణత. అదే సమయంలో, కాల్‌ల సంఖ్య దాదాపు అదే స్థాయిలో ఉంది.

మరియు ఇక్కడ ప్రధాన విషయం ఏమిటంటే అటువంటి వలసలను సరిగ్గా ఎలా చేయాలో అర్థం చేసుకోవడం. మరియు వారు పూర్తి చేయాలి. మేము ఈ వలసలను చాలా స్థిరంగా చేస్తాము.

• ఇంత పెద్ద వలసలు స్వయంచాలకంగా జరగవు. వారు ఎల్లప్పుడూ నియంత్రణలో ఉండాలి.
• పరిజ్ఞానం ఉన్న వ్యక్తి పర్యవేక్షణ అవసరం. మీరు మీ బృందంలో DBAని కలిగి ఉంటే, DBAని చేయనివ్వండి. అది అతని పని. కాకపోతే, డేటాబేస్‌లతో ఎలా పని చేయాలో తెలిసిన అత్యంత అనుభవజ్ఞుడైన వ్యక్తిని చేయనివ్వండి.
• కొత్త డేటాబేస్ స్కీమా, మేము ఒక నిలువు వరుసను అప్‌డేట్ చేసినప్పటికీ, మేము ఎల్లప్పుడూ దశలవారీగా సిద్ధం చేస్తాము, అంటే అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను రూపొందించడానికి ముందే ముందుగానే:
• మేము నవీకరించబడిన డేటాను రికార్డ్ చేసే కొత్త ఫీల్డ్‌లు జోడించబడ్డాయి.
• మేము పాత ఫీల్డ్ నుండి కొత్త ఫీల్డ్‌కు డేటాను చిన్న భాగాలలో బదిలీ చేస్తాము. ఎందుకు ఇలా చేస్తున్నాం? ముందుగా, మేము ఈ ప్రక్రియ యొక్క ప్రక్రియను ఎల్లప్పుడూ నియంత్రిస్తాము. మేము ఇప్పటికే చాలా బ్యాచ్‌లను బదిలీ చేసాము మరియు మాకు చాలా మంది మిగిలి ఉన్నారని మాకు తెలుసు.
• మరియు రెండవ సానుకూల ప్రభావం ఏమిటంటే, అటువంటి ప్రతి బ్యాచ్ మధ్య మేము లావాదేవీని మూసివేస్తాము, క్రొత్తదాన్ని తెరవండి మరియు ఇది ఆటోవాక్యూమ్ ప్లేట్ ప్రకారం పని చేయడానికి అనుమతిస్తుంది, పునర్వినియోగం కోసం డెడ్ లైన్లను గుర్తించండి.
• అప్లికేషన్ రన్ అవుతున్నప్పుడు కనిపించే పంక్తుల కోసం (మాకు ఇప్పటికీ పాత అప్లికేషన్ అమలులో ఉంది), మేము కొత్త ఫీల్డ్‌లకు కొత్త విలువలను వ్రాసే ట్రిగ్గర్‌ను జోడిస్తాము. మా విషయంలో, ఇది పాత విలువలో వందతో గుణించడం.
• మేము పూర్తిగా మొండిగా ఉండి, అదే ఫీల్డ్ కావాలనుకుంటే, అన్ని మైగ్రేషన్‌లు పూర్తయిన తర్వాత మరియు అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను విడుదల చేయడానికి ముందు, మేము ఫీల్డ్‌ల పేరు మార్చాము. పాత వాటికి కొన్ని కనిపెట్టిన పేరు పెట్టారు మరియు కొత్త ఫీల్డ్‌లకు పాత వాటికి పేరు మార్చారు.
• మరియు ఆ తర్వాత మాత్రమే మేము అప్లికేషన్ యొక్క క్రొత్త సంస్కరణను ప్రారంభిస్తాము.

మరియు అదే సమయంలో మేము ఉబ్బరం పొందలేము మరియు పనితీరు పరంగా బాధపడము.

ఇక్కడితో మూడో కథ ముగుస్తుంది.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

మరియు ఇప్పుడు నేను మొదటి కథలో పేర్కొన్న సాధనాల గురించి కొంచెం వివరంగా చెప్పాను.

ఉబ్బు కోసం శోధించే ముందు, మీరు తప్పనిసరిగా పొడిగింపును ఇన్‌స్టాల్ చేయాలి pgstattuple.

మీరు ప్రశ్నలతో ముందుకు రానవసరం లేదు కాబట్టి, మేము ఇప్పటికే ఈ ప్రశ్నలను మా పనిలో వ్రాసాము. మీరు వాటిని ఉపయోగించవచ్చు. ఇక్కడ రెండు అభ్యర్థనలు ఉన్నాయి.

• మొదటిది పని చేయడానికి చాలా సమయం పడుతుంది, కానీ ఇది టేబుల్ నుండి ఖచ్చితమైన ఉబ్బు విలువలను మీకు చూపుతుంది.
• రెండవది వేగంగా పని చేస్తుంది మరియు టేబుల్ ప్రకారం ఉబ్బు ఉందో లేదో మీరు త్వరగా అంచనా వేయవలసి వచ్చినప్పుడు చాలా ప్రభావవంతంగా ఉంటుంది. పోస్ట్‌గ్రెస్ టేబుల్‌లో బ్లోట్ ఎల్లప్పుడూ ఉంటుందని కూడా మీరు అర్థం చేసుకోవాలి. ఇది దాని MVCC మోడల్ యొక్క లక్షణం.
• మరియు చాలా సందర్భాలలో టేబుల్‌లకు 20% ఉబ్బరం సాధారణం. అంటే, మీరు చింతించకూడదు మరియు ఈ పట్టికను కుదించకూడదు.

పనికిరాని డేటాతో ఉబ్బిన పట్టికలను ఎలా గుర్తించాలో మేము కనుగొన్నాము.

ఇప్పుడు ఉబ్బరం ఎలా పరిష్కరించాలో గురించి:

• మనకు చిన్న టాబ్లెట్ మరియు మంచి డిస్క్‌లు ఉంటే, అంటే, ఒక గిగాబైట్ వరకు ఉన్న టాబ్లెట్‌లో, VACUUM FULLని ఉపయోగించడం చాలా సాధ్యమే. అతను కొన్ని సెకన్ల పాటు టేబుల్‌పై మీ నుండి ప్రత్యేకమైన లాక్‌ని తీసుకుంటాడు మరియు సరే, కానీ అతను ప్రతిదీ త్వరగా మరియు కఠినంగా చేస్తాడు. VACUUM FULL ఏమి చేస్తుంది? ఇది టేబుల్‌పై ప్రత్యేకమైన లాక్‌ని తీసుకుంటుంది మరియు పాత టేబుల్‌ల నుండి లైవ్ అడ్డు వరుసలను కొత్త టేబుల్‌లోకి తిరిగి వ్రాస్తుంది. మరియు చివరికి అతను వాటిని భర్తీ చేస్తాడు. ఇది పాత ఫైల్‌లను తొలగిస్తుంది మరియు పాత వాటిని కొత్త వాటిని భర్తీ చేస్తుంది. కానీ దాని పని వ్యవధి కోసం, ఇది టేబుల్‌పై ప్రత్యేకమైన లాక్‌ని తీసుకుంటుంది. ఈ పట్టికతో మీరు ఏమీ చేయలేరని దీని అర్థం: దానికి వ్రాయవద్దు, చదవవద్దు లేదా సవరించవద్దు. మరియు VACUUM FULLకి డేటాను వ్రాయడానికి అదనపు డిస్క్ స్థలం అవసరం.
• తదుపరి సాధనం pg_repack. దాని సూత్రంలో, ఇది VACUUM FULLకి చాలా పోలి ఉంటుంది, ఎందుకంటే ఇది పాత ఫైళ్ళ నుండి కొత్త వాటికి డేటాను తిరిగి వ్రాసి వాటిని పట్టికలో భర్తీ చేస్తుంది. కానీ అదే సమయంలో, ఇది దాని పని ప్రారంభంలోనే టేబుల్‌పై ప్రత్యేకమైన లాక్‌ని తీసుకోదు, కానీ ఫైల్‌లను భర్తీ చేయడానికి ఇది ఇప్పటికే సిద్ధంగా ఉన్న డేటాను కలిగి ఉన్న క్షణంలో మాత్రమే తీసుకుంటుంది. దీని డిస్క్ రిసోర్స్ అవసరాలు VACUUM FULLకి సమానంగా ఉంటాయి. మీకు అదనపు డిస్క్ స్థలం అవసరం మరియు మీరు టెరాబైట్ పట్టికలను కలిగి ఉంటే ఇది కొన్నిసార్లు క్లిష్టమైనది. మరియు ఇది చాలా ప్రాసెసర్-ఆకలితో ఉంది ఎందుకంటే ఇది I/Oతో చురుకుగా పనిచేస్తుంది.
• మూడవ ప్రయోజనం pgcompactable. ఇది కొద్దిగా భిన్నమైన సూత్రాల ప్రకారం పనిచేస్తుంది కాబట్టి ఇది వనరులతో మరింత జాగ్రత్తగా ఉంటుంది. pgcompactable యొక్క ప్రధాన ఆలోచన ఏమిటంటే, ఇది పట్టికలోని నవీకరణలను ఉపయోగించి అన్ని ప్రత్యక్ష వరుసలను పట్టిక ప్రారంభానికి తరలిస్తుంది. ఆపై అది ఈ టేబుల్‌పై వాక్యూమ్‌ను నడుపుతుంది, ఎందుకంటే మనకు ప్రారంభంలో ప్రత్యక్ష వరుసలు మరియు చివరిలో చనిపోయిన వరుసలు ఉన్నాయని మాకు తెలుసు. మరియు వాక్యూమ్ స్వయంగా ఈ తోకను కత్తిరించుకుంటుంది, అనగా దీనికి ఎక్కువ అదనపు డిస్క్ స్థలం అవసరం లేదు. మరియు అదే సమయంలో, ఇది ఇప్పటికీ వనరుల పరంగా పిండి వేయబడుతుంది.

సాధనాలతో ప్రతిదీ.

మీరు మరింత లోపలికి వెళ్లే విషయంలో ఉబ్బరం అంశం ఆసక్తికరంగా ఉన్నట్లు అనిపిస్తే, ఇక్కడ కొన్ని ఉపయోగకరమైన లింక్‌లు ఉన్నాయి:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ఇది నా సహోద్యోగి నుండి వచ్చిన నివేదిక. పోస్ట్‌గ్రెస్ స్థలం దాని పని మరియు జీవితంలో ఎక్కడికి వెళుతుందనేది సాధారణం. మరియు బ్లోట్ గురించి డేటాబేస్ నిర్వాహకుల కోసం చాలా పెద్ద మరియు వివరణాత్మక సాంకేతిక భాగం ఉంది.
• https://github.com/dataegret/pg-utils - ఇది మా రిపోజిటరీకి లింక్, ఇక్కడ మేము డేటాబేస్ స్థితిని తనిఖీ చేయడానికి ఉపయోగకరమైన స్క్రిప్ట్‌ల సమూహాన్ని నిల్వ చేస్తాము. అక్కడ మీరు ఉబ్బు కోసం శోధించడానికి స్క్రిప్ట్‌లను కనుగొనవచ్చు.
• మూడో и నాల్గవది సంకేతాలను తగ్గించడంలో మీకు సహాయపడే సాధనాలకు లింక్‌లు.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ఇది నా సహోద్యోగి నుండి పోస్ట్. అక్కడ అతను చాలా తీవ్రంగా మరియు సాంకేతికంగా నిర్వాహకులకు దగ్గరగా ఉన్న స్థాయిలో ఉబ్బును వివరంగా విశ్లేషిస్తాడు.

డెవలపర్‌ల కోసం భయానక కథనాన్ని చూపించడానికి నేను మరింత ప్రయత్నించాను, ఎందుకంటే వారు డేటాబేస్‌ల యొక్క మా ప్రత్యక్ష క్లయింట్‌లు మరియు ఏమి మరియు ఏ చర్యలు దారితీస్తాయో అర్థం చేసుకోవాలి. నేను విజయం సాధించానని ఆశిస్తున్నాను. మీరు ఆసక్తి చూపినందుకు ధన్యవాదములు!

మీ ప్రశ్నలు

నివేదికకు ధన్యవాదాలు! మీరు సమస్యలను ఎలా గుర్తించవచ్చనే దాని గురించి మీరు మాట్లాడారు. వారిని ఎలా హెచ్చరించవచ్చు? అంటే, కొన్ని బాహ్య సేవలను యాక్సెస్ చేసినందున మాత్రమే అభ్యర్థనలు వేలాడదీసే పరిస్థితి నాకు ఉంది. ఇవి కొన్ని అడవి చేరికలు మాత్రమే. కొన్ని చిన్న చిన్న, హానిచేయని అభ్యర్థనలు ఒక రోజు చుట్టూ ఉన్నాయి, ఆపై కొన్ని అర్ధంలేనివి చేయడం ప్రారంభించాయి. అంటే, మీరు వివరించిన దానికి చాలా పోలి ఉంటుంది. దీన్ని ఎలా ట్రాక్ చేయాలి? ఏ అభ్యర్థన చిక్కుకుపోయిందో కూర్చుని నిరంతరం చూస్తున్నారా? దీన్ని ఎలా నిరోధించవచ్చు?

ఈ సందర్భంలో, ఇది మీ కంపెనీ నిర్వాహకులకు విధిగా ఉంటుంది, DBA కోసం అవసరం లేదు.

నేను అడ్మినిస్ట్రేటర్‌ని.

PostgreSQL డాంగ్లింగ్ ప్రశ్నలను చూపే pg_stat_activity అనే వీక్షణను కలిగి ఉంది. మరియు అది అక్కడ ఎంతసేపు వేలాడుతుందో మీరు చూడవచ్చు.

నేను ప్రతి 5 నిమిషాలకు వచ్చి చూడాలా?

క్రాన్‌ని సెటప్ చేసి తనిఖీ చేయండి. మీకు దీర్ఘకాలిక అభ్యర్థన ఉంటే, ఒక లేఖ రాయండి మరియు అంతే. అంటే, మీరు మీ కళ్ళతో చూడవలసిన అవసరం లేదు, ఇది స్వయంచాలకంగా ఉంటుంది. మీరు ఒక లేఖను అందుకుంటారు, మీరు దానికి ప్రతిస్పందిస్తారు. లేదా మీరు స్వయంచాలకంగా షూట్ చేయవచ్చు.

ఇలా జరగడానికి ఏవైనా స్పష్టమైన కారణాలు ఉన్నాయా?

నేను కొన్ని జాబితా చేసాను. ఇతర సంక్లిష్ట ఉదాహరణలు. మరియు చాలా సేపు సంభాషణ ఉండవచ్చు.

నివేదికకు ధన్యవాదాలు! నేను pg_repack యుటిలిటీ గురించి స్పష్టం చేయాలనుకుంటున్నాను. ఆమె ప్రత్యేకమైన లాక్ చేయకపోతే, అప్పుడు...

ఆమె ప్రత్యేకమైన లాక్ చేస్తుంది.

... అప్పుడు నేను డేటాను కోల్పోయే అవకాశం ఉంది. ఈ సమయంలో నా అప్లికేషన్ ఏదైనా రికార్డ్ చేయకూడదా?

లేదు, ఇది టేబుల్‌తో సజావుగా పని చేస్తుంది, అనగా pg_repack ముందుగా ఉన్న అన్ని లైవ్ లైన్‌లను బదిలీ చేస్తుంది. సహజంగానే, పట్టికలో ఒక రకమైన ప్రవేశం అక్కడ జరుగుతుంది. అతను ఈ పోనీటైల్‌ని బయటకు విసిరేస్తున్నాడు.

అంటే, అతను చివరికి చేస్తాడా?

చివరికి, అతను ఈ ఫైల్‌లను మార్చుకోవడానికి ప్రత్యేకమైన లాక్‌ని తీసుకుంటాడు.

ఇది VACUUM FULL కంటే వేగంగా ఉంటుందా?

VACUUM FULL, అది ప్రారంభించిన వెంటనే, వెంటనే ప్రత్యేకమైన లాక్‌ని తీసుకుంది. మరియు అతను ప్రతిదీ చేసే వరకు, అతను ఆమెను వెళ్ళనివ్వడు. మరియు pg_repack ఫైల్ రీప్లేస్‌మెంట్ సమయంలో మాత్రమే ప్రత్యేకమైన లాక్‌ని తీసుకుంటుంది. ఈ సమయంలో మీరు అక్కడ వ్రాయరు, కానీ డేటా కోల్పోదు, ప్రతిదీ బాగానే ఉంటుంది.

హలో! మీరు కారు వాక్యూమ్ యొక్క ఆపరేషన్ గురించి మాట్లాడారు. ఎరుపు, పసుపు మరియు ఆకుపచ్చ రికార్డింగ్ సెల్‌లతో గ్రాఫ్ ఉంది. అంటే, పసుపు రంగులు - అతను వాటిని తొలగించినట్లు గుర్తించాడు. మరియు ఫలితంగా, వాటిలో కొత్తది వ్రాయవచ్చు?

అవును. పోస్ట్‌గ్రెస్ పంక్తులను తొలగించదు. అతనికి అలాంటి ప్రత్యేకత ఉంది. మేము పంక్తిని అప్‌డేట్ చేసినట్లయితే, పాతది తొలగించబడినట్లు గుర్తు పెట్టాము. ఈ పంక్తిని మార్చిన లావాదేవీ యొక్క id అక్కడ కనిపిస్తుంది మరియు మేము కొత్త పంక్తిని వ్రాస్తాము. మరియు మేము వాటిని చదవగలిగే సెషన్‌లను కలిగి ఉన్నాము. ఏదో ఒక సమయంలో వారు చాలా పాతవారు అవుతారు. మరియు ఆటోవాక్యూమ్ ఎలా పనిచేస్తుందనే దాని సారాంశం ఏమిటంటే అది ఈ పంక్తుల గుండా వెళుతుంది మరియు వాటిని అనవసరమైనదిగా సూచిస్తుంది. మరియు మీరు అక్కడ డేటాను ఓవర్రైట్ చేయవచ్చు.

నాకు అర్థమైనది. కానీ ప్రశ్న దాని గురించి కాదు. నేను పూర్తి చేయలేదు. మన దగ్గర టేబుల్ ఉందనుకుందాం. ఇది వేరియబుల్ సైజు ఫీల్డ్‌లను కలిగి ఉంది. మరియు నేను కొత్తదాన్ని చొప్పించడానికి ప్రయత్నిస్తే, అది పాత సెల్‌కి సరిపోకపోవచ్చు.

లేదు, ఏ సందర్భంలోనైనా మొత్తం లైన్ అక్కడ నవీకరించబడుతుంది. Postgres రెండు డేటా నిల్వ నమూనాలను కలిగి ఉంది. ఇది డేటా రకం నుండి ఎంపిక చేస్తుంది. పట్టికలో నేరుగా నిల్వ చేయబడిన డేటా ఉంది మరియు టాస్ డేటా కూడా ఉంది. ఇవి పెద్ద మొత్తంలో డేటా: టెక్స్ట్, json. అవి ప్రత్యేక ప్లేట్లలో నిల్వ చేయబడతాయి. మరియు ఈ మాత్రల ప్రకారం, ఉబ్బుతో అదే కథ సంభవిస్తుంది, అనగా ప్రతిదీ ఒకే విధంగా ఉంటుంది. అవి కేవలం విడిగా జాబితా చేయబడ్డాయి.

నివేదికకు ధన్యవాదాలు! వ్యవధిని పరిమితం చేయడానికి స్టేట్‌మెంట్ గడువు ముగిసిన ప్రశ్నలను ఉపయోగించడం ఆమోదయోగ్యమేనా?

చాలా ఆమోదయోగ్యమైనది. మేము దీన్ని ప్రతిచోటా ఉపయోగిస్తాము. మరియు మాకు మా స్వంత సేవలు లేనందున, మేము రిమోట్ మద్దతును అందిస్తాము, మాకు చాలా విభిన్నమైన క్లయింట్లు ఉన్నారు. మరియు ప్రతి ఒక్కరూ దీనితో పూర్తిగా సంతృప్తి చెందారు. అంటే, మాకు చెక్ చేసే క్రాన్ జాబ్‌లు ఉన్నాయి. సెషన్‌ల వ్యవధి క్లయింట్‌తో కేవలం అంగీకరించబడుతుంది, దీనికి ముందు మేము అంగీకరించము. ఇది ఒక నిమిషం కావచ్చు, అది 10 నిమిషాలు కావచ్చు. ఇది బేస్ మరియు దాని ప్రయోజనంపై లోడ్పై ఆధారపడి ఉంటుంది. కానీ మనమందరం pg_stat_activityని ఉపయోగిస్తాము.

నివేదికకు ధన్యవాదాలు! నేను మీ నివేదికను నా దరఖాస్తులకు వర్తింపజేయడానికి ప్రయత్నిస్తున్నాను. మరియు మేము ప్రతిచోటా లావాదేవీని ప్రారంభించినట్లుగా మరియు ప్రతిచోటా స్పష్టంగా పూర్తి చేసినట్లుగా కనిపిస్తోంది. కొంత మినహాయింపు ఉంటే, రోల్‌బ్యాక్ ఇప్పటికీ జరుగుతుంది. ఆపై నేను ఆలోచించడం మొదలుపెట్టాను. అన్నింటికంటే, లావాదేవీ స్పష్టంగా ప్రారంభం కాకపోవచ్చు. ఇది బహుశా అమ్మాయికి సూచన. నేను ఇప్పుడే రికార్డ్‌ను అప్‌డేట్ చేస్తే, లావాదేవీ PostgreSQLలో ప్రారంభమై కనెక్షన్ డిస్‌కనెక్ట్ అయినప్పుడు మాత్రమే పూర్తవుతుందా?

మీరు ఇప్పుడు అప్లికేషన్ స్థాయి గురించి మాట్లాడుతున్నట్లయితే, అది మీరు ఉపయోగిస్తున్న డ్రైవర్‌పై, వినియోగిస్తున్న ORMపై ఆధారపడి ఉంటుంది. అక్కడ చాలా సెట్టింగ్స్ ఉన్నాయి. మీరు ఆటో కమిట్ ఆన్ ఎనేబుల్ చేసి ఉంటే, అక్కడ లావాదేవీ మొదలై వెంటనే మూసివేయబడుతుంది.

అంటే, ఇది నవీకరణ తర్వాత వెంటనే మూసివేయబడుతుంది?

ఇది సెట్టింగులపై ఆధారపడి ఉంటుంది. నేను ఒక సెట్టింగ్‌కి పేరు పెట్టాను. ఇది ఆటో కమిట్ ఆన్. ఇది సర్వసాధారణం. ఇది ప్రారంభించబడితే, లావాదేవీ తెరవబడి మూసివేయబడుతుంది. మీరు “లావాదేవీని ప్రారంభించండి” మరియు “లావాదేవీని ముగించండి” అని స్పష్టంగా చెప్పకపోతే, సెషన్‌లో అభ్యర్థనను ప్రారంభించండి.

హలో! నివేదికకు ధన్యవాదాలు! మనకు వాపు మరియు వాపు ఉన్న డేటాబేస్ ఉందని, ఆపై సర్వర్‌లో ఖాళీ అయిపోతుందని ఊహించుకుందాం. ఈ పరిస్థితిని పరిష్కరించడానికి ఏవైనా సాధనాలు ఉన్నాయా?

సర్వర్‌లోని ఖాళీని సరిగ్గా పర్యవేక్షించాలి.

ఉదాహరణకు, DBA టీ కోసం వెళ్ళింది, రిసార్ట్‌లో ఉంది, మొదలైనవి.

ఫైల్ సిస్టమ్ సృష్టించబడినప్పుడు, డేటా వ్రాయబడని చోట కనీసం కొంత రకమైన బ్యాకప్ స్థలం సృష్టించబడుతుంది.

ఇది పూర్తిగా సున్నా కంటే తక్కువగా ఉంటే?

అక్కడ దానిని రిజర్వ్ చేసిన స్థలం అని పిలుస్తారు, అనగా దానిని విముక్తి చేయవచ్చు మరియు అది ఎంత పెద్దదిగా సృష్టించబడిందనే దానిపై ఆధారపడి, మీరు ఖాళీ స్థలాన్ని పొందుతారు. డిఫాల్ట్‌గా ఎన్ని ఉన్నాయో నాకు తెలియదు. మరియు మరొక సందర్భంలో, డిస్క్‌లను బట్వాడా చేయండి, తద్వారా మీరు పునర్నిర్మాణ ఆపరేషన్ చేయడానికి స్థలం ఉంటుంది. మీకు అవసరం లేదని హామీ ఇవ్వబడిన కొన్ని పట్టికలను మీరు తొలగించవచ్చు.

ఇతర సాధనాలు ఏమైనా ఉన్నాయా?

ఇది ఎల్లప్పుడూ చేతితో తయారు చేయబడింది. మరియు స్థానికంగా అక్కడ ఏమి చేయడం ఉత్తమం అనేది స్పష్టమవుతుంది, ఎందుకంటే కొన్ని డేటా క్లిష్టమైనది మరియు కొన్ని క్లిష్టమైనది కాదు. మరియు ప్రతి డేటాబేస్ మరియు దానితో పనిచేసే అప్లికేషన్, ఇది వ్యాపారంపై ఆధారపడి ఉంటుంది. ఇది ఎల్లప్పుడూ స్థానికంగా నిర్ణయించబడుతుంది.

నివేదికకు ధన్యవాదాలు! నాకు రెండు ప్రశ్నలు ఉన్నాయి. ముందుగా, లావాదేవీలు నిలిచిపోయినప్పుడు, టేబుల్‌స్పేస్ పరిమాణం మరియు సూచిక పరిమాణం రెండూ పెరుగుతాయని చూపించే స్లయిడ్‌లను మీరు చూపించారు. మరియు నివేదికలో టాబ్లెట్‌ను ప్యాకేజీ చేసే అనేక యుటిలిటీలు ఉన్నాయి. ఇండెక్స్ గురించి ఏమిటి?

వాటిని కూడా సర్దుకుంటారు.

కానీ వాక్యూమ్ సూచికను ప్రభావితం చేయలేదా?

కొన్ని ఇండెక్స్‌తో పని చేస్తాయి. ఉదాహరణకు, pg_rapack, pgcompacttable. వాక్యూమ్ సూచికలను పునఃసృష్టిస్తుంది మరియు వాటిని ప్రభావితం చేస్తుంది. VACUUM FULLతో ప్రతిదీ ఓవర్‌రైట్ చేయాలనే ఆలోచన ఉంటుంది, అనగా ఇది అందరితో పని చేస్తుంది.

మరియు రెండవ ప్రశ్న. ప్రతిరూపాలపై నివేదికలు ప్రతిరూపణపైనే ఎందుకు ఆధారపడతాయో నాకు అర్థం కాలేదు. నివేదికలు చదవడం, ప్రతిరూపం రాయడం అని నాకు అనిపించింది.

ప్రతిరూపణ సంఘర్షణకు కారణమేమిటి? ఏ ప్రక్రియలు జరుగుతాయో మాకు మాస్టర్ ఉంది. మాకు కారు వాక్యూమ్ జరుగుతోంది. ఆటోవాక్యూమ్ వాస్తవానికి ఏమి చేస్తుంది? అతను కొన్ని పాత లైన్లను కత్తిరించాడు. ఈ సమయంలో ఈ పాత పంక్తులను చదివే ప్రతిరూపంపై మాకు అభ్యర్థన ఉంటే మరియు మాస్టర్‌పై ఆటోవాక్యూమ్ ఈ పంక్తులను ఓవర్‌రైటింగ్ కోసం వీలైనంతగా గుర్తించే పరిస్థితి ఏర్పడినట్లయితే, మేము వాటిని భర్తీ చేసాము. మరియు మేము డేటా ప్యాకెట్‌ను స్వీకరించాము, అభ్యర్థనకు ప్రతిరూపంలో అవసరమైన పంక్తులను తిరిగి వ్రాయవలసి వచ్చినప్పుడు, మీరు కాన్ఫిగర్ చేసిన సమయం ముగిసే వరకు ప్రతిరూపణ ప్రక్రియ వేచి ఉంటుంది. ఆపై PostgreSQL దానికి ఏది ముఖ్యమైనదో నిర్ణయిస్తుంది. మరియు అభ్యర్థన కంటే ప్రతిరూపం అతనికి చాలా ముఖ్యమైనది మరియు ప్రతిరూపంలో ఈ మార్పులను చేయడానికి అతను అభ్యర్థనను షూట్ చేస్తాడు.

ఆండ్రీ, నాకు ఒక ప్రశ్న ఉంది. ప్రెజెంటేషన్ సమయంలో మీరు చూపించిన ఈ అద్భుతమైన గ్రాఫ్‌లు, ఇవి మీ యొక్క ఒక రకమైన యుటిలిటీ యొక్క పని ఫలితమా? గ్రాఫ్‌లు ఎలా తయారు చేయబడ్డాయి?

ఇది ఒక సేవ ఆక్మీటర్.

ఇది వాణిజ్య ఉత్పత్తి?

అవును. ఇది వాణిజ్య ఉత్పత్తి.

మూలం: www.habr.com