PostgreSQL పర్యవేక్షణ యొక్క ప్రాథమిక అంశాలు. అలెక్సీ లెసోవ్స్కీ

డేటా ఎగ్రెట్ “ఫండమెంటల్స్ ఆఫ్ పోస్ట్‌గ్రెస్‌స్క్యూఎల్ మానిటరింగ్” నుండి అలెక్సీ లెసోవ్‌స్కీ రిపోర్ట్ యొక్క ట్రాన్స్క్రిప్ట్ చదవమని నేను మీకు సూచిస్తున్నాను.

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

నా పేరు అలెక్సీ లెసోవ్స్కీ, నేను డేటా ఎగ్రెట్ కంపెనీకి ప్రాతినిధ్యం వహిస్తున్నాను.

నా గురించి కొన్ని మాటలు. నేను సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా చాలా కాలం క్రితం ప్రారంభించాను.

నేను అన్ని రకాల విభిన్న Linux సిస్టమ్‌లను నిర్వహించాను, Linuxకి సంబంధించిన వివిధ విషయాలపై పని చేసాను, అనగా వర్చువలైజేషన్, మానిటరింగ్, ప్రాక్సీలతో పని చేసాను, మొదలైనవి. కానీ ఏదో ఒక సమయంలో నేను డేటాబేస్, PostgreSQLతో ఎక్కువగా పని చేయడం ప్రారంభించాను. నేను అతన్ని నిజంగా ఇష్టపడ్డాను. మరియు ఏదో ఒక సమయంలో నేను నా పని సమయంలో ఎక్కువ భాగం PostgreSQLలో పని చేయడం ప్రారంభించాను. కాబట్టి క్రమంగా నేను PostgreSQL DBA అయ్యాను.

మరియు నా కెరీర్ మొత్తంలో, నేను ఎల్లప్పుడూ గణాంకాలు, పర్యవేక్షణ మరియు టెలిమెట్రీ విషయాలపై ఆసక్తి కలిగి ఉన్నాను. మరియు నేను సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా ఉన్నప్పుడు, నేను Zabbixతో చాలా సన్నిహితంగా పనిచేశాను. మరియు నేను వంటి చిన్న స్క్రిప్ట్స్ రాశాను zabbix-పొడిగింపులు. అతను తన కాలంలో బాగా ప్రాచుర్యం పొందాడు. మరియు అక్కడ చాలా భిన్నమైన ముఖ్యమైన విషయాలను పర్యవేక్షించడం సాధ్యమైంది, Linux మాత్రమే కాకుండా, వివిధ భాగాలు కూడా.

ఇప్పుడు నేను PostgreSQLలో పని చేస్తున్నాను. PostgreSQL గణాంకాలతో పని చేయడానికి మిమ్మల్ని అనుమతించే మరొక విషయం నేను ఇప్పటికే వ్రాస్తున్నాను. ఇది అంటారు pgCenter (హబ్రేపై కథనం - నరాలు మరియు ఉద్రిక్తత లేకుండా పోస్ట్-గ్రెస్ గణాంకాలు).

