PostgreSQL செயல்திறனை மேம்படுத்த Linux ட்யூனிங். இலியா கோஸ்மோடெமியன்ஸ்கி

இல்யா கோஸ்மோடெமியன்ஸ்கியின் 2015 அறிக்கையின் டிரான்ஸ்கிரிப்ட் "PostgreSQL செயல்திறனை மேம்படுத்த லினக்ஸ் ட்யூனிங்"

மறுப்பு: இந்த அறிக்கை நவம்பர் 2015 தேதியிட்டது என்பதை நான் கவனிக்கிறேன் - 4 ஆண்டுகளுக்கும் மேலாக கடந்து, நிறைய நேரம் கடந்துவிட்டது. அறிக்கையில் விவாதிக்கப்பட்ட பதிப்பு 9.4 இனி ஆதரிக்கப்படாது. கடந்த 4 ஆண்டுகளில், PostgreSQL இன் 5 புதிய வெளியீடுகள் வெளியிடப்பட்டுள்ளன, மேலும் லினக்ஸ் கர்னலின் 15 பதிப்புகள் வெளியிடப்பட்டுள்ளன. இந்த பத்திகளை நீங்கள் மீண்டும் எழுதினால், நீங்கள் வேறு அறிக்கையுடன் முடிவடையும். ஆனால் இங்கே நாம் PostgreSQL க்கான அடிப்படை லினக்ஸ் ட்யூனிங்கைக் கருதுகிறோம், இது இன்றும் பொருத்தமானது.

என் பெயர் இலியா கோஸ்மோடெமியன்ஸ்கி. நான் PostgreSQL-கன்சல்டிங்கில் வேலை செய்கிறேன். பொதுவாக தரவுத்தளங்கள் மற்றும் குறிப்பாக PostgreSQL தொடர்பாக லினக்ஸை என்ன செய்வது என்பது பற்றி இப்போது நான் கொஞ்சம் பேசுவேன், ஏனெனில் கொள்கைகள் மிகவும் ஒத்தவை.

எதைப் பற்றி பேசுவோம்? நீங்கள் PostgreSQL உடன் தொடர்பு கொண்டால், ஓரளவிற்கு நீங்கள் UNIX நிர்வாகியாக இருக்க வேண்டும். இதற்கு என்ன அர்த்தம்? Oracle மற்றும் PostgreSQLஐ ஒப்பிட்டுப் பார்த்தால், Oracleல் நீங்கள் 80% DBA தரவுத்தள நிர்வாகியாகவும் 20% Linux நிர்வாகியாகவும் இருக்க வேண்டும்.

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

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

எல்லோரும் சோலாரிஸ் போன்ற எக்சோடிக்ஸ் மீது ஆர்வம் குறைவாக இருப்பதாக நான் நினைக்கிறேன், எனவே செல்லலாம்.

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

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

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

நீங்கள் டியூன் செய்யலாம்:

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

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

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

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

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

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

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

இந்த உள்ளீடு-வெளியீடு ஒரு வழி அல்லது வேறு இந்த விஷயத்தில் நடக்கிறது.

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

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

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

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

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

இந்த புள்ளிகள் ஒவ்வொன்றிலும் செல்லலாம்.

இந்தப் பக்கங்களை முன்னும் பின்னுமாக வேகமாகப் பயணிக்க, நீங்கள் பின்வருவனவற்றை அடைய வேண்டும்:

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

நீங்கள் சர்வரில் 512 ஜிபி ரேம் வைத்திருந்தால், அது அனைத்தும் SATA ஹார்ட் டிரைவில் எந்த கேச் இல்லாமல் முடிவடையும் என்றால், முழு தரவுத்தள சேவையகமும் பூசணிக்காயாக மாறாமல், SATA இடைமுகம் கொண்ட பூசணிக்காயாக மாறும். நீங்கள் நேரடியாக அதில் ஓடுவீர்கள். மேலும் எதுவும் உங்களைக் காப்பாற்றாது.

