postgresql හි ඉදිමීමට තුඩු දෙන යෙදුම්වල සාමාන්‍ය දෝෂ. Andrey Salnikov

Andrey Salnikov විසින් "postgresql හි ඉදිමීමට තුඩු දෙන යෙදුම්වල සාමාන්‍ය දෝෂ" 2016 ආරම්භයේ සිට වාර්තාවේ පිටපත කියවීමට මම ඔබට යෝජනා කරමි.

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

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

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

නරක දේවල් සිදු වූ ආකාරය පිළිබඳ භයානක පින්තූර සහිත උදාහරණ තුනක් මම ඔබට දෙන්නෙමි. එහි සිදුවන යාන්ත්‍රණය ගැන මම ඔබට කෙටියෙන් කියන්නම්. ඔවුන් සමඟ කටයුතු කරන්නේ කෙසේද, ඒවා සිදු වූ විට සහ වැරදි වළක්වා ගැනීම සඳහා භාවිතා කළ යුතු වැළැක්වීමේ ක්‍රම මොනවාද? මම ඔබට සහායක මෙවලම් ගැන කියමි සහ ප්රයෝජනවත් සබැඳි ලබා දෙන්නෙමි.

මම මේස දෙකක් තිබූ පරීක්ෂණ දත්ත ගබඩාවක් භාවිතා කළා. පාරිභෝගික ගිණුම් සහිත එක් තහඩුවක්, අනෙක මෙම ගිණුම්වල ගනුදෙනු. තවද යම් සංඛ්‍යාතයකින් අපි මෙම ගිණුම්වල ශේෂයන් යාවත්කාලීන කරන්නෙමු.

තහඩුවේ මූලික දත්ත: එය තරමක් කුඩා, 2 MB. දත්ත සමුදාය සඳහා සහ විශේෂයෙන් ලකුණ සඳහා ප්රතිචාර දැක්වීමේ කාලය ද ඉතා හොඳයි. සහ තරමක් හොඳ බරක් - තහඩුව අනුව තත්පරයට මෙහෙයුම් 2 ක්.

මෙම වාර්තාව හරහා මම ඔබට ප්‍රස්ථාර පෙන්වන්නම් එවිට ඔබට සිදුවන්නේ කුමක්ද යන්න පැහැදිලිව තේරුම් ගත හැකිය. සෑම විටම ප්‍රස්ථාර සහිත විනිවිදක 2ක් ඇත. පළමු විනිවිදකය යනු සේවාදායකයේ පොදුවේ සිදු වන දෙයයි.

මෙම තත්වය තුළ, අපට සැබවින්ම කුඩා ලකුණක් ඇති බව අපට පෙනේ. දර්ශකය 2 MB හි කුඩා වේ. වම් පස ඇති පළමු ප්‍රස්ථාරය මෙයයි.

සේවාදායකයේ සාමාන්‍ය ප්‍රතිචාර කාලය ද ස්ථාවර සහ කෙටි වේ. මෙය ඉහළ දකුණු ප්‍රස්ථාරයයි.

පහළ වම් ප්‍රස්ථාරය දිගම ගනුදෙනු පෙන්වයි. ගනුදෙනු ඉක්මනින් අවසන් වන බව අපට පෙනේ. සහ autovacuum තවමත් මෙහි ක්‍රියා නොකරයි, මන්ද එය ආරම්භක පරීක්ෂණයකි. එය දිගටම වැඩ කරන අතර අපට ප්රයෝජනවත් වනු ඇත.

දෙවන ස්ලයිඩය සෑම විටම පරීක්ෂා කරනු ලබන තහඩුව සඳහා කැප කරනු ලැබේ. මෙම තත්වය තුළ, අපි සේවාදායකයාගේ ගිණුම් ශේෂයන් නිරන්තරයෙන් යාවත්කාලීන කරන්නෙමු. යාවත්කාලීන මෙහෙයුමක් සඳහා සාමාන්‍ය ප්‍රතිචාර කාලය මිලි තත්පරයකට වඩා අඩු බව අපට පෙනේ. ප්‍රොසෙසර සම්පත් (මෙය ඉහළ දකුණු ප්‍රස්ථාරය) ද ඒකාකාරව හා තරමක් කුඩා ලෙස පරිභෝජනය කරන බව අපට පෙනේ.

පහළ දකුණු ප්‍රස්ථාරයෙන් පෙන්නුම් කරන්නේ එය යාවත්කාලීන කිරීමට පෙර අපට අවශ්‍ය රේඛාව සෙවීම සඳහා අප කොපමණ මෙහෙයුම් සහ තැටි මතකය හරහා යනවාද යන්නයි. ඒවගේම ලකුණට අනුව මෙහෙයුම් ගණන මම මුලදී කිව්වා වගේ තත්පරයට 2යි.

දැන් අපට ඛේදවාචකයක් තිබේ. කිසියම් හේතුවක් නිසා දිගු අමතක වූ ගනුදෙනුවක් තිබේ. හේතු සාමාන්‍යයෙන් සියල්ල අශෝභන ය:

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

එවැනි දේවල් ගෙන යන්නේ කොතැනටද?

අපගේ වගු සහ දර්ශක නාටකාකාර ලෙස ඉදිමීමට පටන් ගනී. මෙය හරියටම එකම bloat effect වේ. දත්ත සමුදාය සඳහා, මෙයින් අදහස් කරන්නේ දත්ත සමුදා ප්‍රතිචාර කාලය ඉතා තියුනු ලෙස වැඩි වන අතර දත්ත සමුදා සේවාදායකයේ බර වැඩි වන බවයි. එහි ප්‍රතිඵලයක් වශයෙන්, අපගේ යෙදුම දුක් විඳිනු ඇත. මක්නිසාද යත් ඔබ දත්ත සමුදාය වෙත ඉල්ලීමක් මත ඔබේ කේතයේ මිලි තත්පර 10 ක්, ඔබේ තර්කනය සඳහා මිලි තත්පර 10 ක් වැය කළේ නම්, ඔබේ කාර්යය සම්පූර්ණ කිරීමට මිලි තත්පර 20 ක් ගත විය. දැන් ඔබේ තත්වය සම්පූර්ණයෙන්ම කණගාටුදායක වනු ඇත.

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

සාමාන්‍ය සේවාදායක ප්‍රතිචාර කාලය පිළිබඳ සාමාන්‍ය තත්ත්වය ද විශාලත්වයේ ඇණවුම් කිහිපයකින් වෙනස් වී ඇත. එනම්, සේවාදායකයේ සියලුම ඉල්ලීම් සම්පූර්ණයෙන්ම පහත වැටීමට පටන් ගත්තේය. ඒ අතරම, අභ්‍යන්තර Postgres ක්‍රියාවලීන් autovacuum ආකාරයෙන් දියත් කරන ලද අතර ඒවා යමක් කිරීමට උත්සාහ කරන සහ සම්පත් පරිභෝජනය කරයි.

අපේ ලකුණට මොකද වෙන්නේ? ඒකමයි. ලකුණට අනුව අපගේ සාමාන්‍ය ප්‍රතිචාර කාලය විශාලත්වයේ ඇණවුම් කිහිපයක් ඉහළ ගොස් ඇත. විශේෂයෙන් පරිභෝජනය කරන ලද සම්පත් අනුව, ප්‍රොසෙසරයේ බර විශාල ලෙස වැඩි වී ඇති බව අපට පෙනේ. මෙය ඉහළ දකුණු ප්‍රස්ථාරයයි. තවද එය වැඩි වී ඇත්තේ ප්‍රොසෙසරයට අවශ්‍ය එක සෙවීම සඳහා නිෂ්ඵල රේඛා සමූහයක් හරහා වර්ග කළ යුතු බැවිනි. මෙය පහළ දකුණු ප්‍රස්ථාරයයි. එහි ප්‍රතිඵලයක් වශයෙන්, දත්ත සමුදායට එකම ඉල්ලීම් සංඛ්‍යාවක් සැකසීමට කාලය නොමැති නිසා තත්පරයකට අපගේ ඇමතුම් සංඛ්‍යාව ඉතා සැලකිය යුතු ලෙස පහත වැටීමට පටන් ගත්තේය.