ఒక చిన్న పరిచయ గమనిక. మా కస్టమర్‌లు, మా క్లయింట్లు ఎలాంటి పరిస్థితులను కలిగి ఉన్నారు? డేటాబేస్కు సంబంధించి ఒక రకమైన ప్రమాదం ఉంది. డేటాబేస్ ఇప్పటికే పునరుద్ధరించబడినప్పుడు, డిపార్ట్‌మెంట్ హెడ్ లేదా డెవలప్‌మెంట్ హెడ్ వచ్చి ఇలా అంటారు: “మిత్రులారా, మేము డేటాబేస్‌ను పర్యవేక్షించాలి, ఎందుకంటే ఏదో చెడు జరిగింది మరియు భవిష్యత్తులో ఇది జరగకుండా నిరోధించాలి.” మరియు ఇక్కడ పర్యవేక్షణ వ్యవస్థను ఎంచుకోవడం లేదా ఇప్పటికే ఉన్న మానిటరింగ్ సిస్టమ్‌ను స్వీకరించడం వంటి ఆసక్తికరమైన ప్రక్రియ ప్రారంభమవుతుంది, తద్వారా మీరు మీ డేటాబేస్‌ను పర్యవేక్షించగలరు - PostgreSQL, MySQL లేదా మరికొన్ని. మరియు సహచరులు సూచించడం ప్రారంభిస్తారు: “అటువంటి డేటాబేస్ ఉందని నేను విన్నాను. వాడుకుందాం." సహోద్యోగులు ఒకరితో ఒకరు వాదించడం ప్రారంభిస్తారు. మరియు చివరికి మేము ఒక రకమైన డేటాబేస్ను ఎంచుకున్నామని తేలింది, కానీ PostgreSQL పర్యవేక్షణ దానిలో చాలా తక్కువగా ప్రదర్శించబడుతుంది మరియు మేము ఎల్లప్పుడూ ఏదైనా జోడించాలి. GitHub నుండి కొన్ని రిపోజిటరీలను తీసుకోండి, వాటిని క్లోన్ చేయండి, స్క్రిప్ట్‌లను స్వీకరించండి మరియు వాటిని ఎలాగైనా అనుకూలీకరించండి. మరియు చివరికి ఇది ఒక రకమైన మాన్యువల్ పనిగా ముగుస్తుంది.

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

మరియు ఈ నివేదికలో ఉన్న ఆలోచనలు నేరుగా ఏదైనా డేటాబేస్‌కు స్వీకరించబడతాయి, అది DBMS లేదా noSQL కావచ్చు. అందువల్ల, PostgreSQL మాత్రమే కాదు, PostgreSQLలో దీన్ని ఎలా చేయాలో అనేక వంటకాలు ఉంటాయి. PostgreSQL పర్యవేక్షణ కోసం ప్రశ్నలకు ఉదాహరణలు, ఎంటిటీల ఉదాహరణలు ఉంటాయి. మరియు మీ DBMS వాటిని పర్యవేక్షణలో ఉంచడానికి మిమ్మల్ని అనుమతించే అదే అంశాలను కలిగి ఉంటే, మీరు వాటిని కూడా స్వీకరించవచ్చు, వాటిని జోడించవచ్చు మరియు అది మంచిది.

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

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

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

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

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

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

మీరు ఈ సంఖ్యలను మీకు ఇష్టమైన మానిటరింగ్ సిస్టమ్‌కు జోడించవచ్చు, గ్రాఫ్‌లను గీయవచ్చు, ఫంక్షన్‌లను జోడించవచ్చు మరియు దీర్ఘకాలికంగా విశ్లేషణలను పొందవచ్చు.

కానీ ఈ నివేదికలో నేను ఈ అన్ని విధులను పూర్తిగా కవర్ చేయను, ఎందుకంటే దీనికి రోజంతా పట్టవచ్చు. నేను అక్షరాలా రెండు, మూడు లేదా నాలుగు విషయాలను పరిష్కరిస్తాను మరియు అవి పర్యవేక్షణను మెరుగుపరచడంలో ఎలా సహాయపడతాయో మీకు తెలియజేస్తాను.

మరియు మేము డేటాబేస్ పర్యవేక్షణ గురించి మాట్లాడినట్లయితే, అప్పుడు ఏమి పర్యవేక్షించబడాలి? అన్నింటిలో మొదటిది, మేము లభ్యతను పర్యవేక్షించాలి, ఎందుకంటే డేటాబేస్ అనేది క్లయింట్‌లకు డేటాకు ప్రాప్యతను అందించే సేవ మరియు మేము లభ్యతను పర్యవేక్షించాలి మరియు దాని గుణాత్మక మరియు పరిమాణాత్మక లక్షణాలను కూడా అందించాలి.

మా డేటాబేస్‌కు కనెక్ట్ అయ్యే క్లయింట్‌లను కూడా మేము పర్యవేక్షించాలి, ఎందుకంటే వారు డేటాబేస్‌కు హాని కలిగించే సాధారణ క్లయింట్‌లు మరియు హానికరమైన క్లయింట్‌లు కావచ్చు. వారు కూడా పర్యవేక్షించబడాలి మరియు వారి కార్యకలాపాలను ట్రాక్ చేయాలి.

