PostgreSQL කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා Linux සුසර කිරීම. ඉල්යා කොස්මෝඩෙමියන්ස්කි

Ilya Kosmodemyansky විසින් 2015 වාර්තාවේ පිටපත "PostgreSQL කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා Linux සුසර කිරීම"

වියාචනය: මෙම වාර්තාව නොවැම්බර් 2015 දිනැති බව මම සටහන් කරමි - වසර 4 කට වැඩි කාලයක් ගත වී ඇති අතර බොහෝ කාලයක් ගත වී ඇත. වාර්තාවේ සාකච්ඡා කර ඇති 9.4 අනුවාදය තවදුරටත් සහාය නොදක්වයි. පසුගිය වසර 4 තුළ, PostgreSQL හි නව නිකුතු 5ක් නිකුත් කර ඇති අතර Linux කර්නලයේ අනුවාද 15ක් නිකුත් කර ඇත. ඔබ මෙම ඡේද නැවත ලියන්නේ නම්, ඔබට වෙනත් වාර්තාවක් ලැබෙනු ඇත. නමුත් මෙහිදී අපි PostgreSQL සඳහා මූලික Linux සුසර කිරීම සලකා බලමු, එය අදටත් අදාළ වේ.

මගේ නම Ilya Kosmodemyansky. මම PostgreSQL-Consulting හි වැඩ කරනවා. දැන් මම පොදුවේ දත්ත සමුදායන් හා විශේෂයෙන් PostgreSQL සම්බන්ධයෙන් Linux සමඟ කළ යුතු දේ ගැන ටිකක් කතා කරමි, මන්ද මූලධර්ම බෙහෙවින් සමාන ය.

අපි කුමක් ගැන කතා කරමුද? ඔබ PostgreSQL සමඟ සන්නිවේදනය කරන්නේ නම්, යම් දුරකට ඔබ UNIX පරිපාලකයෙකු විය යුතුය. එයින් අදහස් කරන්නේ කුමක් ද? අපි Oracle සහ PostgreSQL සංසන්දනය කරන්නේ නම්, Oracle හි ඔබ 80% DBA දත්ත සමුදා පරිපාලක සහ 20% Linux පරිපාලක විය යුතුය.

PostgreSQL සමඟ එය ටිකක් සංකීර්ණයි. PostgreSQL සමඟින් ඔබට Linux ක්‍රියා කරන ආකාරය පිළිබඳව වඩා හොඳ අවබෝධයක් තිබිය යුතුය. ඒ අතරම, දුම්රිය එන්ජිම පසුපසින් මඳක් ධාවනය කරන්න, මන්ද මෑතකදී සියල්ල ඉතා හොඳින් යාවත්කාලීන කර ඇත. තවද නව කර්නල් නිකුත් කරනු ලබන අතර නව ක්‍රියාකාරිත්වය දිස්වේ, කාර්ය සාධනය වැඩි දියුණු වේ, ආදිය.

අපි ලිනක්ස් ගැන කතා කරන්නේ ඇයි? අපි Linux සම්මන්ත්‍රණයේ සිටින නිසා නොවේ Peter, නමුත් නූතන තත්වයන් තුළ පොදුවේ දත්ත සමුදායන් භාවිතා කිරීම සඳහා වඩාත්ම සාධාරණ මෙහෙයුම් පද්ධතියක් වන අතර විශේෂයෙන් PostgreSQL Linux වේ. මක්නිසාද යත් FreeBSD, අවාසනාවකට මෙන්, ඉතා අමුතු දිශාවකින් වර්ධනය වෙමින් පවතී. තවද කාර්ය සාධනය සහ වෙනත් බොහෝ දේ සම්බන්ධයෙන් ගැටළු ඇති වේ. Windows හි PostgreSQL හි ක්‍රියාකාරිත්වය සාමාන්‍යයෙන් වෙනම බරපතල ගැටළුවක් වන අතර, Windows හට UNIX හා සමාන හවුල් මතකයක් නොමැති බව මත පදනම්ව, PostgreSQL සියල්ලම මෙයට බැඳී ඇත, මන්ද එය බහු-ක්‍රියාවලි පද්ධතියකි.

ඒ වගේම මම හිතන්නේ හැමෝම Solaris වගේ exotics ගැන උනන්දුව අඩුයි, එහෙනම් අපි යමු.

නවීන Linux බෙදාහැරීමකට ඔබ කර්නලය ගොඩනඟන ආකාරය අනුව syctl විකල්ප 1කට වඩා ඇත. ඒ අතරම, අපි විවිධ ගෙඩි දෙස බැලුවහොත්, අපට බොහෝ ආකාරවලින් යමක් සකස් කළ හැකිය. ඒවා සවි කරන්නේ කෙසේද යන්න පිළිබඳ ගොනු පද්ධති පරාමිතීන් ඇත. එය ආරම්භ කරන්නේ කෙසේද යන්න පිළිබඳව ඔබට ප්‍රශ්න තිබේ නම්: BIOS තුළ සක්‍රීය කළ යුතු දේ, දෘඩාංග වින්‍යාස කරන්නේ කෙසේද, ආදිය.

මෙය ඉතා විශාල පරිමාවක් වන අතර එය එක් කෙටි වාර්තාවකින් නොව දින කිහිපයක් පුරා සාකච්ඡා කළ හැකිය, නමුත් දැන් මම වැදගත් කරුණු කෙරෙහි අවධානය යොමු කරමි, ඔබ ලිනක්ස් මත ඔබේ දත්ත ගබඩාව හොඳින් භාවිතා කිරීමෙන් ඔබව වළක්වන බවට සහතික වන එම රේක් වළක්වා ගන්නේ කෙසේද? ඒවා නිවැරදි නොකරන්න. ඒ අතරම, වැදගත් කරුණක් වන්නේ දත්ත සමුදාය සඳහා නිවැරදි සැකසුම් තුළ බොහෝ පෙරනිමි පරාමිතීන් ඇතුළත් කර නොමැති බවයි. එනම්, පෙරනිමියෙන් එය දුර්වල ලෙස හෝ කිසිසේත්ම ක්රියා නොකරනු ඇත.

Linux හි ඇති සාම්ප්‍රදායික සුසර කිරීමේ ඉලක්ක මොනවාද? ඔබ සියලු දෙනා ලිනක්ස් පරිපාලනය සමඟ කටයුතු කරන බැවින්, ඉලක්ක මොනවාදැයි විශේෂයෙන් පැහැදිලි කිරීමට අවශ්‍ය නොවන බව මම සිතමි.

ඔබට සුසර කළ හැකිය:

• CPUs.
• මතකය.
• ගබඞා.
• අනික්. අපි මේ ගැන අවසානයේ කෙටි කෑමක් සඳහා කතා කරමු. උදාහරණයක් ලෙස, බලශක්ති ඉතිරිකිරීමේ ප්‍රතිපත්ති වැනි පරාමිතීන් පවා ඉතා අනපේක්ෂිත ලෙස කාර්ය සාධනයට බලපෑ හැකි අතර වඩාත් ප්‍රසන්න ආකාරයෙන් නොවේ.

PostgreSQL සහ පොදුවේ දත්ත සමුදායේ විශේෂතා මොනවාද? ගැටළුව වන්නේ ඔබට තනි පුද්ගල ගෙඩියක් වෙනස් කර අපගේ කාර්යසාධනය සැලකිය යුතු ලෙස වැඩිදියුණු වී ඇති බව දැකීමට නොහැකි වීමයි.

