Alexey Lesovsky විසින් 2015 වාර්තාව පිටපත් කිරීම "PostgreSQL අභ්‍යන්තර සංඛ්යාලේඛන වෙත ගැඹුරට කිමිදීම"
වාර්තාවේ කතුවරයාගෙන් වියාචනය: මෙම වාර්තාව 2015 නොවැම්බර් දිනැති බව මම සටහන් කරමි - වසර 4 කට වැඩි කාලයක් ගත වී ඇති අතර බොහෝ කාලයක් ගත වී ඇත. වාර්තාවේ සාකච්ඡා කර ඇති 9.4 අනුවාදය තවදුරටත් සහාය නොදක්වයි. පසුගිය වසර 4 තුළ, නව නිකුතු 5 ක් නිකුත් කර ඇති අතර, සංඛ්යාලේඛන සම්බන්ධයෙන් නව්‍යකරණයන්, වැඩිදියුණු කිරීම් සහ වෙනස්කම් රාශියක් දර්ශනය වී ඇති අතර සමහර ද්‍රව්‍ය යල් පැන ගිය සහ අදාළ නොවේ. මම සමාලෝචනය කළ පරිදි, මම මෙම ස්ථාන සලකුණු කිරීමට උත්සාහ කළේ ඔබ පාඨකයා නොමඟ යැවීමට නොවේ. මම මෙම ස්ථාන නැවත ලිව්වේ නැත, ඒවායින් බොහොමයක් තිබේ, ප්රතිඵලයක් වශයෙන්, සම්පූර්ණයෙන්ම වෙනස් වාර්තාවක් හැරෙනු ඇත.
PostgreSQL DBMS යනු විශාල යාන්ත්‍රණයක් වන අතර, මෙම යාන්ත්‍රණය බොහෝ උප පද්ධති වලින් සමන්විත වන අතර, එහි සම්බන්ධීකරණ කාර්යය DBMS හි ක්‍රියාකාරිත්වයට සෘජුවම බලපායි. මෙහෙයුම් අතරතුර, සංරචකවල ක්රියාකාරිත්වය පිළිබඳ සංඛ්යාලේඛන සහ තොරතුරු රැස් කරනු ලැබේ, එමඟින් ඔබට PostgreSQL හි කාර්යක්ෂමතාව තක්සේරු කිරීමට සහ කාර්ය සාධනය වැඩි දියුණු කිරීමට පියවර ගැනීමට ඉඩ සලසයි. කෙසේ වෙතත්, මෙම තොරතුරු බොහොමයක් ඇති අතර එය තරමක් සරල ආකාරයකින් ඉදිරිපත් කර ඇත. මෙම තොරතුරු සැකසීම සහ එය අර්ථ නිරූපණය කිරීම සමහර විට සම්පූර්ණයෙන්ම සුළු නොවන කාර්යයක් වන අතර, මෙවලම් සහ උපයෝගිතා "සත්වෝද්යානය" උසස් DBA පවා පහසුවෙන් ව්යාකූල කළ හැකිය.
සුභ සන්ධ්යාවක් මගේ නම ඇලෙක්සි. ඉල්යා පැවසූ පරිදි, මම PostgreSQL සංඛ්යාලේඛන ගැන කතා කරමි.
PostgreSQL ක්‍රියාකාරකම් සංඛ්යාලේඛන. PostgreSQL සතුව සංඛ්යාලේඛන දෙකක් ඇත. ක්‍රියාකාරකම් සංඛ්යාලේඛන, සාකච්ඡා කරනු ඇත. දත්ත බෙදා හැරීම පිළිබඳ කාලසටහන් සංඛ්යාලේඛන. මම විශේෂයෙන් PostgreSQL ක්‍රියාකාරකම් සංඛ්යාලේඛන ගැන කතා කරමි, එමඟින් අපට කාර්ය සාධනය විනිශ්චය කිරීමට සහ එය කෙසේ හෝ වැඩිදියුණු කිරීමට ඉඩ සලසයි.
ඔබට ඇති හෝ ඇති විය හැකි විවිධ ගැටළු විසඳීම සඳහා සංඛ්යාලේඛන ඵලදායී ලෙස භාවිතා කරන්නේ කෙසේදැයි මම ඔබට කියමි.
වාර්තාවේ නොතිබෙන්නේ කුමක්ද? වාර්තාවේ, මම උපලේඛකයාගේ සංඛ්යාලේඛන ස්පර්ශ නොකරමි, මන්ද. දත්ත සමුදායේ දත්ත ගබඩා කර ඇති ආකාරය සහ විමසුම් සැලසුම්කරු මෙම දත්තවල ගුණාත්මක හා ප්‍රමාණාත්මක ලක්ෂණ පිළිබඳ අදහසක් ලබා ගන්නේ කෙසේද යන්න පිළිබඳ වෙනම වාර්තාවක් සඳහා මෙය වෙනම මාතෘකාවකි.
තවද මෙවලම් සමාලෝචන නොමැත, මම එක් නිෂ්පාදනයක් තවත් නිෂ්පාදනයක් සමඟ සංසන්දනය නොකරමි. වෙළඳ ප්‍රචාරණයක් සිදු නොවනු ඇත. අපි මේක දාමු.
සංඛ්යාලේඛන භාවිතා කිරීම ප්රයෝජනවත් බව ඔබට පෙන්වීමට මට අවශ්‍යය. එය අවශ්යයි. බය නැතුව පාවිච්චි කරන්න. අපට අවශ්ය වන්නේ සරල SQL සහ SQL පිළිබඳ මූලික දැනුමක් පමණි.
ගැටළු විසඳීම සඳහා තෝරා ගත යුතු සංඛ්යාලේඛන මොනවාද යන්න ගැන අපි කතා කරමු.
අපි PostgreSQL දෙස බලා ක්‍රියාවලි බැලීමට මෙහෙයුම් පද්ධතිය මත විධානයක් ක්රියාත්මක කළහොත් අපට "කළු පෙට්ටියක්" පෙනෙනු ඇත. යමක් කරන සමහර ක්‍රියාවලීන් අපට පෙනෙනු ඇත, ඔවුන් එහි කරන්නේ කුමක්ද, ඔවුන් කරන්නේ කුමක්ද යන්න නමින් අපට දළ වශයෙන් සිතාගත හැකිය. නමුත්, ඇත්ත වශයෙන්ම, මෙය කළු පෙට්ටියක්, අපට ඇතුළත බැලිය නොහැක.
අපිට CPU load එක බලන්න පුළුවන් top, සමහර පද්ධති උපයෝගිතා මගින් මතක භාවිතය අපට දැකිය හැක, නමුත් අපට PostgreSQL තුලින් බැලීමට නොහැකි වනු ඇත. මේ සඳහා අපට වෙනත් මෙවලම් අවශ්ය වේ.
තව දුරටත්, කාලය ගත කරන්නේ කොතැනදැයි මම ඔබට කියමි. අපි එවැනි යෝජනා ක්‍රමයක ස්වරූපයෙන් PostgreSQL නියෝජනය කරන්නේ නම්, කාලය ගත කරන්නේ කොතැනටද යන්න පිළිතුරු දීමට හැකි වනු ඇත. මේවා කරුණු දෙකකි: එය යෙදුම් වලින් සේවාදායක ඉල්ලීම් සැකසීම සහ එය ක්‍රියාත්මකව තබා ගැනීමට PostgreSQL විසින් සිදු කරන පසුබිම් කාර්යයන් වේ.
අපි ඉහළ වම් කෙළවර දෙස බැලීමට පටන් ගත්තොත්, සේවාලාභී ඉල්ලීම් සකසන ආකාරය අපට දැක ගත හැකිය. ඉල්ලීම පැමිණෙන්නේ යෙදුමෙන් වන අතර වැඩිදුර වැඩ සඳහා සේවාදායක සැසියක් විවෘත වේ. ඉල්ලීම කාලසටහන්කරු වෙත යවනු ලැබේ. සැලසුම්කරු විමසුම් සැලැස්මක් ගොඩනඟයි. එය ක්රියාත්මක කිරීම සඳහා තවදුරටත් යවයි. වගු සහ දර්ශක හා සම්බන්ධ යම් ආකාරයක බ්ලොක් I / O දත්ත තිබේ. අවශ්ය දත්ත තැටි වලින් "බෙදාගත් බෆර" නම් විශේෂ ප්‍රදේශයක මතකයට කියවනු ලැබේ. විමසුමේ ප්රතිඵල, ඒවා යාවත්කාලීන, මකාදැමීම් නම්, WAL හි ගනුදෙනු ලොගයේ සටහන් වේ. සමහර සංඛ්‍යාන තොරතුරු ලොග් හෝ සංඛ්යාලේඛන එකතු කරන්නා වෙත යයි. සහ ඉල්ලීමේ ප්රතිඵලය සේවාදායකයා වෙත ආපසු ලබා දෙනු ලැබේ. ඊට පසු, සේවාදායකයාට නව ඉල්ලීමක් සමඟ සියල්ල නැවත කළ හැකිය.
පසුබිම් කාර්යයන් සහ පසුබිම් ක්‍රියාවලීන් සමඟ අපට ඇත්තේ කුමක්ද? දත්ත සමුදාය සාමාන්‍ය පරිදි ක්රියාත්මක වන සහ ක්රියාත්මක කරන ක්‍රියාවලි කිහිපයක් අප සතුව ඇත. මෙම ක්‍රියාවලි වාර්තාවේ ද ආවරණය වනු ඇත: මේවා ස්වයංක්‍රීය රික්තකය, මුරපොල, අනුකරණයට අදාළ ක්‍රියාවලි, පසුබිම් ලේඛකයා වේ. මම වාර්තා කරන විට මම ඒ සෑම එකක්ම ස්පර්ශ කරමි.
සංඛ්යාලේඛන සමඟ ඇති ගැටළු මොනවාද?
- තොරතුරු ගොඩක්. PostgreSQL 9.4 සංඛ්යාලේඛන දත්ත බැලීම සඳහා ප්‍රමිතික 109ක් සපයයි. කෙසේ වෙතත්, දත්ත සමුදාය බොහෝ වගු, ක්‍රම, දත්ත සමුදායන් ගබඩා කරන්නේ නම්, මෙම සියලු ප්‍රමිතික අනුරූප වගු සංඛ්‍යාවෙන්, දත්ත සමුදායෙන් ගුණ කළ යුතුය. එනම්, ඊටත් වඩා තොරතුරු තිබේ. ඒ වගේම ඒකේ ගිලෙන්න හරිම ලේසියි.
- ඊළඟ ගැටළුව වන්නේ සංඛ්යාලේඛන කවුන්ටර මගින් නිරූපණය කිරීමයි. අපි මෙම සංඛ්යා ලේඛන දෙස බැලුවහොත්, අපි නිරන්තරයෙන් වැඩිවන කවුන්ටර දකිනු ඇත. සංඛ්යාලේඛන නැවත සකස් කර බොහෝ කාලයක් ගත වී ඇත්නම්, අපට බිලියන ගණනක අගයන් පෙනෙනු ඇත. ඒ වගේම ඔවුන් අපට කිසිවක් කියන්නේ නැහැ.
- ඉතිහාසයක් නැත. ඔබට යම් ආකාරයක අසාර්ථකත්වයක් තිබේ නම්, විනාඩි 15-30 කට පෙර යමක් වැටුණි, ඔබට සංඛ්යාලේඛන භාවිතා කිරීමට සහ විනාඩි 15-30 කට පෙර සිදු වූ දේ බැලීමට නොහැකි වනු ඇත. මෙය ගැටලුවකි.
- PostgreSQL වෙත ගොඩනගා ඇති මෙවලමක් නොමැතිකම ගැටළුවකි. කර්නල් සංවර්ධකයින් කිසිදු උපයෝගීතාවයක් ලබා නොදේ. එයාලට එහෙම දෙයක් නෑ. ඔවුන් දත්ත ගබඩාවේ සංඛ්යාලේඛන පමණක් ලබා දෙයි. එය භාවිතා කරන්න, එයට ඉල්ලීමක් කරන්න, ඔබට අවශ්ය ඕනෑම දෙයක්, එය කරන්න.
- PostgreSQL තුළට සාදන ලද මෙවලමක් නොමැති බැවින්, මෙය තවත් ගැටළුවක් ඇති කරයි. තෙවන පාර්ශවීය මෙවලම් ගොඩක්. වැඩි හෝ අඩු සෘජු අත් ඇති සෑම සමාගමක්ම තමන්ගේම වැඩසටහනක් ලිවීමට උත්සාහ කරයි. එහි ප්රතිඵලයක් වශයෙන්, සංඛ්යාලේඛන සමඟ වැඩ කිරීමට ඔබට භාවිතා කළ හැකි මෙවලම් රාශියක් ප්‍රජාව සතුව ඇත. ඒවගේම සමහර ටූල් වල සමහර ෆීචර්ස් තියෙනව, අනිත් ටූල් වල වෙන ෆීචර්ස් නෑ, එහෙමත් නැත්තං අලුත් ෆීචර්ස් තියෙනව. ඔබ එකිනෙකා අතිච්ඡාදනය වන සහ විවිධ කාර්යයන් ඇති මෙවලම් දෙකක් හෝ තුනක් හෝ හතරක් භාවිතා කිරීමට අවශ්ය තත්වයක් පැන නගී. මෙය ඉතා අප්රසන්නය.
මෙයින් පහත දැක්වෙන්නේ කුමක්ද? වැඩසටහන් මත රඳා නොපවතින පරිදි සංඛ්යාලේඛන කෙලින්ම ලබා ගැනීමට හැකි වීම වැදගත් වේ, නැතහොත් කෙසේ හෝ මෙම වැඩසටහන් ඔබම වැඩිදියුණු කරන්න: ඔබේ ප්‍රතිලාභ ලබා ගැනීම සඳහා සමහර කාර්යයන් එකතු කරන්න.
ඔබට SQL පිළිබඳ මූලික දැනුමක් අවශ්ය වේ. සංඛ්යාලේඛන වලින් යම් දත්තයක් ලබා ගැනීමට, ඔබ SQL විමසුම් කළ යුතුය, එනම් ඔබ තෝරා ගැනීම, සම්බන්ධ වීම සිදු කරන්නේ කෙසේදැයි දැන ගැනීමට අවශ්ය වේ.
සංඛ්යාලේඛන අපට කරුණු කිහිපයක් කියයි. ඒවා කාණ්ඩවලට බෙදිය හැකිය.
- පළමු කාණ්ඩය වන්නේ දත්ත ගබඩාවේ සිදුවන සිදුවීම් ය. දත්ත සමුදාය තුළ යම් සිදුවීමක් සිදු වන්නේ මෙයයි: විමසුමක්, වගු ප්‍රවේශයක්, ස්වයංක්‍රීය රික්තකය, කැපවීම්, එවිට මේ සියල්ල සිදුවීම් වේ. මෙම සිදුවීම් වලට අනුරූප වන කවුන්ටර වැඩි වේ. තවද අපට මෙම සිදුවීම් නිරීක්ෂණය කළ හැකිය.
- දෙවන කාණ්ඩය වන්නේ වගු, දත්ත සමුදායන් වැනි වස්තූන්ගේ ගුණාංග වේ. ඔවුන්ට දේපල ඇත. මේස ප්රමාණය මෙයයි. අපට වගු වල වර්ධනය, දර්ශක වර්ධනය නිරීක්ෂණය කළ හැකිය. ගතිකත්වයේ වෙනස්කම් අපට දැකිය හැකිය.
- තුන්වන කාණ්ඩය වන්නේ උත්සවය සඳහා ගත කරන කාලයයි. ඉල්ලීම සිදුවීමකි. එයට තමන්ගේම නිශ්චිත කාල සීමාවක් ඇත. මෙතනින් පටන් ගත්තා, මෙතනින් ඉවරයි. අපට එය නිරීක්ෂණය කළ හැකිය. එක්කෝ තැටියෙන් බ්ලොක් එකක් කියවන කාලය හෝ ලිවීම. මේ දේවල් ද ලුහුබඳිනු ලැබේ.
සංඛ්යාලේඛන මූලාශ්‍ර පහත පරිදි ඉදිරිපත් කෙරේ.
- හවුල් මතකයේ (හවුල් බෆර) එහි ස්ථිතික දත්ත තැබීම සඳහා ඛණ්ඩයක් ඇත, ඇතැම් සිදුවීම් සිදු වූ විට හෝ දත්ත සමුදායේ ක්‍රියාකාරිත්වයේ සමහර අවස්ථා නිරන්තරයෙන් වැඩි වන කවුන්ටර ද ඇත.
- මෙම සියලු කවුන්ටර පරිශීලකයාට ලබා ගත නොහැකි අතර පරිපාලකයාට පවා ලබා ගත නොහැක. මේවා පහත් මට්ටමේ දේවල්. ඒවාට ප්‍රවේශ වීමට, PostgreSQL SQL ශ්‍රිතවල අතුරු මුහුණතක් සපයයි. අපට මෙම ශ්‍රිත භාවිතයෙන් තෝරාගත් තේරීම් සිදු කර යම් මෙට්රික් වර්ගයක් (හෝ ප්‍රමිතික කට්ටලයක්) ලබා ගත හැක.
- කෙසේ වෙතත්, මෙම කාර්යයන් භාවිතා කිරීම සැමවිටම පහසු නොවේ, එබැවින් බැලීම් සඳහා පදනම (VIEWs) ශ්‍රිත වේ. මේවා නිශ්චිත උප පද්ධතියක් හෝ දත්ත සමුදායේ ඇති සිදුවීම් මාලාවක් පිළිබඳ සංඛ්යාලේඛන සපයන අතථ්‍ය වගු වේ.
- මෙම බිල්ට්-ඉන් දසුන් (VIEWs) සංඛ්යාලේඛන සමඟ වැඩ කිරීමේ ප්‍රධාන පරිශීලක අතුරුමුහුණත වේ. ඒවා කිසිදු අමතර සැකසුම් නොමැතිව පෙරනිමියෙන් ලබා ගත හැකිය, ඔබට වහාම ඒවා භාවිතා කළ හැකිය, නැරඹීම, එතැනින් තොරතුරු ලබා ගන්න. ඒ වගේම දායකත්වයත් තියෙනවා. දායකත්වය නිල වේ. ඔබට postgresql-contrib පැකේජය ස්ථාපනය කළ හැකිය (උදාහරණයක් ලෙස, postgresql94-contrib), වින්‍යාසය තුළ අවශ්ය මොඩියුලය පැටවීම, ඒ සඳහා පරාමිති සඳහන් කිරීම, PostgreSQL නැවත ආරම්භ කිරීම සහ ඔබට එය භාවිතා කළ හැකිය. (සටහන. බෙදා හැරීම මත පදනම්ව, දායකත්වයේ මෑත සංස්කරණවල පැකේජය ප්‍රධාන පැකේජයේ කොටසකි).
- ඒ වගේම නිල නොවන දායකත්වයත් තියෙනවා. ඒවා සම්මත PostgreSQL බෙදාහැරීම සමඟ සපයා නැත. ඒවා සම්පාදනය කර හෝ පුස්තකාලයක් ලෙස ස්ථාපනය කළ යුතුය. මෙම නිල නොවන දායකත්වයේ සංවර්ධකයා ඉදිරිපත් කළ දේ මත පදනම්ව විකල්ප බෙහෙවින් වෙනස් විය හැකිය.
මෙම විනිවිදකය එම සියලුම දසුන් (VIEWs) සහ PostgreSQL 9.4 හි ඇති සමහර කාර්යයන් පෙන්වයි. අපට පෙනෙන පරිදි, ඒවායින් බොහොමයක් තිබේ. ඔබ එය පළමු වරට අත්විඳින්නේ නම් ව්යාකූල වීම ඉතා පහසුය.
කෙසේ වෙතත්, අපි පෙර පින්තූරය ගත්තොත් Как тратится время на PostgreSQL සහ මෙම ලැයිස්තුවට අනුකූලව, අපට මෙම පින්තූරය ලැබේ. සෑම දසුනක්ම (VIEWs), හෝ එක් එක් කාර්යය, අපට PostgreSQL ක්රියාත්මක වන විට සුදුසු සංඛ්යාලේඛන ලබා ගැනීමට අපට එක් අරමුණක් සඳහා භාවිතා කළ හැක. තවද අපට දැනටමත් උප පද්ධතියේ ක්රියාකාරිත්වය පිළිබඳ යම් තොරතුරු ලබා ගත හැකිය.
අපි බලමු පළමු දෙය pg_stat_database. අපට පෙනෙන පරිදි, මෙය නිරූපණයකි. එහි බොහෝ තොරතුරු අඩංගු වේ. වඩාත්ම විවිධාකාර තොරතුරු. තවද එය දත්ත සමුදායේ අප සිදුවෙමින් පවතින දේ පිළිබඳ ඉතා ප්රයෝජනවත් දැනුමක් ලබා දෙයි.
අපට එතැනින් ගත හැක්කේ කුමක්ද? අපි සරලම දේ සමඟ ආරම්භ කරමු.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;අපට බැලිය හැකි පළමු දෙය නම් හැඹිලි පහර ප්‍රතිශතයයි. හැඹිලි පහර ප්රතිශතය ප්රයෝජනවත් මෙට්රික් එකකි. බෙදාගත් බෆර් හැඹිලියෙන් කොපමණ දත්ත ලබා ගන්නේද සහ තැටියෙන් කොපමණ ප්‍රමාණයක් කියවා ඇත්දැයි තක්සේරු කිරීමට එය ඔබට ඉඩ සලසයි.
එය පැහැදිලි වේ අපට හැඹිලි පහර වැඩි වන තරමට වඩා හොඳය. අපි මෙම මිතිකය ප්‍රතිශතයක් ලෙස ඇගයීමට ලක් කරමු. තවද, උදාහරණයක් ලෙස, අපට මෙම හැඹිලි ප්රතිශතය 90% ට වඩා වැඩි නම්, මෙය හොඳයි. එය 90% ට වඩා පහත වැටේ නම්, උණුසුම් දත්ත මතකයේ තබා ගැනීමට අපට ප්‍රමාණවත් මතකයක් නොමැත. තවද මෙම දත්ත භාවිතා කිරීම සඳහා, PostgreSQL තැටියට ප්‍රවේශ වීමට බල කෙරෙන අතර මෙය දත්ත මතකයෙන් කියවනවාට වඩා මන්දගාමී වේ. මතකය වැඩි කිරීම ගැන ඔබ සිතිය යුතුය: එක්කෝ හවුල් බෆර වැඩි කරන්න, නැතහොත් යකඩ මතකය වැඩි කරන්න (RAM).
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;මෙම රංගනයෙන් තවත් ගත හැක්කේ කුමක්ද? දත්ත ගබඩාවේ සිදුවන විෂමතා ඔබට දැක ගත හැකිය. මෙහි පෙන්වා ඇත්තේ කුමක්ද? කැපවීම්, ආපසු හැරීම්, තාවකාලික ලිපිගොනු නිර්මාණය කිරීම, ඒවායේ ප්රමාණය, අවහිරතා සහ ගැටුම් ඇත.
අපට මෙම ඉල්ලීම භාවිතා කළ හැකිය. මෙම SQL ඉතා සරලයි. තවද මෙම දත්ත අපටම දැක ගත හැකිය.
තවද මෙහි threshold අගයන් වේ. අපි කැපවීම් සහ ආපසු හැරීමේ අනුපාතය දෙස බලමු. කොමිට්ස් යනු ගනුදෙනුව සාර්ථක ලෙස තහවුරු කිරීමකි. Rollbacks යනු ආපසු හැරීමකි, එනම් ගනුදෙනුව යම් කාර්යයක් කර, දත්ත සමුදාය වෙහෙසට පත් කර, යමක් සලකා බලා, පසුව අසාර්ථක වීමක් සිදු වූ අතර, ගනුදෙනුවේ ප්රතිඵල ඉවත දමනු ලැබේ. i.e. නිරන්තරයෙන් වැඩිවන ආපසු හැරීම් ගණන නරක ය. ඔබ කෙසේ හෝ ඒවා වළක්වා, මෙය සිදු නොවන පරිදි කේතය සංස්කරණය කළ යුතුය.
ගැටුම් අනුකරණයට සම්බන්ධයි. තවද ඒවායින් වැළකී සිටිය යුතුය. ඔබට අනුරුව මත ක්රියාත්මක වන විමසුම් කිහිපයක් තිබේ නම් සහ ගැටුම් ඇති වන්නේ නම්, ඔබ මෙම ගැටුම් විශ්ලේෂණය කර සිදුවන්නේ කුමක්දැයි බැලීමට අවශ්ය වේ. විස්තර ලඝු-සටහන් වලින් සොයාගත හැකිය. යෙදුම් ඉල්ලීම් දෝෂයකින් තොරව ක්රියාත්මක වන පරිදි ගැටුම් නිරාකරණය කරන්න.
Deadlocks ද නරක තත්ත්වයකි. ඉල්ලීම් සම්පත් සඳහා තරඟ කරන විට, එක් ඉල්ලීමක් එක් සම්පතක් වෙත ප්‍රවේශ වී අගුලක් ගත් විට, දෙවන ඉල්ලීම දෙවන සම්පතට ප්‍රවේශ වී අගුලද ගත්තේය, පසුව ඉල්ලීම් දෙකම එකිනෙකාගේ සම්පත් වෙත ප්‍රවේශ වී අසල්වැසියා අගුල මුදා හරින තෙක් බලා සිටීම අවහිර කළේය. මෙයද ගැටලු සහගත තත්ත්වයකි. යෙදුම් නැවත ලිවීමේ මට්ටමින් සහ සම්පත් වෙත ප්‍රවේශය අනුක්‍රමිකකරණය කිරීමේ මට්ටමින් ඒවා ආමන්ත්‍රණය කළ යුතුය. ඔබේ අවහිරතා නිරන්තරයෙන් වැඩි වන බව ඔබ දුටුවහොත්, ඔබ ලඝු-සටහන් වල විස්තර දෙස බැලිය යුතුය, පැන නැගී ඇති තත්වයන් විශ්ලේෂණය කර ගැටලුව කුමක්දැයි බලන්න.
තාවකාලික ගොනු (temp_files) ද නරක ය. පරිශීලක ඉල්ලීමකට මෙහෙයුම්, තාවකාලික දත්ත සඳහා ප්‍රමාණවත් මතකයක් නොමැති විට, එය තැටියේ ගොනුවක් නිර්මාණය කරයි. මතකයේ තාවකාලික බෆරයක ඔහුට කළ හැකි සියලුම මෙහෙයුම්, ඔහු දැනටමත් තැටියේ සිදු කිරීමට පටන් ගනී. එය මන්දගාමීයි. මෙය විමසුම් ක්රියාත්මක කිරීමේ කාලය වැඩි කරයි. PostgreSQL වෙත ඉල්ලීමක් යැවූ සේවාදායකයාට ටික වේලාවකට පසුව ප්‍රතිචාරයක් ලැබෙනු ඇත. මෙම සියලු මෙහෙයුම් මතකයේ සිදු කරන්නේ නම්, Postgres වඩා වේගයෙන් ප්රතිචාර දක්වන අතර සේවාදායකයා අඩුවෙන් බලා සිටියි.
pg_stat_bgwriter - මෙම දර්ශනය PostgreSQL පසුබිම් උප පද්ධති දෙකක ක්රියාකාරිත්වය විස්තර කරයි: checkpointer и background writer.
ආරම්භ කිරීම සඳහා, ඊනියා පාලන ස්ථාන විශ්ලේෂණය කරමු. checkpoints. මුරපොලවල් මොනවාද? මුරපොලක් යනු ගනුදෙනු ලොගයේ පිහිටීමක් වන අතර ලොගයේ සිදු කරන ලද සියලුම දත්ත වෙනස් කිරීම් තැටියේ ඇති දත්ත සමඟ සාර්ථකව සමමුහුර්ත කර ඇති බව පෙන්නුම් කරයි. මෙම ක්‍රියාවලිය, කාර්ය භාරය සහ සැකසීම් මත පදනම්ව, දිගු විය හැකි අතර බොහෝ විට තැටියේ ඇති දත්ත ගොනු සමඟ බෙදාගත් බෆරවල අපිරිසිදු පිටු සමමුහුර්ත කිරීම සමන්විත වේ. එය කුමක් සදහාද? PostgreSQL සෑම විටම තැටියට ප්‍රවේශ වෙමින් එතැනින් දත්ත ලබා ගනිමින් එක් එක් ප්‍රවේශය මත දත්ත ලිවීම සිදු කරන්නේ නම්, එය මන්දගාමී වනු ඇත. එබැවින්, PostgreSQL හි මතක අංශයක් ඇත, එහි විශාලත්වය වින්‍යාසයේ ඇති පරාමිතීන් මත රඳා පවතී. Postgres විසින් මෙම මතකයේ මෙහෙයුම් දත්ත තවදුරටත් සැකසීමට හෝ විමසීම සඳහා වෙන් කරයි. දත්ත වෙනස් කිරීමේ ඉල්ලීම් වලදී, ඒවා වෙනස් වේ. තවද අපට දත්ත අනුවාද දෙකක් ලැබේ. එකක් මතකයේ, අනෙක තැටියේ. සහ වරින් වර ඔබ මෙම දත්ත සමමුහුර්ත කිරීමට අවශ්ය වේ. තැටියට සමමුහුර්ත කිරීමට මතකයේ වෙනස් කළ දේ අපට අවශ්ය වේ. මේ සඳහා මුරපොලක් අවශ්ය වේ.
මුරපොල බෙදාගත් බෆර හරහා ගමන් කරයි, මුරපොල සඳහා අවශ්ය අපිරිසිදු පිටු සලකුණු කරයි. එවිට එය හවුල් බෆර හරහා දෙවන ගමන් කිරීම ආරම්භ කරයි. මුරපොල සඳහා සලකුණු කර ඇති පිටු, ඔහු දැනටමත් ඒවා සමමුහුර්ත කරයි. මේ අනුව, දත්ත තැටිය සමඟ දැනටමත් සමමුහුර්ත කර ඇත.
පාලන ස්ථාන වර්ග දෙකක් තිබේ. එක් මුරපොලක් කල් ඉකුත් වූ විට ක්රියාත්මක වේ. මෙම මුරපොල ප්රයෝජනවත් සහ හොඳයි - checkpoint_timed. සහ ඉල්ලුම මත මුරපොලවල් ඇත - checkpoint required. එවැනි මුරපොලක් අපට ඉතා විශාල දත්ත වාර්තාවක් ඇති විට සිදු වේ. අපි ගනුදෙනු ලොග් ගොඩක් වාර්තා කළා. PostgreSQL විශ්වාස කරන්නේ හැකි ඉක්මනින් මේ සියල්ල සමමුහුර්ත කර, මුරපොලක් සාදා ඉදිරියට යා යුතු බවයි.
සහ ඔබ සංඛ්යා ලේඛන දෙස බැලුවහොත් pg_stat_bgwriter සහ ඔබ සතුව ඇති දේ බලන්න checkpoint_req checkpoint_timed වඩා විශාලයි, එවිට මෙය නරකයි. ඇයි නරක? මෙයින් අදහස් කරන්නේ තැටියට දත්ත ලිවීමට අවශ්ය වූ විට PostgreSQL නිරන්තර ආතතියට ලක්වන බවයි. කල් ඉකුත්වීම මගින් මුරපොල අඩු ආතතියකින් යුක්ත වන අතර අභ්‍යන්තර කාලසටහනට අනුව ක්රියාත්මක වන අතර එය කාලයත් සමඟ දිගු වේ. PostgreSQL හට වැඩ නතර කිරීමට සහ තැටි උප පද්ධතියට බාධා නොකිරීමට හැකියාව ඇත. මෙය PostgreSQL සඳහා ප්රයෝජනවත් වේ. මුරපොලේදී ක්රියාත්මක වන ඉල්ලීම් තැටි උප පද්ධතිය කාර්යබහුල වීම නිසා ආතතිය අත්විඳිය නොහැක.
මුරපොල සකස් කිරීම සඳහා පරාමිති තුනක් ඇත:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
පාලන ලක්ෂ්යවල ක්රියාකාරිත්වය පාලනය කිරීමට ඔවුන් ඔබට ඉඩ සලසයි. නමුත් මම ඒවා මත රැඳී නොසිටිමි. ඔවුන්ගේ බලපෑම වෙනම ප්රශ්නයක්.
Внимание: වාර්තාවේ සලකා බැලූ 9.4 අනුවාදය තවදුරටත් අදාළ නොවේ. PostgreSQL හි නවීන අනුවාද වල, පරාමිතිය checkpoint_segments පරාමිති මගින් ප්රතිස්ථාපනය වේ min_wal_size и max_wal_size.
ඊළඟ උප පද්ධතිය පසුබිම් ලේඛකයා වේ background writer. ඔහු මොනවද කරන්නේ? එය නිමක් නැති ලූපයක් තුළ නිරන්තරයෙන් ධාවනය වේ. එය බෙදාගත් බෆරවලට පිටු පරිලෝකනය කරන අතර එය සොයා ගන්නා අපිරිසිදු පිටු තැටියට ෆ්ලෂ් කරයි. මේ ආකාරයෙන්, චෙක්පොයින්ටර් වලදී අඩු වැඩ කිරීමට චෙක්පොයින්ටර්ට උපකාර කරයි.
ඔහු තව කුමක් සඳහා අවශ්යද? එය හදිසියේ (විශාල ප්‍රමාණවලින් සහ ක්ෂණිකව) දත්ත ගබඩා කිරීමට අවශ්ය නම්, බෙදාගත් බෆරවල පිරිසිදු පිටු අවශ්ය වේ. ඉල්ලීමට පිරිසිදු පිටු අවශ්ය වූ විට තත්වයක් ඇති වූ අතර ඒවා දැනටමත් හවුල් බෆරවල තිබේ යැයි සිතමු. Postgres backend ඔහු ඒවා රැගෙන ඒවා භාවිතා කරයි, ඔහුට කිසිවක් පිරිසිදු කිරීමට අවශ්ය නැත. නමුත් හදිසියේ එවැනි පිටු නොමැති නම්, පසුපෙළ විරාමයක් තබා ඒවා තැටියට ෆ්ලෂ් කිරීමට සහ තමන්ගේ අවශ්‍යතා සඳහා ඒවා ගැනීමට පිටු සෙවීමට පටන් ගනී - එය දැනට ක්රියාත්මක වන ඉල්ලීමේ වේලාවට අහිතකර ලෙස බලපායි. ඔබට පරාමිතියක් ඇති බව ඔබ දුටුවහොත් maxwritten_clean විශාලයි, මෙයින් අදහස් කරන්නේ පසුබිම් ලේඛකයා එහි කාර්යය ඉටු නොකරන අතර ඔබ පරාමිති වැඩි කළ යුතු බවයි bgwriter_lru_maxpagesඔහුට එක චක්‍රයක් තුළ වැඩිපුර වැඩ කිරීමට හැකි වන පරිදි, තවත් පිටු හිස් කරන්න.
සහ තවත් ඉතා ප්රයෝජනවත් දර්ශකයකි buffers_backend_fsync. එය මන්දගාමී නිසා පසුපෙළ fsync නොකරයි. ඔවුන් IO ස්ටැක් චෙක්පොයින්ටරය දක්වා fsync සමත් වේ. චෙක්පොයින්ටරයට තමන්ගේම පෝලිමක් ඇත, එය වරින් වර fsync සකසන අතර තැටියේ ඇති ගොනු සමඟ මතකයේ පිටු සමමුහුර්ත කරයි. චෙක්පොයින්ටර් පෝලිම විශාල සහ පිරී තිබේ නම්, පසු අන්තයටම fsync කිරීමට බල කෙරෙන අතර මෙය පසු අන්තය මන්දගාමී කරයි., එනම් සේවාදායකයාට ප්‍රතිචාරයක් ලැබිය හැකි ප්‍රමාණයට වඩා පසුව ලැබෙනු ඇත. ඔබට මෙම අගය ශුන්‍යයට වඩා වැඩි බව ඔබ දකින්නේ නම්, මෙය දැනටමත් ගැටළුවක් සහ ඔබ පසුබිම් ලේඛකයාගේ සැකසුම් කෙරෙහි අවධානය යොමු කළ යුතු අතර තැටි උප පද්ධතියේ ක්රියාකාරිත්වය ද ඇගයීමට ලක් කළ යුතුය.
Внимание: _පහත දැක්වෙන පෙළ අනුකරණය හා සම්බන්ධ සංඛ්‍යානමය දසුන් විස්තර කරයි. බොහෝ දර්ශන සහ ශ්‍රිත නාමයන් Postgres 10 හි නැවත නම් කර ඇත. නැවත නම්වල සාරය වූයේ ප්රතිස්ථාපනය කිරීමයි. xlog මත wal и location මත lsn ශ්‍රිතය/දර්ශන නම් යනාදී වශයෙන්. විශේෂ උදාහරණයක්, කාර්යය pg_xlog_location_diff() ලෙස නැවත නම් කරන ලදී pg_wal_lsn_diff()._
අපිටත් මෙතන ගොඩක් තියෙනවා. නමුත් අපට අවශ්ය වන්නේ ස්ථානයට අදාළ අයිතම පමණි.
සියලුම අගයන් සමාන බව අප දුටුවහොත්, මෙය පරමාදර්ශී වන අතර අනුරුව ස්වාමියාට වඩා පසුගාමී නොවේ.
මෙහි මෙම ෂඩ් දශම පිහිටීම ගනුදෙනු ලොගයේ පිහිටීමයි. දත්ත සමුදායේ යම් ක්‍රියාකාරකම් තිබේ නම් එය නිරන්තරයෙන් වැඩි වේ: ඇතුළු කිරීම්, මකා දැමීම්, ආදිය.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());මේ දේවල් වෙනස් නම්, යම් ආකාරයක පසුබෑමක් තිබේ. Lag යනු මාස්ටර් වෙතින් අනුරුවේ ප්‍රමාදයයි, එනම් දත්ත සේවාදායකයන් අතර වෙනස් වේ.
ප්‍රමාදයට හේතු තුනක් ඇත:
- එය ගොනු සමමුහුර්ත ලිවීම් හැසිරවිය නොහැකි තැටි උප පද්ධතියයි.
- දත්තවලට අනුරුව වෙත ළඟා වීමට කාලය නොමැති විට සහ එය ප්‍රතිනිෂ්පාදනය කිරීමට නොහැකි වූ විට මේවා විය හැකි ජාල දෝෂ හෝ ජාල අධි බර වේ.
- සහ ප්රොසෙසරය. ප්රොසෙසරය ඉතා දුර්ලභ අවස්ථාවකි. අනික මම ඕක දෙතුන් පාරක් දැකල තියෙනව ඒත් එහෙම වෙන්න පුලුවන්.
සංඛ්යාලේඛන භාවිතා කිරීමට අපට ඉඩ සලසන විමසුම් තුනක් මෙන්න. අපගේ ගනුදෙනු ලොගයේ කොපමණ ප්‍රමාණයක් සටහන් වී ඇත්දැයි අපට තක්සේරු කළ හැක. එවැනි කාර්යයක් තිබේ pg_xlog_location_diff සහ අපට බයිට් සහ තත්පර වලින් අනුකරණ ප්‍රමාදය තක්සේරු කළ හැක. අපි මේ සඳහා මෙම දර්ශනයේ (VIEWs) අගය ද භාවිතා කරමු.
සටහන: _pg_xlog_location වෙනුවටdiff() ශ්‍රිතය, ඔබට අඩු කිරීමේ ක්‍රියාකරු භාවිතා කර එක් ස්ථානයක් තවත් ස්ථානයකින් අඩු කළ හැක. සුවපහසුයි.
ප්‍රමාදයකින්, එනම් තත්පර කිහිපයකින්, එක මොහොතක් ඇත. මාස්ටර් මත ක්‍රියාකාරකමක් නොමැති නම්, ගනුදෙනුව මිනිත්තු 15 කට පමණ පෙර පැවති අතර කිසිදු ක්‍රියාකාරකමක් නොමැති අතර, අනුරුවේ මෙම ප්‍රමාදය දෙස බැලුවහොත්, අපට විනාඩි 15 ක ප්‍රමාදයක් පෙනෙනු ඇත. මෙය මතක තබා ගැනීම වටී. තවද ඔබ මෙම ප්‍රමාදය නරඹන විට එය මෝඩකමට හේතු විය හැක.
pg_stat_all_tables තවත් ප්රයෝජනවත් දසුනකි. එය වගු මත සංඛ්යා ලේඛන පෙන්වයි. අපි දත්ත ගබඩාවේ වගු ඇති විට, එය සමඟ යම් ක්‍රියාකාරකම්, සමහර ක්‍රියා ඇති විට, අපට මෙම දර්ශනයෙන් මෙම තොරතුරු ලබා ගත හැකිය.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;අපට බැලිය හැකි පළමු දෙය අනුක්‍රමික වගු ස්කෑන් ය. මෙම ඡේදවලින් පසුව ඇති අංකයම අනිවාර්යයෙන්ම නරක නොවන අතර අප දැනටමත් යමක් කළ යුතු බව අඟවන්නේ නැත.
කෙසේ වෙතත්, දෙවන මෙට්රික් එකක් ඇත - seq_tup_read. අනුක්‍රමික ස්කෑන් කිරීමෙන් ආපසු ලැබුණු පේළි ගණන මෙයයි. සාමාන්‍ය සංඛ්‍යාව 1, 000, 10, 000 ඉක්මවන්නේ නම්, මෙය දැනටමත් දර්ශකයක් වන අතර එමඟින් ප්‍රවේශයන් දර්ශක අනුව වන පරිදි ඔබට කොතැනක හෝ දර්ශකයක් තැනීමට අවශ්ය විය හැකිය, නැතහොත් එවැනි අනුක්‍රමික ස්කෑන් භාවිතා කරන විමසුම් ප්‍රශස්ත කිරීමට හැකි වේ. මෙය සිදු නොවේ.
සරල උදාහරණයක් - විශාල OFFSET සහ LIMIT සහිත ඉල්ලීමක් වටිනවා යැයි සිතමු. උදාහරණයක් ලෙස, වගුවක ඇති පේළි 100 ක් ස්කෑන් කර ඉන් පසුව අවශ්ය පේළි 000 ක් ගෙන කලින් ස්කෑන් කළ පේළි ඉවත දමනු ලැබේ. මේකත් නරක කේස් එකක්. තවද එවැනි ඉල්ලීම් ප්‍රශස්ත කළ යුතුය. මෙන්න එවැනි සරල SQL විමසුමක් ඔබට එය දැක ගත හැකි අතර ලැබුණු අංක ඇගයීමට හැකිය.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;මෙම වගුව භාවිතයෙන් සහ අතිරේක කාර්යයන් භාවිතා කරමින් වගු ප්රමාණය ද ලබා ගත හැකිය pg_total_relation_size(), pg_relation_size().
පොදුවේ ගත් කල, metacommands ඇත dt и di, ඔබට PSQL හි භාවිතා කළ හැකි අතර වගු සහ දර්ශක ප්‍රමාණ ද බලන්න.
කෙසේ වෙතත්, ශ්‍රිත භාවිතය අපට වගු වල ප්‍රමාණයන් බැලීමට, දර්ශක සැලකිල්ලට නොගෙන, හෝ දර්ශක සැලකිල්ලට නොගෙන, දැනටමත් දත්ත සමුදායේ වර්ධනය මත පදනම්ව සමහර ඇස්තමේන්තු සකස් කිරීමට උපකාරී වේ, එනම් එය අප සමඟ වර්ධනය වන ආකාරය කුමන තීව්‍රතාවයද, සහ ප්‍රමාණ ප්‍රශස්තකරණය පිළිබඳව දැනටමත් යම් නිගමනවලට එළඹ ඇත.
ක්‍රියාකාරකම් ලියන්න. වාර්තාවක් යනු කුමක්ද? මෙහෙයුම දෙස බලමු UPDATE - වගුවේ පේළි යාවත්කාලීන කිරීමේ මෙහෙයුම. ඇත්ත වශයෙන්ම, යාවත්කාලීන කිරීම යනු මෙහෙයුම් දෙකකි (හෝ ඊටත් වඩා). මෙය නව පේළි අනුවාදයක් ඇතුළත් කිරීම සහ පැරණි පේළි අනුවාදය යල් පැන ගිය ලෙස සලකුණු කිරීමකි. පසුව, autovacuum පැමිණ මෙම යල්පැන ගිය රේඛාවල අනුවාද ඉවත් කර, මෙම ස්ථානය නැවත භාවිතය සඳහා ඇති ලෙස සලකුණු කරන්න.
එසේම, යාවත්කාලීන කිරීම යනු වගුවක් යාවත්කාලීන කිරීම පමණක් නොවේ. එය තවමත් දර්ශක යාවත්කාලීන කිරීමකි. ඔබට මේසය මත බොහෝ දර්ශක තිබේ නම්, යාවත්කාලීනය සමඟ, විමසුමට යාවත්කාලීන කරන ලද ක්ෂේත්‍ර සහභාගී වන සියලුම දර්ශක ද යාවත්කාලීන කළ යුතුය. මෙම දර්ශක පිරිසිදු කළ යුතු යල් පැන ගිය පේළි අනුවාද ද ඇත.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;තවද එහි සැලසුම නිසා UPDATE යනු හෙවිවේට් මෙහෙයුමකි. නමුත් ඒවා පහසු කර ගත හැකිය. කන්න hot updates. ඒවා PostgreSQL අනුවාදය 8.3 හි දර්ශනය විය. සහ මේ කුමක්ද? මෙය දර්ශක නැවත ගොඩනැගීමට හේතු නොවන සැහැල්ලු යාවත්කාලීනයකි. එනම්, අපි වාර්තාව යාවත්කාලීන කළ නමුත්, පිටුවේ (වගුවට අයත් වන) වාර්තාව පමණක් යාවත්කාලීන කර ඇති අතර, දර්ශක තවමත් පිටුවේ එකම වාර්තාවට යොමු කරයි. ඔය වගේ රසවත් ලොජික් ටිකක් තියෙනවා වැඩේ, රික්තකයක් ආවම මේ දාම තියෙනවා. hot නැවත ගොඩනඟන අතර සෑම දෙයක්ම දර්ශක යාවත්කාලීන කිරීමකින් තොරව දිගටම ක්‍රියා කරයි, සහ සෑම දෙයක්ම සිදුවන්නේ අඩු සම්පත් නාස්තියකිනි.
සහ ඔබට ඇති විට n_tup_hot_upd විශාලයි, එය ඉතා හොඳයි. මෙයින් අදහස් කරන්නේ සැහැල්ලු යාවත්කාලීනයන් පවතින අතර සම්පත් අතින් මෙය අපට වඩා ලාභදායී වන අතර සියල්ල හොඳයි.
ALTER TABLE table_name SET (fillfactor = 70);පරිමාව වැඩි කරන්නේ කෙසේද hot updateov? අපිට පාවිච්චි කරන්න පුළුවන් fillfactor. එය INSERT භාවිතා කර වගුවක පිටුවක් පුරවන විට වෙන් කර ඇති නිදහස් ඉඩ ප්රමාණය තීරණය කරයි. ඇතුළු කිරීම් මේසය වෙත ගිය විට, ඒවා සම්පූර්ණයෙන්ම පිටුව පුරවන්න, එහි හිස් ඉඩ ඉතිරි නොකරන්න. එවිට නව පිටුවක් ඉස්මතු වේ. දත්ත නැවත පුරවා ඇත. තවද මෙය පෙරනිමි හැසිරීමයි, පිරවුම් සාධකය = 100%.
අපට පිරවුම් සාධකය 70% දක්වා සැකසිය හැකිය. එනම්, ඇතුළු කිරීම් සමඟ, නව පිටුවක් වෙන් කර ඇත, නමුත් පිටුවෙන් 70% ක් පමණක් පිරී ඇත. ඒ වගේම අපිට 30%ක් ඉතිරි වෙලා තියෙනවා. ඔබට යාවත්කාලීනයක් කිරීමට අවශ්ය වූ විට, එය බොහෝ විට එකම පිටුවක සිදුවනු ඇති අතර, පේළියේ නව අනුවාදය එකම පිටුවට ගැලපේ. සහ hot_update සිදු කරනු ඇත. මෙය වගු මත ලිවීම පහසු කරයි.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Autovacuum පෝලිම. Autovacuum යනු PostgreSQL හි සංඛ්යාලේඛන ඉතා ස්වල්පයක් ඇති එවැනි උප පද්ධතියකි. pg_stat_activity හි ඇති වගු වල පමණක් අපට මේ මොහොතේ රික්තක කීයක් තිබේදැයි දැකිය හැක. කෙසේ වෙතත්, එය යන විට පෝලිමේ කොපමණ වගු තිබේද යන්න තේරුම් ගැනීම ඉතා අපහසුය.
සටහන: _Postgres 10 සිට, රික්ත රික්තය නිරීක්ෂණය කිරීමේ තත්ත්වය බොහෝ දියුණු වී ඇත - pg_stat_progress දසුන දර්ශනය වී ඇත.රික්තය, එය ස්වයංක්‍රීය රික්ත නිරීක්ෂණ ගැටළුව බෙහෙවින් සරල කරයි.
අපට මෙම සරල කළ විමසුම භාවිතා කළ හැක. රික්තය සෑදිය යුත්තේ කවදාදැයි අපට දැක ගත හැකිය. එහෙත්, රික්තය ආරම්භ කළ යුත්තේ කෙසේද සහ කවදාද? මේ මම කලින් කතා කරපු තන්තු වල පරණ වර්ෂන්. යාවත්කාලීනය සිදුවී ඇත, පේළියේ නව අනුවාදය ඇතුළත් කර ඇත. තන්තුවෙහි යල් පැන ගිය අනුවාදයක් දර්ශනය වී ඇත. වගුව pg_stat_user_tables එවැනි පරාමිතියක් තිබේ n_dead_tup. එය "මියගිය" පේළි ගණන පෙන්වයි. මළ පේළි ගණන නිශ්චිත සීමාවකට වඩා වැඩි වූ වහාම, ස්වයංක්‍රීය රික්තයක් මේසයට පැමිණේ.
සහ මෙම සීමාව ගණනය කරන්නේ කෙසේද? මෙය වගුවේ ඇති මුළු පේළි ගණනින් ඉතා නිශ්චිත ප්‍රතිශතයකි. පරාමිතියක් ඇත autovacuum_vacuum_scale_factor. එය ප්රතිශතය නිර්වචනය කරයි. අපි හිතමු 10% + පේළි 50ක අමතර මූලික සීමාවක් තියෙනවා. සහ කුමක් සිදුවේද? අපි වගුවේ ඇති සියලුම පේළි වලින් "10% + 50" ට වඩා මිය ගිය පේළි ඇති විට, අපි මේසය autovacuum මත තබමු.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));කෙසේ වෙතත්, එක් කරුණක් තිබේ. පරාමිතීන් සඳහා මූලික සීමාවන් av_base_thresh и av_scale_factor තනි තනිව පැවරිය හැක. තවද, ඒ අනුව, එළිපත්ත ගෝලීය නොවනු ඇත, නමුත් මේසය සඳහා තනි පුද්ගලයෙකි. එමනිසා, ගණනය කිරීම සඳහා, එහිදී ඔබ උපක්රම සහ උපක්රම භාවිතා කළ යුතුය. ඔබ උනන්දුවක් දක්වන්නේ නම්, ඔබට Avito වෙතින් අපගේ සගයන්ගේ අත්දැකීම් දෙස බැලිය හැකිය (විනිවිදකයේ ඇති සබැඳිය වලංගු නොවන අතර පෙළෙහි යාවත්කාලීන කර ඇත).
සඳහා ඔවුන් ලිවීය මේ දේවල් සැලකිල්ලට ගන්නවා කියලා. ඇඳ ඇතිරිලි දෙකක් මත අඩි රෙද්දක් ඇත. නමුත් ඔහු නිවැරදිව සිතන අතර තරමක් ඵලදායී ලෙස අපට කුඩා වගු සඳහා රික්තකයක් අවශ්ය වන්නේ කොතැනද යන්න තක්සේරු කිරීමට අපට ඉඩ සලසයි.
ඒ ගැන අපට කුමක් කළ හැකිද? අපට දිගු පෝලිමක් තිබේ නම් සහ ස්වයංක්‍රීය රික්තයට මුහුණ දිය නොහැකි නම්, අපට රික්ත සේවකයින් සංඛ්‍යාව වැඩි කළ හැකිය, නැතහොත් රික්තය වඩාත් ආක්‍රමණශීලී කළ හැකිය.එය කලින් අවුලුවන පරිදි, මේසය කුඩා කැබලිවලට සකසයි. ඒ නිසා පෝලිම අඩු වේවි. - මෙහි ප්රධානතම දෙය වන්නේ තැටි මත පැටවීම නිරීක්ෂණය කිරීමයි, මන්ද. SSD / NVMe උපාංග පැමිණීමත් සමඟම, ගැටළුව අඩුවෙන් දැකිය හැකි වුවද, රික්තකය නොමිලේ නොවේ.
pg_stat_all_indexes යනු දර්ශක පිළිබඳ සංඛ්යාලේඛන වේ. ඇය විශාල නොවේ. ඒවගේම අපිට ඉන්ඩෙක්ස් භාවිතය ගැන තොරතුරු ලබාගන්න පුළුවන්. උදාහරණයක් ලෙස, අපට අතිරේකව ඇත්තේ කුමන දර්ශකද යන්න තීරණය කළ හැකිය.
මම දැනටමත් පවසා ඇති පරිදි, යාවත්කාලීන කිරීම වගු යාවත්කාලීන කිරීම පමණක් නොව, එය දර්ශක යාවත්කාලීන කිරීම ද වේ. ඒ අනුව, අපට මේසය මත බොහෝ දර්ශක තිබේ නම්, වගුවේ පේළි යාවත්කාලීන කිරීමේදී, සුචිගත ක්ෂේත්‍රවල දර්ශක ද යාවත්කාලීන කළ යුතුය, සහ අප සතුව දර්ශක ස්කෑන් නොමැති භාවිතයට නොගත් දර්ශක තිබේ නම්, ඒවා අප සමඟ බැලස්ට් ලෙස එල්ලා තිබේ. ඒ වගේම ඔබ ඔවුන්ගෙන් මිදෙන්න ඕන. මේ සඳහා අපට ක්ෂේත්රයක් අවශ්ය වේ idx_scan. අපි බලන්නේ දර්ශක ස්කෑන් ගණන පමණි. දර්ශකවල සංඛ්යාලේඛන ගබඩා කිරීමේ සාපේක්ෂව දිගු කාලයක් (අවම වශයෙන් සති 2-3 ක්) තුළ ශුන්‍ය ස්කෑන් තිබේ නම්, බොහෝ විට මේවා නරක දර්ශක වේ, අපි ඒවා ඉවත් කළ යුතුය.
සටහන: ප්‍රවාහ අනුරූකරණ පොකුරු සම්බන්ධයෙන් භාවිත නොකළ දර්ශක සොයන විට, ඔබ පොකුරේ සියලුම නෝඩ් පරීක්ෂා කළ යුතුය, මන්ද සංඛ්යාලේඛන ගෝලීය නොවන අතර, දර්ශකය මාස්ටර් මත භාවිතා නොකරන්නේ නම්, එය අනුපිටපත් මත භාවිතා කළ හැකිය (බරක් තිබේ නම්).
සබැඳි දෙකක්:
මේවා භාවිතයට නොගත් දර්ශක සොයා බලන ආකාරය සඳහා වඩාත් උසස් විමසුම් උදාහරණ වේ.
දෙවන සබැඳිය තරමක් සිත්ගන්නා විමසුමකි. ඉතා සුළු නොවන තර්කයක් එහි ඇත. මම එය සමාලෝචනය සඳහා නිර්දේශ කරමි.
දර්ශක මගින් සාරාංශ කළ යුතු තවත් මොනවාද?
-
භාවිතයට නොගත් දර්ශක නරක ය.
-
ඔවුන් අවකාශය ලබා ගනී.
-
යාවත්කාලීන මෙහෙයුම් මන්දගාමී කරන්න.
-
රික්තය සඳහා අමතර වැඩ.
අපි භාවිතා නොකරන ලද දර්ශක ඉවත් කළහොත්, අපි දත්ත සමුදාය වඩා හොඳ කරන්නෙමු.
ඊළඟ දර්ශනය වන්නේ pg_stat_activity. මෙය උපයෝගීතාවයේ ප්රතිසමයකි ps, PostgreSQL හි පමණි. නම් ps'ඔහ්, ඔබ මෙහෙයුම් පද්ධතියේ ක්‍රියාවලීන් නරඹන්න pg_stat_activity PostgreSQL තුළ ක්‍රියාකාරකම් ඔබට පෙන්වනු ඇත.
අපට එතැනින් ගත හැක්කේ කුමක්ද?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;දත්ත සමුදාය තුළ සිදුවන සමස්ත ක්‍රියාකාරකම් අපට දැක ගත හැකිය. අපිට අලුත් යෙදවීමක් කරන්න පුළුවන්. එහි සෑම දෙයක්ම පුපුරා ගියේය, නව සම්බන්ධතා පිළිගනු නොලැබේ, යෙදුමේ දෝෂ ගලා එයි.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;අපට මෙවැනි විමසුමක් ක්රියාත්මක කර උපරිම සම්බන්ධතා සීමාවට සාපේක්ෂව සම්බන්ධතා වල මුළු ප්රතිශතය දැක බලා අපට වැඩිපුරම සම්බන්ධතා ඇත්තේ කාටදැයි බලන්න. මෙම දී ඇති අවස්ථාවක, අපි එම පරිශීලකයා දකිමු cron_role සම්බන්ධතා 508 ක් විවෘත කරන ලදී. සහ ඔහුට යමක් සිදු විය. ඔබ එය සමඟ කටයුතු කර බැලිය යුතුය. තවද මෙය යම් ආකාරයක විෂමතා සම්බන්ධතා සංඛ්‍යාවක් විය හැකිය.
අපට OLTP පැටවීමක් තිබේ නම්, විමසුම් වේගවත්, ඉතා වේගවත් විය යුතු අතර දිගු විමසුම් නොතිබිය යුතුය. කෙසේ වෙතත්, දිගු ඉල්ලීම් තිබේ නම්, කෙටි කාලීනව කරදර වීමට කිසිවක් නැත, නමුත් දිගුකාලීනව, දිගු විමසුම් දත්ත සමුදායට හානි කරයි, වගු ඛණ්ඩනය වන විට ඒවා වගු වල bloat බලපෑම වැඩි කරයි. බඩ පිපීම සහ දිගු විමසුම් දෙකම බැහැර කළ යුතුය.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;කරුණාකර සටහන් කරන්න: එවැනි ඉල්ලීමක් සමඟ, අපට දිගු ඉල්ලීම් සහ ගනුදෙනු නිර්වචනය කළ හැකිය. අපි කාර්යය භාවිතා කරමු clock_timestamp() වැඩ කරන කාලය තීරණය කිරීමට. අපි සොයා ගත් දිගු ඉල්ලීම්, අපට ඒවා මතක තබා ගත හැකිය, ඒවා ක්රියාත්මක කරන්න explain, සැලසුම් දෙස බලා කෙසේ හෝ ප්‍රශස්ත කරන්න. අපි දැනට පවතින දිගු ඉල්ලීම් වෙඩි තබා ජීවත් වෙමු.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';අයහපත් ගනුදෙනු ගනුදෙනුවේදී නිෂ්ක්‍රීය වන අතර ගනුදෙනුවේදී නිෂ්ක්‍රීය (ගබ්සා කළ) ගනුදෙනු වේ.
එයින් අදහස් කරන්නේ කුමක් ද? ගනුදෙනුවලට රාජ්‍ය කිහිපයක් ඇත. තවද මෙම ප්රාන්තවලින් එකක් ඕනෑම අවස්ථාවක ගත හැක. රාජ්යයන් නිර්වචනය කිරීමට ක්ෂේත්රයක් තිබේ state මෙම දැක්ම තුළ. සහ අපි එය රාජ්යය තීරණය කිරීමට භාවිතා කරමු.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';තවද, මා ඉහත කී පරිදි, මෙම ප්රාන්ත දෙක ගනුදෙනුවේදී නිෂ්ක්‍රීය වීම සහ ගනුදෙනුවේ නිෂ්ක්‍රීය වීම (ගබ්සා කළ) අයහපත් වේ. එය කුමක්ද? යෙදුම ගනුදෙනුවක් විවෘත කර, යම් ක්‍රියා සිදු කර එහි ව්‍යාපාරය කරගෙන යන විට මෙයයි. ගනුදෙනුව විවෘතව පවතී. Postrges ගණුදෙණු එන්ජිමේ ගෘහ නිර්මාණ ශිල්පය හේතුවෙන් එය එල්ලී ඇත, එහි කිසිවක් සිදු නොවේ, එය සම්බන්ධතාවයක් ගනී, වෙනස් වූ පේළි මත අගුලු දැමීම සහ අනෙකුත් වගු වල ඉදිමීම පවා වැඩි කරයි. සහ එවැනි ගනුදෙනු ද වෙඩි තැබිය යුතුය, ඔවුන් සාමාන්යයෙන් හානිකර වන නිසා, ඕනෑම අවස්ථාවක.
ඔබේ දත්ත ගබඩාවේ ඒවායින් 5-10-20 කට වඩා ඇති බව ඔබ දුටුවහොත්, ඔබ කලබල වී ඔවුන් සමඟ යමක් කිරීමට පටන් ගත යුතුය.
මෙහිදී අපි ගණනය කිරීමේ කාලය සඳහා ද භාවිතා කරමු clock_timestamp(). අපි ගනුදෙනු වෙඩි තියන්නෙමු, අපි යෙදුම ප්‍රශස්ත කරන්නෙමු.
මම ඉහත කී පරිදි, අගුලු යනු එක් හෝ සම්පත් සමූහයක් සඳහා ගනුදෙනු දෙකක් හෝ වැඩි ගණනක් තරඟ කරන විටය. මේ සඳහා අපට ක්ෂේත්රයක් තිබේ waiting බූලියන් අගය සමඟ true හෝ false.
ඇත්ත - මෙයින් අදහස් කරන්නේ ක්‍රියාවලිය බලා සිටින බවයි, යමක් කළ යුතු බව. ක්‍රියාවලියක් බලා සිටින විට, ක්‍රියාවලිය ආරම්භ කළ සේවාදායකයා ද බලා සිටී. බ්‍රවුසරයේ සේවාදායකයා වාඩි වී බලා සිටී.
Внимание: _Postgres 9.6, ක්ෂේත්‍රයෙන් ආරම්භ වේ waiting ඉවත් කර තවත් තොරතුරු ක්ෂේත්‍ර දෙකක් මගින් ප්රතිස්ථාපනය කරන ලදී wait_event_type и wait_event._
මම කළ යුත්තේ කුමක්ද? ඔබ දිගු කලක් සත්‍ය දකින්නේ නම්, ඔබ එවැනි ඉල්ලීම් වලින් මිදිය යුතුය. අපි එවැනි ගනුදෙනු පමණක් වෙඩි තියන්නෙමු. සම්පත් සඳහා තරඟයක් ඇති නොවන පරිදි කෙසේ හෝ ප්‍රශස්ත කළ යුතු දේ අපි සංවර්ධකයින්ට ලියන්නෙමු. මෙය සිදු නොවන පරිදි සංවර්ධකයින් යෙදුම ප්‍රශස්ත කරයි.
සහ අන්ත, නමුත් ඒ සමඟම මාරාන්තික නොවේ අවහිරතා ඇතිවීම. ගණුදෙණු දෙකක් සම්පත් දෙකක් යාවත්කාලීන කර ඇත, පසුව ඔවුන් නැවත ඒවාට ප්‍රවේශ වේ, දැනටමත් ප්‍රතිවිරුද්ධ සම්පත් වෙත. මෙම නඩුවේ PostgreSQL අනෙක් තැනැත්තාට දිගටම වැඩ කිරීමට හැකි වන පරිදි ගනුදෙනුව ඉවත් කර ඉවත් කරයි. මෙය මාරාන්තික තත්වයක් වන අතර ඇය තමාව තේරුම් නොගනී. එබැවින්, PostgreSQL ආන්තික පියවර ගැනීමට බල කෙරෙයි.
තවද මෙහි ඔබට අගුලු නිරීක්ෂණය කිරීමට ඉඩ සලසන විමසුම් දෙකක් ඇත. අපි දර්ශනය භාවිතා කරමු pg_locks, බර අගුලු නිරීක්ෂණය කිරීමට ඔබට ඉඩ සලසයි.
සහ පළමු සබැඳිය ඉල්ලීම් පෙළ ම වේ. ඒක සෑහෙන්න දිගයි.
දෙවන සබැඳිය අගුලු පිළිබඳ ලිපියකි. එය කියවීමට ප්රයෝජනවත් වේ, එය ඉතා රසවත් ය.
ඉතින් අපි දකින්නේ කුමක්ද? අපි ඉල්ලීම් දෙකක් දකිනවා. සමඟ ගනුදෙනු කිරීම ALTER TABLE අවහිර කරන ගනුදෙනුවකි. ඒක පටන් ගත්ත, ඒත් ඉවර වුනේ නෑ, මේ ගණුදෙනුව දාපු ඇප්ලිකේෂන් එක කොහේ හරි වෙන දේවල් කරනවා. දෙවන ඉල්ලීම යාවත්කාලීන කිරීමයි. එහි වැඩ කරගෙන යාමට පෙර එය වෙනස් කිරීමේ වගුව අවසන් වන තෙක් බලා සිටී.
කවුද අගුලු දමා ඇත්තේ කවුද, කවුරුන් අල්ලාගෙන සිටින්නේද යන්න අපට සොයාගත හැක්කේ එලෙසිනි, අපට මෙය තවදුරටත් සමඟ කටයුතු කළ හැකිය.
ඊළඟ මොඩියුලය වේ pg_stat_statements. මම කිව්වා වගේ, ඒක මොඩියුලයක්. එය භාවිතා කිරීම සඳහා, ඔබට එහි පුස්තකාලය වින්‍යාසය තුළ පැටවිය යුතුය, PostgreSQL නැවත ආරම්භ කරන්න, මොඩියුලය ස්ථාපනය කරන්න (එක් විධානයක් සමඟ), එවිට අපට නව දර්ශනයක් ලැබෙනු ඇත.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;අපට එතැනින් ගත හැක්කේ කුමක්ද? අපි සරල දේවල් ගැන කතා කරන්නේ නම්, අපට සාමාන්‍ය විමසුම් ක්රියාත්මක කිරීමේ කාලය ගත හැකිය. කාලය වර්ධනය වෙමින් පවතී, එයින් අදහස් වන්නේ PostgreSQL සෙමින් ප්රතිචාර දක්වන අතර යමක් කළ යුතු බවයි.
බෙදාගත් බෆරවල දත්ත වෙනස් කරන දත්ත ගබඩාවේ වඩාත්ම ක්‍රියාකාරී ලිවීමේ ගනුදෙනු අපට දැක ගත හැකිය. එහි දත්ත යාවත්කාලීන කරන්නේ හෝ මකා දමන්නේ කවුදැයි බලන්න.
තවද අපට මෙම ඉල්ලීම් සඳහා විවිධ සංඛ්යාලේඛන දෙස බැලිය හැකිය.
අපි pg_stat_statements වාර්තා ගොඩනැගීමට භාවිතා කරයි. අපි දිනකට වරක් සංඛ්යා ලේඛන නැවත සකස් කරමු. අපි එය රැස් කරමු. ඊළඟ වතාවේ සංඛ්යා ලේඛන නැවත සැකසීමට පෙර, අපි වාර්තාවක් ගොඩනඟමු. මෙන්න වාර්තාවට සබැඳියක්. ඔබට එය නැරඹිය හැකිය.
අපි මොනවද කරන්නේ? අපි සියලු විමසුම් සඳහා සමස්ත සංඛ්යා ලේඛන ගණනය කරමු. ඉන්පසුව, එක් එක් විමසුම සඳහා, අපි මෙම සමස්ත සංඛ්‍යාලේඛනයට එහි තනි දායකත්වය ගණනය කරමු.
සහ අපට දැකිය හැක්කේ කුමක්ද? අනෙකුත් සියලුම ඉල්ලීම්වල පසුබිමට එරෙහිව යම් වර්ගයක සියලුම ඉල්ලීම් සම්පූර්ණ ක්රියාත්මක කිරීමේ කාලය අපට දැකිය හැකිය. සමස්ත පින්තූරයට අදාළව අපට CPU සහ I/O භාවිතය දෙස බැලිය හැක. සහ දැනටමත් මෙම ඉල්ලීම් ප්‍රශස්ත කිරීමට. අපි මෙම වාර්තාව මත පදනම්ව ඉහළ විමසුම් ගොඩනඟමින් සිටින අතර ප්‍රශස්ත කළ යුතු දේ පිළිබඳ සිතීමට දැනටමත් ආහාර ලබා ගනිමින් සිටිමු.
තිරය පිටුපස අපට ඇත්තේ කුමක්ද? කාලය සීමිත බැවින් මා සලකා නොබැලූ ඉදිරිපත් කිරීම් කිහිපයක් තවමත් තිබේ.
ඇත pgstattuple සම්මත දායක පැකේජයෙන් අමතර මොඩියුලයක් ද වේ. එය ඔබට ඇගයීමට ඉඩ සලසයි bloat වගු, ඊනියා. මේස ඛණ්ඩනය. ඛණ්ඩනය විශාල නම්, ඔබ එය ඉවත් කළ යුතුය, විවිධ මෙවලම් භාවිතා කරන්න. සහ කාර්යය pgstattuple දිගු කාලයක් වැඩ කරයි. තවද වගු වැඩි වන තරමට එය වැඩ කරනු ඇත.
ඊළඟ දායකත්වය වන්නේ pg_buffercache. බෙදාගත් බෆර පරීක්ෂා කිරීමට එය ඔබට ඉඩ සලසයි: බෆර පිටු කෙතරම් තීව්‍ර ලෙස සහ කුමන වගු සඳහා භාවිතා කරන්නේද යන්න. එය ඔබට හවුල් බෆර දෙස බැලීමට සහ එහි සිදුවන්නේ කුමක්ද යන්න ඇගයීමට ඉඩ සලසයි.
ඊළඟ මොඩියුලය වේ pgfincore. පද්ධති ඇමතුමක් හරහා පහත් මට්ටමේ වගු මෙහෙයුම් සිදු කිරීමට එය ඔබට ඉඩ සලසයි mincore(), එනම් එය ඔබට වගුව බෙදාගත් බෆරවලට පැටවීමට හෝ එය බාගැනීමට ඉඩ සලසයි. වෙනත් දේ අතර, මෙහෙයුම් පද්ධතියේ පිටු හැඹිලිය පරීක්ෂා කිරීමට එය ඉඩ දෙයි, එනම්, පිටු හැඹිලියේ, හවුල් බෆරවල වගුව කොපමණ ප්‍රමාණයක් අල්ලාගෙන සිටීද යන්න සහ මේසය මත ඇති බර තක්සේරු කිරීමට ඔබට ඉඩ සලසයි.
ඊළඟ මොඩියුලය වේ pg_stat_kcache. එය පද්ධති ඇමතුම ද භාවිතා කරයි getrusage(). තවද එය ඉල්ලීම ක්රියාත්මක කිරීමට පෙර සහ පසුව එය ක්රියාත්මක කරයි. ලබාගත් සංඛ්‍යාලේඛනවල, අපගේ ඉල්ලීම තැටිය I / O සඳහා කොපමණ මුදලක් වැය වේද යන්න තක්සේරු කිරීමට එය අපට ඉඩ සලසයි, එනම්, ගොනු පද්ධතිය සමඟ මෙහෙයුම් සහ ප්‍රොසෙසර භාවිතය දෙස බලයි. කෙසේ වෙතත්, මොඩියුලය තරුණ (khe-khe) වන අතර එහි කාර්යය සඳහා මා කලින් සඳහන් කළ PostgreSQL 9.4 සහ pg_stat_statements අවශ්ය වේ.
-
සංඛ්යා ලේඛන භාවිතා කිරීමේ හැකියාව ප්රයෝජනවත් වේ. ඔබට තෙවන පාර්ශවීය මෘදුකාංග අවශ්ය නොවේ. ඔබට බලන්න, බලන්න, යමක් කරන්න, ඉටු කරන්න පුළුවන්.
-
සංඛ්යා ලේඛන භාවිතා කිරීම පහසුය, එය සරල SQL වේ. ඔබ ඉල්ලීමක් එකතු කළා, එය සම්පාදනය කළා, යැව්වා, බැලුවා.
-
සංඛ්යාලේඛන ප්‍රශ්නවලට පිළිතුරු දීමට උපකාරී වේ. ඔබට ප්රශ්න තිබේ නම්, ඔබ සංඛ්යා ලේඛන වෙත හැරෙන්න - බලන්න, නිගමන උකහා ගන්න, ප්රතිඵල විශ්ලේෂණය කරන්න.
-
සහ අත්හදා බැලීම. ඉල්ලීම් ගොඩක්, දත්ත ගොඩක්. ඔබට සැමවිටම පවතින විමසුම් කිහිපයක් ප්‍රශස්ත කළ හැක. ඔබට මුල් පිටපතට වඩා ඔබට ගැලපෙන ඉල්ලීමේ ඔබේම අනුවාදයක් සාදා එය භාවිතා කළ හැකිය.
යොමු
ලිපියේ සොයාගත් වලංගු සබැඳි, ඒ මත පදනම්ව, වාර්තාවේ තිබුණි.
කතුවරයා තවත් ලියන්න
(ඉංජිනේරු)
සංඛ්යා ලේඛන එකතු කරන්නා
පද්ධති පරිපාලන කාර්යයන්
දායක මොඩියුල
SQL උපයෝගිතා සහ sql කේත උදාහරණ
ඔබගේ අවධානයට ඔබ සැමට ස්තූතියි!
මූලාශ්රය: www.habr.com