ശാസ്ത്രീയ പോക്ക് രീതി, അല്ലെങ്കിൽ ബെഞ്ച്മാർക്കുകളും ഒപ്റ്റിമൈസേഷൻ അൽഗോരിതം ഉപയോഗിച്ച് ഒരു ഡാറ്റാബേസ് കോൺഫിഗറേഷൻ എങ്ങനെ തിരഞ്ഞെടുക്കാം

ഹലോ

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

അതിനാൽ, പോയിന്റിലേക്ക്.

ഞങ്ങൾക്ക് ഒരു ചുമതലയുണ്ടെന്ന് കരുതുക: ഏതെങ്കിലും തരത്തിലുള്ള ജോലികൾക്കായി ഒരു നിശ്ചിത സേവന സംവിധാനം സജ്ജീകരിക്കുക.

ഈ സൃഷ്ടിയെക്കുറിച്ച് അറിയാം: അതെന്താണ്, ഈ ജോലിയുടെ ഗുണനിലവാരം എങ്ങനെ അളക്കുന്നു, ഈ ഗുണനിലവാരം അളക്കുന്നതിനുള്ള മാനദണ്ഡം എന്താണ്.

ഇത് കൂടുതലോ കുറവോ അറിയാവുന്നതും മനസ്സിലാക്കിയതും ആണെന്ന് നമുക്ക് അനുമാനിക്കാം: ഈ സേവന സംവിധാനത്തിൽ (അല്ലെങ്കിൽ അതിനൊപ്പം) ജോലി ചെയ്യുന്നത് എങ്ങനെയെന്ന്.

“കൂടുതലോ കുറവോ” - ഇതിനർത്ഥം ഒരു നിശ്ചിത ഉപകരണം, യൂട്ടിലിറ്റി, സേവനം എന്നിവ തയ്യാറാക്കാൻ (അല്ലെങ്കിൽ എവിടെ നിന്നെങ്കിലും അത് നേടാനും) സാധ്യമാണ്, അത് ഉൽ‌പാദനത്തിൽ വേണ്ടത്ര മതിയായ ടെസ്റ്റ് ലോഡ് ഉപയോഗിച്ച് സിസ്റ്റത്തിലേക്ക് സമന്വയിപ്പിക്കാനും പ്രയോഗിക്കാനും കഴിയും. ഉൽപ്പാദനത്തിൽ പ്രവർത്തിക്കാൻ മതിയായ സാഹചര്യങ്ങളിൽ.

ശരി, ഈ സേവന സംവിധാനത്തിനായുള്ള ഒരു കൂട്ടം ക്രമീകരണ പാരാമീറ്ററുകൾ അറിയാമെന്ന് നമുക്ക് അനുമാനിക്കാം, അത് അതിന്റെ പ്രവർത്തനത്തിന്റെ ഉൽപ്പാദനക്ഷമതയുടെ അടിസ്ഥാനത്തിൽ ഈ സിസ്റ്റം കോൺഫിഗർ ചെയ്യാൻ ഉപയോഗിക്കാം.

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

നന്നായി. ഇത് മിക്കവാറും എല്ലായ്‌പ്പോഴും അങ്ങനെയാണ്.

നിങ്ങൾക്ക് ഇവിടെ എന്ത് ചെയ്യാൻ കഴിയും?

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

ആ. സിസ്റ്റത്തിന് അതിന്റെ കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾക്കായി ഒരു പ്രത്യേക സെറ്റ് മൂല്യങ്ങളുടെ രൂപത്തിൽ ഏതെങ്കിലും തരത്തിലുള്ള കോൺഫിഗറേഷൻ നൽകുക.

ഈ ടൂൾ-യൂട്ടിലിറ്റി, ലോഡ് ജനറേറ്റർ ഉപയോഗിച്ച് അതിലേക്ക് ഒരു ടെസ്റ്റ് ലോഡ് പ്രയോഗിക്കുക.
മൂല്യം നോക്കുക - പ്രതികരണം അല്ലെങ്കിൽ സിസ്റ്റത്തിന്റെ ഗുണനിലവാരത്തിന്റെ മെട്രിക്.

രണ്ടാമത്തെ ചിന്ത ഇത് വളരെ നീണ്ട സമയമാണെന്ന നിഗമനമായിരിക്കാം.

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

ശരി, നിങ്ങൾക്ക് മനസിലാക്കാനും ഓർമ്മിക്കാനും കഴിയുന്നത് ഇതാ.

സേവന സിസ്റ്റം ക്രമീകരണ പാരാമീറ്ററുകളുടെ മൂല്യങ്ങളുടെ ഗണത്തിൽ ചില മൂല്യങ്ങളുടെ ക്രമമായി ഒരു വെക്റ്റർ ഉണ്ടെന്ന് നിങ്ങൾക്ക് കണ്ടെത്താനാകും.

അത്തരം ഓരോ വെക്‌ടറും, മറ്റ് കാര്യങ്ങൾ തുല്യമാണ് (ഈ വെക്‌ടർ അതിനെ ബാധിക്കാത്തതിനാൽ), മെട്രിക്കിന്റെ പൂർണ്ണമായ ഒരു നിശ്ചിത മൂല്യവുമായി പൊരുത്തപ്പെടുന്നു - ഒരു ടെസ്റ്റ് ലോഡിന് കീഴിലുള്ള സിസ്റ്റത്തിന്റെ പ്രവർത്തനത്തിന്റെ ഗുണനിലവാരത്തിന്റെ സൂചകം.

അതായത്

നമുക്ക് സിസ്റ്റം കോൺഫിഗറേഷൻ വെക്റ്ററിനെ ഇങ്ങനെ സൂചിപ്പിക്കാം എവിടെ ; എവിടെ — സിസ്റ്റം കോൺഫിഗറേഷൻ പരാമീറ്ററുകളുടെ എണ്ണം, ഇതിൽ എത്ര പരാമീറ്ററുകൾ ഉണ്ട്.

ഇതിനോട് യോജിക്കുന്ന മെട്രിക്കിന്റെ മൂല്യവും എന്ന് സൂചിപ്പിക്കാം
, അപ്പോൾ നമുക്ക് ഒരു ഫംഗ്ഷൻ ലഭിക്കും:

ശരി, അപ്പോൾ: എല്ലാം ഉടനടി വരുന്നു, എന്റെ കാര്യത്തിൽ: എന്റെ വിദ്യാർത്ഥി ദിനങ്ങളിൽ നിന്ന് ഏറെക്കുറെ മറന്നുപോയി, ഒരു ഫംഗ്ഷന്റെ തീവ്രത തിരയുന്നതിനുള്ള അൽഗോരിതങ്ങൾ.