ඔව්, එවැනි ගැජට් ඇත, නමුත් දත්ත සමුදායක් සංකීර්ණ දෙයක්. එය සේවාදායකය සතුව ඇති සියලුම සම්පත් සමඟ අන්තර්ක්‍රියා කරන අතර උපරිම ලෙස අන්තර්ක්‍රියා කිරීමට කැමැත්තක් දක්වයි. ඔබ සත්කාරක මෙහෙයුම් පද්ධතියක් භාවිතා කරන්නේ කෙසේද යන්න පිළිබඳ ඔරකල්ගේ වර්තමාන නිර්දේශ දෙස බැලුවහොත්, එය එම මොන්ගෝලියානු අභ්‍යවකාශගාමියාගේ විහිළුව හා සමාන වනු ඇත - බල්ලාට කන්න දෙන්න සහ කිසිවක් ස්පර්ශ නොකරන්න. දත්ත සමුදායට සියලු සම්පත් ලබා දෙමු, දත්ත සමුදාය විසින්ම සියල්ල නිරාකරණය කරනු ඇත.

ප්‍රතිපත්තිමය වශයෙන්, යම් දුරකට තත්ත්වය PostgreSQL සමඟ හරියටම සමාන වේ. වෙනස වන්නේ දත්ත සමුදායට තවමත් සියලු සම්පත් තමන් වෙත ලබා ගැනීමට නොහැකි වීමයි, එනම් ලිනක්ස් මට්ටමේ කොතැනක හෝ ඔබ විසින්ම සියල්ල නිරාකරණය කර ගත යුතුය.

ප්‍රධාන අදහස නම් තනි ඉලක්කයක් තෝරා එය සුසර කිරීම ආරම්භ කිරීම නොව, උදාහරණයක් ලෙස, මතකය, CPU හෝ එවැනි දෙයක්, නමුත් වැඩ බර විශ්ලේෂණය කර ප්‍රතිදානය හැකිතාක් වැඩි දියුණු කිරීමට උත්සාහ කිරීම, එවිට හොඳ ක්‍රමලේඛකයින් විසින් එය නිර්මාණය කරන ලද භාරය. අපගේ පරිශීලකයින් ඇතුළුව අප සඳහා.

එය කුමක්ද යන්න පැහැදිලි කිරීමට මෙන්න පින්තූරයක්. Linux OS බෆරයක් ඇති අතර හවුල් මතකයක් ඇති අතර PostgreSQL හවුල් බෆර තිබේ. PostgreSQL, Oracle මෙන් නොව, සෘජුවම ක්‍රියා කරන්නේ කර්නල් බෆරය හරහා පමණි, එනම්, තැටියේ ඇති පිටුවක් එහි හවුල් මතකයට ඇතුළු වීමට නම්, එය කර්නල් බෆරය හරහා ගොස් ආපසු යා යුතුය, හරියටම එම තත්වයම.

තැටි මෙම පද්ධතිය යටතේ ජීවත් වේ. මම මේක ඇඳලා තියෙන්නේ තැටි විදියට. ඇත්ත වශයෙන්ම, RAID පාලක යනාදිය තිබිය හැකිය.

තවද මෙම ආදාන-ප්‍රතිදානය මෙම කාරණය හරහා එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් සිදු වේ.

PostgreSQL යනු සම්භාව්‍ය දත්ත සමුදායකි. ඇතුලේ පිටුවක් තියෙනවා. තවද සියලුම ආදාන සහ ප්‍රතිදානය පිටු භාවිතයෙන් සිදුවේ. අපි පිටු සමඟ මතකයට කුට්ටි ඔසවන්නෙමු. කිසිවක් සිදු නොවූයේ නම්, අපි ඒවා කියෙව්වා, පසුව ඒවා ක්‍රමයෙන් මෙම හැඹිලියෙන්, හවුල් බෆරයෙන් අතුරුදහන් වී නැවත තැටියට පැමිණේ.

අපි කොහේ හරි යමක් ප්‍රතිස්ථාපනය කළහොත්, මුළු පිටුවම අපිරිසිදු ලෙස සලකුණු කර ඇත. මම ඒවා මෙහි නිල් පාටින් සලකුණු කළා. මෙයින් අදහස් කරන්නේ මෙම පිටුව බ්ලොක් ආචයනය සමඟ සමමුහුර්ත කළ යුතු බවයි. ඒ කියන්නේ අපි ඒක අපිරිසිදු කළාම අපි WAL එකේ entry එකක් දැම්මා. ඒ වගේම එක්තරා අපූරු මොහොතක මුරපොල නමින් සංසිද්ධියක් ආවා. තවද ඔහු පැමිණි බවට තොරතුරු මෙම ලොගයේ සටහන් විය. තවද මෙයින් අදහස් කරන්නේ මෙම බෙදාගත් බෆරවල ඒ මොහොතේ මෙහි තිබූ සියලුම අපිරිසිදු පිටු කර්නල් බෆරය හරහා fsync භාවිතයෙන් ගබඩා තැටිය සමඟ සමමුහුර්ත කර ඇති බවයි.

ඇයි මෙහෙම කරන්නේ? අපට වෝල්ටීයතාවයක් නැති වූවා නම්, සියලු දත්ත නැති වී යන තත්වයක් අපට නොලැබුණි. සෑම කෙනෙකුම අපට පැවසූ ස්ථිර මතකය මෙතෙක් දත්ත සමුදා න්‍යායේ පවතී - මෙය දීප්තිමත් අනාගතයකි, ඇත්ත වශයෙන්ම අපි උත්සාහ කරන අතර අපි එයට කැමතියි, නමුත් දැනට ඔවුන් ජීවත් වන්නේ අවුරුදු 20 කින් අඩු කාලයකි. තවද, ඇත්ත වශයෙන්ම, මේ සියල්ල නිරීක්ෂණය කළ යුතුය.

ප්‍රතිදානය උපරිම කිරීමේ කර්තව්‍යය වන්නේ මේ සෑම අදියරකදීම හොඳින් සුසර කිරීම වන අතර එමඟින් සියල්ල ඉක්මනින් ඉදිරියට සහ පසුපසට ගමන් කරයි. හවුල් මතකය මූලික වශයෙන් පිටු හැඹිලියකි. PostgreSQL හි අපි තෝරාගත් විමසුමක් හෝ යමක් යැව්වා, එය මෙම දත්ත තැටියෙන් ලබා ගත්තා. ඒවා අවසන් වූයේ හවුල් බෆරවල ය. ඒ අනුව මෙය වඩාත් හොඳින් ක්‍රියාත්මක වීමට නම් මතකය විශාල ප්‍රමාණයක් තිබිය යුතුය.

මේ සියල්ල හොඳින් හා ඉක්මනින් ක්‍රියාත්මක වීමට නම්, ඔබ සෑම අදියරකදීම මෙහෙයුම් පද්ධතිය නිවැරදිව වින්‍යාසගත කළ යුතුය. සමබර දෘඩාංග තෝරන්න, මන්ද ඔබට යම් ස්ථානයක අසමතුලිතතාවයක් තිබේ නම්, ඔබට මතකය විශාල ප්‍රමාණයක් සෑදිය හැකි නමුත් එය ප්‍රමාණවත් වේගයකින් සේවය නොකෙරේ.

තවද අපි මෙම එක් එක් කරුණු හරහා යමු.

මෙම පිටු එහාට මෙහාට වේගයෙන් ගමන් කිරීමට, ඔබ පහත දෑ සාක්ෂාත් කර ගත යුතුය:

• පළමුව, ඔබ මතකය සමඟ වඩාත් කාර්යක්ෂමව වැඩ කළ යුතුය.
• දෙවනුව, මතකයෙන් පිටු තැටියට යන විට මෙම සංක්‍රාන්තිය වඩාත් කාර්යක්ෂම විය යුතුය.
• තෙවනුව, හොඳ තැටි තිබිය යුතුය.

