ഇല്യ കോസ്മോഡെമിയൻസ്കിയുടെ 2015 റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് "PostgreSQL പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനുള്ള ലിനക്സ് ട്യൂണിംഗ്"
നിരാകരണം: ഈ റിപ്പോർട്ട് നവംബർ 2015-ലാണെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു - 4 വർഷത്തിലേറെ കടന്നുപോയി, ഒരുപാട് സമയം കടന്നുപോയി. റിപ്പോർട്ടിൽ ചർച്ച ചെയ്ത പതിപ്പ് 9.4 ഇപ്പോൾ പിന്തുണയ്ക്കില്ല. കഴിഞ്ഞ 4 വർഷത്തിനിടയിൽ, PostgreSQL-ന്റെ 5 പുതിയ പതിപ്പുകൾ പുറത്തിറങ്ങി, ലിനക്സ് കേർണലിന്റെ 15 പതിപ്പുകൾ പുറത്തിറങ്ങി. നിങ്ങൾ ഈ ഖണ്ഡികകൾ മാറ്റിയെഴുതുകയാണെങ്കിൽ, നിങ്ങൾക്ക് മറ്റൊരു റിപ്പോർട്ടിൽ ലഭിക്കും. എന്നാൽ ഇവിടെ ഞങ്ങൾ PostgreSQL-നുള്ള അടിസ്ഥാന ലിനക്സ് ട്യൂണിംഗ് പരിഗണിക്കുന്നു, അത് ഇന്നും പ്രസക്തമാണ്.
എന്റെ പേര് ഇല്യ കോസ്മോഡെമിയൻസ്കി. ഞാൻ PostgreSQL-കൺസൾട്ടിങ്ങിൽ ജോലി ചെയ്യുന്നു. പൊതുവെ ഡാറ്റാബേസുകളുമായും പ്രത്യേകിച്ച് PostgreSQL യുമായും ബന്ധപ്പെട്ട് Linux-ൽ എന്തുചെയ്യണമെന്നതിനെക്കുറിച്ച് ഇപ്പോൾ ഞാൻ കുറച്ച് സംസാരിക്കും, കാരണം തത്വങ്ങൾ തികച്ചും സമാനമാണ്.
നമ്മൾ എന്തിനെ കുറിച്ച് സംസാരിക്കും? നിങ്ങൾ PostgreSQL-മായി ആശയവിനിമയം നടത്തുകയാണെങ്കിൽ, ഒരു പരിധിവരെ നിങ്ങൾ ഒരു UNIX അഡ്മിൻ ആയിരിക്കണം. എന്താണ് ഇതിനർത്ഥം? നമ്മൾ Oracle ഉം PostgreSQL ഉം താരതമ്യം ചെയ്യുകയാണെങ്കിൽ, Oracle-ൽ നിങ്ങൾ 80% DBA ഡാറ്റാബേസ് അഡ്മിനും 20% Linux അഡ്മിനും ആയിരിക്കണം.
PostgreSQL ഉപയോഗിച്ച് ഇത് കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. PostgreSQL ഉപയോഗിച്ച് നിങ്ങൾക്ക് Linux എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് കൂടുതൽ നന്നായി മനസ്സിലാക്കേണ്ടതുണ്ട്. അതേ സമയം, ലോക്കോമോട്ടീവിന് ശേഷം കുറച്ച് ഓടുക, കാരണം ഈയിടെ എല്ലാം വളരെ മനോഹരമായി അപ്‌ഡേറ്റ് ചെയ്തിട്ടുണ്ട്. പുതിയ കേർണലുകൾ പുറത്തിറങ്ങി, പുതിയ പ്രവർത്തനം ദൃശ്യമാകുന്നു, പ്രകടനം മെച്ചപ്പെടുന്നു തുടങ്ങിയവ.
എന്തുകൊണ്ടാണ് നമ്മൾ ലിനക്സിനെക്കുറിച്ച് സംസാരിക്കുന്നത്? ഞങ്ങൾ ലിനക്സ് കോൺഫറൻസ് പീറ്ററിൽ ഉള്ളതുകൊണ്ടല്ല, ആധുനിക സാഹചര്യങ്ങളിൽ പൊതുവായി ഡാറ്റാബേസുകളും PostgreSQL പ്രത്യേകിച്ചും ഉപയോഗിക്കുന്നതിനുള്ള ഏറ്റവും ന്യായമായ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലൊന്നാണ് ലിനക്സ്. കാരണം FreeBSD, നിർഭാഗ്യവശാൽ, വളരെ വിചിത്രമായ ചില ദിശയിലാണ് വികസിക്കുന്നത്. കൂടാതെ പ്രകടനത്തിലും മറ്റ് പല കാര്യങ്ങളിലും പ്രശ്നങ്ങൾ ഉണ്ടാകും. Windows-ലെ PostgreSQL-ന്റെ പ്രകടനം പൊതുവെ ഗുരുതരമായ ഒരു പ്രശ്നമാണ്, Windows-ന് UNIX-ന്റെ അതേ പങ്കിട്ട മെമ്മറി ഇല്ല എന്ന വസ്തുതയെ അടിസ്ഥാനമാക്കി, PostgreSQL എല്ലാം ഇതുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, കാരണം ഇത് ഒരു മൾട്ടി-പ്രോസസ് സിസ്റ്റമാണ്.
എല്ലാവർക്കും സോളാരിസ് പോലുള്ള എക്സോട്ടിക്‌സിനോട് താൽപ്പര്യം കുറവാണെന്ന് ഞാൻ കരുതുന്നു, അതിനാൽ നമുക്ക് പോകാം.
ഒരു ആധുനിക ലിനക്സ് വിതരണത്തിന് 1 syctl ഓപ്ഷനുകൾ ഉണ്ട്, നിങ്ങൾ എങ്ങനെ കേർണൽ നിർമ്മിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. അതേസമയം, വ്യത്യസ്തമായ അണ്ടിപ്പരിപ്പ് നോക്കിയാൽ, നമുക്ക് പല രീതിയിൽ ക്രമീകരിക്കാൻ കഴിയും. അവ എങ്ങനെ മൌണ്ട് ചെയ്യണമെന്നതിനുള്ള ഫയൽ സിസ്റ്റം പാരാമീറ്ററുകൾ ഉണ്ട്. ഇത് എങ്ങനെ ആരംഭിക്കാം എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ചോദ്യങ്ങളുണ്ടെങ്കിൽ: ബയോസിൽ എന്താണ് പ്രവർത്തനക്ഷമമാക്കേണ്ടത്, ഹാർഡ്‌വെയർ എങ്ങനെ ക്രമീകരിക്കാം തുടങ്ങിയവ.
ഇത് ഒരു ചെറിയ റിപ്പോർട്ടിലല്ല, കുറച്ച് ദിവസങ്ങളിലായി ചർച്ച ചെയ്യാവുന്ന വളരെ വലിയ വോളിയമാണ്, എന്നാൽ ഇപ്പോൾ ഞാൻ പ്രധാനപ്പെട്ട കാര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും, നിങ്ങൾ ലിനക്സിൽ നിങ്ങളുടെ ഡാറ്റാബേസ് നന്നായി ഉപയോഗിക്കുന്നതിൽ നിന്ന് നിങ്ങളെ തടയുമെന്ന് ഉറപ്പുനൽകുന്ന ആ റേക്കുകൾ എങ്ങനെ ഒഴിവാക്കാം അവരെ തിരുത്തരുത്. അതേ സമയം, ഡാറ്റാബേസിന് അനുയോജ്യമായ ക്രമീകരണങ്ങളിൽ പല സ്ഥിരസ്ഥിതി പാരാമീറ്ററുകളും ഉൾപ്പെടുത്തിയിട്ടില്ല എന്നതാണ് ഒരു പ്രധാന കാര്യം. അതായത്, സ്ഥിരസ്ഥിതിയായി ഇത് മോശമായി പ്രവർത്തിക്കും അല്ലെങ്കിൽ ഇല്ല.
ലിനക്സിൽ പരമ്പരാഗത ട്യൂണിംഗ് ലക്ഷ്യങ്ങൾ എന്തൊക്കെയാണ്? നിങ്ങളെല്ലാം ലിനക്സ് അഡ്മിനിസ്ട്രേഷനുമായി ഇടപെടുന്നതിനാൽ, ടാർഗെറ്റുകൾ എന്താണെന്ന് വിശദീകരിക്കേണ്ട ആവശ്യമില്ലെന്ന് ഞാൻ കരുതുന്നു.
നിങ്ങൾക്ക് ട്യൂൺ ചെയ്യാൻ കഴിയും:
- സിപിയു.
- മെമ്മറി.
- സംഭരണം.
- മറ്റുള്ളവ. ലഘുഭക്ഷണത്തിനായി ഞങ്ങൾ ഇതിനെക്കുറിച്ച് അവസാനം സംസാരിക്കും. ഉദാഹരണത്തിന്, ഊർജ്ജ സംരക്ഷണ നയം പോലുള്ള പാരാമീറ്ററുകൾ പോലും വളരെ പ്രവചനാതീതമായ രീതിയിൽ പ്രകടനത്തെ ബാധിക്കും.
PostgreSQL-ന്റെയും പൊതുവായ ഡാറ്റാബേസിന്റെയും പ്രത്യേകതകൾ എന്തൊക്കെയാണ്? നിങ്ങൾക്ക് ഒരു വ്യക്തിഗത നട്ട് മാറ്റാനും ഞങ്ങളുടെ പ്രകടനം ഗണ്യമായി മെച്ചപ്പെട്ടതായി കാണാനും കഴിയില്ല എന്നതാണ് പ്രശ്നം.
അതെ, അത്തരം ഗാഡ്‌ജെറ്റുകൾ ഉണ്ട്, പക്ഷേ ഒരു ഡാറ്റാബേസ് ഒരു സങ്കീർണ്ണ കാര്യമാണ്. സെർവറിന് ഉള്ള എല്ലാ ഉറവിടങ്ങളുമായും ഇത് സംവദിക്കുകയും പരമാവധി സംവദിക്കാൻ താൽപ്പര്യപ്പെടുകയും ചെയ്യുന്നു. ഒരു ഹോസ്റ്റ് ഒഎസ് എങ്ങനെ ഉപയോഗിക്കാമെന്നതിനെക്കുറിച്ചുള്ള ഒറാക്കിളിന്റെ നിലവിലെ ശുപാർശകൾ നിങ്ങൾ നോക്കുകയാണെങ്കിൽ, അത് ആ മംഗോളിയൻ ബഹിരാകാശയാത്രികനെക്കുറിച്ചുള്ള തമാശ പോലെയാകും - നായയ്ക്ക് ഭക്ഷണം നൽകുക, ഒന്നും തൊടരുത്. ഡാറ്റാബേസിന് എല്ലാ ഉറവിടങ്ങളും നൽകാം, ഡാറ്റാബേസ് തന്നെ എല്ലാം ക്രമീകരിക്കും.
തത്വത്തിൽ, ഒരു പരിധിവരെ, PostgreSQL ന്റെ സ്ഥിതിയും സമാനമാണ്. ഡാറ്റാബേസിന് ഇതുവരെ എല്ലാ ഉറവിടങ്ങളും സ്വയം എടുക്കാൻ കഴിഞ്ഞിട്ടില്ല എന്നതാണ് വ്യത്യാസം, അതായത് ലിനക്സ് തലത്തിൽ എവിടെയെങ്കിലും നിങ്ങൾ സ്വയം എല്ലാം ക്രമീകരിക്കേണ്ടതുണ്ട്.
ഒരൊറ്റ ടാർഗെറ്റ് തിരഞ്ഞെടുത്ത് അത് ട്യൂൺ ചെയ്യാൻ ആരംഭിക്കുക എന്നതാണ് പ്രധാന ആശയം, ഉദാഹരണത്തിന്, മെമ്മറി, സിപിയു അല്ലെങ്കിൽ അതുപോലുള്ള മറ്റെന്തെങ്കിലും, പക്ഷേ ജോലിഭാരം വിശകലനം ചെയ്ത് ത്രൂപുട്ട് കഴിയുന്നത്ര മെച്ചപ്പെടുത്താൻ ശ്രമിക്കുക, അങ്ങനെ നല്ല പ്രോഗ്രാമർമാർ അത് സൃഷ്ടിച്ച ലോഡ്. ഞങ്ങളുടെ ഉപയോക്താക്കൾ ഉൾപ്പെടെ ഞങ്ങൾക്കായി.
അതെന്താണെന്ന് വിശദീകരിക്കാൻ ഇതാ ഒരു ചിത്രം. ഒരു Linux OS ബഫറും പങ്കിട്ട മെമ്മറിയും ഉണ്ട്, PostgreSQL പങ്കിട്ട ബഫറുകളും ഉണ്ട്. PostgreSQL, Oracle-ൽ നിന്ന് വ്യത്യസ്തമായി, കേർണൽ ബഫറിലൂടെ മാത്രമേ നേരിട്ട് പ്രവർത്തിക്കൂ, അതായത്, ഡിസ്കിൽ നിന്നുള്ള ഒരു പേജ് അതിന്റെ പങ്കിട്ട മെമ്മറിയിൽ പ്രവേശിക്കുന്നതിന്, അത് കേർണൽ ബഫറിലൂടെയും തിരിച്ചും പോകണം, കൃത്യമായ സാഹചര്യം.
ഡിസ്കുകൾ ഈ സിസ്റ്റത്തിന് കീഴിലാണ് ജീവിക്കുന്നത്. ഞാൻ ഇത് ഡിസ്കുകളായി വരച്ചു. വാസ്തവത്തിൽ, ഒരു റെയിഡ് കൺട്രോളർ മുതലായവ ഉണ്ടായിരിക്കാം.
ഈ ഇൻപുട്ട്-ഔട്ട്പുട്ട് ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്ന് ഈ വിഷയത്തിലൂടെ സംഭവിക്കുന്നു.
PostgreSQL ഒരു ക്ലാസിക് ഡാറ്റാബേസാണ്. അകത്ത് ഒരു പേജുണ്ട്. കൂടാതെ എല്ലാ ഇൻപുട്ടും ഔട്ട്പുട്ടും പേജുകൾ ഉപയോഗിച്ചാണ് സംഭവിക്കുന്നത്. ഞങ്ങൾ ബ്ലോക്കുകൾ പേജുകൾ ഉപയോഗിച്ച് മെമ്മറിയിലേക്ക് ഉയർത്തുകയാണ്. ഒന്നും സംഭവിച്ചില്ലെങ്കിൽ, ഞങ്ങൾ അവ വായിക്കുന്നു, പിന്നീട് അവ ഈ കാഷെയിൽ നിന്നും പങ്കിട്ട ബഫറുകളിൽ നിന്നും അപ്രത്യക്ഷമാവുകയും വീണ്ടും ഡിസ്കിൽ അവസാനിക്കുകയും ചെയ്യും.
നമ്മൾ എവിടെയെങ്കിലും എന്തെങ്കിലും മാറ്റിസ്ഥാപിക്കുകയാണെങ്കിൽ, പേജ് മുഴുവൻ വൃത്തികെട്ടതായി അടയാളപ്പെടുത്തും. ഞാൻ അവ ഇവിടെ നീല നിറത്തിൽ അടയാളപ്പെടുത്തി. ഇതിനർത്ഥം ഈ പേജ് ബ്ലോക്ക് സ്റ്റോറേജുമായി സമന്വയിപ്പിച്ചിരിക്കണം എന്നാണ്. അതായത്, ഞങ്ങൾ അത് വൃത്തികെട്ടതാക്കിയപ്പോൾ, ഞങ്ങൾ WAL-ൽ ഒരു എൻട്രി നടത്തി. ഒരു അത്ഭുതകരമായ നിമിഷത്തിൽ, ചെക്ക് പോയിന്റ് എന്ന ഒരു പ്രതിഭാസം വന്നു. ഒപ്പം എത്തിയ വിവരം ഈ രേഖയിൽ രേഖപ്പെടുത്തിയിരുന്നു. ഇതിനർത്ഥം, ഈ പങ്കിട്ട ബഫറുകളിൽ ആ നിമിഷം ഇവിടെ ഉണ്ടായിരുന്ന എല്ലാ വൃത്തികെട്ട പേജുകളും കേർണൽ ബഫറിലൂടെ fsync ഉപയോഗിച്ച് സ്റ്റോറേജ് ഡിസ്കുമായി സമന്വയിപ്പിച്ചു എന്നാണ്.
എന്തുകൊണ്ടാണ് ഇത് ചെയ്യുന്നത്? നമുക്ക് വോൾട്ടേജ് നഷ്ടപ്പെട്ടാൽ, എല്ലാ ഡാറ്റയും നഷ്ടപ്പെടുന്ന സാഹചര്യം ഞങ്ങൾക്ക് ലഭിച്ചില്ല. എല്ലാവരും ഞങ്ങളോട് പറഞ്ഞ സ്ഥിരമായ മെമ്മറി ഇതുവരെ ഡാറ്റാബേസ് സിദ്ധാന്തത്തിലാണ് - ഇതൊരു ശോഭനമായ ഭാവിയാണ്, ഞങ്ങൾ തീർച്ചയായും പരിശ്രമിക്കുകയും ഞങ്ങൾ അത് ഇഷ്ടപ്പെടുകയും ചെയ്യുന്നു, പക്ഷേ ഇപ്പോൾ അവർ മൈനസ് 20 വർഷത്തിലാണ് ജീവിക്കുന്നത്. കൂടാതെ, തീർച്ചയായും, ഇതെല്ലാം നിരീക്ഷിക്കേണ്ടതുണ്ട്.
ത്രൂപുട്ട് പരമാവധിയാക്കുന്നതിനുള്ള ചുമതല ഈ ഘട്ടങ്ങളിലെല്ലാം നന്നായി ട്യൂൺ ചെയ്യുക എന്നതാണ്, അങ്ങനെ എല്ലാം വേഗത്തിൽ അങ്ങോട്ടും ഇങ്ങോട്ടും നീങ്ങുന്നു. പങ്കിട്ട മെമ്മറി അടിസ്ഥാനപരമായി ഒരു പേജ് കാഷെയാണ്. PostgreSQL-ൽ ഞങ്ങൾ ഒരു തിരഞ്ഞെടുത്ത ചോദ്യം അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും അയച്ചു, അത് ഡിസ്കിൽ നിന്ന് ഈ ഡാറ്റ വീണ്ടെടുത്തു. അവ പങ്കിട്ട ബഫറുകളിൽ അവസാനിച്ചു. അതനുസരിച്ച്, ഇത് നന്നായി പ്രവർത്തിക്കാൻ, ധാരാളം മെമ്മറി ഉണ്ടായിരിക്കണം.
ഇതെല്ലാം മികച്ചതും വേഗത്തിലും പ്രവർത്തിക്കുന്നതിന്, നിങ്ങൾ എല്ലാ ഘട്ടങ്ങളിലും ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ശരിയായി ക്രമീകരിക്കേണ്ടതുണ്ട്. സമതുലിതമായ ഹാർഡ്‌വെയർ തിരഞ്ഞെടുക്കുക, കാരണം നിങ്ങൾക്ക് എവിടെയെങ്കിലും അസന്തുലിതാവസ്ഥ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ധാരാളം മെമ്മറി ഉണ്ടാക്കാൻ കഴിയും, പക്ഷേ അത് മതിയായ വേഗതയിൽ സേവനം നൽകില്ല.
ഈ ഓരോ പോയിന്റുകളിലൂടെയും നമുക്ക് പോകാം.
ഈ പേജുകൾ അങ്ങോട്ടും ഇങ്ങോട്ടും വേഗത്തിൽ സഞ്ചരിക്കാൻ, നിങ്ങൾ ഇനിപ്പറയുന്നവ നേടേണ്ടതുണ്ട്:
- ഒന്നാമതായി, നിങ്ങൾ മെമ്മറി ഉപയോഗിച്ച് കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കേണ്ടതുണ്ട്.
- രണ്ടാമതായി, മെമ്മറിയിൽ നിന്നുള്ള പേജുകൾ ഡിസ്കിലേക്ക് പോകുമ്പോൾ ഈ പരിവർത്തനം കൂടുതൽ കാര്യക്ഷമമായിരിക്കണം.
- മൂന്നാമതായി, നല്ല ഡിസ്കുകൾ ഉണ്ടായിരിക്കണം.
നിങ്ങൾക്ക് സെർവറിൽ 512 ജിബി റാം ഉണ്ടെങ്കിൽ, അതെല്ലാം ഒരു കാഷെ ഇല്ലാതെ ഒരു SATA ഹാർഡ് ഡ്രൈവിൽ അവസാനിക്കുന്നുവെങ്കിൽ, മുഴുവൻ ഡാറ്റാബേസ് സെർവറും ഒരു മത്തങ്ങ മാത്രമല്ല, SATA ഇന്റർഫേസുള്ള ഒരു മത്തങ്ങയായി മാറുന്നു. നിങ്ങൾ അതിൽ നേരിട്ട് ഓടും. പിന്നെ ഒന്നും നിങ്ങളെ രക്ഷിക്കില്ല.
മെമ്മറിയുമായുള്ള ആദ്യ പോയിന്റിനെ സംബന്ധിച്ചിടത്തോളം, ജീവിതത്തെ വളരെ പ്രയാസകരമാക്കുന്ന മൂന്ന് കാര്യങ്ങളുണ്ട്.
അവയിൽ ആദ്യത്തേത് NUMA ആണ്. പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനായി നിർമ്മിച്ച ഒരു വസ്തുവാണ് NUMA. ജോലിഭാരത്തെ ആശ്രയിച്ച്, വ്യത്യസ്ത കാര്യങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും. അതിന്റെ പുതിയ നിലവിലെ രൂപത്തിൽ, പേജ് കാഷെ പങ്കിട്ട ബഫറുകൾ തീവ്രമായി ഉപയോഗിക്കുന്ന ഡാറ്റാബേസുകൾ പോലുള്ള ആപ്ലിക്കേഷനുകൾക്ക് ഇത് അത്ര നല്ലതല്ല.
ചുരുക്കത്തിൽ. NUMA-യിൽ എന്തെങ്കിലും കുഴപ്പമുണ്ടെങ്കിൽ നിങ്ങൾക്ക് എങ്ങനെ പറയാനാകും? നിങ്ങൾക്ക് ഒരുതരം അസുഖകരമായ മുട്ടുണ്ട്, പെട്ടെന്ന് കുറച്ച് സിപിയു ഓവർലോഡ് ആയി. അതേ സമയം, നിങ്ങൾ PostgreSQL-ലെ ചോദ്യങ്ങൾ വിശകലനം ചെയ്യുകയും അവിടെ സമാനമായി ഒന്നുമില്ലെന്ന് കാണുക. ഈ ചോദ്യങ്ങൾ CPU തീവ്രമായിരിക്കരുത്. നിങ്ങൾക്ക് ഇത് വളരെക്കാലം പിടിക്കാം. PostgreSQL-നായി NUMA എങ്ങനെ കോൺഫിഗർ ചെയ്യാം എന്നതിനെക്കുറിച്ചുള്ള ശരിയായ ശുപാർശ ആദ്യം മുതൽ ഉപയോഗിക്കുന്നത് എളുപ്പമാണ്.
ശരിക്കും എന്താണ് നടക്കുന്നത്? NUMA എന്നാൽ നോൺ-യൂണിഫോം മെമ്മറി ആക്സസ്. കാര്യം എന്തണ്? നിങ്ങൾക്ക് ഒരു സിപിയു ഉണ്ട്, അതിനടുത്തായി അതിന്റെ ലോക്കൽ മെമ്മറി ഉണ്ട്. ഈ മെമ്മറി ഇന്റർകണക്റ്റിന് മറ്റ് CPU-കളിൽ നിന്ന് മെമ്മറി ഉയർത്താൻ കഴിയും.
നിങ്ങൾ ഓടുകയാണെങ്കിൽ numactl --hardware, അപ്പോൾ നിങ്ങൾക്ക് ഇത്രയും വലിയ ഷീറ്റ് ലഭിക്കും. മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, ഒരു ദൂര ഫീൽഡ് ഉണ്ടാകും. അക്കങ്ങൾ ഉണ്ടാകും - 10-20, അത്തരത്തിലുള്ള ഒന്ന്. ഈ നമ്പരുകൾ ഈ വിദൂര മെമ്മറി എടുക്കുന്നതിനും പ്രാദേശികമായി ഉപയോഗിക്കുന്നതിനുമുള്ള ഹോപ്പുകളുടെ എണ്ണമല്ലാതെ മറ്റൊന്നുമല്ല. തത്വത്തിൽ, ഒരു നല്ല ആശയം. ഇത് ജോലിഭാരത്തിന്റെ പരിധിയിൽ മികച്ച പ്രകടനത്തെ വേഗത്തിലാക്കുന്നു.
ഇപ്പോൾ നിങ്ങൾക്ക് ഒരു സിപിയു ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക, ആദ്യം അതിന്റെ ലോക്കൽ മെമ്മറി ഉപയോഗിക്കാൻ ശ്രമിക്കുന്നു, തുടർന്ന് എന്തെങ്കിലും ഇന്റർകണക്റ്റ് വഴി മറ്റൊരു മെമ്മറി ഉയർത്താൻ ശ്രമിക്കുന്നു. ഈ സിപിയുവിന് നിങ്ങളുടെ മുഴുവൻ PostgreSQL പേജ് കാഷെയും ലഭിക്കുന്നു - അത്രയേയുള്ളൂ, കുറച്ച് ജിഗാബൈറ്റുകൾ. നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഏറ്റവും മോശം അവസ്ഥയാണ് ലഭിക്കുന്നത്, കാരണം സിപിയുവിൽ ആ മൊഡ്യൂളിൽ തന്നെ മെമ്മറി കുറവാണ്. കൂടാതെ സർവീസ് ചെയ്യുന്ന എല്ലാ മെമ്മറിയും ഈ പരസ്പര ബന്ധങ്ങളിലൂടെ കടന്നുപോകുന്നു. ഇത് സാവധാനത്തിലും സങ്കടകരമായും മാറുന്നു. ഈ നോഡിന് സേവനം നൽകുന്ന നിങ്ങളുടെ പ്രോസസർ നിരന്തരം ഓവർലോഡ് ചെയ്യപ്പെടുന്നു. ഈ മെമ്മറിയുടെ ആക്സസ് സമയം മോശമാണ്, മന്ദഗതിയിലാണ്. നിങ്ങൾ ഇത് ഒരു ഡാറ്റാബേസിനായി ഉപയോഗിക്കുകയാണെങ്കിൽ നിങ്ങൾക്ക് ആവശ്യമില്ലാത്ത സാഹചര്യമാണിത്.
അതിനാൽ, ലിനക്സ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് അറിയാതിരിക്കുക എന്നതാണ് ഡാറ്റാബേസിനായി കൂടുതൽ ശരിയായ ഓപ്ഷൻ. അങ്ങനെ അത് മെമ്മറി ആക്സസ് ചെയ്യുന്നു.
എന്തുകൊണ്ടാണത്? അത് നേരെ മറിച്ചായിരിക്കണമെന്ന് തോന്നുന്നു. ഒരു ലളിതമായ കാരണത്താലാണ് ഇത് സംഭവിക്കുന്നത്: പേജ് കാഷെക്കായി ഞങ്ങൾക്ക് ധാരാളം മെമ്മറി ആവശ്യമാണ് - പതിനായിരക്കണക്കിന്, നൂറുകണക്കിന് ജിഗാബൈറ്റുകൾ.
ഞങ്ങൾ ഇതെല്ലാം അനുവദിക്കുകയും ഞങ്ങളുടെ ഡാറ്റ അവിടെ കാഷെ ചെയ്യുകയും ചെയ്താൽ, കാഷെ ഉപയോഗിക്കുന്നതിലൂടെ ലഭിക്കുന്ന നേട്ടം മെമ്മറിയിലേക്കുള്ള അത്തരം തന്ത്രപരമായ ആക്‌സസ്സിൽ നിന്നുള്ള നേട്ടത്തേക്കാൾ വളരെ കൂടുതലായിരിക്കും. NUMA ഉപയോഗിച്ച് കൂടുതൽ കാര്യക്ഷമമായി മെമ്മറി ആക്സസ് ചെയ്യുമെന്ന വസ്തുതയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ നമുക്ക് അങ്ങനെ പ്രയോജനം ലഭിക്കും.
അതിനാൽ, ശോഭനമായ ഭാവി വരുന്നതുവരെ ഇപ്പോൾ ഇവിടെ രണ്ട് സമീപനങ്ങളുണ്ട്, കൂടാതെ ഏത് സിപിയുകളിലാണ് ഇത് പ്രവർത്തിക്കുന്നതെന്നും എവിടെ നിന്ന് എന്തെങ്കിലും വലിക്കണമെന്നും ഡാറ്റാബേസിന് തന്നെ കണ്ടെത്താനാവില്ല.
അതിനാൽ, NUMA പൂർണ്ണമായും പ്രവർത്തനരഹിതമാക്കുക എന്നതാണ് ശരിയായ സമീപനം, ഉദാഹരണത്തിന്, റീബൂട്ട് ചെയ്യുമ്പോൾ. മിക്ക കേസുകളിലും, വിജയങ്ങൾ വ്യാപ്തിയുള്ളവയാണ്, ഏതാണ് മികച്ചത് എന്ന ചോദ്യം ഉയർന്നുവരുന്നില്ല.
മറ്റൊരു ഓപ്ഷൻ ഉണ്ട്. ഞങ്ങൾ ഇത് ആദ്യത്തേതിനേക്കാൾ കൂടുതൽ തവണ ഉപയോഗിക്കുന്നു, കാരണം പിന്തുണയ്‌ക്കായി ഒരു ക്ലയന്റ് ഞങ്ങളുടെ അടുത്ത് വരുമ്പോൾ, സെർവർ റീബൂട്ട് ചെയ്യുന്നത് അദ്ദേഹത്തിന് വലിയ കാര്യമാണ്. അയാൾക്ക് അവിടെ ഒരു ബിസിനസ്സ് ഉണ്ട്. NUMA കാരണം അവർ പ്രശ്നങ്ങൾ അനുഭവിക്കുന്നു. അതിനാൽ, റീബൂട്ട് ചെയ്യുന്നതിനേക്കാൾ ആക്രമണാത്മകമല്ലാത്ത രീതിയിൽ ഞങ്ങൾ ഇത് പ്രവർത്തനരഹിതമാക്കാൻ ശ്രമിക്കുന്നു, പക്ഷേ ഇത് പ്രവർത്തനരഹിതമാണോയെന്ന് പരിശോധിക്കാൻ ശ്രദ്ധിക്കുക. കാരണം, അനുഭവം കാണിക്കുന്നത് പോലെ, പാരന്റ് PostgreSQL പ്രോസസ്സിൽ ഞങ്ങൾ NUMA പ്രവർത്തനരഹിതമാക്കുന്നത് നല്ലതാണ്, പക്ഷേ അത് പ്രവർത്തിക്കുമെന്നത് ഒട്ടും ആവശ്യമില്ല. അവൾ ശരിക്കും സ്വിച്ച് ഓഫ് ആണെന്ന് പരിശോധിച്ച് നോക്കേണ്ടതുണ്ട്.
റോബർട്ട് ഹാസിന്റെ ഒരു നല്ല പോസ്റ്റ് ഉണ്ട്. ഇത് PostgreSQL കമ്മിറ്ററുകളിൽ ഒന്നാണ്. എല്ലാ താഴ്ന്ന നിലയിലുള്ള ജിബ്ലറ്റുകളുടെയും പ്രധാന ഡെവലപ്പർമാരിൽ ഒരാൾ. നിങ്ങൾ ഈ പോസ്റ്റിൽ നിന്നുള്ള ലിങ്കുകൾ പിന്തുടരുകയാണെങ്കിൽ, NUMA എങ്ങനെയാണ് ആളുകൾക്ക് ജീവിതം ദുഷ്കരമാക്കിയത് എന്നതിനെക്കുറിച്ചുള്ള നിരവധി വർണ്ണാഭമായ കഥകൾ അവർ വിവരിക്കുന്നു. നോക്കൂ, ഞങ്ങളുടെ ഡാറ്റാബേസ് നന്നായി പ്രവർത്തിക്കുന്നതിന് സെർവറിൽ എന്താണ് കോൺഫിഗർ ചെയ്യേണ്ടത് എന്നതിന്റെ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർ ചെക്ക്‌ലിസ്റ്റ് പഠിക്കുക. ഈ ക്രമീകരണങ്ങൾ എഴുതി പരിശോധിക്കേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം ഇത് വളരെ നല്ലതായിരിക്കില്ല.
ഞാൻ സംസാരിക്കുന്ന എല്ലാ ക്രമീകരണങ്ങൾക്കും ഇത് ബാധകമാണെന്ന് ദയവായി ശ്രദ്ധിക്കുക. എന്നാൽ സാധാരണയായി ഡാറ്റാബേസുകൾ മാസ്റ്റർ-സ്ലേവ് മോഡിൽ തെറ്റ് സഹിഷ്ണുതയ്ക്കായി ശേഖരിക്കുന്നു. സ്ലേവിൽ ഈ ക്രമീകരണങ്ങൾ ചെയ്യാൻ മറക്കരുത് കാരണം ഒരു ദിവസം നിങ്ങൾക്ക് ഒരു അപകടം സംഭവിക്കും, നിങ്ങൾ അടിമയിലേക്ക് മാറും, അത് യജമാനനാകും.
ഒരു അടിയന്തര സാഹചര്യത്തിൽ, എല്ലാം വളരെ മോശമായിരിക്കുമ്പോൾ, നിങ്ങളുടെ ഫോൺ നിരന്തരം റിംഗ് ചെയ്യുമ്പോഴും നിങ്ങളുടെ ബോസ് ഒരു വലിയ വടിയുമായി ഓടുമ്പോൾ, പരിശോധിക്കുന്നതിനെക്കുറിച്ച് ചിന്തിക്കാൻ നിങ്ങൾക്ക് സമയമില്ല. കൂടാതെ ഫലങ്ങൾ തികച്ചും വിനാശകരമായിരിക്കും.
അടുത്ത പോയിന്റ് വലിയ പേജുകളാണ്. വലിയ പേജുകൾ വെവ്വേറെ പരിശോധിക്കുന്നത് ബുദ്ധിമുട്ടാണ്, ഇത് ചെയ്യാൻ കഴിയുന്ന മാനദണ്ഡങ്ങൾ ഉണ്ടെങ്കിലും അങ്ങനെ ചെയ്യുന്നതിൽ അർത്ഥമില്ല. അവ ഗൂഗിളിന് എളുപ്പമാണ്.
കാര്യം എന്തണ്? നിങ്ങൾക്ക് ധാരാളം റാം ഉള്ള വളരെ ചെലവേറിയ സെർവർ ഇല്ല, ഉദാഹരണത്തിന്, 30 GB-യിൽ കൂടുതൽ. നിങ്ങൾ വലിയ പേജുകൾ ഉപയോഗിക്കുന്നില്ല. മെമ്മറി ഉപയോഗത്തിന്റെ കാര്യത്തിൽ നിങ്ങൾക്ക് തീർച്ചയായും ഓവർഹെഡ് ഉണ്ടെന്നാണ് ഇതിനർത്ഥം. ഈ ഓവർഹെഡ് ഏറ്റവും മനോഹരമായതിൽ നിന്ന് വളരെ അകലെയാണ്.
എന്തുകൊണ്ടാണത്? എന്താണ് നടക്കുന്നത്? ഓപ്പറേറ്റിംഗ് സിസ്റ്റം മെമ്മറി ചെറിയ കഷണങ്ങളായി അനുവദിക്കുന്നു. ഇത് വളരെ സൗകര്യപ്രദമാണ്, അത് ചരിത്രപരമായി എങ്ങനെ സംഭവിച്ചു. നമ്മൾ വിശദാംശങ്ങളിലേക്ക് പോകുകയാണെങ്കിൽ, OS വെർച്വൽ വിലാസങ്ങളെ ഫിസിക്കൽ വിലാസങ്ങളിലേക്ക് വിവർത്തനം ചെയ്യണം. ഈ പ്രക്രിയ ഏറ്റവും ലളിതമല്ല, അതിനാൽ ഈ പ്രവർത്തനത്തിന്റെ ഫലം വിവർത്തന ലുക്ക്സൈഡ് ബഫറിൽ (TLB) OS കാഷെ ചെയ്യുന്നു.
TLB ഒരു കാഷെ ആയതിനാൽ, ഒരു കാഷെയിൽ അന്തർലീനമായ എല്ലാ പ്രശ്നങ്ങളും ഈ സാഹചര്യത്തിൽ ഉണ്ടാകുന്നു. ഒന്നാമതായി, നിങ്ങൾക്ക് ധാരാളം റാം ഉണ്ടെങ്കിൽ, അതെല്ലാം ചെറിയ കഷണങ്ങളായി നീക്കിവച്ചിട്ടുണ്ടെങ്കിൽ, ഈ ബഫർ വളരെ വലുതായിരിക്കും. കാഷെ വലുതാണെങ്കിൽ, അതിലൂടെ തിരയുന്നത് മന്ദഗതിയിലാണ്. ഓവർഹെഡ് ആരോഗ്യകരമാണ്, അത് തന്നെ ഇടം എടുക്കുന്നു, അതായത് റാം തെറ്റായി ഉപയോഗിക്കപ്പെടുന്നു. ഇത്തവണ.
രണ്ട് - അത്തരമൊരു സാഹചര്യത്തിൽ കാഷെ എത്രയധികം വളരുന്നുവോ അത്രയധികം നിങ്ങൾക്ക് കാഷെ നഷ്ടപ്പെടാനുള്ള സാധ്യത കൂടുതലാണ്. ഈ കാഷെയുടെ വലിപ്പം കൂടുന്നതിനനുസരിച്ച് അതിന്റെ കാര്യക്ഷമത അതിവേഗം കുറയുന്നു. അതിനാൽ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ ലളിതമായ ഒരു സമീപനം കൊണ്ടുവന്നു. ഇത് ലിനക്സിൽ വളരെക്കാലമായി ഉപയോഗിക്കുന്നു. ഇത് വളരെക്കാലം മുമ്പല്ല FreeBSD-യിൽ പ്രത്യക്ഷപ്പെട്ടത്. എന്നാൽ നമ്മൾ ലിനക്സിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. ഇവ വലിയ പേജുകളാണ്.
ഒരു ആശയമെന്ന നിലയിൽ, ഒറാക്കിളും ഐബിഎമ്മും ഉൾപ്പെടുന്ന കമ്മ്യൂണിറ്റികളാണ് വലിയ പേജുകൾ ആദ്യം തള്ളിയത് എന്നത് ഇവിടെ ശ്രദ്ധിക്കേണ്ടതാണ്, അതായത് ഡാറ്റാബേസുകൾക്കും ഇത് ഉപയോഗപ്രദമാകുമെന്ന് ഡാറ്റാബേസ് നിർമ്മാതാക്കൾ ശക്തമായി കരുതി.
ഇത് എങ്ങനെ PostgreSQL-മായി ചങ്ങാത്തം കൂടാം? ഒന്നാമതായി, ലിനക്സ് കേർണലിൽ വലിയ പേജുകൾ പ്രവർത്തനക്ഷമമാക്കണം.
രണ്ടാമതായി, അവ sysctl പാരാമീറ്റർ ഉപയോഗിച്ച് വ്യക്തമായി വ്യക്തമാക്കണം - എത്ര എണ്ണം ഉണ്ട്. ഇവിടെയുള്ള നമ്പറുകൾ ഏതോ പഴയ സെർവറിൽ നിന്നുള്ളതാണ്. നിങ്ങൾക്ക് എത്ര പങ്കിട്ട ബഫറുകൾ ഉണ്ടെന്ന് നിങ്ങൾക്ക് കണക്കാക്കാം, അതിലൂടെ വലിയ പേജുകൾ അവിടെ ഉൾക്കൊള്ളിക്കാനാകും.
നിങ്ങളുടെ മുഴുവൻ സെർവറും PostgreSQL-ന് സമർപ്പിക്കപ്പെട്ടതാണെങ്കിൽ, ഒരു നല്ല ആരംഭ പോയിന്റ് ഒന്നുകിൽ RAM-ന്റെ 25% പങ്കിട്ട ബഫറുകൾക്കായി നീക്കിവയ്ക്കുക, അല്ലെങ്കിൽ നിങ്ങളുടെ ഡാറ്റാബേസ് തീർച്ചയായും ഈ 75%-ൽ യോജിക്കുമെന്ന് നിങ്ങൾക്ക് ഉറപ്പുണ്ടെങ്കിൽ 75%. ആരംഭ പോയിന്റ് ഒന്ന്. പരിഗണിക്കുക, നിങ്ങൾക്ക് 256 ജിബി റാം ഉണ്ടെങ്കിൽ, അതനുസരിച്ച്, നിങ്ങൾക്ക് 64 ജിബി വലിയ ബഫറുകൾ ഉണ്ടാകും. കുറച്ച് മാർജിൻ ഉപയോഗിച്ച് ഏകദേശം കണക്കാക്കുക - ഈ കണക്ക് എന്താണ് സജ്ജീകരിക്കേണ്ടത്.
പതിപ്പ് 9.2 ന് മുമ്പ് (ഞാൻ തെറ്റിദ്ധരിച്ചിട്ടില്ലെങ്കിൽ, പതിപ്പ് 8.2 മുതൽ), ഒരു മൂന്നാം കക്ഷി ലൈബ്രറി ഉപയോഗിച്ച് വലിയ പേജുകളുമായി PostgreSQL കണക്റ്റുചെയ്യുന്നത് സാധ്യമായിരുന്നു. കൂടാതെ ഇത് എപ്പോഴും ചെയ്യണം. ആദ്യം, വലിയ പേജുകൾ ശരിയായി അനുവദിക്കുന്നതിന് നിങ്ങൾക്ക് കേർണൽ ആവശ്യമാണ്. രണ്ടാമതായി, അവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കുന്ന അപ്ലിക്കേഷന് അവ ഉപയോഗിക്കാൻ കഴിയും. അത് അങ്ങനെ മാത്രം ഉപയോഗിക്കില്ല. PostgreSQL സിസ്റ്റം 5 ശൈലിയിൽ മെമ്മറി അനുവദിച്ചതിനാൽ, ഇത് libhugetlbfs ഉപയോഗിച്ച് ചെയ്യാം - ഇതാണ് ലൈബ്രറിയുടെ മുഴുവൻ പേര്.
9.3-ൽ, മെമ്മറിയിൽ പ്രവർത്തിക്കുമ്പോൾ PostgreSQL പ്രകടനം മെച്ചപ്പെടുത്തുകയും സിസ്റ്റം 5 മെമ്മറി അലോക്കേഷൻ രീതി ഉപേക്ഷിക്കുകയും ചെയ്തു. എല്ലാവരും വളരെ സന്തുഷ്ടരായിരുന്നു, അല്ലാത്തപക്ഷം നിങ്ങൾ ഒരു മെഷീനിൽ രണ്ട് PostgreSQL ഇൻസ്‌റ്റൻസുകൾ പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുന്നു, എനിക്ക് വേണ്ടത്ര പങ്കിട്ട മെമ്മറി ഇല്ലെന്ന് അദ്ദേഹം പറയുന്നു. sysctl ശരിയാക്കേണ്ടതുണ്ടെന്നും അദ്ദേഹം പറയുന്നു. നിങ്ങൾ ഇപ്പോഴും റീബൂട്ട് ചെയ്യേണ്ട ഒരു sysctl ഉണ്ട്, മുതലായവ. പൊതുവേ, എല്ലാവരും സന്തോഷവാനായിരുന്നു. എന്നാൽ mmap മെമ്മറി അലോക്കേഷൻ വലിയ പേജുകളുടെ ഉപയോഗം തകർത്തു. ഞങ്ങളുടെ മിക്ക ക്ലയന്റുകളും വലിയ പങ്കിട്ട ബഫറുകൾ ഉപയോഗിക്കുന്നു. 9.3 ലേക്ക് മാറരുതെന്ന് ഞങ്ങൾ ശക്തമായി ശുപാർശ ചെയ്തു, കാരണം ഓവർഹെഡ് നല്ല ശതമാനത്തിൽ കണക്കാക്കാൻ തുടങ്ങി.
എന്നാൽ കമ്മ്യൂണിറ്റി ഈ പ്രശ്നം ശ്രദ്ധിച്ചു, 9.4 ൽ അവർ ഈ ഇവന്റ് വളരെ നന്നായി പുനർനിർമ്മിച്ചു. 9.4-ൽ postgresql.conf-ൽ ഒരു പരാമീറ്റർ പ്രത്യക്ഷപ്പെട്ടു, അതിൽ നിങ്ങൾക്ക് ശ്രമിക്കാം, ഓൺ അല്ലെങ്കിൽ ഓഫ് ചെയ്യാം.
ശ്രമിക്കുക എന്നതാണ് ഏറ്റവും സുരക്ഷിതമായ ഓപ്ഷൻ. PostgreSQL ആരംഭിക്കുമ്പോൾ, അത് പങ്കിട്ട മെമ്മറി അനുവദിക്കുമ്പോൾ, വലിയ പേജുകളിൽ നിന്ന് ഈ മെമ്മറി പിടിച്ചെടുക്കാൻ അത് ശ്രമിക്കുന്നു. ഇത് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, അത് സാധാരണ തിരഞ്ഞെടുപ്പിലേക്ക് മടങ്ങും. നിങ്ങൾക്ക് FreeBSD അല്ലെങ്കിൽ Solaris ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ശ്രമിക്കാം, അത് എല്ലായ്പ്പോഴും സുരക്ഷിതമാണ്.
ഓണാണെങ്കിൽ, വലിയ പേജുകളിൽ നിന്ന് തിരഞ്ഞെടുക്കാൻ കഴിയുന്നില്ലെങ്കിൽ അത് ആരംഭിക്കില്ല. ആരാണ്, എന്താണ് നല്ലത് എന്നതിനെക്കുറിച്ചാണ് ഇവിടെ പറയുന്നത്. എന്നാൽ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഹൈലൈറ്റ് ചെയ്യേണ്ടത് ശരിക്കും ഉണ്ടെന്ന് പരിശോധിക്കുക, കാരണം പിശകിന് ധാരാളം ഇടമുണ്ട്. നിലവിൽ ഈ പ്രവർത്തനം Linux-ൽ മാത്രമേ പ്രവർത്തിക്കൂ.
മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് ഒരു ചെറിയ കുറിപ്പ് കൂടി. സുതാര്യമായ വലിയ പേജുകൾ ഇതുവരെ PostgreSQL-നെക്കുറിച്ചല്ല. അയാൾക്ക് അവ സാധാരണയായി ഉപയോഗിക്കാൻ കഴിയില്ല. അത്തരം ജോലിഭാരത്തിന് സുതാര്യമായ വലിയ പേജുകൾക്കൊപ്പം, ഒരു വലിയ പങ്കുവെച്ച മെമ്മറി ആവശ്യമായി വരുമ്പോൾ, ആനുകൂല്യങ്ങൾ വളരെ വലിയ വോള്യങ്ങളിൽ മാത്രമേ ലഭ്യമാകൂ. നിങ്ങൾക്ക് ടെറാബൈറ്റ് മെമ്മറി ഉണ്ടെങ്കിൽ, ഇത് പ്രവർത്തനക്ഷമമായേക്കാം. ഞങ്ങൾ കൂടുതൽ ദൈനംദിന ആപ്ലിക്കേഷനുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, നിങ്ങളുടെ മെഷീനിൽ 32, 64, 128, 256 GB മെമ്മറി ഉള്ളപ്പോൾ, സാധാരണ വലിയ പേജുകൾ ശരിയാണ്, ഞങ്ങൾ സുതാര്യമായത് പ്രവർത്തനരഹിതമാക്കും.
മെമ്മറിയുടെ അവസാന കാര്യം ഫ്രൂട്ടുമായി നേരിട്ട് ബന്ധപ്പെട്ടതല്ല, അത് നിങ്ങളുടെ ജീവിതത്തെ ശരിക്കും നശിപ്പിക്കും. സെർവർ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന വസ്തുത എല്ലാ ത്രൂപുട്ടിനെയും വളരെയധികം ബാധിക്കും.
കൂടാതെ ഇത് പല തരത്തിൽ വളരെ അരോചകമായിരിക്കും. ആധുനിക കേർണലുകൾ പഴയ ലിനക്സ് കേർണലുകളിൽ നിന്ന് അല്പം വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു എന്നതാണ് പ്രധാന പ്രശ്നം. ഈ കാര്യം ചുവടുവെക്കുന്നത് തികച്ചും അസുഖകരമാണ്, കാരണം ഞങ്ങൾ സ്വാപ്പിനൊപ്പം ഏതെങ്കിലും തരത്തിലുള്ള ജോലിയെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, അത് അവസാനിക്കുന്നത് OOM-കൊലയാളിയുടെ അകാല വരവോടെയാണ്. കൃത്യസമയത്ത് എത്താതെ PostgreSQL ഉപേക്ഷിച്ച OOM-കില്ലർ അസുഖകരമാണ്. ഇതിനെക്കുറിച്ച് എല്ലാവർക്കും അറിയാം, അതായത്, അവസാന ഉപയോക്താവ് വരെ.
എന്താണ് സംഭവിക്കുന്നത്? നിങ്ങൾക്ക് അവിടെ വലിയ അളവിലുള്ള റാം ഉണ്ട്, എല്ലാം നന്നായി പ്രവർത്തിക്കുന്നു. എന്നാൽ ചില കാരണങ്ങളാൽ സെർവർ സ്വാപ്പിൽ തൂങ്ങിക്കിടക്കുകയും ഇതുമൂലം വേഗത കുറയുകയും ചെയ്യുന്നു. ഒരുപാട് മെമ്മറി ഉണ്ടെന്ന് തോന്നുന്നു, പക്ഷേ ഇത് സംഭവിക്കുന്നു.
മുമ്പ്, vm.swappiness പൂജ്യമായി സജ്ജീകരിക്കാൻ ഞങ്ങൾ ഉപദേശിച്ചു, അതായത് സ്വാപ്പ് പ്രവർത്തനരഹിതമാക്കുന്നു. മുമ്പ്, 32 ജിബി റാമും അനുബന്ധ പങ്കിട്ട ബഫറുകളും ഒരു വലിയ തുകയാണ്. നമ്മൾ വീണാൽ പുറംതോട് എറിയാനുള്ള ഒരു സ്ഥലം എന്നതാണ് സ്വാപ്പിന്റെ പ്രധാന ലക്ഷ്യം. പിന്നെ അത് പ്രത്യേകിച്ച് നിവൃത്തിയായില്ല. എന്നിട്ട് ഈ പുറംതോട് എന്ത് ചെയ്യാൻ പോകുന്നു? സ്വാപ്പ് എന്തിന് ആവശ്യമാണെന്ന് വ്യക്തമല്ലാത്ത ഒരു ടാസ്‌ക്കാണിത്, പ്രത്യേകിച്ച് അത്തരമൊരു വലുപ്പം.
എന്നാൽ കൂടുതൽ ആധുനികമായ, അതായത്, കേർണലിന്റെ മൂന്നാം പതിപ്പുകളിൽ, സ്വഭാവം മാറി. നിങ്ങൾ സ്വാപ്പ് പൂജ്യത്തിലേക്ക് സജ്ജീകരിച്ചാൽ, അതായത് അത് ഓഫ് ചെയ്താൽ, എത്രയും വേഗം അല്ലെങ്കിൽ പിന്നീട്, കുറച്ച് റാം അവശേഷിക്കുന്നുണ്ടെങ്കിൽ പോലും, ഏറ്റവും തീവ്രമായ ഉപഭോക്താക്കളെ കൊല്ലാൻ ഒരു OOM കൊലയാളി നിങ്ങളുടെ അടുത്ത് വരും. കാരണം, അത്തരമൊരു ജോലിഭാരത്തിൽ നമുക്ക് ഇനിയും അൽപ്പം ബാക്കിയുണ്ടെന്നും ഞങ്ങൾ പുറത്തേക്ക് ചാടുമെന്നും അദ്ദേഹം പരിഗണിക്കും, അതായത്, സിസ്റ്റം പ്രക്രിയയെ തകർക്കാനല്ല, മറിച്ച് പ്രാധാന്യം കുറഞ്ഞ എന്തെങ്കിലും നഖം കുറയ്ക്കാൻ. ഈ കുറവ് പ്രധാനം പങ്കുവയ്ക്കുന്ന മെമ്മറിയുടെ തീവ്രമായ ഉപഭോക്താവായിരിക്കും, അതായത് പോസ്റ്റ്മാസ്റ്റർ. അതിനുശേഷം അടിസ്ഥാനം പുനഃസ്ഥാപിക്കേണ്ടതില്ലെങ്കിൽ അത് നന്നായിരിക്കും.
അതിനാൽ, ഇപ്പോൾ ഡിഫോൾട്ട്, ഞാൻ ഓർക്കുന്നിടത്തോളം, മിക്ക വിതരണങ്ങളും എവിടെയോ 6 ആണ്, അതായത് എത്ര മെമ്മറി ശേഷിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച് ഏത് ഘട്ടത്തിലാണ് നിങ്ങൾ സ്വാപ്പ് ഉപയോഗിക്കാൻ തുടങ്ങേണ്ടത്. ഞങ്ങൾ ഇപ്പോൾ vm.swappiness = 1 സജ്ജീകരിക്കാൻ ശുപാർശചെയ്യുന്നു, കാരണം ഇത് പ്രായോഗികമായി ഇത് ഓഫാക്കുന്നു, പക്ഷേ അപ്രതീക്ഷിതമായി വന്ന് മൊത്തത്തിൽ കൊന്നൊടുക്കിയ OOM-കില്ലർ പോലെയുള്ള അതേ ഇഫക്റ്റുകൾ നൽകുന്നില്ല.
അടുത്തത് എന്താണ്? ഞങ്ങൾ ഡാറ്റാബേസുകളുടെ പ്രകടനത്തെക്കുറിച്ച് സംസാരിക്കുകയും ക്രമേണ ഡിസ്കുകളിലേക്ക് നീങ്ങുകയും ചെയ്യുമ്പോൾ, എല്ലാവരും അവരുടെ തലയിൽ പിടിക്കാൻ തുടങ്ങുന്നു. കാരണം ഡിസ്ക് സ്ലോ ആണ്, മെമ്മറി ഫാസ്റ്റ് ആണ് എന്ന സത്യം കുട്ടിക്കാലം മുതൽ എല്ലാവർക്കും പരിചിതമാണ്. ഡാറ്റാബേസിന് ഡിസ്ക് പ്രകടന പ്രശ്നങ്ങൾ ഉണ്ടാകുമെന്ന് എല്ലാവർക്കും അറിയാം.
ഡിസ്ക് മന്ദഗതിയിലായതിനാൽ ചെക്ക് പോയിന്റുകളുടെ സ്പൈക്കുകളുമായി ബന്ധപ്പെട്ട പ്രധാന PostgreSQL പ്രകടന പ്രശ്നം സംഭവിക്കുന്നില്ല. മെമ്മറിയും ഡിസ്ക് ബാൻഡ്‌വിഡ്ത്തും സന്തുലിതമല്ല എന്ന വസ്തുതയാണ് ഇതിന് കാരണം. എന്നിരുന്നാലും, വ്യത്യസ്ത സ്ഥലങ്ങളിൽ അവ സന്തുലിതമാകണമെന്നില്ല. PostgreSQL കോൺഫിഗർ ചെയ്‌തിട്ടില്ല, OS കോൺഫിഗർ ചെയ്‌തിട്ടില്ല, ഹാർഡ്‌വെയർ കോൺഫിഗർ ചെയ്‌തിട്ടില്ല, ഹാർഡ്‌വെയർ തെറ്റാണ്. എല്ലാം സംഭവിക്കുന്നതുപോലെ സംഭവിച്ചാൽ മാത്രം ഈ പ്രശ്നം സംഭവിക്കില്ല, അതായത് ഒന്നുകിൽ ലോഡ് ഇല്ല, അല്ലെങ്കിൽ ക്രമീകരണങ്ങളും ഹാർഡ്‌വെയറും നന്നായി തിരഞ്ഞെടുത്തു.
അത് എന്താണ്, അത് എങ്ങനെ കാണപ്പെടുന്നു? സാധാരണയായി PostgreSQL-ൽ പ്രവർത്തിക്കുന്ന ആളുകൾ ഒന്നിലധികം തവണ ഈ വിഷയത്തിൽ പ്രവേശിച്ചിട്ടുണ്ട്. ഞാൻ വിശദീകരിക്കാം. ഞാൻ പറഞ്ഞതുപോലെ, പങ്കിട്ട മെമ്മറിയിലെ വൃത്തികെട്ട പേജുകൾ ഡിസ്കിലേക്ക് ഇടാൻ PostgreSQL ഇടയ്ക്കിടെ ചെക്ക് പോയിന്റുകൾ ഉണ്ടാക്കുന്നു. ഞങ്ങൾക്ക് വലിയ അളവിൽ പങ്കിട്ട മെമ്മറി ഉണ്ടെങ്കിൽ, ചെക്ക് പോയിന്റ് ഡിസ്കിൽ തീവ്രമായ സ്വാധീനം ചെലുത്താൻ തുടങ്ങുന്നു, കാരണം ഇത് ഈ പേജുകളെ fsync ഉപയോഗിച്ച് ഉപേക്ഷിക്കുന്നു. ഇത് കേർണൽ ബഫറിൽ എത്തുകയും fsync ഉപയോഗിച്ച് ഡിസ്കുകളിലേക്ക് എഴുതുകയും ചെയ്യുന്നു. ഈ ബിസിനസ്സിന്റെ അളവ് വലുതാണെങ്കിൽ, നമുക്ക് അസുഖകരമായ ഒരു പ്രഭാവം നിരീക്ഷിക്കാൻ കഴിയും, അതായത് ഡിസ്കുകളുടെ വളരെ വലിയ ഉപയോഗം.
ഇവിടെ എനിക്ക് രണ്ട് ചിത്രങ്ങൾ ഉണ്ട്. അത് എന്താണെന്ന് ഞാൻ ഇപ്പോൾ വിശദീകരിക്കും. ഇവ രണ്ട് സമയബന്ധിത ഗ്രാഫുകളാണ്. ആദ്യത്തെ ഗ്രാഫ് ഡിസ്ക് ഉപയോഗമാണ്. ഈ സമയത്ത് ഇത് ഏകദേശം 90% വരെ എത്തുന്നു. നിങ്ങൾക്ക് ഫിസിക്കൽ ഡിസ്കുകളുള്ള ഒരു ഡാറ്റാബേസ് പരാജയം ഉണ്ടെങ്കിൽ, ഒരു റെയിഡ് കൺട്രോളർ ഉപയോഗം 90% ആണെങ്കിൽ, ഇത് മോശം വാർത്തയാണ്. ഇതിനർത്ഥം കുറച്ച് കൂടി, അത് 100 ൽ എത്തുകയും I/O നിർത്തുകയും ചെയ്യും.
നിങ്ങൾക്ക് ഒരു ഡിസ്ക് അറേ ഉണ്ടെങ്കിൽ, അത് അല്പം വ്യത്യസ്തമായ കഥയാണ്. ഇത് എങ്ങനെ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു, ഏത് തരം അറേയാണ് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
സമാന്തരമായി, ആന്തരിക പോസ്റ്റ്‌ഗ്രേസ് കാഴ്ചയിൽ നിന്നുള്ള ഒരു ഗ്രാഫ് ഇവിടെ ക്രമീകരിച്ചിരിക്കുന്നു, ഇത് ചെക്ക്‌പോയിന്റ് എങ്ങനെ സംഭവിക്കുന്നുവെന്ന് പറയുന്നു. ഇവിടെയുള്ള പച്ച നിറം കാണിക്കുന്നത് എത്ര ബഫറുകൾ, ഈ വൃത്തികെട്ട പേജുകൾ, ആ നിമിഷം സമന്വയത്തിനായി ഈ ചെക്ക് പോയിന്റിൽ എത്തിയിരിക്കുന്നു. ഇവിടെ നിങ്ങൾ അറിയേണ്ട പ്രധാന കാര്യം ഇതാണ്. ഞങ്ങൾക്ക് ഇവിടെ ധാരാളം പേജുകൾ ഉണ്ടെന്ന് ഞങ്ങൾ കാണുന്നു, ചില സമയങ്ങളിൽ ഞങ്ങൾ ബോർഡിൽ തട്ടുന്നു, അതായത്, ഞങ്ങൾ എഴുതി, എഴുതി, ഇവിടെ ഡിസ്ക് സിസ്റ്റം വളരെ തിരക്കിലാണ്. ഞങ്ങളുടെ ചെക്ക് പോയിന്റ് ഡിസ്കിൽ വളരെ ശക്തമായ സ്വാധീനം ചെലുത്തുന്നു. സാഹചര്യം ഇതുപോലെയായിരിക്കണം, അതായത് ഞങ്ങൾക്ക് ഇവിടെ റെക്കോർഡിംഗ് കുറവായിരുന്നു. ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച് നമുക്ക് ഇത് പരിഹരിക്കാനാകും, അങ്ങനെ അത് തുടരും. അതായത്, റീസൈക്ലിംഗ് ചെറുതാണ്, എന്നാൽ എവിടെയോ ഞങ്ങൾ ഇവിടെ എന്തെങ്കിലും എഴുതുകയാണ്.
ഈ പ്രശ്നം മറികടക്കാൻ എന്താണ് ചെയ്യേണ്ടത്? നിങ്ങൾ ഡാറ്റാബേസിന് കീഴിൽ IO നിർത്തിയിട്ടുണ്ടെങ്കിൽ, അവരുടെ അഭ്യർത്ഥനകൾ നിറവേറ്റാൻ വന്ന എല്ലാ ഉപയോക്താക്കളും കാത്തിരിക്കും എന്നാണ് ഇതിനർത്ഥം.
നിങ്ങൾ ലിനക്സിന്റെ വീക്ഷണകോണിൽ നിന്ന് നോക്കുകയാണെങ്കിൽ, നിങ്ങൾ നല്ല ഹാർഡ്‌വെയർ എടുത്ത്, അത് ശരിയായി കോൺഫിഗർ ചെയ്ത്, PostgreSQL സാധാരണയായി ക്രമീകരിച്ചാൽ, ഈ ചെക്ക്‌പോസ്റ്റുകൾ ഇടയ്ക്കിടെ കുറയ്‌ക്കുകയും കാലക്രമേണ അവ പരസ്പരം വ്യാപിക്കുകയും ചെയ്യുന്നു, തുടർന്ന് നിങ്ങൾ സ്ഥിരസ്ഥിതി ഡെബിയൻ പാരാമീറ്ററുകളിലേക്ക് കടക്കുന്നു. മിക്ക ലിനക്സ് വിതരണങ്ങൾക്കും, ഇതാണ് ചിത്രം: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
എന്താണ് ഇതിനർത്ഥം? കേർണൽ 2.6 ൽ നിന്ന് ഒരു ഫ്ലഷിംഗ് ഭൂതം പ്രത്യക്ഷപ്പെട്ടു. Pdglush, ആരാണ് ഉപയോഗിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ച്, അത് കേർണൽ ബഫറിൽ നിന്ന് വൃത്തികെട്ട പേജുകൾ പശ്ചാത്തലത്തിൽ ഉപേക്ഷിക്കുന്നതിലും വൃത്തികെട്ട പേജുകൾ ഉപേക്ഷിക്കേണ്ടിവരുമ്പോൾ ഉപേക്ഷിക്കുന്നതിലും ഏർപ്പെട്ടിരിക്കുന്നു.
എപ്പോഴാണ് പശ്ചാത്തലം വരുന്നത്? സെർവറിൽ ലഭ്യമായ മൊത്തം റാമിന്റെ 10% കേർണൽ ബഫറിലെ വൃത്തികെട്ട പേജുകളാൽ കൈവശപ്പെടുത്തുമ്പോൾ, പശ്ചാത്തലത്തിൽ ഒരു പ്രത്യേക റൈറ്റ്-ഓഫ് ഫംഗ്ഷൻ വിളിക്കുന്നു. എന്തുകൊണ്ടാണ് അതിന്റെ പശ്ചാത്തലം? ഒരു പാരാമീറ്റർ എന്ന നിലയിൽ, എത്ര പേജുകൾ എഴുതിത്തള്ളണമെന്ന് അത് കണക്കിലെടുക്കുന്നു. കൂടാതെ, അദ്ദേഹം N പേജുകൾ എഴുതിത്തള്ളുന്നുവെന്ന് പറയുക. കുറച്ചു നേരം ഈ കാര്യം ഉറങ്ങുന്നു. എന്നിട്ട് അവൾ വീണ്ടും വന്ന് കുറച്ച് പേജുകൾ പകർത്തുന്നു.
ഇത് വളരെ ലളിതമായ ഒരു കഥയാണ്. സ്വിമ്മിംഗ് പൂളിലെ പോലെ ഇവിടെ പ്രശ്നം, ഒരു പൈപ്പിൽ ഒഴിക്കുമ്പോൾ അത് മറ്റൊന്നിലേക്ക് ഒഴുകുന്നു. ഞങ്ങളുടെ ചെക്ക്‌പോയിന്റ് എത്തി, അത് ഉപേക്ഷിക്കാൻ കുറച്ച് വൃത്തികെട്ട പേജുകൾ അയച്ചാൽ, ക്രമേണ മുഴുവൻ കാര്യവും കേർണൽ ബഫർ pgflush-ൽ നിന്ന് ഭംഗിയായി പരിഹരിക്കപ്പെടും.
ഈ വൃത്തികെട്ട പേജുകൾ കുമിഞ്ഞുകൂടുന്നത് തുടരുകയാണെങ്കിൽ, അവ 20% വരെ ശേഖരിക്കും, അതിനുശേഷം OS മുൻഗണന മുഴുവൻ ഡിസ്കിലേക്ക് എഴുതുക എന്നതാണ്, കാരണം വൈദ്യുതി പരാജയപ്പെടുകയും എല്ലാം നമുക്ക് ദോഷകരമാവുകയും ചെയ്യും. നമുക്ക് ഈ ഡാറ്റ നഷ്‌ടമാകും, ഉദാഹരണത്തിന്.
എന്താണ് തന്ത്രം? ആധുനിക ലോകത്തിലെ ഈ പാരാമീറ്ററുകൾ മെഷീനിലുള്ള മൊത്തം റാമിന്റെ 20 ഉം 10% ഉം ആണ്, നിങ്ങളുടെ കൈവശമുള്ള ഏതെങ്കിലും ഡിസ്ക് സിസ്റ്റത്തിന്റെ ത്രൂപുട്ടിന്റെ കാര്യത്തിൽ അവ തികച്ചും ഭീകരമാണ്.
നിങ്ങൾക്ക് 128 ജിബി റാം ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക. നിങ്ങളുടെ ഡിസ്ക് സിസ്റ്റത്തിൽ 12,8 GB എത്തുന്നു. നിങ്ങൾക്ക് അവിടെ എന്ത് കാഷെ ഉണ്ടെങ്കിലും, നിങ്ങൾക്ക് അവിടെ എന്ത് അറേ ഉണ്ടായിരുന്നാലും, അവ അധികകാലം നിലനിൽക്കില്ല.
അതിനാൽ, നിങ്ങളുടെ റെയിഡ് കൺട്രോളറിന്റെ കഴിവുകളെ അടിസ്ഥാനമാക്കി ഈ നമ്പറുകൾ ഉടനടി ക്രമീകരിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. 512 MB കാഷെ ഉള്ള ഒരു കൺട്രോളറിനായി ഞാൻ ഉടൻ തന്നെ ഇവിടെ ഒരു ശുപാർശ നൽകി.
എല്ലാം വളരെ ലളിതമായി കണക്കാക്കപ്പെടുന്നു. നിങ്ങൾക്ക് vm.dirty_background ബൈറ്റുകളിൽ ഇടാം. ഈ ക്രമീകരണങ്ങൾ മുമ്പത്തെ രണ്ടെണ്ണം റദ്ദാക്കുന്നു. ഒന്നുകിൽ അനുപാതം ഡിഫോൾട്ടാണ്, അല്ലെങ്കിൽ ബൈറ്റുകൾ ഉള്ളവ സജീവമാക്കിയാൽ, ബൈറ്റുകൾ ഉള്ളവ പ്രവർത്തിക്കും. എന്നാൽ ഞാൻ ഒരു ഡിബിഎ കൺസൾട്ടന്റായതിനാലും വ്യത്യസ്ത ക്ലയന്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നതിനാലും ഞാൻ സ്ട്രോകൾ വരയ്ക്കാൻ ശ്രമിക്കുന്നു, അതിനാൽ, ബൈറ്റുകളിലാണെങ്കിൽ, ബൈറ്റുകളിൽ. ഒരു നല്ല അഡ്മിൻ സെർവറിൽ കൂടുതൽ മെമ്മറി ചേർക്കില്ലെന്നും റീബൂട്ട് ചെയ്യുമെന്നും കണക്ക് അതേപടി നിലനിൽക്കുമെന്നും ആരും ഉറപ്പ് നൽകിയില്ല. ഈ സംഖ്യകൾ കണക്കാക്കുക, അങ്ങനെ എല്ലാം ഒരു ഗ്യാരന്റിയോടെ അവിടെ യോജിക്കുന്നു.
നിങ്ങൾ പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ എന്ത് സംഭവിക്കും? ഏതെങ്കിലും ഫ്ലഷിംഗ് ഫലപ്രദമായി നിർത്തലാക്കുന്നുവെന്ന് ഞാൻ എഴുതിയിട്ടുണ്ട്, എന്നാൽ വാസ്തവത്തിൽ ഇത് സംസാരത്തിന്റെ ഒരു രൂപമാണ്. ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് ഒരു വലിയ പ്രശ്‌നമുണ്ട് - ഇതിന് ധാരാളം വൃത്തികെട്ട പേജുകൾ ഉണ്ട്, അതിനാൽ നിങ്ങളുടെ ക്ലയന്റുകൾ സൃഷ്ടിക്കുന്ന IO ഫലപ്രദമായി നിർത്തി, അതായത് ഡാറ്റാബേസിലേക്ക് ഒരു sql അന്വേഷണം അയയ്‌ക്കാൻ അപ്ലിക്കേഷൻ വന്നിരിക്കുന്നു, അത് കാത്തിരിക്കുന്നു. അതിലേക്കുള്ള ഏതൊരു ഇൻപുട്ടും/ഔട്ട്പുട്ടും ഏറ്റവും കുറഞ്ഞ മുൻഗണനയുള്ളതാണ്, കാരണം ഡാറ്റാബേസ് ഒരു ചെക്ക്‌പോയിന്റാണ്. അവൾ എപ്പോൾ പൂർത്തിയാക്കും എന്നത് പൂർണ്ണമായും വ്യക്തമല്ല. നിങ്ങൾ നോൺ-ബാക്ക്ഗ്രൗണ്ട് ഫ്ലഷിംഗ് നേടിയാൽ, നിങ്ങളുടെ എല്ലാ IO-യും അത് ഉൾക്കൊള്ളുന്നു എന്നാണ്. അത് അവസാനിക്കുന്നതുവരെ നിങ്ങൾ ഒന്നും ചെയ്യില്ല.
ഈ റിപ്പോർട്ടിന്റെ പരിധിക്കപ്പുറമുള്ള രണ്ട് പ്രധാന കാര്യങ്ങൾ കൂടി ഇവിടെയുണ്ട്. ഈ ക്രമീകരണങ്ങൾ postgresql.conf-ലെ ക്രമീകരണങ്ങളുമായി പൊരുത്തപ്പെടണം, അതായത് ചെക്ക്‌പോയിന്റ് ക്രമീകരണങ്ങൾ. നിങ്ങളുടെ ഡിസ്ക് സിസ്റ്റം വേണ്ടത്ര ക്രമീകരിച്ചിരിക്കണം. RAID-ൽ നിങ്ങൾക്ക് ഒരു കാഷെ ഉണ്ടെങ്കിൽ, അതിന് ബാറ്ററി ഉണ്ടായിരിക്കണം. ആളുകൾ ബാറ്ററി ഇല്ലാതെ നല്ല കാഷെ ഉപയോഗിച്ച് RAID വാങ്ങുന്നു. നിങ്ങൾക്ക് RAID-ൽ SSD-കൾ ഉണ്ടെങ്കിൽ, അവ സെർവർ ആയിരിക്കണം, അവിടെ കപ്പാസിറ്ററുകൾ ഉണ്ടായിരിക്കണം. വിശദമായ ഒരു ചെക്ക്‌ലിസ്റ്റ് ഇതാ. PostgreSQL-ൽ ഒരു പെർഫോമൻസ് ഡിസ്ക് എങ്ങനെ കോൺഫിഗർ ചെയ്യാം എന്നതിനെക്കുറിച്ചുള്ള എന്റെ റിപ്പോർട്ട് ഈ ലിങ്കിൽ അടങ്ങിയിരിക്കുന്നു. ഈ ചെക്ക്‌ലിസ്റ്റുകളെല്ലാം അവിടെയുണ്ട്.
മറ്റെന്താണ് ജീവിതം വളരെ പ്രയാസകരമാക്കുന്നത്? ഇവ രണ്ട് പരാമീറ്ററുകളാണ്. അവ താരതമ്യേന പുതിയതാണ്. സ്ഥിരസ്ഥിതിയായി, അവ വ്യത്യസ്ത ആപ്ലിക്കേഷനുകളിൽ ഉൾപ്പെടുത്താം. തെറ്റായി ഓൺ ചെയ്താൽ അവർക്ക് ജീവിതം ബുദ്ധിമുട്ടുള്ളതാക്കും.
താരതമ്യേന പുതിയ രണ്ട് കാര്യങ്ങളുണ്ട്. അവർ ഇതിനകം മൂന്നാം കോറുകളിൽ പ്രത്യക്ഷപ്പെട്ടു. ഇത് നാനോസെക്കൻഡിലെ sched_migration_cost ആണ്, sched_autogroup_enabled ആണ്, ഇത് സ്ഥിരസ്ഥിതിയായി ഒന്നാണ്.
പിന്നെ എങ്ങനെയാണ് അവർ നിങ്ങളുടെ ജീവിതം നശിപ്പിക്കുന്നത്? ഷെഡ്_മൈഗ്രേഷൻ_ചെലവ് എന്താണ്? ലിനക്സിൽ, ഷെഡ്യൂളറിന് ഒരു സിപിയുവിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ഒരു പ്രോസസ്സ് മൈഗ്രേറ്റ് ചെയ്യാൻ കഴിയും. അന്വേഷണങ്ങൾ നടപ്പിലാക്കുന്ന PostgreSQL-ന്, മറ്റൊരു സിപിയുവിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നത് പൂർണ്ണമായും വ്യക്തമല്ല. ഒരു ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ വീക്ഷണകോണിൽ, നിങ്ങൾ ഓപ്പൺ ഓഫീസിനും ടെർമിനലിനും ഇടയിൽ വിൻഡോകൾ മാറുമ്പോൾ, ഇത് നല്ലതായിരിക്കാം, പക്ഷേ ഒരു ഡാറ്റാബേസിന് ഇത് വളരെ മോശമാണ്. അതിനാൽ, മൈഗ്രേഷൻ_കോസ്റ്റ് ചില വലിയ മൂല്യത്തിലേക്ക്, കുറഞ്ഞത് ആയിരക്കണക്കിന് നാനോസെക്കൻഡുകളെങ്കിലും സജ്ജീകരിക്കുക എന്നതാണ് ന്യായമായ നയം.
ഷെഡ്യൂളർക്ക് ഇത് എന്താണ് അർത്ഥമാക്കുന്നത്? ഈ സമയത്ത് പ്രക്രിയ ഇപ്പോഴും ചൂടുള്ളതായി കണക്കാക്കും. അതായത്, നിങ്ങൾ ദീർഘകാലമായി എന്തെങ്കിലും ചെയ്യുന്ന ഒരു ദീർഘകാല ഇടപാട് ഉണ്ടെങ്കിൽ, ഷെഡ്യൂളർക്ക് ഇത് മനസ്സിലാകും. ഈ സമയപരിധി കടന്നുപോകുന്നതുവരെ, ഈ പ്രക്രിയ എവിടെയും മൈഗ്രേറ്റ് ചെയ്യേണ്ട ആവശ്യമില്ലെന്ന് അദ്ദേഹം അനുമാനിക്കും. അതേ സമയം പ്രോസസ്സ് എന്തെങ്കിലും ചെയ്യുകയാണെങ്കിൽ, അത് എവിടെയും മൈഗ്രേറ്റ് ചെയ്യപ്പെടില്ല, അത് അനുവദിച്ചിരിക്കുന്ന സിപിയുവിൽ നിശബ്ദമായി പ്രവർത്തിക്കും. കൂടാതെ ഫലം മികച്ചതാണ്.
രണ്ടാമത്തെ പോയിന്റ് ഓട്ടോഗ്രൂപ്പ് ആണ്. ആധുനിക ഡാറ്റാബേസുകളുമായി ബന്ധമില്ലാത്ത നിർദ്ദിഷ്‌ട വർക്ക്‌ലോഡുകൾക്ക് ഒരു നല്ല ആശയമുണ്ട് - അവ സമാരംഭിച്ച വെർച്വൽ ടെർമിനൽ വഴി പ്രോസസ്സുകൾ ഗ്രൂപ്പുചെയ്യുക എന്നതാണ്. ചില ജോലികൾക്ക് ഇത് സൗകര്യപ്രദമാണ്. പ്രായോഗികമായി, ഒരൊറ്റ ടെർമിനലിൽ നിന്ന് പ്രവർത്തിക്കുന്ന ഒരു പ്രീഫോർക്ക് ഉള്ള ഒരു മൾട്ടി-പ്രോസസ് സിസ്റ്റമാണ് PostgreSQL. നിങ്ങൾക്ക് ഒരു ലോക്ക് റൈറ്ററും ചെക്ക് പോയിന്റും ഉണ്ട്, നിങ്ങളുടെ എല്ലാ ക്ലയന്റ് അഭ്യർത്ഥനകളും ഓരോ സിപിയുവിലും ഒരു ഷെഡ്യൂളറായി ഗ്രൂപ്പുചെയ്യപ്പെടും. പരസ്പരം ഇടപെടാനും അവനെ കൂടുതൽ നേരം തളച്ചിടാനും വേണ്ടി, അവൻ സ്വതന്ത്രനാകാൻ അവർ ഐക്യത്തോടെ അവിടെ കാത്തിരിക്കും. ഇത്തരമൊരു ലോഡിന്റെ കാര്യത്തിൽ തീർത്തും അനാവശ്യമായ ഒരു കഥയാണിത്, അതിനാൽ ഇത് ഓഫ് ചെയ്യേണ്ടത് ആവശ്യമാണ്.
എന്റെ സഹപ്രവർത്തകനായ അലക്സി ലെസോവ്സ്കി ഒരു ലളിതമായ pgbench ഉപയോഗിച്ച് ടെസ്റ്റുകൾ നടത്തി, അവിടെ അദ്ദേഹം മൈഗ്രേഷൻ_ചെലവ് ഒരു ക്രമത്തിൽ വർദ്ധിപ്പിക്കുകയും ഓട്ടോഗ്രൂപ്പ് ഓഫ് ചെയ്യുകയും ചെയ്തു. മോശം ഹാർഡ്‌വെയറിന്റെ വ്യത്യാസം ഏകദേശം 10% ആയിരുന്നു. പോസ്റ്റ്ഗ്രെസ് മെയിലിംഗ് ലിസ്റ്റിൽ ആളുകൾ അന്വേഷണ വേഗതയിൽ സമാനമായ മാറ്റങ്ങളുടെ ഫലങ്ങൾ നൽകുന്ന ഒരു ചർച്ചയുണ്ട് 50% സ്വാധീനിച്ചു. അത്തരം കഥകൾ ധാരാളം ഉണ്ട്.
അവസാനമായി, പവർ സേവിംഗ് പോളിസിയെക്കുറിച്ച്. ലിനക്സ് ഇപ്പോൾ ലാപ്‌ടോപ്പിൽ ഉപയോഗിക്കാം എന്നതാണ് നല്ല കാര്യം. ഇത് ബാറ്ററി നന്നായി ഉപയോഗിക്കുമെന്ന് കരുതപ്പെടുന്നു. എന്നാൽ ഇത് സെർവറിലും സംഭവിക്കാമെന്ന് പെട്ടെന്ന് മാറുന്നു.
മാത്രമല്ല, നിങ്ങൾ ഏതെങ്കിലും ഹോസ്റ്ററിൽ നിന്ന് സെർവറുകൾ വാടകയ്‌ക്കെടുക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് മികച്ച പ്രകടനം ഉണ്ടെന്ന് “നല്ല” ഹോസ്റ്റർമാർ ശ്രദ്ധിക്കുന്നില്ല. അവരുടെ ഇരുമ്പ് കഴിയുന്നത്ര കാര്യക്ഷമമായി ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക എന്നതാണ് അവരുടെ ചുമതല. അതിനാൽ, സ്ഥിരസ്ഥിതിയായി അവർക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ ലാപ്‌ടോപ്പ് പവർ സേവിംഗ് മോഡ് പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയും.
കനത്ത ലോഡിന് കീഴിലുള്ള ഡാറ്റാബേസുള്ള ഒരു സെർവറിൽ നിങ്ങൾ ഈ സ്റ്റഫ് ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ തിരഞ്ഞെടുപ്പ് acpi_cpufreq + permormance ആണ്. ആവശ്യമുണ്ടെങ്കിൽ പോലും പ്രശ്നങ്ങൾ ഉണ്ടാകും.
Intel_pstate അല്പം വ്യത്യസ്തമായ ഡ്രൈവറാണ്. ഇപ്പോൾ ഇതിന് മുൻഗണന നൽകിയിട്ടുണ്ട്, കാരണം ഇത് പിന്നീട് മികച്ചതാണ്.
അതനുസരിച്ച്, ഗവർണർ പ്രകടനം മാത്രമാണ്. Ondemand, powersave എന്നിവയും മറ്റെല്ലാം നിങ്ങളെക്കുറിച്ചല്ല.
നിങ്ങൾ പവർസേവ് പ്രവർത്തനക്ഷമമാക്കുകയാണെങ്കിൽ PostgreSQL-ന്റെ വിശദാംശ വിശകലനത്തിന്റെ ഫലങ്ങൾ വ്യത്യസ്തമായേക്കാം, കാരണം പ്രായോഗികമായി നിങ്ങളുടെ ഡാറ്റാബേസിന് കീഴിലുള്ള സിപിയു പൂർണ്ണമായും പ്രവചനാതീതമായ രീതിയിൽ പ്രവർത്തിക്കും.
ഈ ഇനങ്ങൾ ഡിഫോൾട്ടായി ഉൾപ്പെടുത്തിയേക്കാം. അവർ അത് ഡിഫോൾട്ടായി ഓണാക്കിയിട്ടുണ്ടോ എന്ന് ശ്രദ്ധാപൂർവ്വം നോക്കുക. ഇത് ശരിക്കും ഒരു വലിയ പ്രശ്നമാകാം.
അവസാനം, എല്ലാ ദിവസവും ഈ വിഷയത്തിൽ മുന്നേറുന്ന ഞങ്ങളുടെ PosgreSQL- കൺസൾട്ടിംഗ് DBA ടീമിലെ മാക്സ് ബോഗുക്കും അലക്സി ലെസോവ്സ്കിയും ഉള്ള ആൺകുട്ടികൾക്ക് നന്ദി പറയാൻ ഞാൻ ആഗ്രഹിച്ചു. ഞങ്ങളുടെ ക്ലയന്റുകൾക്ക് വേണ്ടി ഞങ്ങളാൽ കഴിയുന്നത് ചെയ്യാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, അതിലൂടെ എല്ലാം അവർക്ക് വേണ്ടി പ്രവർത്തിക്കും. ഇത് വ്യോമയാന സുരക്ഷാ നിർദ്ദേശങ്ങൾ പോലെയാണ്. ഇവിടെ എല്ലാം രക്തത്തിൽ എഴുതിയിരിക്കുന്നു. ഈ പരിപ്പ് ഓരോന്നും ഏതെങ്കിലും തരത്തിലുള്ള പ്രശ്നത്തിന്റെ പ്രക്രിയയിൽ കാണപ്പെടുന്നു. അവ നിങ്ങളുമായി പങ്കിടുന്നതിൽ എനിക്ക് സന്തോഷമുണ്ട്.
ചോദ്യങ്ങൾ:
നന്ദി! ഉദാഹരണത്തിന്, ഒരു കമ്പനി പണം ലാഭിക്കാനും ഡാറ്റാബേസും ആപ്ലിക്കേഷൻ ലോജിക്കും ഒരു സെർവറിൽ സ്ഥാപിക്കാനും ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അല്ലെങ്കിൽ കമ്പനി ഒരു കണ്ടെയ്നറിൽ PostgreSQL പ്രവർത്തിക്കുന്ന മൈക്രോസർവീസ് ആർക്കിടെക്ചറുകളുടെ ഫാഷനബിൾ ട്രെൻഡ് പിന്തുടരുകയാണെങ്കിൽ. എന്താണ് തന്ത്രം? Sysctl ആഗോളതലത്തിൽ മുഴുവൻ കേർണലിനെയും ബാധിക്കും. ഒരു കണ്ടെയ്നറിൽ വെവ്വേറെ പ്രവർത്തിക്കുന്ന തരത്തിൽ sysctls എങ്ങനെയെങ്കിലും വെർച്വലൈസ് ചെയ്തതായി ഞാൻ കേട്ടിട്ടില്ല. ഒരു cgroup മാത്രമേ ഉള്ളൂ, അവിടെ നിയന്ത്രണത്തിന്റെ ഒരു ഭാഗം മാത്രമേ ഉള്ളൂ. ഇതുപയോഗിച്ച് നിങ്ങൾക്ക് എങ്ങനെ ജീവിക്കാനാകും? അല്ലെങ്കിൽ നിങ്ങൾക്ക് പ്രകടനം വേണമെങ്കിൽ, ഒരു പ്രത്യേക ഹാർഡ്‌വെയർ സെർവറിൽ PostgreSQL പ്രവർത്തിപ്പിച്ച് ട്യൂൺ ചെയ്യണോ?
നിങ്ങളുടെ ചോദ്യത്തിന് ഞങ്ങൾ മൂന്ന് തരത്തിൽ ഉത്തരം നൽകി. ട്യൂൺ ചെയ്യാൻ കഴിയുന്ന ഒരു ഹാർഡ്‌വെയർ സെർവറിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കുന്നില്ലെങ്കിൽ, വിശ്രമിക്കുക, ഈ ക്രമീകരണങ്ങളില്ലാതെ എല്ലാം നന്നായി പ്രവർത്തിക്കും. നിങ്ങൾക്ക് ഈ ക്രമീകരണങ്ങൾ നടത്തേണ്ട ഒരു ലോഡ് ഉണ്ടെങ്കിൽ, ഈ ക്രമീകരണങ്ങളേക്കാൾ നേരത്തെ നിങ്ങൾ ഇരുമ്പ് സെർവറിലേക്ക് വരും.
എന്താണ് പ്രശ്നം? ഇതൊരു വെർച്വൽ മെഷീനാണെങ്കിൽ, മിക്കവാറും നിങ്ങൾക്ക് നിരവധി പ്രശ്നങ്ങൾ ഉണ്ടാകും, ഉദാഹരണത്തിന്, മിക്ക വെർച്വൽ മെഷീനുകളിലും ഡിസ്കിന്റെ ലേറ്റൻസി തികച്ചും പൊരുത്തമില്ലാത്തതാണ്. ഡിസ്ക് ത്രൂപുട്ട് നല്ലതാണെങ്കിലും, ചെക്ക് പോയിന്റിന്റെ സമയത്തോ WAL-ലേക്ക് എഴുതുന്ന സമയത്തോ സംഭവിച്ച ശരാശരി ത്രൂപുട്ടിനെ കാര്യമായി ബാധിക്കാത്ത ഒരു I/O ഇടപാട് പരാജയപ്പെട്ടാൽ, ഡാറ്റാബേസ് ഇതിൽ നിന്ന് വളരെയധികം കഷ്ടപ്പെടും. നിങ്ങൾ ഈ പ്രശ്നങ്ങൾ നേരിടുന്നതിന് മുമ്പ് ഇത് ശ്രദ്ധിക്കും.
നിങ്ങൾക്ക് ഒരേ സെർവറിൽ NGINX ഉണ്ടെങ്കിൽ, നിങ്ങൾക്കും ഇതേ പ്രശ്നം ഉണ്ടാകും. പങ്കിട്ട ഓർമ്മയ്ക്കായി അവൻ പോരാടും. ഇവിടെ വിവരിച്ചിരിക്കുന്ന പ്രശ്‌നങ്ങളിലേക്ക് നിങ്ങൾ എത്തില്ല.
എന്നാൽ മറുവശത്ത്, ഈ പാരാമീറ്ററുകളിൽ ചിലത് നിങ്ങൾക്ക് ഇപ്പോഴും പ്രസക്തമായിരിക്കും. ഉദാഹരണത്തിന്, sysctl ഉപയോഗിച്ച് dirty_ratio സജ്ജമാക്കുക, അങ്ങനെ അത് ഭ്രാന്തനാകില്ല - ഏത് സാഹചര്യത്തിലും, ഇത് സഹായിക്കും. ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ, നിങ്ങൾക്ക് ഡിസ്കുമായി ആശയവിനിമയം ഉണ്ടാകും. അത് തെറ്റായ പാറ്റേൺ അനുസരിച്ചായിരിക്കും. ഞാൻ കാണിച്ച പാരാമീറ്ററുകൾക്കുള്ള സ്ഥിരസ്ഥിതിയാണിത്. ഏത് സാഹചര്യത്തിലും അവ മാറ്റുന്നതാണ് നല്ലത്.
എന്നാൽ NUMA-യിൽ പ്രശ്നങ്ങൾ ഉണ്ടാകാം. ഉദാഹരണത്തിന്, VmWare, കൃത്യമായി വിപരീത ക്രമീകരണങ്ങളുള്ള NUMA-യിൽ നന്നായി പ്രവർത്തിക്കുന്നു. ഇവിടെ നിങ്ങൾ തിരഞ്ഞെടുക്കണം - ഒരു ഇരുമ്പ് സെർവർ അല്ലെങ്കിൽ ഇരുമ്പ് അല്ലാത്ത ഒന്ന്.
എനിക്ക് Amazon AWS-മായി ബന്ധപ്പെട്ട ഒരു ചോദ്യമുണ്ട്. അവ മുൻകൂട്ടി ക്രമീകരിച്ച ചിത്രങ്ങൾ ഉണ്ട്. അതിലൊന്നിന്റെ പേര് ആമസോൺ ആർഡിഎസ് എന്നാണ്. അവരുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് എന്തെങ്കിലും ഇഷ്ടാനുസൃത ക്രമീകരണങ്ങൾ ഉണ്ടോ?
അവിടെ ക്രമീകരണങ്ങളുണ്ട്, പക്ഷേ അവ വ്യത്യസ്ത ക്രമീകരണങ്ങളാണ്. ഡാറ്റാബേസ് ഈ കാര്യം എങ്ങനെ ഉപയോഗിക്കും എന്നതിന്റെ അടിസ്ഥാനത്തിൽ ഞങ്ങൾ ഇവിടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കോൺഫിഗർ ചെയ്യുന്നു. രൂപപ്പെടുത്തൽ പോലുള്ള പാരാമീറ്ററുകൾ ഞങ്ങൾ ഇപ്പോൾ എവിടെ പോകണമെന്ന് നിർണ്ണയിക്കുന്നു. അതായത്, ഞങ്ങൾക്ക് വളരെയധികം വിഭവങ്ങൾ ആവശ്യമാണ്, ഞങ്ങൾ ഇപ്പോൾ അവ തിന്നും. ഇതിനുശേഷം, ആമസോൺ ആർഡിഎസ് ഈ ഉറവിടങ്ങൾ കർശനമാക്കുകയും പ്രകടനം അവിടെ കുറയുകയും ചെയ്യുന്നു. ആളുകൾ ഈ വിഷയത്തിൽ എങ്ങനെ കുഴപ്പമുണ്ടാക്കാൻ തുടങ്ങുന്നു എന്നതിന് വ്യക്തിഗത കഥകളുണ്ട്. ചിലപ്പോൾ വളരെ വിജയകരമായി പോലും. എന്നാൽ ഇതിന് OS ക്രമീകരണങ്ങളുമായി യാതൊരു ബന്ധവുമില്ല. ഇത് മേഘത്തെ ഹാക്ക് ചെയ്യുന്നതുപോലെയാണ്. അത് വേറെ കഥയാണ്.
വലിയ TLB-യുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ സുതാര്യമായ വലിയ പേജുകൾക്ക് ഫലമില്ലാത്തത് എന്തുകൊണ്ട്?
കൊടുക്കരുത്. ഇത് പല തരത്തിൽ വിശദീകരിക്കാം. എന്നാൽ വാസ്തവത്തിൽ അവർ അത് നൽകുന്നില്ല. PostgreSQL-ന്റെ ചരിത്രം എന്താണ്? തുടക്കത്തിൽ, ഇത് പങ്കിട്ട മെമ്മറിയുടെ ഒരു വലിയ ഭാഗം അനുവദിക്കുന്നു. അവ സുതാര്യമാണോ അല്ലയോ എന്നത് പൂർണ്ണമായും അപ്രസക്തമാണ്. തുടക്കത്തിൽ അവർ വേറിട്ടുനിൽക്കുന്നു എന്ന വസ്തുത എല്ലാം വിശദീകരിക്കുന്നു. ധാരാളം മെമ്മറി ഉണ്ടെങ്കിൽ നിങ്ങൾ പങ്കിട്ട_മെമ്മറി സെഗ്‌മെന്റ് പുനർനിർമ്മിക്കണമെങ്കിൽ, സുതാര്യമായ വലിയ പേജുകൾ പ്രസക്തമായിരിക്കും. PostgreSQL-ൽ, ഇത് തുടക്കത്തിൽ തന്നെ ഒരു വലിയ ഭാഗത്തിൽ അനുവദിച്ചിരിക്കുന്നു, അത്രയേയുള്ളൂ, തുടർന്ന് പ്രത്യേകിച്ച് ഒന്നും സംഭവിക്കുന്നില്ല. നിങ്ങൾക്ക് തീർച്ചയായും ഇത് ഉപയോഗിക്കാൻ കഴിയും, എന്നാൽ അത് എന്തെങ്കിലും വീണ്ടും അനുവദിക്കുമ്പോൾ പങ്കിട്ട_മെമ്മറിയുടെ ഒരു അഴിമതി ലഭിക്കാനുള്ള അവസരമുണ്ട്. PostgreSQL-ന് ഇതിനെക്കുറിച്ച് അറിയില്ല.
അവലംബം: www.habr.com