క్లయింట్‌లు డేటాబేస్‌కి కనెక్ట్ అయినప్పుడు, వారు మా డేటాతో పని చేయడం ప్రారంభిస్తారని స్పష్టంగా తెలుస్తుంది, కాబట్టి క్లయింట్‌లు డేటాతో ఎలా పని చేస్తారో మనం పర్యవేక్షించాలి: ఏ పట్టికలతో మరియు కొంత మేరకు, ఏ సూచికలతో. అంటే, మా క్లయింట్లు సృష్టించే పనిభారాన్ని మనం అంచనా వేయాలి.

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

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

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

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

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

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

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

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

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

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

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

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

ఒక లావాదేవీకి అనేక అభ్యర్థనలు సరిపోతాయని అందరూ అర్థం చేసుకున్నారా? అందువల్ల TPS మరియు QPS కొద్దిగా భిన్నంగా ఉంటాయి.

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

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

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

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

మీరు దీన్ని ఎందుకు పర్యవేక్షించాలి? ఎందుకంటే వాక్యూమ్ కొన్నిసార్లు చాలా బాధిస్తుంది. ఇది పెద్ద మొత్తంలో వనరులను వినియోగిస్తుంది మరియు క్లయింట్ అభ్యర్థనలు ఫలితంగా బాధపడటం ప్రారంభమవుతుంది.

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

PostgreSQL గురించి మరొక విషయం ఏమిటంటే, PostgreSQL సుదీర్ఘ లావాదేవీల వల్ల చాలా అనారోగ్యంతో ఉంది. ముఖ్యంగా చాలా కాలం పాటు వేలాడుతూ ఏమీ చేయని లావాదేవీల నుండి. ఇది స్టాట్ ఐడిల్-ఇన్-ట్రాన్సాక్షన్ అని పిలవబడేది. అటువంటి లావాదేవీ తాళాలను కలిగి ఉంటుంది మరియు వాక్యూమ్ పని చేయకుండా నిరోధిస్తుంది. మరియు ఫలితంగా, పట్టికలు ఉబ్బు మరియు పరిమాణం పెరుగుతాయి. మరియు ఈ పట్టికలతో పని చేసే ప్రశ్నలు నెమ్మదిగా పని చేయడం ప్రారంభిస్తాయి, ఎందుకంటే మీరు మెమరీ నుండి డిస్క్ మరియు వెనుకకు వరుసల అన్ని పాత సంస్కరణలను పారవేయాలి. అందువల్ల, సమయం, సుదీర్ఘ లావాదేవీల వ్యవధి, పొడవైన వాక్యూమ్ అభ్యర్థనలను కూడా పర్యవేక్షించడం అవసరం. మరియు OLTP లోడ్ కోసం ఇప్పటికే 10-20-30 నిమిషాల కంటే ఎక్కువ కాలం నడుస్తున్న కొన్ని ప్రక్రియలను మనం చూసినట్లయితే, మేము వాటిపై శ్రద్ధ వహించాలి మరియు వాటిని బలవంతంగా ముగించాలి లేదా అప్లికేషన్‌ను ఆప్టిమైజ్ చేయాలి. పిలవబడరు మరియు చాలా సేపు వేలాడదీయవద్దు. విశ్లేషణాత్మక పనిభారం కోసం, 10-20-30 నిమిషాలు సాధారణం; ఎక్కువ కాలం కూడా ఉన్నాయి.

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

కనెక్ట్ చేయబడిన క్లయింట్‌ల గురించిన సమాచారం ముఖ్యమైనది ఎందుకంటే, PostgreSQL కోణం నుండి, క్లయింట్లు భిన్నంగా ఉంటారు. మంచి క్లయింట్లు ఉన్నారు మరియు చెడ్డ క్లయింట్లు ఉన్నారు.

