அலெக்ஸி லெசோவ்ஸ்கியின் 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 இல் உள்ள பரிவர்த்தனை பதிவில் பதிவு செய்யப்படும். சில புள்ளிவிவரத் தகவல்கள் பதிவு அல்லது புள்ளியியல் சேகரிப்பாளரில் முடிவடையும். மேலும் கோரிக்கையின் முடிவு வாடிக்கையாளருக்கு திருப்பி அனுப்பப்படும். அதன் பிறகு கிளையன்ட் ஒரு புதிய கோரிக்கையுடன் எல்லாவற்றையும் மீண்டும் செய்யலாம்.
பின்னணி பணிகள் மற்றும் பின்னணி செயல்முறைகள் பற்றி என்ன? தரவுத்தளத்தை சாதாரண இயக்க முறையில் இயங்க வைக்கும் பல செயல்முறைகள் எங்களிடம் உள்ளன. இந்தச் செயல்முறைகள் அறிக்கையில் தொடுக்கப்படும்: autovacuum, checkpointer, replication தொடர்பான செயல்முறைகள், பின்னணி எழுத்தாளர். நான் அறிக்கையிடும்போது அவை ஒவ்வொன்றையும் தொடுவேன்.
புள்ளிவிவரங்களில் என்ன சிக்கல்கள் உள்ளன?
- நிறைய தகவல்கள் உள்ளன. PostgreSQL 9.4 புள்ளியியல் தரவைப் பார்ப்பதற்கு 109 அளவீடுகளை வழங்குகிறது. இருப்பினும், தரவுத்தளம் பல அட்டவணைகள், ஸ்கீமாக்கள், தரவுத்தளங்களைச் சேமித்து வைத்தால், இந்த அளவீடுகள் அனைத்தும் தொடர்புடைய அட்டவணைகள், தரவுத்தளங்களால் பெருக்கப்பட வேண்டும். அதாவது, இன்னும் அதிகமான தகவல்கள் உள்ளன. மேலும் அதில் மூழ்குவது மிகவும் எளிது.
- அடுத்த சிக்கல் என்னவென்றால், புள்ளிவிவரங்கள் கவுண்டர்களால் குறிப்பிடப்படுகின்றன. இந்த புள்ளிவிவரங்களைப் பார்த்தால், தொடர்ந்து அதிகரித்து வரும் கவுண்டர்களைப் பார்க்கலாம். புள்ளிவிவரங்கள் மீட்டமைக்கப்பட்டதிலிருந்து நிறைய நேரம் கடந்துவிட்டால், பில்லியன்களில் மதிப்புகளைக் காண்போம். மேலும் அவர்கள் எங்களிடம் எதுவும் சொல்வதில்லை.
- கதை இல்லை. உங்களுக்கு ஏதேனும் தோல்வி ஏற்பட்டால், 15-30 நிமிடங்களுக்கு முன்பு ஏதாவது விழுந்தால், நீங்கள் புள்ளிவிவரங்களைப் பயன்படுத்த முடியாது மற்றும் 15-30 நிமிடங்களுக்கு முன்பு என்ன நடந்தது என்பதைப் பார்க்க முடியாது. இது பிரச்சனை.
- PostgreSQL இல் கட்டமைக்கப்பட்ட கருவி இல்லாதது ஒரு பிரச்சனை. கர்னல் டெவலப்பர்கள் எந்த பயன்பாட்டையும் வழங்கவில்லை. அவர்களிடம் அப்படி எதுவும் இல்லை. அவை தரவுத்தளத்தில் புள்ளிவிவரங்களை வழங்குகின்றன. அதைப் பயன்படுத்துங்கள், கோரிக்கை விடுங்கள், நீங்கள் விரும்பியதைச் செய்யுங்கள்.
- PostgreSQL இல் எந்த கருவியும் கட்டமைக்கப்படாததால், இது மற்றொரு சிக்கலை ஏற்படுத்துகிறது. மூன்றாம் தரப்பு கருவிகள் நிறைய. அதிகமாகவோ அல்லது குறைவாகவோ நேரடி கைகளைக் கொண்ட ஒவ்வொரு நிறுவனமும் அதன் சொந்த திட்டத்தை எழுத முயற்சிக்கிறது. இதன் விளைவாக, புள்ளிவிவரங்களுடன் பணிபுரிய சமூகத்தில் நிறைய கருவிகள் உள்ளன. மேலும் சில கருவிகளுக்கு சில திறன்கள் உள்ளன, மற்ற கருவிகளுக்கு வேறு திறன்கள் இல்லை அல்லது சில புதிய திறன்கள் உள்ளன. நீங்கள் இரண்டு, மூன்று அல்லது நான்கு கருவிகளைப் பயன்படுத்த வேண்டிய சூழ்நிலை எழுகிறது, அவை ஒன்றுடன் ஒன்று மற்றும் வெவ்வேறு செயல்பாடுகளைக் கொண்டுள்ளன. இது மிகவும் விரும்பத்தகாதது.
இதிலிருந்து என்ன தெரிகிறது? நிரல்களைச் சார்ந்து இருக்காமல், அல்லது எப்படியாவது இந்தத் திட்டங்களை நீங்களே மேம்படுத்திக் கொள்ளாமல் இருக்க, புள்ளிவிவரங்களை நேரடியாகப் பெறுவது முக்கியம்: உங்கள் சொந்த நன்மையைப் பெற சில செயல்பாடுகளைச் சேர்க்கவும்.
உங்களுக்கு SQL பற்றிய அடிப்படை அறிவு தேவை. புள்ளிவிவரங்களிலிருந்து சில தரவைப் பெற, நீங்கள் SQL வினவல்களை உருவாக்க வேண்டும், அதாவது தேர்ந்தெடுத்து சேர்வது எப்படி தொகுக்கப்படுகிறது என்பதை நீங்கள் அறிந்து கொள்ள வேண்டும்.
புள்ளிவிவரங்கள் நமக்கு பல விஷயங்களைக் கூறுகின்றன. அவற்றை வகைகளாகப் பிரிக்கலாம்.
- முதல் வகை தரவுத்தளத்தில் நிகழும் நிகழ்வுகள். தரவுத்தளத்தில் சில நிகழ்வுகள் நிகழும்போது இது நடக்கும்: ஒரு கோரிக்கை, ஒரு அட்டவணைக்கான அணுகல், autovacuum, உறுதிகள், பின்னர் இவை அனைத்தும் நிகழ்வுகள். இந்த நிகழ்வுகளுடன் தொடர்புடைய கவுண்டர்கள் அதிகரிக்கப்படுகின்றன. இந்த நிகழ்வுகளை நாம் கண்காணிக்க முடியும்.
- இரண்டாவது வகை அட்டவணைகள் மற்றும் தரவுத்தளங்கள் போன்ற பொருட்களின் பண்புகள் ஆகும். அவர்களுக்கு பண்புகள் உள்ளன. இது அட்டவணைகளின் அளவு. அட்டவணைகளின் வளர்ச்சி மற்றும் குறியீடுகளின் வளர்ச்சியை நாம் கண்காணிக்க முடியும். இயக்கவியலில் மாற்றங்களைக் காணலாம்.
- மூன்றாவது வகை நிகழ்வில் செலவழித்த நேரம். கோரிக்கை என்பது ஒரு நிகழ்வு. இது அதன் சொந்த குறிப்பிட்ட கால அளவைக் கொண்டுள்ளது. இங்கே தொடங்கியது, இங்கே முடிந்தது. நாம் அதை கண்காணிக்க முடியும். வட்டில் இருந்து ஒரு தொகுதியைப் படிக்க அல்லது அதை எழுத எடுக்கும் நேரம். போன்ற விஷயங்களும் கண்காணிக்கப்படுகின்றன.
புள்ளிவிவரங்களின் ஆதாரங்கள் பின்வருமாறு வழங்கப்படுகின்றன:
- பகிரப்பட்ட நினைவகத்தில் (பகிரப்பட்ட இடையகங்கள்) நிலையான தரவைச் சேமிப்பதற்கான ஒரு பிரிவு உள்ளது, சில நிகழ்வுகள் நிகழும்போது அல்லது தரவுத்தளத்தின் செயல்பாட்டில் சில தருணங்கள் ஏற்படும் போது தொடர்ந்து அதிகரிக்கும் கவுண்டர்களும் உள்ளன.
- இந்த கவுண்டர்கள் அனைத்தும் பயனரால் அணுக முடியாதவை மற்றும் நிர்வாகிக்கு கூட அணுக முடியாதவை. இவை குறைந்த அளவிலான விஷயங்கள். அவற்றை அணுக, PostgreSQL ஆனது SQL செயல்பாடுகளின் வடிவத்தில் ஒரு இடைமுகத்தை வழங்குகிறது. இந்த செயல்பாடுகளைப் பயன்படுத்தி தேர்ந்தெடுக்கப்பட்ட எறிதல்களை உருவாக்கலாம் மற்றும் சில வகையான மெட்ரிக் (அல்லது அளவீடுகளின் தொகுப்பு) பெறலாம்.
- இருப்பினும், இந்த செயல்பாடுகளைப் பயன்படுத்துவது எப்போதும் வசதியானது அல்ல, எனவே செயல்பாடுகள் பார்வைகளுக்கு (VIEWs) அடிப்படையாகும். இவை ஒரு குறிப்பிட்ட துணை அமைப்பில் அல்லது தரவுத்தளத்தில் ஒரு குறிப்பிட்ட நிகழ்வுகளின் புள்ளிவிவரங்களை வழங்கும் மெய்நிகர் அட்டவணைகள்.
- இந்த உட்பொதிக்கப்பட்ட காட்சிகள் (VIEWs) புள்ளிவிவரங்களுடன் பணிபுரிவதற்கான முதன்மையான பயனர் இடைமுகமாகும். அவை எந்த கூடுதல் அமைப்புகளும் இல்லாமல் இயல்பாகவே கிடைக்கின்றன, நீங்கள் உடனடியாக அவற்றைப் பயன்படுத்தலாம், அவற்றைப் பார்க்கலாம் மற்றும் அவர்களிடமிருந்து தகவல்களைப் பெறலாம். பின்னர் பங்களிப்புகள் உள்ளன. பங்களிப்புகள் அதிகாரப்பூர்வமானது. நீங்கள் postgresql-contrib தொகுப்பை நிறுவலாம் (உதாரணமாக, postgresql94-contrib), தேவையான தொகுதியை உள்ளமைவில் ஏற்றலாம், அதற்கான அளவுருக்களைக் குறிப்பிடலாம், PostgreSQL ஐ மறுதொடக்கம் செய்யலாம் மற்றும் நீங்கள் அதைப் பயன்படுத்தலாம். (குறிப்பு. விநியோகத்தைப் பொறுத்து, சமீபத்திய பதிப்புகளில் பங்களிப்பு தொகுப்பு முக்கிய தொகுப்பின் ஒரு பகுதியாகும்).
- மற்றும் அதிகாரப்பூர்வமற்ற பங்களிப்புகள் உள்ளன. நிலையான PostgreSQL விநியோகத்தில் அவை சேர்க்கப்படவில்லை. அவை தொகுக்கப்பட வேண்டும் அல்லது நூலகமாக நிறுவப்பட வேண்டும். இந்த அதிகாரப்பூர்வமற்ற பங்களிப்பின் டெவலப்பர் என்ன கொண்டு வந்தார் என்பதைப் பொறுத்து, விருப்பங்கள் மிகவும் வித்தியாசமாக இருக்கும்.
இந்த ஸ்லைடு அனைத்து காட்சிகளையும் PostgreSQL 9.4 இல் கிடைக்கும் சில செயல்பாடுகளையும் வழங்குகிறது. நாம் பார்க்கிறபடி, அவற்றில் நிறைய உள்ளன. நீங்கள் அதை முதல் முறையாக சந்தித்தால் குழப்பமடைவது மிகவும் எளிதானது.
இருப்பினும், முந்தைய படத்தை எடுத்தால் Как тратится время на PostgreSQL இந்த பட்டியலுடன் இணக்கமானது, இந்த படத்தைப் பெறுகிறோம். PostgreSQL இயங்கும் போது தொடர்புடைய புள்ளிவிவரங்களைப் பெற, ஒவ்வொரு பார்வையையும் (VIEWs) அல்லது ஒவ்வொரு செயல்பாட்டையும் ஒரு நோக்கத்திற்காகப் பயன்படுத்தலாம். துணை அமைப்பின் செயல்பாட்டைப் பற்றி ஏற்கனவே சில தகவல்களைப் பெறலாம்.
நாம் முதலில் பார்ப்பது pg_stat_database. நாம் பார்க்க முடியும் என, இது ஒரு செயல்திறன். அதில் பல தகவல்கள் உள்ளன. மிகவும் மாறுபட்ட தகவல்கள். மேலும் இது எங்கள் தரவுத்தளத்தில் என்ன நடக்கிறது என்பது பற்றிய மிகவும் பயனுள்ள அறிவை வழங்குகிறது.
அதிலிருந்து நாம் என்ன பயனுள்ள விஷயங்களை எடுக்க முடியும்? எளிமையான விஷயங்களுடன் ஆரம்பிக்கலாம்.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;நாம் பார்க்கக்கூடிய முதல் விஷயம் கேச் ஹிட் சதவீதமாகும். கேச் ஹிட் வீதம் பயனுள்ள அளவீடு ஆகும். பகிர்ந்த இடையக தற்காலிக சேமிப்பிலிருந்து எவ்வளவு தரவு எடுக்கப்படுகிறது மற்றும் வட்டில் இருந்து எவ்வளவு படிக்கப்படுகிறது என்பதை மதிப்பிட இது உங்களை அனுமதிக்கிறது.
என்பது தெளிவாகிறது எங்களிடம் அதிக கேச் ஹிட்ஸ் உள்ளது, சிறந்தது. இந்த அளவீட்டை சதவீதமாக அளவிடுகிறோம். மேலும், எடுத்துக்காட்டாக, இந்த கேச் ஹிட்களில் நமது சதவீதம் 90%க்கு மேல் இருந்தால், இது நல்லது. இது 90%க்குக் கீழே குறைந்தால், தரவுகளின் சூடான தலையை நினைவகத்தில் வைத்திருக்க போதுமான நினைவகம் நம்மிடம் இல்லை என்று அர்த்தம். இந்தத் தரவைப் பயன்படுத்த, PostgreSQL வட்டை அணுக வேண்டிய கட்டாயத்தில் உள்ளது, மேலும் இது தரவு நினைவகத்திலிருந்து படிக்கப்பட்டதை விட மெதுவாக இருக்கும். நினைவகத்தை அதிகரிப்பது பற்றி நீங்கள் சிந்திக்க வேண்டும்: பகிரப்பட்ட இடையகங்களை அதிகரிக்கவும் அல்லது வன்பொருள் நினைவகத்தை (ரேம்) அதிகரிக்கவும்.
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 க்கு கோரிக்கையை அனுப்பிய வாடிக்கையாளர் சிறிது நேரம் கழித்து பதிலைப் பெறுவார். இந்த செயல்பாடுகள் அனைத்தும் நினைவகத்தில் செய்யப்பட்டால், Postgres மிக வேகமாக பதிலளிக்கும் மற்றும் கிளையன்ட் குறைவாக காத்திருக்கும்.
Pg_stat_bgwriter - இந்த பார்வை இரண்டு PostgreSQL பின்னணி துணை அமைப்புகளின் செயல்பாட்டை விவரிக்கிறது: இது checkpointer и background writer.
முதலில், கட்டுப்பாட்டு புள்ளிகள் என்று அழைக்கப்படுவதைப் பார்ப்போம். checkpoints. கட்டுப்பாட்டு புள்ளிகள் என்றால் என்ன? சோதனைச் சாவடி என்பது பரிவர்த்தனை பதிவில் உள்ள ஒரு நிலையாகும், பதிவில் பதிவுசெய்யப்பட்ட அனைத்து தரவு மாற்றங்களும் வட்டில் உள்ள தரவுகளுடன் வெற்றிகரமாக ஒத்திசைக்கப்பட்டுள்ளன என்பதைக் குறிக்கிறது. பணிச்சுமை மற்றும் அமைப்புகளைப் பொறுத்து, செயல்முறை நீண்டதாக இருக்கும் மற்றும் பெரும்பாலும் பகிர்ந்த இடையகங்களில் உள்ள அழுக்கு பக்கங்களை வட்டில் உள்ள தரவுக் கோப்புகளுடன் ஒத்திசைப்பதைக் கொண்டுள்ளது. இது எதற்காக? PostgreSQL தொடர்ந்து வட்டை அணுகி, அங்கிருந்து தரவைப் பெற்று, ஒவ்வொரு அணுகலிலும் தரவை எழுதினால், அது மெதுவாக இருக்கும். எனவே, PostgreSQL ஆனது நினைவகப் பிரிவைக் கொண்டுள்ளது, அதன் அளவு உள்ளமைவில் உள்ள அமைப்புகளைப் பொறுத்தது. Postgres இந்த நினைவகத்தில் நேரடி தரவை பின்னர் செயலாக்க அல்லது வினவுவதற்காக சேமிக்கிறது. தரவை மாற்ற கோரிக்கைகள் இருந்தால், அது மாற்றப்படும். தரவுகளின் இரண்டு பதிப்புகளைப் பெறுகிறோம். ஒன்று நம் நினைவகத்தில் உள்ளது, மற்றொன்று வட்டில் உள்ளது. மேலும் அவ்வப்போது இந்தத் தரவை ஒத்திசைக்க வேண்டும். நினைவகத்தில் மாற்றப்பட்டதை வட்டுக்கு ஒத்திசைக்க வேண்டும். இதற்கு உங்களுக்கு சோதனைச் சாவடிகள் தேவை.
சோதனைச் சாவடி பகிரப்பட்ட இடையகங்கள் வழியாகச் சென்று, சோதனைச் சாவடிக்குத் தேவையான அழுக்குப் பக்கங்களைக் குறிக்கும். பின்னர் அது பகிரப்பட்ட இடையகங்கள் வழியாக இரண்டாவது பாஸைத் தொடங்குகிறது. சோதனைச் சாவடிக்காகக் குறிக்கப்பட்ட பக்கங்கள், அவற்றை ஏற்கனவே ஒத்திசைக்கிறது. இந்த வழியில் தரவு வட்டுடன் ஒத்திசைக்கப்படுகிறது.
இரண்டு வகையான சோதனைச் சாவடிகள் உள்ளன. ஒரு சோதனைச் சாவடி காலாவதியுடன் செயல்படுத்தப்படுகிறது. இந்தச் சோதனைச் சாவடி பயனுள்ளதாகவும் சிறப்பாகவும் உள்ளது - checkpoint_timed. தேவைக்கேற்ப சோதனைச் சாவடிகள் உள்ளன - checkpoint required. எங்களிடம் மிகப் பெரிய தரவுப் பதிவேடு இருக்கும்போது இந்தச் சோதனைச் சாவடி நிகழ்கிறது. நாங்கள் நிறைய பரிவர்த்தனை பதிவுகளை பதிவு செய்துள்ளோம். போஸ்ட்கிரெஸ்க்யூஎல் இதையெல்லாம் கூடிய விரைவில் ஒத்திசைத்து, ஒரு சோதனைச் சாவடியை உருவாக்கி முன்னேற வேண்டும் என்று நம்புகிறது.
மற்றும் நீங்கள் புள்ளிவிவரங்களைப் பார்த்தால் 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. பின்தளங்கள் மெதுவாக இருப்பதால் ஒத்திசைவதில்லை. அவர்கள் fsync ஐ ஐஓ ஸ்டேக் சோதனைச் சாவடியில் அனுப்புகிறார்கள். சோதனைச் சாவடிக்கு அதன் சொந்த வரிசை உள்ளது, இது அவ்வப்போது fsync ஐ செயலாக்குகிறது மற்றும் வட்டில் உள்ள கோப்புகளுடன் நினைவகத்தில் பக்கங்களை ஒத்திசைக்கிறது. சோதனைச் சாவடியில் வரிசை பெரியதாகவும், நிரம்பியதாகவும் இருந்தால், பின்தளமானது தன்னையே fsync செய்யும்படி நிர்பந்திக்கப்படும், மேலும் இது பின்தளத்தின் வேலையை குறைக்கிறது., அதாவது கிளையன்ட் முடிந்ததை விட பின்னர் பதிலைப் பெறுவார். உங்கள் மதிப்பு பூஜ்ஜியத்தை விட அதிகமாக இருப்பதை நீங்கள் கண்டால், இது ஏற்கனவே ஒரு பிரச்சனை மற்றும் பின்னணி எழுத்தாளரின் அமைப்புகளுக்கு நீங்கள் கவனம் செலுத்த வேண்டும் மற்றும் வட்டு துணை அமைப்பின் செயல்திறனை மதிப்பீடு செய்ய வேண்டும்.
எச்சரிக்கை: _பின்வரும் உரை நகலெடுப்புடன் தொடர்புடைய புள்ளிவிவரக் காட்சிகளை விவரிக்கிறது. பெரும்பாலான பார்வை மற்றும் செயல்பாட்டு பெயர்கள் Postgres 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 க்குப் பதிலாகdiff() செயல்பாடு கழித்தல் ஆபரேட்டரைப் பயன்படுத்தலாம் மற்றும் ஒரு இடத்தை மற்றொரு இடத்திலிருந்து கழிக்கலாம். வசதியான.
பின்னடைவுடன் ஒரு புள்ளி உள்ளது, இது நொடிகளில் உள்ளது. மாஸ்டரில் எந்த நடவடிக்கையும் இல்லை என்றால், 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 ஐ விட அதிகமாக இருந்தால், இது ஏற்கனவே ஒரு குறிகாட்டியாகும், ஒருவேளை நீங்கள் எங்காவது ஒரு குறியீட்டை உருவாக்க வேண்டும், இதனால் வினவல்கள் குறியீட்டை அடிப்படையாகக் கொண்டவை, அல்லது இதுபோன்ற தொடர்ச்சியான ஸ்கேன்களைப் பயன்படுத்தும் வினவல்களை மேம்படுத்த முடியும். இது நடக்காது என்று.
ஒரு எளிய உதாரணம் - ஒரு பெரிய OFFSET மற்றும் LIMIT செலவுகளைக் கொண்ட கோரிக்கையை வைத்துக் கொள்வோம். எடுத்துக்காட்டாக, ஒரு அட்டவணையில் உள்ள 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. INSERTகளைப் பயன்படுத்தி அட்டவணையில் ஒரு பக்கத்தை நிரப்பும்போது ஒதுக்கப்பட்ட இலவச இடத்தின் அளவை இது தீர்மானிக்கிறது. ஒரு அட்டவணையில் செருகல்கள் சேர்க்கப்படும் போது, அவை பக்கத்தை முழுவதுமாக நிரப்புகின்றன மற்றும் காலி இடத்தை விட்டுவிடாது. பின்னர் ஒரு புதிய பக்கம் முன்னிலைப்படுத்தப்படுகிறது. தரவு மீண்டும் நிரப்பப்பட்டது. இது இயல்புநிலை நடத்தை, நிரப்பு காரணி = 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 இல் உள்ள அட்டவணையில் மட்டுமே பார்க்க முடியும். இருப்பினும், வரிசையில் எத்தனை அட்டவணைகள் உள்ளன என்பதைப் புரிந்துகொள்வது மிகவும் கடினம்.
குறிப்பு: _Postgres 10 இல் தொடங்கி, Vatovac கண்காணிப்பின் நிலைமை பெரிதும் மேம்பட்டுள்ளது - pg_stat_progress காட்சி தோன்றியதுவெற்றிடம், இது கார் வெற்றிடத்தை கண்காணிக்கும் சிக்கலை கணிசமாக எளிதாக்குகிறது.
இந்த எளிமைப்படுத்தப்பட்ட வினவலை நாம் பயன்படுத்தலாம். வெற்றிடத்தை எப்போது உருவாக்க வேண்டும் என்பதை நாம் பார்க்கலாம். ஆனால் வெற்றிடத்தை எப்படி, எப்போது தொடங்க வேண்டும்? நான் முன்பு பேசிய வரிகளின் மரபு பதிப்புகள் இவை. புதுப்பிப்பு ஏற்பட்டது, வரியின் புதிய பதிப்பு செருகப்பட்டது. சரத்தின் காலாவதியான பதிப்பு தோன்றியது. அட்டவணையில் pg_stat_user_tables அத்தகைய அளவுரு உள்ளது n_dead_tup. இது "இறந்த" வரிகளின் எண்ணிக்கையைக் காட்டுகிறது. இறந்த வரிசைகளின் எண்ணிக்கை ஒரு குறிப்பிட்ட வரம்பை விட அதிகமாகும் போது, ஒரு autovacuum மேசைக்கு வரும்.
இந்த வரம்பு எவ்வாறு கணக்கிடப்படுகிறது? அட்டவணையில் உள்ள மொத்த வரிசைகளின் எண்ணிக்கையில் இது மிகவும் குறிப்பிட்ட சதவீதமாகும். ஒரு அளவுரு உள்ளது 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.
உண்மை - இதன் பொருள் செயல்முறை நிலுவையில் உள்ளது, ஏதாவது செய்ய வேண்டும். ஒரு செயல்முறை காத்திருக்கும் போது, இந்த செயல்முறையைத் தொடங்கிய கிளையன்ட்டும் காத்திருக்கிறார் என்று அர்த்தம். கிளையன்ட் உலாவியில் அமர்ந்து காத்திருக்கிறார்.
எச்சரிக்கை: _Postgres பதிப்பு 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_statements தேவை, நான் முன்பு குறிப்பிட்டேன்.
-
புள்ளிவிவரங்களை எவ்வாறு பயன்படுத்துவது என்பதை அறிவது பயனுள்ளதாக இருக்கும். உங்களுக்கு மூன்றாம் தரப்பு திட்டங்கள் தேவையில்லை. நீங்கள் உள்ளே வரலாம், பார்க்கலாம், ஏதாவது செய்யலாம், எதையாவது சாதிக்கலாம்.
-
புள்ளிவிவரங்களைப் பயன்படுத்துவது கடினம் அல்ல, இது வழக்கமான SQL தான். நீங்கள் கோரிக்கையை சேகரித்தீர்கள், தொகுத்தீர்கள், அனுப்பியுள்ளீர்கள், பார்த்தீர்கள்.
-
புள்ளிவிவரங்கள் கேள்விகளுக்கு பதிலளிக்க உதவுகின்றன. உங்களிடம் கேள்விகள் இருந்தால், நீங்கள் புள்ளிவிவரங்களுக்குத் திரும்புங்கள் - பாருங்கள், முடிவுகளை எடுக்கவும், முடிவுகளை பகுப்பாய்வு செய்யவும்.
-
மற்றும் பரிசோதனை. நிறைய கோரிக்கைகள், நிறைய தரவுகள் உள்ளன. ஏற்கனவே உள்ள வினவலை நீங்கள் எப்போதும் மேம்படுத்தலாம். அசல் கோரிக்கையை விட உங்களுக்கு மிகவும் பொருத்தமான கோரிக்கையின் உங்கள் சொந்த பதிப்பை உருவாக்கி அதைப் பயன்படுத்தலாம்.
குறிப்புகள்
கட்டுரையில் காணப்படும் பொருத்தமான இணைப்புகள், பொருட்களின் அடிப்படையில், அறிக்கையில் இருந்தன.
ஆசிரியர் மேலும் எழுதுங்கள்
(இங்கி)
புள்ளியியல் சேகரிப்பாளர்
கணினி நிர்வாக செயல்பாடுகள்
பங்களிப்பு தொகுதிகள்
SQL பயன்பாடுகள் மற்றும் sql குறியீடு எடுத்துக்காட்டுகள்
உங்கள் கவனத்திற்கு அனைவருக்கும் நன்றி!
ஆதாரம்: www.habr.com