අපි ආපහු ජීවිතයට එන්න ඕන. අපි අන්තර්ජාලයට ගොස් දිගු ගනුදෙනු ගැටළු වලට තුඩු දෙන බව සොයා ගනිමු. අපි මේ ගනුදෙනුව හොයාගෙන මරනවා. ඒ වගේම හැම දෙයක්ම අපිට සාමාන්‍ය දෙයක් වෙනවා. සෑම දෙයක්ම කළ යුතු පරිදි ක්රියා කරයි.

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

සහ ප්‍රශ්නය: “මේ මොහොතේ පදනමට සිදුවන්නේ කුමක්ද?” සහ පහත තත්ත්වය පදනම සමඟ සිදු වේ. ගනුදෙනු ප්‍රස්ථාරයේ එය නතර වී ඇති බවත් දිගු කාලීන ගනුදෙනු නොමැති බවත් ඔබට දැක ගත හැකිය. නමුත් අනතුර අතරතුර ලකුණෙහි විශාලත්වය මාරාන්තික ලෙස වැඩි විය. අනික එදා ඉඳන් ඒවා අඩුවෙලා නෑ. පදනම මත සාමාන්ය කාලය ස්ථාවර වී ඇත. පිළිතුරු අපට පිළිගත හැකි වේගයකින් ප්‍රමාණවත් ලෙස පැමිණෙන බව පෙනේ. autovacuum එක වඩාත් සක්‍රීය වී ලකුණ සමඟ යමක් කිරීමට පටන් ගත්තේය, මන්ද එයට තවත් දත්ත පෙරීමට අවශ්‍ය බැවිනි.

විශේෂයෙන්, ගිණුම් සහිත පරීක්ෂණ තහඩුවට අනුව, අපි ශේෂයන් වෙනස් කරන ස්ථානය: ඉල්ලීමක් සඳහා ප්‍රතිචාර දැක්වීමේ කාලය සාමාන්‍ය තත්ත්වයට පත්ව ඇති බව පෙනේ. නමුත් යථාර්ථයේ දී එය එකහමාරක් වැඩි ය.

ඒවගේම ප්‍රොසෙසරයේ ලෝඩ් එකෙන් අපිට පේනවා ප්‍රොසෙසරයේ ලෝඩ් එක කඩා වැටීමට පෙර අවශ්‍ය අගයට පැමිණ නැති බව. එහි ඇති හේතු හරියටම පහළ දකුණු ප්‍රස්ථාරයේ පිහිටා ඇත. එහිදී යම් මතක ප්‍රමාණයක් සොයමින් පවතින බව පෙනේ. එනම්, අවශ්‍ය රේඛාව සොයා ගැනීමට, අපි වැඩකට නැති දත්ත වර්ග කිරීමේදී දත්ත සමුදා සේවාදායකයේ සම්පත් නාස්ති කරමු. තත්පරයකට ගනුදෙනු ගණන ස්ථාවර වී ඇත.

සමස්තයක් වශයෙන් හොඳයි, නමුත් තත්වය තිබුණාට වඩා නරකයි. මෙම දත්ත සමුදාය සමඟ ක්‍රියා කරන අපගේ යෙදුමේ ප්‍රතිඵලයක් ලෙස දත්ත සමුදාය පිරිහීම ඉවත් කරන්න.

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

අවබෝධය සඳහා කෙටියෙන්. යම් අවස්ථාවක දී අපට මේසයක් තිබේ. අපට මේසයේ පේළි තිබේ. මෙම රේඛා ක්‍රියාකාරී, ජීවමාන සහ දැන් අපට අවශ්‍ය දේ විය හැක. පින්තූරයේ ඒවා කොළ පැහැයෙන් සලකුණු කර ඇත. තවද දැනටමත් සකස් කර ඇති, යාවත්කාලීන කර ඇති සහ නව ප්‍රවේශයන් ඒවායේ දර්ශනය වී ඇති අවසාන රේඛා ඇත. තවද ඒවා දත්ත සමුදායට තවදුරටත් රසවත් නොවන බව සලකුණු කර ඇත. නමුත් Postgres විශේෂාංගයක් නිසා ඒවා වගුවේ ඇත.

ඔබට කාර් රික්තයක් අවශ්ය වන්නේ ඇයි? යම් අවස්ථාවක දී, autovacuum පැමිණ, දත්ත සමුදායට ප්‍රවේශ වී එය අසයි: "කරුණාකර දත්ත සමුදායේ දැනට විවෘතව ඇති පැරණිතම ගනුදෙනුවේ හැඳුනුම්පත ලබා දෙන්න." දත්ත සමුදාය මෙම හැඳුනුම්පත ලබා දෙයි. සහ autovacuum, එය මත විශ්වාසය තබා, වගුවේ ඇති රේඛා හරහා වර්ග කරයි. සමහර රේඛා බොහෝ පැරණි ගනුදෙනු මගින් වෙනස් වී ඇති බව ඔහු දුටුවහොත්, අනාගතයේදී එහි නව දත්ත ලිවීමෙන් අපට නැවත භාවිතා කළ හැකි රේඛා ලෙස සලකුණු කිරීමට ඔහුට අයිතියක් ඇත. මෙය පසුබිම් ක්‍රියාවලියකි.

මෙම අවස්ථාවේදී, අපි දත්ත සමුදාය සමඟ දිගටම වැඩ කරන අතර වගුවේ යම් යම් වෙනස්කම් සිදු කරන්නෙමු. අපට නැවත භාවිතා කළ හැකි මෙම රේඛාවල අපි නව දත්ත ලියන්නෙමු. මේ අනුව අපට චක්‍රයක් ලැබේ, එනම් සෑම විටම එහි සමහර මිය ගිය පැරණි රේඛා දිස් වේ, ඒවා වෙනුවට අපි අපට අවශ්‍ය නව රේඛා ලියන්නෙමු. තවද මෙය PostgreSQL සඳහා සාමාන්‍ය තත්වයකි.

අනතුර අතරතුර සිදුවූයේ කුමක්ද? මෙම ක්‍රියාවලිය එහි සිදුවූයේ කෙසේද?

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

නමුත් මේ අවස්ථාවේදී අපි මේසය සමඟ දිගටම වැඩ කරන්නෙමු. අපි එය තුළ යමක් කරන්න, එය යාවත්කාලීන කරන්න, දත්ත වෙනස් කරන්න. මෙම අවස්ථාවේදී දත්ත සමුදාය කළ යුත්තේ කුමක්ද? පවතින මේසයේ කෙළවරට නව රේඛා එකතු කිරීම හැර වෙනත් විකල්පයක් ඇයට නැත. මේ අනුව අපගේ මේසයේ ප්‍රමාණය ඉදිමීමට පටන් ගනී.

ඇත්ත වශයෙන්ම, අපට වැඩ කිරීමට හරිත රේඛා අවශ්ය වේ. නමුත් එවැනි ගැටළුවක් අතරතුර, මුළු වගුව පුරාම හරිත රේඛා ප්රතිශතය අතිශයින් අඩු බව පෙනී යයි.

