ചെറിയ ക്വറികൾ പ്രവർത്തിക്കുന്നു, വലുത് പരാജയപ്പെടുന്നു: ഏത് പാക്കറ്റ് വലിപ്പമാണ്?
SQL Server ഡ്രൈവറിന്റെ പാക്കറ്റുകൾ, MySQL സന്ദേശ പരിധികൾ, ഒരു IP പാതയുടെ MTU എന്നിവ വ്യത്യസ്ത യൂണിറ്റുകളാണ്. വലിപ്പത്തെ ആശ്രയിക്കുന്ന പരാജയം അവയെ പരസ്പരം മാറ്റാവുന്നതാക്കുന്നില്ല.
ചെറിയ ക്വറികൾ തിരികെ വരുന്നു, വലുത് തൂങ്ങുന്നു അല്ലെങ്കിൽ വീഴുന്നു, പാക്കറ്റ് വലിപ്പത്തിൽ എന്തോ കുഴപ്പമുണ്ടെന്നാണ് ആദ്യ ഊഹം. ആ ഊഹം സാധാരണയായി ശരിയാണ്, ഏതാണ്ട് എപ്പോഴും തെറ്റായ പാളിയെ ലക്ഷ്യമിടുന്നു. മൂന്ന് ക്രമീകരണങ്ങൾ പാക്കറ്റ് എന്ന വാക്ക് പങ്കിടുന്നു, ബന്ധമില്ലാത്ത മൂന്ന് കാര്യങ്ങൾ അളക്കുന്നു: ഒരു ഡാറ്റാബേസ് ഡ്രൈവറുടെ ഗതാഗത പാക്കേജിംഗ്, ഒരു ഡാറ്റാബേസ് സർവറിന്റെ സന്ദേശ പരിധി, IP പാതയുടെ പരമാവധി സംപ്രേഷണ യൂണിറ്റ്. ഒന്ന് ക്രമീകരിച്ച് മറ്റൊന്ന് സൃഷ്ടിച്ച ലക്ഷണം ശരിയാക്കുന്നതാണ് അഞ്ച് മിനിറ്റ് പ്രശ്നം ഒരു ആഴ്ചയിലെ ട്യൂണിംഗ് ആക്കുന്ന വഴി. താഴെയുള്ള ക്രമമാണ് എനിക്ക് ഏറ്റവും കുറഞ്ഞ സമയം എടുത്തത്.
മൂന്ന് പാളികൾ, ഒരു പൊതു വാക്ക്
താഴെയുള്ള ഓരോ വരിയും വ്യത്യസ്ത ഉടമയുള്ള വ്യത്യസ്ത യൂണിറ്റാണ്, അവയിൽ ഏതിനെക്കുറിച്ചും മറ്റുള്ളവയിൽ നിന്ന് അനുമാനിക്കാനാവില്ല. ഒരു ഡാറ്റാബേസ് സന്ദേശം നിരവധി TCP സെഗ്മെന്റുകളിലും നിരവധി IP പാക്കറ്റുകളിലും വ്യാപിക്കാം, അതിനാൽ അതിന്റെ അനുവദനീയ വലിപ്പം വർധിപ്പിക്കുന്നത് പാത വിശാലമാക്കുന്നില്ല, ഡ്രൈവർ ക്രമീകരണം കുറയ്ക്കുന്നത് ഇന്റർഫേസ് MTU മാറ്റുന്ന അതേ പ്രവർത്തനമല്ല. വാക്ക് മൂന്ന് വ്യത്യസ്ത കോൺഫിഗറേഷൻ ഫയലുകളിൽ വരുന്നു, അതിനാൽ അത് തിരയുമ്പോൾ ബന്ധമില്ലാത്ത മൂന്ന് ഉത്തരങ്ങൾ വരുന്നു. ആദ്യം പിശകിന്റെ വാചകം വായിക്കുക, പിന്നെ ഏത് ഫയൽ തുറക്കണമെന്ന് തീരുമാനിക്കുക.
| Setting or observation | Unit it describes |
|---|---|
| SQL Server client network packet setting | The provider's transport packaging for that connection |
| MySQL communication packet limit | A database message, such as one statement, row or replication event |
| IP path MTU | The largest IP packet the path carries without fragmentation handling |
കോൺഫിഗറേഷൻ ഫയൽ തുറക്കുന്നതിന് മുമ്പ് പരാജയപ്പെട്ട പ്രവർത്തനം ഏത് പാളിയിലാണെന്ന് എഴുതുക. പിശകിന്റെ വാചകം സാധാരണയായി അത് പറയുന്നു, ആ വാചകമാണ് ആളുകൾ ഒഴിവാക്കുന്ന ഭാഗം.
അതിന്റെ ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് ദാതാവിനെ തിരിച്ചറിയുക
SQL Server ന് ആപ്ലിക്കേഷൻ, ഡ്രൈവർ അല്ലെങ്കിൽ ദാതാവിന്റെ പേര്, പതിപ്പ്, ഫലപ്രദമായ കണക്ഷൻ കോൺഫിഗറേഷൻ എന്നിവ രേഖപ്പെടുത്തുക. ഒരു ഡയഗ്നോസ്റ്റിക് സ്ക്രിപ്റ്റും ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷനും വ്യത്യസ്ത ദാതാക്കളിലൂടെ ഒരേ സർവറിൽ എത്താം, അതിനാൽ ഒന്നിന് സഹായിക്കുന്ന ക്രമീകരണം മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ദാതാക്കളുടെ സ്വതവേയുള്ള മൂല്യങ്ങൾ വ്യത്യസ്തമാണ്, കണക്ഷൻ സ്ട്രിംഗിലെ സമാന നാമമുള്ള ഫീൽഡ് എല്ലാ ദാതാക്കളും അത് ഒരേ രീതിയിൽ വ്യാഖ്യാനിക്കുന്നു എന്നതിന് തെളിവല്ല.
പഴയ പരിഹാരം അതിന്റെ സിന്താക്സ് ഉപയോഗിച്ചത് കൊണ്ട് മാത്രം പരിപാലിക്കുന്ന ഡ്രൈവറെ പഴയതിന് മാറ്റരുത്. നിലവിലെ ഡോക്യുമെന്റേഷൻ ആ പഴയ ഘടകങ്ങൾക്കെതിരെ പുതിയ വികസനം പ്രോത്സാഹിപ്പിക്കുന്നില്ല, അവയുടെ പരിമിതികൾ പാരമ്പര്യമായി സ്വീകരിക്കുന്നത് ഒരു ക്രമീകരണത്തിന് മോശം വ്യാപാരമാണ്.
സന്ദേശം നിരസിക്കുന്നത് പാതയുടെ തടസ്സമല്ല
MySQL 8.4 ൽ, ആശയവിനിമയ പാക്കറ്റ് ഡോക്യുമെന്റേഷൻ ബാധകമായ പരിധിക്കെതിരെ വളരെ വലിയ സ്റ്റേറ്റ്മെന്റ്, വരി അല്ലെങ്കിൽ ബൈനറി-ലോഗ് ഇവന്റ് നിരസിക്കുന്നത് വിവരിക്കുന്നു, ക്ലയന്റിന്റെയും സർവറിന്റെയും പരിധികൾ രണ്ടും പ്രധാനമായേക്കാം. അത് ഡാറ്റാബേസ് പാളിയിലെ നിരസിക്കലാണ്, നെറ്റ്വർക്ക് ഭീമാകാരമായ IP പാക്കറ്റ് വഹിക്കണമെന്ന പ്രസ്താവനയല്ല. യഥാർത്ഥ പിശകും പ്രശ്നകരമായ സന്ദേശത്തിന്റെ രൂപവും വായിക്കുക: ഒട്ടേറെ ചെറിയ വരികൾ കൊണ്ടുള്ള വലിയ ഫലം ഒരു ഭീമാകാരമായ വരിയിൽ നിന്ന് വ്യത്യസ്തമായ കേസാണ്, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു.
MariaDB ഇൻസ്റ്റലേഷനുകൾക്ക് അവയുടെ സ്വന്തം പതിപ്പിന്റെ രേഖപ്പെടുത്തിയ പരിധികളും ഡയഗ്നോസ്റ്റിക്സും വേണം. MySQL ന്റെ സ്വതവേയുള്ള മൂല്യങ്ങൾ MariaDB ലേക്ക് പകർത്തുന്നത് അധിക ഘട്ടങ്ങളോടെയുള്ള ഊഹമാണ്.
പാതയുടെ തെളിവ് യഥാർത്ഥത്തിൽ എങ്ങനെയിരിക്കും
പാത-വലിപ്പ പ്രശ്നത്തിന് സ്വന്തം വിരലടയാളമുണ്ട്: ഒരു പ്രത്യേക റൂട്ടിലും വിലാസ കുടുംബത്തിലും പുനർനിർമ്മിക്കാവുന്ന വലിപ്പാധിഷ്ഠിത ഗതാഗത പരാജയം, ടണലിന്റെ അധിക ഭാരം ഉൾപ്പെട്ട് കണ്ടെത്തൽ പ്രതികരണം പാത അനുവദിക്കുന്നതുപോലെ പെരുമാറുന്നു. ഒറ്റ ടൈംഔട്ട് അതിനെ മന്ദഗതിയിലുള്ള ക്വറിയിൽ നിന്നും ഡ്രൈവർ ബഗ്ഗിൽ നിന്നും സർവർ വശത്തെ പരിധിയിൽ നിന്നും വേർതിരിക്കുന്നില്ല, ടൈംഔട്ടിനെ MTU പ്രശ്നങ്ങളുടെ തെളിവായി കാണുന്നത് ആത്മവിശ്വാസത്തോടെ തെറ്റായ പാളിയിലേക്ക് അയക്കുന്നു.
നിങ്ങൾ പാത പരീക്ഷിക്കുകയാണെങ്കിൽ, ലക്ഷ്യം, അക്കൗണ്ട്, ജോലിഭാരം എന്നിവ സ്ഥിരമായി വയ്ക്കുക, ഒരേയൊരു ചരം നിങ്ങൾ പരിശോധിക്കുന്ന വലിപ്പമായിരിക്കട്ടെ. മൂന്ന് കാര്യങ്ങൾ മാറിയ പരീക്ഷണം ഏതാണ് പ്രധാനമായിരുന്നത് എന്ന് ഒന്നും പറയുന്നില്ല.
ഒരു രേഖപ്പെടുത്തിയ ചരം മാറ്റുക, പിന്നീട് അത് രേഖപ്പെടുത്തുക
ലക്ഷ്യം, അക്കൗണ്ട്, ദാതാവ്, ജോലിഭാരം എന്നിവ സ്ഥിരമായി നിർത്തുക, യഥാർത്ഥ മൂല്യം രേഖപ്പെടുത്തുക, ഒരു പിന്തുണയുള്ള മാറ്റം പ്രയോഗിക്കുക, ഫലം രേഖപ്പെടുത്തുക. ഒരു പരീക്ഷണം വിജയിപ്പിക്കുന്ന ചെറിയ ക്രമീകരണം ആ പരീക്ഷിച്ച സ്റ്റാക്കിനെക്കുറിച്ച് ഉപകാരപ്രദമായ തെളിവാണ്; അത് സാർവത്രിക ഒപ്റ്റിമം അല്ല, യഥാർത്ഥ പരാജയത്തിന് കാരണം എന്താണെന്ന് സ്ഥാപിക്കുന്നുമില്ല. ഇവ വ്യത്യസ്ത അവകാശവാദങ്ങളാണ്, ആദ്യത്തേതിന് മാത്രം ഒരു പരീക്ഷണം പിന്തുണ നൽകുന്നു.
തിരിച്ചറിഞ്ഞ പരിധി അതിന്റെ സ്വന്തം പാളിയിൽ പരിഹരിക്കുക, പിന്നെ ഏത് പാളിയായിരുന്നു എന്ന് രേഖപ്പെടുത്തുക. ആ കുറിപ്പാണ് പ്രശ്നം പാതയായിരുന്നതിനാൽ അടുത്ത ആളെ ഡ്രൈവർ ട്യൂൺ ചെയ്യുന്നതിൽ നിന്ന് തടയുന്നത്.