ඔබට සේවාදායකයේ 512 GB RAM තිබේ නම් සහ ඒ සියල්ල කිසිදු හැඹිලියකින් තොරව SATA දෘඪ තැටියක අවසන් වන්නේ නම්, එවිට සම්පූර්ණ දත්ත සමුදා සේවාදායකයම වට්ටක්කා පමණක් නොව SATA අතුරුමුහුණතක් සහිත වට්ටක්කා බවට පත්වේ. ඔබ කෙලින්ම එයට ඇතුල් වනු ඇත. තවද කිසිවක් ඔබව ගලවා නොගනු ඇත.

මතකය සමඟ පළමු කරුණ සම්බන්ධයෙන්, ජීවිතය ඉතා දුෂ්කර කළ හැකි කරුණු තුනක් තිබේ.

ඒවායින් පළමුවැන්න NUMA ය. NUMA කියන්නේ Performance වැඩි දියුණු කරන්න හදපු දෙයක්. වැඩ ප්රමාණය අනුව, විවිධ දේවල් ප්රශස්තිකරණය කළ හැකිය. තවද එහි නව වත්මන් ස්වරූපයෙන්, පිටු හැඹිලි බෙදාගත් බෆර තීව්‍ර ලෙස භාවිතා කරන දත්ත සමුදායන් වැනි යෙදුම් සඳහා එය එතරම් හොඳ නැත.

කෙටියෙන්. NUMA හි යම් වරදක් තිබේදැයි ඔබට කිව හැක්කේ කෙසේද? ඔබට යම් ආකාරයක අප්‍රසන්න තට්ටු කිරීමක් තිබේ, හදිසියේම සමහර CPU අධික ලෙස පටවා ඇත. ඒ සමගම, ඔබ PostgreSQL හි විමසුම් විශ්ලේෂණය කර එහි සමාන කිසිවක් නොමැති බව දකියි. මෙම විමසුම් එතරම් CPU තීව්‍ර නොවිය යුතුය. ඔබට මෙය දිගු කාලයක් අල්ලා ගත හැකිය. PostgreSQL සඳහා NUMA වින්‍යාස කරන්නේ කෙසේද යන්න පිළිබඳව ආරම්භයේ සිටම නිවැරදි නිර්දේශය භාවිතා කිරීම පහසුය.

ඇත්තටම මොකද වෙන්නේ? NUMA යනු Un-Uniform Memory Access යන්නයි. කාරණය කුමක්ද? ඔබට CPU එකක් ඇත, එය අසල එහි දේශීය මතකය ඇත. තවද මෙම මතක අන්තර් සම්බන්ධතා වලට අනෙකුත් CPU වලින් මතකය ඉහලට ඇද ගත හැක.

දුවනවා නම් numactl --hardware, එවිට ඔබට එවැනි විශාල පත්රයක් ලැබෙනු ඇත. වෙනත් දේ අතර, දුරස්ථ ක්ෂේත්රයක් ඇත. අංක ඇත - 10-20, ඒ වගේ දෙයක්. මෙම සංඛ්යා මෙම දුරස්ථ මතකය ලබා ගැනීමට සහ එය දේශීයව භාවිතා කිරීමට ඇති hops ගණනට වඩා වැඩි දෙයක් නොවේ. ප්රතිපත්තිමය වශයෙන්, හොඳ අදහසක්. මෙය වැඩ බර පරාසයක් යටතේ කාර්ය සාධනය හොඳින් වේගවත් කරයි.

දැන් සිතන්න, ඔබ සතුව එක් CPU එකක් ඇති බව පළමුව එහි දේශීය මතකය භාවිතා කිරීමට උත්සාහ කරයි, පසුව යමක් සඳහා අන්තර් සම්බන්ධතාව හරහා තවත් මතකයක් ලබා ගැනීමට උත්සාහ කරයි. තවද මෙම CPU ඔබගේ සම්පූර්ණ PostgreSQL පිටු හැඹිලිය ලබා ගනී - එපමණයි, ගිගාබයිට් කිහිපයක්. ඔබට සෑම විටම නරකම අවස්ථාව ලැබේ, මන්ද CPU හි සාමාන්‍යයෙන් එම මොඩියුලය තුළම මතකය අඩුය. තවද සේවා සපයන සියලුම මතකය මෙම අන්තර් සම්බන්ධතා හරහා ගමන් කරයි. එය සෙමින් හා කණගාටුදායක ලෙස හැරේ. තවද මෙම නෝඩයට සේවා සපයන ඔබේ ප්‍රොසෙසරය නිරන්තරයෙන් අධික ලෙස පටවනු ලැබේ. තවද මෙම මතකයේ ප්‍රවේශ කාලය නරක, මන්දගාමී වේ. ඔබ මෙය Database එකකට භාවිතා කරන්නේ නම් ඔබට අවශ්‍ය නොවන තත්වය මෙයයි.

එබැවින්, දත්ත සමුදාය සඳහා වඩාත් නිවැරදි විකල්පය වන්නේ ලිනක්ස් මෙහෙයුම් පද්ධතිය එහි සිදුවන්නේ කුමක්ද යන්න නොදැන සිටීමයි. ඒ නිසා එය මතකයට පිවිසෙන ආකාරයටම ප්‍රවේශ වේ.

ඇයි ඒ? එය අනෙක් අතට විය යුතු බව පෙනේ. මෙය එක් සරල හේතුවක් නිසා සිදු වේ: පිටු හැඹිලිය සඳහා අපට විශාල මතකයක් අවශ්ය වේ - දස, ගිගාබයිට් සිය ගණනක්.

තවද අපි මේ සියල්ල වෙන් කර එහි දත්ත ගබඩා කළහොත්, හැඹිලිය භාවිතා කිරීමෙන් ලැබෙන ලාභය මතකයට එවැනි උපක්‍රමශීලී ප්‍රවේශයකින් ලැබෙන ලාභයට වඩා සැලකිය යුතු ලෙස වැඩි වනු ඇත. තවද අපි NUMA භාවිතයෙන් වඩාත් කාර්යක්ෂමව මතකයට ප්‍රවේශ වීම හා සසඳන විට අපට අසමසම ප්‍රතිලාභයක් ලැබෙනු ඇත.

එබැවින්, දීප්තිමත් අනාගතය පැමිණෙන තුරු, මේ මොහොතේ මෙහි ප්‍රවේශයන් දෙකක් ඇති අතර, එය ක්‍රියාත්මක වන්නේ කුමන CPU මතද සහ යමක් ඇද ගත යුත්තේ කොතැනින්ද යන්න සොයා ගැනීමට දත්ත සමුදායටම නොහැකි වේ.

එබැවින්, නිවැරදි ප්‍රවේශය වන්නේ NUMA සම්පූර්ණයෙන්ම අක්‍රිය කිරීමයි, උදාහරණයක් ලෙස, නැවත ආරම්භ කරන විට. බොහෝ අවස්ථාවන්හීදී, ජයග්‍රහණ එතරම් විශාල වන අතර වඩා හොඳ කුමක්ද යන ප්‍රශ්නය කිසිසේත්ම මතු නොවේ.

තවත් විකල්පයක් ඇත. අපි එය පළමු එකට වඩා බොහෝ විට භාවිතා කරන්නෙමු, මන්ද සේවාදායකයෙකු සහාය සඳහා අප වෙත පැමිණි විට, සේවාදායකය නැවත ආරම්භ කිරීම ඔහුට විශාල ගනුදෙනුවක් වේ. ඔහුට එහි ව්‍යාපාරයක් තිබේ. තවද ඔවුන් NUMA නිසා ගැටලු අත්විඳිති. එමනිසා, අපි එය නැවත පණගැන්වීමට වඩා අඩු ආක්‍රමණශීලී ක්‍රම වලින් අක්‍රිය කිරීමට උත්සාහ කරමු, නමුත් එය අක්‍රිය කර ඇත්දැයි පරීක්ෂා කිරීමට ප්‍රවේශම් වන්න. මක්නිසාද යත්, අත්දැකීම් පෙන්නුම් කරන පරිදි, අපි මාපිය PostgreSQL ක්‍රියාවලිය මත NUMA අක්‍රිය කිරීම හොඳය, නමුත් එය ක්‍රියාත්මක වීම කිසිසේත් අවශ්‍ය නොවේ. අපි පරීක්ෂා කර බැලිය යුතුයි ඇය ඇත්තටම ක්‍රියා විරහිත කර ඇත්ද යන්න.