තවද අපි විමසුමක් ක්‍රියාත්මක කරන විට, දත්ත සමුදාය සියලුම රේඛා හරහා යා යුතුය: රතු සහ කොළ යන දෙකම, අපේක්ෂිත රේඛාව සොයා ගැනීමට. තවද වැඩකට නැති දත්ත සහිත මේසයක් පිම්බීමේ බලපෑම "බ්ලොට්" ලෙස හැඳින්වේ, එය අපගේ තැටි අවකාශය ද අනුභව කරයි. මතකද 2 MB, 300 MB වුනාද? දැන් මෙගාබයිට් ගිගාබයිට් වලට වෙනස් කරන්න, එවිට ඔබට ඔබගේ සියලුම තැටි සම්පත් ඉක්මනින් අහිමි වනු ඇත.

අපට ඇති විය හැකි ප්‍රතිවිපාක මොනවාද?

• මගේ උදාහරණයේ, වගුව සහ දර්ශකය 150 ගුණයකින් වර්ධනය විය. අපගේ සමහර සේවාදායකයින්ට තැටි ඉඩ මදි වීමට පටන් ගත් විට ඔවුන්ට වඩා මාරාන්තික අවස්ථා තිබේ.
• මේසවල ප්‍රමාණයම කිසිදා අඩු නොවේ. සමහර අවස්ථාවලදී Autovacuum හට ඩෙඩ් රේඛා පමණක් තිබේ නම් මේසයේ වලිගය කපා දැමිය හැකිය. නමුත් නිරන්තර භ්‍රමණයක් ඇති බැවින්, එක් හරිත රේඛාවක් අවසානයේ කැටි විය හැකි අතර යාවත්කාලීන නොවනු ඇත, අනෙක් සියල්ල තහඩුවේ ආරම්භයේ කොතැනක හෝ ලියා ඇත. නමුත් මෙය ඔබගේ මේසයේ ප්‍රමාණයෙන් හැකිලීමට නොහැකි සිදුවීමකි, එබැවින් ඔබ ඒ ගැන බලාපොරොත්තු නොවිය යුතුය.
• දත්ත සමුදාය නිෂ්ඵල රේඛා සමූහයක් හරහා වර්ග කළ යුතුය. තවද අපි තැටි සම්පත් නාස්ති කරමු, අපි ප්‍රොසෙසර සම්පත් සහ විදුලිය නාස්ති කරමු.
• මෙය අපගේ යෙදුමට කෙලින්ම බලපායි, මන්ද ආරම්භයේදී අපි ඉල්ලීම සඳහා මිලි තත්පර 10 ක්, අපගේ කේතය සඳහා මිලි තත්පර 10 ක් වැය කළේ නම්, බිඳවැටීමේදී අපි ඉල්ලීම සඳහා තත්පරයක් සහ කේතය සඳහා මිලි තත්පර 10 ක් ගත කිරීමට පටන් ගත්තෙමු, එනම් නියෝගයක් යෙදුම් කාර්ය සාධනයේ විශාලත්වය අඩු විය. අනතුර නිරාකරණය වූ විට, අපි ඉල්ලීමක් සඳහා මිලි තත්පර 20 ක්, කේතයක් සඳහා මිලි තත්පර 10 ක් වැය කිරීමට පටන් ගත්තෙමු. මෙයින් අදහස් කරන්නේ අප තවමත් ඵලදායිතාවයෙන් එකහමාරකින් පහත වැටී ඇති බවයි. මේ සියල්ල කැටි වූ එක් ගනුදෙනුවක් නිසා විය හැකිය, සමහර විට අපගේ වරදින්.
• සහ ප්‍රශ්නය: “අපි සියල්ල ආපසු ලබා ගන්නේ කෙසේද?” එවිට සියල්ල අප සමඟ හොඳින් සිදුවන අතර අනතුරට පෙර මෙන් ඉල්ලීම් ඉක්මනින් පැමිණේ.

මෙම කාර්යය සඳහා සිදු කරනු ලබන කාර්යයේ නිශ්චිත චක්රයක් ඇත.

මුලින්ම අපි පුම්බා ඇති ගැටළුකාරී වගු සොයා ගත යුතුය. සමහර වගු වල පටිගත කිරීම වඩාත් සක්‍රීය වන අතර අනෙක් ඒවා අඩු ක්‍රියාකාරී බව අපි තේරුම් ගනිමු. මේ සඳහා අපි දිගුව භාවිතා කරමු pgstattuple. මෙම දිගුව ස්ථාපනය කිරීමෙන්, ඔබට තරමක් පුම්බා ඇති වගු සොයා ගැනීමට උපකාර වන විමසුම් ලිවිය හැක.

ඔබ මෙම වගු සොයාගත් පසු, ඔබ ඒවා සම්පීඩනය කළ යුතුය. මේ සඳහා දැනටමත් මෙවලම් තිබේ. අපගේ සමාගම තුළ අපි මෙවලම් තුනක් භාවිතා කරමු. පළමුවැන්න බිල්ට්-ඉන් VACUUM FULL. ඔහු කෲර, රළු සහ අනුකම්පා විරහිත ය, නමුත් සමහර විට ඔහු ඉතා ප්රයෝජනවත් වේ. Pg_repack и pgcompactable - මේවා සංකෝචන වගු සඳහා තෙවන පාර්ශවීය උපයෝගිතා වේ. තවද ඔවුන් දත්ත සමුදාය වඩාත් ප්රවේශමෙන් සලකයි.

ඔබට වඩාත් පහසු දේ මත පදනම්ව ඒවා භාවිතා වේ. නමුත් මම මේ ගැන අවසානයේ ඔබට කියන්නම්. ප්රධාන දෙය වන්නේ මෙවලම් තුනක් තිබීමයි. තෝරා ගැනීමට බොහෝ දේ ඇත.

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

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

මෙම ප්‍රස්ථාරවල, මම මෙම නඩුවේ VACUUM FULL සහිත ලකුණ හරහා ගිය පසු දත්ත සමුදායේ ලකුණ සහ හැසිරීම වෙනස් වූ ආකාරය ඔබට පෙන්වීමට අවශ්‍ය විය. මේක මට නිෂ්පාදනයක් නෙවෙයි.

මේස ප්‍රමාණය වහාම මෙගාබයිට් කිහිපයක සාමාන්‍ය මෙහෙයුම් තත්ත්වයට පත් විය. මෙය සේවාදායකයේ සාමාන්‍ය ප්‍රතිචාර කාලයට විශාල ලෙස බලපෑවේ නැත.

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

ඔන්න ඔතනින් තමයි පලවෙනි කතාව ඉවර වෙන්නේ. එය වඩාත් පොදු වේ. සේවාදායකයාගේ අත්දැකීම් සහ ක්‍රමලේඛකයින් කෙතරම් සුදුසුකම් ලත්ද යන්න නොසලකා එය සෑම කෙනෙකුටම සිදු වේ. ඉක්මනින් හෝ පසුව මෙය සිදු වේ.

අපි භාරය බෙදා හරින සහ සේවාදායක සම්පත් ප්‍රශස්ත කරන දෙවන කතාව