ఒక సాధారణ ఉదాహరణ. క్లయింట్ ద్వారా నేను అప్లికేషన్‌ను అర్థం చేసుకున్నాను. అప్లికేషన్ డేటాబేస్‌కు కనెక్ట్ చేయబడింది మరియు వెంటనే దాని అభ్యర్థనలను అక్కడకు పంపడం ప్రారంభిస్తుంది, డేటాబేస్ వాటిని ప్రాసెస్ చేస్తుంది మరియు అమలు చేస్తుంది మరియు ఫలితాలను క్లయింట్‌కు అందిస్తుంది. వీరు మంచి మరియు సరైన క్లయింట్లు.

క్లయింట్ కనెక్ట్ అయినప్పుడు పరిస్థితులు ఉన్నాయి, అది కనెక్షన్‌ని కలిగి ఉంటుంది, కానీ ఏమీ చేయదు. ఇది నిష్క్రియ స్థితిలో ఉంది.

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

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

పర్యవేక్షణకు మరొక ఉదాహరణ. మరియు ఇక్కడ ఇప్పటికే మంచి డాష్‌బోర్డ్ ఉంది. పైన కనెక్షన్‌ల సమాచారం ఉంది. DB కనెక్షన్ - 8 ముక్కలు. మరియు ఇది అంతా. ఏ క్లయింట్‌లు యాక్టివ్‌గా ఉన్నారు, ఏ క్లయింట్‌లు నిష్క్రియంగా ఉన్నారు, ఏమీ చేయడం లేదు అనే దాని గురించి మాకు సమాచారం లేదు. పెండింగ్‌లో ఉన్న లావాదేవీలు మరియు పెండింగ్ కనెక్షన్‌ల గురించి సమాచారం లేదు, అంటే ఇది కనెక్షన్‌ల సంఖ్యను చూపే సంఖ్య మరియు అంతే. ఆపై మీరే ఊహించండి.

దీని ప్రకారం, పర్యవేక్షణకు ఈ సమాచారాన్ని జోడించడానికి, మీరు pg_stat_activity సిస్టమ్ వీక్షణను యాక్సెస్ చేయాలి. మీరు PostgreSQLలో ఎక్కువ సమయం గడిపినట్లయితే, ఇది చాలా మంచి వీక్షణ, ఇది మీ స్నేహితుడిగా మారాలి, ఎందుకంటే ఇది PostgreSQLలో ప్రస్తుత కార్యాచరణను చూపుతుంది, అంటే దానిలో ఏమి జరుగుతోంది. ప్రతి ప్రాసెస్ కోసం ఈ ప్రక్రియ గురించి సమాచారాన్ని చూపే ప్రత్యేక లైన్ ఉంది: ఏ హోస్ట్ నుండి కనెక్షన్ చేయబడింది, ఏ వినియోగదారు కింద, ఏ పేరుతో, లావాదేవీని ప్రారంభించినప్పుడు, ప్రస్తుతం ఏ అభ్యర్థన అమలులో ఉంది, చివరిగా ఏ అభ్యర్థన అమలు చేయబడింది. మరియు, తదనుగుణంగా, మేము స్టాట్ ఫీల్డ్‌ని ఉపయోగించి క్లయింట్ యొక్క స్థితిని అంచనా వేయవచ్చు. సాపేక్షంగా చెప్పాలంటే, మేము ఈ ఫీల్డ్ ద్వారా సమూహపరచవచ్చు మరియు ప్రస్తుతం డేటాబేస్‌లో ఉన్న గణాంకాలను మరియు డేటాబేస్‌లో ఈ గణాంకాలను కలిగి ఉన్న కనెక్షన్‌ల సంఖ్యను పొందవచ్చు. మరియు మేము ఇప్పటికే అందుకున్న నంబర్‌లను మా పర్యవేక్షణకు పంపవచ్చు మరియు వాటి ఆధారంగా గ్రాఫ్‌లను గీయవచ్చు.
లావాదేవీ వ్యవధిని అంచనా వేయడం కూడా ముఖ్యం. వాక్యూమ్‌ల వ్యవధిని అంచనా వేయడం చాలా ముఖ్యం అని నేను ఇప్పటికే చెప్పాను, అయితే లావాదేవీలు అదే విధంగా మూల్యాంకనం చేయబడతాయి. xact_start మరియు query_start ఫీల్డ్‌లు ఉన్నాయి. వారు, సాపేక్షంగా చెప్పాలంటే, లావాదేవీ ప్రారంభ సమయం మరియు అభ్యర్థన ప్రారంభ సమయాన్ని చూపుతారు. మేము ఇప్పుడు () ఫంక్షన్‌ని తీసుకుంటాము, ఇది ప్రస్తుత టైమ్‌స్టాంప్‌ను చూపుతుంది మరియు లావాదేవీని తీసివేసి టైమ్‌స్టాంప్‌ను అభ్యర్థిస్తాము. మరియు మేము లావాదేవీ వ్యవధి, అభ్యర్థన వ్యవధిని పొందుతాము.

