PostgreSQL கண்காணிப்பின் அடிப்படைகள். அலெக்ஸி லெசோவ்ஸ்கி

Data Egret "PostgreSQL கண்காணிப்பின் அடிப்படைகள்" இலிருந்து அலெக்ஸி லெசோவ்ஸ்கியின் அறிக்கையின் டிரான்ஸ்கிரிப்டைப் படிக்க பரிந்துரைக்கிறேன்.

இந்த அறிக்கையில், அலெக்ஸி லெசோவ்ஸ்கி பிந்தைய முன்னேற்ற புள்ளிவிவரங்களின் முக்கிய புள்ளிகளைப் பற்றி பேசுவார், அவை எதைக் குறிக்கின்றன, அவை ஏன் கண்காணிப்பில் இருக்க வேண்டும்; கண்காணிப்பில் என்ன வரைபடங்கள் இருக்க வேண்டும், அவற்றை எவ்வாறு சேர்ப்பது மற்றும் அவற்றை எவ்வாறு விளக்குவது என்பது பற்றி. Postgres சரிசெய்தலில் ஆர்வமுள்ள தரவுத்தள நிர்வாகிகள், கணினி நிர்வாகிகள் மற்றும் டெவலப்பர்களுக்கு இந்த அறிக்கை பயனுள்ளதாக இருக்கும்.

எனது பெயர் அலெக்ஸி லெசோவ்ஸ்கி, நான் டேட்டா எக்ரெட் நிறுவனத்தை பிரதிநிதித்துவப்படுத்துகிறேன்.

என்னைப் பற்றி சில வார்த்தைகள். நான் ஒரு கணினி நிர்வாகியாக நீண்ட காலத்திற்கு முன்பு தொடங்கினேன்.

நான் பல்வேறு வகையான லினக்ஸ் அமைப்புகளை நிர்வகித்தேன், லினக்ஸ் தொடர்பான பல்வேறு விஷயங்களில் வேலை செய்தேன், அதாவது மெய்நிகராக்கம், கண்காணிப்பு, ப்ராக்ஸிகளுடன் பணிபுரிந்தேன். நான் அவரை மிகவும் விரும்பினேன். சில சமயங்களில் நான் எனது பெரும்பாலான வேலை நேரத்தில் PostgreSQL இல் வேலை செய்ய ஆரம்பித்தேன். அதனால் படிப்படியாக நான் PostgreSQL DBA ஆனேன்.

எனது தொழில் வாழ்க்கை முழுவதும், புள்ளியியல், கண்காணிப்பு மற்றும் டெலிமெட்ரி ஆகிய தலைப்புகளில் நான் எப்போதும் ஆர்வமாக இருந்தேன். நான் சிஸ்டம் அட்மினிஸ்ட்ரேட்டராக இருந்தபோது, ​​ஜாபிக்ஸுடன் மிக நெருக்கமாகப் பணியாற்றினேன். மற்றும் போன்ற சிறிய ஸ்கிரிப்ட்களை எழுதினேன் zabbix-நீட்டிப்புகள். அவர் காலத்தில் மிகவும் பிரபலமாக இருந்தார். லினக்ஸ் மட்டுமல்ல, பல்வேறு கூறுகளும் மிகவும் வேறுபட்ட முக்கியமான விஷயங்களைக் கண்காணிக்க முடிந்தது.

இப்போது நான் PostgreSQL இல் வேலை செய்கிறேன். PostgreSQL புள்ளிவிவரங்களுடன் பணிபுரிய உங்களை அனுமதிக்கும் மற்றொரு விஷயத்தை நான் ஏற்கனவே எழுதி வருகிறேன். அது அழைக்கபடுகிறது pgCenter (ஹப்ரே பற்றிய கட்டுரை - நரம்புகள் மற்றும் பதற்றம் இல்லாத பிந்தைய முன்னேற்ற புள்ளிவிவரங்கள்).

ஒரு சிறிய அறிமுகக் குறிப்பு. எங்கள் வாடிக்கையாளர்கள், எங்கள் வாடிக்கையாளர்களுக்கு என்ன சூழ்நிலைகள் உள்ளன? தரவுத்தளத்துடன் தொடர்புடைய ஒருவித விபத்து உள்ளது. தரவுத்தளம் ஏற்கனவே மீட்டெடுக்கப்பட்டவுடன், துறைத் தலைவர் அல்லது மேம்பாட்டுத் தலைவர் வந்து கூறுகிறார்: "நண்பர்களே, தரவுத்தளத்தை நாங்கள் கண்காணிக்க வேண்டும், ஏனென்றால் ஏதோ மோசமானது நடந்தது, எதிர்காலத்தில் இது நிகழாமல் தடுக்க வேண்டும்." ஒரு கண்காணிப்பு அமைப்பைத் தேர்ந்தெடுப்பது அல்லது ஏற்கனவே உள்ள கண்காணிப்பு அமைப்பைத் தழுவுவது போன்ற சுவாரஸ்யமான செயல்முறை இங்கே தொடங்குகிறது, இதன் மூலம் உங்கள் தரவுத்தளத்தை நீங்கள் கண்காணிக்க முடியும் - PostgreSQL, MySQL அல்லது வேறு சில. சகாக்கள் பரிந்துரைக்கத் தொடங்குகிறார்கள்: “இதுபோன்ற மற்றும் அத்தகைய தரவுத்தளம் இருப்பதாக நான் கேள்விப்பட்டேன். அதைப் பயன்படுத்துவோம்." சக ஊழியர்கள் ஒருவருக்கொருவர் வாதிடத் தொடங்குகிறார்கள். இறுதியில், நாங்கள் ஒருவித தரவுத்தளத்தைத் தேர்ந்தெடுக்கிறோம், ஆனால் PostgreSQL கண்காணிப்பு அதில் மிகவும் மோசமாக உள்ளது, மேலும் நாம் எப்போதும் ஏதாவது சேர்க்க வேண்டும். GitHub இலிருந்து சில களஞ்சியங்களை எடுத்து, அவற்றை குளோன் செய்யவும், ஸ்கிரிப்ட்களை மாற்றியமைக்கவும், எப்படியாவது தனிப்பயனாக்கவும். இறுதியில் அது ஒருவித கையேடு வேலையாக முடிகிறது.

எனவே, இந்தப் பேச்சில், PostgreSQL க்கு மட்டுமல்ல, தரவுத்தளத்திற்கும் கண்காணிப்பை எவ்வாறு தேர்வு செய்வது என்பது பற்றிய சில அறிவை உங்களுக்கு வழங்க முயற்சிக்கிறேன். மேலும் வரவிருக்கும் அவசரகால சூழ்நிலைகளை உடனடியாகத் தடுக்க, உங்கள் தரவுத்தளத்தை நன்மையுடன் கண்காணிக்கும் வகையில், உங்கள் கண்காணிப்பை நிறைவுசெய்ய அனுமதிக்கும் அறிவை உங்களுக்கு வழங்கவும்.

மேலும் இந்த அறிக்கையில் இருக்கும் யோசனைகள் DBMS அல்லது noSQL என எந்த தரவுத்தளத்திற்கும் நேரடியாக மாற்றியமைக்கப்படலாம். எனவே, PostgreSQL மட்டும் இல்லை, ஆனால் PostgreSQL இல் இதை எப்படி செய்வது என்பது குறித்து பல சமையல் குறிப்புகள் இருக்கும். வினவல்களின் எடுத்துக்காட்டுகள், PostgreSQL கண்காணிக்கும் நிறுவனங்களின் எடுத்துக்காட்டுகள் இருக்கும். உங்கள் டிபிஎம்எஸ்ஸில் அதே விஷயங்கள் இருந்தால், அவற்றை கண்காணிப்பில் வைக்க அனுமதிக்கலாம், நீங்கள் அவற்றை மாற்றியமைக்கலாம், அவற்றைச் சேர்க்கலாம், அது நன்றாக இருக்கும்.