ശരി, എന്നാൽ ഇവിടെ സംഘടനാപരവും പ്രായോഗികവുമായ ഒരു ചോദ്യം ഉയർന്നുവരുന്നു: ഏത് അൽഗോരിതം ഉപയോഗിക്കണം.

1. അർത്ഥത്തിൽ - നിങ്ങൾക്ക് കൈകൊണ്ട് കുറച്ച് കോഡ് ചെയ്യാൻ കഴിയും.
2. അത് പ്രവർത്തിക്കുന്നതിന്, അതായത്. എക്സ്ട്രീം കണ്ടെത്തി (ഒന്ന് ഉണ്ടെങ്കിൽ), നന്നായി, കോർഡിനേറ്റ് ഇറക്കത്തേക്കാൾ വേഗത്തിലെങ്കിലും.

അത്തരം അൽഗരിതങ്ങൾ ഇതിനകം നടപ്പിലാക്കിയിട്ടുള്ളതും ഏതെങ്കിലും രൂപത്തിൽ കോഡിൽ ഉപയോഗിക്കാൻ തയ്യാറായതുമായ ചില പരിതസ്ഥിതികളിലേക്ക് നമ്മൾ നോക്കേണ്ടതുണ്ടെന്ന് ആദ്യ പോയിന്റ് സൂചന നൽകുന്നു.
ശരി, എനിക്കറിയാം python и cran-r

രണ്ടാമത്തെ പോയിന്റ് അർത്ഥമാക്കുന്നത് നിങ്ങൾ അൽഗോരിതങ്ങളെ കുറിച്ചും അവ എന്തൊക്കെയാണ്, അവയുടെ ആവശ്യകതകൾ എന്തൊക്കെയാണ്, അവരുടെ ജോലിയുടെ സവിശേഷതകളെ കുറിച്ചും വായിക്കേണ്ടതുണ്ട്.

അവർ നൽകുന്നത് ഉപയോഗപ്രദമായ പാർശ്വഫലങ്ങൾ ആകാം - ഫലങ്ങൾ, അല്ലെങ്കിൽ നേരിട്ട് അൽഗോരിതം.

അല്ലെങ്കിൽ അൽഗോരിതത്തിന്റെ ഫലങ്ങളിൽ നിന്ന് അവ ലഭിക്കും.

ഒരുപാട് ഇൻപുട്ട് വ്യവസ്ഥകളെ ആശ്രയിച്ചിരിക്കുന്നു.

ഉദാഹരണത്തിന്, ചില കാരണങ്ങളാൽ, നിങ്ങൾക്ക് വേഗത്തിൽ ഫലം ലഭിക്കണമെങ്കിൽ, നിങ്ങൾ ഗ്രേഡിയന്റ് ഡിസെന്റ് അൽഗോരിതങ്ങളിലേക്ക് നോക്കുകയും അവയിലൊന്ന് തിരഞ്ഞെടുക്കുകയും വേണം.

അല്ലെങ്കിൽ, സമയം അത്ര പ്രധാനമല്ലെങ്കിൽ, നിങ്ങൾക്ക്, ഉദാഹരണത്തിന്, ഒരു ജനിതക അൽഗോരിതം പോലെയുള്ള ഒപ്റ്റിമൈസേഷൻ രീതികൾ ഉപയോഗിക്കാം.

ഈ സമീപനത്തിന്റെ പ്രവർത്തനം പരിഗണിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു, സിസ്റ്റം കോൺഫിഗറേഷൻ തിരഞ്ഞെടുക്കുന്നു, ഒരു ജനിതക അൽഗോരിതം ഉപയോഗിച്ച്, അടുത്തതായി, സംസാരിക്കാൻ: ലബോറട്ടറി ജോലി.

യഥാർത്ഥം:

1. ഒരു സേവന സംവിധാനമെന്ന നിലയിൽ ഉണ്ടാകട്ടെ: oracle xe 18c
2. ഇത് ഇടപാട് പ്രവർത്തനവും ലക്ഷ്യവും നൽകട്ടെ: ഇടപാടുകൾ/സെക്കൻഡിൽ സബ്ഡാറ്റാബേസിന്റെ സാധ്യമായ ഏറ്റവും ഉയർന്ന ത്രൂപുട്ട് നേടുന്നതിന്.
3. ഡാറ്റയുമായി പ്രവർത്തിക്കുന്നതിന്റെ സ്വഭാവത്തിലും ജോലിയുടെ സന്ദർഭത്തിലും ഇടപാടുകൾ വളരെ വ്യത്യസ്തമായിരിക്കും.
   വലിയ അളവിലുള്ള ടാബുലാർ ഡാറ്റ പ്രോസസ്സ് ചെയ്യാത്ത ഇടപാടുകളാണ് ഇവയെന്ന് സമ്മതിക്കാം.
   അവർ വീണ്ടും ചെയ്യുന്നതിനേക്കാൾ കൂടുതൽ പൂർവാവസ്ഥയിലാക്കുന്ന ഡാറ്റ സൃഷ്ടിക്കുന്നില്ല, വലിയ ശതമാനം വരികളും വലിയ പട്ടികകളും പ്രോസസ്സ് ചെയ്യുന്നില്ല എന്ന അർത്ഥത്തിൽ.

ഈ ടേബിളിൽ ഒരു ചെറിയ എണ്ണം സൂചികകളുള്ള, കൂടുതലോ കുറവോ വലിയ പട്ടികയിൽ ഒരു വരി മാറ്റുന്ന ഇടപാടുകളാണ് ഇവ.

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

നിരാകരണം - ഞങ്ങൾ സബ്ഡിബി ക്രമീകരണങ്ങളെക്കുറിച്ച് പ്രത്യേകം സംസാരിക്കുകയാണെങ്കിൽ.

കാരണം, പൊതുവായ സാഹചര്യത്തിൽ, ഉദാഹരണത്തിന്, ടാബുലാർ ഡാറ്റ കൂടാതെ/അല്ലെങ്കിൽ ടാബുലാർ മോഡൽ ഉപയോഗിച്ച് ഉപയോക്തൃ വർക്കിന്റെ രൂപകൽപ്പന കാരണം, SQL സെഷനുകൾക്കിടയിൽ ട്രാൻസാക്ഷൻ ലോക്കുകൾ ഉണ്ടാകാം.

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