• අපි දැනටමත් හැදී වැඩී බරපතල මිනිසුන් බවට පත්ව ඇත. අප සතුව අනුරුවක් ඇති බව අපට වැටහෙන අතර බර සමතුලිත කිරීම අපට හොඳ වනු ඇත: මාස්ටර්ට ලියන්න, සහ අනුරුවෙන් කියවන්න. තවද සාමාන්‍යයෙන් මෙම තත්ත්වය ඇතිවන්නේ අපට සමහර වාර්තා හෝ ETL සකස් කිරීමට අවශ්‍ය වූ විටය. ඒ වගේම බිස්නස් මේ ගැන ගොඩක් සතුටුයි. ඔහුට සැබවින්ම අවශ්‍ය වන්නේ සංකීර්ණ විශ්ලේෂණ රාශියක් සහිත විවිධ වාර්තා ය.
• සංකීර්ණ විශ්ලේෂණ මිලි තත්පර වලින් ගණනය කළ නොහැකි නිසා වාර්තා සඳහා පැය ගණනාවක් ගත වේ. අපි, නිර්භීත කොල්ලන් මෙන්, කේතය ලියන්නෙමු. ඇතුළත් කිරීමේ යෙදුමේදී අපි මාස්ටර් මත පටිගත කිරීම සිදු කරන අතර අනුරුව මත වාර්තා ක්‍රියාත්මක කරන්න.
• බර බෙදා හැරීම.
• සෑම දෙයක්ම පරිපූර්ණව ක්රියා කරයි. අපි නියමයි.

සහ මෙම තත්වය පෙනෙන්නේ කෙසේද? විශේෂයෙන් මෙම ප්‍රස්ථාර මත, මම ගනුදෙනු කාලසීමාව සඳහා අනුරුවෙන් ගනුදෙනු කාලසීමාව ද එක් කළෙමි. අනෙකුත් සියලුම ප්‍රස්ථාර මාස්ටර් සේවාදායකයට පමණක් යොමු වේ.

මේ වන විට මගේ වාර්තා පුවරුව වර්ධනය වී තිබුණි. තව ඒවා තියෙනවා. සාමාන්‍ය සේවාදායක ප්‍රතිචාර කාලය ස්ථාවර බව අපට පෙනේ. අනුරුවෙහි අපට පැය 2ක් පුරා දිවෙන දිගුකාලීන ගනුදෙනුවක් ඇති බව අපට පෙනේ. ඩෙඩ් ලයින් සකසන autovacuum හි නිහඬ ක්‍රියාකාරිත්වය අපි දකිමු. ඒ වගේම අපිත් එක්ක හැම දෙයක්ම හොඳයි.

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

අනුවර්තනය සමඟ ගැටුමක් හේතුවෙන් මෙම වාර්තා නැවත වෙඩි තැබීමට පටන් ගන්නා මොහොත දක්වා සියල්ල හොඳින් පවතී. තවද ඔවුන් නියමිත කාල පරාසයන් තුළ නැවත වෙඩි තබයි.

අපි අන්තර්ජාලයට ගොස් මෙය සිදුවන්නේ මන්දැයි කියවීමට පටන් ගනිමු. ඒ වගේම අපි විසඳුමක් සොයා ගනිමු.

පළමු විසඳුම වන්නේ අනුවර්තනය වීමේ ප්රමාදය වැඩි කිරීමයි. අපි දන්නවා අපේ වාර්තාව පැය 3ක් දුවනවා. අපි පිටපත් කිරීමේ ප්‍රමාදය පැය 3කට සකසන්නෙමු. අපි සෑම දෙයක්ම දියත් කරමින් සිටිමු, නමුත් සමහර විට වාර්තා අවලංගු කිරීම සම්බන්ධයෙන් අපට තවමත් ගැටලු තිබේ.

සෑම දෙයක්ම පරිපූර්ණ වීමට අපට අවශ්‍යයි. අපි තවත් නගිනවා. තවද අපි අන්තර්ජාලයේ සිසිල් සැකසුම සොයා ගත්තෙමු - hot_standby_feedback. අපි එය සක්රිය කරමු. Hot_standby_feedback අපට Master මත ස්වයංක්‍රීය රික්තකය රඳවා ගැනීමට ඉඩ සලසයි. මේ අනුව, අපි අනුකරණ ගැටුම් සම්පූර්ණයෙන්ම ඉවත් කරමු. වාර්තා සමඟ සෑම දෙයක්ම අපට හොඳින් ක්‍රියාත්මක වේ.

සහ මේ වෙලාවේ Master server එකට මොකද වෙන්නේ? ඒ වගේම අපි Master server එකත් එක්ක සම්පුර්ණ අවුලක ඉන්නේ. මම මෙම සැකසුම් දෙකම සක්‍රීය කර ඇති විට දැන් අපි ප්‍රස්ථාර දකිමු. අපගේ අනුරුවෙහි සැසිය කෙසේ හෝ මාස්ටර් සේවාදායකයේ තත්වයට බලපෑම් කිරීමට පටන් ගත් බව අපට පෙනේ. ඇය ස්වයංක්‍රීය රික්තකය විරාම කළ නිසා ඇයට බලපෑමක් ඇත, එය ඩෙඩ් ලයින් ඉවත් කරයි. අපේ මේස ප්‍රමාණය නැවතත් අහස උසට නැග ඇත. සමස්ත දත්ත සමුදාය හරහා සාමාන්‍ය විමසුම් ක්‍රියාත්මක කිරීමේ කාලය ද අහස උසට නැඟී ඇත. autovacuums ටිකක් තද උනා.

විශේෂයෙන්ම, අපේ තහඩුවෙන්, එය මත දත්ත යාවත්කාලීන කිරීම ද අහසට පැන්නා බව අපට පෙනේ. CPU පරිභෝජනය ඒ හා සමානව විශාල ලෙස වැඩි වී ඇත. අපි නැවතත් මිය ගිය, වැඩකට නැති රේඛා විශාල සංඛ්‍යාවක් හරහා යමින් සිටිමු. තවද මෙම ලකුණ සඳහා ප්‍රතිචාර දැක්වීමේ කාලය සහ ගනුදෙනු සංඛ්‍යාව පහත වැටී ඇත.

මම කලින් කතා කළ දේ අපි නොදන්නේ නම් එය කෙබඳු වනු ඇත්ද?

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

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

සැසිය අවසන්. තවද ටික වේලාවකට පසුව පමණක් සේවාදායකය අඩු වැඩි වශයෙන් පිළිවෙලට පැමිණේ. තවද Master server හි ඉල්ලීම් සඳහා සාමාන්‍ය ප්‍රතිචාර කාලය සාමාන්‍ය තත්වයට පත්වේ. මක්නිසාද යත්, අවසාන වශයෙන්, autovacuum හට මෙම ඩෙඩ් රේඛා පිරිසිදු කර සලකුණු කිරීමට අවස්ථාව තිබේ. තවද ඔහු තම කාර්යය කිරීමට පටන් ගත්තේය. ඔහු එය කෙතරම් ඉක්මනින් කරයිද, එතරම් ඉක්මනින් අපි පිළිවෙලට ගනිමු.

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

ඕනෑම අවස්ථාවක, අපට කාර්ය සාධනය අඩුවීමක් ලැබේ, පළමු අවස්ථාවේ දී මෙන්, එකහමාරක් හෝ දෙගුණයක් සහ සමහර විට තවත්.

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