நான் அறிக்கையில் இருக்க மாட்டேன்
அளவீடுகளை எவ்வாறு வழங்குவது மற்றும் சேமிப்பது என்பது பற்றி பேசுங்கள். தரவை பிந்தைய செயலாக்கம் மற்றும் பயனருக்கு வழங்குவது பற்றி நான் எதுவும் கூறமாட்டேன். எச்சரிக்கை செய்வது பற்றி நான் எதுவும் சொல்ல மாட்டேன்.
ஆனால் கதை முன்னேறும்போது, ​​ஏற்கனவே இருக்கும் கண்காணிப்பின் வெவ்வேறு ஸ்கிரீன் ஷாட்களைக் காட்டி எப்படியாவது விமர்சிப்பேன். ஆயினும்கூட, இந்த தயாரிப்புகளுக்கு விளம்பரம் அல்லது எதிர்ப்பு விளம்பரங்களை உருவாக்காதபடி பிராண்டுகளுக்கு பெயரிட வேண்டாம். எனவே, அனைத்து தற்செயல்களும் சீரற்றவை மற்றும் உங்கள் கற்பனைக்கு விடப்படுகின்றன.

முதலில், கண்காணிப்பு என்றால் என்ன என்பதைக் கண்டுபிடிப்போம். கண்காணிப்பு என்பது மிக முக்கியமான விஷயம். இதை அனைவரும் புரிந்துகொள்கிறார்கள். ஆனால் அதே நேரத்தில், கண்காணிப்பு ஒரு வணிக தயாரிப்புடன் தொடர்புடையது அல்ல மற்றும் நிறுவனத்தின் லாபத்தை நேரடியாகப் பாதிக்காது, எனவே எஞ்சிய அடிப்படையில் கண்காணிக்க எப்போதும் நேரம் ஒதுக்கப்படுகிறது. எங்களுக்கு நேரம் இருந்தால், நாங்கள் கண்காணிப்போம்; எங்களுக்கு நேரம் இல்லையென்றால், சரி, நாங்கள் அதை பேக்லாக்கில் வைப்போம், ஒருநாள் இந்த பணிகளுக்குத் திரும்புவோம்.

எனவே, எங்கள் நடைமுறையில் இருந்து, நாங்கள் வாடிக்கையாளர்களிடம் வரும்போது, ​​கண்காணிப்பு பெரும்பாலும் முழுமையடையாது மற்றும் தரவுத்தளத்தில் சிறப்பாக செயல்பட உதவும் சுவாரஸ்யமான விஷயங்கள் எதுவும் இல்லை. எனவே கண்காணிப்பு எப்போதும் முடிக்கப்பட வேண்டும்.

தரவுத்தளங்கள் மிகவும் சிக்கலான விஷயங்கள், அவை கண்காணிக்கப்பட வேண்டும், ஏனெனில் தரவுத்தளங்கள் தகவல்களின் களஞ்சியமாகும். நிறுவனத்திற்கு தகவல் மிகவும் முக்கியமானது; அதை எந்த வகையிலும் இழக்க முடியாது. ஆனால் அதே நேரத்தில், தரவுத்தளங்கள் மிகவும் சிக்கலான மென்பொருளாகும். அவை அதிக எண்ணிக்கையிலான கூறுகளைக் கொண்டிருக்கின்றன. மேலும் இந்த கூறுகளில் பலவற்றை கண்காணிக்க வேண்டும்.

நாம் குறிப்பாக PostgreSQL பற்றி பேசுகிறோம் என்றால், அது ஒரு பெரிய எண்ணிக்கையிலான கூறுகளைக் கொண்ட ஒரு திட்டத்தின் வடிவத்தில் குறிப்பிடப்படலாம். இந்த கூறுகள் ஒருவருக்கொருவர் தொடர்பு கொள்கின்றன. அதே நேரத்தில், PostgreSQL ஆனது புள்ளிவிவர சேகரிப்பு துணை அமைப்பு என்று அழைக்கப்படுவதைக் கொண்டுள்ளது, இது இந்த துணை அமைப்புகளின் செயல்பாட்டைப் பற்றிய புள்ளிவிவரங்களைச் சேகரிக்கவும், நிர்வாகி அல்லது பயனருக்கு ஒருவித இடைமுகத்தை வழங்கவும் உங்களை அனுமதிக்கிறது, இதனால் அவர் இந்த புள்ளிவிவரங்களைப் பார்க்க முடியும்.

இந்த புள்ளிவிவரங்கள் ஒரு குறிப்பிட்ட செயல்பாடுகள் மற்றும் பார்வைகளின் வடிவத்தில் வழங்கப்படுகின்றன. அவற்றை அட்டவணைகள் என்றும் அழைக்கலாம். அதாவது, வழக்கமான psql கிளையண்டைப் பயன்படுத்தி, நீங்கள் தரவுத்தளத்துடன் இணைக்கலாம், இந்த செயல்பாடுகள் மற்றும் பார்வைகளைத் தேர்ந்தெடுத்து, PostgreSQL துணை அமைப்புகளின் செயல்பாட்டைப் பற்றி சில குறிப்பிட்ட எண்களைப் பெறலாம்.

இந்த எண்களை உங்களுக்கு பிடித்த கண்காணிப்பு அமைப்பில் சேர்க்கலாம், வரைபடங்களை வரையலாம், செயல்பாடுகளைச் சேர்க்கலாம் மற்றும் நீண்ட காலத்திற்கு பகுப்பாய்வுகளைப் பெறலாம்.

ஆனால் இந்த அறிக்கையில் நான் இந்த செயல்பாடுகளை முழுவதுமாக மறைக்க மாட்டேன், ஏனென்றால் அதற்கு முழு நாள் ஆகலாம். நான் உண்மையில் இரண்டு, மூன்று அல்லது நான்கு விஷயங்களைக் குறிப்பிடுவேன், மேலும் அவை எவ்வாறு கண்காணிப்பை சிறப்பாகச் செய்ய உதவுகின்றன என்பதை உங்களுக்குச் சொல்வேன்.

தரவுத்தள கண்காணிப்பு பற்றி நாம் பேசினால், என்ன கண்காணிக்க வேண்டும்? முதலில், நாம் கிடைப்பதைக் கண்காணிக்க வேண்டும், ஏனெனில் தரவுத்தளம் என்பது வாடிக்கையாளர்களுக்கு தரவுக்கான அணுகலை வழங்கும் ஒரு சேவையாகும், மேலும் நாம் கிடைப்பதைக் கண்காணிக்க வேண்டும், மேலும் அதன் சில தரமான மற்றும் அளவு பண்புகளையும் வழங்க வேண்டும்.

எங்கள் தரவுத்தளத்துடன் இணைக்கும் வாடிக்கையாளர்களையும் நாங்கள் கண்காணிக்க வேண்டும், ஏனெனில் அவர்கள் சாதாரண வாடிக்கையாளர்களாகவும், தரவுத்தளத்திற்கு தீங்கு விளைவிக்கும் தீங்கு விளைவிக்கும் வாடிக்கையாளர்களாகவும் இருக்கலாம். அவர்களையும் கண்காணிக்க வேண்டும் மற்றும் அவர்களின் செயல்பாடுகள் கண்காணிக்கப்பட வேண்டும்.

வாடிக்கையாளர்கள் தரவுத்தளத்துடன் இணைக்கும்போது, ​​​​அவர்கள் எங்கள் தரவுடன் வேலை செய்யத் தொடங்குகிறார்கள் என்பது தெளிவாகிறது, எனவே வாடிக்கையாளர்கள் தரவுகளுடன் எவ்வாறு செயல்படுகிறார்கள் என்பதை நாங்கள் கண்காணிக்க வேண்டும்: எந்த அட்டவணைகள், மற்றும் குறைந்த அளவிற்கு, எந்த குறியீடுகளுடன். அதாவது, எங்கள் வாடிக்கையாளர்களால் உருவாக்கப்படும் பணிச்சுமையை மதிப்பீடு செய்ய வேண்டும்.

ஆனால் பணிச்சுமை, நிச்சயமாக, கோரிக்கைகளைக் கொண்டுள்ளது. பயன்பாடுகள் தரவுத்தளத்துடன் இணைகின்றன, வினவல்களைப் பயன்படுத்தி தரவை அணுகுகின்றன, எனவே தரவுத்தளத்தில் உள்ள வினவல்களை மதிப்பீடு செய்வது, அவற்றின் போதுமான தன்மையைக் கண்காணிப்பது, அவை வக்கிரமாக எழுதப்படவில்லை, சில விருப்பங்களை மீண்டும் எழுத வேண்டும், அவை விரைவாக வேலை செய்ய வேண்டும். மற்றும் சிறந்த செயல்திறனுடன்.