അതിനാൽ, പരീക്ഷണത്തിന്റെ പരിശുദ്ധിക്കായി, ഞങ്ങൾ ഈ ഘടകം ഒഴിവാക്കും, താഴെ ഞാൻ കൃത്യമായി എങ്ങനെ വ്യക്തമാക്കും.

1. ഡാറ്റാബേസിലേക്ക് സമർപ്പിച്ച SQL കമാൻഡുകളുടെ 100% ഡിഎംഎൽ കമാൻഡുകൾ ആണെന്ന് നമുക്ക് ഉറപ്പിക്കാം.
   ഉപഡാറ്റബേസിനൊപ്പം ഉപയോക്തൃ വർക്കിന്റെ സ്വഭാവസവിശേഷതകൾ ടെസ്റ്റുകളിൽ സമാനമാകട്ടെ.
   അതായത്: skl സെഷനുകളുടെ എണ്ണം, ടാബുലാർ ഡാറ്റ, skl സെഷനുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു.
2. സബ്ഡി പ്രവർത്തിക്കുന്നു FORCE LOGGING, ARCHIVELOG മോഡുകൾ. സബ്ഡി ലെവലിൽ ഫ്ലാഷ്ബാക്ക്-ഡാറ്റാബേസ് മോഡ് ഓഫാക്കിയിരിക്കുന്നു.
3. ലോഗുകൾ വീണ്ടും ചെയ്യുക: ഒരു പ്രത്യേക ഫയൽ സിസ്റ്റത്തിൽ, ഒരു പ്രത്യേക "ഡിസ്കിൽ" സ്ഥിതിചെയ്യുന്നു;
   ഡാറ്റാബേസിന്റെ ബാക്കി ഭൗതിക ഘടകങ്ങൾ: മറ്റൊന്നിൽ, പ്രത്യേക ഫയൽ സിസ്റ്റത്തിൽ, ഒരു പ്രത്യേക "ഡിസ്കിൽ":

ഭൗതിക ഉപകരണത്തെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ. ലബോറട്ടറി ഡാറ്റാബേസ് ഘടകങ്ങൾ

SQL> select status||' '||name from v$controlfile;
 /db/u14/oradata/XE/control01.ctl
SQL> select GROUP#||' '||MEMBER from v$logfile;
1 /db/u02/oradata/XE/redo01_01.log
2 /db/u02/oradata/XE/redo02_01.log
SQL> select FILE_ID||' '||TABLESPACE_NAME||' '||round(BYTES/1024/1024,2)||' '||FILE_NAME as col from dba_data_files;
4 UNDOTBS1 2208 /db/u14/oradata/XE/undotbs1_01.dbf
2 SLOB 128 /db/u14/oradata/XE/slob01.dbf
7 USERS 5 /db/u14/oradata/XE/users01.dbf
1 SYSTEM 860 /db/u14/oradata/XE/system01.dbf
3 SYSAUX 550 /db/u14/oradata/XE/sysaux01.dbf
5 MONITOR 128 /db/u14/oradata/XE/monitor.dbf
SQL> !cat /proc/mounts | egrep "/db/u[0-2]"
/dev/vda1 /db/u14 ext4 rw,noatime,nodiratime,data=ordered 0 0
/dev/mapper/vgsys-ora_redo /db/u02 xfs rw,noatime,nodiratime,attr2,nobarrier,inode64,logbsize=256k,noquota 0 0

തുടക്കത്തിൽ, ഈ ലോഡ് അവസ്ഥകളിൽ, ഇടപാട് സബ്ഡി ഉപയോഗിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു SLOB- യൂട്ടിലിറ്റി
ഇതിന് അതിശയകരമായ ഒരു സവിശേഷതയുണ്ട്, ഞാൻ രചയിതാവിനെ ഉദ്ധരിക്കാം:

SLOB യുടെ ഹൃദയഭാഗത്ത് "SLOB രീതി" ആണ്. പ്ലാറ്റ്‌ഫോമുകൾ പരീക്ഷിക്കാൻ SLOB രീതി ലക്ഷ്യമിടുന്നു
അപേക്ഷ തർക്കമില്ലാതെ. ഒരാൾക്ക് പരമാവധി ഹാർഡ്‌വെയർ പ്രകടനം നടത്താൻ കഴിയില്ല
ആപ്ലിക്കേഷൻ കോഡ് ഉപയോഗിക്കുന്നത്, ഉദാഹരണത്തിന്, ആപ്ലിക്കേഷൻ ലോക്കിംഗ് അല്ലെങ്കിൽ പോലും
Oracle ഡാറ്റാബേസ് ബ്ലോക്കുകൾ പങ്കിടുന്നു. അത് ശരിയാണ് - ഡാറ്റ പങ്കിടുമ്പോൾ ഓവർഹെഡ് ഉണ്ട്
ഡാറ്റ ബ്ലോക്കുകളിൽ! എന്നാൽ SLOB-അതിന്റെ ഡിഫോൾട്ട് വിന്യാസത്തിൽ-അത്തരം തർക്കങ്ങളിൽ നിന്ന് മുക്തമാണ്.

ഈ പ്രഖ്യാപനം: യോജിക്കുന്നു, അത്.
cl സെഷനുകളുടെ സമാന്തരതയുടെ അളവ് നിയന്ത്രിക്കുന്നത് സൗകര്യപ്രദമാണ്, ഇതാണ് പ്രധാനം -t യൂട്ടിലിറ്റി സമാരംഭിക്കുക runit.sh SLOB ൽ നിന്ന്
സബ്‌ഡിയിലേക്ക് അയയ്‌ക്കുന്ന ടെക്‌സ്‌റ്റ് സന്ദേശങ്ങളുടെ എണ്ണത്തിൽ, ഓരോ ടെക്‌സ്‌റ്റ് സെഷനിലും പാരാമീറ്ററിലും ഡിഎംഎൽ കമാൻഡുകളുടെ ശതമാനം നിയന്ത്രിക്കപ്പെടുന്നു. UPDATE_PCT
വെവ്വേറെയും വളരെ സൗകര്യപ്രദമായും: SLOB സ്വയം, ലോഡ് സെഷനു മുമ്പും ശേഷവും - ഒരു സ്റ്റാറ്റ്സ്പാക്ക് അല്ലെങ്കിൽ awr-സ്നാപ്പ്ഷോട്ടുകൾ (തയ്യാറാക്കാൻ സജ്ജമാക്കിയിരിക്കുന്നത്) തയ്യാറാക്കുന്നു.

