postgresql-ൽ വീർക്കുന്നതിലേക്ക് നയിക്കുന്ന ആപ്ലിക്കേഷനുകളിലെ സാധാരണ പിശകുകൾ. ആൻഡ്രി സാൽനികോവ്

2016-ന്റെ തുടക്കം മുതൽ ആന്ദ്രേ സാൽനിക്കോവ് എഴുതിയ റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് വായിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു "പോസ്റ്റ്ഗ്രെസ്‌ക്ലിലെ വയറിളക്കത്തിന് കാരണമാകുന്ന ആപ്ലിക്കേഷനുകളിലെ സാധാരണ പിശകുകൾ"

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

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

എന്തുകൊണ്ടാണ് തെറ്റുകൾ സംഭവിക്കുന്നത്? അവ രണ്ട് കാരണങ്ങളാൽ ചെയ്യപ്പെടുന്നു: ക്രമരഹിതമായി, ഒരുപക്ഷേ ഇത് പ്രവർത്തിക്കും, കൂടാതെ ഡാറ്റാബേസിനും ആപ്ലിക്കേഷനും ഇടയിലുള്ള തലത്തിലും ഡാറ്റാബേസിലും സംഭവിക്കുന്ന ചില മെക്കാനിസങ്ങളെക്കുറിച്ചുള്ള അജ്ഞത കാരണം.

കാര്യങ്ങൾ എത്ര മോശമായി എന്നതിന്റെ ഭയാനകമായ ചിത്രങ്ങളുള്ള മൂന്ന് ഉദാഹരണങ്ങൾ ഞാൻ നിങ്ങൾക്ക് തരാം. അവിടെ സംഭവിക്കുന്ന മെക്കാനിസത്തെക്കുറിച്ച് ഞാൻ ചുരുക്കമായി പറയാം. അവ എങ്ങനെ കൈകാര്യം ചെയ്യണം, അവ എപ്പോൾ സംഭവിച്ചു, തെറ്റുകൾ തടയാൻ എന്ത് പ്രതിരോധ മാർഗ്ഗങ്ങൾ ഉപയോഗിക്കണം. സഹായ ഉപകരണങ്ങളെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയുകയും ഉപയോഗപ്രദമായ ലിങ്കുകൾ നൽകുകയും ചെയ്യും.

എനിക്ക് രണ്ട് പട്ടികകളുള്ള ഒരു ടെസ്റ്റ് ഡാറ്റാബേസ് ഞാൻ ഉപയോഗിച്ചു. കസ്റ്റമർ അക്കൗണ്ടുകളുള്ള ഒരു പ്ലേറ്റ്, മറ്റൊന്ന് ഈ അക്കൗണ്ടുകളിലെ ഇടപാടുകൾ. കുറച്ച് ഫ്രീക്വൻസി ഉപയോഗിച്ച് ഞങ്ങൾ ഈ അക്കൗണ്ടുകളിലെ ബാലൻസുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു.

പ്ലേറ്റിന്റെ പ്രാരംഭ ഡാറ്റ: ഇത് വളരെ ചെറുതാണ്, 2 MB. ഡാറ്റാബേസിനും പ്രത്യേകിച്ച് ചിഹ്നത്തിനുമുള്ള പ്രതികരണ സമയവും വളരെ നല്ലതാണ്. ഒരു നല്ല ലോഡ് - പ്ലേറ്റ് അനുസരിച്ച് സെക്കൻഡിൽ 2 പ്രവർത്തനങ്ങൾ.

എന്താണ് സംഭവിക്കുന്നതെന്ന് വ്യക്തമായി മനസ്സിലാക്കാൻ ഈ റിപ്പോർട്ടിലൂടെ ഞാൻ നിങ്ങൾക്ക് ഗ്രാഫുകൾ കാണിക്കും. ഗ്രാഫുകളുള്ള 2 സ്ലൈഡുകൾ എപ്പോഴും ഉണ്ടായിരിക്കും. സെർവറിൽ പൊതുവെ എന്താണ് സംഭവിക്കുന്നത് എന്നതാണ് ആദ്യത്തെ സ്ലൈഡ്.

ഈ സാഹചര്യത്തിൽ, നമുക്ക് ശരിക്കും ഒരു ചെറിയ അടയാളം ഉണ്ടെന്ന് ഞങ്ങൾ കാണുന്നു. സൂചിക 2 MB-യിൽ ചെറുതാണ്. ഇടതുവശത്തുള്ള ആദ്യത്തെ ഗ്രാഫ് ഇതാണ്.

സെർവറിലെ ശരാശരി പ്രതികരണ സമയവും സ്ഥിരവും ഹ്രസ്വവുമാണ്. ഇതാണ് മുകളിൽ വലത് ഗ്രാഫ്.

താഴെ ഇടതുവശത്തുള്ള ഗ്രാഫ് ഏറ്റവും ദൈർഘ്യമേറിയ ഇടപാടുകൾ കാണിക്കുന്നു. ഇടപാടുകൾ വേഗത്തിൽ പൂർത്തിയാകുന്നതായി ഞങ്ങൾ കാണുന്നു. ഓട്ടോവാക്വം ഇതുവരെ ഇവിടെ പ്രവർത്തിക്കുന്നില്ല, കാരണം ഇതൊരു ആരംഭ പരീക്ഷണമായിരുന്നു. ഇത് തുടർന്നും പ്രവർത്തിക്കുകയും ഞങ്ങൾക്ക് ഉപയോഗപ്രദമാവുകയും ചെയ്യും.

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

അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ആവശ്യമുള്ള ലൈൻ തിരയുന്നതിനായി ഞങ്ങൾ എത്ര ഓപ്പറേറ്റിംഗ്, ഡിസ്ക് മെമ്മറി എന്നിവയിലൂടെ കടന്നുപോകുന്നു എന്ന് ചുവടെ വലത് ഗ്രാഫ് കാണിക്കുന്നു. ഞാൻ തുടക്കത്തിൽ പറഞ്ഞതുപോലെ, അടയാളം അനുസരിച്ച് പ്രവർത്തനങ്ങളുടെ എണ്ണം സെക്കൻഡിൽ 2 ആണ്.

ഇപ്പോൾ നമുക്ക് ഒരു ദുരന്തമുണ്ട്. ചില കാരണങ്ങളാൽ വളരെക്കാലം മറന്നുപോയ ഒരു ഇടപാടുണ്ട്. കാരണങ്ങൾ സാധാരണയായി എല്ലാം നിസ്സാരമാണ്:

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

അത്തരം കാര്യങ്ങൾ എവിടേക്കാണ് നയിക്കുന്നത്?

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

പിന്നെ എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കാം. താഴെ ഇടതുവശത്തുള്ള ഗ്രാഫ് നമുക്ക് ഒരു നീണ്ട ഇടപാട് ഉണ്ടെന്ന് കാണിക്കുന്നു. മുകളിൽ ഇടതുവശത്തുള്ള ഗ്രാഫ് നോക്കിയാൽ, നമ്മുടെ മേശയുടെ വലിപ്പം പെട്ടെന്ന് രണ്ട് മെഗാബൈറ്റിൽ നിന്ന് 300 മെഗാബൈറ്റിലേക്ക് കുതിച്ചുയരുന്നതായി കാണാം. അതേ സമയം, പട്ടികയിലെ ഡാറ്റയുടെ അളവ് മാറിയിട്ടില്ല, അതായത് അവിടെ വളരെ വലിയ മാലിന്യമുണ്ട്.

ശരാശരി സെർവർ പ്രതികരണ സമയത്തെ സംബന്ധിച്ച പൊതുവായ സാഹചര്യവും നിരവധി ക്രമങ്ങളാൽ മാറിയിരിക്കുന്നു. അതായത്, സെർവറിലെ എല്ലാ അഭ്യർത്ഥനകളും പൂർണ്ണമായും ഡ്രോപ്പ് ചെയ്യാൻ തുടങ്ങി. അതേ സമയം, ആന്തരിക പോസ്റ്റ്ഗ്രെസ് പ്രക്രിയകൾ ഓട്ടോവാക്വം രൂപത്തിൽ സമാരംഭിച്ചു, അത് എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിക്കുകയും വിഭവങ്ങൾ ഉപയോഗിക്കുകയും ചെയ്യുന്നു.

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

നമുക്ക് ജീവിതത്തിലേക്ക് തിരിച്ചുവരണം. ദൈർഘ്യമേറിയ ഇടപാടുകൾ പ്രശ്‌നങ്ങളിലേക്ക് നയിക്കുന്നുവെന്ന് ഞങ്ങൾ ഓൺലൈനിൽ പോയി കണ്ടെത്തുന്നു. ഞങ്ങൾ ഈ ഇടപാട് കണ്ടെത്തി കൊല്ലുന്നു. പിന്നെ എല്ലാം നമുക്ക് സാധാരണമായിക്കൊണ്ടിരിക്കുന്നു. എല്ലാം ചെയ്യേണ്ടതുപോലെ പ്രവർത്തിക്കുന്നു.

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

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

പ്രത്യേകമായി, അക്കൗണ്ടുകളുള്ള ടെസ്റ്റ് പ്ലേറ്റ് അനുസരിച്ച്, ഞങ്ങൾ ബാലൻസ് മാറ്റുന്നിടത്ത്: ഒരു അഭ്യർത്ഥനയ്ക്കുള്ള പ്രതികരണ സമയം സാധാരണ നിലയിലേക്ക് മടങ്ങിയതായി തോന്നുന്നു. എന്നാൽ വാസ്തവത്തിൽ ഇത് ഒന്നര മടങ്ങ് കൂടുതലാണ്.

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

മൊത്തത്തിൽ നല്ലത്, പക്ഷേ സ്ഥിതി പഴയതിനേക്കാൾ മോശമാണ്. ഈ ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുന്ന ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ അനന്തരഫലമായി ഡാറ്റാബേസ് ഡീഗ്രേഡേഷൻ മായ്‌ക്കുക.

അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാൻ, നിങ്ങൾ മുമ്പത്തെ റിപ്പോർട്ടിൽ ഇല്ലെങ്കിൽ, ഇപ്പോൾ നമുക്ക് ഒരു ചെറിയ സിദ്ധാന്തം എടുക്കാം. ആന്തരിക പ്രക്രിയയെക്കുറിച്ചുള്ള സിദ്ധാന്തം. എന്തുകൊണ്ടാണ് ഒരു കാർ വാക്വം, അത് എന്താണ് ചെയ്യുന്നത്?

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

എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് ഒരു കാർ വാക്വം വേണ്ടത്? ചില സമയങ്ങളിൽ, ഓട്ടോവാക്വം വരുന്നു, ഡാറ്റാബേസ് ആക്‌സസ് ചെയ്‌ത് അതിനോട് ചോദിക്കുന്നു: "ഡാറ്റാബേസിൽ നിലവിൽ തുറന്നിരിക്കുന്ന ഏറ്റവും പഴയ ഇടപാടിന്റെ ഐഡി ദയവായി എനിക്ക് തരൂ." ഡാറ്റാബേസ് ഈ ഐഡി നൽകുന്നു. ഓട്ടോവാക്വം, അതിനെ ആശ്രയിച്ച്, പട്ടികയിലെ വരികളിലൂടെ അടുക്കുന്നു. ചില വരികൾ വളരെ പഴയ ഇടപാടുകൾ വഴി മാറ്റിയതായി അദ്ദേഹം കാണുകയാണെങ്കിൽ, പുതിയ ഡാറ്റ അവിടെ എഴുതി ഭാവിയിൽ നമുക്ക് പുനരുപയോഗിക്കാവുന്ന വരികളായി അടയാളപ്പെടുത്താൻ അദ്ദേഹത്തിന് അവകാശമുണ്ട്. ഇതൊരു പശ്ചാത്തല പ്രക്രിയയാണ്.

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

അപകട സമയത്ത് എന്താണ് സംഭവിച്ചത്? ഈ പ്രക്രിയ അവിടെ എങ്ങനെ സംഭവിച്ചു?

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

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

വാസ്തവത്തിൽ, നമുക്ക് പ്രവർത്തിക്കാൻ പച്ച ലൈനുകൾ ആവശ്യമാണ്. എന്നാൽ അത്തരമൊരു പ്രശ്ന സമയത്ത്, മുഴുവൻ പട്ടികയിലുടനീളം പച്ച ലൈനുകളുടെ ശതമാനം വളരെ കുറവാണെന്ന് ഇത് മാറുന്നു.

ഞങ്ങൾ ഒരു ചോദ്യം എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, ഡാറ്റാബേസ് എല്ലാ വരികളിലൂടെയും പോകേണ്ടതുണ്ട്: ചുവപ്പും പച്ചയും, ആവശ്യമുള്ള ലൈൻ കണ്ടെത്താൻ. ഉപയോഗശൂന്യമായ ഡാറ്റയുള്ള ഒരു ടേബിൾ വീർക്കുന്നതിന്റെ ഫലത്തെ "ബ്ലോട്ട്" എന്ന് വിളിക്കുന്നു, ഇത് നമ്മുടെ ഡിസ്കിന്റെ ഇടവും നശിപ്പിക്കുന്നു. ഓർക്കുക, അത് 2 MB ആയിരുന്നു, അത് 300 MB ആയി? ഇപ്പോൾ മെഗാബൈറ്റുകൾ ജിഗാബൈറ്റിലേക്ക് മാറ്റുക, നിങ്ങളുടെ എല്ലാ ഡിസ്ക് ഉറവിടങ്ങളും പെട്ടെന്ന് നഷ്ടപ്പെടും.

നമുക്ക് എന്ത് പരിണതഫലങ്ങൾ ഉണ്ടായേക്കാം?

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

ഈ ആവശ്യത്തിനായി ഒരു നിശ്ചിത ചക്രം നടക്കുന്നു.

ആദ്യം നമ്മൾ വീർക്കുന്ന പ്രശ്നമുള്ള പട്ടികകൾ കണ്ടെത്തേണ്ടതുണ്ട്. ചില പട്ടികകളിൽ റെക്കോർഡിംഗ് കൂടുതൽ സജീവമാണെന്നും മറ്റുള്ളവയിൽ കുറവ് സജീവമാണെന്നും ഞങ്ങൾ മനസ്സിലാക്കുന്നു. ഇതിനായി ഞങ്ങൾ വിപുലീകരണം ഉപയോഗിക്കുന്നു pgstattuple. ഈ വിപുലീകരണം ഇൻസ്റ്റാൾ ചെയ്യുന്നതിലൂടെ, നിങ്ങൾക്ക് വളരെ വീർപ്പുമുട്ടുന്ന പട്ടികകൾ കണ്ടെത്താൻ സഹായിക്കുന്ന ചോദ്യങ്ങൾ എഴുതാം.

ഈ പട്ടികകൾ കണ്ടെത്തിക്കഴിഞ്ഞാൽ, നിങ്ങൾ അവയെ കംപ്രസ് ചെയ്യേണ്ടതുണ്ട്. ഇതിനുള്ള ഉപകരണങ്ങൾ ഇതിനകം തന്നെ ഉണ്ട്. ഞങ്ങളുടെ കമ്പനിയിൽ ഞങ്ങൾ മൂന്ന് ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നു. ആദ്യത്തേത് അന്തർനിർമ്മിത VACUUM FULL ആണ്. അവൻ ക്രൂരനും പരുഷവും കരുണയില്ലാത്തവനുമാണ്, പക്ഷേ ചിലപ്പോൾ അവൻ വളരെ ഉപയോഗപ്രദമാണ്. Pg_repack и pgcompactable - ഇവ ടേബിളുകൾ കംപ്രസ്സുചെയ്യുന്നതിനുള്ള മൂന്നാം കക്ഷി യൂട്ടിലിറ്റികളാണ്. അവർ ഡാറ്റാബേസിനെ കൂടുതൽ ശ്രദ്ധയോടെ കൈകാര്യം ചെയ്യുന്നു.