நாம் ஒரு தரவுத்தளத்தைப் பற்றி பேசுவதால், தரவுத்தளம் எப்போதும் பின்னணி செயல்முறைகளாகும். பின்னணி செயல்முறைகள் தரவுத்தள செயல்திறனை ஒரு நல்ல மட்டத்தில் பராமரிக்க உதவுகின்றன, எனவே அவை செயல்படுவதற்கு ஒரு குறிப்பிட்ட அளவு ஆதாரங்கள் தேவைப்படுகின்றன. அதே நேரத்தில், அவை கிளையன்ட் கோரிக்கை ஆதாரங்களுடன் ஒன்றுடன் ஒன்று சேரலாம், எனவே பேராசை கொண்ட பின்னணி செயல்முறைகள் கிளையன்ட் கோரிக்கைகளின் செயல்திறனை நேரடியாக பாதிக்கலாம். எனவே, பின்னணி செயல்முறைகளின் அடிப்படையில் எந்த சிதைவுகளும் ஏற்படாதவாறு அவை கண்காணிக்கப்பட்டு கண்காணிக்கப்பட வேண்டும்.

தரவுத்தள கண்காணிப்பின் அடிப்படையில் இவை அனைத்தும் கணினி மெட்ரிக்கில் உள்ளது. ஆனால் எங்கள் உள்கட்டமைப்பில் பெரும்பாலானவை மேகங்களுக்கு நகர்கின்றன என்பதைக் கருத்தில் கொண்டு, ஒரு தனிப்பட்ட ஹோஸ்டின் கணினி அளவீடுகள் எப்போதும் பின்னணியில் மங்கிவிடும். ஆனால் தரவுத்தளங்களில் அவை இன்னும் பொருத்தமானவை, நிச்சயமாக, கணினி அளவீடுகளை கண்காணிப்பதும் அவசியம்.

கணினி அளவீடுகளுடன் எல்லாம் அதிகமாகவோ அல்லது குறைவாகவோ நன்றாக உள்ளது, அனைத்து நவீன கண்காணிப்பு அமைப்புகளும் ஏற்கனவே இந்த அளவீடுகளை ஆதரிக்கின்றன, ஆனால் பொதுவாக, சில கூறுகள் இன்னும் போதுமானதாக இல்லை மற்றும் சில விஷயங்களைச் சேர்க்க வேண்டும். நான் அவற்றைத் தொடுவேன், அவற்றைப் பற்றி பல ஸ்லைடுகள் இருக்கும்.

திட்டத்தின் முதல் புள்ளி அணுகல். அணுகல்தன்மை என்றால் என்ன? எனது புரிதலில் கிடைக்கும் என்பது சேவை இணைப்புகளுக்கான தளத்தின் திறன், அதாவது அடிப்படை உயர்த்தப்பட்டது, இது ஒரு சேவையாக, வாடிக்கையாளர்களிடமிருந்து இணைப்புகளை ஏற்றுக்கொள்கிறது. இந்த அணுகல் தன்மையை சில குணாதிசயங்களால் மதிப்பிட முடியும். இந்த பண்புகளை டாஷ்போர்டில் காட்டுவது மிகவும் வசதியானது.

டாஷ்போர்டுகள் என்றால் என்ன என்பது அனைவருக்கும் தெரியும். தேவையான தகவல்கள் தொகுக்கப்பட்டுள்ள திரையில் நீங்கள் ஒரு முறை பார்த்தீர்கள். தரவுத்தளத்தில் ஏதேனும் சிக்கல் உள்ளதா இல்லையா என்பதை நீங்கள் உடனடியாக தீர்மானிக்க முடியும்.
அதன்படி, தரவுத்தளத்தின் கிடைக்கும் தன்மை மற்றும் பிற முக்கிய குணாதிசயங்கள் எப்போதும் டாஷ்போர்டில் காட்டப்பட வேண்டும், இதனால் இந்த தகவல் உங்களிடம் உள்ளது மற்றும் உங்களுக்கு எப்போதும் கிடைக்கும். சம்பவங்களின் விசாரணையில் ஏற்கனவே உதவும் சில கூடுதல் விவரங்கள், சில அவசரகால சூழ்நிலைகளை விசாரிக்கும் போது, ​​அவை ஏற்கனவே இரண்டாம் நிலை டாஷ்போர்டுகளில் வைக்கப்பட வேண்டும் அல்லது மூன்றாம் தரப்பு கண்காணிப்பு அமைப்புகளுக்கு வழிவகுக்கும் டிரில் டவுன் இணைப்புகளில் மறைக்கப்பட வேண்டும்.

ஒரு நன்கு அறியப்பட்ட கண்காணிப்பு அமைப்பின் எடுத்துக்காட்டு. இது மிகவும் அருமையான கண்காணிப்பு அமைப்பு. அவள் நிறைய தரவுகளை சேகரிக்கிறாள், ஆனால் என் பார்வையில், டாஷ்போர்டுகள் பற்றிய ஒரு விசித்திரமான கருத்து அவளுக்கு உள்ளது. "டாஷ்போர்டை உருவாக்க" ஒரு இணைப்பு உள்ளது. ஆனால் நீங்கள் ஒரு டாஷ்போர்டை உருவாக்கும்போது, ​​​​நீங்கள் இரண்டு நெடுவரிசைகளின் பட்டியலை, வரைபடங்களின் பட்டியலை உருவாக்குகிறீர்கள். நீங்கள் எதையாவது பார்க்க வேண்டியிருக்கும் போது, ​​நீங்கள் சுட்டியைக் கிளிக் செய்யவும், ஸ்க்ரோலிங் செய்யவும், விரும்பிய விளக்கப்படத்தைத் தேடவும். இதற்கு நேரம் எடுக்கும், அதாவது டாஷ்போர்டுகள் எதுவும் இல்லை. விளக்கப்படங்களின் பட்டியல்கள் மட்டுமே உள்ளன.

இந்த டாஷ்போர்டுகளில் என்ன சேர்க்க வேண்டும்? மறுமொழி நேரம் போன்ற ஒரு பண்புடன் நீங்கள் தொடங்கலாம். PostgreSQL pg_stat_statements காட்சியைக் கொண்டுள்ளது. இது இயல்பாகவே முடக்கப்பட்டுள்ளது, ஆனால் இது எப்போதும் இயக்கப்பட்டு பயன்படுத்தப்பட வேண்டிய முக்கியமான கணினி காட்சிகளில் ஒன்றாகும். தரவுத்தளத்தில் செயல்படுத்தப்பட்ட அனைத்து இயங்கும் வினவல்கள் பற்றிய தகவலை இது சேமிக்கிறது.

அதன்படி, எல்லா கோரிக்கைகளின் மொத்த செயலாக்க நேரத்தையும், மேலே உள்ள புலங்களைப் பயன்படுத்தி கோரிக்கைகளின் எண்ணிக்கையால் வகுக்க முடியும் என்பதிலிருந்து தொடங்கலாம். ஆனால் இது மருத்துவமனையில் சராசரி வெப்பநிலை. நாம் மற்ற துறைகளில் இருந்து தொடங்கலாம் - குறைந்தபட்ச வினவல் செயல்படுத்தும் நேரம், அதிகபட்சம் மற்றும் இடைநிலை. நாம் சதவீதங்களை கூட உருவாக்க முடியும்; PostgreSQL இதற்கு தொடர்புடைய செயல்பாடுகளைக் கொண்டுள்ளது. ஏற்கனவே பூர்த்தி செய்யப்பட்ட கோரிக்கைகளுக்கான எங்கள் தரவுத்தளத்தின் பதிலளிப்பு நேரத்தை வகைப்படுத்தும் சில எண்களைப் பெறலாம், அதாவது 'செலக்ட் 1' என்ற போலி கோரிக்கையை நாங்கள் செயல்படுத்த மாட்டோம் மற்றும் மறுமொழி நேரத்தைப் பார்க்கிறோம், ஆனால் ஏற்கனவே முடிக்கப்பட்ட கோரிக்கைகளுக்கான மறுமொழி நேரத்தை பகுப்பாய்வு செய்து வரைகிறோம். ஒரு தனி உருவம், அல்லது அதன் அடிப்படையில் ஒரு வரைபடத்தை உருவாக்குவோம்.