Robert Haas ගේ හොඳ පෝස්ට් එකක් තියෙනවා. මෙය PostgreSQL කැපකරුවන්ගෙන් එකකි. සියලුම පහත් මට්ටමේ ජිබ්ලට් වල ප්‍රධාන සංවර්ධකයන්ගෙන් එකකි. තවද ඔබ මෙම සටහනේ සබැඳි අනුගමනය කරන්නේ නම්, ඔවුන් NUMA මිනිසුන්ට ජීවිතය දුෂ්කර කළ ආකාරය පිළිබඳ වර්ණවත් කථා කිහිපයක් විස්තර කරයි. බලන්න, අපගේ දත්ත සමුදාය හොඳින් ක්‍රියා කිරීම සඳහා සේවාදායකයේ වින්‍යාස කළ යුතු දේ පිළිබඳ පද්ධති පරිපාලක පිරික්සුම් ලැයිස්තුව අධ්‍යයනය කරන්න. මෙම සැකසුම් ලියා පරීක්ෂා කර බැලිය යුතුය, එසේ නොමැති නම් එය ඉතා හොඳ නොවනු ඇත.

මම කතා කරන සියලුම සැකසුම් සඳහා මෙය අදාළ වන බව කරුණාවෙන් සලකන්න. නමුත් සාමාන්‍යයෙන් දත්ත සමුදායන් වැරදි ඉවසීම සඳහා මාස්ටර්-ස්ලේව් ප්‍රකාරයේදී එකතු කරනු ලැබේ. මේ සෙටින්ග්ස් වහලාට දාන්න අමතක කරන්න එපා මොකද දවසක ඔයාට අනතුරක් වෙලා ඔයා වහල්කමට මාරු වෙලා ඒක ස්වාමියා වෙන නිසා.

හදිසි අවස්ථාවකදී, සෑම දෙයක්ම ඉතා නරක වූ විට, ඔබේ දුරකථනය නිරන්තරයෙන් නාද වන විට සහ ඔබේ ප්‍රධානියා විශාල පොල්ලකින් දුවන විට, ඔබට පරීක්ෂා කිරීම ගැන සිතන්නට කාලයක් නොමැත. එමෙන්ම එහි ප්‍රතිඵල ඉතා විනාශකාරී විය හැක.

ඊළඟ කරුණ විශාල පිටු වේ. විශාල පිටු වෙන වෙනම පරීක්ෂා කිරීමට අපහසු වන අතර, මෙය කළ හැකි මිණුම් සලකුණු තිබුණද, එසේ කිරීමෙන් පලක් නැත. ඒවා Google කිරීමට පහසුයි.

කාරණය කුමක්ද? ඔබට RAM විශාල ප්‍රමාණයක් සහිත ඉතා මිල අධික සේවාදායකයක් නොමැත, උදාහරණයක් ලෙස, 30 GB ට වැඩි. ඔබ විශාල පිටු භාවිතා නොකරයි. මෙයින් අදහස් කරන්නේ මතක භාවිතය සම්බන්ධයෙන් ඔබට අනිවාර්යෙන්ම පොදු කාර්ය භාරයක් ඇති බවයි. තවද මෙම උඩිස් කොටස වඩාත් ප්රසන්න නොවේ.

ඇයි ඒ? ඉතින් මොකද වෙන්නේ? මෙහෙයුම් පද්ධතිය කුඩා කැබලිවලට මතකය වෙන් කරයි. එය ඉතා පහසුයි, එය ඓතිහාසිකව සිදු වූ ආකාරයයි. අපි විස්තරාත්මකව ගියහොත්, OS විසින් අතථ්‍ය ලිපින භෞතික ඒවාට පරිවර්තනය කළ යුතුය. තවද මෙම ක්‍රියාවලිය සරලම නොවේ, එබැවින් පරිවර්තන Lookaside Buffer (TLB) හි මෙම මෙහෙයුමේ ප්‍රතිඵලය OS විසින් හැඹිලිගත කරයි.

TLB යනු හැඹිලියක් බැවින්, හැඹිලියකට ආවේණික වූ සියලුම ගැටළු මෙම තත්වය තුළ පැන නගී. පළමුව, ඔබට විශාල RAM ප්‍රමාණයක් තිබේ නම් සහ එය කුඩා කැබලිවලට වෙන් කර ඇත්නම්, මෙම බෆරය ඉතා විශාල වේ. හැඹිලිය විශාල නම්, එය හරහා සෙවීම මන්දගාමී වේ. උඩිස් හෙඩ් සෞඛ්‍ය සම්පන්න වන අතර එයම ඉඩක් ගනී, එනම් වැරදි දෙයක් මගින් RAM පරිභෝජනය කරයි. මෙම අවස්ථාවේ.

දෙක - එවැනි තත්වයක් තුළ හැඹිලිය වැඩි වන තරමට, ඔබට හැඹිලි මග හැරීමට ඇති ඉඩකඩ වැඩිය. තවද මෙම හැඹිලියේ ප්‍රමාණය වැඩි වන විට එහි කාර්යක්ෂමතාවය වේගයෙන් අඩු වේ. එබැවින්, මෙහෙයුම් පද්ධති සරල ප්රවේශයක් ඉදිරිපත් කළේය. එය ලිනක්ස් වල බොහෝ කාලයක් භාවිතා කර ඇත. එය බොහෝ කලකට පෙර FreeBSD හි දර්ශනය විය. නමුත් අපි ලිනක්ස් ගැන කතා කරනවා. මේවා විශාල පිටු.

තවද මෙහිදී සැලකිය යුතු කරුණක් වන්නේ අදහසක් ලෙස විශාල පිටු මුලින් තල්ලු කරනු ලැබුවේ Oracle සහ IBM ඇතුළත් ප්‍රජාවන් විසිනි, එනම් දත්ත සමුදා නිෂ්පාදකයින් මෙය දත්ත සමුදායන් සඳහාද ප්‍රයෝජනවත් වනු ඇතැයි තරයේ සිතූහ.

තවද මෙය PostgreSQL සමඟ මිතුරු වන්නේ කෙසේද? පළමුව, ලිනක්ස් කර්නලයේ විශාල පිටු සක්‍රීය කළ යුතුය.

දෙවනුව, ඒවා sysctl පරාමිතිය මගින් පැහැදිලිව සඳහන් කළ යුතුය - කීයක් තිබේද යන්න. මෙහි ඇති අංක සමහර පැරණි සේවාදායකයකින්. ඔබට විශාල පිටු එහි ගැළපෙන පරිදි බෙදාගත් බෆර කීයක් තිබේදැයි ගණනය කළ හැක.

ඔබේ සම්පූර්ණ සේවාදායකයම PostgreSQL සඳහා කැපවී ඇත්නම්, හොඳ ආරම්භක ලක්ෂ්‍යයක් වන්නේ ඔබේ දත්ත සමුදාය අනිවාර්යයෙන්ම මෙම 25% ට ගැළපෙන බව ඔබට විශ්වාස නම් RAM වලින් 75% ක් හෝ හවුල් බෆර සඳහා 75%ක් වෙන් කිරීමයි. ආරම්භක ස්ථානය එක. සහ සලකා බලන්න, ඔබට 256 GB RAM තිබේ නම්, ඒ අනුව, ඔබට විශාල බෆර 64 GB ඇත. යම් ආන්තිකයක් සමඟ ආසන්න වශයෙන් ගණනය කරන්න - මෙම රූපය සැකසිය යුත්තේ කුමක් ද යන්න.

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 තිබේ නම්, ඔබට උත්සාහ කළ හැකිය, එය සැමවිටම ආරක්ෂිතයි.

