PostgreSQL ആന്തരിക സ്ഥിതിവിവരക്കണക്കുകളിലേക്ക് ആഴത്തിൽ മുങ്ങുക. അലക്സി ലെസോവ്സ്കി

അലക്സി ലെസോവ്സ്കിയുടെ 2015 ലെ റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് "PostgreSQL ആന്തരിക സ്ഥിതിവിവരക്കണക്കുകളിലേക്ക് ആഴത്തിൽ മുങ്ങുക"

റിപ്പോർട്ടിന്റെ രചയിതാവിൽ നിന്നുള്ള നിരാകരണം: ഈ റിപ്പോർട്ട് നവംബർ 2015-ലാണെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു - 4 വർഷത്തിലേറെ കടന്നുപോയി, ഒരുപാട് സമയം കടന്നുപോയി. റിപ്പോർട്ടിൽ ചർച്ച ചെയ്ത പതിപ്പ് 9.4 ഇപ്പോൾ പിന്തുണയ്ക്കില്ല. കഴിഞ്ഞ 4 വർഷത്തിനിടയിൽ, 5 പുതിയ റിലീസുകൾ പുറത്തിറങ്ങി, അതിൽ സ്ഥിതിവിവരക്കണക്കുകൾ സംബന്ധിച്ച് ധാരാളം പുതുമകളും മെച്ചപ്പെടുത്തലുകളും മാറ്റങ്ങളും ഉണ്ട്, കൂടാതെ ചില മെറ്റീരിയലുകൾ കാലഹരണപ്പെട്ടതും പ്രസക്തമല്ലാത്തതുമാണ്. ഞാൻ അവലോകനം ചെയ്യുമ്പോൾ, വായനക്കാരനെ തെറ്റിദ്ധരിപ്പിക്കാതിരിക്കാൻ ഈ സ്ഥലങ്ങൾ അടയാളപ്പെടുത്താൻ ഞാൻ ശ്രമിച്ചു. ഞാൻ ഈ ഭാഗങ്ങൾ മാറ്റിയെഴുതിയിട്ടില്ല, അവയിൽ ധാരാളം ഉണ്ട്, ഫലം തികച്ചും വ്യത്യസ്തമായ ഒരു റിപ്പോർട്ടായിരിക്കും.

PostgreSQL DBMS ഒരു വലിയ സംവിധാനമാണ്, ഈ മെക്കാനിസത്തിൽ നിരവധി ഉപസിസ്റ്റങ്ങൾ അടങ്ങിയിരിക്കുന്നു, ഇതിന്റെ ഏകോപിത പ്രവർത്തനം DBMS-ന്റെ പ്രവർത്തനത്തെ നേരിട്ട് ബാധിക്കുന്നു. പ്രവർത്തന സമയത്ത്, ഘടകങ്ങളുടെ പ്രവർത്തനത്തെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകളും വിവരങ്ങളും ശേഖരിക്കുന്നു, ഇത് PostgreSQL ന്റെ ഫലപ്രാപ്തി വിലയിരുത്താനും പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനുള്ള നടപടികൾ കൈക്കൊള്ളാനും നിങ്ങളെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, ഈ വിവരങ്ങളിൽ ധാരാളം ഉണ്ട്, അത് വളരെ ലളിതമായ രൂപത്തിൽ അവതരിപ്പിച്ചിരിക്കുന്നു. ഈ വിവരങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതും വ്യാഖ്യാനിക്കുന്നതും ചിലപ്പോൾ തികച്ചും നിസ്സാരമല്ലാത്ത ഒരു ജോലിയാണ്, കൂടാതെ ടൂളുകളുടെയും യൂട്ടിലിറ്റികളുടെയും "മൃഗശാല" ഒരു വിപുലമായ DBA-യെപ്പോലും എളുപ്പത്തിൽ ആശയക്കുഴപ്പത്തിലാക്കും.

ഗുഡ് ആഫ്റ്റർനൂൺ എന്റെ പേര് അലക്സി. ഇല്യ പറഞ്ഞതുപോലെ, ഞാൻ PostgreSQL സ്ഥിതിവിവരക്കണക്കുകളെ കുറിച്ച് സംസാരിക്കും.

PostgreSQL പ്രവർത്തന സ്ഥിതിവിവരക്കണക്കുകൾ. PostgreSQL-ന് രണ്ട് സ്ഥിതിവിവരക്കണക്കുകൾ ഉണ്ട്. ചർച്ച ചെയ്യപ്പെടുന്ന പ്രവർത്തന സ്ഥിതിവിവരക്കണക്കുകൾ. ഡാറ്റ വിതരണത്തെക്കുറിച്ചുള്ള ഷെഡ്യൂളർ സ്ഥിതിവിവരക്കണക്കുകളും. പ്രകടനം വിലയിരുത്താനും എങ്ങനെയെങ്കിലും അത് മെച്ചപ്പെടുത്താനും ഞങ്ങളെ അനുവദിക്കുന്ന PostgreSQL പ്രവർത്തന സ്ഥിതിവിവരക്കണക്കുകളെ കുറിച്ച് ഞാൻ പ്രത്യേകം സംസാരിക്കും.

നിങ്ങൾക്ക് ഉള്ളതോ ഉണ്ടായേക്കാവുന്നതോ ആയ വിവിധ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് സ്ഥിതിവിവരക്കണക്കുകൾ എങ്ങനെ ഫലപ്രദമായി ഉപയോഗിക്കാമെന്ന് ഞാൻ നിങ്ങളോട് പറയും.

റിപ്പോർട്ടിൽ എന്തുണ്ടാകില്ല? റിപ്പോർട്ടിൽ ഞാൻ ഷെഡ്യൂളർ സ്ഥിതിവിവരക്കണക്കുകളിൽ സ്പർശിക്കില്ല, കാരണം... ഡാറ്റാബേസിൽ ഡാറ്റ എങ്ങനെ സംഭരിക്കുന്നുവെന്നും ഈ ഡാറ്റയുടെ ഗുണപരവും അളവ്പരവുമായ സവിശേഷതകളെ കുറിച്ച് അന്വേഷണ പ്ലാനർക്ക് എങ്ങനെ ഒരു ആശയം ലഭിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു പ്രത്യേക റിപ്പോർട്ടിന് ഇത് ഒരു പ്രത്യേക വിഷയമാണ്.

ഉപകരണ അവലോകനങ്ങളൊന്നും ഉണ്ടാകില്ല, ഞാൻ ഒരു ഉൽപ്പന്നത്തെ മറ്റൊന്നുമായി താരതമ്യം ചെയ്യില്ല. പരസ്യം ഉണ്ടാകില്ല. അത് മാറ്റിവെക്കാം.

സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിക്കുന്നത് ഉപയോഗപ്രദമാണെന്ന് നിങ്ങളെ കാണിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഇത് അത്യാവശ്യമാണ്. ഇത് ഉപയോഗിക്കുന്നത് സുരക്ഷിതമാണ്. ഞങ്ങൾക്ക് വേണ്ടത് സാധാരണ SQL ഉം SQL-നെ കുറിച്ചുള്ള അടിസ്ഥാന അറിവും മാത്രമാണ്.

പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിന് എന്ത് സ്ഥിതിവിവരക്കണക്കുകളാണ് തിരഞ്ഞെടുക്കേണ്ടതെന്ന് നമുക്ക് സംസാരിക്കാം.

നമ്മൾ PostgreSQL നോക്കുകയും പ്രോസസ്സുകൾ കാണുന്നതിന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയും ചെയ്താൽ, നമുക്ക് ഒരു "ബ്ലാക്ക് ബോക്സ്" കാണാം. എന്തെങ്കിലും ചെയ്യുന്ന ചില പ്രക്രിയകൾ ഞങ്ങൾ കാണും, അവർ അവിടെ എന്താണ് ചെയ്യുന്നതെന്നും അവർ എന്താണ് ചെയ്യുന്നതെന്നും പേരിൽ നിന്ന് നമുക്ക് ഏകദേശം സങ്കൽപ്പിക്കാൻ കഴിയും. പക്ഷേ, സാരാംശത്തിൽ, ഇതൊരു ബ്ലാക്ക് ബോക്സാണ്; നമുക്ക് അകത്തേക്ക് നോക്കാൻ കഴിയില്ല.

സിപിയു ലോഡ് ഇൻ ചെയ്യുന്നത് നമുക്ക് കാണാം top, ചില സിസ്റ്റം യൂട്ടിലിറ്റികൾ മുഖേന മെമ്മറി ഉപയോഗം നോക്കാം, എന്നാൽ PostgreSQL-നുള്ളിൽ നോക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല. ഇതിനായി ഞങ്ങൾക്ക് മറ്റ് ഉപകരണങ്ങൾ ആവശ്യമാണ്.

കൂടുതൽ തുടരുമ്പോൾ, സമയം എവിടെയാണ് ചെലവഴിച്ചതെന്ന് ഞാൻ നിങ്ങളോട് പറയും. പോസ്റ്റ്‌ഗ്രെഎസ്‌ക്യുഎൽ അത്തരമൊരു ഡയഗ്രാമിന്റെ രൂപത്തിൽ സങ്കൽപ്പിക്കുകയാണെങ്കിൽ, സമയം എവിടെയാണ് ചെലവഴിച്ചതെന്ന് നമുക്ക് ഉത്തരം നൽകാം. ഇവ രണ്ട് കാര്യങ്ങളാണ്: ഇത് ആപ്ലിക്കേഷനുകളിൽ നിന്നുള്ള ക്ലയന്റ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നു, സ്വയം പ്രവർത്തിക്കാൻ PostgreSQL ചെയ്യുന്ന പശ്ചാത്തല ജോലികൾ.