మేము సుదీర్ఘ లావాదేవీలను చూసినట్లయితే, మేము వాటిని ఇప్పటికే పూర్తి చేయాలి. OLTP లోడ్ కోసం, సుదీర్ఘ లావాదేవీలు ఇప్పటికే 1-2-3 నిమిషాల కంటే ఎక్కువ. OLAP పనిభారం కోసం, సుదీర్ఘ లావాదేవీలు సాధారణం, కానీ అవి పూర్తి కావడానికి రెండు గంటల కంటే ఎక్కువ సమయం తీసుకుంటే, ఇది కూడా మనకు ఎక్కడో వక్రమార్గం ఉందని సంకేతం.

క్లయింట్‌లు డేటాబేస్‌కు కనెక్ట్ అయిన తర్వాత, వారు మా డేటాతో పని చేయడం ప్రారంభిస్తారు. వారు పట్టికలను యాక్సెస్ చేస్తారు, వారు పట్టిక నుండి డేటాను పొందడానికి సూచికలను యాక్సెస్ చేస్తారు. మరియు క్లయింట్లు ఈ డేటాతో ఎలా ఇంటరాక్ట్ అవుతారో విశ్లేషించడం ముఖ్యం.

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

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

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

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

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

మరియు మేము దీనిని పర్యవేక్షణలో చూడవచ్చు. మరియు ఇప్పటికే ఈ ప్రశ్నను చూడండి, దాని కోసం వివరించండి, గణాంకాలను సేకరించండి, కొత్త అదనపు సూచికను రూపొందించండి. మరియు ఇప్పటికే ఈ సమస్యకు స్పందించండి. అందుకే ఇది ముఖ్యం.

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

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

ఈ పట్టికలలో గణాంకాలను ఎలా పొందాలి? ఈ ప్రయోజనం కోసం, PostgreSQLకి నిర్దిష్ట కుటుంబ వీక్షణలు ఉన్నాయి. మరియు ప్రధాన అభిప్రాయం pg_stat_user_tables. User_tables - దీని అర్థం వినియోగదారు తరపున సృష్టించబడిన పట్టికలు. దీనికి విరుద్ధంగా, PostgreSQL ద్వారా ఉపయోగించబడే సిస్టమ్ వీక్షణలు ఉన్నాయి. మరియు సారాంశం పట్టిక ఆల్టేబుల్స్ ఉంది, ఇందులో సిస్టమ్ మరియు యూజర్ వాటిని కలిగి ఉంటుంది. వాటిలో మీకు బాగా నచ్చిన వాటి నుండి మీరు ప్రారంభించవచ్చు.

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

ఈ డేటా ఆధారంగా, మేము TopN పట్టికలు అని పిలవబడే వాటిని రూపొందించవచ్చు. ఉదాహరణకు, టాప్-5, టాప్-10. మరియు మీరు ఇతరుల కంటే ఎక్కువగా రీసైకిల్ చేయబడిన హాట్ టేబుల్‌లను ట్రాక్ చేయవచ్చు. ఉదాహరణకు, చొప్పించడం కోసం 5 "హాట్" పట్టికలు. మరియు ఈ TopN పట్టికలను ఉపయోగించి మేము మా పనిభారాన్ని మూల్యాంకనం చేస్తాము మరియు ఏవైనా విడుదలలు, నవీకరణలు మరియు విస్తరణల తర్వాత పనిభారాన్ని అంచనా వేయవచ్చు.

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