සක්‍රිය නම්, විශාල පිටු වලින් එය තෝරාගත නොහැකි නම් එය සරලව ආරම්භ නොවේ. මෙන්න එය දැනටමත් කවුද සහ වඩා හොඳ කුමක්ද යන්න ගැන ය. නමුත් ඔබ උත්සාහ කර ඇත්නම්, ඔබට උද්දීපනය කළ යුතු දේ ඇත්ත වශයෙන්ම තිබේදැයි පරීක්ෂා කරන්න, මන්ද දෝෂ සඳහා විශාල ඉඩක් ඇත. දැනට මෙම ක්‍රියාකාරීත්වය ක්‍රියාත්මක වන්නේ Linux මත පමණි.

අපි තවත් ඉදිරියට යාමට පෙර තවත් කුඩා සටහනක්. විනිවිද පෙනෙන විශාල පිටු තවමත් PostgreSQL ගැන නොවේ. ඔහුට ඒවා සාමාන්‍යයෙන් භාවිතා කළ නොහැක. එවැනි වැඩ බරක් සඳහා විනිවිද පෙනෙන විශාල පිටු සමඟ, විශාල හවුල් මතකයක් අවශ්‍ය වූ විට, ප්‍රතිලාභ ලැබෙන්නේ ඉතා විශාල වෙළුම් වලින් පමණි. ඔබට ටෙරාබයිට් මතකයක් තිබේ නම් මෙය ක්‍රියාත්මක විය හැක. අපි වැඩිපුර එදිනෙදා යෙදුම් ගැන කතා කරන්නේ නම්, ඔබට ඔබේ යන්ත්‍රයේ 32, 64, 128, 256 GB මතකයක් ඇති විට, සාමාන්‍ය විශාල පිටු හරි, අපි විනිවිද පෙනෙන අක්‍රිය කරන්නෙමු.

මතකය පිළිබඳ අවසාන දෙය fruitut සමඟ කෙලින්ම සම්බන්ධ නොවේ, එය ඇත්ත වශයෙන්ම ඔබේ ජීවිතය විනාශ කළ හැකිය. සේවාදායකය නිරන්තරයෙන් හුවමාරු වීම නිසා සියලුම ප්‍රතිදානය බෙහෙවින් බලපානු ඇත.

තවද මෙය ක්රම කිහිපයකින් ඉතා අප්රසන්න වනු ඇත. තවද ප්‍රධාන ගැටළුව වන්නේ නවීන කර්නල් පැරණි ලිනක්ස් කර්නල් වලට වඩා තරමක් වෙනස් ලෙස හැසිරීමයි. තවද මෙම කාරණය ඉදිරියට යාම තරමක් අප්‍රසන්න ය, මන්ද අපි swap සමඟ යම් ආකාරයක වැඩක් ගැන කතා කරන විට, එය අවසන් වන්නේ OOM-ඝාතකයා අකාලයේ පැමිණීමෙනි. නියමිත වේලාවට නොපැමිණි සහ PostgreSQL අතහැර දැමූ OOM-ඝාතකයා අප්රසන්න ය. සෑම කෙනෙකුම මේ ගැන දැන ගනු ඇත, එනම් අවසාන පරිශීලකයා දක්වා.

සිද්ධවන්නේ කුමක් ද? ඔබට එහි විශාල RAM ප්‍රමාණයක් ඇත, සියල්ල හොඳින් ක්‍රියාත්මක වේ. නමුත් කිසියම් හේතුවක් නිසා සේවාදායකය swap හි එල්ලී ඇති අතර මේ නිසා මන්දගාමී වේ. මතකය ගොඩක් ඇති බව පෙනේ, නමුත් මෙය සිදු වේ.

පෙර, අපි vm.swappiness ශුන්‍යයට සැකසීමට උපදෙස් දුන්නෙමු, එනම් swap අක්‍රිය කරන්න. මීට පෙර, 32 GB RAM සහ අනුරූප බෙදාගත් බෆර විශාල මුදලක් බව පෙනෙන්නට තිබුණි. swap එකේ ප්‍රධාන අරමුණ තමයි අපි වැටුනොත් කබොල විසි කරන්න තැනක් තිබීම. තවද එය තවදුරටත් විශේෂයෙන් ඉටු නොවීය. එතකොට ඔයා මේ කබොලෙන් මොකක්ද කරන්න යන්නේ? මෙය විශේෂයෙන්ම එවැනි ප්‍රමාණයකින් swap අවශ්‍ය වන්නේ මන්දැයි ඉතා පැහැදිලි නැති කාර්යයකි.

නමුත් වඩාත් නවීන, එනම්, කර්නලයේ තුන්වන අනුවාද වල හැසිරීම වෙනස් වී ඇත. තවද ඔබ swap බිංදුවට සකසන්නේ නම්, එනම් එය ක්‍රියා විරහිත කළහොත්, ඉක්මනින් හෝ පසුව, යම් RAM ප්‍රමාණයක් ඉතිරිව තිබුණද, වඩාත් තීව්‍ර පාරිභෝගිකයින් මරා දැමීමට OOM ඝාතකයෙක් ඔබ වෙත පැමිණෙනු ඇත. මක්නිසාද යත් එවැනි වැඩ බරක් සමඟ අපට තවමත් ටිකක් ඉතිරිව ඇති බවත්, අපි පිටතට පනින බවත් ඔහු සලකනු ඇත, එනම්, පද්ධති ක්‍රියාවලියට ඇණ ගැසීමට නොව, අඩු වැදගත් දෙයක් ඇණ ගැසීමට. මෙම අඩු වැදගත්කම හවුල් මතකයේ තීව්‍ර පාරිභෝගිකයා වනු ඇත, එනම් තැපැල් ස්ථානාධිපති. ඊට පසු, පදනම යථා තත්වයට පත් කිරීමට අවශ්‍ය නැතිනම් එය හොඳ වනු ඇත.

එමනිසා, දැන් පෙරනිමිය, මට මතක ඇති පරිදි, බොහෝ බෙදාහැරීම් කොහේ හරි 6 ක් පමණ වේ, එනම් මතකය කොපමණ ප්‍රමාණයක් ඉතිරිව තිබේද යන්න මත ඔබ swap භාවිතා කිරීම ආරම්භ කළ යුත්තේ කුමන අවස්ථාවේදීද යන්නයි. අපි දැන් vm.swappiness = 1 සැකසීමට නිර්දේශ කරමු, මන්ද මෙය ප්‍රායෝගිකව එය ක්‍රියා විරහිත කරයි, නමුත් අනපේක්ෂිත ලෙස පැමිණ මුළු දේම මරා දැමූ OOM-ඝාතකයෙකුට සමාන ප්‍රයෝග ලබා නොදේ.

ඊළඟට කුමක් ද? අපි දත්ත සමුදායේ කාර්ය සාධනය ගැන කතා කරන විට සහ ක්රමයෙන් තැටි දෙසට ගමන් කරන විට, සෑම කෙනෙකුම ඔවුන්ගේ හිස අල්ලා ගැනීමට පටන් ගනී. මන්ද තැටිය මන්දගාමී වන අතර මතකය වේගවත් බව කුඩා කල සිටම සෑම කෙනෙකුටම හුරුපුරුදු සත්යය. තවද දත්ත සමුදායේ තැටි ක්‍රියාකාරීත්වයේ ගැටළු ඇති බව කවුරුත් දනිති.