கணினியால் தற்போது உருவாக்கப்படும் பிழைகளின் எண்ணிக்கையைக் கண்காணிப்பதும் முக்கியம். இதற்கு நீங்கள் pg_stat_database காட்சியைப் பயன்படுத்தலாம். நாங்கள் xact_rollback புலத்தில் கவனம் செலுத்துகிறோம். இந்த புலம் தரவுத்தளத்தில் நிகழும் ரோல்பேக்குகளின் எண்ணிக்கையை மட்டும் காட்டுகிறது, ஆனால் பிழைகளின் எண்ணிக்கையையும் கணக்கில் எடுத்துக்கொள்கிறது. ஒப்பீட்டளவில் பேசினால், இந்த எண்ணிக்கையை எங்கள் டாஷ்போர்டில் காட்டலாம் மற்றும் தற்போது எத்தனை பிழைகள் உள்ளன என்பதைப் பார்க்கலாம். நிறைய பிழைகள் இருந்தால், பதிவுகளைப் பார்த்து, அவை என்ன வகையான பிழைகள் மற்றும் அவை ஏன் ஏற்படுகின்றன என்பதைப் பார்க்கவும், பின்னர் முதலீடு செய்து அவற்றைத் தீர்க்கவும் இது ஒரு நல்ல காரணம்.

டேகோமீட்டர் போன்ற ஒன்றை நீங்கள் சேர்க்கலாம். இவை ஒரு வினாடிக்கான பரிவர்த்தனைகளின் எண்ணிக்கை மற்றும் வினாடிக்கு கோரிக்கைகளின் எண்ணிக்கை. ஒப்பீட்டளவில், இந்த எண்களை உங்கள் தரவுத்தளத்தின் தற்போதைய செயல்திறனாகப் பயன்படுத்தலாம் மற்றும் கோரிக்கைகளில் உச்சங்கள் உள்ளதா, பரிவர்த்தனைகளில் உச்சங்கள் உள்ளதா அல்லது அதற்கு மாறாக, சில பின்தளத்தில் தோல்வியுற்றதால் தரவுத்தளம் குறைவாக உள்ளதா என்பதைக் கண்காணிக்கலாம். இந்த எண்ணிக்கையை எப்போதும் பார்த்து, எங்கள் திட்டத்திற்கு இந்த வகையான செயல்திறன் இயல்பானது என்பதை நினைவில் கொள்வது அவசியம், ஆனால் மேலேயும் கீழேயும் உள்ள மதிப்புகள் ஏற்கனவே ஒருவித சிக்கலான மற்றும் புரிந்துகொள்ள முடியாதவை, அதாவது இந்த எண்கள் ஏன் என்று நாம் பார்க்க வேண்டும். மிகவும் அதிகம்.

பரிவர்த்தனைகளின் எண்ணிக்கையைக் கணக்கிட, pg_stat_database காட்சியைப் பார்க்கவும். நாம் கமிட்களின் எண்ணிக்கை மற்றும் திரும்பப் பெறுதல்களின் எண்ணிக்கையைச் சேர்த்து, ஒரு வினாடிக்கு எவ்வளவு பரிவர்த்தனைகளின் எண்ணிக்கையைப் பெறலாம்.

ஒரு பரிவர்த்தனைக்கு பல கோரிக்கைகள் பொருந்தும் என்பதை அனைவரும் புரிந்துகொள்கிறார்களா? எனவே டிபிஎஸ் மற்றும் கியூபிஎஸ் சற்று வித்தியாசமானது.

ஒரு வினாடிக்கான கோரிக்கைகளின் எண்ணிக்கையை 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 புலங்கள் உள்ளன. அவை, ஒப்பீட்டளவில், பரிவர்த்தனையின் தொடக்க நேரத்தையும் கோரிக்கையின் தொடக்க நேரத்தையும் காட்டுகின்றன. தற்போதைய நேர முத்திரையைக் காட்டும் now() செயல்பாட்டை நாங்கள் எடுத்துக்கொள்கிறோம், மேலும் பரிவர்த்தனை மற்றும் கோரிக்கை நேர முத்திரையைக் கழிக்கவும். பரிவர்த்தனையின் காலம், கோரிக்கையின் காலம் ஆகியவற்றைப் பெறுகிறோம்.

நீண்ட பரிவர்த்தனைகளைக் கண்டால், அவற்றை ஏற்கனவே முடிக்க வேண்டும். OLTP சுமைக்கு, நீண்ட பரிவர்த்தனைகள் ஏற்கனவே 1-2-3 நிமிடங்களுக்கு மேல் ஆகும். OLAP பணிச்சுமைக்கு, நீண்ட பரிவர்த்தனைகள் இயல்பானவை, ஆனால் அவை முடிவடைய இரண்டு மணி நேரத்திற்கும் மேலாக எடுத்துக் கொண்டால், இதுவும் எங்காவது ஒரு வளைந்திருப்பதற்கான அறிகுறியாகும்.

வாடிக்கையாளர்கள் தரவுத்தளத்துடன் இணைந்தவுடன், அவர்கள் எங்கள் தரவுடன் வேலை செய்யத் தொடங்குவார்கள். அவர்கள் அட்டவணைகளை அணுகுகிறார்கள், அட்டவணையில் இருந்து தரவைப் பெற அவர்கள் குறியீடுகளை அணுகுகிறார்கள். இந்த தரவுகளுடன் வாடிக்கையாளர்கள் எவ்வாறு தொடர்பு கொள்கிறார்கள் என்பதை மதிப்பீடு செய்வது முக்கியம்.

எங்கள் பணிச்சுமையை மதிப்பிடுவதற்கும், எந்த அட்டவணைகள் எங்களுக்கு "வெப்பமானவை" என்பதை தோராயமாக புரிந்துகொள்வதற்கும் இது அவசியம். எடுத்துக்காட்டாக, சில வகையான வேகமான SSD சேமிப்பகத்தில் "ஹாட்" அட்டவணைகளை வைக்க விரும்பும் சூழ்நிலைகளில் இது தேவைப்படுகிறது. எடுத்துக்காட்டாக, நாங்கள் நீண்ட காலமாகப் பயன்படுத்தாத சில காப்பக அட்டவணைகள் ஒருவித "குளிர்" காப்பகத்திற்கு, SATA டிரைவ்களுக்கு நகர்த்தப்பட்டு, அவற்றை அங்கு வாழ அனுமதிக்கலாம், அவை தேவைக்கேற்ப அணுகப்படும்.

ஏதேனும் வெளியீடுகள் மற்றும் வரிசைப்படுத்தல்களுக்குப் பிறகு முரண்பாடுகளைக் கண்டறிவதற்கும் இது பயனுள்ளதாக இருக்கும். திட்டம் சில புதிய அம்சங்களை வெளியிட்டுள்ளது என்று வைத்துக் கொள்வோம். எடுத்துக்காட்டாக, தரவுத்தளத்துடன் பணிபுரிய புதிய செயல்பாட்டைச் சேர்த்துள்ளோம். மேலும் டேபிள் யூஸ் கிராஃப்களை ப்ளாட் செய்தால், இந்த வரைபடங்களில் இந்த முரண்பாடுகளை எளிதாகக் கண்டறியலாம். எடுத்துக்காட்டாக, வெடிப்புகளைப் புதுப்பிக்கவும் அல்லது வெடிப்புகளை நீக்கவும். இது மிகவும் புலப்படும்.

"மிதக்கும்" புள்ளிவிவரங்களில் உள்ள முரண்பாடுகளையும் நீங்கள் கண்டறியலாம். இதற்கு என்ன அர்த்தம்? PostgreSQL மிகவும் வலுவான மற்றும் நல்ல வினவல் திட்டமிடலைக் கொண்டுள்ளது. டெவலப்பர்கள் அதன் வளர்ச்சிக்கு நிறைய நேரம் ஒதுக்குகிறார்கள். அவர் எப்படி வேலை செய்கிறார்? நல்ல திட்டங்களை உருவாக்க, PostgreSQL ஆனது குறிப்பிட்ட கால இடைவெளியில் மற்றும் ஒரு குறிப்பிட்ட அதிர்வெண்ணுடன் அட்டவணையில் தரவு விநியோகம் பற்றிய புள்ளிவிவரங்களை சேகரிக்கிறது. இவை மிகவும் பொதுவான மதிப்புகள்: தனிப்பட்ட மதிப்புகளின் எண்ணிக்கை, அட்டவணையில் NULL பற்றிய தகவல்கள், நிறைய தகவல்கள்.