മുകളിൽ ഇടത് കോണിൽ നിന്ന് നോക്കാൻ തുടങ്ങിയാൽ, ക്ലയന്റ് അഭ്യർത്ഥനകൾ എങ്ങനെ പ്രോസസ്സ് ചെയ്യപ്പെടുന്നുവെന്ന് നമുക്ക് കാണാൻ കഴിയും. അപേക്ഷയിൽ നിന്നാണ് അഭ്യർത്ഥന വരുന്നത്, തുടർന്നുള്ള ജോലികൾക്കായി ഒരു ക്ലയന്റ് സെഷൻ തുറക്കുന്നു. അഭ്യർത്ഥന ഷെഡ്യൂളർക്ക് അയച്ചു. ഷെഡ്യൂളർ ഒരു അന്വേഷണ പ്ലാൻ നിർമ്മിക്കുന്നു. നിർവ്വഹണത്തിനായി ഇത് കൂടുതൽ അയയ്ക്കുന്നു. പട്ടികകളുമായും സൂചികകളുമായും ബന്ധപ്പെട്ട ചില തരത്തിലുള്ള ബ്ലോക്ക് ഡാറ്റ ഇൻപുട്ട്/ഔട്ട്പുട്ട് ഉണ്ട്. ആവശ്യമായ ഡാറ്റ ഡിസ്കുകളിൽ നിന്ന് മെമ്മറിയിലേക്ക് "പങ്കിട്ട ബഫറുകൾ" എന്ന പ്രത്യേക ഏരിയയിലേക്ക് റീഡ് ചെയ്യുന്നു. അഭ്യർത്ഥനയുടെ ഫലങ്ങൾ, അവ അപ്‌ഡേറ്റുകളും ഇല്ലാതാക്കലുകളുമാണെങ്കിൽ, WAL-ലെ ഇടപാട് ലോഗിൽ രേഖപ്പെടുത്തുന്നു. ചില സ്റ്റാറ്റിസ്റ്റിക്കൽ വിവരങ്ങൾ ലോഗ് അല്ലെങ്കിൽ സ്റ്റാറ്റിസ്റ്റിക്സ് കളക്ടറിൽ അവസാനിക്കുന്നു. അഭ്യർത്ഥനയുടെ ഫലം ക്ലയന്റിലേക്ക് തിരികെ അയയ്ക്കുന്നു. അതിനുശേഷം ക്ലയന്റിന് ഒരു പുതിയ അഭ്യർത്ഥനയോടെ എല്ലാം ആവർത്തിക്കാനാകും.

ബാക്ക്ഗ്രൗണ്ട് ടാസ്ക്കുകളും പശ്ചാത്തല പ്രക്രിയകളും സംബന്ധിച്ചെന്ത്? ഡാറ്റാബേസ് സാധാരണ ഓപ്പറേറ്റിംഗ് മോഡിൽ പ്രവർത്തിപ്പിക്കുന്ന നിരവധി പ്രക്രിയകൾ ഞങ്ങൾക്കുണ്ട്. ഈ പ്രക്രിയകളും റിപ്പോർട്ടിൽ സ്പർശിക്കും: ഓട്ടോവാക്വം, ചെക്ക്പോയിന്റർ, റെപ്ലിക്കേഷനുമായി ബന്ധപ്പെട്ട പ്രക്രിയകൾ, പശ്ചാത്തല എഴുത്തുകാരൻ. ഞാൻ റിപ്പോർട്ടുചെയ്യുമ്പോൾ അവ ഓരോന്നും ഞാൻ സ്പർശിക്കും.

സ്ഥിതിവിവരക്കണക്കുകളിൽ എന്തൊക്കെ പ്രശ്നങ്ങൾ ഉണ്ട്?

• ധാരാളം വിവരങ്ങൾ ഉണ്ട്. സ്റ്റാറ്റിസ്റ്റിക്സ് ഡാറ്റ കാണുന്നതിന് PostgreSQL 9.4 109 മെട്രിക്സ് നൽകുന്നു. എന്നിരുന്നാലും, ഡാറ്റാബേസ് നിരവധി പട്ടികകൾ, സ്കീമകൾ, ഡാറ്റാബേസുകൾ എന്നിവ സംഭരിക്കുന്നുവെങ്കിൽ, ഈ അളവുകളെല്ലാം അനുബന്ധ പട്ടികകൾ, ഡാറ്റാബേസുകൾ എന്നിവയാൽ ഗുണിക്കേണ്ടതുണ്ട്. അതായത്, അതിലും കൂടുതൽ വിവരങ്ങൾ ഉണ്ട്. കൂടാതെ അതിൽ മുങ്ങാൻ വളരെ എളുപ്പമാണ്.
• അടുത്ത പ്രശ്നം സ്ഥിതിവിവരക്കണക്കുകൾ കൗണ്ടറുകൾ പ്രതിനിധീകരിക്കുന്നു എന്നതാണ്. ഈ സ്ഥിതിവിവരക്കണക്കുകൾ പരിശോധിച്ചാൽ, നിരന്തരം വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്ന കൗണ്ടറുകൾ നമുക്ക് കാണാം. സ്ഥിതിവിവരക്കണക്കുകൾ പുനഃസജ്ജമാക്കിയതിന് ശേഷം ഒരുപാട് സമയം കടന്നുപോയാൽ, നമുക്ക് കോടിക്കണക്കിന് മൂല്യങ്ങൾ കാണാനാകും. പിന്നെ അവർ ഞങ്ങളോട് ഒന്നും പറയുന്നില്ല.
• കഥയില്ല. നിങ്ങൾക്ക് 15-30 മിനിറ്റ് മുമ്പ് എന്തെങ്കിലും പരാജയം സംഭവിച്ചിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിക്കാനും 15-30 മിനിറ്റ് മുമ്പ് എന്താണ് സംഭവിച്ചതെന്ന് കാണാനും കഴിയില്ല. ഇത് പ്രശ്നമാണ്.
• PostgreSQL-ൽ നിർമ്മിച്ച ഒരു ഉപകരണത്തിന്റെ അഭാവം ഒരു പ്രശ്നമാണ്. കേർണൽ ഡെവലപ്പർമാർ ഒരു യൂട്ടിലിറ്റിയും നൽകുന്നില്ല. അവർക്ക് അങ്ങനെയൊന്നും ഇല്ല. അവർ ഡാറ്റാബേസിൽ സ്ഥിതിവിവരക്കണക്കുകൾ നൽകുന്നു. ഇത് ഉപയോഗിക്കുക, അതിനോട് ഒരു അഭ്യർത്ഥന നടത്തുക, നിങ്ങൾ ആഗ്രഹിക്കുന്നതെന്തും ചെയ്യുക.
• PostgreSQL-ൽ ഒരു ടൂളും നിർമ്മിച്ചിട്ടില്ലാത്തതിനാൽ, ഇത് മറ്റൊരു പ്രശ്നം ഉണ്ടാക്കുന്നു. ധാരാളം മൂന്നാം കക്ഷി ഉപകരണങ്ങൾ. കൂടുതലോ കുറവോ നേരിട്ടുള്ള കൈകളുള്ള എല്ലാ കമ്പനികളും സ്വന്തം പ്രോഗ്രാം എഴുതാൻ ശ്രമിക്കുന്നു. തൽഫലമായി, സ്ഥിതിവിവരക്കണക്കുകൾക്കൊപ്പം പ്രവർത്തിക്കാൻ ഉപയോഗിക്കാവുന്ന ധാരാളം ഉപകരണങ്ങൾ കമ്മ്യൂണിറ്റിയിലുണ്ട്. കൂടാതെ ചില ഉപകരണങ്ങൾക്ക് ചില കഴിവുകൾ ഉണ്ട്, മറ്റ് ഉപകരണങ്ങൾക്ക് മറ്റ് കഴിവുകൾ ഇല്ല, അല്ലെങ്കിൽ ചില പുതിയ കഴിവുകൾ ഉണ്ട്. പരസ്പരം ഓവർലാപ്പ് ചെയ്യുന്നതും വ്യത്യസ്തമായ പ്രവർത്തനങ്ങളുള്ളതുമായ രണ്ടോ മൂന്നോ നാലോ ഉപകരണങ്ങൾ നിങ്ങൾ ഉപയോഗിക്കേണ്ട സാഹചര്യം ഉണ്ടാകുന്നു. ഇത് വളരെ അരോചകമാണ്.

ഇതിൽ നിന്ന് എന്താണ് പിന്തുടരുന്നത്? പ്രോഗ്രാമുകളെ ആശ്രയിക്കാതിരിക്കാൻ സ്ഥിതിവിവരക്കണക്കുകൾ നേരിട്ട് എടുക്കുന്നത് പ്രധാനമാണ്, അല്ലെങ്കിൽ എങ്ങനെയെങ്കിലും ഈ പ്രോഗ്രാമുകൾ സ്വയം മെച്ചപ്പെടുത്തുക: നിങ്ങളുടെ സ്വന്തം നേട്ടം ലഭിക്കുന്നതിന് ചില പ്രവർത്തനങ്ങൾ ചേർക്കുക.

നിങ്ങൾക്ക് SQL-നെ കുറിച്ചുള്ള അടിസ്ഥാന അറിവ് ആവശ്യമാണ്. സ്ഥിതിവിവരക്കണക്കുകളിൽ നിന്ന് കുറച്ച് ഡാറ്റ ലഭിക്കുന്നതിന്, നിങ്ങൾ SQL അന്വേഷണങ്ങൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്, അതായത് തിരഞ്ഞെടുത്തതും ചേരുന്നതും എങ്ങനെ സമാഹരിച്ചിരിക്കുന്നുവെന്ന് നിങ്ങൾ അറിയേണ്ടതുണ്ട്.

സ്ഥിതിവിവരക്കണക്കുകൾ നമ്മോട് നിരവധി കാര്യങ്ങൾ പറയുന്നു. അവയെ വിഭാഗങ്ങളായി തിരിക്കാം.

• ഡാറ്റാബേസിൽ സംഭവിക്കുന്ന സംഭവങ്ങളാണ് ആദ്യ വിഭാഗം. ഡാറ്റാബേസിൽ ചില ഇവന്റുകൾ സംഭവിക്കുമ്പോൾ ഇതാണ്: ഒരു അഭ്യർത്ഥന, ഒരു ടേബിളിലേക്കുള്ള ആക്സസ്, ഓട്ടോവാക്വം, കമ്മിറ്റ്സ്, പിന്നെ ഇവയെല്ലാം ഇവന്റുകളാണ്. ഈ സംഭവങ്ങളുമായി ബന്ധപ്പെട്ട കൗണ്ടറുകൾ വർദ്ധിപ്പിക്കും. ഈ ഇവന്റുകൾ നമുക്ക് ട്രാക്ക് ചെയ്യാം.
• പട്ടികകൾ, ഡാറ്റാബേസുകൾ തുടങ്ങിയ ഒബ്ജക്റ്റുകളുടെ ഗുണങ്ങളാണ് രണ്ടാമത്തെ വിഭാഗം. അവർക്ക് സ്വത്തുക്കളുണ്ട്. ഇതാണ് മേശകളുടെ വലിപ്പം. പട്ടികകളുടെ വളർച്ചയും സൂചികകളുടെ വളർച്ചയും നമുക്ക് ട്രാക്ക് ചെയ്യാം. ചലനാത്മകതയിൽ മാറ്റങ്ങൾ നമുക്ക് കാണാൻ കഴിയും.
• മൂന്നാമത്തെ വിഭാഗം ഇവന്റിനായി ചെലവഴിച്ച സമയമാണ്. അഭ്യർത്ഥന ഒരു സംഭവമാണ്. അതിന് അതിന്റേതായ നിശ്ചിത ദൈർഘ്യം ഉണ്ട്. ഇവിടെ തുടങ്ങി, ഇവിടെ അവസാനിച്ചു. നമുക്കത് ട്രാക്ക് ചെയ്യാം. ഒന്നുകിൽ ഡിസ്കിൽ നിന്ന് ഒരു ബ്ലോക്ക് വായിക്കാനോ എഴുതാനോ എടുക്കുന്ന സമയം. ഇത്തരം കാര്യങ്ങളും നിരീക്ഷിക്കുന്നുണ്ട്.