මුරපොලවල් කරල් හා සම්බන්ධ ප්‍රධාන PostgreSQL කාර්ය සාධන ගැටළුව තැටිය මන්දගාමී නිසා සිදු නොවේ. මෙය බොහෝ විට මතකය සහ තැටි කලාප පළල සමතුලිත නොවීම නිසා විය හැකිය. කෙසේ වෙතත්, ඒවා විවිධ ස්ථානවල සමතුලිත නොවිය හැකිය. PostgreSQL වින්‍යාස කර නැත, OS වින්‍යාස කර නැත, දෘඩාංග වින්‍යාස කර නැත සහ දෘඩාංග වැරදියි. තවද මෙම ගැටළුව සිදුවන්නේ සෑම දෙයක්ම සිදුවිය යුතු ආකාරයටම සිදු වුවහොත්, එනම් එක්කෝ බරක් නොමැති නම්, නැතහොත් සැකසුම් සහ දෘඩාංග හොඳින් තෝරාගෙන තිබේ නම් පමණි.

එය කුමක්ද සහ එය පෙනෙන්නේ කෙසේද? සාමාන්‍යයෙන් PostgreSQL සමඟ වැඩ කරන පුද්ගලයින් එක් වරකට වඩා මෙම කාරණයට ඇතුළු වී ඇත. මම පැහැදිලි කරන්නම්. මා කී පරිදි, බෙදාගත් මතකයේ ඇති අපිරිසිදු පිටු තැටියට දැමීමට PostgreSQL වරින් වර මුරපොලවල් කරයි. අපට හවුල් මතකය විශාල ප්‍රමාණයක් තිබේ නම්, මුරපොල තැටියට දැඩි බලපෑමක් ඇති කිරීමට පටන් ගනී, මන්ද එය මෙම පිටු fsync සමඟ ඉවතලන බැවිනි. එය කර්නල් බෆරය වෙත පැමිණෙන අතර fsync භාවිතයෙන් තැටි වෙත ලියා ඇත. තවද මෙම ව්‍යාපාරයේ පරිමාව විශාල නම්, අපට අප්රසන්න බලපෑමක් නිරීක්ෂණය කළ හැකිය, එනම් තැටි ඉතා විශාල ලෙස භාවිතා කිරීම.

මෙන්න මට පින්තූර දෙකක් තියෙනවා. එය කුමක්දැයි මම දැන් පැහැදිලි කරමි. මේවා කාල සහසම්බන්ධිත ප්‍රස්ථාර දෙකකි. පළමු ප්රස්ථාරය තැටි භාවිතයයි. මෙන්න මේ අවස්ථාවේ දී එය 90% කට ආසන්න වේ. ඔබට භෞතික තැටි සමඟ දත්ත සමුදාය අසමත් වීමක් තිබේ නම්, RAID පාලක භාවිතය 90% කින් නම්, මෙය නරක ආරංචියකි. ඒ කියන්නේ තව ටිකක් වැඩි වෙලා 100ට ඇවිත් I/O එක නතර වෙනවා.

ඔබට තැටි අරාවක් තිබේ නම්, එය තරමක් වෙනස් කතාවකි. එය වින්‍යාස කර ඇති ආකාරය, එය කුමන ආකාරයේ අරාවක් යනාදිය මත රඳා පවතී.

සහ සමාන්තරව, අභ්‍යන්තර postgres දසුනෙන් ප්‍රස්ථාරයක් මෙහි වින්‍යාස කර ඇත, එය මුරපොල සිදු වන ආකාරය කියයි. තවද මෙහි ඇති කොළ පැහැයෙන් පෙන්නුම් කරන්නේ මෙම අපිරිසිදු පිටු, එම මොහොතේ සමමුහුර්තකරණය සඳහා මෙම මුරපොලට කොපමණ බෆර පැමිණ තිබේද යන්නයි. තවද මෙහිදී ඔබ දැනගත යුතු ප්රධානතම දෙය මෙයයි. අපට පෙනෙන්නේ මෙහි පිටු රාශියක් ඇති බවත්, යම් අවස්ථාවක අපි පුවරුවට පහර දෙන බවත්, එනම්, අපි ලිවූ සහ ලිවූ බවත්, මෙහි තැටි පද්ධතිය ඉතා කාර්යබහුල බව පැහැදිලිය. තවද අපගේ මුරපොල තැටියට ඉතා දැඩි බලපෑමක් ඇති කරයි. ඉතා මැනවින්, තත්වය මේ ආකාරයෙන් දිස්විය යුතුය, එනම් අපට මෙහි පටිගත කිරීම් අඩු විය. ඒවගේම අපිට ඒක සෙටින්ග්ස් වලින් හදාගන්න පුලුවන් ඒක දිගටම මේ විදියටම තියේවි. එනම්, ප්රතිචක්රීකරණය කුඩා වේ, නමුත් කොහේ හරි අපි මෙහි යමක් ලියන්නෙමු.

මෙම ගැටලුව ජය ගැනීමට කුමක් කළ යුතුද? ඔබ දත්ත සමුදාය යටතේ IO නතර කර ඇත්නම්, මෙයින් අදහස් කරන්නේ ඔවුන්ගේ ඉල්ලීම් ඉටු කිරීමට පැමිණි සියලුම පරිශීලකයින් බලා සිටින බවයි.

ඔබ Linux හි දෘෂ්ටිකෝණයෙන් බැලුවහොත්, ඔබ හොඳ දෘඪාංගයක් ගෙන, එය නිවැරදිව වින්‍යාස කර, PostgreSQL සාමාන්‍යයෙන් වින්‍යාස කර ඇති අතර එමඟින් මෙම මුරපොලවල් අඩුවෙන් සිදු වන පරිදි, කාලයත් සමඟ ඒවා එකිනෙක අතර පැතිරේ නම්, ඔබ පෙරනිමි Debian පරාමිති වෙත පිවිසෙන්න. බොහෝ Linux බෙදාහැරීම් සඳහා, මෙය පින්තූරයයි: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

එයින් අදහස් කරන්නේ කුමක් ද? කර්නලය 2.6 වෙතින් එක් ෆ්ලෂ් කරන යක්ෂයෙක් දර්ශනය විය. Pdglush, භාවිතා කරන්නේ කවුරුන්ද යන්න මත පදනම්ව, කර්නල් බෆරයෙන් අපිරිසිදු පිටු පසුබිමෙන් ඉවතලීමේ සහ අපිරිසිදු පිටු කුමක් වුවත් ඉවත දැමීමට අවශ්‍ය වූ විට, පසුබිම් ඉවතලීම උදව් නොකරන විට ඉවත දැමීමේ යෙදී සිටී.

පසුබිම පැමිණෙන්නේ කවදාද? සේවාදායකයේ ඇති මුළු RAM ප්‍රමාණයෙන් 10% ක් කර්නල් බෆරයේ අපිරිසිදු පිටු විසින් අල්ලාගෙන සිටින විට, පසුබිමේ විශේෂ ලිවීමේ කාර්යයක් කැඳවනු ලැබේ. එය පසුබිම වන්නේ ඇයි? පරාමිතියක් ලෙස, පිටු කීයක් කපා හැරිය යුතුද යන්න සැලකිල්ලට ගනී. තවද, ඔහු N පිටු කපා හරින බව කියමු. ඒ වගේම ටික වෙලාවකින් මේ දේ නිදිමතයි. ඊට පස්සේ ඇය ආයෙත් ඇවිත් තවත් පිටු කිහිපයක් පිටපත් කරනවා.