நினைவகத்தின் முதல் புள்ளியைப் பொறுத்தவரை, வாழ்க்கையை மிகவும் கடினமாக்கும் மூன்று விஷயங்கள் உள்ளன.

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

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

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

ஓடினால் numactl --hardware, பிறகு இவ்வளவு பெரிய தாள் கிடைக்கும். மற்றவற்றுடன், ஒரு தூர புலம் இருக்கும். எண்கள் இருக்கும் - 10-20, அது போன்ற ஏதாவது. இந்த எண்கள் இந்த தொலைநிலை நினைவகத்தை எடுத்து உள்நாட்டில் பயன்படுத்துவதற்கான ஹாப்களின் எண்ணிக்கையைத் தவிர வேறில்லை. கொள்கையளவில், ஒரு நல்ல யோசனை. இது பலவிதமான பணிச்சுமைகளின் கீழ் செயல்திறனை விரைவுபடுத்துகிறது.

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

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

அது ஏன்? அதற்கு நேர்மாறாக இருக்க வேண்டும் என்று தோன்றுகிறது. இது ஒரு எளிய காரணத்திற்காக நிகழ்கிறது: பக்க தற்காலிக சேமிப்பிற்கு நமக்கு நிறைய நினைவகம் தேவை - பத்துகள், நூற்றுக்கணக்கான ஜிகாபைட்கள்.

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

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

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

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

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

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

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

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

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

அது ஏன்? அதனால் என்ன நடக்கிறது? இயக்க முறைமை நினைவகத்தை சிறிய துண்டுகளாக ஒதுக்குகிறது. இது மிகவும் வசதியானது, இது வரலாற்று ரீதியாக எப்படி நடந்தது. நாம் விரிவாகச் சென்றால், OS மெய்நிகர் முகவரிகளை இயற்பியல் முகவரிகளாக மொழிபெயர்க்க வேண்டும். இந்த செயல்முறை எளிமையானது அல்ல, எனவே இந்த செயல்பாட்டின் முடிவை OS ஆனது Translation Lookaside Buffer (TLB) இல் தேக்குகிறது.

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

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

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

இதை எப்படி PostgreSQL உடன் நண்பர்களாக்கலாம்? முதலில், லினக்ஸ் கர்னலில் பெரிய பக்கங்கள் இயக்கப்பட வேண்டும்.

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

உங்கள் முழு சேவையகமும் PostgreSQL க்கு அர்ப்பணிக்கப்பட்டிருந்தால், ஒரு நல்ல தொடக்க புள்ளியாக 25% RAM ஐ பகிர்ந்த பஃபர்களுக்கு ஒதுக்க வேண்டும் அல்லது 75% உங்கள் தரவுத்தளம் கண்டிப்பாக இந்த 75% இல் பொருந்தும் என்று நீங்கள் உறுதியாக நம்பினால். தொடக்கப் புள்ளி ஒன்று. உங்களிடம் 256 ஜிபி ரேம் இருந்தால், அதன்படி, உங்களிடம் 64 ஜிபி பெரிய இடையகங்கள் இருக்கும். தோராயமாக சில விளிம்புடன் கணக்கிடுங்கள் - இந்த எண்ணிக்கை என்ன அமைக்கப்பட வேண்டும்.

பதிப்பு 9.2 க்கு முன் (நான் தவறாக நினைக்கவில்லை என்றால், பதிப்பு 8.2 முதல்), மூன்றாம் தரப்பு நூலகத்தைப் பயன்படுத்தி பெரிய பக்கங்களுடன் PostgreSQL ஐ இணைக்க முடியும். மேலும் இது எப்போதும் செய்யப்பட வேண்டும். முதலில், பெரிய பக்கங்களை சரியாக ஒதுக்க உங்களுக்கு கர்னல் தேவை. மற்றும், இரண்டாவதாக, அவர்களுடன் வேலை செய்யும் பயன்பாடு அவற்றைப் பயன்படுத்த முடியும். அது அப்படியே பயன்படுத்தப்படாது. PostgreSQL ஆனது கணினி 5 பாணியில் நினைவகத்தை ஒதுக்கியதால், இது libhugetlbfs ஐப் பயன்படுத்தி செய்யப்படலாம் - இது நூலகத்தின் முழுப் பெயர்.

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