നിങ്ങൾക്ക് കൂടുതൽ സൗകര്യപ്രദമായതിനെ ആശ്രയിച്ചാണ് അവ ഉപയോഗിക്കുന്നത്. എന്നാൽ ഇതിനെക്കുറിച്ച് ഞാൻ അവസാനം നിങ്ങളോട് പറയും. മൂന്ന് ഉപകരണങ്ങൾ ഉണ്ട് എന്നതാണ് പ്രധാന കാര്യം. തിരഞ്ഞെടുക്കാൻ ധാരാളം ഉണ്ട്.

ഞങ്ങൾ എല്ലാം ശരിയാക്കുകയും എല്ലാം ശരിയാണെന്ന് ഉറപ്പുവരുത്തുകയും ചെയ്ത ശേഷം, ഭാവിയിൽ ഈ സാഹചര്യം എങ്ങനെ തടയാമെന്ന് ഞങ്ങൾ അറിഞ്ഞിരിക്കണം:

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

ഈ ഗ്രാഫുകളിൽ, ഈ സാഹചര്യത്തിൽ വാക്വം ഫുൾ ഉപയോഗിച്ച് ഞാൻ സൈനിലേക്ക് പോയതിനുശേഷം ഡാറ്റാബേസിന്റെ അടയാളവും പെരുമാറ്റവും എങ്ങനെ മാറിയെന്ന് നിങ്ങളെ കാണിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഇത് എനിക്ക് ഉൽപ്പാദനമല്ല.

പട്ടികയുടെ വലുപ്പം ഉടൻ തന്നെ രണ്ട് മെഗാബൈറ്റുകളുടെ സാധാരണ പ്രവർത്തന നിലയിലേക്ക് മടങ്ങി. ഇത് സെർവറിന്റെ ശരാശരി പ്രതികരണ സമയത്തെ കാര്യമായി ബാധിച്ചില്ല.

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

ഇവിടെയാണ് ആദ്യ കഥ അവസാനിക്കുന്നത്. ഇത് ഏറ്റവും സാധാരണമാണ്. ക്ലയന്റിന്റെ അനുഭവവും പ്രോഗ്രാമർമാർ എത്രത്തോളം യോഗ്യതയുള്ളവരാണെന്നതും പരിഗണിക്കാതെ എല്ലാവർക്കും ഇത് സംഭവിക്കുന്നു. താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ഇത് സംഭവിക്കുന്നു.

രണ്ടാമത്തെ സ്റ്റോറി, അതിൽ ഞങ്ങൾ ലോഡ് വിതരണം ചെയ്യുകയും സെർവർ ഉറവിടങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്യുന്നു

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

ഈ സാഹചര്യം എങ്ങനെ കാണപ്പെടുന്നു? പ്രത്യേകിച്ചും ഈ ഗ്രാഫുകളിൽ, ഇടപാട് കാലയളവിനുള്ള പകർപ്പിൽ നിന്നുള്ള ഇടപാടുകളുടെ ദൈർഘ്യവും ഞാൻ ചേർത്തു. മറ്റെല്ലാ ഗ്രാഫുകളും മാസ്റ്റർ സെർവറിനെ മാത്രം പരാമർശിക്കുന്നു.

അപ്പോഴേക്കും എന്റെ റിപ്പോർട്ട് ബോർഡ് വളർന്നിരുന്നു. അവയിൽ കൂടുതൽ ഉണ്ട്. ശരാശരി സെർവർ പ്രതികരണ സമയം സ്ഥിരമാണെന്ന് ഞങ്ങൾ കാണുന്നു. പകർപ്പിൽ ഞങ്ങൾക്ക് 2 മണിക്കൂർ പ്രവർത്തിക്കുന്ന ഒരു ദീർഘകാല ഇടപാട് ഉണ്ടെന്ന് ഞങ്ങൾ കാണുന്നു. ഡെഡ് ലൈനുകൾ പ്രോസസ്സ് ചെയ്യുന്ന ഓട്ടോവാക്വത്തിന്റെ ശാന്തമായ പ്രവർത്തനം ഞങ്ങൾ കാണുന്നു. പിന്നെ എല്ലാം ഞങ്ങളോട് നന്നായിരിക്കുന്നു.

പ്രത്യേകമായി, പരിശോധിച്ച പ്ലേറ്റ് അനുസരിച്ച്, ഞങ്ങൾ അവിടെ അക്കൗണ്ട് ബാലൻസുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നത് തുടരുന്നു. അഭ്യർത്ഥനകൾ, സ്ഥിരമായ വിഭവ ഉപഭോഗം എന്നിവയ്‌ക്കായി ഞങ്ങൾക്ക് സ്ഥിരമായ പ്രതികരണ സമയവും ഉണ്ട്. ഞങ്ങൾക്ക് എല്ലാം ശരിയാണ്.