இந்த புள்ளிவிவரங்களின் அடிப்படையில், திட்டமிடுபவர் பல வினவல்களை உருவாக்கி, மிகவும் உகந்த ஒன்றைத் தேர்ந்தெடுத்து, வினவலைச் செயல்படுத்தவும், தரவை வழங்கவும் இந்த வினவல் திட்டத்தைப் பயன்படுத்துகிறார்.

புள்ளிவிவரங்கள் "மிதவை" என்று நடக்கும். தரம் மற்றும் அளவு தரவு எப்படியோ அட்டவணையில் மாற்றப்பட்டது, ஆனால் புள்ளிவிவரங்கள் சேகரிக்கப்படவில்லை. மேலும் உருவாக்கப்பட்ட திட்டங்கள் உகந்ததாக இருக்காது. அட்டவணைகளின் அடிப்படையில் சேகரிக்கப்பட்ட கண்காணிப்பின் அடிப்படையில் எங்கள் திட்டங்கள் துணைநிலையாக மாறினால், இந்த முரண்பாடுகளை நாம் காண முடியும். எடுத்துக்காட்டாக, எங்காவது தரவு தரமானதாக மாறியது மற்றும் குறியீட்டுக்குப் பதிலாக, அட்டவணையின் வழியாக ஒரு வரிசையான பாஸ் பயன்படுத்தத் தொடங்கியது, அதாவது. ஒரு வினவல் 100 வரிசைகளை மட்டுமே வழங்க வேண்டும் என்றால் (100 வரம்பு உள்ளது), இந்த வினவலுக்கான முழுமையான தேடல் செய்யப்படும். இது எப்போதும் செயல்திறனில் மிகவும் மோசமான விளைவைக் கொண்டிருக்கிறது.

இதை நாம் கண்காணிப்பில் காணலாம். ஏற்கனவே இந்த வினவலைப் பார்த்து, அதற்கான விளக்கத்தை இயக்கவும், புள்ளிவிவரங்களைச் சேகரிக்கவும், புதிய கூடுதல் குறியீட்டை உருவாக்கவும். ஏற்கனவே இந்த பிரச்சனைக்கு பதிலளிக்கவும். அதனால அது முக்கியம்.

கண்காணிப்புக்கு மற்றொரு எடுத்துக்காட்டு. அவர் மிகவும் பிரபலமானவர் என்பதால் பலர் அவரை அடையாளம் கண்டுகொண்டார்கள் என்று நினைக்கிறேன். யார் அதை தங்கள் திட்டங்களில் பயன்படுத்துகிறார்கள் பிரமீதீயஸ்? ப்ரோமிதியஸுடன் இணைந்து இந்த தயாரிப்பை யார் பயன்படுத்துகிறார்கள்? உண்மை என்னவென்றால், இந்த கண்காணிப்பின் நிலையான களஞ்சியத்தில் PostgreSQL உடன் பணிபுரிய ஒரு டாஷ்போர்டு உள்ளது - postgres_exporter ப்ரோமிதியஸ். ஆனால் ஒரு மோசமான விவரம் உள்ளது.

பல வரைபடங்கள் உள்ளன. பைட்டுகள் ஒற்றுமையாகக் குறிக்கப்படுகின்றன, அதாவது 5 வரைபடங்கள் உள்ளன. டேட்டாவைச் செருகுதல், தரவைப் புதுப்பித்தல், தரவை நீக்குதல், தரவைப் பெறுதல் மற்றும் தரவைத் திரும்பப் பெறுதல் ஆகியவை ஆகும். அலகு அளவீடு பைட்டுகள். ஆனால் விஷயம் என்னவென்றால், PostgreSQL இல் உள்ள புள்ளிவிவரங்கள் tuple (வரிசைகளில்) தரவை வழங்குகிறது. மேலும், அதன்படி, இந்த வரைபடங்கள் உங்கள் பணிச்சுமையை பல முறை, பல்லாயிரக்கணக்கான முறை குறைத்து மதிப்பிடுவதற்கான மிகச் சிறந்த வழியாகும், ஏனெனில் ஒரு டூப்பிள் ஒரு பைட் அல்ல, ஒரு ட்யூப்பிள் ஒரு சரம், இது பல பைட்டுகள் மற்றும் அது எப்போதும் மாறி நீளமாக இருக்கும். அதாவது, டூப்பிள்களைப் பயன்படுத்தி பைட்டுகளில் பணிச்சுமையைக் கணக்கிடுவது ஒரு நம்பத்தகாத பணி அல்லது மிகவும் கடினம். எனவே, நீங்கள் டாஷ்போர்டை அல்லது உள்ளமைக்கப்பட்ட கண்காணிப்பைப் பயன்படுத்தும் போது, ​​அது சரியாகச் செயல்படுவதையும், சரியாக மதிப்பிடப்பட்ட தரவை உங்களுக்குத் தருவதையும் எப்போதும் புரிந்துகொள்வது அவசியம்.

இந்த அட்டவணையில் புள்ளிவிவரங்களைப் பெறுவது எப்படி? இந்த நோக்கத்திற்காக, PostgreSQL ஒரு குறிப்பிட்ட குடும்பக் காட்சிகளைக் கொண்டுள்ளது. மற்றும் முக்கிய பார்வை pg_stat_user_tables. பயனர்_அட்டவணைகள் - இதன் பொருள் பயனரின் சார்பாக உருவாக்கப்பட்ட அட்டவணைகள். இதற்கு மாறாக, PostgreSQL ஆல் பயன்படுத்தப்படும் கணினி காட்சிகள் உள்ளன. மற்றும் ஒரு சுருக்க அட்டவணை Alltables உள்ளது, இதில் கணினி மற்றும் பயனர் இரண்டும் அடங்கும். அவற்றில் உங்களுக்கு மிகவும் பிடித்தமானவற்றிலிருந்து நீங்கள் தொடங்கலாம்.

மேலே உள்ள புலங்களைப் பயன்படுத்தி, செருகல்கள், புதுப்பிப்புகள் மற்றும் நீக்குதல்களின் எண்ணிக்கையை நீங்கள் மதிப்பிடலாம். நான் பயன்படுத்திய டாஷ்போர்டின் உதாரணம், பணிச்சுமையின் பண்புகளை மதிப்பிடுவதற்கு இந்தப் புலங்களைப் பயன்படுத்துகிறது. எனவே, நாமும் அவற்றைக் கட்டியெழுப்பலாம். ஆனால் இவை டூப்பிள்கள், பைட்டுகள் அல்ல என்பதை நினைவில் கொள்வது மதிப்பு, எனவே நாம் அதை பைட்டுகளில் செய்ய முடியாது.

இந்தத் தரவின் அடிப்படையில், TopN அட்டவணைகள் என்று அழைக்கப்படுவதை நாம் உருவாக்கலாம். உதாரணமாக, டாப்-5, டாப்-10. மற்றவர்களை விட மறுசுழற்சி செய்யப்பட்ட சூடான அட்டவணைகளை நீங்கள் கண்காணிக்கலாம். உதாரணமாக, செருகுவதற்கு 5 "சூடான" அட்டவணைகள். இந்த TopN அட்டவணைகளைப் பயன்படுத்தி, நாங்கள் எங்கள் பணிச்சுமையை மதிப்பிடுகிறோம், மேலும் ஏதேனும் வெளியீடுகள், புதுப்பிப்புகள் மற்றும் வரிசைப்படுத்தல்களுக்குப் பிறகு பணிச்சுமையின் வெடிப்புகளை மதிப்பீடு செய்யலாம்.

அட்டவணையின் அளவை மதிப்பிடுவதும் முக்கியம், ஏனென்றால் சில நேரங்களில் டெவலப்பர்கள் ஒரு புதிய அம்சத்தை வெளியிடுகிறார்கள், மேலும் எங்கள் அட்டவணைகள் அவற்றின் பெரிய அளவுகளில் வீங்கத் தொடங்குகின்றன, ஏனெனில் அவர்கள் கூடுதல் தரவுகளைச் சேர்க்க முடிவு செய்தனர், ஆனால் இது எப்படி இருக்கும் என்று கணிக்கவில்லை. தரவுத்தளத்தின் அளவை பாதிக்கும். இது போன்ற சம்பவங்களும் நமக்கு ஆச்சரியத்தை ஏற்படுத்துகின்றன.