സ്ഥിതിവിവരക്കണക്കുകളുടെ ഉറവിടങ്ങൾ ഇനിപ്പറയുന്ന രീതിയിൽ അവതരിപ്പിച്ചിരിക്കുന്നു:

• പങ്കിട്ട മെമ്മറിയിൽ (പങ്കിട്ട ബഫറുകൾ) സ്റ്റാറ്റിക് ഡാറ്റ സംഭരിക്കുന്നതിന് ഒരു സെഗ്‌മെന്റ് ഉണ്ട്, ചില ഇവന്റുകൾ സംഭവിക്കുമ്പോൾ അല്ലെങ്കിൽ ഡാറ്റാബേസിന്റെ പ്രവർത്തനത്തിൽ ചില നിമിഷങ്ങൾ ഉണ്ടാകുമ്പോൾ നിരന്തരം വർദ്ധിക്കുന്ന കൗണ്ടറുകളും ഉണ്ട്.
• ഈ കൗണ്ടറുകളെല്ലാം ഉപയോക്താവിന് ആക്‌സസ് ചെയ്യാനാകുന്നില്ല, കൂടാതെ അഡ്മിനിസ്ട്രേറ്റർക്ക് പോലും ആക്‌സസ് ചെയ്യാനാകുന്നില്ല. ഇതൊക്കെ താഴ്ന്ന നിലവാരത്തിലുള്ള കാര്യങ്ങളാണ്. അവ ആക്സസ് ചെയ്യുന്നതിന്, PostgreSQL SQL ഫംഗ്ഷനുകളുടെ രൂപത്തിൽ ഒരു ഇന്റർഫേസ് നൽകുന്നു. ഈ ഫംഗ്‌ഷനുകൾ ഉപയോഗിച്ച് നമുക്ക് തിരഞ്ഞെടുത്ത ത്രോകൾ നടത്താനും ഏതെങ്കിലും തരത്തിലുള്ള മെട്രിക് (അല്ലെങ്കിൽ മെട്രിക്‌സിന്റെ സെറ്റ്) നേടാനും കഴിയും.
• എന്നിരുന്നാലും, ഈ ഫംഗ്‌ഷനുകൾ ഉപയോഗിക്കുന്നത് എല്ലായ്പ്പോഴും സൗകര്യപ്രദമല്ല, അതിനാൽ ഫംഗ്‌ഷനുകൾ കാഴ്‌ചകളുടെ അടിസ്ഥാനമാണ് (കാഴ്‌ചകൾ). ഒരു നിർദ്ദിഷ്‌ട സബ്‌സിസ്റ്റത്തിലോ ഡാറ്റാബേസിലെ ഒരു നിശ്ചിത ഇവന്റുകളിലോ സ്ഥിതിവിവരക്കണക്കുകൾ നൽകുന്ന വെർച്വൽ പട്ടികകളാണിവ.
• ഈ ഉൾച്ചേർത്ത കാഴ്‌ചകൾ (VIEWs) സ്ഥിതിവിവരക്കണക്കുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള പ്രാഥമിക ഉപയോക്തൃ ഇന്റർഫേസാണ്. അധിക ക്രമീകരണങ്ങളൊന്നുമില്ലാതെ അവ സ്ഥിരസ്ഥിതിയായി ലഭ്യമാണ്, നിങ്ങൾക്ക് അവ ഉടനടി ഉപയോഗിക്കാനും അവ നോക്കാനും അവയിൽ നിന്ന് വിവരങ്ങൾ എടുക്കാനും കഴിയും. പിന്നെ സംഭാവനകളുണ്ട്. സംഭാവനകൾ ഔദ്യോഗികമാണ്. നിങ്ങൾക്ക് postgresql-contrib പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യാം (ഉദാഹരണത്തിന്, postgresql94-contrib), കോൺഫിഗറേഷനിൽ ആവശ്യമായ മൊഡ്യൂൾ ലോഡ് ചെയ്യുക, അതിനുള്ള പാരാമീറ്ററുകൾ വ്യക്തമാക്കുക, PostgreSQL പുനരാരംഭിക്കുക, നിങ്ങൾക്ക് അത് ഉപയോഗിക്കാം. (കുറിപ്പ്. വിതരണത്തെ ആശ്രയിച്ച്, സമീപകാല പതിപ്പുകളിൽ പ്രധാന പാക്കേജിന്റെ ഭാഗമാണ് സംഭാവന പാക്കേജ്).
• കൂടാതെ അനൗദ്യോഗിക സംഭാവനകളും ഉണ്ട്. അവ സ്റ്റാൻഡേർഡ് PostgreSQL വിതരണത്തിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. അവ ഒന്നുകിൽ കംപൈൽ ചെയ്യണം അല്ലെങ്കിൽ ഒരു ലൈബ്രറിയായി ഇൻസ്റ്റാൾ ചെയ്യണം. ഈ അനൗദ്യോഗിക സംഭാവനയുടെ ഡെവലപ്പർ എന്താണ് കൊണ്ടുവന്നത് എന്നതിനെ ആശ്രയിച്ച് ഓപ്ഷനുകൾ വളരെ വ്യത്യസ്തമായിരിക്കും.

ഈ സ്ലൈഡ് എല്ലാ കാഴ്ചകളും PostgreSQL 9.4-ൽ ലഭ്യമായ ചില ഫംഗ്ഷനുകളും അവതരിപ്പിക്കുന്നു. നമ്മൾ കാണുന്നതുപോലെ, അവയിൽ ധാരാളം ഉണ്ട്. നിങ്ങൾ ആദ്യമായി കണ്ടുമുട്ടിയാൽ ആശയക്കുഴപ്പത്തിലാകുന്നത് വളരെ എളുപ്പമാണ്.

എന്നിരുന്നാലും, ഞങ്ങൾ മുമ്പത്തെ ചിത്രം എടുക്കുകയാണെങ്കിൽ Как тратится время на PostgreSQL ഈ ലിസ്റ്റുമായി പൊരുത്തപ്പെടുന്നു, ഞങ്ങൾക്ക് ഈ ചിത്രം ലഭിക്കും. PostgreSQL പ്രവർത്തിക്കുമ്പോൾ അനുബന്ധ സ്ഥിതിവിവരക്കണക്കുകൾ ലഭിക്കുന്നതിന് ഞങ്ങൾക്ക് ഓരോ കാഴ്‌ചയും (കാഴ്‌ചകൾ) അല്ലെങ്കിൽ ഓരോ ഫംഗ്‌ഷനും ഒരു ഉദ്ദേശ്യത്തിനോ മറ്റോ ഉപയോഗിക്കാം. ഉപസിസ്റ്റത്തിന്റെ പ്രവർത്തനത്തെക്കുറിച്ചുള്ള ചില വിവരങ്ങൾ ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ലഭിക്കും.

നമ്മൾ ആദ്യം നോക്കുന്നത് pg_stat_database. നമുക്ക് കാണാനാകുന്നതുപോലെ, ഇതൊരു പ്രകടനമാണ്. അതിൽ ധാരാളം വിവരങ്ങൾ ഉണ്ട്. ഏറ്റവും വൈവിധ്യമാർന്ന വിവരങ്ങൾ. ഞങ്ങളുടെ ഡാറ്റാബേസിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഇത് വളരെ ഉപയോഗപ്രദമായ അറിവ് നൽകുന്നു.

അവിടെ നിന്ന് നമുക്ക് എന്ത് ഉപയോഗപ്രദമായ കാര്യങ്ങൾ എടുക്കാൻ കഴിയും? ഏറ്റവും ലളിതമായ കാര്യങ്ങളിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

നമുക്ക് ആദ്യം നോക്കാൻ കഴിയുന്നത് കാഷെ ഹിറ്റ് ശതമാനമാണ്. കാഷെ ഹിറ്റ് നിരക്ക് ഉപയോഗപ്രദമായ ഒരു മെട്രിക് ആണ്. പങ്കിട്ട ബഫറുകളുടെ കാഷെയിൽ നിന്ന് എത്ര ഡാറ്റ എടുക്കുന്നുവെന്നും ഡിസ്കിൽ നിന്ന് എത്രമാത്രം വായിക്കപ്പെടുന്നുവെന്നും കണക്കാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

അത് വ്യക്തമാണ് നമുക്ക് എത്ര കാഷെ ഹിറ്റുകൾ ഉണ്ടോ അത്രയും നല്ലത്. ഈ മെട്രിക് ഞങ്ങൾ ഒരു ശതമാനമായി അളക്കുന്നു. കൂടാതെ, ഉദാഹരണത്തിന്, ഈ കാഷെ ഹിറ്റുകളുടെ നമ്മുടെ ശതമാനം 90%-ൽ കൂടുതലാണെങ്കിൽ, ഇത് നല്ലതാണ്. ഇത് 90% ത്തിൽ താഴെ വീണാൽ, മെമ്മറിയിൽ ഡാറ്റയുടെ ഹോട്ട് ഹെഡ് ഹോൾഡ് ചെയ്യാൻ ഞങ്ങൾക്ക് മതിയായ മെമ്മറി ഇല്ല എന്നാണ് ഇതിനർത്ഥം. ഈ ഡാറ്റ ഉപയോഗിക്കുന്നതിന്, PostgreSQL ഡിസ്ക് ആക്സസ് ചെയ്യാൻ നിർബന്ധിതരാകുന്നു, ഇത് മെമ്മറിയിൽ നിന്ന് ഡാറ്റ വായിക്കുന്നതിനേക്കാൾ വേഗത കുറവാണ്. മെമ്മറി വർദ്ധിപ്പിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾ ചിന്തിക്കേണ്ടതുണ്ട്: ഒന്നുകിൽ പങ്കിട്ട ബഫറുകൾ വർദ്ധിപ്പിക്കുക, അല്ലെങ്കിൽ ഹാർഡ്‌വെയർ മെമ്മറി (റാം) വർദ്ധിപ്പിക്കുക.

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 വളരെ ലളിതമാണ്. ഈ ഡാറ്റ നമുക്ക് ഇവിടെ നോക്കാം.