അനുകരണവുമായുള്ള വൈരുദ്ധ്യം കാരണം ഈ റിപ്പോർട്ടുകൾ തിരിച്ചടിക്കാൻ തുടങ്ങുന്നത് വരെ എല്ലാം ശരിയാണ്. അവർ കൃത്യമായ ഇടവേളകളിൽ വെടിയുതിർക്കുന്നു.

എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നതെന്ന് ഞങ്ങൾ ഓൺലൈനിൽ പോയി വായിക്കാൻ തുടങ്ങുന്നു. ഞങ്ങൾ ഒരു പരിഹാരം കണ്ടെത്തുകയും ചെയ്യുന്നു.

റിപ്ലിക്കേഷൻ ലേറ്റൻസി വർദ്ധിപ്പിക്കുക എന്നതാണ് ആദ്യ പരിഹാരം. ഞങ്ങളുടെ റിപ്പോർട്ട് 3 മണിക്കൂർ പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾക്കറിയാം. ഞങ്ങൾ റെപ്ലിക്കേഷൻ കാലതാമസം 3 മണിക്കൂറായി സജ്ജമാക്കി. ഞങ്ങൾ എല്ലാം സമാരംഭിക്കുകയാണ്, പക്ഷേ റിപ്പോർട്ടുകൾ ചിലപ്പോൾ റദ്ദാക്കപ്പെടുന്നതിൽ ഞങ്ങൾക്ക് ഇപ്പോഴും പ്രശ്‌നങ്ങൾ തുടരുന്നു.

എല്ലാം തികഞ്ഞതായിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ കൂടുതൽ കയറുന്നു. ഞങ്ങൾ ഇന്റർനെറ്റിൽ ഒരു രസകരമായ ക്രമീകരണം കണ്ടെത്തി - hot_standby_feedback. നമുക്ക് അത് ഓണാക്കാം. Hot_standby_feedback ഞങ്ങളെ മാസ്റ്ററിലെ ഓട്ടോവാക്വം തടഞ്ഞുനിർത്താൻ അനുവദിക്കുന്നു. അങ്ങനെ, ഞങ്ങൾ ആവർത്തന വൈരുദ്ധ്യങ്ങളിൽ നിന്ന് പൂർണ്ണമായും മുക്തി നേടുന്നു. റിപ്പോർട്ടുകൾക്കൊപ്പം എല്ലാം ഞങ്ങൾക്ക് നന്നായി പ്രവർത്തിക്കുന്നു.

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

പ്രത്യേകിച്ചും, ഞങ്ങളുടെ പ്ലേറ്റിൽ നിന്ന്, അതിലെ ഡാറ്റ അപ്‌ഡേറ്റും ആകാശത്തേക്ക് കുതിച്ചതായി ഞങ്ങൾ കാണുന്നു. സിപിയു ഉപഭോഗം സമാനമായി വളരെയധികം വർദ്ധിച്ചു. നിർജ്ജീവവും ഉപയോഗശൂന്യവുമായ നിരവധി വരികളിലൂടെ നാം വീണ്ടും കടന്നുപോകുന്നു. ഈ ചിഹ്നത്തിനായുള്ള പ്രതികരണ സമയവും ഇടപാടുകളുടെ എണ്ണവും കുറഞ്ഞു.

ഞാൻ മുമ്പ് എന്താണ് സംസാരിച്ചതെന്ന് ഞങ്ങൾക്ക് അറിയില്ലെങ്കിൽ അത് എങ്ങനെയിരിക്കും?

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

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

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

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

എന്തായാലും, ആദ്യ കേസിലെന്നപോലെ, ഒന്നര മുതൽ രണ്ട് മടങ്ങ് വരെ, ചിലപ്പോൾ അതിൽ കൂടുതലും ഞങ്ങൾക്ക് ഒരു പെർഫോമൻസ് ഡ്രോഡൗൺ ലഭിക്കും.

ഞങ്ങൾ എല്ലാം ശരിയായി ചെയ്തുവെന്ന് തോന്നുന്നു. ലോഡ് വിതരണം ചെയ്യുക. ഉപകരണങ്ങൾ നിഷ്ക്രിയമല്ല. ഞങ്ങൾ അഭ്യർത്ഥനകൾ ഞങ്ങളുടെ മനസ്സിന് അനുസരിച്ച് വിഭജിച്ചു, പക്ഷേ അപ്പോഴും എല്ലാം മോശമായി.

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

അതേ രീതിയിൽ ഞങ്ങൾ അനന്തരഫലങ്ങൾ ഇല്ലാതാക്കുന്നു:

• വീർത്ത മേശകൾ ഞങ്ങൾ കണ്ടെത്തുന്നു.
• ഞങ്ങൾക്ക് അനുയോജ്യമായ ഏറ്റവും സൗകര്യപ്രദമായ ഉപകരണം ഉപയോഗിച്ച് ഞങ്ങൾ ഇത് കംപ്രസ് ചെയ്യുന്നു.

രണ്ടാമത്തെ കഥ ഇവിടെ അവസാനിക്കുന്നു. നമുക്ക് മൂന്നാമത്തെ കഥയിലേക്ക് കടക്കാം.

നമ്മൾ മൈഗ്രേഷൻ നടത്തുന്നതും വളരെ സാധാരണമാണ്.

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