• hot_standby_feedback සබල නොකරන්නද? ඔව්, විශේෂයෙන් ශක්තිමත් හේතු නොමැතිව එය සක්රිය කිරීම නිර්දේශ නොකරයි. මොකද මේ twist එක Master server එකට කෙලින්ම බලපාන නිසා එතන autovacuum එකේ ක්‍රියාකාරිත්වය අත්හිටුවනවා. එය කිසියම් අනුරුවක සක්‍රීය කර එය අමතක කිරීමෙන්, ඔබට මාස්ටර් මරා දමා යෙදුම සමඟ විශාල ගැටළු ඇති කළ හැකිය.
• max_standby_streaming_delay වැඩි කරන්නද? ඔව්, වාර්තා සඳහා මෙය සත්යයකි. ඔබට පැය තුනක වාර්තාවක් තිබේ නම් සහ එය අනුවර්තන ගැටුම් හේතුවෙන් බිඳ වැටීමට ඔබට අවශ්‍ය නැතිනම්, ප්‍රමාදය වැඩි කරන්න. දිගු කාලීන වාර්තාවකට දැන් දත්ත සමුදායට පැමිණ ඇති දත්ත කිසි විටෙකත් අවශ්‍ය නොවේ. ඔබට එය පැය තුනක් තිබේ නම්, ඔබ එය පැරණි දත්ත කාල සීමාවක් සඳහා ධාවනය කරයි. තවද ඔබට, පැය තුනක ප්‍රමාදයක් හෝ පැය හයක ප්‍රමාදයක් තිබේද යන්නෙන් කිසිදු වෙනසක් සිදු නොවනු ඇත, නමුත් ඔබට අඛණ්ඩව වාර්තා ලැබෙනු ඇති අතර ඒවා වැටීමෙන් කිසිදු ගැටළුවක් ඇති නොවේ.
• ස්වාභාවිකවම, ඔබට අනුරූ මත දිගු සැසි පාලනය කිරීමට අවශ්‍ය වේ, විශේෂයෙන් ඔබ අනුරුවක hot_standby_feedback සබල කිරීමට තීරණය කරන්නේ නම්. මොකද ඕනම දෙයක් වෙන්න පුළුවන්. අපි මෙම අනුරුව සංවර්ධකයාට ලබා දුන්නේ ඔහුට විමසුම් පරීක්ෂා කිරීමට හැකි වන පරිදිය. ඔහු පිස්සු ඉල්ලීමක් ලිවීය. ඔහු එය දියත් කර තේ පානය කිරීමට පිටත් වූ අතර, අපි ස්ථාපිත මාස්ටර් ලබා ගත්තෙමු. එසේත් නැතිනම් අපි එහි වැරදි යෙදුමක් දමා ඇත. තත්වයන් විවිධාකාර වේ. අනුරූ පිළිබඳ සැසි මාස්ටර් මෙන් ප්‍රවේශමෙන් නිරීක්ෂණය කළ යුතුය.
• ඔබට අනුරූ පිළිබඳ වේගවත් හා දිගු විමසුම් තිබේ නම්, මේ අවස්ථාවේ දී බර බෙදා හැරීම සඳහා ඒවා බෙදීම වඩා හොඳය. මෙය streaming_delay වෙත සබැඳියකි. වේගවත් ඒවා සඳහා, කුඩා අනුරූ ප්‍රමාදයක් සහිත එක් අනුරුවක් ඇත. දිගුකාලීන වාර්තාකරණ ඉල්ලීම් සඳහා, පැය 6ක් හෝ දිනකට ප්‍රමාද විය හැකි අනුරුවක් තබා ගන්න. මෙය සම්පූර්ණයෙන්ම සාමාන්‍ය තත්ත්වයකි.

අපි එකම ආකාරයෙන් ප්රතිවිපාක ඉවත් කරමු:

• අපි පිම්බුණු මේස සොයා ගනිමු.
• තවද අපි එය අපට ගැලපෙන වඩාත් පහසු මෙවලමක් සමඟ සම්පීඩනය කරමු.

දෙවෙනි කතාව මෙතනින් ඉවරයි. අපි තුන්වෙනි කතාවට යමු.

අපි සංක්‍රමණය කරන අපටත් සාමාන්‍ය දෙයක්.

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

මෙන්න ඔබ ඉදිරියේ ඉදිරිපත් කරන ලද යාවත්කාලීනය සමඟ සංක්‍රමණය වේ. මේවා මගේ ගිණුම් ගනුදෙනු නිසා තහඩුව 15 GB විය. තවද අපි සෑම පේළියක්ම යාවත්කාලීන කරන බැවින්, අපි යාවත්කාලීනය සමඟ මේසයේ ප්‍රමාණය දෙගුණ කළෙමු, මන්ද අපි සෑම පේළියක්ම නැවත ලිවූ බැවිනි.

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

අපි සංක්‍රමණය කරලා ආයෙත් ප්‍රශ්න ආවා.

සංක්‍රමණය සාර්ථක විය, නමුත්:

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

මෙය නැවතත් ඉදිමීමකි, එය නැවතත් අපගේ ජීවිත විනාශ කරයි.

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

තවද අපි ගිණුම් සහිත වගුව වෙත හැරී ගියහොත්, මෙම වගුව සඳහා සාමාන්ය ඉල්ලීම් කාලය දෙගුණ වී ඇති බව අපට පෙනෙනු ඇත. ප්‍රොසෙසරයේ බර සහ මතකයේ වර්ග කර ඇති රේඛා ගණන 7,5 ට වඩා ඉහළ ගිය නමුත් අඩු විය. තවද එය ප්‍රොසෙසර සම්බන්ධයෙන් 2 වතාවක්, බ්ලොක් මෙහෙයුම් වලදී 1,5 ගුණයක් පැන්නා, එනම් අපට සේවාදායකයේ ක්‍රියාකාරිත්වයේ පිරිහීමක් ලැබුණි. සහ ප්රතිඵලයක් ලෙස - අපගේ යෙදුමේ කාර්ය සාධනය පිරිහීම. ඒ සමගම, ඇමතුම් සංඛ්යාව ආසන්න වශයෙන් එකම මට්ටමේ පැවතුනි.

තවද මෙහි ප්රධානතම දෙය වන්නේ එවැනි සංක්රමණයන් නිවැරදිව සිදු කරන්නේ කෙසේද යන්න තේරුම් ගැනීමයි. ඒ වගේම ඒවා කරන්න ඕන. අපි මේ සංක්‍රමණයන් සෑහෙන්න ස්ථාවරව කරනවා.

• එවැනි විශාල සංක්‍රමණ ස්වයංක්‍රීයව සිදු නොවේ. ඔවුන් සැමවිටම පාලනය කළ යුතුය.
• දැනුවත් පුද්ගලයෙකුගේ අධීක්ෂණය අවශ්ය වේ. ඔබේ කණ්ඩායමේ DBA එකක් තිබේ නම්, DBA ට එය කිරීමට ඉඩ දෙන්න. ඒක එයාගේ වැඩක්. එසේ නොවේ නම්, දත්ත සමුදායන් සමඟ වැඩ කරන්නේ කෙසේදැයි දන්නා වඩාත්ම පළපුරුදු පුද්ගලයාට එය කිරීමට ඉඩ දෙන්න.
• නව දත්ත සමුදා සැලැස්මක්, අපි එක් තීරුවක් යාවත්කාලීන කළත්, අපි සෑම විටම අදියර වශයෙන් සූදානම් කරමු, එනම් යෙදුමේ නව අනුවාදය නිකුත් කිරීමට පෙර කල්තියා:
• අපි යාවත්කාලීන දත්ත සටහන් කරන නව ක්ෂේත්‍ර එකතු වේ.
• අපි කුඩා කොටස්වල පැරණි ක්ෂේත්රයේ සිට නව ක්ෂේත්රයට දත්ත මාරු කරමු. ඇයි අපි මෙහෙම කරන්නේ? පළමුව, අපි සෑම විටම මෙම ක්රියාවලියේ ක්රියාවලිය පාලනය කරමු. අපි දන්නවා අපි දැනටමත් කණ්ඩායම් ගණනාවක් මාරු කර ඇති අතර අපට ඉතිරිව ඇති බව.
• දෙවන ධනාත්මක බලපෑම නම්, එවැනි සෑම කණ්ඩායමක් අතරම අපි ගනුදෙනුව වසා දමා, නව එකක් විවෘත කරන අතර, මෙය ස්වයංක්‍රීයව තහඩුවට අනුව ක්‍රියා කිරීමට, නැවත භාවිතය සඳහා නියමිත රේඛා සලකුණු කිරීමට ඉඩ සලසයි.
• යෙදුම ක්‍රියාත්මක වන විට දිස්වන රේඛා සඳහා (අපට තවමත් පැරණි යෙදුම ක්‍රියාත්මක වේ), අපි නව ක්ෂේත්‍රවලට නව අගයන් ලියන ප්‍රේරකයක් එක් කරන්නෙමු. අපගේ නඩුවේදී, මෙය පැරණි අගයෙන් සියයකින් ගුණ කිරීමකි.
• අපි සම්පූර්ණයෙන්ම මුරණ්ඩු නම් සහ එකම ක්ෂේත්‍රය අවශ්‍ය නම්, සියලුම සංක්‍රමණ අවසන් වූ පසු සහ යෙදුමේ නව අනුවාදයක් නිකුත් කිරීමට පෙර, අපි ක්ෂේත්‍ර නැවත නම් කරන්නෙමු. පැරණි ඒවාට නව නිපැයුම් කරන ලද නමක් ලබා දී ඇති අතර නව ක්ෂේත්‍ර පැරණි ඒවා ලෙස නැවත නම් කරනු ලැබේ.
• ඉන් පසුව පමණක් අපි යෙදුමේ නව අනුවාදයක් දියත් කරන්නෙමු.