ത്രെഷോൾഡ് മൂല്യങ്ങൾ ഇതാ. കമ്മിറ്റുകളുടെയും റോൾബാക്കുകളുടെയും അനുപാതം ഞങ്ങൾ നോക്കുന്നു. ഒരു ഇടപാടിന്റെ വിജയകരമായ സ്ഥിരീകരണമാണ് കമ്മിറ്റുകൾ. റോൾബാക്കുകൾ ഒരു റോൾബാക്ക് ആണ്, അതായത് ഒരു ഇടപാട് ചില ജോലികൾ ചെയ്തു, ഡാറ്റാബേസ് ബുദ്ധിമുട്ടിച്ചു, എന്തെങ്കിലും കണക്കുകൂട്ടി, തുടർന്ന് ഒരു പരാജയം സംഭവിക്കുകയും ഇടപാടിന്റെ ഫലങ്ങൾ ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു. അതാണ് തുടർച്ചയായി വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്ന റോൾബാക്കുകളുടെ എണ്ണം മോശമാണ്. നിങ്ങൾ എങ്ങനെയെങ്കിലും അവ ഒഴിവാക്കുകയും ഇത് സംഭവിക്കാതിരിക്കാൻ കോഡ് എഡിറ്റ് ചെയ്യുകയും വേണം.

പൊരുത്തക്കേടുകൾ അനുകരണവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. കൂടാതെ അവ ഒഴിവാക്കുകയും വേണം. നിങ്ങൾക്ക് ഒരു പകർപ്പിൽ എക്സിക്യൂട്ട് ചെയ്യപ്പെടുകയും പൊരുത്തക്കേടുകൾ ഉണ്ടാകുകയും ചെയ്യുന്ന ചില അന്വേഷണങ്ങൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഈ വൈരുദ്ധ്യങ്ങൾ ക്രമീകരിച്ച് എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണേണ്ടതുണ്ട്. വിശദാംശങ്ങൾ ലോഗുകളിൽ കാണാം. കൂടാതെ വൈരുദ്ധ്യ സാഹചര്യങ്ങൾ ഇല്ലാതാക്കുക, അതുവഴി ആപ്ലിക്കേഷൻ അഭ്യർത്ഥനകൾ പിശകുകളില്ലാതെ പ്രവർത്തിക്കും.

ഡെഡ്‌ലോക്കുകളും ഒരു മോശം അവസ്ഥയാണ്. ഉറവിടങ്ങൾക്കായി അഭ്യർത്ഥനകൾ പോരാടുമ്പോൾ, ഒരു അഭ്യർത്ഥന ഒരു റിസോഴ്‌സ് ആക്‌സസ് ചെയ്‌ത് ലോക്ക് എടുത്തു, രണ്ടാമത്തെ അഭ്യർത്ഥന രണ്ടാമത്തെ റിസോഴ്‌സ് ആക്‌സസ് ചെയ്‌ത് ലോക്ക് എടുത്തു, തുടർന്ന് രണ്ട് അഭ്യർത്ഥനകളും പരസ്പരം ഉറവിടങ്ങൾ ആക്‌സസ് ചെയ്യുകയും അയൽക്കാരൻ ലോക്ക് റിലീസ് ചെയ്യാൻ കാത്തിരിക്കുമ്പോൾ ബ്ലോക്ക് ചെയ്യുകയും ചെയ്തു. ഇതും പ്രശ്‌നകരമായ അവസ്ഥയാണ്. ആപ്ലിക്കേഷനുകൾ റീറൈറ്റുചെയ്യുന്നതിനും ഉറവിടങ്ങളിലേക്കുള്ള ആക്സസ് സീരിയലൈസ് ചെയ്യുന്നതിനുമുള്ള തലത്തിൽ അവ അഭിസംബോധന ചെയ്യേണ്ടതുണ്ട്. നിങ്ങളുടെ ഡെഡ്‌ലോക്കുകൾ നിരന്തരം വർദ്ധിക്കുന്നതായി നിങ്ങൾ കാണുകയാണെങ്കിൽ, നിങ്ങൾ ലോഗുകളിലെ വിശദാംശങ്ങൾ നോക്കുകയും ഉണ്ടാകുന്ന സാഹചര്യങ്ങൾ വിശകലനം ചെയ്യുകയും പ്രശ്‌നം എന്താണെന്ന് കാണുകയും വേണം.

താൽക്കാലിക ഫയലുകളും (temp_files) മോശമാണ്. ഒരു ഉപയോക്തൃ അഭ്യർത്ഥനയ്ക്ക് പ്രവർത്തനപരവും താൽക്കാലികവുമായ ഡാറ്റ ഉൾക്കൊള്ളാൻ മതിയായ മെമ്മറി ഇല്ലെങ്കിൽ, അത് ഡിസ്കിൽ ഒരു ഫയൽ സൃഷ്ടിക്കുന്നു. മെമ്മറിയിലെ ഒരു താൽക്കാലിക ബഫറിൽ ഇത് ചെയ്യാൻ കഴിയുന്ന എല്ലാ പ്രവർത്തനങ്ങളും ഡിസ്കിൽ നടപ്പിലാക്കാൻ തുടങ്ങുന്നു. ഇത് പതുക്കെയാണ്. ഇത് അന്വേഷണ നിർവ്വഹണ സമയം വർദ്ധിപ്പിക്കുന്നു. PostgreSQL-ലേക്ക് ഒരു അഭ്യർത്ഥന അയച്ച ക്ലയന്റിന് കുറച്ച് കഴിഞ്ഞ് ഒരു പ്രതികരണം ലഭിക്കും. ഈ പ്രവർത്തനങ്ങളെല്ലാം മെമ്മറിയിൽ നടത്തുകയാണെങ്കിൽ, Postgres വളരെ വേഗത്തിൽ പ്രതികരിക്കുകയും ക്ലയന്റ് കുറച്ച് കാത്തിരിക്കുകയും ചെയ്യും.

Pg_stat_bgwriter - ഈ കാഴ്ച രണ്ട് PostgreSQL പശ്ചാത്തല ഉപസിസ്റ്റങ്ങളുടെ പ്രവർത്തനത്തെ വിവരിക്കുന്നു: ഇത് checkpointer и background writer.

ആദ്യം, നമുക്ക് നിയന്ത്രണ പോയിന്റുകൾ നോക്കാം, വിളിക്കപ്പെടുന്നവ. checkpoints. നിയന്ത്രണ പോയിന്റുകൾ എന്തൊക്കെയാണ്? ലോഗിൽ രേഖപ്പെടുത്തിയിട്ടുള്ള എല്ലാ ഡാറ്റ മാറ്റങ്ങളും ഡിസ്കിലെ ഡാറ്റയുമായി വിജയകരമായി സമന്വയിപ്പിച്ചതായി സൂചിപ്പിക്കുന്ന ഇടപാട് ലോഗിലെ ഒരു സ്ഥാനമാണ് ചെക്ക്പോയിന്റ്. ജോലിഭാരവും ക്രമീകരണങ്ങളും അനുസരിച്ച് ഈ പ്രക്രിയ ദൈർഘ്യമേറിയതും ഡിസ്കിലെ ഡാറ്റ ഫയലുകളുമായി പങ്കിട്ട ബഫറുകളിലെ വൃത്തികെട്ട പേജുകൾ സമന്വയിപ്പിക്കുന്നതുമാണ്. ഇതെന്തിനാണു? PostgreSQL തുടർച്ചയായി ഡിസ്കിലേക്ക് പ്രവേശിക്കുകയും അവിടെ നിന്ന് ഡാറ്റ എടുക്കുകയും ഓരോ ആക്സസിലും ഡാറ്റ എഴുതുകയും ചെയ്യുകയാണെങ്കിൽ, അത് മന്ദഗതിയിലാകും. അതിനാൽ, PostgreSQL-ന് ഒരു മെമ്മറി സെഗ്മെന്റ് ഉണ്ട്, അതിന്റെ വലിപ്പം കോൺഫിഗറേഷനിലെ ക്രമീകരണങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. പോസ്റ്റ്‌ഗ്രെസ് ഈ മെമ്മറിയിൽ തത്സമയ ഡാറ്റ സംഭരിക്കുന്നു, പിന്നീടുള്ള പ്രോസസ്സിംഗിനും അന്വേഷണത്തിനും. ഡാറ്റ മാറ്റാനുള്ള അഭ്യർത്ഥനകളുടെ കാര്യത്തിൽ, അത് മാറ്റി. കൂടാതെ ഞങ്ങൾക്ക് ഡാറ്റയുടെ രണ്ട് പതിപ്പുകൾ ലഭിക്കും. ഒന്ന് നമ്മുടെ ഓർമ്മയിലുണ്ട്, മറ്റൊന്ന് ഡിസ്കിലാണ്. ഇടയ്ക്കിടെ നിങ്ങൾ ഈ ഡാറ്റ സമന്വയിപ്പിക്കേണ്ടതുണ്ട്. മെമ്മറിയിൽ മാറിയത് ഡിസ്കിലേക്ക് സമന്വയിപ്പിക്കേണ്ടതുണ്ട്. ഇതിനായി നിങ്ങൾക്ക് ചെക്ക്പോസ്റ്റുകൾ ആവശ്യമാണ്.

ചെക്ക്‌പോയിന്റ് പങ്കിട്ട ബഫറുകളിലൂടെ കടന്നുപോകുന്നു, ചെക്ക്‌പോയിന്റിന് ആവശ്യമായ വൃത്തികെട്ട പേജുകൾ അടയാളപ്പെടുത്തുന്നു. പിന്നീട് അത് പങ്കിട്ട ബഫറുകളിലൂടെ രണ്ടാമത്തെ പാസ് സമാരംഭിക്കുന്നു. ചെക്ക് പോയിന്റിനായി അടയാളപ്പെടുത്തിയിരിക്കുന്ന പേജുകൾ, അത് ഇതിനകം തന്നെ അവയെ സമന്വയിപ്പിക്കുന്നു. ഈ രീതിയിൽ ഡാറ്റ ഡിസ്കുമായി സമന്വയിപ്പിക്കപ്പെടുന്നു.