നിങ്ങളുടെ മുന്നിൽ അവതരിപ്പിച്ചിരിക്കുന്ന അപ്‌ഡേറ്റ് ഉള്ള മൈഗ്രേഷൻ ഇതാ. ഇത് എന്റെ അക്കൗണ്ട് ഇടപാടുകൾ ആയതിനാൽ, പ്ലേറ്റ് 15 ജിബി ആയിരുന്നു. ഞങ്ങൾ ഓരോ വരിയും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനാൽ, അപ്‌ഡേറ്റിനൊപ്പം ഞങ്ങൾ പട്ടികയുടെ വലുപ്പം ഇരട്ടിയാക്കി, കാരണം ഞങ്ങൾ ഓരോ വരിയും മാറ്റിയെഴുതി.

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

ആദ്യ കഥയിൽ ഞാൻ സൂചിപ്പിച്ച ഉപകരണങ്ങളെക്കുറിച്ച് ഇപ്പോൾ കുറച്ചുകൂടി വിശദമായി.

ബ്ലോട്ടിനായി തിരയുന്നതിന് മുമ്പ്, നിങ്ങൾ വിപുലീകരണം ഇൻസ്റ്റാൾ ചെയ്യണം pgstattuple.

അതിനാൽ നിങ്ങൾ ചോദ്യങ്ങളുമായി വരേണ്ടതില്ല, ഞങ്ങളുടെ ജോലിയിൽ ഈ ചോദ്യങ്ങൾ ഞങ്ങൾ ഇതിനകം എഴുതിയിട്ടുണ്ട്. നിങ്ങൾക്ക് അവ ഉപയോഗിക്കാം. ഇവിടെ രണ്ട് അപേക്ഷകൾ ഉണ്ട്.

• ആദ്യത്തേത് പ്രവർത്തിക്കാൻ വളരെ സമയമെടുക്കും, പക്ഷേ ഇത് പട്ടികയിൽ നിന്ന് കൃത്യമായ ബ്ലോട്ട് മൂല്യങ്ങൾ കാണിക്കും.
• രണ്ടാമത്തേത് വേഗത്തിൽ പ്രവർത്തിക്കുന്നു, പട്ടിക അനുസരിച്ച് ഒരു ബ്ലാറ്റ് ഉണ്ടോ ഇല്ലയോ എന്ന് നിങ്ങൾ വേഗത്തിൽ വിലയിരുത്തേണ്ടിവരുമ്പോൾ വളരെ ഫലപ്രദമാണ്. പോസ്‌റ്റ്‌ഗ്രെസ് ടേബിളിൽ ബ്ലോട്ട് എപ്പോഴും ഉണ്ടെന്നും നിങ്ങൾ മനസ്സിലാക്കണം. ഇത് അതിന്റെ 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 - ഇത് എന്റെ സഹപ്രവർത്തകനിൽ നിന്നുള്ള ഒരു റിപ്പോർട്ടാണ്. പോസ്റ്റ്‌ഗ്രേസിന്റെ ജോലിയിലും ജീവിതത്തിലും ഇടം എവിടെ പോകുന്നു എന്നത് പൊതുവായ കാര്യമാണ്. ബ്ലോട്ടിനെക്കുറിച്ച് ഡാറ്റാബേസ് അഡ്മിനിസ്ട്രേറ്റർമാർക്കായി വളരെ വലുതും വിശദവുമായ ഒരു സാങ്കേതിക ഭാഗം ഉണ്ട്.
• https://github.com/dataegret/pg-utils - ഇത് ഞങ്ങളുടെ റിപ്പോസിറ്ററിയിലേക്കുള്ള ഒരു ലിങ്കാണ്, ഡാറ്റാബേസിന്റെ അവസ്ഥ പരിശോധിക്കുന്നതിനായി ഞങ്ങൾ ഉപയോഗപ്രദമായ ഒരു കൂട്ടം സ്ക്രിപ്റ്റുകൾ സംഭരിക്കുന്നു. അവിടെ നിങ്ങൾക്ക് ബ്ലോട്ട് തിരയാൻ സ്ക്രിപ്റ്റുകൾ കണ്ടെത്താം.
• മൂന്നാമത് и നാലാമത്തെ അടയാളങ്ങൾ ചുരുക്കാൻ നിങ്ങളെ സഹായിക്കുന്ന ടൂളുകളിലേക്കുള്ള ലിങ്കുകൾ.
• 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 വരികൾ ഇല്ലാതാക്കുന്നില്ല. അദ്ദേഹത്തിന് അത്തരമൊരു പ്രത്യേകതയുണ്ട്. ഞങ്ങൾ ഒരു ലൈൻ അപ്‌ഡേറ്റ് ചെയ്‌താൽ, പഴയത് ഇല്ലാതാക്കിയതായി ഞങ്ങൾ അടയാളപ്പെടുത്തി. ഈ ലൈൻ മാറ്റിയ ഇടപാടിന്റെ ഐഡി അവിടെ ദൃശ്യമാകുന്നു, ഞങ്ങൾ ഒരു പുതിയ വരി എഴുതുന്നു. അവ വായിക്കാൻ സാധ്യതയുള്ള സെഷനുകളും ഞങ്ങൾക്കുണ്ട്. ചില സമയങ്ങളിൽ അവർ വളരെ പ്രായപൂർത്തിയാകും. ഓട്ടോവാക്വം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ സാരം, അത് ഈ വരികളിലൂടെ കടന്നുപോകുകയും അവയെ അനാവശ്യമായി അടയാളപ്പെടുത്തുകയും ചെയ്യുന്നു എന്നതാണ്. നിങ്ങൾക്ക് അവിടെ ഡാറ്റ പുനരാലേഖനം ചെയ്യാം.

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