ඒ සමඟම අපට ඉදිමීමක් නොලැබෙන අතර කාර්ය සාධනය අනුව දුක් විඳින්නේ නැත.

තුන්වෙනි කතාව මෙතනින් ඉවරයි.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

දැන් මම පළමු කතාවේ සඳහන් කළ මෙවලම් ගැන තව ටිකක් විස්තර කරන්න.

bloat සෙවීමට පෙර, ඔබ දිගුව ස්ථාපනය කළ යුතුය pgstattuple.

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

• පළමු එක වැඩ කිරීමට සෑහෙන කාලයක් ගත වේ, නමුත් එය ඔබට වගුවේ ඇති නිවැරදි bloat අගයන් පෙන්වයි.
• දෙවැන්න වේගයෙන් ක්‍රියා කරන අතර මේසයට අනුව ඉදිමීමක් තිබේද නැද්ද යන්න ඉක්මනින් තක්සේරු කිරීමට අවශ්‍ය වූ විට ඉතා effective ලදායී වේ. තවද, පොස්ට්ග්‍රෙස් වගුවක ඉදිමීම සැමවිටම පවතින බව ඔබ තේරුම් ගත යුතුය. මෙය එහි MVCC ආකෘතියේ ලක්ෂණයකි.
• බොහෝ අවස්ථාවලදී මේස සඳහා 20% ඉදිමීම සාමාන්ය වේ. එනම්, ඔබ කරදර නොවිය යුතු අතර මෙම වගුව සම්පීඩනය කළ යුතුය.

වැඩකට නැති දත්තවලින් ඉදිමුණු වගු හඳුනා ගන්නේ කෙසේදැයි අපි සොයා ගත්තෙමු.

දැන් ඉදිමීම නිවැරදි කරන්නේ කෙසේද යන්න ගැන:

• අපට කුඩා ටැබ්ලටයක් සහ හොඳ තැටි තිබේ නම්, එනම්, ගිගාබයිට් දක්වා ටැබ්ලටයක් මත, VACUUM FULL භාවිතා කිරීමට බෙහෙවින් හැකිය. ඔහු තත්පර කිහිපයක් සඳහා මේසය මත ඔබෙන් සුවිශේෂී අගුලක් ගෙන හරිනු ඇත, නමුත් ඔහු සෑම දෙයක්ම ඉක්මනින් හා දැඩි ලෙස කරනු ඇත. VACUUM FULL කරන්නේ කුමක්ද? එය මේසය මත ඇති සුවිශේෂී අගුලක් ගෙන පැරණි වගු වලින් සජීවී පේළි නව වගුවට නැවත ලියයි. අවසානයේ ඔහු ඔවුන් වෙනුවට ආදේශ කරයි. එය පැරණි ගොනු මකා දමන අතර පැරණි ඒවා නව ඒවා සමඟ ප්රතිස්ථාපනය කරයි. නමුත් එහි කාර්යයේ කාලසීමාව සඳහා එය මේසය මත සුවිශේෂී අගුලක් ගනී. මෙයින් අදහස් කරන්නේ ඔබට මෙම වගුව සමඟ කිසිවක් කළ නොහැකි බවයි: එයට ලියන්න, කියවීමට හෝ එය වෙනස් නොකරන්න. තවද VACUUM FULL හට දත්ත ලිවීමට අමතර තැටි ඉඩක් අවශ්‍ය වේ.
• ඊළඟ මෙවලම pg_repack. එහි මූලධර්මය අනුව, එය VACUUM FULL ට බෙහෙවින් සමාන ය, මන්ද එය පැරණි ලිපිගොනු වලින් නව ඒවා වෙත දත්ත නැවත ලියන අතර ඒවා වගුවේ ප්‍රතිස්ථාපනය කරයි. නමුත් ඒ සමඟම, එය එහි කාර්යයේ ආරම්භයේදීම මේසය මත සුවිශේෂී අගුලක් නොගනී, නමුත් එය ගන්නේ ගොනු ප්‍රතිස්ථාපනය කිරීම සඳහා දැනටමත් සූදානම් දත්ත ඇති මොහොතේ පමණි. එහි තැටි සම්පත් අවශ්‍යතා VACUUM FULL වලට සමාන වේ. ඔබට අමතර තැටි ඉඩක් අවශ්‍ය වන අතර, ඔබට ටෙරාබයිට් වගු තිබේ නම් මෙය සමහර විට ඉතා වැදගත් වේ. තවද එය I/O සමඟ සක්‍රියව ක්‍රියා කරන නිසා එය තරමක් ප්‍රොසෙසරයට බඩගිනියි.
• තුන්වන උපයෝගීතාව වේ pgcompactable. එය තරමක් වෙනස් මූලධර්මවලට අනුව ක්‍රියා කරන බැවින් එය සම්පත් සමඟ වඩාත් ප්‍රවේශම් වේ. pgcompactable හි ප්‍රධාන අදහස නම්, එය වගුවේ යාවත්කාලීන කිරීම් භාවිතයෙන් සියලුම සජීවී පේළි මේසයේ ආරම්භයට ගෙන යාමයි. එවිට එය මෙම මේසය මත රික්තයක් ධාවනය කරයි, මන්ද අපට ආරම්භයේ සජීවී පේළි සහ අවසානයේ මළ පේළි ඇති බව අපි දනිමු. රික්තය විසින්ම මෙම වලිගය කපා දමයි, එනම් එයට අමතර තැටි ඉඩක් අවශ්‍ය නොවේ. ඒ අතරම, එය තවමත් සම්පත් අනුව මිරිකා ගත හැකිය.

මෙවලම් සමඟ සෑම දෙයක්ම.