രണ്ട് തരത്തിലുള്ള ചെക്ക്പോസ്റ്റുകളുണ്ട്. ഒരു ചെക്ക്‌പോയിന്റ് കാലഹരണപ്പെട്ടതോടെ നിർവ്വഹിക്കുന്നു. ഈ ചെക്ക് പോയിന്റ് ഉപയോഗപ്രദവും മികച്ചതുമാണ് - checkpoint_timed. ആവശ്യാനുസരണം ചെക്ക്‌പോസ്റ്റുകളുണ്ട് - checkpoint required. ഞങ്ങൾക്ക് വളരെ വലിയ ഡാറ്റ റെക്കോർഡ് ഉള്ളപ്പോൾ ഈ ചെക്ക് പോയിന്റ് സംഭവിക്കുന്നു. ഞങ്ങൾ ഒരുപാട് ഇടപാട് ലോഗുകൾ രേഖപ്പെടുത്തി. കൂടാതെ, കഴിയുന്നത്ര വേഗത്തിൽ ഇതെല്ലാം സമന്വയിപ്പിക്കേണ്ടതുണ്ടെന്നും ഒരു ചെക്ക് പോയിന്റ് ഉണ്ടാക്കി മുന്നോട്ട് പോകേണ്ടതുണ്ടെന്നും PostgreSQL വിശ്വസിക്കുന്നു.

നിങ്ങൾ സ്ഥിതിവിവരക്കണക്കുകൾ നോക്കിയാൽ pg_stat_bgwriter നിനക്കുള്ളത് കണ്ടു checkpoint_req ചെക്ക്‌പോയിന്റ്_ടൈം ചെയ്തതിനേക്കാൾ വളരെ വലുതാണ്, അപ്പോൾ ഇത് മോശമാണ്. എന്തുകൊണ്ട് മോശം? ഡിസ്കിലേക്ക് ഡാറ്റ എഴുതേണ്ടിവരുമ്പോൾ PostgreSQL നിരന്തരമായ സമ്മർദ്ദത്തിലാണെന്നാണ് ഇതിനർത്ഥം. ടൈംഔട്ട് ചെക്ക്‌പോയിന്റ് സമ്മർദ്ദം കുറവുള്ളതും ആന്തരിക ഷെഡ്യൂൾ അനുസരിച്ചുള്ളതും കാലക്രമേണ വ്യാപിക്കുന്നതുമാണ്. PostgreSQL-ന് ജോലി താൽക്കാലികമായി നിർത്താനും ഡിസ്ക് സബ്സിസ്റ്റം ബുദ്ധിമുട്ടാക്കാതിരിക്കാനുമുള്ള കഴിവുണ്ട്. ഇത് PostgreSQL-ന് ഉപയോഗപ്രദമാണ്. ഡിസ്ക് സബ്സിസ്റ്റം തിരക്കിലായതിനാൽ ചെക്ക് പോയിന്റ് സമയത്ത് എക്സിക്യൂട്ട് ചെയ്യുന്ന അന്വേഷണങ്ങൾക്ക് സമ്മർദ്ദം അനുഭവപ്പെടില്ല.

ചെക്ക് പോയിന്റ് ക്രമീകരിക്കുന്നതിന് മൂന്ന് പാരാമീറ്ററുകൾ ഉണ്ട്:

• сheckpoint_segments.

• сheckpoint_timeout.

• сheckpoint_competion_target.

നിയന്ത്രണ പോയിന്റുകളുടെ പ്രവർത്തനം നിയന്ത്രിക്കാൻ അവർ നിങ്ങളെ അനുവദിക്കുന്നു. എന്നാൽ ഞാൻ അവയിൽ വസിക്കുകയില്ല. അവരുടെ സ്വാധീനം ഒരു പ്രത്യേക വിഷയമാണ്.

മുന്നറിയിപ്പ്: റിപ്പോർട്ടിൽ ചർച്ച ചെയ്ത പതിപ്പ് 9.4 ഇപ്പോൾ പ്രസക്തമല്ല. PostgreSQL-ന്റെ ആധുനിക പതിപ്പുകളിൽ പരാമീറ്റർ checkpoint_segments പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചു min_wal_size и max_wal_size.

അടുത്ത ഉപസിസ്റ്റം പശ്ചാത്തല എഴുത്തുകാരനാണ് - background writer. അവൻ എന്താണ് ചെയ്യുന്നത്? ഇത് അനന്തമായ ലൂപ്പിൽ നിരന്തരം പ്രവർത്തിക്കുന്നു. പങ്കിട്ട ബഫറുകളിലെ പേജുകൾ സ്കാൻ ചെയ്യുകയും അത് കണ്ടെത്തുന്ന വൃത്തികെട്ട പേജുകൾ ഡിസ്കിലേക്ക് തള്ളുകയും ചെയ്യുന്നു. അതിനാൽ, ചെക്ക്‌പോയിന്റ് എക്‌സിക്യൂഷൻ സമയത്ത് കുറച്ച് ജോലി ചെയ്യാൻ ഇത് ചെക്ക്‌പോയിന്ററെ സഹായിക്കുന്നു.

മറ്റെന്താണ് വേണ്ടത്? ഡാറ്റ ഉൾക്കൊള്ളാൻ പെട്ടെന്ന് (വലിയ അളവിലും ഉടനടിയും) ആവശ്യമെങ്കിൽ പങ്കിട്ട ബഫറുകളിൽ ശൂന്യമായ പേജുകളുടെ ആവശ്യകത ഇത് നൽകുന്നു. ഒരു അഭ്യർത്ഥന പൂർത്തിയാക്കാൻ ശൂന്യമായ പേജുകൾ ആവശ്യമായി വരുമ്പോൾ ഒരു സാഹചര്യം ഉടലെടുത്തുവെന്നും അവ ഇതിനകം പങ്കിട്ട ബഫറുകളിൽ ഉണ്ടെന്നും കരുതുക. പോസ്റ്റ്ഗ്രേസീവ് backend അവൻ അവ എടുക്കുകയും അവ ഉപയോഗിക്കുകയും ചെയ്യുന്നു, അവൻ സ്വയം ഒന്നും വൃത്തിയാക്കേണ്ടതില്ല. എന്നാൽ പെട്ടെന്ന് അത്തരം പേജുകൾ ഇല്ലെങ്കിൽ, ബാക്കെൻഡ് പ്രവർത്തനം താൽക്കാലികമായി നിർത്തുകയും അവ ഡിസ്കിലേക്ക് വലിച്ചെറിയാനും സ്വന്തം ആവശ്യങ്ങൾക്കായി എടുക്കാനും പേജുകൾക്കായി തിരയാൻ തുടങ്ങുന്നു - ഇത് നിലവിൽ നടപ്പിലാക്കുന്ന അഭ്യർത്ഥനയുടെ സമയത്തെ പ്രതികൂലമായി ബാധിക്കുന്നു. നിങ്ങൾക്ക് ഒരു പരാമീറ്റർ ഉണ്ടെന്ന് നിങ്ങൾ കാണുകയാണെങ്കിൽ maxwritten_clean വലുത്, ഇതിനർത്ഥം പശ്ചാത്തല എഴുത്തുകാരൻ അതിന്റെ ജോലി ചെയ്യുന്നില്ല, നിങ്ങൾ പാരാമീറ്ററുകൾ വർദ്ധിപ്പിക്കേണ്ടതുണ്ട് എന്നാണ് bgwriter_lru_maxpages, ഒരു സൈക്കിളിൽ അയാൾക്ക് കൂടുതൽ ജോലി ചെയ്യാൻ കഴിയും, കൂടുതൽ പേജുകൾ മായ്‌ക്കുക.

വളരെ ഉപയോഗപ്രദമായ മറ്റൊരു സൂചകമാണ് buffers_backend_fsync. ബാക്കെൻഡുകൾ മന്ദഗതിയിലായതിനാൽ സമന്വയിപ്പിക്കപ്പെടുന്നില്ല. അവർ ഐഒ സ്റ്റാക്ക് ചെക്ക്പോയിന്ററിലേക്ക് fsync കൈമാറുന്നു. ചെക്ക്പോയിന്ററിന് അതിന്റേതായ ക്യൂ ഉണ്ട്, അത് ഇടയ്ക്കിടെ fsync പ്രോസസ്സ് ചെയ്യുകയും ഡിസ്കിലെ ഫയലുകളുമായി മെമ്മറിയിലെ പേജുകൾ സമന്വയിപ്പിക്കുകയും ചെയ്യുന്നു. ചെക്ക്‌പോയിന്ററിലെ ക്യൂ വലുതും നിറഞ്ഞതുമാണെങ്കിൽ, ബാക്കെൻഡ് സ്വയം fsync ചെയ്യാൻ നിർബന്ധിതരാകുന്നു, ഇത് ബാക്കെൻഡിന്റെ പ്രവർത്തനത്തെ മന്ദഗതിയിലാക്കുന്നു., അതായത് ക്ലയന്റിന് അതിന് കഴിയുന്നതിനേക്കാൾ പിന്നീട് ഒരു പ്രതികരണം ലഭിക്കും. നിങ്ങളുടെ മൂല്യം പൂജ്യത്തേക്കാൾ വലുതാണെന്ന് നിങ്ങൾ കാണുകയാണെങ്കിൽ, ഇത് ഇതിനകം ഒരു പ്രശ്നമാണ് നിങ്ങൾ പശ്ചാത്തല എഴുത്തുകാരന്റെ ക്രമീകരണങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്, കൂടാതെ ഡിസ്ക് സബ്സിസ്റ്റത്തിന്റെ പ്രകടനം വിലയിരുത്തുകയും വേണം.

മുന്നറിയിപ്പ്: _ഇനിപ്പറയുന്ന വാചകം അനുകരണവുമായി ബന്ധപ്പെട്ട സ്ഥിതിവിവരക്കണക്കുകൾ വിവരിക്കുന്നു. മിക്ക കാഴ്ചകളുടെയും പ്രവർത്തനങ്ങളുടെയും പേരുകൾ പോസ്റ്റ്ഗ്രെസ് 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());