මෙය අතිශය සරල කතාවකි. මෙතන තියෙන ප්‍රශ්නය හරියට පිහිනුම් තටාකයක් වගේ එක පයිප්පයකට වත් කළාම තවත් නලයකට ගලා යනවා. අපගේ මුරපොල පැමිණි අතර එය ඉවතලීම සඳහා අපිරිසිදු පිටු කිහිපයක් එව්වේ නම්, ක්‍රමයෙන් මුළු දේම කර්නල් බෆරය pgflush වෙතින් මනාව විසඳනු ඇත.

මෙම අපිරිසිදු පිටු දිගටම එකතු වුවහොත්, ඒවා 20% දක්වා එකතු වේ, ඉන්පසු OS ප්‍රමුඛතාවය වන්නේ තැටියට සම්පූර්ණ දේ ලිවීමයි, මන්ද බලය අසමත් වන අතර සෑම දෙයක්ම අපට නරක වනු ඇත. උදාහරණයක් ලෙස, අපට මෙම දත්ත අහිමි වනු ඇත.

උපක්රමය කුමක්ද? උපක්‍රමය නම්, නවීන ලෝකයේ මෙම පරාමිතීන් යන්ත්‍රයේ ඇති මුළු RAM ප්‍රමාණයෙන් 20 සහ 10% ක් වන අතර, ඒවා ඔබ සතුව ඇති ඕනෑම තැටි පද්ධතියක ප්‍රතිදානය අනුව නියත වශයෙන්ම භයානක ය.

ඔබ සතුව 128 GB RAM එකක් ඇතැයි සිතන්න. ඔබගේ තැටි පද්ධතියට 12,8 GB පැමිණේ. තවද ඔබට එහි කුමන හැඹිලියක් තිබුණත්, ඔබට එහි කුමන අරාවක් තිබුණත්, ඒවා එතරම් කාලයක් පවතින්නේ නැත.

එබැවින්, ඔබගේ RAID පාලකයේ හැකියාවන් මත පදනම්ව මෙම අංක වහාම සකස් කරන ලෙස අපි නිර්දේශ කරමු. මම වහාම 512 MB හැඹිලි සහිත පාලකයක් සඳහා මෙහි නිර්දේශයක් කළෙමි.

සෑම දෙයක්ම ඉතා සරල ලෙස සලකනු ලැබේ. ඔබට බයිට් වලින් vm.dirty_background දැමිය හැක. තවද මෙම සැකසුම් පෙර දෙක අවලංගු කරයි. එක්කෝ අනුපාතය පෙරනිමියෙන් වේ, නැතහොත් බයිට් ඇති ඒවා සක්‍රිය කර ඇත, එවිට බයිට් ඇති ඒවා ක්‍රියා කරයි. නමුත් මම DBA උපදේශකයෙකු වන අතර විවිධ සේවාදායකයින් සමඟ වැඩ කරන බැවින්, මම පිදුරු ඇඳීමට උත්සාහ කරමි, එබැවින් බයිට් වලින් නම්, බයිට් වලින්. හොඳ පරිපාලකයෙකු සේවාදායකයට වැඩි මතකයක් එකතු නොකරන බවට, එය නැවත ආරම්භ නොකරන බවට සහ රූපය එලෙසම පවතින බවට කිසිවෙකු සහතිකයක් ලබා දුන්නේ නැත. සෑම දෙයක්ම සහතිකයක් සමඟ ගැලපෙන පරිදි මෙම සංඛ්යා ගණනය කරන්න.

ඔබ ගැලපෙන්නේ නැත්නම් කුමක් සිදුවේද? ඕනෑම ෆ්ලෂ් කිරීම ඵලදායී ලෙස නතර කර ඇති බව මම ලියා ඇත, නමුත් ඇත්ත වශයෙන්ම මෙය කථන රූපයකි. මෙහෙයුම් පද්ධතියට විශාල ගැටළුවක් ඇත - එහි අපිරිසිදු පිටු රාශියක් ඇත, එබැවින් ඔබේ සේවාදායකයින් උත්පාදනය කරන IO ඵලදායී ලෙස නතර වේ, එනම් දත්ත ගබඩාවට sql විමසුමක් යැවීමට යෙදුම පැමිණ ඇත, එය බලා සිටී. දත්ත සමුදාය මුරපොලක් විසින් අල්ලාගෙන ඇති බැවින් එයට ඕනෑම ආදානයක්/ප්‍රතිදානයක් අඩුම ප්‍රමුඛතාවයකි. ඇය අවසන් කරන්නේ කවදාද යන්න සම්පූර්ණයෙන්ම අපැහැදිලි ය. තවද ඔබ පසුබිම් නොවන ෆ්ලෂ් කිරීම ලබාගෙන ඇති විට, එයින් අදහස් වන්නේ ඔබගේ සියලුම IO එය විසින් අත්පත් කරගෙන ඇති බවයි. එය අවසන් වන තුරු, ඔබ කිසිවක් නොකරනු ඇත.

මෙම වාර්තාවේ විෂය පථයට එහා ගිය තවත් වැදගත් කරුණු දෙකක් මෙහි ඇත. මෙම සිටුවම් postgresql.conf හි ඇති සැකසුම් වලට ගැලපිය යුතුය, එනම් මුරපොල සැකසීම්. තවද ඔබගේ තැටි පද්ධතිය ප්‍රමාණවත් ලෙස වින්‍යාස කර තිබිය යුතුය. ඔබට RAID මත හැඹිලියක් තිබේ නම්, එය බැටරියක් තිබිය යුතුය. අය බැටරියක් නොමැතිව හොඳ හැඹිලි සහිත RAID මිලදී ගනී. ඔබට RAID හි SSD තිබේ නම්, ඒවා සේවාදායකයන් විය යුතුය, එහි ධාරිත්‍රක තිබිය යුතුය. මෙන්න සවිස්තර පිරික්සුම් ලැයිස්තුවක්. PostgreSQL හි කාර්ය සාධන තැටියක් වින්‍යාස කරන්නේ කෙසේද යන්න පිළිබඳ මගේ වාර්තාව මෙම සබැඳියේ අඩංගු වේ. මෙම පිරික්සුම් ලැයිස්තු සියල්ලම එහි තිබේ.

ජීවිතය ඉතා දුෂ්කර කළ හැකි තවත් මොනවාද? මේවා පරාමිති දෙකකි. ඒවා සාපේක්ෂව අලුත් ය. පෙරනිමියෙන්, ඒවා විවිධ යෙදුම්වල ඇතුළත් කළ හැකිය. තවද ඒවා වැරදි ලෙස ක්‍රියාත්මක කළහොත් ජීවිතය දුෂ්කර කර ගත හැකිය.

සාපේක්ෂව අලුත් දේවල් දෙකක් තියෙනවා. ඔවුන් දැනටමත් තුන්වන හරය තුළ පෙනී සිට ඇත. මෙය නැනෝ තත්පර වලින් sched_migration_cost වන අතර පෙරනිමියෙන් එකක් වන sched_autogroup_enabled වේ.

සහ ඔවුන් ඔබේ ජීවිතය විනාශ කරන්නේ කෙසේද? කාලසටහන්_සංක්‍රමණ_පිරිවැය යනු කුමක්ද? Linux මත, උපලේඛකයාට CPU එකකින් තවත් CPU එකකට ක්‍රියාවලියක් සංක්‍රමණය කළ හැක. තවද විමසුම් ක්‍රියාත්මක කරන PostgreSQL සඳහා වෙනත් CPU එකකට සංක්‍රමණය වීම සම්පූර්ණයෙන්ම අපැහැදිලි වේ. මෙහෙයුම් පද්ධතියේ දෘෂ්ටි කෝණයෙන්, ඔබ openoffice සහ terminal අතර කවුළු මාරු කරන විට, මෙය හොඳ විය හැක, නමුත් දත්ත සමුදායක් සඳහා මෙය ඉතා නරක ය. එබැවින්, සාධාරණ ප්‍රතිපත්තියක් වන්නේ සංක්‍රමණ_පිරිවැය යම් විශාල අගයකට, අවම වශයෙන් නැනෝ තත්පර දහස් ගණනකට සැකසීමයි.