තව දුරටත් අභ්‍යන්තරයේ ගැඹුරින් පිරික්සීමේදී ඔබට බ්ලොට් මාතෘකාව සිත්ගන්නාසුළු නම්, මෙන්න ප්‍රයෝජනවත් සබැඳි කිහිපයක්:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - මෙය මගේ සගයාගේ වාර්තාවකි. එහි වැඩ සහ ජීවිතය තුළ Postgres ගේ අවකාශය යන්නේ කොතැනටද යන්න ගැන එය සාමාන්ය දෙයක්. බ්ලොට් ගැන දත්ත සමුදා පරිපාලකයින් සඳහා ඉතා විශාල සහ සවිස්තරාත්මක තාක්ෂණික කෑල්ලක් ඇත.
• https://github.com/dataegret/pg-utils - මෙය අපගේ ගබඩාවට සබැඳියකි, එහිදී අපි දත්ත සමුදායේ තත්වය පරීක්ෂා කිරීම සඳහා ප්‍රයෝජනවත් ස්ක්‍රිප්ට් පොකුරක් ගබඩා කරමු. එහිදී ඔබට bloat සෙවීමට ස්ක්‍රිප්ට් සොයා ගත හැක.
• තෙවනුව и හතරවන ඔබට සංඥා හැකිලීමට උපකාර වන මෙවලම් වෙත සබැඳි.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - මෙය මගේ සගයාගේ ලිපියකි. එහිදී ඔහු පරිපාලකයින්ට සමීප මට්ටමකින් බඩ පිපීම ඉතා බැරෑරුම් ලෙස හා තාක්‍ෂණිකව විශ්ලේෂණය කරයි.

සංවර්ධකයින් සඳහා ත්‍රාසජනක කතාවක් පෙන්වීමට මම වැඩිපුර උත්සාහ කළෙමි, මන්ද ඔවුන් අපගේ සෘජු දත්ත සමුදා සේවාදායකයන් වන අතර කුමන ක්‍රියාවලට මඟ පාදන්නේද යන්න තේරුම් ගත යුතුය. මම සාර්ථක වුණා කියලා මම හිතනවා. ඔබගේ අවදානය පිළිබඳ ස්තූතියි!

ඔබගේ ප්රශ්න

වාර්තාවට ස්තූතියි! ඔබ ගැටළු හඳුනා ගන්නේ කෙසේද යන්න ගැන කතා කළා. ඔවුන්ට අනතුරු අඟවන්නේ කෙසේද? එනම්, සමහර බාහිර සේවාවන් වෙත ප්‍රවේශ වීම නිසා පමණක් ඉල්ලීම් එල්ලෙන තත්වයක් මට තිබුණි. මේවා වල් බැඳීම් කිහිපයක් පමණි. කුඩා, හානිකර නොවන ඉල්ලීම් කිහිපයක් දිනක් තිස්සේ එල්ලී ඇති අතර පසුව සමහර විකාර කිරීමට පටන් ගත්හ. එනම්, ඔබ විස්තර කරන දෙයට බෙහෙවින් සමාන ය. මෙය නිරීක්ෂණය කරන්නේ කෙසේද? කුමන ඉල්ලීම හිරවී ඇත්දැයි වාඩි වී නිරන්තරයෙන් නරඹන්න? මෙය වළක්වා ගත හැක්කේ කෙසේද?

මෙම අවස්ථාවෙහිදී, මෙය ඔබගේ සමාගමේ පරිපාලකයින් සඳහා වන කාර්යයකි, DBA සඳහා අවශ්ය නොවේ.

මම පරිපාලකයෙක්.

PostgreSQL හි එල්ලෙන විමසුම් පෙන්වන pg_stat_activity නමින් දසුනක් ඇත. ඒවගේම ඒක කොච්චර වෙලාවක් එල්ලිලා තියෙනවද කියල බලාගන්න පුළුවන්.

මම විනාඩි 5කට වරක් ඇවිත් බලන්න ඕනද?

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

මෙය සිදුවීමට පැහැදිලි හේතු තිබේද?

මම සමහරක් ලැයිස්තුගත කර ඇත. වෙනත් සංකීර්ණ උදාහරණ. ඒ වගේම දිගු වේලාවක් සංවාදයක් තිබිය හැකිය.

වාර්තාවට ස්තූතියි! මට pg_repack උපයෝගීතාව ගැන පැහැදිලි කිරීමට අවශ්‍ය විය. ඇය සුවිශේෂී අගුලක් නොකරන්නේ නම්, එසේ නම් ...

ඇය සුවිශේෂී අගුලක් කරයි.

... එවිට මට දත්ත නැති විය හැක. මෙම කාලය තුළ මගේ අයදුම්පත කිසිවක් වාර්තා නොකළ යුතුද?

නැත, එය මේසය සමඟ සුමටව ක්‍රියා කරයි, එනම් pg_repack පළමුව පවතින සියලුම සජීවී රේඛා මාරු කරයි. ස්වාභාවිකවම, මේසයට යම් ආකාරයක ඇතුල්වීමක් එහි සිදු වේ. එයා මේ පෝනිටේල් එක එළියට විසි කරනවා විතරයි.

එනම්, ඔහු අවසානයේ එය කරන්නේද?

අවසානයේදී, ඔහු මෙම ගොනු හුවමාරු කිරීම සඳහා සුවිශේෂී අගුලක් ගනී.

එය VACUUM FULL ට වඩා වේගවත් වේවිද?

VACUUM FULL, එය ආරම්භ වූ වහාම, වහාම සුවිශේෂී අගුලක් ගත්තේය. ඔහු සෑම දෙයක්ම කරන තුරු, ඔහු ඇයට යන්න දෙන්නේ නැහැ. තවද pg_repack ගොනු ප්‍රතිස්ථාපන අවස්ථාවේදී පමණක් සුවිශේෂී අගුලක් ගනී. මේ මොහොතේ ඔබ එහි ලියන්නේ නැත, නමුත් දත්ත නැති නොවනු ඇත, සියල්ල හොඳින් වනු ඇත.

ආයුබෝවන්! ඔබ කාර් රික්තකයේ ක්‍රියාකාරිත්වය ගැන කතා කළා. රතු, කහ සහ කොළ පටිගත කිරීමේ සෛල සහිත ප්‍රස්ථාරයක් එහි විය. එනම්, කහ ඒවා - ඔහු ඒවා මකා දැමූ ලෙස සලකුණු කළේය. ඒ වගේම එහි ප්‍රතිඵලයක් වශයෙන් ඔවුන්ට අලුත් දෙයක් ලිවිය හැකිද?

ඔව්. Postgres රේඛා මකන්නේ නැත. ඔහුට එවැනි විශේෂත්වයක් ඇත. අපි රේඛාවක් යාවත්කාලීන කළහොත්, අපි පැරණි එක මකා දැමූ ලෙස සලකුණු කරමු. මෙම රේඛාව වෙනස් කළ ගනුදෙනුවේ හැඳුනුම්පත එහි දිස්වන අතර අපි නව රේඛාවක් ලියන්නෙමු. තවද ඒවා කියවිය හැකි සැසි අප සතුව ඇත. යම් අවස්ථාවක දී ඔවුන් තරමක් වයස්ගත වේ. තවද autovacuum ක්‍රියා කරන ආකාරයෙහි සාරය නම් එය මෙම රේඛා හරහා ගොස් අනවශ්‍ය ලෙස සලකුණු කිරීමයි. තවද ඔබට එහි දත්ත උඩින් ලිවිය හැක.

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

නැත, ඕනෑම අවස්ථාවක සම්පූර්ණ රේඛාව එහි යාවත්කාලීන වේ. Postgres සතුව දත්ත ගබඩා කිරීමේ ආකෘති දෙකක් ඇත. එය දත්ත වර්ගය අනුව තෝරා ගනී. වගුවේ කෙලින්ම ගබඩා කර ඇති දත්ත ඇත, සහ tos දත්ත ද ඇත. මේවා විශාල දත්ත ප්‍රමාණයකි: පෙළ, json. ඒවා වෙනම තහඩු වල ගබඩා කර ඇත. තවද මෙම පෙති වලට අනුව, ඉදිමීම සමඟ එකම කථාව සිදු වේ, එනම් සෑම දෙයක්ම සමාන වේ. ඒවා වෙන වෙනම ලැයිස්තුගත කර ඇත.