இப்போது உங்களுக்கு ஒரு சிறிய கேள்வி. உங்கள் தரவுத்தள சேவையகத்தில் ஏற்றத்தை நீங்கள் கவனிக்கும்போது என்ன கேள்வி எழுகிறது? அடுத்த கேள்வி என்ன?

ஆனால் உண்மையில் கேள்வி பின்வருமாறு எழுகிறது. சுமை என்ன கோரிக்கைகளை ஏற்படுத்துகிறது? அதாவது, சுமையால் ஏற்படும் செயல்முறைகளைப் பார்ப்பது சுவாரஸ்யமானது அல்ல. ஹோஸ்டுக்கு ஒரு தரவுத்தளம் இருந்தால், தரவுத்தளம் அங்கு இயங்குகிறது என்பது தெளிவாகிறது, மேலும் தரவுத்தளங்கள் மட்டுமே அங்கு அகற்றப்படும் என்பது தெளிவாகிறது. நாம் Topஐத் திறந்தால், PostgreSQL இல் ஏதாவது செய்யும் செயல்முறைகளின் பட்டியலைக் காண்போம். அவர்கள் என்ன செய்கிறார்கள் என்பது மேலிடத்திலிருந்து தெளிவாக இருக்காது.

அதன்படி, அதிக சுமையை ஏற்படுத்தும் வினவல்களை நீங்கள் கண்டுபிடிக்க வேண்டும், ஏனெனில் டியூனிங் வினவல்கள், ஒரு விதியாக, PostgreSQL அல்லது இயக்க முறைமை உள்ளமைவை சரிசெய்வதை விட அல்லது வன்பொருளை சரிசெய்வதை விட அதிக லாபத்தை அளிக்கிறது. எனது மதிப்பீட்டின்படி, இது தோராயமாக 80-85-90% ஆகும். மேலும் இது மிக வேகமாக செய்யப்படுகிறது. உள்ளமைவை சரிசெய்வதை விட கோரிக்கையை சரிசெய்வது, மறுதொடக்கத்தை திட்டமிடுவது, குறிப்பாக தரவுத்தளத்தை மறுதொடக்கம் செய்ய முடியாவிட்டால் அல்லது வன்பொருளைச் சேர்ப்பது வேகமானது. இந்த வினவலிலிருந்து சிறந்த முடிவைப் பெற, வினவலை எங்காவது மீண்டும் எழுதுவது அல்லது குறியீட்டைச் சேர்ப்பது எளிது.

அதன்படி, கோரிக்கைகள் மற்றும் அவற்றின் போதுமான தன்மையைக் கண்காணிப்பது அவசியம். கண்காணிப்பின் மற்றொரு உதாரணத்தை எடுத்துக் கொள்வோம். இங்கும் சிறந்த கண்காணிப்பு இருப்பதாக தெரிகிறது. நகலெடுப்பு பற்றிய தகவல் உள்ளது, செயல்திறன், தடுப்பு, வள பயன்பாடு பற்றிய தகவல்கள் உள்ளன. எல்லாம் நன்றாக இருக்கிறது, ஆனால் கோரிக்கைகள் பற்றிய தகவல் இல்லை. எங்கள் தரவுத்தளத்தில் என்ன வினவல்கள் இயங்குகின்றன, அவை எவ்வளவு நேரம் இயங்குகின்றன, இதில் எத்தனை வினவல்கள் உள்ளன என்பது தெளிவாகத் தெரியவில்லை. எங்கள் கண்காணிப்பில் இந்த தகவலை எப்போதும் வைத்திருக்க வேண்டும்.

இந்தத் தகவலைப் பெற, நாம் pg_stat_statements தொகுதியைப் பயன்படுத்தலாம். அதன் அடிப்படையில், நீங்கள் பல்வேறு வரைபடங்களை உருவாக்கலாம். எடுத்துக்காட்டாக, நீங்கள் அடிக்கடி கேட்கப்படும் வினவல்களைப் பற்றிய தகவலைப் பெறலாம், அதாவது, அடிக்கடி செயல்படுத்தப்படும் வினவல்கள். ஆம், வரிசைப்படுத்தப்பட்ட பிறகு, அதைப் பார்த்து, கோரிக்கைகளில் ஏதேனும் எழுச்சி உள்ளதா என்பதைப் புரிந்துகொள்வதும் மிகவும் பயனுள்ளதாக இருக்கும்.

நீங்கள் நீண்ட வினவல்களைக் கண்காணிக்கலாம், அதாவது முடிக்க அதிக நேரம் எடுக்கும் வினவல்கள். அவை செயலியில் இயங்குகின்றன, அவை I/O ஐப் பயன்படுத்துகின்றன. மொத்த_நேரம், சராசரி_நேரம், blk_write_time மற்றும் blk_read_time ஆகிய புலங்களைப் பயன்படுத்தியும் இதை மதிப்பீடு செய்யலாம்.

வள பயன்பாடு, வட்டில் இருந்து படிக்கும், நினைவகத்துடன் வேலை செய்யும், அல்லது மாறாக, சில வகையான எழுதும் சுமைகளை உருவாக்குதல் ஆகியவற்றின் அடிப்படையில் மிகப்பெரிய கோரிக்கைகளை மதிப்பீடு செய்யலாம் மற்றும் கண்காணிக்கலாம்.

மிகவும் தாராளமான கோரிக்கைகளை நாம் மதிப்பீடு செய்யலாம். அதிக எண்ணிக்கையிலான வரிசைகளை வழங்கும் வினவல்கள் இவை. எடுத்துக்காட்டாக, அவர்கள் வரம்பை அமைக்க மறந்த சில கோரிக்கையாக இது இருக்கலாம். மேலும் இது அட்டவணையின் முழு உள்ளடக்கங்களையும் அல்லது வினவப்பட்ட அட்டவணைகள் முழுவதும் வினவலை வழங்குகிறது.

தற்காலிக கோப்புகள் அல்லது தற்காலிக அட்டவணைகளைப் பயன்படுத்தும் வினவல்களையும் நீங்கள் கண்காணிக்கலாம்.

எங்களிடம் இன்னும் பின்னணி செயல்முறைகள் உள்ளன. பின்னணி செயல்முறைகள் முதன்மையாக சோதனைச் சாவடிகள் அல்லது அவை சோதனைச் சாவடிகள் என்றும் அழைக்கப்படுகின்றன, இவை ஆட்டோவாக்யூம் மற்றும் ரெப்ளிகேஷன்.

கண்காணிப்புக்கு மற்றொரு எடுத்துக்காட்டு. இடதுபுறத்தில் ஒரு பராமரிப்பு தாவல் உள்ளது, அதற்குச் சென்று பயனுள்ள ஒன்றைக் காண்பீர்கள் என்று நம்புகிறேன். ஆனால் இங்கே வெற்றிட செயல்பாடு மற்றும் புள்ளிவிவரங்கள் சேகரிப்பு நேரம் மட்டுமே உள்ளது, அதற்கு மேல் எதுவும் இல்லை. இது மிகவும் மோசமான தகவல், எனவே எங்கள் தரவுத்தளத்தில் பின்னணி செயல்முறைகள் எவ்வாறு செயல்படுகின்றன மற்றும் அவற்றின் வேலையில் ஏதேனும் சிக்கல்கள் உள்ளதா என்பது பற்றிய தகவல்களை எப்போதும் வைத்திருக்க வேண்டும்.

நாம் சோதனைச் சாவடிகளைப் பார்க்கும்போது, ​​சோதனைச் சாவடிகள் துண்டிக்கப்பட்ட நினைவகப் பகுதியிலிருந்து வட்டுக்கு அழுக்குப் பக்கங்களைப் பறித்து, ஒரு சோதனைச் சாவடியை உருவாக்குகின்றன என்பதை நினைவில் கொள்ள வேண்டும். அவசரகாலத்தில் PostgreSQL திடீரென நிறுத்தப்பட்டால், இந்த சோதனைச் சாவடியை மீட்டெடுப்பதற்கான இடமாகப் பயன்படுத்தலாம்.