എന്നിരുന്നാലും, അത് മാറി SLOB 30 സെക്കൻഡിൽ താഴെ ദൈർഘ്യമുള്ള SQL സെഷനുകളെ പിന്തുണയ്ക്കുന്നില്ല.
അതിനാൽ, ഞാൻ ആദ്യം ലോഡറിന്റെ സ്വന്തം, തൊഴിലാളി-കർഷക പതിപ്പ് കോഡ് ചെയ്തു, തുടർന്ന് അത് പ്രവർത്തനത്തിൽ തുടർന്നു.

വ്യക്തതയ്ക്കായി, ലോഡർ എന്താണ് ചെയ്യുന്നതെന്നും അത് എങ്ങനെ ചെയ്യുന്നുവെന്നും ഞാൻ വ്യക്തമാക്കാം.
അടിസ്ഥാനപരമായി, ലോഡർ ഇതുപോലെ കാണപ്പെടുന്നു:

തൊഴിലാളി കോഡ്

function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"

$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off

define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum

declare
 v_upto number;
 v_key  number;
 v_tots number;
 v_cts  number;
begin
 select max(col1) into v_upto from system.testtab_&&wnum;
 SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 v_tots := &&period + v_cts;
 while v_cts <= v_tots
 loop
  v_key:=abs(mod(dbms_random.random,v_upto));
  if v_key=0 then
   v_key:=1;
  end if;
  update system.testtab_&&wnum t
  set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
  where t.col1=v_key
  ;
  commit;
  SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 end loop;
end;
/

exit
__EOF__
}
export -f dotx

തൊഴിലാളികളെ ഈ രീതിയിൽ വിക്ഷേപിക്കുന്നു:

ഓടുന്ന തൊഴിലാളികൾ

echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
 echo "sql-session: ${i}" >> "$v_logfile"
 dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
wait

തൊഴിലാളികൾക്കുള്ള പട്ടികകൾ ഇതുപോലെയാണ് തയ്യാറാക്കിയിരിക്കുന്നത്:

പട്ടികകൾ സൃഷ്ടിക്കുന്നു

function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off

define wnum="$1"
define ts_name="slob"

begin
 execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/

create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable

seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"

ആ. ഓരോ തൊഴിലാളിക്കും (പ്രായോഗികമായി: DB-യിൽ ഒരു പ്രത്യേക SQL സെഷൻ) ഒരു പ്രത്യേക പട്ടിക സൃഷ്ടിക്കപ്പെടുന്നു, അതിലൂടെ തൊഴിലാളി പ്രവർത്തിക്കുന്നു.

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

ലോഡിന് കീഴിലുള്ള സബ്‌ഡിയുടെ പ്രവർത്തനം വിവരിക്കുന്ന സ്റ്റാറ്റ്‌സ്‌പാക്ക് റിപ്പോർട്ടിന്റെ ഒരു ഭാഗം

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          2929910313 XE                  1 07-Sep-20 23:12 18.0.0.0.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     billing.izhevsk1 Linux x86 64-bit           2     2       1         15.6

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:       1630 07-Sep-20 23:12:27       55        .7
  End Snap:       1631 07-Sep-20 23:20:29       62        .6
   Elapsed:       8.03 (mins) Av Act Sess:       8.4
   DB time:      67.31 (mins)      DB CPU:      15.01 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:     1,392M              Std Block Size:         8K
     Shared Pool:       288M                  Log Buffer:   103,424K

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                8.4                0.0        0.00        0.20
       DB CPU(s):                1.9                0.0        0.00        0.04
       Redo size:        7,685,765.6              978.4
   Logical reads:           60,447.0                7.7
   Block changes:           47,167.3                6.0
  Physical reads:                8.3                0.0
 Physical writes:              253.4                0.0
      User calls:               42.6                0.0
          Parses:               23.2                0.0
     Hard parses:                1.2                0.0
W/A MB processed:                1.0                0.0
          Logons:                0.5                0.0
        Executes:           15,756.5                2.0
       Rollbacks:                0.0                0.0
    Transactions:            7,855.1

ലബോറട്ടറി ജോലികളിലേക്ക് മടങ്ങുന്നു.
മറ്റ് കാര്യങ്ങൾ തുല്യമായതിനാൽ, ലബോറട്ടറി സബ്‌ഡേറ്റാബേസിന്റെ ഇനിപ്പറയുന്ന പാരാമീറ്ററുകളുടെ മൂല്യങ്ങൾ ഞങ്ങൾ വ്യത്യാസപ്പെടുത്തും:

1. ഡാറ്റാബേസ് ലോഗ് ഗ്രൂപ്പുകളുടെ വലുപ്പം. മൂല്യ പരിധി: [32, 1024] MB;
2. ഡാറ്റാബേസിലെ ജേണൽ ഗ്രൂപ്പുകളുടെ എണ്ണം. മൂല്യ പരിധി: [2,32];
3. log_archive_max_processes മൂല്യ പരിധി: [1,8];
4. commit_logging രണ്ട് മൂല്യങ്ങൾ അനുവദനീയമാണ്: batch|immediate;
5. commit_wait രണ്ട് മൂല്യങ്ങൾ അനുവദനീയമാണ്: wait|nowait;
6. log_buffer മൂല്യ പരിധി: [2,128] MB.
7. log_checkpoint_timeout മൂല്യ പരിധി: [60,1200] സെക്കൻഡ്
8. db_writer_processes മൂല്യ പരിധി: [1,4]
9. undo_retention മൂല്യ പരിധി: [30;300] സെക്കൻഡ്
10. transactions_per_rollback_segment മൂല്യ പരിധി: [1,8]
11. disk_asynch_io രണ്ട് മൂല്യങ്ങൾ അനുവദനീയമാണ്: true|false;
12. filesystemio_options ഇനിപ്പറയുന്ന മൂല്യങ്ങൾ അനുവദനീയമാണ്: none|setall|directIO|asynch;
13. db_block_checking ഇനിപ്പറയുന്ന മൂല്യങ്ങൾ അനുവദനീയമാണ്: OFF|LOW|MEDIUM|FULL;
14. db_block_checksum ഇനിപ്പറയുന്ന മൂല്യങ്ങൾ അനുവദനീയമാണ്: OFF|TYPICAL|FULL;

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

പക്ഷേ.

ഒപ്റ്റിമൈസേഷൻ അൽഗോരിതം തന്നെ താരതമ്യേന വേഗത്തിൽ നമുക്ക് ഇത് വ്യക്തമാക്കുമെന്ന് കാണിക്കുക എന്നതാണ് ലബോറട്ടറി പ്രവർത്തനത്തിന്റെ ലക്ഷ്യം.

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