మరియు ఇప్పుడు మీ కోసం ఒక చిన్న ప్రశ్న. మీరు మీ డేటాబేస్ సర్వర్‌లో లోడ్‌ను గమనించినప్పుడు ఏ ప్రశ్న తలెత్తుతుంది? మీకు తదుపరి ప్రశ్న ఏమిటి?

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

దీని ప్రకారం, మీరు అత్యధిక లోడ్‌కు కారణమయ్యే ప్రశ్నలను కనుగొనవలసి ఉంటుంది, ఎందుకంటే ట్యూనింగ్ ప్రశ్నలు, నియమం ప్రకారం, PostgreSQL లేదా ఆపరేటింగ్ సిస్టమ్ కాన్ఫిగరేషన్‌ను ట్యూన్ చేయడం లేదా హార్డ్‌వేర్‌ను ట్యూన్ చేయడం కంటే ఎక్కువ లాభాన్ని ఇస్తుంది. నా అంచనా ప్రకారం, ఇది దాదాపు 80-85-90%. మరియు ఇది చాలా వేగంగా జరుగుతుంది. కాన్ఫిగరేషన్‌ను సరిదిద్దడం, పునఃప్రారంభించడాన్ని షెడ్యూల్ చేయడం, ప్రత్యేకించి డేటాబేస్ పునఃప్రారంభించబడకపోతే లేదా హార్డ్‌వేర్‌ను జోడించడం కంటే అభ్యర్థనను సరిచేయడం వేగంగా ఉంటుంది. ఈ ప్రశ్న నుండి మెరుగైన ఫలితాన్ని పొందడానికి ప్రశ్నను ఎక్కడైనా తిరిగి వ్రాయడం లేదా సూచికను జోడించడం సులభం.

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

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

మీరు పొడవైన ప్రశ్నలను పర్యవేక్షించవచ్చు, అంటే, పూర్తి చేయడానికి ఎక్కువ సమయం పట్టే ప్రశ్నలను మీరు పర్యవేక్షించవచ్చు. అవి ప్రాసెసర్‌పై నడుస్తాయి, అవి I/Oని వినియోగిస్తాయి. మేము దీన్ని total_time, mean_time, blk_write_time మరియు blk_read_time ఫీల్డ్‌లను ఉపయోగించి కూడా అంచనా వేయవచ్చు.

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

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

మరియు మీరు తాత్కాలిక ఫైల్‌లు లేదా తాత్కాలిక పట్టికలను ఉపయోగించే ప్రశ్నలను కూడా పర్యవేక్షించవచ్చు.

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

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

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

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

దీని ప్రకారం, పేర్కొన్న ఫీల్డ్‌లను ఉపయోగించి pg_stat_bgwriter ద్వారా మేము సంభవించే చెక్‌పాయింట్‌ల సంఖ్యను పర్యవేక్షించవచ్చు. మరియు మేము నిర్దిష్ట వ్యవధిలో (10-15-20 నిమిషాలలో, అరగంటలో) చాలా చెక్‌పోస్టులను కలిగి ఉంటే, ఉదాహరణకు, 3-4-5, ఇది ఇప్పటికే సమస్య కావచ్చు. మరియు మీరు ఇప్పటికే డేటాబేస్లో చూడాలి, కాన్ఫిగరేషన్‌లో చూడండి, చెక్‌పాయింట్ల సమృద్ధికి కారణమేమిటి. బహుశా ఏదో ఒక రకమైన పెద్ద రికార్డింగ్ జరుగుతోంది. మేము ఇప్పటికే పనిభారాన్ని అంచనా వేయవచ్చు, ఎందుకంటే మేము ఇప్పటికే పనిభార గ్రాఫ్‌లను జోడించాము. మేము ఇప్పటికే చెక్‌పాయింట్ పారామితులను సర్దుబాటు చేయవచ్చు మరియు అవి ప్రశ్న పనితీరును పెద్దగా ప్రభావితం చేయలేదని నిర్ధారించుకోవచ్చు.

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

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