ഈ കാര്യങ്ങൾ വ്യത്യസ്തമാണെങ്കിൽ, ഒരുതരം കാലതാമസമുണ്ട്. റെപ്ലിക്കയും മാസ്റ്ററും തമ്മിലുള്ള കാലതാമസമാണ് ലാഗ്, അതായത് ഡാറ്റ സെർവറുകൾക്കിടയിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

കാലതാമസത്തിന് മൂന്ന് കാരണങ്ങളുണ്ട്:

• ഈ ഡിസ്ക് സബ്സിസ്റ്റത്തിന് റെക്കോർഡിംഗ് ഫയൽ സിൻക്രൊണൈസേഷൻ നേരിടാൻ കഴിയില്ല.
• ഇവ സാധ്യമായ നെറ്റ്‌വർക്ക് പിശകുകൾ അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ഓവർലോഡ് ആണ്, ഡാറ്റയ്ക്ക് പകർപ്പിൽ എത്താൻ സമയമില്ലാതിരിക്കുകയും അത് പുനർനിർമ്മിക്കാൻ കഴിയാതിരിക്കുകയും ചെയ്യുമ്പോൾ.
• ഒപ്പം പ്രൊസസറും. പ്രോസസ്സർ വളരെ അപൂർവമായ ഒരു കേസാണ്. ഞാൻ ഇത് രണ്ടോ മൂന്നോ തവണ കണ്ടു, പക്ഷേ ഇതും സംഭവിക്കാം.

സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന മൂന്ന് അന്വേഷണങ്ങൾ ഇതാ. ഇടപാട് ലോഗിൽ നമ്മൾ എത്രമാത്രം രേഖപ്പെടുത്തിയിട്ടുണ്ടെന്ന് നമുക്ക് കണക്കാക്കാം. അത്തരമൊരു പ്രവർത്തനം ഉണ്ട് pg_xlog_location_diff ബൈറ്റുകളിലും സെക്കന്റുകളിലും നമുക്ക് റെപ്ലിക്കേഷൻ ലാഗ് കണക്കാക്കാം. ഇതിനായി ഞങ്ങൾ ഈ കാഴ്ചയിൽ നിന്നുള്ള മൂല്യവും (കാഴ്ചകൾ) ഉപയോഗിക്കുന്നു.

കുറിപ്പ്: _പകരം pg_xlog_locationഡിഫ്() ഫംഗ്‌ഷന് സബ്‌ട്രാക്ഷൻ ഓപ്പറേറ്റർ ഉപയോഗിക്കാനും ഒരു ലൊക്കേഷൻ മറ്റൊന്നിൽ നിന്ന് കുറയ്ക്കാനും കഴിയും. സുഖപ്രദമായ.

കാലതാമസത്തിനൊപ്പം ഒരു പോയിന്റ് ഉണ്ട്, അത് സെക്കന്റുകൾക്കുള്ളിലാണ്. മാസ്റ്ററിൽ ആക്‌റ്റിവിറ്റി ഇല്ലെങ്കിൽ, ഇടപാട് ഏകദേശം 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().

പൊതുവേ, മെറ്റാകമാൻഡുകൾ ഉണ്ട് dt и di, ഇത് PSQL-ൽ ഉപയോഗിക്കുകയും പട്ടികകളുടെയും സൂചികകളുടെയും വലിപ്പവും കാണുകയും ചെയ്യാം.

എന്നിരുന്നാലും, ഫംഗ്‌ഷനുകൾ ഉപയോഗിക്കുന്നത്, സൂചികകൾ കണക്കിലെടുക്കാതെയോ അല്ലെങ്കിൽ സൂചികകൾ കണക്കിലെടുക്കാതെയോ പട്ടികകളുടെ വലുപ്പങ്ങൾ നോക്കാൻ ഞങ്ങളെ സഹായിക്കുന്നു, കൂടാതെ ഡാറ്റാബേസിന്റെ വളർച്ചയെ അടിസ്ഥാനമാക്കി ഇതിനകം തന്നെ ചില കണക്കുകൾ ഉണ്ടാക്കുന്നു, അതായത് അത് എങ്ങനെ വളരുന്നു, ഏത് തീവ്രതയോടെ, കൂടാതെ സൈസിംഗ് ഒപ്റ്റിമൈസേഷനെ കുറിച്ച് ചില നിഗമനങ്ങളിൽ എത്തിച്ചേരുക.

റെക്കോർഡിംഗ് പ്രവർത്തനം. എന്താണ് ഒരു റെക്കോർഡിംഗ്? നമുക്ക് ഓപ്പറേഷൻ നോക്കാം UPDATE - ഒരു പട്ടികയിലെ വരികൾ അപ്ഡേറ്റ് ചെയ്യുന്നതിന്റെ പ്രവർത്തനം. വാസ്തവത്തിൽ, അപ്ഡേറ്റ് രണ്ട് പ്രവർത്തനങ്ങളാണ് (അല്ലെങ്കിൽ അതിലും കൂടുതൽ). ഇത് വരിയുടെ പുതിയ പതിപ്പ് ചേർക്കുകയും വരിയുടെ പഴയ പതിപ്പ് കാലഹരണപ്പെട്ടതായി അടയാളപ്പെടുത്തുകയും ചെയ്യുന്നു. തുടർന്ന്, ഓട്ടോവാക്വം വരികയും ലൈനുകളുടെ ഈ കാലഹരണപ്പെട്ട പതിപ്പുകൾ വൃത്തിയാക്കുകയും ഈ സ്ഥലം പുനരുപയോഗത്തിന് ലഭ്യമാണെന്ന് അടയാളപ്പെടുത്തുകയും ചെയ്യും.

കൂടാതെ, അപ്ഡേറ്റ് എന്നത് ഒരു ടേബിൾ അപ്ഡേറ്റ് ചെയ്യുന്നത് മാത്രമല്ല. ഇതൊരു സൂചിക അപ്‌ഡേറ്റ് കൂടിയാണ്. നിങ്ങൾക്ക് പട്ടികയിൽ നിരവധി സൂചികകൾ ഉണ്ടെങ്കിൽ, അപ്ഡേറ്റ് സമയത്ത്, അന്വേഷണത്തിൽ അപ്ഡേറ്റ് ചെയ്ത ഫീൽഡുകൾ ഉൾപ്പെടുന്ന എല്ലാ സൂചികകളും അപ്ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട്. ഈ സൂചികകളിൽ ക്ലീൻ ചെയ്യേണ്ട വരികളുടെ പഴകിയ പതിപ്പുകളും ഉണ്ടാകും.

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;

പുതിയ ഡിസൈൻ കാരണം, അപ്‌ഡേറ്റ് ഒരു ഹെവിവെയ്റ്റ് ഓപ്പറേഷനാണ്. എന്നാൽ അവ എളുപ്പമാക്കാം. കഴിക്കുക 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));

ഓട്ടോവാക്വം ക്യൂ. PostgreSQL-ൽ വളരെ കുറച്ച് സ്ഥിതിവിവരക്കണക്കുകൾ മാത്രമുള്ള ഒരു ഉപസിസ്റ്റമാണ് Autovacuum. pg_stat_activity എന്നതിലെ പട്ടികകളിൽ മാത്രമേ നമുക്ക് ഇപ്പോൾ എത്ര വാക്വം ഉണ്ടെന്ന് കാണാൻ കഴിയൂ. എന്നിരുന്നാലും, എത്ര ടേബിളുകൾ ക്യൂവിൽ ഉണ്ടെന്ന് ഉടൻ മനസ്സിലാക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ്.

കുറിപ്പ്: _Postgres 10-ൽ തുടങ്ങി, Vatovac ട്രാക്കിംഗിന്റെ സ്ഥിതി വളരെ മെച്ചപ്പെട്ടു - pg_stat_progress കാഴ്ച പ്രത്യക്ഷപ്പെട്ടു.വാക്വം, ഇത് കാർ വാക്വം നിരീക്ഷിക്കുന്നതിനുള്ള പ്രശ്നം ഗണ്യമായി ലളിതമാക്കുന്നു.

നമുക്ക് ഈ ലളിതമായ ചോദ്യം ഉപയോഗിക്കാം. എപ്പോൾ വാക്വം ഉണ്ടാക്കേണ്ടിവരുമെന്ന് നമുക്ക് കാണാൻ കഴിയും. എന്നാൽ എങ്ങനെ, എപ്പോൾ വാക്വം ആരംഭിക്കണം? ഞാൻ നേരത്തെ പറഞ്ഞ വരികളുടെ പൈതൃക പതിപ്പുകളാണിത്. അപ്‌ഡേറ്റ് സംഭവിച്ചു, ലൈനിന്റെ ഒരു പുതിയ പതിപ്പ് ചേർത്തു. സ്ട്രിംഗിന്റെ കാലഹരണപ്പെട്ട ഒരു പതിപ്പ് പ്രത്യക്ഷപ്പെട്ടു. മേശയിൽ pg_stat_user_tables അത്തരമൊരു പരാമീറ്റർ ഉണ്ട് n_dead_tup. ഇത് "ഡെഡ്" ലൈനുകളുടെ എണ്ണം കാണിക്കുന്നു. ഡെഡ് റോകളുടെ എണ്ണം ഒരു നിശ്ചിത പരിധിയേക്കാൾ കൂടുതലായാലുടൻ, ഒരു ഓട്ടോവാക്വം മേശപ്പുറത്ത് വരും.

ഈ പരിധി എങ്ങനെയാണ് കണക്കാക്കുന്നത്? പട്ടികയിലെ മൊത്തം വരികളുടെ എണ്ണത്തിന്റെ വളരെ നിർദ്ദിഷ്ട ശതമാനമാണിത്. ഒരു പരാമീറ്റർ ഉണ്ട് autovacuum_vacuum_scale_factor. ഇത് ശതമാനം നിർണ്ണയിക്കുന്നു. 10% + 50 വരികളുടെ അധിക അടിസ്ഥാന പരിധി ഉണ്ടെന്ന് പറയാം. പിന്നെ എന്ത് സംഭവിക്കും? പട്ടികയിലെ എല്ലാ വരികളുടെയും "10% + 50" എന്നതിനേക്കാൾ കൂടുതൽ നിർജ്ജീവമായ വരികൾ ഉള്ളപ്പോൾ, ഞങ്ങൾ പട്ടിക ഓട്ടോവാക്വമിൽ ഇടുന്നു.

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 ആഴ്ചയെങ്കിലും) സൂചികകൾക്ക് സീറോ സ്കാനുകൾ ഉണ്ടെങ്കിൽ, മിക്കവാറും ഇവ മോശം സൂചികകളാണ്, നമ്മൾ അവ ഒഴിവാക്കേണ്ടതുണ്ട്.