അതിനാൽ, ഇപ്പോൾ കോഡിനെക്കുറിച്ച്.
ഞാൻ മുകളിൽ സംസാരിച്ചു cran-r, അതായത്: ഇഷ്‌ടാനുസൃതമാക്കിയ സിസ്റ്റത്തിലുള്ള എല്ലാ കൃത്രിമത്വങ്ങളും ഒരു R സ്‌ക്രിപ്റ്റിന്റെ രൂപത്തിലാണ് ക്രമീകരിച്ചിരിക്കുന്നത്.

യഥാർത്ഥ ടാസ്‌ക്, വിശകലനം, മെട്രിക് മൂല്യം പ്രകാരമുള്ള തിരഞ്ഞെടുപ്പ്, സിസ്റ്റം സ്റ്റേറ്റ് വെക്‌ടറുകൾ: ഇതൊരു പാക്കേജാണ് GA (പ്രമാണീകരണം)
ഈ സാഹചര്യത്തിൽ, പാക്കേജ് വളരെ അനുയോജ്യമല്ല, അതായത് വെക്റ്ററുകൾ (ക്രോമസോമുകൾ, പാക്കേജിന്റെ അടിസ്ഥാനത്തിൽ) ഒരു ഫ്രാക്ഷണൽ ഭാഗമുള്ള സംഖ്യകളുടെ സ്ട്രിംഗുകളുടെ രൂപത്തിൽ വ്യക്തമാക്കണമെന്ന് പ്രതീക്ഷിക്കുന്നു.

എന്റെ വെക്റ്റർ, ക്രമീകരണ പാരാമീറ്ററുകളുടെ മൂല്യങ്ങളിൽ നിന്ന്: ഇവ 14 അളവുകളാണ് - പൂർണ്ണസംഖ്യകളും സ്ട്രിംഗ് മൂല്യങ്ങളും.

സ്ട്രിംഗ് മൂല്യങ്ങൾക്ക് ചില പ്രത്യേക സംഖ്യകൾ നൽകുന്നതിലൂടെ പ്രശ്നം തീർച്ചയായും ഒഴിവാക്കാനാകും.

അങ്ങനെ, അവസാനം, R സ്ക്രിപ്റ്റിന്റെ പ്രധാന ഭാഗം ഇതുപോലെ കാണപ്പെടുന്നു:

വിളിക്കുക GA::ga

cat( "", file=v_logfile, sep="n", append=F)

pSize = 10
elitism_value=1
pmutation_coef=0.8
pcrossover_coef=0.1
iterations=50

gam=GA::ga(type="real-valued", fitness=evaluate,
lower=c(32,2, 1,1,1,2,60,1,30,1,0,0, 0,0), upper=c(1024,32, 8,10,10,128,800,4,300,8,10,40, 40,30),
popSize=pSize,
pcrossover = pcrossover_coef,
pmutation = pmutation_coef,
maxiter=iterations,
run=4,
keepBest=T)
cat( "GA-session is done" , file=v_logfile, sep="n", append=T)
gam@solution

ഇവിടെ, സഹായത്തോടെ lower и upper സബ്റൂട്ടീൻ ആട്രിബ്യൂട്ടുകൾ ga അടിസ്ഥാനപരമായി, തിരയൽ സ്ഥലത്തിന്റെ ഒരു പ്രദേശം വ്യക്തമാക്കിയിട്ടുണ്ട്, അതിനുള്ളിൽ ഫിറ്റ്നസ് ഫംഗ്ഷന്റെ പരമാവധി മൂല്യം ലഭിക്കുന്ന അത്തരം വെക്റ്ററിനായി (അല്ലെങ്കിൽ വെക്റ്ററുകൾ) ഒരു തിരയൽ നടത്തും.

ga സബ്റൂട്ടീൻ ഫിറ്റ്നസ് ഫംഗ്ഷൻ പരമാവധിയാക്കിക്കൊണ്ട് ഒരു തിരയൽ നടത്തുന്നു.

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

അതായത്: നൽകിയിരിക്കുന്ന സബ്‌ഡി സജ്ജീകരണവും സബ്‌ഡിയിൽ നൽകിയിരിക്കുന്ന ലോഡും ഉപയോഗിച്ച് എത്ര എണ്ണം: സബ്‌ഡി ഒരു സെക്കൻഡിൽ ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യുന്നു.

അതായത്, തുറക്കുമ്പോൾ, ഫിറ്റ്നസ് ഫംഗ്ഷനിൽ ഇനിപ്പറയുന്ന മൾട്ടി-സ്റ്റെപ്പ് നടത്തണം:

1. സംഖ്യകളുടെ ഇൻപുട്ട് വെക്റ്റർ പ്രോസസ്സ് ചെയ്യുന്നു - സബ്ഡാറ്റ പാരാമീറ്ററുകൾക്കുള്ള മൂല്യങ്ങളാക്കി മാറ്റുന്നു.
2. ഒരു നിശ്ചിത വലുപ്പത്തിലുള്ള ഒരു നിശ്ചിത എണ്ണം റെഡോ ഗ്രൂപ്പുകൾ സൃഷ്ടിക്കാനുള്ള ശ്രമം. മാത്രമല്ല, ശ്രമം പരാജയപ്പെട്ടേക്കാം.
   പരീക്ഷണത്തിന്റെ പരിശുദ്ധിക്കായി സബ്ഡിയിൽ ഇതിനകം നിലവിലിരുന്ന മാഗസിൻ ഗ്രൂപ്പുകൾ - d.b. ഇല്ലാതാക്കി.