වාර්තාවට ස්තූතියි! කාල සීමාව සීමා කිරීමට ප්‍රකාශ කල් ඉකුත් වීමේ විමසුම් භාවිතා කිරීම පිළිගත හැකිද?

ඉතා පිළිගත හැකි ය. අපි මේක හැමතැනම පාවිච්චි කරනවා. අපට අපගේම සේවාවන් නොමැති බැවින්, අපි දුරස්ථ සහාය සපයන්නෙමු, අපට විවිධ ගනුදෙනුකරුවන් සිටී. තවද සෑම කෙනෙකුම මේ ගැන සම්පූර්ණයෙන්ම සෑහීමකට පත්වේ. එනම්, අපට පරීක්ෂා කරන ක්‍රෝන් රැකියා තිබේ. සැසිවල කාලසීමාව සේවාදායකයා සමඟ සරලව එකඟ වී ඇති අතර, ඊට පෙර අපි එකඟ නොවෙමු. එය විනාඩියක් විය හැකිය, එය විනාඩි 10 ක් විය හැකිය. එය පදනම මත බර පැටවීම සහ එහි අරමුණ මත රඳා පවතී. නමුත් අපි හැමෝම pg_stat_activity භාවිතා කරනවා.

වාර්තාවට ස්තූතියි! මම ඔබේ වාර්තාව මගේ අයදුම්පත්වලට යෙදවීමට උත්සාහ කරමි. අපි සෑම තැනකම ගනුදෙනුවක් ආරම්භ කර එය සෑම තැනකම පැහැදිලිව සම්පූර්ණ කරන්නාක් මෙන් පෙනේ. යම් ව්යතිරේකයක් තිබේ නම්, ආපසු හැරීම තවමත් සිදු වේ. ඊට පස්සේ මම හිතන්න පටන් ගත්තා. සියල්ලට පසු, ගනුදෙනුව පැහැදිලිවම ආරම්භ නොවිය හැකිය. මෙය බොහෝ විට ගැහැණු ළමයාට ඉඟියක් විය හැකිය. මම වාර්තාවක් යාවත්කාලීන කළහොත්, ගනුදෙනුව PostgreSQL හි ආරම්භ වී සම්බන්ධතාවය විසන්ධි වූ විට පමණක් සම්පූර්ණ වේද?

ඔබ දැන් යෙදුම් මට්ටම ගැන කතා කරන්නේ නම්, එය ඔබ භාවිතා කරන ධාවකය මත, භාවිතා කරන ORM මත රඳා පවතී. එතන ගොඩක් settings තියෙනවා. ඔබ ස්වයංක්‍රීය කැපවීම සක්‍රීය කර ඇත්නම්, ගනුදෙනුවක් එතැනින් ආරම්භ වී වහාම වසා දමයි.

එනම්, එය යාවත්කාලීන වූ වහාම වසා දමයි?

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

ආයුබෝවන්! වාර්තාවට ස්තූතියි! අපි හිතමු අපිට ඉදිමුම සහ ඉදිමුණු දත්ත ගබඩාවක් තියෙනවා කියලා එතකොට server එකේ ඉඩ ඉවර වෙනවා. මෙම තත්ත්වය නිවැරදි කිරීමට මෙවලම් තිබේද?

සේවාදායකයේ ඉඩ නිසි ලෙස නිරීක්ෂණය කිරීම අවශ්ය වේ.

උදාහරණයක් ලෙස, DBA තේ සඳහා ගියේය, නිවාඩු නිකේතනයක යනාදිය.

ගොනු පද්ධතියක් නිර්මාණය කරන විට, දත්ත ලියා නොමැති අවම වශයෙන් යම් ආකාරයක උපස්ථ ඉඩක් නිර්මාණය වේ.

එය සම්පූර්ණයෙන්ම බිංදුවට වඩා අඩු නම් කුමක් කළ යුතුද?

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

වෙනත් මෙවලම් තිබේද?

එය සෑම විටම අතින් සාදා ඇත. සමහර දත්ත තීරණාත්මක වන අතර සමහරක් විවේචනාත්මක නොවන නිසා එහි කළ යුතු හොඳම දේ දේශීයව පැහැදිලි වේ. තවද එක් එක් දත්ත සමුදාය සහ එය සමඟ ක්‍රියා කරන යෙදුම සඳහා එය ව්‍යාපාරය මත රඳා පවතී. එය සෑම විටම දේශීයව තීරණය වේ.

වාර්තාවට ස්තූතියි! මට ප්‍රශ්න දෙකක් තියෙනවා. පළමුව, ඔබ ගණුදෙණු හිර වූ විට, මේස ඉඩ ප්‍රමාණය සහ දර්ශක ප්‍රමාණය යන දෙකම වර්ධනය වන බව පෙන්වන විනිවිදක පෙන්වීය. තවද වාර්තාවේ තවදුරටත් ටැබ්ලටය ඇසුරුම් කරන උපයෝගිතා පොකුරක් විය. දර්ශකය ගැන කුමක් කිව හැකිද?

ඒවත් පැක් කරනවා.

නමුත් රික්තකය දර්ශකයට බලපාන්නේ නැද්ද?

සමහරු දර්ශකයක් සමඟ වැඩ කරති. උදාහරණයක් ලෙස, pg_rapack, pgcompactable. රික්තකය දර්ශක ප්‍රතිනිර්මාණය කර ඒවාට බලපායි. VACUUM FULL සමඟ අදහස වන්නේ සියල්ල උඩින් ලිවීමයි, එනම් එය සෑම කෙනෙකු සමඟම ක්‍රියා කරයි.

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

අනුවර්තන ගැටුමකට හේතුව කුමක්ද? ක්‍රියාවලි සිදු වන මාස්ටර් අපට ඇත. අපට කාර් රික්තයක් සිදුවෙමින් පවතී. autovacuum ඇත්තටම කරන්නේ කුමක්ද? ඔහු පැරණි රේඛා කිහිපයක් කපා දමයි. මෙම අවස්ථාවේදී අපට මෙම පැරණි රේඛා කියවන අනුරුවෙහි ඉල්ලීමක් තිබේ නම් සහ මාස්ටර් මත ස්වයංක්‍රීය රික්තකය මෙම රේඛා නැවත ලිවීම සඳහා හැකි ලෙස සලකුණු කර ඇත්නම්, අපි ඒවා උඩින් ලිව්වෙමු. තවද අපට දත්ත පැකට්ටුවක් ලැබුණි, ඉල්ලීමට අවශ්‍ය රේඛා අනුරුව මත නැවත ලිවීමට අවශ්‍ය වූ විට, අනුරූ ක්‍රියාවලිය ඔබ වින්‍යාස කළ කල් ඉකුත්වන තෙක් බලා සිටිනු ඇත. එවිට PostgreSQL එයට වඩා වැදගත් දේ තීරණය කරයි. ඔහුට ඉල්ලීමට වඩා අනුකරණය වැදගත් වන අතර, අනුරුව මත මෙම වෙනස්කම් සිදු කිරීම සඳහා ඔහු ඉල්ලීමට වෙඩි තබයි.

ඇන්ඩ්‍රේ, මට ප්‍රශ්නයක් තියෙනවා. ඉදිරිපත් කිරීමේදී ඔබ පෙන්වූ මේ අපූරු ප්‍රස්ථාර, මේවා ඔබේ යම් ආකාරයක උපයෝගීතාවයක ප්‍රතිඵලයක් ද? ප්‍රස්තාර හැදුවේ කොහොමද?

මෙය සේවාවකි ඔක්මීටරය.

මෙය වාණිජ නිෂ්පාදනයක්ද?

ඔව්. මෙය වාණිජ නිෂ්පාදනයකි.

මූලාශ්රය: www.habr.com