మరియు, వాస్తవానికి, వాక్యూమ్ల వ్యవధి. మనకు చాలా కాలం పాటు నడిచే దీర్ఘకాలిక వాక్యూమ్‌లు ఉంటే, దీని అర్థం మనం మళ్లీ వాక్యూమ్ కాన్ఫిగరేషన్‌పై శ్రద్ధ వహించాలి మరియు దాని సెట్టింగ్‌లను పునఃపరిశీలించవచ్చు. ఎందుకంటే వాక్యూమ్ టేబుల్‌పై ఎక్కువసేపు (3-4 గంటలు) పనిచేసినప్పుడు పరిస్థితి తలెత్తవచ్చు, కానీ వాక్యూమ్ పని చేస్తున్న సమయంలో, పెద్ద మొత్తంలో చనిపోయిన వరుసలు మళ్లీ టేబుల్‌లో పేరుకుపోతాయి. మరియు వాక్యూమ్ పూర్తయిన వెంటనే, అతను ఈ పట్టికను మళ్లీ వాక్యూమ్ చేయాలి. మరియు మేము ఒక పరిస్థితికి వస్తాము - అంతులేని వాక్యూమ్. మరియు ఈ సందర్భంలో, వాక్యూమ్ దాని పనిని భరించదు, మరియు పట్టికలు క్రమంగా పరిమాణంలో ఉబ్బడం ప్రారంభిస్తాయి, అయినప్పటికీ దానిలోని ఉపయోగకరమైన డేటా పరిమాణం అలాగే ఉంటుంది. అందువల్ల, సుదీర్ఘ వాక్యూమ్‌ల సమయంలో, మేము ఎల్లప్పుడూ కాన్ఫిగరేషన్‌ను పరిశీలిస్తాము మరియు దానిని ఆప్టిమైజ్ చేయడానికి ప్రయత్నిస్తాము, కానీ అదే సమయంలో క్లయింట్ అభ్యర్థనల పనితీరు దెబ్బతినదు.

ఈ రోజుల్లో స్ట్రీమింగ్ రెప్లికేషన్ లేని PostgreSQL ఇన్‌స్టాలేషన్ ఆచరణాత్మకంగా లేదు. ప్రతిరూపం అనేది మాస్టర్ నుండి ప్రతిరూపానికి డేటాను తరలించే ప్రక్రియ.

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

దీని ప్రకారం, రెప్లికేషన్ లాగ్‌ని పర్యవేక్షించడానికి pg_stat_replication వీక్షణ ఉపయోగించబడుతుంది. కానీ ఆమెతో ప్రతిదీ సులభం కాదు. వెర్షన్ 10లో, వీక్షణ అనేక మార్పులకు గురైంది. మొదట, కొన్ని ఫీల్డ్‌లు పేరు మార్చబడ్డాయి. మరియు కొన్ని ఫీల్డ్‌లు జోడించబడ్డాయి. వెర్షన్ 10లో, సెకన్లలో రెప్లికేషన్ లాగ్‌ని అంచనా వేయడానికి మిమ్మల్ని అనుమతించే ఫీల్డ్‌లు కనిపించాయి. ఇది చాలా సౌకర్యంగా ఉంటుంది. వెర్షన్ 10కి ముందు, బైట్‌లలో రెప్లికేషన్ లాగ్‌ని అంచనా వేయడం సాధ్యమైంది. ఈ ఐచ్ఛికం వెర్షన్ 10లో మిగిలి ఉంది, అంటే మీరు మీ కోసం మరింత సౌకర్యవంతంగా ఉండేదాన్ని ఎంచుకోవచ్చు - బైట్‌లలో లాగ్‌ను అంచనా వేయండి లేదా సెకన్లలో లాగ్‌ను అంచనా వేయండి. చాలా మంది రెండూ చేస్తారు.

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

వెర్షన్ 10లో, ఈ ఫంక్షన్ pg_wal_lsn_diff()గా పేరు మార్చబడింది. సాధారణంగా, "xlog" అనే పదం కనుగొనబడిన అన్ని విధులు, వీక్షణలు మరియు యుటిలిటీలలో, అది "wal" విలువతో భర్తీ చేయబడింది. ఇది వీక్షణలు మరియు విధులు రెండింటికీ వర్తిస్తుంది. ఇది అలాంటి ఆవిష్కరణ.

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

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

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

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

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

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

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