3. മുമ്പത്തെ പോയിന്റ് വിജയകരമാണെങ്കിൽ: ഡാറ്റാബേസിലേക്ക് കോൺഫിഗറേഷൻ പാരാമീറ്ററുകളുടെ മൂല്യങ്ങൾ വ്യക്തമാക്കുന്നു (വീണ്ടും: ഒരു പരാജയം ഉണ്ടാകാം)
4. മുമ്പത്തെ ഘട്ടം വിജയകരമാണെങ്കിൽ: സബ്ഡി നിർത്തുക, സബ്ഡി ആരംഭിക്കുക, അങ്ങനെ പുതുതായി വ്യക്തമാക്കിയ പാരാമീറ്റർ മൂല്യങ്ങൾ പ്രാബല്യത്തിൽ വരും. (വീണ്ടും: ഒരു തകരാറുണ്ടാകാം)
5. മുമ്പത്തെ ഘട്ടം വിജയകരമാണെങ്കിൽ: ഒരു ലോഡ് ടെസ്റ്റ് നടത്തുക. സബ്ഡിയിൽ നിന്ന് മെട്രിക്സ് നേടുക.
6. സബ്ഡിയെ അതിന്റെ യഥാർത്ഥ അവസ്ഥയിലേക്ക് തിരികെ കൊണ്ടുവരിക, അതായത്. അധിക ലോഗ് ഗ്രൂപ്പുകൾ ഇല്ലാതാക്കുക, യഥാർത്ഥ സബ്ഡേറ്റാബേസ് കോൺഫിഗറേഷൻ പ്രവർത്തനത്തിലേക്ക് തിരികെ നൽകുക.

ഫിറ്റ്നസ് ഫംഗ്ഷൻ കോഡ്

evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
 opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")

opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
 opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")

opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
 opn$disk_asynch_io="false"
} 

opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
 opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
 opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
 opn$filesystemio_options="asynch"
}

opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
 opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
 opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
 opn$db_block_checking="FULL"
}

opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
 opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
 opn$db_block_checksum="FULL"
}

v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)

rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
 cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
 return (0)
}

v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) {  v_rc=1 }

if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("immediate")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("abort")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=run_test()
v_metric=getmetric()

rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}

അത്. എല്ലാ ജോലികളും: ഫിറ്റ്നസ് ഫംഗ്ഷനിൽ നിർവഹിച്ചു.

ga-subroutine വെക്റ്ററുകൾ അല്ലെങ്കിൽ, കൂടുതൽ ശരിയായി, ക്രോമസോമുകൾ പ്രോസസ്സ് ചെയ്യുന്നു.
ഇതിൽ, ഫിറ്റ്നസ് ഫംഗ്ഷൻ വലിയ മൂല്യങ്ങൾ സൃഷ്ടിക്കുന്ന ജീനുകളുള്ള ക്രോമസോമുകളുടെ തിരഞ്ഞെടുപ്പാണ് ഞങ്ങൾക്ക് ഏറ്റവും പ്രധാനം.

ഇത്, സാരാംശത്തിൽ, ഒരു എൻ-ഡൈമൻഷണൽ സെർച്ച് സ്പേസിൽ ഒരു വെക്റ്റർ ഉപയോഗിച്ച് ഒപ്റ്റിമൽ സെറ്റ് ക്രോമസോമുകൾക്കായി തിരയുന്ന പ്രക്രിയയാണ്.

വളരെ വ്യക്തം, വിശദമായി വിശദീകരണം, R-കോഡിന്റെ ഉദാഹരണങ്ങൾക്കൊപ്പം, ഒരു ജനിതക അൽഗോരിതത്തിന്റെ പ്രവർത്തനം.

രണ്ട് സാങ്കേതിക പോയിന്റുകൾ പ്രത്യേകം ശ്രദ്ധിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ചടങ്ങിൽ നിന്നുള്ള സഹായ കോളുകൾ evaluate, ഉദാഹരണത്തിന്, സ്റ്റോപ്പ്-സ്റ്റാർട്ട്, സബ്ഡി പാരാമീറ്ററിന്റെ മൂല്യം സജ്ജമാക്കൽ എന്നിവ അടിസ്ഥാനമാക്കിയാണ് നടപ്പിലാക്കുന്നത് cran-r പ്രവർത്തനങ്ങൾ system2

ഇതിന്റെ സഹായത്തോടെ: ചില ബാഷ് സ്ക്രിപ്റ്റ് അല്ലെങ്കിൽ കമാൻഡ് വിളിക്കുന്നു.

ഉദാഹരണത്തിന്:

set_db_parameter

set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")

x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
 cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (attributes(x)$status)
}
else {
 cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (0)
}
}

രണ്ടാമത്തെ പോയിന്റ് വരിയാണ്, evaluate ഫംഗ്‌ഷനുകൾ, ഒരു പ്രത്യേക മെട്രിക് മൂല്യവും അതിന്റെ അനുബന്ധ ട്യൂണിംഗ് വെക്‌ടറും ഒരു ലോഗ് ഫയലിലേക്ക് സംരക്ഷിക്കുന്നു:

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)

ഇത് പ്രധാനമാണ്, കാരണം ഈ ഡാറ്റ അറേയിൽ നിന്ന്, ട്യൂണിംഗ് വെക്റ്ററിന്റെ ഏത് ഘടകങ്ങളാണ് മെട്രിക് മൂല്യത്തിൽ കൂടുതലോ കുറവോ സ്വാധീനം ചെലുത്തുന്നത് എന്നതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ നേടാനാകും.

അതായത്: ആട്രിബ്യൂട്ട്-ഇംപോർട്ടംസ് വിശകലനം നടത്താൻ കഴിയും.

അപ്പോൾ എന്ത് സംഭവിക്കാം?

ഗ്രാഫ് രൂപത്തിൽ, നിങ്ങൾ ആരോഹണ മെട്രിക് ക്രമത്തിൽ ടെസ്റ്റുകൾ ഓർഡർ ചെയ്താൽ, ചിത്രം ഇപ്രകാരമാണ്:

മെട്രിക്കിന്റെ അങ്ങേയറ്റത്തെ മൂല്യങ്ങളുമായി പൊരുത്തപ്പെടുന്ന ചില ഡാറ്റ:

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

നന്നായി. ഇത് ധാരാളം അല്ലെങ്കിൽ കുറച്ച് ആണോ, ~8 ആയിരം ടിപിഎസ്: ഒരു പ്രത്യേക ചോദ്യം.
ലബോറട്ടറി ജോലിയുടെ ചട്ടക്കൂടിനുള്ളിൽ, ഈ കണക്ക് പ്രധാനമല്ല, എന്താണ് പ്രധാനം ഡൈനാമിക്സ്, ഈ മൂല്യം എങ്ങനെ മാറുന്നു.

ഇവിടെ ചലനാത്മകത നല്ലതാണ്.
ക്രോമസോം വെക്റ്ററുകളിലൂടെ അടുക്കുന്ന ഗ-അൽഗോരിതം എന്ന മെട്രിക്സിന്റെ മൂല്യത്തെ കുറഞ്ഞത് ഒരു ഘടകമെങ്കിലും ഗണ്യമായി സ്വാധീനിക്കുന്നു എന്നത് വ്യക്തമാണ്: കവർ ചെയ്യുന്നു.
കർവ് മൂല്യങ്ങളുടെ സാമാന്യം ഊർജ്ജസ്വലമായ ചലനാത്മകത വിലയിരുത്തുമ്പോൾ, ഗണ്യമായി ചെറുതാണെങ്കിലും സ്വാധീനം ചെലുത്തുന്ന ഒരു ഘടകം കൂടിയുണ്ട്.