ஆனால் சமூகம் இந்த பிரச்சனையில் கவனம் செலுத்தியது மற்றும் 9.4 இல் அவர்கள் இந்த நிகழ்வை நன்றாக மாற்றினர். மற்றும் 9.4 இல் postgresql.conf இல் ஒரு அளவுரு தோன்றியது, அதில் நீங்கள் முயற்சியை இயக்கலாம் அல்லது முடக்கலாம்.

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

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

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

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

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

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

முன்னதாக, vm.swappiness ஐ பூஜ்ஜியமாக அமைக்குமாறு அறிவுறுத்தினோம், அதாவது swap ஐ முடக்க வேண்டும். முன்னதாக, 32 ஜிபி ரேம் மற்றும் அதனுடன் தொடர்புடைய பகிர்வு இடையகங்கள் ஒரு பெரிய தொகை என்று தோன்றியது. இடமாற்று முக்கிய நோக்கம் நாம் விழுந்தால் மேலோடு தூக்கி எறிய ஒரு இடம் வேண்டும். மேலும் அது இனி குறிப்பாக நிறைவேறவில்லை. பின்னர் இந்த மேலோடு என்ன செய்யப் போகிறீர்கள்? இது ஒரு பணியாகும், குறிப்பாக அத்தகைய அளவு ஏன் இடமாற்று தேவைப்படுகிறது என்பது தெளிவாகத் தெரியவில்லை.

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

எனவே, இப்போது இயல்புநிலை, எனக்கு நினைவிருக்கும் வரை, பெரும்பாலான விநியோகங்கள் எங்காவது 6 இல் உள்ளன, அதாவது எந்த நேரத்தில் எவ்வளவு நினைவகம் மீதமுள்ளது என்பதைப் பொறுத்து ஸ்வாப்பைப் பயன்படுத்தத் தொடங்க வேண்டும். நாங்கள் இப்போது vm.swappiness = 1 ஐ அமைக்க பரிந்துரைக்கிறோம், ஏனெனில் இது நடைமுறையில் அதை அணைத்துவிடும், ஆனால் OOM-கில்லர் எதிர்பாராமல் வந்து முழுவதையும் கொன்றது போன்ற விளைவுகளைத் தராது.

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

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

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

இங்கே என்னிடம் இரண்டு படங்கள் உள்ளன. அது என்ன என்பதை இப்போது விளக்குகிறேன். இவை இரண்டு நேர-தொடர்புடைய வரைபடங்கள். முதல் வரைபடம் வட்டு பயன்பாடு ஆகும். இங்கே அது இந்த நேரத்தில் கிட்டத்தட்ட 90% அடையும். 90% RAID கன்ட்ரோலர் பயன்பாட்டுடன், இயற்பியல் வட்டுகளுடன் தரவுத்தள தோல்வி இருந்தால், இது மோசமான செய்தி. அதாவது இன்னும் கொஞ்சம் அதிகமாகி அது 100ஐ எட்டும் மற்றும் I/O நின்றுவிடும்.

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

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

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

நீங்கள் லினக்ஸின் பார்வையில் இருந்து பார்த்தால், நீங்கள் நல்ல வன்பொருளை எடுத்து, அதை சரியாக உள்ளமைத்து, PostgreSQL ஐ சாதாரணமாக கட்டமைத்திருந்தால், அது இந்த சோதனைச் சாவடிகளை அடிக்கடி குறைக்கிறது, காலப்போக்கில் அவற்றை ஒருவருக்கொருவர் பரப்புகிறது, பின்னர் நீங்கள் இயல்புநிலை Debian அளவுருக்களுக்குள் செல்லலாம். பெரும்பாலான லினக்ஸ் விநியோகங்களுக்கு, இது படம்: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

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

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

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

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

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

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

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

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

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