ഇല്ല, ഏത് സാഹചര്യത്തിലും മുഴുവൻ വരിയും അവിടെ അപ്ഡേറ്റ് ചെയ്യുന്നു. പോസ്റ്റ്ഗ്രേസിന് രണ്ട് ഡാറ്റ സ്റ്റോറേജ് മോഡലുകളുണ്ട്. ഇത് ഡാറ്റ തരത്തിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നു. പട്ടികയിൽ നേരിട്ട് സംഭരിച്ചിരിക്കുന്ന ഡാറ്റയുണ്ട്, കൂടാതെ ടോസ് ഡാറ്റയും ഉണ്ട്. ഇവ വലിയ അളവിലുള്ള ഡാറ്റയാണ്: ടെക്സ്റ്റ്, json. അവ പ്രത്യേക പ്ലേറ്റുകളിൽ സൂക്ഷിക്കുന്നു. ഈ ടാബ്‌ലെറ്റുകൾ അനുസരിച്ച്, വയറുമായി ഒരേ കഥ സംഭവിക്കുന്നു, അതായത് എല്ലാം ഒന്നുതന്നെയാണ്. അവ വെവ്വേറെ പട്ടികപ്പെടുത്തിയിരിക്കുന്നു.

റിപ്പോർട്ടിന് നന്ദി! ദൈർഘ്യം പരിമിതപ്പെടുത്താൻ സ്റ്റേറ്റ്മെന്റ് ടൈംഔട്ട് ചോദ്യങ്ങൾ ഉപയോഗിക്കുന്നത് സ്വീകാര്യമാണോ?

വളരെ സ്വീകാര്യം. ഞങ്ങൾ ഇത് എല്ലായിടത്തും ഉപയോഗിക്കുന്നു. ഞങ്ങൾക്ക് സ്വന്തമായി സേവനങ്ങൾ ഇല്ലാത്തതിനാൽ, ഞങ്ങൾ വിദൂര പിന്തുണ നൽകുന്നു, ഞങ്ങൾക്ക് വൈവിധ്യമാർന്ന ക്ലയന്റുകൾ ഉണ്ട്. കൂടാതെ എല്ലാവരും ഇതിൽ പൂർണ്ണ സംതൃപ്തരാണ്. അതായത്, പരിശോധിക്കുന്ന ക്രോൺ ജോലികൾ ഞങ്ങൾക്കുണ്ട്. സെഷനുകളുടെ ദൈർഘ്യം ക്ലയന്റുമായി യോജിച്ചതാണ്, അതിന് മുമ്പ് ഞങ്ങൾ അംഗീകരിക്കുന്നില്ല. ഇത് ഒരു മിനിറ്റായിരിക്കാം, അത് 10 മിനിറ്റായിരിക്കാം. ഇത് അടിത്തറയിലെ ലോഡിനെയും അതിന്റെ ഉദ്ദേശ്യത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. എന്നാൽ നമ്മൾ എല്ലാവരും pg_stat_activity ഉപയോഗിക്കുന്നു.

റിപ്പോർട്ടിന് നന്ദി! നിങ്ങളുടെ റിപ്പോർട്ട് എന്റെ അപേക്ഷകളിൽ പ്രയോഗിക്കാൻ ഞാൻ ശ്രമിക്കുന്നു. ഞങ്ങൾ എല്ലായിടത്തും ഒരു ഇടപാട് ആരംഭിക്കുകയും എല്ലായിടത്തും അത് വ്യക്തമായി പൂർത്തിയാക്കുകയും ചെയ്യുന്നതുപോലെ തോന്നുന്നു. ചില ഒഴിവാക്കലുകൾ ഉണ്ടെങ്കിൽ, റോൾബാക്ക് ഇപ്പോഴും സംഭവിക്കുന്നു. പിന്നെ ഞാൻ ആലോചിക്കാൻ തുടങ്ങി. എല്ലാത്തിനുമുപരി, ഇടപാട് വ്യക്തമായി ആരംഭിച്ചേക്കില്ല. ഇത് പെൺകുട്ടിക്ക് ഒരു സൂചനയായിരിക്കാം. ഞാൻ ഒരു റെക്കോർഡ് അപ്‌ഡേറ്റ് ചെയ്‌താൽ, ഇടപാട് PostgreSQL-ൽ ആരംഭിക്കുകയും കണക്ഷൻ വിച്ഛേദിക്കുമ്പോൾ മാത്രം പൂർത്തിയാകുകയും ചെയ്യുമോ?

നിങ്ങൾ ഇപ്പോൾ ആപ്ലിക്കേഷൻ ലെവലിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, അത് നിങ്ങൾ ഉപയോഗിക്കുന്ന ORM-നെ ആശ്രയിച്ചിരിക്കുന്നു. അവിടെ ഒരുപാട് ക്രമീകരണങ്ങൾ ഉണ്ട്. നിങ്ങൾക്ക് സ്വയമേവയുള്ള കമ്മിറ്റ് ഓൺ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ, ഒരു ഇടപാട് അവിടെ ആരംഭിക്കുകയും ഉടനടി ക്ലോസ് ചെയ്യുകയും ചെയ്യും.