ഇവിടെയാണ് നിങ്ങൾക്ക് ആവശ്യമുള്ളത് attribute-importance ആട്രിബ്യൂട്ടുകൾ (നന്നായി, ഈ സാഹചര്യത്തിൽ, ട്യൂണിംഗ് വെക്റ്ററിന്റെ ഘടകങ്ങൾ) എന്താണെന്നും അവ മെട്രിക് മൂല്യത്തെ എത്രമാത്രം സ്വാധീനിക്കുന്നുവെന്നും മനസിലാക്കാൻ വിശകലനം.
ഈ വിവരങ്ങളിൽ നിന്ന്: കാര്യമായ ആട്രിബ്യൂട്ടുകളിലെ മാറ്റങ്ങൾ ഏതൊക്കെ ഘടകങ്ങളെ ബാധിച്ചുവെന്ന് മനസ്സിലാക്കുക.

ഓട്ടം attribute-importance വ്യത്യസ്ത വഴികളിൽ സാധ്യമാണ്.

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

ഞങ്ങളുടെ കാര്യത്തിൽ, ലോഡ് ടെസ്റ്റുകളിൽ ഡാറ്റാബേസിൽ നിന്ന് ലഭിച്ച ഒരു മെട്രിക് ആണ് പ്രതികരണ വേരിയബിൾ: tps;
ട്യൂണിംഗ് വെക്റ്ററിന്റെ ഘടകങ്ങളാണ് ആട്രിബ്യൂട്ടുകൾ.

അതിനാൽ ഇവിടെ randomForest രണ്ട് സംഖ്യകളുള്ള ഓരോ മോഡൽ ആട്രിബ്യൂട്ടിന്റെയും പ്രാധാന്യം വിലയിരുത്തുന്നു: %IncMSE — ഒരു മോഡലിലെ ഈ ആട്രിബ്യൂട്ടിന്റെ സാന്നിധ്യം/അഭാവം ഈ മോഡലിന്റെ MSE ഗുണനിലവാരത്തെ എങ്ങനെ മാറ്റുന്നു (മിച്ച സ്‌ക്വയർ പിശക്);

ഈ ആട്രിബ്യൂട്ടിന്റെ മൂല്യങ്ങളെ അടിസ്ഥാനമാക്കി, നിരീക്ഷണങ്ങളുള്ള ഒരു ഡാറ്റാസെറ്റ് എത്ര നന്നായി വിഭജിക്കാം എന്ന് പ്രതിഫലിപ്പിക്കുന്ന ഒരു സംഖ്യയാണ് IncNodePurity, അങ്ങനെ ഒരു ഭാഗത്ത് മെട്രിക്കിന്റെ ഒരു മൂല്യമുള്ള ഡാറ്റയും മറ്റൊന്നിൽ വിവരിച്ചിരിക്കുന്നു. മെട്രിക്കിന്റെ മറ്റൊരു മൂല്യം.
ശരി, അതായത്: ഇത് എത്രത്തോളം ക്ലാസിഫൈയിംഗ് ആട്രിബ്യൂട്ട് ആണ് (RandomForest-ൽ ഏറ്റവും വ്യക്തമായ, റഷ്യൻ ഭാഷയിലുള്ള വിശദീകരണം ഞാൻ കണ്ടു. ഇവിടെ).

ലോഡ് ടെസ്റ്റുകളുടെ ഫലങ്ങളുള്ള ഒരു ഡാറ്റാസെറ്റ് പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള തൊഴിലാളി-കർഷക ആർ-കോഡ്:

x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')

idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]

library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importance

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

നിങ്ങൾക്ക് R പാക്കേജ് ഉപയോഗിക്കാം caret, പോയിന്റല്ല പ്രധാനം.

തൽഫലമായി, ഈ സാഹചര്യത്തിൽ, ആട്രിബ്യൂട്ടുകളുടെ പ്രാധാന്യത്തിന്റെ അളവ് വിലയിരുത്തുന്നതിന് ഇനിപ്പറയുന്ന ഫലം ലഭിക്കും:

നന്നായി. അങ്ങനെ, നമുക്ക് ആഗോള പ്രതിഫലനം ആരംഭിക്കാം:

1. ഈ ടെസ്റ്റിംഗ് സാഹചര്യങ്ങളിൽ ഏറ്റവും പ്രധാനപ്പെട്ടത് പാരാമീറ്റർ ആണെന്ന് ഇത് മാറുന്നു commit_wait
   സാങ്കേതികമായി, സബ്ഡിബി ലോഗ് ബഫറിൽ നിന്ന് നിലവിലെ ലോഗ് ഗ്രൂപ്പിലേക്ക് റിഡോ ഡാറ്റ എഴുതുന്നതിനുള്ള ഐഒ ഓപ്പറേഷന്റെ എക്സിക്യൂഷൻ മോഡ് ഇത് വ്യക്തമാക്കുന്നു: സിൻക്രണസ് അല്ലെങ്കിൽ അസിൻക്രണസ്.
   വില nowait ഇത് tps മെട്രിക്കിന്റെ മൂല്യത്തിൽ ഏതാണ്ട് ലംബമായ ഒന്നിലധികം വർദ്ധനവിന് കാരണമാകുന്നു: ഇത് redo ഗ്രൂപ്പുകളിൽ അസിൻക്രണസ് io മോഡ് ഉൾപ്പെടുത്തുന്നതാണ്.
   ഒരു ഫുഡ് ഡാറ്റാബേസിൽ നിങ്ങൾ ഇത് ചെയ്യണോ വേണ്ടയോ എന്നതാണ് ഒരു പ്രത്യേക ചോദ്യം. ഇവിടെ ഞാൻ എന്നെത്തന്നെ പ്രസ്താവിക്കാൻ പരിമിതപ്പെടുത്തുന്നു: ഇത് ഒരു പ്രധാന ഘടകമാണ്.
