VPN വഴിയുള്ള psql സമയ അളവ്: നെറ്റ്വർക്ക് കാത്തിരിപ്പിനെ ക്വറിയുടെ ജോലിയിൽ നിന്ന് വേർതിരിക്കൽ

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

psql ടൈമർ യഥാർത്ഥത്തിൽ അളക്കുന്നത്

\timing on ക്ലയന്റ് പ്രസ്താവന സോക്കറ്റിലേക്ക് എഴുതുന്നതിന് തൊട്ടുമുമ്പ് സ്റ്റോപ്പ്വാച്ച് ആരംഭിച്ച് ആ ഫലത്തിന്റെ അവസാന വരി വായിച്ചപ്പോൾ നിർത്തുന്നു. സെർവറിന്റെ സ്വന്തം എക്സിക്യൂഷൻ ആ വിൻഡോയിലെവിടെയോ ഉണ്ട്, പാക്കറ്റുകൾ ടണലിൽ ചെലവഴിക്കുന്ന ഓരോ മില്ലിസെക്കൻഡും അങ്ങനെതന്നെ. ഔട്ട്പുട്ടിൽ ഒന്നും അവയെ വേർതിരിക്കുന്നില്ല. EXPLAIN സംഖ്യയും അച്ചടിക്കുന്നു, പക്ഷേ അത് സെർവർ ഉണ്ടാക്കുന്നതാണ്, ക്ലയന്റിന്റെ കാത്തിരിപ്പ് അത് ഒഴിവാക്കുന്നു. രണ്ട് സംഖ്യകൾ, രണ്ട് വ്യത്യസ്ത ചോദ്യങ്ങൾ.

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

psql "host=db.internal port=5432 dbname=appdb user=app" \
  -c "\timing on" \
  -c "select count(*) from orders where created_at > now() - interval '1 day';"

ഫലത്തിന്റെ കൈമാറ്റം സംഖ്യയിൽ ഇപ്പോഴും ഉണ്ട്, അതാണ് ഇവിടെ വേണ്ടത്. പുതിയ വിളി ചേർക്കുന്ന കണക്ഷൻ, ആധികാരികതാ കൈമാറ്റം എന്നിവ ഇനി അതിൽ ഉൾപ്പെടുന്നില്ല.

ഒരു പ്രസ്താവന മൂന്ന് വഴികളിൽ താരതമ്യം ചെയ്യുക

അതേ പ്രസ്താവന Unix സോക്കറ്റ്, LAN വിലാസം, VPN ഹോസ്റ്റ് നാമം എന്നിവയിലൂടെ പ്രവർത്തിപ്പിച്ച് മൂന്നും താരതമ്യം ചെയ്യുക. അവസാനത്തേത് മാത്രം മന്ദഗതിയിലാണെങ്കിൽ, ക്വറി ചരമല്ല.

ഓരോ വിളിയും ആദ്യം കണക്റ്റുചെയ്ത് പിന്നീടാണ് പ്രസ്താവന അളക്കുന്നത്, അതിനാൽ കണക്ഷൻ ചെലവ് സംഖ്യയ്ക്ക് പുറത്തും കൈമാറ്റം അകത്തും നിലനിൽക്കുന്നു. WHERE ഖണ്ഡിക, വരി എണ്ണം, ക്ലയന്റ് യന്ത്രം എന്നിവ സമാനമായി നിർത്തുക, അല്ലെങ്കിൽ നിങ്ങൾ വഴികളല്ല, ജോലിഭാരം താരതമ്യം ചെയ്യുകയാണ്.

psql -h /var/run/postgresql -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h 10.40.0.12 -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h db.vpn.internal -U app -d appdb -c "\timing on" -c "select count(*) from orders;"

LAN ൽ വ്യത്യാസം സാധാരണയായി അവഗണിക്കാവുന്നത്ര ചെറുതാണ്; VPN വഴി പലപ്പോഴും അങ്ങനെയല്ല. മൂന്ന് ഫലങ്ങൾ ക്രമീകരിച്ചാൽ ഏത് കാത്തിരിപ്പിനെ ആക്രമിക്കണമെന്ന് പിന്നീട് അറിയാം.

മന്ദഗതിയിലുള്ള പ്രാദേശിക സോക്കറ്റ് എന്നാൽ സെർവറിന്റെ ജോലി അല്ലെങ്കിൽ ആസൂത്രണം. മന്ദഗതിയിലുള്ള LAN ഫലം എന്നാൽ ക്വറി അല്ലെങ്കിൽ അത് നീക്കുന്ന അളവ്. VPN ഫലം മാത്രം മന്ദഗതിയിലാകുന്നത് വഴിയിൽ കാലതാമസം, MTU അല്ലെങ്കിൽ ലഭ്യമായ ബാൻഡ്വിഡ്ത്ത് എന്നാണ് അർത്ഥം, ഇൻഡക്സ് മാറ്റങ്ങളൊന്നും അത് ശരിയാക്കുന്നില്ല.