അതായത്, അപ്‌ഡേറ്റ് ചെയ്‌ത ഉടൻ തന്നെ ഇത് അടയ്ക്കുമോ?

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

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! വീക്കവും വീക്കവും ഉള്ള ഒരു ഡാറ്റാബേസ് നമുക്കുണ്ടെന്ന് സങ്കൽപ്പിക്കുക, തുടർന്ന് സെർവറിലെ ഇടം തീർന്നു. ഈ സാഹചര്യം പരിഹരിക്കാൻ എന്തെങ്കിലും ഉപകരണങ്ങൾ ഉണ്ടോ?

സെർവറിലെ ഇടം ശരിയായി നിരീക്ഷിക്കേണ്ടതുണ്ട്.

ഉദാഹരണത്തിന്, DBA ചായ കുടിക്കാൻ പോയി, ഒരു റിസോർട്ടിൽ ആയിരുന്നു, മുതലായവ.

ഒരു ഫയൽ സിസ്റ്റം സൃഷ്‌ടിക്കുമ്പോൾ, ഡാറ്റ എഴുതാത്തിടത്ത് കുറഞ്ഞത് ഒരുതരം ബാക്കപ്പ് സ്‌പെയ്‌സ് സൃഷ്‌ടിക്കുന്നു.

ഇത് പൂർണ്ണമായും പൂജ്യത്തിന് താഴെ ആണെങ്കിലോ?

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

മറ്റെന്തെങ്കിലും ഉപകരണങ്ങൾ ഉണ്ടോ?

ഇത് എല്ലായ്പ്പോഴും കൈകൊണ്ട് നിർമ്മിച്ചതാണ്. പ്രാദേശികമായി അവിടെ എന്താണ് ചെയ്യേണ്ടതെന്ന് വ്യക്തമാകും, കാരണം ചില ഡാറ്റ നിർണായകവും ചിലത് നിർണ്ണായകമല്ലാത്തതുമാണ്. ഓരോ ഡാറ്റാബേസിനും അതിനോടൊപ്പം പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനും, അത് ബിസിനസിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഇത് എല്ലായ്പ്പോഴും പ്രാദേശികമായി തീരുമാനിക്കപ്പെടുന്നു.

റിപ്പോർട്ടിന് നന്ദി! എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. ആദ്യം, ഇടപാടുകൾ തടസ്സപ്പെടുമ്പോൾ, ടേബിൾസ്‌പേസിന്റെ വലുപ്പവും സൂചിക വലുപ്പവും വർദ്ധിക്കുന്നുവെന്ന് കാണിക്കുന്ന സ്ലൈഡുകൾ നിങ്ങൾ കാണിച്ചു. റിപ്പോർട്ടിൽ ടാബ്‌ലെറ്റ് പാക്കേജ് ചെയ്യുന്ന ഒരു കൂട്ടം യൂട്ടിലിറ്റികൾ ഉണ്ടായിരുന്നു. സൂചികയെ സംബന്ധിച്ചെന്ത്?

അവരും പാക്ക് ചെയ്യുന്നു.

എന്നാൽ വാക്വം സൂചികയെ ബാധിക്കില്ലേ?

ചിലത് ഒരു സൂചിക ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു. ഉദാഹരണത്തിന്, pg_rapack, pgcompactable. വാക്വം സൂചികകളെ പുനർനിർമ്മിക്കുകയും അവയെ ബാധിക്കുകയും ചെയ്യുന്നു. VACUUM FULL ഉപയോഗിച്ച് എല്ലാം തിരുത്തിയെഴുതുക എന്നതാണ് ആശയം, അതായത് ഇത് എല്ലാവരുമായും പ്രവർത്തിക്കുന്നു.

പിന്നെ രണ്ടാമത്തെ ചോദ്യവും. തനിപ്പകർപ്പുകളെക്കുറിച്ചുള്ള റിപ്പോർട്ടുകൾ തനിപ്പകർപ്പിനെത്തന്നെ ആശ്രയിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് എനിക്ക് മനസ്സിലാകുന്നില്ല. റിപ്പോർട്ടുകൾ വായിക്കുന്നു, പകർപ്പ് എഴുതുന്നു എന്ന് എനിക്ക് തോന്നി.

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

ആൻഡ്രി, എനിക്കൊരു ചോദ്യമുണ്ട്. അവതരണ വേളയിൽ നിങ്ങൾ കാണിച്ച ഈ അത്ഭുതകരമായ ഗ്രാഫുകൾ, ഇത് നിങ്ങളുടെ ഏതെങ്കിലും തരത്തിലുള്ള ഉപയോഗത്തിന്റെ ഫലമാണോ? ഗ്രാഫുകൾ എങ്ങനെയാണ് നിർമ്മിച്ചത്?

ഇതൊരു സേവനമാണ് ഒക്മീറ്റർ.

ഇതൊരു വാണിജ്യ ഉൽപ്പന്നമാണോ?

അതെ. ഇതൊരു വാണിജ്യ ഉൽപ്പന്നമാണ്.

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