మరియు కొన్ని ముఖ్య అంశాలు:

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

మీకు ఈ అంశంపై ఆసక్తి ఉంటే, మీరు ఈ లింక్‌లను అనుసరించవచ్చు.
http://bit.do/stats_collector - ఇది గణాంకాల కలెక్టర్ నుండి అధికారిక డాక్యుమెంటేషన్. అన్ని గణాంక వీక్షణల వివరణ మరియు అన్ని ఫీల్డ్‌ల వివరణ ఉంది. మీరు వాటిని చదవవచ్చు, అర్థం చేసుకోవచ్చు మరియు విశ్లేషించవచ్చు. మరియు వాటి ఆధారంగా, మీ గ్రాఫ్‌లను రూపొందించండి మరియు వాటిని మీ పర్యవేక్షణకు జోడించండి.

ఉదాహరణ అభ్యర్థనలు:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

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

మీ ప్రశ్నలు

ప్రశ్న: మీరు బ్రాండ్‌లను ప్రచారం చేయరని చెప్పారు, కానీ నాకు ఇంకా ఆసక్తి ఉంది - మీరు మీ ప్రాజెక్ట్‌లలో ఎలాంటి డ్యాష్‌బోర్డ్‌లను ఉపయోగిస్తున్నారు?
సమాధానం: ఇది మారుతూ ఉంటుంది. మేము కస్టమర్ వద్దకు వచ్చాము మరియు అతనికి ఇప్పటికే తన స్వంత పర్యవేక్షణ ఉంది. మరియు మేము కస్టమర్‌కు వారి పర్యవేక్షణకు ఏమి జోడించాలో సలహా ఇస్తున్నాము. చెత్త పరిస్థితి Zabbix తో ఉంది. ఎందుకంటే దీనికి TopN గ్రాఫ్‌లను నిర్మించే సామర్థ్యం లేదు. మనమే ఉపయోగిస్తాము ఆక్మీటర్, ఎందుకంటే మేము పర్యవేక్షణపై ఈ కుర్రాళ్లతో సంప్రదింపులు జరుపుతున్నాము. వారు మా సాంకేతిక వివరాల ఆధారంగా PostgreSQLని పర్యవేక్షించారు. నేను నా స్వంత పెంపుడు-ప్రాజెక్ట్‌ని వ్రాస్తున్నాను, ఇది ప్రోమేథియస్ ద్వారా డేటాను సేకరించి, దానిని రెండర్ చేస్తుంది గ్రాఫనా. ప్రోమేథియస్‌లో నా స్వంత ఎగుమతిదారుని సృష్టించి, ఆపై గ్రాఫానాలో ప్రతిదీ అందించడం నా పని.

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

PS1 మీరు postgres_exporterని ఉపయోగిస్తుంటే, మీరు ఏ డాష్‌బోర్డ్‌ని ఉపయోగిస్తున్నారు? వాటిలో అనేకం ఉన్నాయి. అవి ఇప్పటికే పాతబడిపోయాయి. బహుశా సంఘం నవీకరించబడిన టెంప్లేట్‌ను సృష్టిస్తుందా?

PS2 pganalyze తీసివేయబడింది ఎందుకంటే ఇది యాజమాన్య SaaS సమర్పణ, ఇది పనితీరు పర్యవేక్షణ మరియు ఆటోమేటెడ్ ట్యూనింగ్ సూచనలపై దృష్టి సారిస్తుంది.

నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. సైన్ ఇన్ చేయండిదయచేసి.

మీరు ఏ స్వీయ-హోస్ట్ చేసిన postgresql పర్యవేక్షణ (డ్యాష్‌బోర్డ్‌తో) ఉత్తమమైనదిగా భావిస్తారు?

• 30,0%Alexey Lesovsky లేదా zabbix 4.4 నుండి Zabbix + చేర్పులు లేదా libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze అనేది యాజమాన్య SaaS - నేను దానిని తొలగించలేను1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 మంది వినియోగదారులు ఓటు వేశారు. 26 మంది వినియోగదారులు దూరంగా ఉన్నారు.

మూలం: www.habr.com