സെർവറിന്റെ സ്വന്തം എക്സിക്യൂഷൻ സമയം എടുക്കുക

സെർവറിന് എത്ര സമയം ചെലവഴിച്ചുവെന്ന് റിപ്പോർട്ട് ചെയ്യാം, ക്ലയന്റിന്റെ സംഖ്യയ്ക്ക് എതിരായി വെക്കേണ്ടത് ആ സംഖ്യയാണ്. ANALYZE-നൊപ്പം EXPLAIN പ്രസ്താവന പ്രവർത്തിപ്പിച്ച് പ്ലാനിനുള്ളിൽ ആസൂത്രണ-എക്സിക്യൂഷൻ സമയം അച്ചടിക്കുന്നു, BUFFERS കാഷ് സ്വഭാവം ചേർക്കുന്നു, അത് ചൂടുള്ള ഓട്ടത്തെ തണുത്തതിനോട് വിശദീകരിക്കാറുണ്ട്. എഴുതാൻ ഉദ്ദേശമില്ലെങ്കിൽ അത് എഴുത്ത് പ്രസ്താവനകളിലേക്ക് തിരിക്കരുത്. വായനയ്ക്ക് മാത്രമുള്ള പകർപ്പിൽ ഇത് തുടങ്ങാൻ ഏറ്റവും സുരക്ഷിതമായ സ്ഥലമാണ്, കൂടാതെ psql റഫറൻസ് ടൈമറിന്റെ ക്ലയന്റ് വശ പരിധി രേഖപ്പെടുത്തുന്നു.

ആപ്ലിക്കേഷൻ ഇതിനകം പ്രവർത്തിപ്പിക്കുന്ന പ്രസ്താവനകൾക്ക്, pg_stat_statements ഒന്നും വീണ്ടും പ്രവർത്തിപ്പിക്കാതെ സെർവർ വശ എക്സിക്യൂഷൻ ശേഖരിക്കുന്നു. വരികൾ സാധാരണവൽക്കരിച്ച ക്വറിക്ക്, അതിനാൽ ഒരു എൻട്രി നിരവധി വിളിസ്ഥലങ്ങളെ ഉൾക്കൊള്ളാം.

select calls, round(mean_exec_time::numeric, 2) as mean_ms, rows
from pg_stat_statements
order by mean_exec_time desc
limit 5;

നിരനാമങ്ങൾ റിലീസ് അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു: PostgreSQL 13 ഉം അതിനുശേഷമുള്ളവയും mean_exec_time കാണിക്കുന്നു, പഴയ പതിപ്പുകൾ അതിനെ mean_time എന്ന് വിളിക്കുന്നു, അതിനാൽ പരിശോധിക്കുക \d pg_stat_statements ഉപയോഗിച്ച്, ആ ക്വറി പിശക് നൽകിയാൽ. ഈ മൂല്യങ്ങൾ ആസൂത്രണം ഒഴിവാക്കുന്നു, നിങ്ങളുടെ ക്ലയന്റിലേക്കുള്ള യാത്രയും ഒഴിവാക്കുന്നു. ആ ഒഴിവാക്കലാണ് അവയെ താരതമ്യത്തിന് ഉപയോഗപ്രദമാക്കുന്നത്.

പോക്കും വരവും എണ്ണുക, മില്ലിസെക്കൻഡുകൾ മാത്രമല്ല

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

പ്രസ്താവനകളുടെ എണ്ണം കണക്കാക്കാതെ അളക്കുക. ആകെ വായിച്ച്, റിപ്പോർട്ട് ഒരിക്കൽ പ്രവർത്തിപ്പിച്ച്, പിന്നീട് വീണ്ടും വായിച്ച് കുറയ്ക്കുക.

select sum(calls) as calls from pg_stat_statements;
-- run the report here
select sum(calls) as calls from pg_stat_statements;

ഡെൽറ്റ വലുതാണെങ്കിൽ, സെർവറിൽ ഓരോ പ്രസ്താവനയും വിലകുറഞ്ഞതാണെങ്കിൽ, ബാച്ചിംഗാണ് ഫലം നൽകുന്ന പരിഹാരം. ആശ്രിത ക്വറികൾ കൂട്ടിച്ചേർക്കുക, ഒരു സെറ്റ് അധിഷ്ഠിത പ്രസ്താവന ഉപയോഗിക്കുക, അല്ലെങ്കിൽ കർസറിൽ നിന്ന് ലൂപ്പ് നയിക്കുക. ഇന്ററാക്ടീവ് psql ൽ, \set FETCH_COUNT 1000 വലിയ ഫലം ബാച്ചുകളായി വരാൻ അനുവദിക്കുന്നു, കൈമാറ്റത്തിന്റെയും ക്ലയന്റ് മെമ്മറിയുടെയും സ്വഭാവം മാറ്റുന്നു. അത് സെർവർ ജോലി കുറയ്ക്കുന്നില്ല, അതിനാൽ മന്ദഗതിയിലുള്ള ക്വറിയെ രക്ഷിക്കില്ല.