இந்த அறிக்கையின் எல்லைக்கு அப்பாற்பட்ட இன்னும் இரண்டு முக்கியமான விஷயங்கள் இங்கே உள்ளன. இந்த அமைப்புகள் postgresql.conf இல் உள்ள அமைப்புகளுடன் பொருந்த வேண்டும், அதாவது சோதனைச் சாவடி அமைப்புகளுடன். உங்கள் வட்டு அமைப்பு போதுமான அளவு கட்டமைக்கப்பட்டிருக்க வேண்டும். உங்களிடம் RAID இல் கேச் இருந்தால், அதில் பேட்டரி இருக்க வேண்டும். மக்கள் பேட்டரி இல்லாமல் நல்ல தற்காலிக சேமிப்புடன் RAID ஐ வாங்குகிறார்கள். உங்களிடம் RAID இல் SSDகள் இருந்தால், அவை சேவையகமாக இருக்க வேண்டும், அங்கு மின்தேக்கிகள் இருக்க வேண்டும். இங்கே ஒரு விரிவான சரிபார்ப்பு பட்டியல் உள்ளது. இந்த இணைப்பில் PostgreSQL இல் செயல்திறன் வட்டை எவ்வாறு கட்டமைப்பது என்பது பற்றிய எனது அறிக்கை உள்ளது. இந்த சரிபார்ப்பு பட்டியல்கள் அனைத்தும் உள்ளன.

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

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

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

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

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

எனது சகாவான அலெக்ஸி லெசோவ்ஸ்கி ஒரு எளிய pgbench மூலம் சோதனைகளைச் செய்தார், அங்கு அவர் இடம்பெயர்வு_செலவை அளவின் மூலம் அதிகரித்து, ஆட்டோகுரூப்பை முடக்கினார். மோசமான வன்பொருளின் வித்தியாசம் கிட்டத்தட்ட 10%. போஸ்ட்கிரெஸ் அஞ்சல் பட்டியலில் ஒரு விவாதம் உள்ளது, அங்கு மக்கள் வினவல் வேகத்தில் இதே போன்ற மாற்றங்களின் முடிவுகளை வழங்குகிறார்கள் தாக்கம் 50%. இதுபோன்ற கதைகள் நிறைய உள்ளன.

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

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

அதிக சுமையின் கீழ் உள்ள தரவுத்தளத்துடன் சேவையகத்தில் இதைப் பயன்படுத்தினால், உங்கள் விருப்பம் acpi_cpufreq + permormance. தேவையில்லாமல் இருந்தாலும் பிரச்சனைகள் இருக்கும்.

Intel_pstate சற்று வித்தியாசமான இயக்கி. இப்போது முன்னுரிமை இதற்கு வழங்கப்படுகிறது, ஏனெனில் இது பின்னர் மற்றும் சிறப்பாக செயல்படுகிறது.

மற்றும், அதன்படி, கவர்னர் செயல்திறன் மட்டுமே. Ondemand, powersave மற்றும் மற்ற அனைத்தும் உங்களைப் பற்றியது அல்ல.

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

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

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

கேள்விகள்:

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

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

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

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

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

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

Amazon AWS தொடர்பான கேள்வி என்னிடம் உள்ளது. அவை முன் கட்டமைக்கப்பட்ட படங்கள் உள்ளன. அவற்றில் ஒன்று அமேசான் ஆர்.டி.எஸ். அவர்களின் இயக்க முறைமைக்கு ஏதேனும் தனிப்பயன் அமைப்புகள் உள்ளதா?

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

பெரிய TLB உடன் ஒப்பிடும்போது வெளிப்படையான பெரிய பக்கங்கள் ஏன் எந்த விளைவையும் ஏற்படுத்தாது?

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

ஆதாரம்: www.habr.com