Alexey Lesovsky యొక్క 2015 నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ "PostgreSQL అంతర్గత గణాంకాలలోకి లోతుగా డైవ్"
నివేదిక రచయిత నుండి నిరాకరణ: ఈ నివేదిక నవంబర్ 2015 నాటిదని నేను గమనించాను - 4 సంవత్సరాలకు పైగా గడిచిపోయింది మరియు చాలా సమయం గడిచిపోయింది. నివేదికలో చర్చించబడిన సంస్కరణ 9.4కు మద్దతు లేదు. గత 4 సంవత్సరాలలో, 5 కొత్త విడుదలలు విడుదల చేయబడ్డాయి, ఇందులో గణాంకాలకు సంబంధించి చాలా ఆవిష్కరణలు, మెరుగుదలలు మరియు మార్పులు ఉన్నాయి మరియు కొన్ని అంశాలు పాతవి మరియు సంబంధితమైనవి కావు. నేను సమీక్షిస్తున్నప్పుడు, పాఠకులను తప్పుదారి పట్టించకుండా ఈ స్థలాలను గుర్తించడానికి ప్రయత్నించాను. నేను ఈ భాగాలను తిరిగి వ్రాయలేదు, వాటిలో చాలా ఉన్నాయి మరియు ఫలితం పూర్తిగా భిన్నమైన నివేదికగా ఉంటుంది.
PostgreSQL DBMS అనేది ఒక భారీ మెకానిజం, మరియు ఈ మెకానిజం అనేక ఉపవ్యవస్థలను కలిగి ఉంటుంది, దీని యొక్క సమన్వయ ఆపరేషన్ నేరుగా DBMS పనితీరును ప్రభావితం చేస్తుంది. ఆపరేషన్ సమయంలో, భాగాల ఆపరేషన్ గురించి గణాంకాలు మరియు సమాచారం సేకరించబడతాయి, ఇది PostgreSQL యొక్క ప్రభావాన్ని అంచనా వేయడానికి మరియు పనితీరును మెరుగుపరచడానికి చర్యలు తీసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. అయితే, ఈ సమాచారం చాలా ఉంది మరియు ఇది చాలా సరళమైన రూపంలో ప్రదర్శించబడుతుంది. ఈ సమాచారాన్ని ప్రాసెస్ చేయడం మరియు దానిని వివరించడం కొన్నిసార్లు పూర్తిగా పనికిమాలిన పని, మరియు ఉపకరణాలు మరియు యుటిలిటీల "జూ" అధునాతన DBAని కూడా సులభంగా గందరగోళానికి గురి చేస్తుంది.
శుభ మద్యాహ్నం నా పేరు అలెక్సీ. ఇలియా చెప్పినట్లుగా, నేను PostgreSQL గణాంకాల గురించి మాట్లాడతాను.
PostgreSQL కార్యాచరణ గణాంకాలు. PostgreSQL రెండు గణాంకాలను కలిగి ఉంది. చర్చించబడే కార్యాచరణ గణాంకాలు. మరియు డేటా పంపిణీ గురించి షెడ్యూలర్ గణాంకాలు. నేను PostgreSQL కార్యాచరణ గణాంకాల గురించి ప్రత్యేకంగా మాట్లాడతాను, ఇది పనితీరును నిర్ధారించడానికి మరియు దానిని మెరుగుపరచడానికి మమ్మల్ని అనుమతిస్తుంది.
మీకు ఉన్న లేదా కలిగి ఉన్న అనేక రకాల సమస్యలను పరిష్కరించడానికి గణాంకాలను ఎలా సమర్థవంతంగా ఉపయోగించాలో నేను మీకు చెప్తాను.
నివేదికలో ఏమి ఉండదు? నివేదికలో నేను షెడ్యూలర్ గణాంకాలను తాకను, ఎందుకంటే... డేటాబేస్లో డేటా ఎలా నిల్వ చేయబడుతుంది మరియు ఈ డేటా యొక్క గుణాత్మక మరియు పరిమాణాత్మక లక్షణాల గురించి ప్రశ్న ప్లానర్‌కు ఎలా ఆలోచన వస్తుంది అనేదానిపై ప్రత్యేక నివేదిక కోసం ఇది ఒక ప్రత్యేక అంశం.
మరియు సాధన సమీక్షలు ఉండవు, నేను ఒక ఉత్పత్తిని మరొకదానితో పోల్చను. ప్రకటనలు ఉండవు. అన్నది పక్కన పెడదాం.
గణాంకాలను ఉపయోగించడం ఉపయోగకరంగా ఉంటుందని నేను మీకు చూపించాలనుకుంటున్నాను. ఇది అవసరం. ఇది ఉపయోగించడానికి సురక్షితం. మనకు కావలసిందల్లా సాధారణ SQL మరియు SQL యొక్క ప్రాథమిక జ్ఞానం.
మరియు సమస్యలను పరిష్కరించడానికి ఏ గణాంకాలను ఎంచుకోవాలి అనే దాని గురించి మాట్లాడుదాం.
మేము PostgreSQL ను చూసి, ప్రక్రియలను వీక్షించడానికి ఆపరేటింగ్ సిస్టమ్‌పై ఆదేశాన్ని అమలు చేస్తే, మనకు "బ్లాక్ బాక్స్" కనిపిస్తుంది. మనం ఏదో చేసే కొన్ని ప్రక్రియలను చూస్తాము మరియు పేరును బట్టి వారు అక్కడ ఏమి చేస్తున్నారో, వారు ఏమి చేస్తున్నారో మనం స్థూలంగా ఊహించవచ్చు. కానీ, సారాంశంలో, ఇది బ్లాక్ బాక్స్; మనం లోపలికి చూడలేము.
మనం CPU లోడ్‌ని చూడవచ్చు top, మేము కొన్ని సిస్టమ్ యుటిలిటీల ద్వారా మెమరీ వినియోగాన్ని చూడవచ్చు, కానీ మేము PostgreSQL లోపల చూడలేము. దీని కోసం మాకు ఇతర సాధనాలు అవసరం.
ఇంకా కొనసాగిస్తూ, సమయం ఎక్కడ గడిపారో నేను మీకు చెప్తాను. అటువంటి రేఖాచిత్రం రూపంలో మనం PostgreSQLని ఊహించినట్లయితే, సమయం ఎక్కడ వెచ్చించబడుతుందో మనం సమాధానం ఇవ్వగలము. ఇవి రెండు విషయాలు: ఇది అప్లికేషన్‌ల నుండి క్లయింట్ అభ్యర్థనలను ప్రాసెస్ చేస్తోంది మరియు PostgreSQL దానంతట అదే రన్ అయ్యేలా చేసే బ్యాక్‌గ్రౌండ్ టాస్క్‌లు.
మేము ఎగువ ఎడమ మూలలో చూడటం ప్రారంభిస్తే, క్లయింట్ అభ్యర్థనలు ఎలా ప్రాసెస్ చేయబడతాయో మనం చూడవచ్చు. అభ్యర్థన అప్లికేషన్ నుండి వచ్చింది మరియు తదుపరి పని కోసం క్లయింట్ సెషన్ తెరవబడుతుంది. అభ్యర్థన షెడ్యూలర్‌కు పంపబడుతుంది. షెడ్యూలర్ ప్రశ్న ప్రణాళికను రూపొందిస్తుంది. అమలు కోసం దాన్ని మరింత పంపుతుంది. పట్టికలు మరియు సూచికలతో అనుబంధించబడిన కొన్ని రకాల బ్లాక్ డేటా ఇన్‌పుట్/అవుట్‌పుట్ ఉంది. అవసరమైన డేటా డిస్క్‌ల నుండి మెమరీలోకి ప్రత్యేక ప్రాంతం "షేర్డ్ బఫర్‌లు" లోకి చదవబడుతుంది. అభ్యర్థన ఫలితాలు, అవి అప్‌డేట్‌లు అయితే, తొలగిస్తే, WALలోని లావాదేవీ లాగ్‌లో రికార్డ్ చేయబడతాయి. కొన్ని గణాంక సమాచారం లాగ్ లేదా స్టాటిస్టిక్స్ కలెక్టర్‌లో ముగుస్తుంది. మరియు అభ్యర్థన యొక్క ఫలితం క్లయింట్‌కు తిరిగి పంపబడుతుంది. దీని తర్వాత క్లయింట్ కొత్త అభ్యర్థనతో మళ్లీ ప్రతిదీ పునరావృతం చేయవచ్చు.
నేపథ్య పనులు మరియు నేపథ్య ప్రక్రియల గురించి ఏమిటి? డేటాబేస్‌ని సాధారణ ఆపరేటింగ్ మోడ్‌లో ఉంచే అనేక ప్రక్రియలు మా వద్ద ఉన్నాయి. ఈ ప్రక్రియలు నివేదికలో కూడా టచ్ చేయబడతాయి: ఆటోవాక్యూమ్, చెక్‌పాయింటర్, రెప్లికేషన్-సంబంధిత ప్రక్రియలు, నేపథ్య రచయిత. నేను నివేదించేటప్పుడు వాటిలో ప్రతిదానిని తాకుతాను.
గణాంకాలతో ఏ సమస్యలు ఉన్నాయి?
- చాలా సమాచారం ఉంది. PostgreSQL 9.4 గణాంకాల డేటాను వీక్షించడానికి 109 కొలమానాలను అందిస్తుంది. అయినప్పటికీ, డేటాబేస్ అనేక పట్టికలు, స్కీమాలు, డేటాబేస్‌లను నిల్వ చేస్తే, ఈ కొలమానాలన్నింటినీ సంబంధిత పట్టికలు, డేటాబేస్‌ల సంఖ్యతో గుణించాలి. అంటే, ఇంకా ఎక్కువ సమాచారం ఉంది. మరియు దానిలో మునిగిపోవడం చాలా సులభం.
- తదుపరి సమస్య ఏమిటంటే గణాంకాలు కౌంటర్ల ద్వారా సూచించబడతాయి. ఈ గణాంకాలను పరిశీలిస్తే, నిరంతరం పెరుగుతున్న కౌంటర్లు మనకు కనిపిస్తాయి. మరియు గణాంకాలను రీసెట్ చేసినప్పటి నుండి చాలా సమయం గడిచినట్లయితే, మేము బిలియన్లలో విలువలను చూస్తాము. మరియు వారు మాకు ఏమీ చెప్పరు.
- కథ లేదు. మీరు ఒక రకమైన వైఫల్యాన్ని కలిగి ఉంటే, 15-30 నిమిషాల క్రితం ఏదో పడిపోయినట్లయితే, మీరు గణాంకాలను ఉపయోగించలేరు మరియు 15-30 నిమిషాల క్రితం ఏమి జరిగిందో చూడలేరు. ఇది సమస్య.
- PostgreSQLలో అంతర్నిర్మిత సాధనం లేకపోవడం ఒక సమస్య. కెర్నల్ డెవలపర్లు ఎటువంటి యుటిలిటీని అందించరు. వారికి అలాంటిదేమీ లేదు. వారు డేటాబేస్లో గణాంకాలను అందిస్తారు. దీన్ని ఉపయోగించండి, దానికి అభ్యర్థన చేయండి, మీకు కావలసినది చేయండి.
- PostgreSQLలో అంతర్నిర్మిత సాధనం లేనందున, ఇది మరొక సమస్యను కలిగిస్తుంది. అనేక మూడవ పక్ష సాధనాలు. ఎక్కువ లేదా తక్కువ ప్రత్యక్ష చేతులు కలిగి ఉన్న ప్రతి సంస్థ దాని స్వంత ప్రోగ్రామ్‌ను వ్రాయడానికి ప్రయత్నిస్తుంది. మరియు ఫలితంగా, సంఘం గణాంకాలతో పని చేయడానికి ఉపయోగించే అనేక సాధనాలను కలిగి ఉంది. మరియు కొన్ని సాధనాలు నిర్దిష్ట సామర్థ్యాలను కలిగి ఉంటాయి, ఇతర సాధనాలకు ఇతర సామర్థ్యాలు లేవు లేదా కొన్ని కొత్త సామర్థ్యాలు ఉన్నాయి. మరియు మీరు ఒకదానికొకటి అతివ్యాప్తి చెందుతున్న మరియు విభిన్న విధులను కలిగి ఉన్న రెండు, మూడు లేదా నాలుగు సాధనాలను ఉపయోగించాల్సిన పరిస్థితి తలెత్తుతుంది. ఇది చాలా అసహ్యకరమైనది.
దీని నుండి ఏమి అనుసరిస్తుంది? ప్రోగ్రామ్‌లపై ఆధారపడకుండా నేరుగా గణాంకాలను తీసుకోవడం చాలా ముఖ్యం, లేదా ఈ ప్రోగ్రామ్‌లను మీరే మెరుగుపరచుకోండి: మీ స్వంత ప్రయోజనం పొందడానికి కొన్ని విధులను జోడించండి.
మరియు మీకు SQL యొక్క ప్రాథమిక జ్ఞానం అవసరం. గణాంకాల నుండి కొంత డేటాను పొందడానికి, మీరు SQL ప్రశ్నలను సృష్టించాలి, అంటే ఎంపిక మరియు చేరడం ఎలా కంపైల్ చేయబడిందో మీరు తెలుసుకోవాలి.
గణాంకాలు మనకు అనేక విషయాలను తెలియజేస్తాయి. వాటిని వర్గాలుగా విభజించవచ్చు.
- మొదటి వర్గం డేటాబేస్లో సంభవించే సంఘటనలు. డేటాబేస్లో కొన్ని ఈవెంట్‌లు సంభవించినప్పుడు ఇది జరుగుతుంది: అభ్యర్థన, టేబుల్‌కి యాక్సెస్, ఆటోవాక్యూమ్, కమిట్‌లు, అప్పుడు ఇవన్నీ ఈవెంట్‌లు. ఈ ఈవెంట్‌లకు సంబంధించిన కౌంటర్లు పెంచబడ్డాయి. మరియు మేము ఈ ఈవెంట్‌లను ట్రాక్ చేయవచ్చు.
- రెండవ వర్గం పట్టికలు మరియు డేటాబేస్ వంటి వస్తువుల లక్షణాలు. వారికి ఆస్తులు ఉన్నాయి. ఇది పట్టికల పరిమాణం. మేము పట్టికల పెరుగుదల మరియు సూచికల పెరుగుదలను ట్రాక్ చేయవచ్చు. డైనమిక్స్‌లో మార్పులను మనం చూడవచ్చు.
- మరియు మూడవ వర్గం ఈవెంట్ కోసం గడిపిన సమయం. అభ్యర్థన అనేది ఒక సంఘటన. ఇది దాని స్వంత నిర్దిష్ట వ్యవధిని కలిగి ఉంటుంది. ఇక్కడ ప్రారంభించారు, ఇక్కడ ముగిసింది. మేము దానిని ట్రాక్ చేయవచ్చు. డిస్క్ నుండి బ్లాక్‌ని చదవడానికి లేదా వ్రాయడానికి పట్టే సమయం. వంటి వాటిని కూడా ట్రాక్ చేస్తారు.
గణాంకాల మూలాలు క్రింది విధంగా ప్రదర్శించబడ్డాయి:
- భాగస్వామ్య మెమరీలో (షేర్డ్ బఫర్‌లు) స్టాటిక్ డేటాను నిల్వ చేయడానికి ఒక విభాగం ఉంది, కొన్ని సంఘటనలు సంభవించినప్పుడు లేదా డేటాబేస్ యొక్క ఆపరేషన్‌లో కొన్ని క్షణాలు తలెత్తినప్పుడు నిరంతరం పెంచబడే కౌంటర్లు కూడా ఉన్నాయి.
- ఈ కౌంటర్‌లన్నీ వినియోగదారుకు అందుబాటులో ఉండవు మరియు నిర్వాహకులకు కూడా అందుబాటులో ఉండవు. ఇవి తక్కువ స్థాయి విషయాలు. వాటిని యాక్సెస్ చేయడానికి, PostgreSQL SQL ఫంక్షన్ల రూపంలో ఇంటర్‌ఫేస్‌ను అందిస్తుంది. మేము ఈ ఫంక్షన్లను ఉపయోగించి ఎంపిక త్రోలను చేయవచ్చు మరియు కొన్ని రకాల మెట్రిక్ (లేదా కొలమానాల సమితి) పొందవచ్చు.
- అయితే, ఈ ఫంక్షన్లను ఉపయోగించడం ఎల్లప్పుడూ అనుకూలమైనది కాదు, కాబట్టి వీక్షణలకు (వీక్షణలు) విధులు ఆధారం. ఇవి నిర్దిష్ట సబ్‌సిస్టమ్‌పై లేదా డేటాబేస్‌లోని నిర్దిష్ట ఈవెంట్‌లపై గణాంకాలను అందించే వర్చువల్ పట్టికలు.
- ఈ ఎంబెడెడ్ వీక్షణలు (VIEWs) గణాంకాలతో పని చేయడానికి ప్రాథమిక వినియోగదారు ఇంటర్‌ఫేస్. అవి ఎటువంటి అదనపు సెట్టింగ్‌లు లేకుండా డిఫాల్ట్‌గా అందుబాటులో ఉంటాయి, మీరు వాటిని వెంటనే ఉపయోగించవచ్చు, వాటిని చూడవచ్చు మరియు వాటి నుండి సమాచారాన్ని తీసుకోవచ్చు. ఆపై రచనలు ఉన్నాయి. రచనలు అధికారికమైనవి. మీరు postgresql-contrib ప్యాకేజీని ఇన్‌స్టాల్ చేయవచ్చు (ఉదాహరణకు, postgresql94-contrib), కాన్ఫిగరేషన్‌లో అవసరమైన మాడ్యూల్‌ను లోడ్ చేయండి, దాని కోసం పారామితులను పేర్కొనండి, PostgreSQL పునఃప్రారంభించండి మరియు మీరు దానిని ఉపయోగించవచ్చు. (గమనిక. పంపిణీపై ఆధారపడి, ఇటీవలి సంస్కరణల్లో కాంట్రిబ్ ప్యాకేజీ ప్రధాన ప్యాకేజీలో భాగం).
- మరియు అనధికారిక సహకారం ఉన్నాయి. అవి ప్రామాణిక PostgreSQL పంపిణీలో చేర్చబడలేదు. అవి తప్పనిసరిగా కంపైల్ చేయబడాలి లేదా లైబ్రరీగా ఇన్‌స్టాల్ చేయబడాలి. ఈ అనధికారిక సహకారం యొక్క డెవలపర్ అందించిన దాని ఆధారంగా ఎంపికలు చాలా భిన్నంగా ఉంటాయి.
ఈ స్లయిడ్ ఆ అన్ని వీక్షణలు మరియు PostgreSQL 9.4లో అందుబాటులో ఉన్న కొన్ని ఫంక్షన్లను అందిస్తుంది. మనం చూస్తున్నట్లుగా, వాటిలో చాలా ఉన్నాయి. మరియు మీరు మొదటిసారి ఎదుర్కొన్నట్లయితే గందరగోళం చెందడం చాలా సులభం.
అయితే, మేము మునుపటి చిత్రాన్ని తీసుకుంటే Как тратится время на PostgreSQL మరియు ఈ జాబితాకు అనుకూలంగా, మేము ఈ చిత్రాన్ని పొందుతాము. PostgreSQL రన్ అవుతున్నప్పుడు సంబంధిత గణాంకాలను పొందేందుకు మేము ప్రతి వీక్షణను (వీక్షణలు) లేదా ప్రతి ఫంక్షన్‌ని ఒక ప్రయోజనం లేదా మరొక ప్రయోజనం కోసం ఉపయోగించవచ్చు. మరియు మేము ఇప్పటికే ఉపవ్యవస్థ యొక్క ఆపరేషన్ గురించి కొంత సమాచారాన్ని పొందవచ్చు.
మనం చూడబోయే మొదటి విషయం pg_stat_database. మనం చూడగలిగినట్లుగా, ఇది ఒక ప్రదర్శన. అందులో చాలా సమాచారం ఉంది. అత్యంత వైవిధ్యమైన సమాచారం. మరియు ఇది మా డేటాబేస్లో ఏమి జరుగుతుందో చాలా ఉపయోగకరమైన జ్ఞానాన్ని ఇస్తుంది.
అక్కడ నుండి మనం ఎలాంటి ఉపయోగకరమైన వస్తువులను తీసుకోవచ్చు? సరళమైన విషయాలతో ప్రారంభిద్దాం.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;మనం చూడగలిగే మొదటి విషయం కాష్ హిట్ శాతం. కాష్ హిట్ రేటు ఉపయోగకరమైన మెట్రిక్. భాగస్వామ్య బఫర్‌ల కాష్ నుండి ఎంత డేటా తీసుకోబడింది మరియు డిస్క్ నుండి ఎంత చదవబడుతుందో అంచనా వేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.
అన్నది స్పష్టం మన వద్ద ఎంత ఎక్కువ కాష్ హిట్‌లు ఉంటే అంత మంచిది. మేము ఈ మెట్రిక్‌ను శాతంగా కొలుస్తాము. మరియు, ఉదాహరణకు, ఈ కాష్ హిట్‌లలో మన శాతం 90% కంటే ఎక్కువగా ఉంటే, ఇది మంచిది. అది 90% కంటే తక్కువగా పడిపోతే, మెమరీలో డేటా యొక్క హాట్ హెడ్‌ని ఉంచడానికి మనకు తగినంత మెమరీ లేదని అర్థం. మరియు ఈ డేటాను ఉపయోగించడానికి, PostgreSQL డిస్క్‌ని యాక్సెస్ చేయవలసి వస్తుంది మరియు ఇది మెమరీ నుండి డేటా చదివిన దానికంటే నెమ్మదిగా ఉంటుంది. మరియు మీరు మెమరీని పెంచడం గురించి ఆలోచించాలి: షేర్డ్ బఫర్‌లను పెంచండి లేదా హార్డ్‌వేర్ మెమరీని పెంచండి (RAM).
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;ఈ ప్రదర్శన నుండి మీరు ఇంకా ఏమి తీసుకోగలరు? మీరు డేటాబేస్లో సంభవించే క్రమరాహిత్యాలను చూడవచ్చు. ఇక్కడ ఏమి చూపబడింది? కమిట్‌లు, రోల్‌బ్యాక్‌లు, తాత్కాలిక ఫైల్‌ల సృష్టి, వాటి పరిమాణం, డెడ్‌లాక్‌లు మరియు వైరుధ్యాలు ఉన్నాయి.
మేము ఈ అభ్యర్థనను ఉపయోగించవచ్చు. ఈ SQL చాలా సులభం. మరియు మేము ఇక్కడ ఈ డేటాను చూడవచ్చు.
మరియు ఇక్కడ థ్రెషోల్డ్ విలువలు ఉన్నాయి. మేము కమిట్‌లు మరియు రోల్‌బ్యాక్‌ల నిష్పత్తిని పరిశీలిస్తాము. కమిట్‌లు అనేది లావాదేవీ యొక్క విజయవంతమైన నిర్ధారణ. రోల్‌బ్యాక్‌లు అనేది రోల్‌బ్యాక్, అంటే లావాదేవీ కొంత పని చేసి, డేటాబేస్ను వడకట్టడం, ఏదైనా లెక్కించడం, ఆపై వైఫల్యం సంభవించింది మరియు లావాదేవీ ఫలితాలు విస్మరించబడతాయి. అంటే నిరంతరం పెరుగుతున్న రోల్‌బ్యాక్‌ల సంఖ్య చెడ్డది. మరియు మీరు వాటిని ఎలాగైనా నివారించాలి మరియు ఇది జరగకుండా కోడ్‌ను సవరించండి.
వైరుధ్యాలు ప్రతిరూపానికి సంబంధించినవి. మరియు వాటిని కూడా నివారించాలి. మీకు ప్రతిరూపంపై అమలు చేయబడిన కొన్ని ప్రశ్నలు మరియు వైరుధ్యాలు తలెత్తితే, మీరు ఈ వైరుధ్యాలను క్రమబద్ధీకరించాలి మరియు ఏమి జరుగుతుందో చూడాలి. వివరాలను లాగ్‌లలో చూడవచ్చు. మరియు వైరుధ్య పరిస్థితులను తొలగించండి, తద్వారా అప్లికేషన్ అభ్యర్థనలు లోపాలు లేకుండా పని చేస్తాయి.
డెడ్‌లాక్‌లు కూడా చెడ్డ పరిస్థితి. రిక్వెస్ట్‌లు రిసోర్స్‌ల కోసం పోరాడుతున్నప్పుడు, ఒక రిక్వెస్ట్ ఒక రిసోర్స్‌ని యాక్సెస్ చేసి లాక్‌ని తీసుకుంది, రెండవ రిక్వెస్ట్ రెండవ రిసోర్స్‌ని యాక్సెస్ చేసి లాక్‌ని కూడా తీసుకుంది, ఆపై రెండు రిక్వెస్ట్‌లు ఒకదానికొకటి రిసోర్స్‌లను యాక్సెస్ చేసి, లాక్‌ని విడుదల చేయడానికి పొరుగువారి కోసం వేచి ఉన్నప్పుడు బ్లాక్ చేయబడ్డాయి. ఇది కూడా సమస్యాత్మకమైన పరిస్థితి. అనువర్తనాలను తిరిగి వ్రాయడం మరియు వనరులకు ప్రాప్యతను సీరియలైజ్ చేయడం వంటి స్థాయిలో వాటిని పరిష్కరించాలి. మరియు మీ డెడ్‌లాక్‌లు నిరంతరం పెరుగుతున్నాయని మీరు చూస్తే, మీరు లాగ్‌లలోని వివరాలను చూడాలి, ఉత్పన్నమయ్యే పరిస్థితులను విశ్లేషించాలి మరియు సమస్య ఏమిటో చూడాలి.
తాత్కాలిక ఫైల్‌లు (temp_files) కూడా చెడ్డవి. వినియోగదారు అభ్యర్థనలో కార్యాచరణ, తాత్కాలిక డేటాను ఉంచడానికి తగినంత మెమరీ లేనప్పుడు, అది డిస్క్‌లో ఫైల్‌ను సృష్టిస్తుంది. మరియు మెమరీలో తాత్కాలిక బఫర్‌లో నిర్వహించగల అన్ని కార్యకలాపాలు డిస్క్‌లో నిర్వహించడం ప్రారంభిస్తాయి. ఇది నెమ్మదిగా ఉంది. ఇది ప్రశ్న అమలు సమయాన్ని పెంచుతుంది. మరియు PostgreSQLకి అభ్యర్థన పంపిన క్లయింట్ కొద్దిసేపటి తర్వాత ప్రతిస్పందనను అందుకుంటారు. ఈ కార్యకలాపాలన్నీ మెమరీలో నిర్వహించబడితే, పోస్ట్‌గ్రెస్ చాలా వేగంగా స్పందిస్తుంది మరియు క్లయింట్ తక్కువ వేచి ఉంటుంది.
Pg_stat_bgwriter - ఈ వీక్షణ రెండు PostgreSQL బ్యాక్‌గ్రౌండ్ సబ్‌సిస్టమ్‌ల ఆపరేషన్‌ను వివరిస్తుంది: ఇది checkpointer и background writer.
మొదట, నియంత్రణ పాయింట్లు, అని పిలవబడే వాటిని చూద్దాం. checkpoints. నియంత్రణ పాయింట్లు ఏమిటి? చెక్‌పాయింట్ అనేది లావాదేవీ లాగ్‌లోని స్థానం, ఇది లాగ్‌లో నమోదు చేయబడిన అన్ని డేటా మార్పులు డిస్క్‌లోని డేటాతో విజయవంతంగా సమకాలీకరించబడిందని సూచిస్తుంది. పనిభారం మరియు సెట్టింగ్‌ల ఆధారంగా ప్రక్రియ సుదీర్ఘంగా ఉంటుంది మరియు డిస్క్‌లోని డేటా ఫైల్‌లతో షేర్డ్ బఫర్‌లలో డర్టీ పేజీలను సమకాలీకరించడాన్ని ఎక్కువగా కలిగి ఉంటుంది. అది దేనికోసం? PostgreSQL నిరంతరం డిస్క్‌ను యాక్సెస్ చేస్తూ మరియు అక్కడి నుండి డేటాను పొందుతూ ఉంటే మరియు ప్రతి యాక్సెస్‌పై డేటాను వ్రాసి ఉంటే, అది నెమ్మదిగా ఉంటుంది. కాబట్టి, PostgreSQL మెమొరీ సెగ్మెంట్‌ను కలిగి ఉంది, దీని పరిమాణం ఆకృతీకరణలోని సెట్టింగ్‌లపై ఆధారపడి ఉంటుంది. పోస్ట్‌గ్రెస్ ఈ మెమరీలో లైవ్ డేటాను తర్వాత ప్రాసెస్ చేయడం లేదా ప్రశ్నించడం కోసం నిల్వ చేస్తుంది. డేటాను మార్చడానికి అభ్యర్థనల విషయంలో, అది మార్చబడుతుంది. మరియు మేము డేటా యొక్క రెండు వెర్షన్లను పొందుతాము. ఒకటి మన మెమరీలో ఉంది, మరొకటి డిస్క్‌లో ఉంది. మరియు క్రమానుగతంగా మీరు ఈ డేటాను సమకాలీకరించాలి. మెమరీలో మార్చబడిన వాటిని డిస్క్‌కి సమకాలీకరించాలి. దీని కోసం మీకు చెక్‌పోస్టులు అవసరం.
చెక్‌పాయింట్ షేర్డ్ బఫర్‌ల ద్వారా వెళుతుంది, చెక్‌పాయింట్ కోసం అవసరమైన డర్టీ పేజీలను గుర్తు చేస్తుంది. అప్పుడు అది షేర్డ్ బఫర్‌ల ద్వారా రెండవ పాస్‌ను ప్రారంభిస్తుంది. మరియు చెక్‌పాయింట్ కోసం గుర్తించబడిన పేజీలు, ఇది ఇప్పటికే వాటిని సమకాలీకరిస్తుంది. ఈ విధంగా డేటా డిస్క్‌తో సమకాలీకరించబడుతుంది.
రెండు రకాల చెక్‌పోస్టులు ఉన్నాయి. ఒక చెక్‌పాయింట్ గడువు ముగియడంతో అమలు చేయబడుతుంది. ఈ తనిఖీ కేంద్రం ఉపయోగకరమైనది మరియు మంచిది - checkpoint_timed. మరియు డిమాండ్‌పై చెక్‌పోస్టులు ఉన్నాయి - checkpoint required. మన దగ్గర చాలా పెద్ద డేటా రికార్డ్ ఉన్నప్పుడు ఈ చెక్‌పాయింట్ జరుగుతుంది. మేము చాలా లావాదేవీల లాగ్‌లను రికార్డ్ చేసాము. మరియు PostgreSQL వీటన్నింటిని వీలైనంత త్వరగా సమకాలీకరించాలని, చెక్‌పాయింట్‌ని తయారు చేసి ముందుకు సాగాలని విశ్వసిస్తుంది.
మరియు మీరు గణాంకాలను పరిశీలిస్తే pg_stat_bgwriter మరియు మీరు ఏమి చూసారు checkpoint_req checkpoint_timed కంటే చాలా పెద్దది, అప్పుడు ఇది చెడ్డది. ఎందుకు చెడ్డది? డిస్క్‌కి డేటాను వ్రాయవలసి వచ్చినప్పుడు PostgreSQL స్థిరమైన ఒత్తిడిలో ఉంటుందని దీని అర్థం. సమయం ముగిసిన చెక్‌పాయింట్ తక్కువ ఒత్తిడితో కూడుకున్నది మరియు అంతర్గత షెడ్యూల్ ప్రకారం నిర్వహించబడుతుంది మరియు కాలక్రమేణా విస్తరించి ఉంటుంది. PostgreSQL పనిని పాజ్ చేయగల సామర్థ్యాన్ని కలిగి ఉంది మరియు డిస్క్ సబ్‌సిస్టమ్‌ను వక్రీకరించదు. ఇది PostgreSQLకి ఉపయోగపడుతుంది. మరియు చెక్‌పాయింట్ సమయంలో అమలు చేయబడిన ప్రశ్నలు డిస్క్ సబ్‌సిస్టమ్ బిజీగా ఉన్నందున ఒత్తిడిని అనుభవించవు.
మరియు తనిఖీ కేంద్రాన్ని సర్దుబాటు చేయడానికి మూడు పారామితులు ఉన్నాయి:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
నియంత్రణ పాయింట్ల ఆపరేషన్‌ను నియంత్రించడానికి అవి మిమ్మల్ని అనుమతిస్తాయి. కానీ నేను వాటిపై నివసించను. వారి ప్రభావం ఒక ప్రత్యేక అంశం.
హెచ్చరిక: నివేదికలో చర్చించబడిన సంస్కరణ 9.4 ఇకపై సంబంధితంగా లేదు. PostgreSQL యొక్క ఆధునిక సంస్కరణల్లో పరామితి checkpoint_segments పారామితుల ద్వారా భర్తీ చేయబడింది min_wal_size и max_wal_size.
తదుపరి ఉపవ్యవస్థ నేపథ్య రచయిత - background writer. అతను ఏమి చేస్తున్నాడు? ఇది అంతులేని లూప్‌లో నిరంతరం నడుస్తుంది. భాగస్వామ్య బఫర్‌లలోని పేజీలను స్కాన్ చేస్తుంది మరియు డిస్క్‌లో కనుగొనబడిన మురికి పేజీలను డంప్ చేస్తుంది. అందువల్ల, చెక్‌పాయింట్ అమలు సమయంలో చెక్‌పాయింటర్ తక్కువ పని చేయడానికి ఇది సహాయపడుతుంది.
ఇంకా దేనికి కావాలి? డేటాను ఉంచడానికి అకస్మాత్తుగా (పెద్ద పరిమాణంలో మరియు వెంటనే) అవసరమైతే షేర్డ్ బఫర్‌లలో ఖాళీ పేజీల అవసరాన్ని ఇది అందిస్తుంది. అభ్యర్థనను పూర్తి చేయడానికి ఖాళీ పేజీలు అవసరమైనప్పుడు మరియు అవి ఇప్పటికే భాగస్వామ్య బఫర్‌లలో ఉన్నప్పుడు పరిస్థితి ఏర్పడిందని అనుకుందాం. పోస్ట్గ్రేసివ్ backend అతను వాటిని ఎంచుకొని వాటిని ఉపయోగిస్తాడు, అతను ఏదైనా శుభ్రం చేయవలసిన అవసరం లేదు. కానీ అకస్మాత్తుగా అటువంటి పేజీలు లేకుంటే, బ్యాకెండ్ పనిని పాజ్ చేస్తుంది మరియు వాటిని డిస్క్‌లోకి డంప్ చేయడానికి మరియు దాని స్వంత అవసరాల కోసం వాటిని తీసుకోవడానికి పేజీల కోసం శోధించడం ప్రారంభిస్తుంది - ఇది ప్రస్తుతం అమలు చేస్తున్న అభ్యర్థన సమయాన్ని ప్రతికూలంగా ప్రభావితం చేస్తుంది. మీకు పరామితి ఉందని మీరు చూస్తే maxwritten_clean పెద్దది, దీని అర్థం నేపథ్య రచయిత తన పనిని చేయడం లేదని మరియు మీరు పారామితులను పెంచాలి bgwriter_lru_maxpages, తద్వారా అతను ఒక సైకిల్‌లో ఎక్కువ పని చేయగలడు, మరిన్ని పేజీలను క్లియర్ చేయవచ్చు.
మరియు మరొక చాలా ఉపయోగకరమైన సూచిక buffers_backend_fsync. ఇది నెమ్మదిగా ఉన్నందున బ్యాక్‌ఎండ్‌లు సమకాలీకరించబడవు. వారు IO స్టాక్ చెక్‌పాయింటర్‌ను fsyncని పాస్ చేస్తారు. చెక్‌పాయింటర్‌కు దాని స్వంత క్యూ ఉంది, ఇది క్రమానుగతంగా fsyncని ప్రాసెస్ చేస్తుంది మరియు డిస్క్‌లోని ఫైల్‌లతో మెమరీలో పేజీలను సమకాలీకరిస్తుంది. చెక్‌పాయింటర్ వద్ద క్యూ పెద్దగా మరియు నిండుగా ఉంటే, బ్యాకెండ్ స్వయంగా fsync చేయవలసి వస్తుంది మరియు ఇది బ్యాకెండ్ పనిని నెమ్మదిస్తుంది, అంటే క్లయింట్ దాని కంటే ఆలస్యంగా ప్రతిస్పందనను అందుకుంటారు. మీ విలువ సున్నా కంటే ఎక్కువగా ఉందని మీరు చూస్తే, ఇది ఇప్పటికే సమస్య మరియు మీరు బ్యాక్‌గ్రౌండ్ రైటర్ సెట్టింగ్‌లకు శ్రద్ధ వహించాలి మరియు డిస్క్ సబ్‌సిస్టమ్ పనితీరును కూడా అంచనా వేయాలి.
హెచ్చరిక: _క్రింది వచనం ప్రతిరూపణతో అనుబంధించబడిన గణాంక వీక్షణలను వివరిస్తుంది. చాలా వీక్షణ మరియు ఫంక్షన్ పేర్లు పోస్ట్‌గ్రెస్ 10లో పేరు మార్చబడ్డాయి. పేరు మార్చడం యొక్క సారాంశం భర్తీ చేయడం xlog న wal и location న lsn ఫంక్షన్/వ్యూ పేర్లు మొదలైన వాటిలో. ప్రత్యేక ఉదాహరణ, ఫంక్షన్ pg_xlog_location_diff() గా పేరు మార్చబడింది pg_wal_lsn_diff()._
ఇక్కడ కూడా మనకు చాలా విషయాలు ఉన్నాయి. కానీ మనకు స్థానానికి సంబంధించిన అంశాలు మాత్రమే అవసరం.
అన్ని విలువలు సమానంగా ఉన్నాయని మేము చూస్తే, ఇది ఆదర్శవంతమైన ఎంపిక మరియు ప్రతిరూపం మాస్టర్ కంటే వెనుకబడి ఉండదు.
ఇక్కడ ఈ హెక్సాడెసిమల్ స్థానం లావాదేవీ లాగ్‌లోని స్థానం. డేటాబేస్లో ఏదైనా కార్యాచరణ ఉంటే అది నిరంతరం పెరుగుతుంది: ఇన్సర్ట్, డిలీట్, మొదలైనవి.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());ఈ విషయాలు భిన్నంగా ఉంటే, అప్పుడు కొంత లాగ్ ఉంది. లాగ్ అనేది ప్రతిరూపం మరియు మాస్టర్ మధ్య లాగ్, అనగా సర్వర్‌ల మధ్య డేటా భిన్నంగా ఉంటుంది.
ఆలస్యం కోసం మూడు కారణాలు ఉన్నాయి:
- ఈ డిస్క్ సబ్‌సిస్టమ్ రికార్డింగ్ ఫైల్ సింక్రొనైజేషన్‌ను ఎదుర్కోదు.
- ఇవి సాధ్యమయ్యే నెట్‌వర్క్ లోపాలు లేదా నెట్‌వర్క్ ఓవర్‌లోడ్, డేటా ప్రతిరూపాన్ని చేరుకోవడానికి సమయం లేనప్పుడు మరియు దానిని పునరుత్పత్తి చేయలేనప్పుడు.
- మరియు ప్రాసెసర్. ప్రాసెసర్ చాలా అరుదైన కేసు. మరియు నేను దీనిని రెండు లేదా మూడు సార్లు చూశాను, కానీ ఇది కూడా జరగవచ్చు.
మరియు గణాంకాలను ఉపయోగించడానికి మాకు అనుమతించే మూడు ప్రశ్నలు ఇక్కడ ఉన్నాయి. లావాదేవీ లాగ్‌లో మనం ఎంత నమోదు చేశామో అంచనా వేయవచ్చు. అటువంటి ఫంక్షన్ ఉంది pg_xlog_location_diff మరియు మేము బైట్లు మరియు సెకన్లలో రెప్లికేషన్ లాగ్‌ను అంచనా వేయవచ్చు. మేము దీని కోసం ఈ వీక్షణ (VIEWs) నుండి విలువను కూడా ఉపయోగిస్తాము.
గమనిక: _pg_xlog_locationకి బదులుగాడిఫ్() ఫంక్షన్ వ్యవకలన ఆపరేటర్‌ను ఉపయోగించవచ్చు మరియు ఒక స్థానాన్ని మరొక దాని నుండి తీసివేయవచ్చు. సౌకర్యవంతమైన.
లాగ్‌తో ఒక పాయింట్ ఉంది, ఇది సెకన్లలో ఉంటుంది. మాస్టర్‌లో ఎటువంటి కార్యాచరణ లేకుంటే, లావాదేవీ దాదాపు 15 నిమిషాల క్రితం జరిగింది మరియు ఎటువంటి కార్యాచరణ లేదు, మరియు ప్రతిరూపంలో ఈ లాగ్‌ని చూస్తే, మనకు 15 నిమిషాల లాగ్ కనిపిస్తుంది. ఇది గుర్తుంచుకోవడం విలువ. మరియు మీరు ఈ లాగ్‌ను చూసినప్పుడు ఇది గందరగోళంగా ఉంటుంది.
Pg_stat_all_tables మరొక ఉపయోగకరమైన వీక్షణ. ఇది పట్టికలలో గణాంకాలను చూపుతుంది. మేము డేటాబేస్లో పట్టికలను కలిగి ఉన్నప్పుడు, దానితో కొంత కార్యాచరణ ఉంది, కొన్ని చర్యలు, మేము ఈ వీక్షణ నుండి ఈ సమాచారాన్ని పొందవచ్చు.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;మేము చూడగలిగే మొదటి విషయం టేబుల్ అంతటా సీక్వెన్షియల్ స్కాన్‌లు. ఈ పాస్‌ల తర్వాత సంఖ్య తప్పనిసరిగా చెడ్డది కాదు మరియు మనం ఏదైనా చేయాల్సిన అవసరం ఉన్న సూచిక కాదు.
అయితే, రెండవ మెట్రిక్ ఉంది - seq_tup_read. ఇది సీక్వెన్షియల్ స్కాన్ నుండి తిరిగి వచ్చిన అడ్డు వరుసల సంఖ్య. సగటు సంఖ్య 1, 000, 10, 000 మించి ఉంటే, ఇది ఇప్పటికే సూచికగా ఉంది, బహుశా మీరు ఇండెక్స్‌పై ఆధారపడి ప్రశ్నలు ఉండేలా మీరు ఇండెక్స్‌ని ఎక్కడైనా నిర్మించాల్సిన అవసరం ఉంది లేదా అటువంటి సీక్వెన్షియల్ స్కాన్‌లను ఉపయోగించే ప్రశ్నలను ఆప్టిమైజ్ చేయడం సాధ్యమవుతుంది. ఇది జరగదని.
ఒక సాధారణ ఉదాహరణ - పెద్ద ఆఫ్‌సెట్ మరియు పరిమితి ఖర్చులతో కూడిన అభ్యర్థనను చెప్పండి. ఉదాహరణకు, పట్టికలోని 100 అడ్డు వరుసలు స్కాన్ చేయబడతాయి మరియు ఆ తర్వాత 000 అవసరమైన అడ్డు వరుసలు తీసుకోబడతాయి మరియు మునుపటి స్కాన్ చేసిన అడ్డు వరుసలు విస్మరించబడతాయి. ఇది కూడా చెడ్డ కేసు. మరియు అలాంటి ప్రశ్నలను ఆప్టిమైజ్ చేయాలి. మరియు ఇక్కడ ఒక సాధారణ SQL ప్రశ్న ఉంది, ఇక్కడ మీరు దీన్ని చూడవచ్చు మరియు ఫలిత సంఖ్యలను అంచనా వేయవచ్చు.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;ఈ పట్టికను ఉపయోగించి మరియు అదనపు ఫంక్షన్లను ఉపయోగించి టేబుల్ పరిమాణాలను కూడా పొందవచ్చు pg_total_relation_size(), pg_relation_size().
సాధారణంగా, మెటాకమాండ్‌లు ఉన్నాయి dt и di, ఇది PSQLలో ఉపయోగించబడుతుంది మరియు పట్టికలు మరియు సూచికల పరిమాణాలను కూడా వీక్షించవచ్చు.
అయినప్పటికీ, ఫంక్షన్లను ఉపయోగించడం వలన సూచికలను పరిగణనలోకి తీసుకోకుండా లేదా సూచికలను పరిగణనలోకి తీసుకోకుండా పట్టికల పరిమాణాలను చూడటంలో మాకు సహాయపడుతుంది మరియు డేటాబేస్ యొక్క పెరుగుదల ఆధారంగా ఇప్పటికే కొన్ని అంచనాలను రూపొందించడం, అంటే అది ఎలా పెరుగుతోంది, ఏ తీవ్రతతో మరియు సైజింగ్ ఆప్టిమైజేషన్ గురించి కొన్ని తీర్మానాలు చేయండి.
రికార్డింగ్ కార్యాచరణ. రికార్డింగ్ అంటే ఏమిటి? ఆపరేషన్ చూద్దాం UPDATE - పట్టికలో అడ్డు వరుసలను నవీకరించే ఆపరేషన్. వాస్తవానికి, నవీకరణ రెండు కార్యకలాపాలు (లేదా అంతకంటే ఎక్కువ). ఇది అడ్డు వరుస యొక్క కొత్త సంస్కరణను చొప్పించడం మరియు అడ్డు వరుస యొక్క పాత సంస్కరణను వాడుకలో లేనిదిగా గుర్తించడం. తదనంతరం, ఆటోవాక్యూమ్ వచ్చి, ఈ పాతకాలపు లైన్ల సంస్కరణలను శుభ్రపరుస్తుంది, ఈ స్థలాన్ని పునర్వినియోగానికి అందుబాటులో ఉన్నట్లు గుర్తు చేస్తుంది.
అదనంగా, నవీకరణ అనేది పట్టికను నవీకరించడం మాత్రమే కాదు. ఇది కూడా ఇండెక్స్ అప్‌డేట్. మీరు టేబుల్‌పై అనేక సూచికలను కలిగి ఉంటే, అప్‌డేట్ సమయంలో ప్రశ్నలో అప్‌డేట్ చేయబడిన ఫీల్డ్‌లను కలిగి ఉన్న అన్ని సూచికలు కూడా నవీకరించబడాలి. ఈ సూచికలు క్లీన్ అప్ చేయాల్సిన అడ్డు వరుసల పాత వెర్షన్లను కూడా కలిగి ఉంటాయి.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;మరియు దాని కొత్త డిజైన్ కారణంగా, UPDATE అనేది హెవీవెయిట్ ఆపరేషన్. కానీ వాటిని సులభతరం చేయవచ్చు. తినండి hot updates. అవి PostgreSQL వెర్షన్ 8.3లో కనిపించాయి. మరియు ఇది ఏమిటి? ఇది తేలికైన అప్‌డేట్, ఇండెక్స్‌లు పునర్నిర్మించబడవు. అంటే, మేము రికార్డ్‌ను అప్‌డేట్ చేసాము, కానీ పేజీలోని రికార్డ్ మాత్రమే (టేబుల్‌కి చెందినది) అప్‌డేట్ చేయబడింది మరియు ఇండెక్స్‌లు ఇప్పటికీ పేజీలోని అదే రికార్డ్‌ను సూచిస్తాయి. ఒక ఆసక్తికరమైన ఆపరేటింగ్ లాజిక్ ఉంది: వాక్యూమ్ వచ్చినప్పుడు, అది ఈ గొలుసులను సృష్టిస్తుంది hot పునర్నిర్మిస్తుంది మరియు సూచికలను నవీకరించకుండా ప్రతిదీ పని చేస్తూనే ఉంటుంది మరియు ప్రతిదీ తక్కువ వనరుల వ్యర్థాలతో జరుగుతుంది.
మరియు మీరు ఎప్పుడు n_tup_hot_upd పెద్దది, అప్పుడు చాలా బాగుంది. దీని అర్థం తేలికైన నవీకరణలు ప్రధానంగా ఉంటాయి మరియు వనరుల పరంగా ఇది మాకు చౌకగా ఉంటుంది మరియు ప్రతిదీ బాగానే ఉంది.
ALTER TABLE table_name SET (fillfactor = 70);వాల్యూమ్ పెంచడం ఎలా hot updateov? మనం ఉపయోగించుకోవచ్చు fillfactor. ఇన్సర్ట్లను ఉపయోగించి పట్టికలో పేజీని పూరించేటప్పుడు ఇది రిజర్వు చేయబడిన ఖాళీ స్థలం యొక్క పరిమాణాన్ని నిర్ణయిస్తుంది. పట్టికకు ఇన్సర్ట్లను జోడించినప్పుడు, అవి పేజీని పూర్తిగా నింపుతాయి మరియు దానిలో ఖాళీ స్థలాన్ని వదిలివేయవు. అప్పుడు కొత్త పేజీ హైలైట్ అవుతుంది. డేటా మళ్లీ పూరించబడింది. మరియు ఇది డిఫాల్ట్ ప్రవర్తన, ఫిల్‌ఫ్యాక్టర్ = 100%.
మేము ఫిల్ఫ్యాక్టరును 70% చేయవచ్చు. అంటే, ఇన్‌సర్ట్‌ల సమయంలో, ఒక కొత్త పేజీ హైలైట్ చేయబడింది, అయితే పేజీలో 70% మాత్రమే నింపబడింది. మరియు మాకు 30% రిజర్వ్‌గా మిగిలి ఉంది. మీరు నవీకరణ చేయవలసి వచ్చినప్పుడు, ఇది చాలా మటుకు అదే పేజీలో జరుగుతుంది మరియు లైన్ యొక్క కొత్త వెర్షన్ అదే పేజీలో సరిపోతుంది. మరియు hot_update చేయబడుతుంది. ఇది టేబుల్‌లపై రాయడం సులభతరం చేస్తుంది.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));ఆటోవాక్యూమ్ క్యూ. Autovacuum అనేది PostgreSQLలో చాలా తక్కువ గణాంకాలు ఉన్న ఉపవ్యవస్థ. ప్రస్తుతం మనకు ఎన్ని వాక్యూమ్‌లు ఉన్నాయో pg_stat_activityలోని టేబుల్‌లలో మాత్రమే మనం చూడగలం. అయితే, క్యూలో ఎన్ని టేబుల్స్ ఉన్నాయో అర్థం చేసుకోవడం చాలా కష్టం.
గమనిక: _పోస్ట్‌గ్రెస్ 10తో ప్రారంభించి, వాటోవాక్ ట్రాకింగ్‌తో పరిస్థితి బాగా మెరుగుపడింది - pg_stat_progress వీక్షణ కనిపించిందివాక్యూమ్, ఇది కారు వాక్యూమ్‌ను పర్యవేక్షించే సమస్యను గణనీయంగా సులభతరం చేస్తుంది.
మేము ఈ సరళీకృత ప్రశ్నను ఉపయోగించవచ్చు. మరియు వాక్యూమ్‌ను ఎప్పుడు తయారు చేయాల్సి ఉంటుందో మనం చూడవచ్చు. కానీ వాక్యూమ్ ఎలా మరియు ఎప్పుడు ప్రారంభించాలి? ఇవి నేను ఇంతకు ముందు మాట్లాడుతున్న పంక్తుల వారసత్వ సంస్కరణలు. అప్‌డేట్ జరిగింది, లైన్ యొక్క కొత్త వెర్షన్ చొప్పించబడింది. స్ట్రింగ్ యొక్క పాత వెర్షన్ కనిపించింది. పట్టికలో pg_stat_user_tables అటువంటి పరామితి ఉంది n_dead_tup. ఇది "డెడ్" లైన్ల సంఖ్యను చూపుతుంది. మరియు చనిపోయిన వరుసల సంఖ్య నిర్దిష్ట థ్రెషోల్డ్ కంటే ఎక్కువగా మారిన వెంటనే, ఆటోవాక్యూమ్ టేబుల్‌పైకి వస్తుంది.
మరియు ఈ థ్రెషోల్డ్ ఎలా లెక్కించబడుతుంది? ఇది పట్టికలోని మొత్తం వరుసల సంఖ్యలో చాలా నిర్దిష్ట శాతం. ఒక పరామితి ఉంది autovacuum_vacuum_scale_factor. ఇది శాతాన్ని నిర్ణయిస్తుంది. 10% + 50 లైన్ల అదనపు ప్రాథమిక థ్రెషోల్డ్ ఉందని చెప్పండి. మరియు ఏమి జరుగుతుంది? టేబుల్‌లోని అన్ని అడ్డు వరుసలలో “10% + 50” కంటే ఎక్కువ డెడ్ రోలు ఉన్నప్పుడు, మేము టేబుల్‌ను ఆటోవాక్యూమ్‌లో ఉంచుతాము.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));అయితే, ఒక పాయింట్ ఉంది. పారామితుల కోసం ప్రాథమిక థ్రెషోల్డ్‌లు av_base_thresh и av_scale_factor వ్యక్తిగతంగా కేటాయించవచ్చు. మరియు, తదనుగుణంగా, థ్రెషోల్డ్ గ్లోబల్ కాదు, కానీ టేబుల్ కోసం వ్యక్తిగతమైనది. అందువలన, లెక్కించేందుకు, మీరు ట్రిక్స్ మరియు ట్రిక్స్ ఉపయోగించాలి. మరియు మీకు ఆసక్తి ఉంటే, మీరు Avito నుండి మా సహోద్యోగుల అనుభవాన్ని చూడవచ్చు (స్లయిడ్‌లోని లింక్ చెల్లదు మరియు టెక్స్ట్‌లో నవీకరించబడింది).
వారు వ్రాసారు , ఈ విషయాలను పరిగణనలోకి తీసుకుంటుంది. అక్కడ రెండు షీట్ల ఫుట్‌క్లాత్ ఉంది. కానీ ఇది సరిగ్గా లెక్కిస్తుంది మరియు చాలా ప్రభావవంతంగా మాకు తక్కువ ఉన్న పట్టికల కోసం చాలా వాక్యూమ్ ఎక్కడ అవసరమో అంచనా వేయడానికి అనుమతిస్తుంది.
దాని గురించి మనం ఏమి చేయగలం? మనకు పెద్ద క్యూ ఉంటే మరియు ఆటోవాక్యూమ్ తట్టుకోలేకపోతే, మేము వాక్యూమ్ వర్కర్ల సంఖ్యను పెంచవచ్చు లేదా వాక్యూమ్‌ను మరింత దూకుడుగా చేయవచ్చు, తద్వారా ఇది ముందుగా ప్రేరేపిస్తుంది, పట్టికను చిన్న ముక్కలుగా ప్రాసెస్ చేస్తుంది. దీంతో క్యూ తగ్గుతుంది. — ఇక్కడ ప్రధాన విషయం ఏమిటంటే డిస్క్‌లపై లోడ్‌ను పర్యవేక్షించడం, ఎందుకంటే... వాక్యూమ్ అనేది ఉచిత విషయం కాదు, అయినప్పటికీ SSD/NVMe పరికరాల రాకతో సమస్య తక్కువగా గుర్తించబడింది.
Pg_stat_all_indexes అనేది సూచికలపై గణాంకాలు. ఆమె పెద్దది కాదు. మరియు మేము సూచికల ఉపయోగంపై సమాచారాన్ని పొందేందుకు దీనిని ఉపయోగించవచ్చు. మరియు ఉదాహరణకు, మనకు ఏ ఇండెక్స్‌లు అదనంగా ఉన్నాయో మనం గుర్తించవచ్చు.
నేను ఇప్పటికే చెప్పినట్లు, నవీకరణ అనేది పట్టికల నవీకరణ మాత్రమే కాదు, ఇది సూచికల నవీకరణ కూడా. దీని ప్రకారం, మేము పట్టికలో అనేక సూచికలను కలిగి ఉంటే, అప్పుడు పట్టికలోని అడ్డు వరుసలను నవీకరించేటప్పుడు, ఇండెక్స్ చేయబడిన ఫీల్డ్‌ల సూచికలు కూడా నవీకరించబడాలి మరియు ఇండెక్స్ స్కాన్‌లు లేని ఉపయోగించని ఇండెక్స్‌లను కలిగి ఉంటే, అవి బ్యాలస్ట్‌గా వేలాడతాయి. మరియు మనం వాటిని వదిలించుకోవాలి. దీని కోసం మనకు ఒక క్షేత్రం కావాలి idx_scan. మేము ఇండెక్స్ స్కాన్‌ల సంఖ్యను మాత్రమే చూస్తాము. సూచికలు సాపేక్షంగా ఎక్కువ కాలం గణాంక నిల్వ (కనీసం 2-3 వారాలు) సున్నా స్కాన్‌లను కలిగి ఉంటే, చాలా మటుకు ఇవి చెడ్డ సూచికలు, మనం వాటిని వదిలించుకోవాలి.
గమనిక: స్ట్రీమింగ్ రెప్లికేషన్ క్లస్టర్‌ల విషయంలో ఉపయోగించని సూచికల కోసం శోధిస్తున్నప్పుడు, మీరు అన్ని క్లస్టర్ నోడ్‌లను తనిఖీ చేయాలి, ఎందుకంటే గణాంకాలు గ్లోబల్ కాదు, మరియు ఇండెక్స్ మాస్టర్‌లో ఉపయోగించబడకపోతే, దానిని ప్రతిరూపాలపై ఉపయోగించవచ్చు (అక్కడ లోడ్ ఉంటే).
రెండు లింకులు:
ఇవి ఉపయోగించని ఇండెక్స్‌లను ఎలా చూడాలనే దానిపై మరింత అధునాతన ప్రశ్న ఉదాహరణలు.
రెండవ లింక్ చాలా ఆసక్తికరమైన అభ్యర్థన. అక్కడ చాలా నాన్-ట్రివియల్ లాజిక్ ఉంది. నేను సూచన కోసం సిఫార్సు చేస్తున్నాను.
సూచికలను ఉపయోగించి సంగ్రహించడం విలువైనది ఏమిటి?
-
ఉపయోగించని సూచికలు చెడ్డవి.
-
వారు స్థలాన్ని తీసుకుంటారు.
-
నవీకరణ కార్యకలాపాలను నెమ్మదిస్తుంది.
-
వాక్యూమ్ కోసం అదనపు పని.
మేము ఉపయోగించని సూచికలను తీసివేస్తే, మేము డేటాబేస్ను మాత్రమే మెరుగుపరుస్తాము.
తదుపరి ప్రదర్శన pg_stat_activity. ఇది యుటిలిటీ యొక్క అనలాగ్ ps, PostgreSQLలో మాత్రమే. ఉంటే ps'ఓం మీరు ఆపరేటింగ్ సిస్టమ్‌లోని ప్రక్రియలను చూడండి pg_stat_activity ఇది మీకు PostgreSQLలోని కార్యాచరణను చూపుతుంది.
అక్కడ నుండి మనం ఎలాంటి ఉపయోగకరమైన వస్తువులను తీసుకోవచ్చు?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;మేము సాధారణ కార్యాచరణను చూడవచ్చు, డేటాబేస్లో ఏమి జరుగుతుందో. మేము ఒక కొత్త విస్తరణ చేయవచ్చు. ఇక్కడ అంతా పేలింది, కొత్త కనెక్షన్లు అంగీకరించడం లేదు, అప్లికేషన్‌లో లోపాలు వెల్లువెత్తుతున్నాయి.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;మేము ఇలాంటి ప్రశ్నను అమలు చేయవచ్చు మరియు గరిష్ట కనెక్షన్ పరిమితికి సంబంధించి కనెక్షన్ల మొత్తం శాతాన్ని చూడవచ్చు మరియు ఎవరికి ఎక్కువ కనెక్షన్లు ఉన్నాయో చూడవచ్చు. మరియు ఈ సందర్భంలో మేము ఆ వినియోగదారుని చూస్తాము cron_role 508 కనెక్షన్లు తెరిచారు. మరియు అక్కడ అతనికి ఏదో జరిగింది. మేము దానిని ఎదుర్కోవాలి మరియు దానిని పరిశీలించాలి. మరియు ఇది ఒక రకమైన క్రమరహిత కనెక్షన్ల సంఖ్య అని చాలా సాధ్యమే.
మనకు OLTP పనిభారం ఉన్నట్లయితే, ప్రశ్నలు వేగంగా, చాలా వేగంగా ఉండాలి మరియు ఎక్కువ ప్రశ్నలు ఉండకూడదు. అయితే, సుదీర్ఘ ప్రశ్నలు తలెత్తితే, స్వల్పకాలికంలో ఆందోళన చెందాల్సిన పని లేదు, కానీ దీర్ఘకాలంలో, దీర్ఘకాల ప్రశ్నలు డేటాబేస్‌కు హాని కలిగిస్తాయి; టేబుల్ ఫ్రాగ్మెంటేషన్ జరిగినప్పుడు అవి టేబుల్‌ల ఉబ్బు ప్రభావాన్ని పెంచుతాయి. మీరు ఉబ్బు మరియు దీర్ఘ ప్రశ్నలు రెండింటినీ వదిలించుకోవాలి.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;దయచేసి గమనించండి: ఈ అభ్యర్థనతో మేము సుదీర్ఘ ప్రశ్నలు మరియు లావాదేవీలను గుర్తించగలము. మేము ఫంక్షన్‌ని ఉపయోగిస్తాము clock_timestamp() ఆపరేటింగ్ సమయాన్ని నిర్ణయించడానికి. మేము కనుగొన్న సుదీర్ఘ ప్రశ్నలు, మేము వాటిని గుర్తుంచుకోవచ్చు, వాటిని నెరవేర్చవచ్చు explain, ప్రణాళికలను చూడండి మరియు ఏదో ఒకవిధంగా ఆప్టిమైజ్ చేయండి. మేము ప్రస్తుత సుదీర్ఘ అభ్యర్థనలను తగ్గించి, మా జీవితాలను కొనసాగిస్తాము.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';చెడ్డ లావాదేవీలు అనేది లావాదేవీలో నిష్క్రియ మరియు లావాదేవీలలో నిష్క్రియ (ఆపివేయబడిన) రాష్ట్రాల్లో లావాదేవీలు.
దాని అర్థం ఏమిటి? లావాదేవీలు బహుళ రాష్ట్రాలను కలిగి ఉంటాయి. మరియు ఈ రాష్ట్రాల్లో ఒకదానిని ఎప్పుడైనా ఊహించవచ్చు. రాష్ట్రాలను నిర్వచించడానికి ఒక ఫీల్డ్ ఉంది state ఈ ప్రదర్శనలో. మరియు మేము దానిని రాష్ట్రాన్ని నిర్ణయించడానికి ఉపయోగిస్తాము.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';మరియు, నేను పైన చెప్పినట్లుగా, ఈ రెండు రాష్ట్రాలు లావాదేవీలో నిష్క్రియ మరియు లావాదేవీలో నిష్క్రియ (ఆపివేయబడినవి) చెడ్డవి. అదేంటి? అప్లికేషన్ లావాదేవీని తెరిచినప్పుడు, కొన్ని చర్యలు చేసి, దాని వ్యాపారాన్ని ప్రారంభించింది. లావాదేవీ తెరిచి ఉంటుంది. ఇది వ్రేలాడదీయబడుతుంది, దానిలో ఏమీ జరగదు, ఇది కనెక్షన్‌ని తీసుకుంటుంది, మార్చబడిన అడ్డు వరుసలపై లాక్ చేస్తుంది మరియు పోస్టర్జెస్ లావాదేవీ ఇంజిన్ యొక్క నిర్మాణం కారణంగా ఇతర పట్టికల ఉబ్బును సంభావ్యంగా పెంచుతుంది. మరియు అలాంటి లావాదేవీలు కూడా కాల్చివేయబడాలి, ఎందుకంటే అవి సాధారణంగా హానికరం, ఏ సందర్భంలోనైనా.
మీ డేటాబేస్లో వాటిలో 5-10-20 కంటే ఎక్కువ ఉన్నట్లు మీరు చూసినట్లయితే, మీరు ఆందోళన చెందాలి మరియు వారితో ఏదైనా చేయడం ప్రారంభించాలి.
ఇక్కడ మేము గణన సమయం కోసం కూడా ఉపయోగిస్తాము clock_timestamp(). మేము లావాదేవీలను షూట్ చేస్తాము మరియు అప్లికేషన్‌ను ఆప్టిమైజ్ చేస్తాము.
నేను పైన చెప్పినట్లుగా, రెండు లేదా అంతకంటే ఎక్కువ లావాదేవీలు ఒకటి లేదా వనరుల సమూహం కోసం పోరాడినప్పుడు నిరోధించడం. దీని కోసం మనకు ఒక క్షేత్రం ఉంది waiting బూలియన్ విలువతో true లేదా false.
నిజమే - దీని అర్థం ప్రక్రియ పెండింగ్‌లో ఉంది, ఏదో ఒకటి చేయాలి. ప్రక్రియ వేచి ఉన్నప్పుడు, ఈ ప్రక్రియను ప్రారంభించిన క్లయింట్ కూడా వేచి ఉన్నారని అర్థం. క్లయింట్ బ్రౌజర్‌లో కూర్చుని కూడా వేచి ఉంటాడు.
హెచ్చరిక: _పోస్ట్‌గ్రెస్ వెర్షన్ 9.6 ఫీల్డ్ నుండి ప్రారంభమవుతుంది waiting తీసివేయబడింది మరియు బదులుగా మరో రెండు సమాచార ఫీల్డ్‌లు జోడించబడ్డాయి wait_event_type и wait_event._
నేను ఏమి చేయాలి? మీరు చాలా కాలం వరకు నిజం అని చూస్తున్నట్లయితే, మీరు అలాంటి అభ్యర్థనలను వదిలించుకోవాలని అర్థం. మేము కేవలం అటువంటి లావాదేవీలను తగ్గించుకుంటాము. డెవలపర్లు ఏదో ఒకవిధంగా ఆప్టిమైజ్ చేయాలని మేము వారికి వ్రాస్తాము, తద్వారా వనరుల కోసం రేసు ఉండదు. ఆపై డెవలపర్లు అప్లికేషన్‌ను ఆప్టిమైజ్ చేస్తారు, తద్వారా ఇది జరగదు.
మరియు విపరీతమైన, కానీ ప్రాణాంతకం కాని కేసు ప్రతిష్టంభనలు సంభవించడం. రెండు లావాదేవీలు రెండు వనరులను నవీకరించాయి, ఆపై వాటిని మళ్లీ యాక్సెస్ చేయబడ్డాయి, ఈసారి వ్యతిరేక వనరులకు. ఈ సందర్భంలో, PostgreSQL లావాదేవీని చంపేస్తుంది, తద్వారా మరొకటి పనిని కొనసాగించవచ్చు. ఇది డెడ్ ఎండ్ పరిస్థితి మరియు ఆమె దానిని స్వయంగా గుర్తించలేరు. అందువల్ల, PostgreSQL తీవ్ర చర్యలు తీసుకోవలసి వస్తుంది.
బ్లాక్ చేయడాన్ని ట్రాక్ చేయడానికి మిమ్మల్ని అనుమతించే రెండు ప్రశ్నలు ఇక్కడ ఉన్నాయి. మేము వీక్షణను ఉపయోగిస్తాము pg_locks, ఇది భారీ తాళాలను ట్రాక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
మరియు మొదటి లింక్ అభ్యర్థన వచనం. ఇది చాలా పొడవుగా ఉంది.
మరియు రెండవ లింక్ తాళాలపై ఒక వ్యాసం. ఇది చదవడానికి ఉపయోగకరంగా ఉంటుంది, ఇది చాలా ఆసక్తికరంగా ఉంటుంది.
కాబట్టి మనం ఏమి చూస్తాము? మేము రెండు అభ్యర్థనలను చూస్తాము. తో లావాదేవీ ALTER TABLE నిరోధించే లావాదేవీ. ఇది ప్రారంభమైంది, కానీ పూర్తి కాలేదు మరియు ఈ లావాదేవీని రికార్డ్ చేసిన అప్లికేషన్ ఎక్కడో ఇతర పనులను చేస్తోంది. మరియు రెండవ అభ్యర్థన నవీకరణ. అతను తన పనిని కొనసాగించడానికి ముందు ఆల్టర్ టేబుల్ ముగిసే వరకు వేచి ఉంటాడు.
ఎవరు ఎవరిని లాక్ చేసారో, ఎవరిని పట్టుకున్నారో ఈ విధంగా మనం కనుగొనవచ్చు మరియు మేము దానిని మరింతగా ఎదుర్కోగలము.
తదుపరి మాడ్యూల్ pg_stat_statements. నేను చెప్పినట్లుగా, ఇది మాడ్యూల్. దీన్ని ఉపయోగించడానికి, మీరు దాని లైబ్రరీని కాన్ఫిగరేషన్‌లో లోడ్ చేయాలి, PostgreSQLని పునఃప్రారంభించాలి, మాడ్యూల్‌ను ఇన్‌స్టాల్ చేయాలి (ఒక కమాండ్‌తో) ఆపై మనకు కొత్త వీక్షణ ఉంటుంది.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;మేము అక్కడ నుండి ఏమి తీసుకోవచ్చు? మేము సాధారణ విషయాల గురించి మాట్లాడినట్లయితే, మేము సగటు ప్రశ్న అమలు సమయాన్ని తీసుకోవచ్చు. సమయం పెరుగుతోంది, అంటే PostgreSQL నెమ్మదిగా ప్రతిస్పందిస్తోంది మరియు మనం ఏదైనా చేయాలి.
షేర్డ్ బఫర్‌లలో డేటాను మార్చే డేటాబేస్లో అత్యంత యాక్టివ్ రైటింగ్ లావాదేవీలను మనం చూడవచ్చు. అక్కడ డేటాను ఎవరు అప్‌డేట్ చేస్తారో లేదా తొలగిస్తారో చూడండి.
మరియు మేము ఈ అభ్యర్థనల కోసం వివిధ గణాంకాలను చూడవచ్చు.
మేము pg_stat_statements మేము దానిని నివేదికలను రూపొందించడానికి ఉపయోగిస్తాము. మేము రోజుకు ఒకసారి గణాంకాలను రీసెట్ చేస్తాము. దాన్ని కూడబెట్టుకుందాం. తదుపరిసారి గణాంకాలను రీసెట్ చేయడానికి ముందు, ఒక నివేదికను రూపొందించండి. నివేదికకు లింక్ ఇక్కడ ఉంది. మీరు దానిని చూడవచ్చు.
ఏం చేస్తున్నాం? మేము అన్ని అభ్యర్థనల కోసం సాధారణ గణాంకాలను గణిస్తాము. ఆపై, ప్రతి అభ్యర్థన కోసం, మేము ఈ మొత్తం గణాంకాలకు దాని వ్యక్తిగత సహకారాన్ని లెక్కిస్తాము.
మరియు మనం ఏమి చూడవచ్చు? మేము అన్ని ఇతర అభ్యర్థనల నేపథ్యానికి వ్యతిరేకంగా నిర్దిష్ట రకానికి చెందిన అన్ని అభ్యర్థనల మొత్తం అమలు సమయాన్ని చూడవచ్చు. మేము మొత్తం చిత్రానికి సంబంధించి CPU మరియు I/O వనరుల వినియోగాన్ని చూడవచ్చు. మరియు ఇప్పటికే ఈ ప్రశ్నలను ఆప్టిమైజ్ చేయండి. మేము ఈ నివేదిక ఆధారంగా అగ్రశ్రేణి ప్రశ్నలను రూపొందిస్తున్నాము మరియు దేనిని ఆప్టిమైజ్ చేయాలనే దాని గురించి ఇప్పటికే ఆలోచించాల్సిన అవసరం ఉంది.
తెర వెనుక మనకు ఏమి మిగిలి ఉంది? సమయం తక్కువగా ఉన్నందున నేను పరిగణించని కొన్ని సమర్పణలు ఇంకా మిగిలి ఉన్నాయి.
ఉన్నాయి pgstattuple ప్రామాణిక సహకారాల ప్యాకేజీ నుండి అదనపు మాడ్యూల్ కూడా. ఇది మూల్యాంకనం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది bloat పట్టికలు, అని పిలవబడే టేబుల్ ఫ్రాగ్మెంటేషన్. మరియు ఫ్రాగ్మెంటేషన్ చాలా ఉంటే, మీరు దానిని తీసివేయాలి మరియు వివిధ సాధనాలను ఉపయోగించాలి. మరియు ఫంక్షన్ pgstattuple చాలా కాలం పని చేస్తుంది. మరియు ఎక్కువ పట్టికలు ఉంటే, అది ఎక్కువసేపు పని చేస్తుంది.
తదుపరి సహకారం pg_buffercache. ఇది భాగస్వామ్య బఫర్‌లను తనిఖీ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది: బఫర్ పేజీలు ఎంత ఇంటెన్సివ్‌గా మరియు ఏ టేబుల్స్ కోసం ఉపయోగించబడుతున్నాయి. మరియు ఇది భాగస్వామ్య బఫర్‌లను పరిశీలించడానికి మరియు అక్కడ ఏమి జరుగుతుందో విశ్లేషించడానికి మిమ్మల్ని అనుమతిస్తుంది.
తదుపరి మాడ్యూల్ pgfincore. ఇది సిస్టమ్ కాల్ ద్వారా తక్కువ-స్థాయి పట్టిక కార్యకలాపాలను అనుమతిస్తుంది mincore(), అంటే ఇది షేర్ చేయబడిన బఫర్‌లలోకి పట్టికను లోడ్ చేయడానికి లేదా దాన్ని అన్‌లోడ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మరియు, ఇతర విషయాలతోపాటు, ఇది ఆపరేటింగ్ సిస్టమ్ యొక్క పేజీ కాష్‌ను తనిఖీ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, అనగా, పేజీ కాష్‌లో, షేర్డ్ బఫర్‌లలో టేబుల్ ఎంత స్థలాన్ని ఆక్రమిస్తుంది మరియు పట్టిక యొక్క పనిభారాన్ని అంచనా వేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
తదుపరి మాడ్యూల్ - pg_stat_kcache. ఇది సిస్టమ్ కాల్‌ను కూడా ఉపయోగిస్తుంది getrusage(). మరియు అభ్యర్థనను అమలు చేయడానికి ముందు మరియు తర్వాత అది అమలు చేస్తుంది. మరియు ఫలిత గణాంకాలలో, డిస్క్ I/Oపై మన అభ్యర్థన ఎంత ఖర్చు చేయబడిందో అంచనా వేయడానికి అనుమతిస్తుంది, అనగా ఫైల్ సిస్టమ్‌తో కార్యకలాపాలు మరియు ప్రాసెసర్ వినియోగాన్ని చూస్తుంది. అయినప్పటికీ, మాడ్యూల్ చిన్నది (దగ్గు దగ్గు) మరియు దాని ఆపరేషన్ కోసం నేను ఇంతకు ముందు పేర్కొన్న PostgreSQL 9.4 మరియు pg_stat_statementలు అవసరం.
-
గణాంకాలను ఎలా ఉపయోగించాలో తెలుసుకోవడం ఉపయోగకరంగా ఉంటుంది. మీకు థర్డ్ పార్టీ ప్రోగ్రామ్‌లు అవసరం లేదు. మీరు లోపలికి రావచ్చు, చూడవచ్చు, ఏదైనా చేయవచ్చు, ఏదైనా సాధించవచ్చు.
-
గణాంకాలను ఉపయోగించడం కష్టం కాదు, ఇది సాధారణ SQL మాత్రమే. మీరు అభ్యర్థనను సేకరించారు, కంపైల్ చేసారు, పంపారు, చూశారు.
-
ప్రశ్నలకు సమాధానం ఇవ్వడానికి గణాంకాలు సహాయపడతాయి. మీకు ఏవైనా ప్రశ్నలు ఉంటే, మీరు గణాంకాలను ఆశ్రయించండి - చూడండి, తీర్మానాలు చేయండి, ఫలితాలను విశ్లేషించండి.
-
మరియు ప్రయోగం. చాలా అభ్యర్థనలు, చాలా డేటా ఉన్నాయి. మీరు ఇప్పటికే ఉన్న ప్రశ్నను ఎల్లప్పుడూ ఆప్టిమైజ్ చేయవచ్చు. మీరు ఒరిజినల్ కంటే మీకు సరిపోయే అభ్యర్థన యొక్క మీ స్వంత వెర్షన్‌ను తయారు చేసుకోవచ్చు మరియు దానిని ఉపయోగించవచ్చు.
సూచనలు
మెటీరియల్‌ల ఆధారంగా కథనంలో కనుగొనబడిన తగిన లింక్‌లు నివేదికలో ఉన్నాయి.
రచయిత మరింత వ్రాయండి
(ఇంగ్లీషు)
స్టాటిస్టిక్స్ కలెక్టర్
సిస్టమ్ అడ్మినిస్ట్రేషన్ విధులు
కాంట్రిబ్ మాడ్యూల్స్
SQL యుటిల్స్ మరియు sql కోడ్ ఉదాహరణలు
మీ దృష్టికి అందరికీ ధన్యవాదాలు!
మూలం: www.habr.com