2. സബ്‌ഡിയുടെ ലോഗ് ബഫറിന്റെ വലുപ്പം: ഒരു പ്രധാന ഘടകമായി മാറുന്നത് യുക്തിസഹമാണ്.
   ലോഗ് ബഫറിന്റെ വലുപ്പം ചെറുതാകുമ്പോൾ, അതിന്റെ ബഫറിംഗ് ശേഷി കുറയും, കൂടുതൽ തവണ അത് കവിഞ്ഞൊഴുകുന്നു കൂടാതെ/അല്ലെങ്കിൽ പുതിയ റെഡോക്സ് ഡാറ്റയുടെ ഒരു ഭാഗത്തിനായി അതിൽ ഒരു സ്വതന്ത്ര ഏരിയ അനുവദിക്കാനുള്ള കഴിവില്ലായ്മ.
   ഇതിനർത്ഥം: ലോഗ് ബഫറിൽ ഇടം അനുവദിക്കുന്നതുമായി ബന്ധപ്പെട്ട കാലതാമസം കൂടാതെ/അല്ലെങ്കിൽ അതിൽ നിന്ന് വീണ്ടും ചെയ്യാനുള്ള ഡാറ്റ വീണ്ടും ചെയ്യുക ഗ്രൂപ്പുകളിലേക്ക് ഡംപ് ചെയ്യുന്നു.
   ഈ കാലതാമസം, തീർച്ചയായും, ഇടപാടുകൾക്കായുള്ള ഡാറ്റാബേസിന്റെ ത്രൂപുട്ടിനെ ബാധിക്കുകയും ചെയ്യും.
3. പാരാമീറ്റർ db_block_checksum: നന്നായി, കൂടാതെ, പൊതുവായി ഇത് വ്യക്തമാണ് - ഇടപാട് പ്രോസസ്സിംഗ് സബ്ഡാറ്റബേസിന്റെ ബഫർ കാഷെയിൽ ഡാർട്ടി ബ്ലോക്കുകളുടെ രൂപീകരണത്തിലേക്ക് നയിക്കുന്നു.
   ഡാറ്റാബ്ലോക്കുകളുടെ ചെക്ക്സം പരിശോധിക്കുമ്പോൾ, ഡാറ്റാബേസ് പ്രോസസ്സ് ചെയ്യേണ്ടതുണ്ട് - ഡാറ്റാബ്ലോക്കിന്റെ ബോഡിയിൽ നിന്ന് ഈ ചെക്ക്സം കണക്കാക്കുക, ഡാറ്റാബ്ലോക്ക് ഹെഡറിൽ എഴുതിയിരിക്കുന്നവ ഉപയോഗിച്ച് പരിശോധിക്കുക: പൊരുത്തങ്ങൾ / പൊരുത്തപ്പെടുന്നില്ല.
   അത്തരം ജോലികൾക്ക് വീണ്ടും ഡാറ്റ പ്രോസസ്സിംഗ് കാലതാമസം വരുത്താൻ കഴിയില്ല, അതനുസരിച്ച്, ഈ പാരാമീറ്റർ സജ്ജമാക്കുന്ന പാരാമീറ്ററും മെക്കാനിസവും പ്രാധാന്യമർഹിക്കുന്നു.
   അതുകൊണ്ടാണ് വെണ്ടർ ഈ പാരാമീറ്ററിനുള്ള ഡോക്യുമെന്റേഷനിൽ, അതിനായി വ്യത്യസ്ത മൂല്യങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നത് (പാരാമീറ്റർ) അതെ, ഒരു സ്വാധീനം ഉണ്ടാകുമെന്ന് കുറിക്കുന്നു, പക്ഷേ, നിങ്ങൾക്ക് "ഓഫ്" വരെ വ്യത്യസ്ത മൂല്യങ്ങൾ തിരഞ്ഞെടുക്കാം. വ്യത്യസ്ത ആഘാതങ്ങൾ.

ശരി, ഒരു ആഗോള നിഗമനം.

സമീപനം, പൊതുവേ, തികച്ചും പ്രവർത്തിക്കുന്നതായി മാറുന്നു.

ലോഡിനായി അതിന്റെ (സിസ്റ്റം) ഒപ്റ്റിമൽ കോൺഫിഗറേഷൻ തിരഞ്ഞെടുക്കുന്നതിന്, ഒരു നിശ്ചിത സേവന സിസ്റ്റത്തിന്റെ ലോഡ് ടെസ്റ്റിംഗിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ, ലോഡിനായി സിസ്റ്റം സജ്ജീകരിക്കുന്നതിന്റെ പ്രത്യേകതകൾ വളരെയധികം പരിശോധിക്കാതിരിക്കാൻ അദ്ദേഹം സ്വയം അനുവദിക്കുന്നു.

എന്നാൽ ഇത് പൂർണ്ണമായും ഒഴിവാക്കുന്നില്ല - കുറഞ്ഞത് ധാരണയുടെ തലത്തിലെങ്കിലും: സിസ്റ്റം “അഡ്ജസ്റ്റ്മെന്റ് നോബുകളെക്കുറിച്ചും” ഈ നോബുകളുടെ അനുവദനീയമായ ഭ്രമണ ശ്രേണികളെക്കുറിച്ചും അറിഞ്ഞിരിക്കണം.

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

തീർച്ചയായും, ഒരു നിശ്ചിത ലോഡിന് കീഴിലെങ്കിലും സിസ്റ്റത്തെക്കുറിച്ചും അതിന്റെ പ്രവർത്തനത്തെക്കുറിച്ചും വളരെ ആഴത്തിലുള്ള ഈ ധാരണയുടെ ആവിർഭാവത്തിന് ഇത് കാരണമാകണം.

പ്രായോഗികമായി, ഇത് സിസ്റ്റത്തിന്റെ അത്തരം പരിശോധനകൾ തയ്യാറാക്കുന്നതിനുള്ള ചെലവുകൾക്കായി ഇഷ്‌ടാനുസൃതമാക്കിയ സിസ്റ്റം മനസ്സിലാക്കുന്നതിനുള്ള ചെലവുകളുടെ ഒരു കൈമാറ്റമാണ്.

ഞാൻ പ്രത്യേകം ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു: ഈ സമീപനത്തിൽ, വാണിജ്യ പ്രവർത്തനത്തിൽ ഉണ്ടായിരിക്കുന്ന ഓപ്പറേറ്റിംഗ് അവസ്ഥകളിലേക്കുള്ള സിസ്റ്റം ടെസ്റ്റിംഗിന്റെ പര്യാപ്തതയുടെ അളവ് വളരെ പ്രധാനമാണ്.

നിങ്ങളുടെ ശ്രദ്ധയ്ക്കും സമയത്തിനും നന്ദി.

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