அதன்படி, அனைத்து "அழுக்கு" பக்கங்களையும் வட்டில் சுத்தப்படுத்த, நீங்கள் ஒரு குறிப்பிட்ட அளவு எழுத வேண்டும். மேலும், ஒரு விதியாக, அதிக அளவு நினைவகம் கொண்ட கணினிகளில், இது நிறைய உள்ளது. ஒரு குறுகிய இடைவெளியில் நாம் அடிக்கடி சோதனைச் சாவடிகளைச் செய்தால், வட்டு செயல்திறன் மிகவும் குறையும். வாடிக்கையாளர் கோரிக்கைகள் வளங்களின் பற்றாக்குறையால் பாதிக்கப்படும். அவர்கள் வளங்களுக்காக போட்டியிடுவார்கள் மற்றும் உற்பத்தித்திறன் இல்லாதவர்கள்.

அதன்படி, குறிப்பிட்ட புலங்களைப் பயன்படுத்தி pg_stat_bgwriter மூலம் நிகழும் சோதனைச் சாவடிகளின் எண்ணிக்கையை நாம் கண்காணிக்க முடியும். ஒரு குறிப்பிட்ட காலத்திற்கு (10-15-20 நிமிடங்களில், அரை மணி நேரத்தில்) எங்களிடம் நிறைய சோதனைச் சாவடிகள் இருந்தால், எடுத்துக்காட்டாக, 3-4-5, இது ஏற்கனவே ஒரு சிக்கலாக இருக்கலாம். நீங்கள் ஏற்கனவே தரவுத்தளத்தைப் பார்க்க வேண்டும், உள்ளமைவைப் பார்க்க வேண்டும், இதுபோன்ற ஏராளமான சோதனைச் சாவடிகளுக்கு என்ன காரணம். ஏதோ பெரிய ரெக்கார்டிங் நடக்கலாம். பணிச்சுமையை ஏற்கனவே மதிப்பீடு செய்யலாம், ஏனெனில் நாங்கள் ஏற்கனவே பணிச்சுமை வரைபடங்களைச் சேர்த்துள்ளோம். நாம் ஏற்கனவே சோதனைச் சாவடி அளவுருக்களை மாற்றியமைக்கலாம் மற்றும் அவை வினவல் செயல்திறனைப் பெரிதும் பாதிக்காது என்பதை உறுதிப்படுத்திக் கொள்ளலாம்.

நான் மீண்டும் autovacuum க்கு வருகிறேன், ஏனென்றால் நான் சொன்னது போல், இது வட்டு மற்றும் வினவல் செயல்திறன் இரண்டையும் எளிதாக சேர்க்க முடியும், எனவே autovacuum அளவை மதிப்பிடுவது எப்போதும் முக்கியம்.

தரவுத்தளத்தில் ஆட்டோவாக்யூம் தொழிலாளர்களின் எண்ணிக்கை குறைவாக உள்ளது. இயல்பாக, அவற்றில் மூன்று உள்ளன, எனவே தரவுத்தளத்தில் எப்போதும் மூன்று தொழிலாளர்கள் பணிபுரிந்தால், இதன் பொருள் எங்கள் ஆட்டோவாக்யூம் கட்டமைக்கப்படவில்லை, வரம்புகளை உயர்த்த வேண்டும், ஆட்டோவாக்யூம் அமைப்புகளை மறுபரிசீலனை செய்து உள்ளமைவில் இறங்க வேண்டும்.
எங்களிடம் எந்த வெற்றிட தொழிலாளர்கள் உள்ளனர் என்பதை மதிப்பிடுவது முக்கியம். ஒன்று அது பயனரிடமிருந்து தொடங்கப்பட்டது, 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" என்ற வார்த்தை தோன்றிய அனைத்து செயல்பாடுகள், காட்சிகள் மற்றும் பயன்பாடுகளில், அது "வால்" மதிப்புடன் மாற்றப்பட்டது. இது காட்சிகள் மற்றும் செயல்பாடுகள் இரண்டிற்கும் பொருந்தும். அப்படிப்பட்ட புதுமை இது.

கூடுதலாக, பதிப்பு 10 இல், குறிப்பாக பின்னடைவைக் காட்டும் வரிகள் சேர்க்கப்பட்டன. அவை எழுதும் பின்னடைவு, ஃப்ளஷ் லேக், மறுவிளைவு பின்னடைவு. அதாவது, இந்த விஷயங்களைக் கண்காணிப்பது முக்கியம். நம்மிடம் நகலெடுக்கும் பின்னடைவு இருப்பதைக் கண்டால், அது ஏன் தோன்றியது, எங்கிருந்து வந்தது என்பதை ஆராய்ந்து சிக்கலைச் சரிசெய்ய வேண்டும்.

கணினி அளவீடுகளுடன் கிட்டத்தட்ட அனைத்தும் ஒழுங்காக உள்ளன. எந்த கண்காணிப்பும் தொடங்கும் போது, ​​அது கணினி அளவீடுகளுடன் தொடங்குகிறது. இது செயலிகள், நினைவகம், ஸ்வாப், நெட்வொர்க் மற்றும் வட்டு ஆகியவற்றை அகற்றுவது. இருப்பினும், பல அளவுருக்கள் இயல்பாக இல்லை.

மறுசுழற்சி செயல்முறையுடன் எல்லாம் ஒழுங்காக இருந்தால், வட்டு மறுசுழற்சியில் சிக்கல்கள் உள்ளன. ஒரு விதியாக, கண்காணிப்பு டெவலப்பர்கள் செயல்திறன் பற்றிய தகவலைச் சேர்க்கிறார்கள். இது iops அல்லது பைட்டுகளில் இருக்கலாம். ஆனால் வட்டு சாதனங்களின் தாமதம் மற்றும் பயன்பாடு பற்றி அவர்கள் மறந்து விடுகிறார்கள். இவை மிக முக்கியமான அளவுருக்கள் ஆகும், அவை எங்கள் வட்டுகள் எவ்வளவு ஏற்றப்படுகின்றன மற்றும் அவை எவ்வளவு மெதுவாக உள்ளன என்பதை மதிப்பீடு செய்ய அனுமதிக்கின்றன. நமக்கு அதிக தாமதம் இருந்தால், வட்டுகளில் சில சிக்கல்கள் உள்ளன என்று அர்த்தம். நம்மிடம் அதிக பயன்பாடு இருந்தால், வட்டுகள் சமாளிக்கவில்லை என்று அர்த்தம். இவை செயல்திறனை விட சிறந்த பண்புகள்.

மேலும், இந்த புள்ளிவிவரங்களை மறுசுழற்சி செயலிகளில் செய்வது போல் /proc கோப்பு முறைமையிலிருந்தும் பெறலாம். இந்தத் தகவல் ஏன் கண்காணிப்பில் சேர்க்கப்படவில்லை என்று எனக்குத் தெரியவில்லை. இருப்பினும், இதை உங்கள் கண்காணிப்பில் வைத்திருப்பது முக்கியம்.

பிணைய இடைமுகங்களுக்கும் இது பொருந்தும். பிணைய செயல்திறன் பற்றிய தகவல்கள் பாக்கெட்டுகளில், பைட்டுகளில் உள்ளன, இருப்பினும் தாமதம் மற்றும் பயன்பாடு பற்றிய எந்த தகவலும் இல்லை, இருப்பினும் இது பயனுள்ள தகவலாகும்.

எந்த கண்காணிப்பிலும் குறைபாடுகள் உள்ளன. நீங்கள் எந்த வகையான கண்காணிப்பை மேற்கொண்டாலும், அது எப்போதும் சில நிபந்தனைகளை பூர்த்தி செய்யாது. ஆயினும்கூட, அவை உருவாகின்றன, புதிய அம்சங்கள் மற்றும் புதிய விஷயங்கள் சேர்க்கப்படுகின்றன, எனவே ஏதாவது ஒன்றைத் தேர்ந்தெடுத்து அதை முடிக்கவும்.

மேலும் முடிப்பதற்கு, வழங்கப்பட்ட புள்ளிவிவரங்கள் எதைக் குறிக்கின்றன மற்றும் சிக்கல்களைத் தீர்க்க அவற்றை எவ்வாறு பயன்படுத்தலாம் என்பது பற்றிய யோசனை உங்களுக்கு எப்போதும் இருக்க வேண்டும்.

மற்றும் சில முக்கிய புள்ளிகள்:

• நீங்கள் எப்பொழுதும் கிடைக்கும் தன்மையை கண்காணிக்க வேண்டும் மற்றும் டாஷ்போர்டுகளை வைத்திருக்க வேண்டும், எனவே தரவுத்தளத்துடன் எல்லாம் ஒழுங்காக உள்ளதா என்பதை நீங்கள் விரைவாக மதிப்பிடலாம்.
• மோசமான வாடிக்கையாளர்களைக் களைவதற்கும் அவர்களைச் சுட்டு வீழ்த்துவதற்கும் உங்கள் தரவுத்தளத்தில் வாடிக்கையாளர்கள் என்ன வேலை செய்கிறார்கள் என்பதைப் பற்றிய யோசனை உங்களுக்கு எப்போதும் இருக்க வேண்டும்.
• இந்த வாடிக்கையாளர்கள் தரவுகளுடன் எவ்வாறு செயல்படுகிறார்கள் என்பதை மதிப்பீடு செய்வது முக்கியம். உங்களின் பணிச்சுமை குறித்து உங்களுக்கு ஒரு யோசனை இருக்க வேண்டும்.
• இந்த பணிச்சுமை எவ்வாறு உருவாகிறது, என்ன வினவல்களின் உதவியுடன் மதிப்பீடு செய்வது முக்கியம். நீங்கள் வினவல்களை மதிப்பீடு செய்யலாம், அவற்றை மேம்படுத்தலாம், மறுசீரமைக்கலாம், அவற்றுக்கான குறியீடுகளை உருவாக்கலாம். இது மிகவும் முக்கியமானது.
• பின்னணி செயல்முறைகள் கிளையன்ட் கோரிக்கைகளை எதிர்மறையாக பாதிக்கும், எனவே அவை அதிக ஆதாரங்களைப் பயன்படுத்தவில்லை என்பதைக் கண்காணிப்பது முக்கியம்.
• கணினி அளவீடுகள் உங்கள் சேவையகங்களின் திறனை அளவிடுதல் மற்றும் அதிகரிப்பதற்கான திட்டங்களை உருவாக்க உங்களை அனுமதிக்கின்றன, எனவே அவற்றைக் கண்காணித்து மதிப்பீடு செய்வதும் முக்கியம்.

இந்த தலைப்பில் நீங்கள் ஆர்வமாக இருந்தால், இந்த இணைப்புகளைப் பின்தொடரலாம்.
http://bit.do/stats_collector - இது புள்ளிவிவர சேகரிப்பாளரின் அதிகாரப்பூர்வ ஆவணமாகும். அனைத்து புள்ளியியல் காட்சிகளின் விளக்கமும் அனைத்து துறைகளின் விளக்கமும் உள்ளது. நீங்கள் அவற்றைப் படிக்கலாம், புரிந்து கொள்ளலாம் மற்றும் பகுப்பாய்வு செய்யலாம். அவற்றின் அடிப்படையில், உங்கள் வரைபடங்களை உருவாக்கி அவற்றை உங்கள் கண்காணிப்பில் சேர்க்கவும்.

எடுத்துக்காட்டு கோரிக்கைகள்:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

இது எங்கள் நிறுவன களஞ்சியம் மற்றும் என்னுடையது. அவை எடுத்துக்காட்டு வினவல்களைக் கொண்டுள்ளன. அங்குள்ள தொடரிலிருந்து தேர்ந்தெடு* என்பதில் இருந்து வினவல்கள் எதுவும் இல்லை. இணைக்கப்பட்ட வினவல்கள் ஏற்கனவே உள்ளன, சுவாரஸ்யமான செயல்பாடுகளைப் பயன்படுத்தி, மூல எண்களை படிக்கக்கூடிய, வசதியான மதிப்புகளாக மாற்ற உங்களை அனுமதிக்கிறது, அதாவது இவை பைட்டுகள், நேரம். நீங்கள் அவற்றை எடுக்கலாம், அவற்றைப் பார்க்கலாம், பகுப்பாய்வு செய்யலாம், உங்கள் கண்காணிப்பில் சேர்க்கலாம், அவற்றின் அடிப்படையில் உங்கள் கண்காணிப்பை உருவாக்கலாம்.

உங்கள் கேள்விகள்

கேள்வி: நீங்கள் பிராண்டுகளை விளம்பரப்படுத்த மாட்டீர்கள் என்று சொன்னீர்கள், ஆனால் நான் இன்னும் ஆர்வமாக இருக்கிறேன் - உங்கள் திட்டங்களில் எந்த வகையான டாஷ்போர்டுகளைப் பயன்படுத்துகிறீர்கள்?
பதில்: இது மாறுபடும். நாங்கள் ஒரு வாடிக்கையாளரிடம் வருகிறோம், அவருக்கு ஏற்கனவே தனது சொந்த கண்காணிப்பு உள்ளது. வாடிக்கையாளருக்கு அவர்களின் கண்காணிப்பில் என்ன சேர்க்க வேண்டும் என்று நாங்கள் அறிவுறுத்துகிறோம். மிக மோசமான நிலைமை ஜாபிக்ஸில் உள்ளது. ஏனெனில் அதற்கு TopN வரைபடங்களை உருவாக்கும் திறன் இல்லை. நாமே பயன்படுத்துகிறோம் ஓக்மீட்டர், ஏனென்றால் நாங்கள் இவர்களுடன் கண்காணிப்பு குறித்து ஆலோசனை செய்து கொண்டிருந்தோம். எங்கள் தொழில்நுட்ப விவரக்குறிப்புகளின் அடிப்படையில் அவர்கள் PostgreSQL ஐ கண்காணித்தனர். நான் எனது சொந்த செல்லப் பிராஜெக்ட்டை எழுதுகிறேன், இது ப்ரோமிதியஸ் மூலம் தரவைச் சேகரித்து அதை வழங்குகிறது. கிரபனா. ப்ரோமிதியஸில் எனது சொந்த ஏற்றுமதியாளரை உருவாக்கி, பின்னர் எல்லாவற்றையும் கிராஃபனாவில் வழங்குவதே எனது பணி.

கேள்வி: AWR அறிக்கைகளின் ஒப்புமைகள் அல்லது... திரட்டுதல் ஏதேனும் உள்ளதா? இது போன்ற ஒன்றைப் பற்றி உங்களுக்குத் தெரியுமா?
பதில்: ஆம், AWR என்றால் என்னவென்று எனக்குத் தெரியும், அது ஒரு அருமையான விஷயம். இந்த நேரத்தில் தோராயமாக பின்வரும் மாதிரியை செயல்படுத்தும் பல்வேறு சைக்கிள்கள் உள்ளன. சில கால இடைவெளியில், சில அடிப்படைகள் அதே PostgreSQL அல்லது தனி சேமிப்பகத்திற்கு எழுதப்படும். நீங்கள் அவற்றை இணையத்தில் கூகிள் செய்யலாம், அவை உள்ளன. அத்தகைய விஷயத்தை உருவாக்குபவர்களில் ஒருவர் PostgreSQL நூலில் உள்ள sql.ru மன்றத்தில் அமர்ந்திருக்கிறார். நீங்கள் அவரை அங்கே பிடிக்கலாம். ஆம், இதுபோன்ற விஷயங்கள் உள்ளன, அவற்றைப் பயன்படுத்தலாம். பிளஸ் அதில் pgCenter நானும் அதையே செய்ய அனுமதிக்கும் ஒரு விஷயத்தை எழுதுகிறேன்.

PS1 நீங்கள் postgres_exporter ஐப் பயன்படுத்துகிறீர்கள் என்றால், எந்த டேஷ்போர்டைப் பயன்படுத்துகிறீர்கள்? அவற்றில் பல உள்ளன. அவை ஏற்கனவே காலாவதியானவை. ஒருவேளை சமூகம் புதுப்பிக்கப்பட்ட டெம்ப்ளேட்டை உருவாக்குமா?

PS2 pganalyze அகற்றப்பட்டது, ஏனெனில் இது செயல்திறன் கண்காணிப்பு மற்றும் தானியங்கு டியூனிங் பரிந்துரைகளில் கவனம் செலுத்தும் தனியுரிம SaaS வழங்கல் ஆகும்.

பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். உள்நுழையவும், தயவு செய்து.

எந்த சுய-ஹோஸ்ட் செய்யப்பட்ட postgresql கண்காணிப்பு (டாஷ்போர்டுடன்) சிறந்தது என்று நீங்கள் கருதுகிறீர்கள்?

• 30,0%Alexey Lesovsky அல்லது zabbix 4.4 அல்லது libzbxpgsql + zabbix libzbxpgsql + zabbix3 இலிருந்து Zabbix + சேர்த்தல்கள்

• 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