උපලේඛකයා සඳහා මෙයින් අදහස් කරන්නේ කුමක්ද? මෙම කාලය තුළ ක්රියාවලිය තවමත් උණුසුම් බව සලකනු ලැබේ. එනම්, ඔබ දිගු කලක් තිස්සේ යමක් කරමින් දිගුකාලීන ගනුදෙනුවක් ඇත්නම්, කාලසටහන්කරුට මෙය වැටහෙනු ඇත. මෙම කාලය අවසන් වන තුරු, මෙම ක්‍රියාවලිය කොතැනකටවත් සංක්‍රමණය වීමට අවශ්‍ය නොවන බව ඔහු උපකල්පනය කරනු ඇත. ඒ සමඟම ක්‍රියාවලිය යමක් කරන්නේ නම්, එය ඕනෑම තැනකට සංක්‍රමණය නොවනු ඇත, එය එයට වෙන් කර ඇති CPU මත නිහඬව ක්‍රියා කරයි. සහ ප්රතිඵලය විශිෂ්ටයි.

දෙවන කරුණ ස්වයං සමූහයයි. නවීන දත්ත සමුදායන් හා සම්බන්ධ නොවන නිශ්චිත කාර්ය භාරයන් සඳහා හොඳ අදහසක් ඇත - මෙය ඔවුන් දියත් කරන ලද අතථ්‍ය පර්යන්තය මගින් ක්‍රියාවලි සමූහගත කිරීමයි. සමහර කාර්යයන් සඳහා මෙය පහසු වේ. ප්‍රායෝගිකව, PostgreSQL යනු තනි පර්යන්තයකින් ධාවනය වන prefork සහිත බහු-ක්‍රියාවලි පද්ධතියකි. ඔබට අගුළු ලේඛකයෙකු, මුරපොලක් ඇති අතර, ඔබගේ සියලුම සේවාදායක ඉල්ලීම් CPU එකකට එක් උපලේඛකයකට කාණ්ඩගත කෙරේ. එකිනෙකාට බාධා කිරීමට සහ ඔහුව වැඩි වේලාවක් වාඩිලා ගැනීමට ඔහු නිදහස් වන තෙක් ඔවුන් එකමුතුව බලා සිටිනු ඇත. එහෙම ලෝඩ් එකකදී සම්පූර්ණයෙන්ම අනවශ්‍ය කතාවක් ඒ නිසා ඕෆ් කරන්න ඕන.

මගේ සගයා වන ඇලෙක්සි ලෙසොව්ස්කි සරල pgbench සමඟ පරීක්ෂණ සිදු කළේය, එහිදී ඔහු විශාල අනුපිළිවෙලකින් සංක්‍රමණ_ පිරිවැය වැඩි කර ස්වයංක්‍රීය සමූහය ක්‍රියා විරහිත කළේය. නරක දෘඩාංගවල වෙනස 10% ක් පමණ විය. විමසුම් වේගයට සමාන වෙනස්කම් වල ප්‍රතිඵල ලබා දෙන postgres තැපැල් ලැයිස්තුවේ සාකච්ඡාවක් ඇත බලපෑම 50%. මේ වගේ කතා ඕන තරම් තියෙනවා.

අවසාන වශයෙන්, බලශක්ති ඉතිරිකිරීමේ ප්රතිපත්තිය ගැන. හොඳ දෙය නම් ලිනක්ස් දැන් ලැප්ටොප් එකක භාවිතා කළ හැකි වීමයි. තවද එය බැටරිය හොඳින් භාවිතා කරනු ඇත. නමුත් හදිසියේම මෙය සේවාදායකයේ ද සිදුවිය හැකි බව පෙනේ.

එපමණක් නොව, ඔබ කිසියම් සත්කාරක සමාගමකින් සේවාදායකයන් කුලියට ගන්නේ නම්, ඔබට වඩා හොඳ කාර්ය සාධනයක් ඇති බව “හොඳ” සත්කාරකයින් ගණන් ගන්නේ නැත. ඔවුන්ගේ කාර්යය වන්නේ ඔවුන්ගේ යකඩ හැකි තරම් කාර්යක්ෂමව භාවිතා කිරීම සහතික කිරීමයි. එබැවින්, පෙරනිමියෙන් ඔවුන්ට මෙහෙයුම් පද්ධතියේ ලැප්ටොප් බලශක්ති සුරැකීමේ මාදිලිය සක්රිය කළ හැකිය.

ඔබ අධික බරක් යටතේ දත්ත සමුදායක් සහිත සේවාදායකයක් මත මෙම දේවල් භාවිතා කරන්නේ නම්, එවිට ඔබේ තේරීම acpi_cpufreq + permormance වේ. Ondemand සමඟ පවා ගැටළු ඇති වේ.

Intel_pstate යනු තරමක් වෙනස් ධාවකයකි. දැන් මෙයට මනාප ලබා දී ඇත, එය පසුව වන අතර වඩා හොඳින් ක්‍රියා කරයි.

සහ, ඒ අනුව, ආණ්ඩුකාරවරයා කාර්ය සාධනය පමණි. Ondemand, powersave සහ අනෙකුත් සියල්ල ඔබ ගැන නොවේ.

ඔබ Powersave සක්‍රීය කළහොත් PostgreSQL විග්‍රහ කිරීමේ ප්‍රතිඵල විශාලත්වයේ අනුපිළිවෙල කිහිපයකින් වෙනස් විය හැක, මන්ද ප්‍රායෝගිකව ඔබගේ දත්ත ගබඩාව යටතේ ඇති CPU සම්පූර්ණයෙන්ම අනපේක්ෂිත ආකාරයෙන් ක්‍රියාත්මක වන බැවිනි.

මෙම අයිතම පෙරනිමියෙන් ඇතුළත් කළ හැක. ඔවුන් එය පෙරනිමියෙන් ක්‍රියාත්මක කර ඇත්දැයි බැලීමට හොඳින් බලන්න. මෙය ඇත්තෙන්ම විශාල ගැටලුවක් විය හැකිය.

අවසානයේදී, මට අවශ්‍ය වූයේ අපගේ PosgreSQL-උපදේශන DBA කණ්ඩායමේ, එනම් Max Boguk සහ Alexey Lesovsky, දිනපතා මේ කාරණය සම්බන්ධයෙන් ඉදිරියට යන පිරිමි ළමයින්ට ස්තූතියි. තවද අපි අපගේ ගනුදෙනුකරුවන් සඳහා අපට කළ හැකි උපරිමය කිරීමට උත්සාහ කරමු, එවිට ඒ සියල්ල ඔවුන් සඳහා ක්‍රියාත්මක වේ. එය ගුවන් ආරක්ෂණ උපදෙස් සමඟ සමාන ය. මෙහි සෑම දෙයක්ම ලේ වලින් ලියා ඇත. මෙම සෑම ගෙඩියක්ම යම් ආකාරයක ගැටලුවක ක්රියාවලිය තුළ දක්නට ලැබේ. ඒවා ඔබ සමඟ බෙදා ගැනීමට මම සතුටු වෙමි.

ප්‍රශ්න:

ඔයාට ස්තූතියි! උදාහරණයක් ලෙස, සමාගමකට මුදල් ඉතිරි කර දත්ත සමුදාය සහ යෙදුම් තර්කනය එක් සේවාදායකයක් මත තැබීමට අවශ්‍ය නම්, හෝ සමාගම PostgreSQL බහාලුමක් තුළ ක්‍රියාත්මක වන microservice architectures හි විලාසිතාමය ප්‍රවණතාව අනුගමනය කරන්නේ නම්. උපක්රමය කුමක්ද? 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