കുറിപ്പ്: സ്ട്രീമിംഗ് റെപ്ലിക്കേഷൻ ക്ലസ്റ്ററുകളുടെ കാര്യത്തിൽ ഉപയോഗിക്കാത്ത സൂചികകൾക്കായി തിരയുമ്പോൾ, നിങ്ങൾ എല്ലാ ക്ലസ്റ്റർ നോഡുകളും പരിശോധിക്കേണ്ടതുണ്ട്, കാരണം സ്ഥിതിവിവരക്കണക്കുകൾ ആഗോളമല്ല, മാസ്റ്ററിൽ സൂചിക ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, അത് പകർപ്പുകളിൽ ഉപയോഗിക്കാം (അവിടെ ഒരു ലോഡ് ഉണ്ടെങ്കിൽ).

രണ്ട് ലിങ്കുകൾ:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

ഉപയോഗിക്കാത്ത സൂചികകൾ എങ്ങനെ നോക്കാം എന്നതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിപുലമായ അന്വേഷണ ഉദാഹരണങ്ങളാണിവ.

രണ്ടാമത്തെ ലിങ്ക് വളരെ രസകരമായ ഒരു അഭ്യർത്ഥനയാണ്. വളരെ നിസ്സാരമല്ലാത്ത ഒരു യുക്തി അവിടെയുണ്ട്. റഫറൻസിനായി ഞാൻ ഇത് ശുപാർശ ചെയ്യുന്നു.

സൂചികകൾ ഉപയോഗിച്ച് മറ്റെന്താണ് സംഗ്രഹിക്കുന്നത്?

• ഉപയോഗിക്കാത്ത സൂചികകൾ മോശമാണ്.

• അവർ സ്ഥലം ഏറ്റെടുക്കുന്നു.

• അപ്‌ഡേറ്റ് പ്രവർത്തനങ്ങൾ മന്ദഗതിയിലാക്കുക.

• വാക്വം വേണ്ടി അധിക ജോലി.

ഉപയോഗിക്കാത്ത സൂചികകൾ നീക്കം ചെയ്താൽ, ഞങ്ങൾ ഡാറ്റാബേസ് മികച്ചതാക്കുക മാത്രമേ ചെയ്യൂ.

അടുത്ത അവതരണം 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 വർക്ക്ലോഡ് ഉണ്ടെങ്കിൽ, ചോദ്യങ്ങൾ വേഗമേറിയതും വളരെ വേഗമേറിയതും നീണ്ട അന്വേഷണങ്ങൾ ഉണ്ടാകരുത്. എന്നിരുന്നാലും, നീണ്ട ചോദ്യങ്ങൾ ഉയർന്നുവരുന്നുവെങ്കിൽ, ഹ്രസ്വകാലത്തേക്ക് വിഷമിക്കേണ്ട കാര്യമില്ല, പക്ഷേ ദീർഘകാലാടിസ്ഥാനത്തിൽ, ദൈർഘ്യമേറിയ അന്വേഷണങ്ങൾ ഡാറ്റാബേസിനെ ദോഷകരമായി ബാധിക്കുന്നു; പട്ടിക വിഘടനം സംഭവിക്കുമ്പോൾ അവ ടേബിളുകളുടെ ബ്ലോട്ട് പ്രഭാവം വർദ്ധിപ്പിക്കുന്നു. വീർപ്പുമുട്ടലും നീണ്ട അന്വേഷണങ്ങളും നിങ്ങൾ ഒഴിവാക്കേണ്ടതുണ്ട്.

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)';

കൂടാതെ, ഞാൻ മുകളിൽ പറഞ്ഞതുപോലെ, ഈ രണ്ട് സംസ്ഥാനങ്ങളും ഇടപാടിൽ നിഷ്‌ക്രിയവും ഇടപാടിൽ നിഷ്‌ക്രിയവും (അലസിപ്പിച്ചത്) മോശമാണ്. അത് എന്താണ്? ആപ്ലിക്കേഷൻ ഒരു ഇടപാട് തുറക്കുകയും ചില പ്രവർത്തനങ്ങൾ ചെയ്യുകയും അതിന്റെ ബിസിനസ്സിലേക്ക് പോകുകയും ചെയ്തപ്പോഴാണ് ഇത്. ഇടപാട് തുറന്നിരിക്കുന്നു. ഇത് തൂങ്ങിക്കിടക്കുന്നു, അതിൽ ഒന്നും സംഭവിക്കുന്നില്ല, ഇത് കണക്ഷൻ എടുക്കുന്നു, മാറിയ വരികളിൽ പൂട്ടുന്നു, പോസ്റ്റർജെസ് ഇടപാട് എഞ്ചിന്റെ ആർക്കിടെക്ചർ കാരണം മറ്റ് ടേബിളുകളുടെ വീക്കം വർദ്ധിപ്പിക്കാൻ സാധ്യതയുണ്ട്. അത്തരം ഇടപാടുകളും വെടിവയ്ക്കണം, കാരണം അവ പൊതുവെ ദോഷകരമാണ്, ഏത് സാഹചര്യത്തിലും.

നിങ്ങളുടെ ഡാറ്റാബേസിൽ അവയിൽ 5-10-20-ൽ കൂടുതൽ ഉണ്ടെന്ന് നിങ്ങൾ കാണുകയാണെങ്കിൽ, നിങ്ങൾ വിഷമിക്കുകയും അവരുമായി എന്തെങ്കിലും ചെയ്യാൻ തുടങ്ങുകയും വേണം.

ഇവിടെ ഞങ്ങൾ കണക്കുകൂട്ടൽ സമയത്തിനും ഉപയോഗിക്കുന്നു clock_timestamp(). ഞങ്ങൾ ഇടപാടുകൾ ഷൂട്ട് ചെയ്യുകയും ആപ്ലിക്കേഷൻ ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്യുന്നു.

ഞാൻ മുകളിൽ പറഞ്ഞതുപോലെ, രണ്ടോ അതിലധികമോ ഇടപാടുകൾ ഒന്നോ അല്ലെങ്കിൽ ഒരു കൂട്ടം വിഭവങ്ങൾക്ക് വേണ്ടി പോരാടുമ്പോഴാണ് തടയുന്നത്. ഇതിനായി ഞങ്ങൾക്ക് ഒരു ഫീൽഡ് ഉണ്ട് waiting ബൂളിയൻ മൂല്യം true അഥവാ false.

ശരിയാണ് - ഇതിനർത്ഥം ഈ പ്രക്രിയ തീർപ്പുകൽപ്പിക്കുന്നില്ല, എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട് എന്നാണ്. ഒരു പ്രോസസ്സ് കാത്തിരിക്കുമ്പോൾ, ഈ പ്രക്രിയ ആരംഭിച്ച ക്ലയന്റും കാത്തിരിക്കുന്നു എന്നാണ് ഇതിനർത്ഥം. ക്ലയന്റ് ബ്രൗസറിൽ ഇരിക്കുകയും കാത്തിരിക്കുകയും ചെയ്യുന്നു.

മുന്നറിയിപ്പ്: _Postgres പതിപ്പ് 9.6 ഫീൽഡിൽ നിന്ന് ആരംഭിക്കുന്നു waiting നീക്കം ചെയ്യുകയും പകരം രണ്ട് വിജ്ഞാനപ്രദമായ ഫീൽഡുകൾ ചേർക്കുകയും ചെയ്തു wait_event_type и wait_event._

ഞാൻ എന്തു ചെയ്യണം? നിങ്ങൾ വളരെക്കാലമായി ശരിയാണെന്ന് കാണുകയാണെങ്കിൽ, അത്തരം അഭ്യർത്ഥനകളിൽ നിന്ന് നിങ്ങൾ രക്ഷപ്പെടണമെന്ന് അർത്ഥമാക്കുന്നു. അത്തരം ഇടപാടുകൾ ഞങ്ങൾ വെറുതെ വെടിവയ്ക്കുന്നു. വിഭവങ്ങൾക്കായി ഓട്ടമത്സരം ഉണ്ടാകാതിരിക്കാൻ അവർ എങ്ങനെയെങ്കിലും ഒപ്റ്റിമൈസ് ചെയ്യണമെന്ന് ഞങ്ങൾ ഡെവലപ്പർമാർക്ക് എഴുതുന്നു. തുടർന്ന് ഇത് സംഭവിക്കാതിരിക്കാൻ ഡവലപ്പർമാർ ആപ്ലിക്കേഷൻ ഒപ്റ്റിമൈസ് ചെയ്യുന്നു.

അങ്ങേയറ്റത്തെ, എന്നാൽ മാരകമല്ലാത്ത കേസാണ് തടസ്സങ്ങൾ ഉണ്ടാകുന്നത്. രണ്ട് ഇടപാടുകൾ രണ്ട് ഉറവിടങ്ങൾ അപ്‌ഡേറ്റുചെയ്‌തു, തുടർന്ന് അവ വീണ്ടും ആക്‌സസ് ചെയ്‌തു, ഇത്തവണ വിപരീത ഉറവിടങ്ങളിലേക്ക്. ഈ സാഹചര്യത്തിൽ, PostgreSQL ഇടപാടിനെ തന്നെ ഇല്ലാതാക്കുന്നു, അങ്ങനെ മറ്റൊന്ന് പ്രവർത്തിക്കുന്നത് തുടരാം. ഇതൊരു അവസാന ഘട്ടമാണ്, അവൾക്ക് ഇത് സ്വയം മനസിലാക്കാൻ കഴിയില്ല. അതിനാൽ, അങ്ങേയറ്റത്തെ നടപടികൾ സ്വീകരിക്കാൻ PostgreSQL നിർബന്ധിതരാകുന്നു.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

തടയൽ ട്രാക്ക് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന രണ്ട് അന്വേഷണങ്ങൾ ഇവിടെയുണ്ട്. ഞങ്ങൾ കാഴ്ച ഉപയോഗിക്കുന്നു 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 സാവധാനത്തിൽ പ്രതികരിക്കുന്നു, ഞങ്ങൾ എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ട് എന്നാണ്.