വീണ്ടും അയയ്ക്കലുകൾക്കും MTU തടസ്സങ്ങൾക്കും ടണൽ പരിശോധിക്കുക

ചെറിയ പ്രസ്താവനകൾ വേഗത്തിലും വലിയ ഫലങ്ങൾ പകുതി വഴിയിൽ നിൽക്കുന്നതും ആണെങ്കിൽ, ക്വറി സാധാരണയായി കുഴപ്പമില്ല, വഴിയല്ല. അടിസ്ഥാന ലിങ്കിനേക്കാൾ MTU കുറവുള്ള ടണൽ തടയപ്പെട്ട ICMP-യോടൊപ്പം ചേരുമ്പോൾ കൃത്യമായി ആ മാതൃക സൃഷ്ടിക്കുന്നു: ആദ്യ പാക്കറ്റുകൾ വരുന്നു, വലിയവ അപ്രത്യക്ഷമാകുന്നു, വീണ്ടും ശ്രമിക്കുന്നതുവരെ കൈമാറ്റം തൂങ്ങിക്കിടക്കുന്നു. ക്ലയന്റ് വശത്തെ വീണ്ടും അയയ്ക്കൽ കൗണ്ടറുകൾ അത് കാണിക്കുന്നു.

മനഃപൂർവം മന്ദഗതിയിലുള്ള കൈമാറ്റം നടക്കുമ്പോൾ സോക്കറ്റും കെർണൽ കൗണ്ടറുകളും ശ്രദ്ധിക്കുക. വീണ്ടും അയയ്ക്കൽ തുകകൾ സഞ്ചിതമാണ്, അതിനാൽ ഒരു സാമ്പിൾ വായിക്കുന്നതിന് പകരം മുമ്പും ശേഷവും രേഖപ്പെടുത്തുക.

ss -tin dst 10.40.0.12
netstat -s | grep -iE "retransmit|segments retransmitted"
ping -M do -s 1400 -c 3 10.40.0.12

കൈമാറ്റത്തിനിടയിൽ ഉയരുന്ന വീണ്ടും അയയ്ക്കലുകൾ, 1400 ബൈറ്റിൽ വിജയിച്ച് 1472 ൽ പരാജയപ്പെടുന്ന ping-നോടൊപ്പം, ഡാറ്റാബേസ് പ്രശ്നമല്ല, MTU പ്രശ്നമാണ് സൂചിപ്പിക്കുന്നത്. ടണൽ ഇന്റർഫേസിന്റെ MTU കുറയ്ക്കുകയോ ഗേറ്റ്വേയിൽ MSS ഞെക്കുകയോ ചെയ്യുന്നതാണ് സാധാരണ പരിഹാരം, അതേ മൂന്ന് കമാന്റുകൾ പിന്നീട് അത് സ്ഥിരീകരിക്കുന്നു. കൈമാറ്റം ഇപ്പോഴും മന്ദഗതിയിലായിരിക്കെ വീണ്ടും അയയ്ക്കലുകൾ പരന്നാൽ, നഷ്ടത്തിലല്ല, ടണലിന് അനുവദിച്ച ബാൻഡ്വിഡ്ത്തിൽ നോക്കുക.

ചെറിയ ക്രമം അടുത്ത മന്ദഗതിയിലുള്ള റിപ്പോർട്ട് ഉൾക്കൊള്ളുന്നു: ഒരു പ്രസ്താവന പ്രാദേശികമായി, LAN ൽ, VPN വഴി താരതമ്യം ചെയ്യുക; EXPLAIN അല്ലെങ്കിൽ pg_stat_statements ൽ നിന്ന് സെർവർ എക്സിക്യൂഷൻ വായിക്കുക; ഒരിക്കൽ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പും ശേഷവും വിളികൾ എണ്ണുക; വലിയ ഫലം നീങ്ങുമ്പോൾ വീണ്ടും അയയ്ക്കലുകൾ ശ്രദ്ധിക്കുക. ഓരോ ഘട്ടവും വഴിയുടെ ഒരു വശം ഒഴിവാക്കുന്നു. ഏത് ഘടകം പുനരാരംഭിക്കണമെന്ന് ഊഹിക്കാൻ അവയൊന്നും ആവശ്യപ്പെടുന്നില്ല.