പങ്കിട്ട ബഫറുകളിലെ ഡാറ്റ മാറ്റുന്ന ഡാറ്റാബേസിലെ ഏറ്റവും സജീവമായ എഴുത്ത് ഇടപാടുകൾ നമുക്ക് നോക്കാം. ആരാണ് അവിടെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യുന്നതെന്നും ഇല്ലാതാക്കുന്നതെന്നും കാണുക.

ഈ അഭ്യർത്ഥനകൾക്കായി നമുക്ക് വ്യത്യസ്ത സ്ഥിതിവിവരക്കണക്കുകൾ നോക്കാം.

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

മ pg_stat_statements റിപ്പോർട്ടുകൾ നിർമ്മിക്കാൻ ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു. ഞങ്ങൾ ഒരു ദിവസത്തിൽ ഒരിക്കൽ സ്ഥിതിവിവരക്കണക്കുകൾ പുനഃസജ്ജമാക്കുന്നു. നമുക്ക് അത് ശേഖരിക്കാം. അടുത്ത തവണ സ്ഥിതിവിവരക്കണക്കുകൾ പുനഃസജ്ജമാക്കുന്നതിന് മുമ്പ്, നമുക്ക് ഒരു റിപ്പോർട്ട് നിർമ്മിക്കാം. റിപ്പോർട്ടിന്റെ ലിങ്ക് ഇതാ. നിങ്ങൾക്ക് അത് കാണാൻ കഴിയും.

നമ്മള് എന്താണ് ചെയ്യുന്നത്? എല്ലാ അഭ്യർത്ഥനകൾക്കും പൊതുവായ സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾ കണക്കാക്കുന്നു. തുടർന്ന്, ഓരോ അഭ്യർത്ഥനയ്ക്കും, ഈ മൊത്തത്തിലുള്ള സ്ഥിതിവിവരക്കണക്കുകളിലേക്കുള്ള അതിന്റെ വ്യക്തിഗത സംഭാവന ഞങ്ങൾ കണക്കാക്കുന്നു.

പിന്നെ നമുക്ക് എന്ത് കാണാൻ കഴിയും? മറ്റെല്ലാ അഭ്യർത്ഥനകളുടെയും പശ്ചാത്തലത്തിൽ ഒരു പ്രത്യേക തരത്തിലുള്ള എല്ലാ അഭ്യർത്ഥനകളുടെയും ആകെ എക്സിക്യൂഷൻ സമയം നമുക്ക് നോക്കാം. മൊത്തത്തിലുള്ള ചിത്രവുമായി ബന്ധപ്പെട്ട് CPU, I/O റിസോഴ്സ് ഉപയോഗം നമുക്ക് നോക്കാം. ഈ അന്വേഷണങ്ങൾ ഇതിനകം ഒപ്റ്റിമൈസ് ചെയ്യുക. ഈ റിപ്പോർട്ടിനെ അടിസ്ഥാനമാക്കി ഞങ്ങൾ മുൻനിര അന്വേഷണങ്ങൾ നിർമ്മിക്കുകയാണ്, എന്താണ് ഒപ്റ്റിമൈസ് ചെയ്യേണ്ടത് എന്നതിനെക്കുറിച്ചുള്ള ചിന്തയ്ക്ക് ഇതിനകം തന്നെ ഭക്ഷണം ലഭിക്കുന്നു.

തിരശ്ശീലയ്ക്ക് പിന്നിൽ നമുക്ക് എന്താണ് അവശേഷിക്കുന്നത്? സമയം പരിമിതമായതിനാൽ ഞാൻ പരിഗണിക്കാത്ത കുറച്ച് സമർപ്പിക്കലുകൾ ഇനിയും ബാക്കിയുണ്ട്.

ഉണ്ട് pgstattuple സ്റ്റാൻഡേർഡ് കോൺട്രിബ്സ് പാക്കേജിൽ നിന്നുള്ള ഒരു അധിക മൊഡ്യൂൾ കൂടിയാണ്. ഇത് വിലയിരുത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു bloat പട്ടികകൾ, വിളിക്കപ്പെടുന്നവ പട്ടിക വിഘടനം. ധാരാളം വിഘടനങ്ങൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾ അത് നീക്കം ചെയ്യുകയും വ്യത്യസ്ത ഉപകരണങ്ങൾ ഉപയോഗിക്കുകയും വേണം. ഒപ്പം പ്രവർത്തനവും pgstattuple വളരെക്കാലം പ്രവർത്തിക്കുന്നു. കൂടുതൽ ടേബിളുകൾ ഉണ്ടെങ്കിൽ, അത് കൂടുതൽ നേരം പ്രവർത്തിക്കും.

അടുത്ത സംഭാവനയാണ് pg_buffercache. പങ്കിട്ട ബഫറുകൾ പരിശോധിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു: ബഫർ പേജുകൾ എത്ര തീവ്രമായും ഏത് ടേബിളുകൾക്കായി ഉപയോഗിക്കുന്നു. പങ്കിട്ട ബഫറുകളിലേക്ക് നോക്കാനും അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് വിലയിരുത്താനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

അടുത്ത മൊഡ്യൂൾ ആണ് pgfincore. ഒരു സിസ്റ്റം കോൾ വഴി താഴ്ന്ന നിലയിലുള്ള ടേബിൾ പ്രവർത്തനങ്ങൾ ഇത് അനുവദിക്കുന്നു mincore(), അതായത്, പങ്കിട്ട ബഫറുകളിലേക്ക് ഒരു ടേബിൾ ലോഡ് ചെയ്യാനോ അൺലോഡ് ചെയ്യാനോ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പേജ് കാഷെ പരിശോധിക്കാൻ ഇത് അനുവദിക്കുന്നു, അതായത്, പേജ് കാഷെയിൽ, പങ്കിട്ട ബഫറുകളിൽ പട്ടിക എത്ര സ്ഥലം ഉൾക്കൊള്ളുന്നു, കൂടാതെ പട്ടികയുടെ ജോലിഭാരം വിലയിരുത്താൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

അടുത്ത മൊഡ്യൂൾ - pg_stat_kcache. ഇത് ഒരു സിസ്റ്റം കോളും ഉപയോഗിക്കുന്നു getrusage(). അഭ്യർത്ഥന നടപ്പിലാക്കുന്നതിന് മുമ്പും ശേഷവും അത് അത് നടപ്പിലാക്കുന്നു. തത്ഫലമായുണ്ടാകുന്ന സ്ഥിതിവിവരക്കണക്കുകളിൽ, ഡിസ്ക് I/O-യിൽ ഞങ്ങളുടെ അഭ്യർത്ഥന എത്രമാത്രം ചെലവഴിച്ചുവെന്ന് കണക്കാക്കാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു, അതായത്, ഫയൽ സിസ്റ്റവുമായുള്ള പ്രവർത്തനങ്ങളും പ്രോസസർ ഉപയോഗവും നോക്കുന്നു. എന്നിരുന്നാലും, മൊഡ്യൂൾ ചെറുപ്പമാണ് (ചുമ ചുമ) അതിന്റെ പ്രവർത്തനത്തിന് ഞാൻ നേരത്തെ സൂചിപ്പിച്ച PostgreSQL 9.4, pg_stat_statements എന്നിവ ആവശ്യമാണ്.

• സ്ഥിതിവിവരക്കണക്കുകൾ എങ്ങനെ ഉപയോഗിക്കണമെന്ന് അറിയുന്നത് ഉപയോഗപ്രദമാണ്. നിങ്ങൾക്ക് മൂന്നാം കക്ഷി പ്രോഗ്രാമുകൾ ആവശ്യമില്ല. നിങ്ങൾക്ക് വരാം, കാണുക, എന്തെങ്കിലും ചെയ്യാം, എന്തെങ്കിലും നേടാം.

• സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിക്കുന്നത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല, ഇത് സാധാരണ SQL മാത്രമാണ്. നിങ്ങൾ അഭ്യർത്ഥന ശേഖരിച്ചു, സമാഹരിച്ചു, അയച്ചു, നോക്കി.

• സ്ഥിതിവിവരക്കണക്കുകൾ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ സഹായിക്കുന്നു. നിങ്ങൾക്ക് ചോദ്യങ്ങളുണ്ടെങ്കിൽ, നിങ്ങൾ സ്ഥിതിവിവരക്കണക്കുകളിലേക്ക് തിരിയുക - നോക്കുക, നിഗമനങ്ങളിൽ എത്തിച്ചേരുക, ഫലങ്ങൾ വിശകലനം ചെയ്യുക.

• ഒപ്പം പരീക്ഷണവും. ധാരാളം അഭ്യർത്ഥനകളുണ്ട്, ധാരാളം ഡാറ്റയുണ്ട്. നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും നിലവിലുള്ള ഒരു ചോദ്യം ഒപ്റ്റിമൈസ് ചെയ്യാം. ഒറിജിനലിനേക്കാൾ നിങ്ങൾക്ക് അനുയോജ്യമായ അഭ്യർത്ഥനയുടെ നിങ്ങളുടെ സ്വന്തം പതിപ്പ് ഉണ്ടാക്കുകയും അത് ഉപയോഗിക്കുകയും ചെയ്യാം.

റെഫറൻസുകൾ

മെറ്റീരിയലുകളെ അടിസ്ഥാനമാക്കി ലേഖനത്തിൽ കണ്ടെത്തിയ അനുയോജ്യമായ ലിങ്കുകൾ റിപ്പോർട്ടിലുണ്ട്.

രചയിതാവ് കൂടുതൽ എഴുതുക
https://dataegret.com/news-blog (ഇംഗ്ലീഷ്)

സ്റ്റാറ്റിസ്റ്റിക്സ് കളക്ടർ
https://www.postgresql.org/docs/current/monitoring-stats.html

സിസ്റ്റം അഡ്മിനിസ്ട്രേഷൻ പ്രവർത്തനങ്ങൾ
https://www.postgresql.org/docs/current/functions-admin.html

സംഭാവന മൊഡ്യൂളുകൾ
https://www.postgresql.org/docs/current/pgstatstatements.html
https://www.postgresql.org/docs/current/pgstattuple.html
https://www.postgresql.org/docs/current/pgbuffercache.html
https://github.com/klando/pgfincore
https://github.com/dalibo/pg_stat_kcache

SQL യൂട്ടിലുകളും sql കോഡ് ഉദാഹരണങ്ങളും
https://github.com/dataegret/pg-utils

നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് എല്ലാവർക്കും നന്ദി!

അവലംബം: www.habr.com