🥇वैज्ञानिक पोकिंग विधि, या बेंचमार्क और एक अनुकूलन एल्गोरिदम का उपयोग करके उपडेटाबेस कॉन्फ़िगरेशन का चयन कैसे करें

नमस्ते

मैंने अपनी खोज को साझा करने का निर्णय लिया - विचार, परीक्षण और त्रुटि का फल।
कुल मिलाकर: निश्चित रूप से, यह कोई खोज नहीं है - यह सब उन लोगों को लंबे समय से ज्ञात होना चाहिए था, जो लागू सांख्यिकीय डेटा प्रसंस्करण और किसी भी सिस्टम के अनुकूलन में शामिल हैं, जरूरी नहीं कि विशेष रूप से डीबीएमएस।
और: हाँ, वे जानते हैं, वे अपने शोध पर दिलचस्प लेख लिखते हैं, उदाहरण (यूपीडी: टिप्पणियों में उन्होंने एक बहुत ही दिलचस्प परियोजना की ओर इशारा किया: ottertune )
दूसरी ओर: ऑफहैंड, मुझे आईटी विशेषज्ञों, डीबीए के बीच इंटरनेट पर इस दृष्टिकोण का कोई व्यापक उल्लेख या प्रसार नहीं दिख रहा है।

तो, मुद्दे की बात पर।

आइए मान लें कि हमारे पास एक कार्य है: किसी प्रकार के कार्य की सेवा के लिए एक निश्चित सेवा प्रणाली स्थापित करना।

इस कार्य के बारे में जाना जाता है कि यह क्या है, इस कार्य की गुणवत्ता कैसे मापी जाती है और इस गुणवत्ता को मापने का मापदंड क्या है।

आइए यह भी मान लें कि यह कमोबेश ज्ञात और समझा हुआ है: वास्तव में इस सेवा प्रणाली में (या इसके साथ) काम कैसे किया जाता है।

"अधिक या कम" - इसका मतलब है कि एक निश्चित उपकरण, उपयोगिता, सेवा तैयार करना (या इसे कहीं से प्राप्त करना) संभव है जिसे उत्पादन में होने वाले परीक्षण लोड के साथ सिस्टम में संश्लेषित और लागू किया जा सकता है, उत्पादन में काम करने के लिए पर्याप्त परिस्थितियों में।

ठीक है, मान लीजिए कि इस सेवा प्रणाली के लिए समायोजन मापदंडों का एक सेट ज्ञात है, जिसका उपयोग इस प्रणाली को उसके कार्य की उत्पादकता के संदर्भ में कॉन्फ़िगर करने के लिए किया जा सकता है।

और समस्या क्या है - इस सेवा प्रणाली की पर्याप्त रूप से पूर्ण समझ नहीं है, जो आपको किसी दिए गए प्लेटफ़ॉर्म पर भविष्य के लोड के लिए इस प्रणाली की सेटिंग्स को विशेषज्ञ रूप से कॉन्फ़िगर करने और सिस्टम की आवश्यक उत्पादकता प्राप्त करने की अनुमति देती है।

कुंआ। लगभग हमेशा यही स्थिति होती है.

आप यहां क्या कर सकते हैं?

खैर, पहली बात जो दिमाग में आती है वह इस प्रणाली के दस्तावेज़ीकरण को देखना है। समझें कि समायोजन मापदंडों के मूल्यों के लिए स्वीकार्य सीमाएँ क्या हैं। और, उदाहरण के लिए, समन्वय वंश पद्धति का उपयोग करके, परीक्षणों में सिस्टम मापदंडों के लिए मानों का चयन करें।

वे। सिस्टम को उसके कॉन्फ़िगरेशन मापदंडों के लिए मानों के एक विशिष्ट सेट के रूप में किसी प्रकार का कॉन्फ़िगरेशन दें।

इसी उपकरण-उपयोगिता, लोड जनरेटर का उपयोग करके, इस पर एक परीक्षण लोड लागू करें।
और मूल्य - प्रतिक्रिया, या सिस्टम की गुणवत्ता का एक मीट्रिक देखें।

दूसरा विचार यह निष्कर्ष हो सकता है कि यह बहुत लंबा समय है।

ठीक है, वह यह है: यदि बहुत सारे सेटिंग पैरामीटर हैं, यदि उनके चलाए जा रहे मानों की सीमाएँ बड़ी हैं, यदि प्रत्येक व्यक्तिगत लोड परीक्षण को पूरा होने में बहुत समय लगता है, तो: हाँ, यह सब अस्वीकार्य रूप से लग सकता है लंबे समय तक।

खैर, यहाँ वह है जिसे आप समझ सकते हैं और याद रख सकते हैं।

आप यह पता लगा सकते हैं कि सेवा प्रणाली सेटिंग्स पैरामीटर के मानों के सेट में कुछ मानों के अनुक्रम के रूप में एक वेक्टर होता है।

ऐसा प्रत्येक वेक्टर, अन्य सभी चीजें समान होने पर (इसमें कि यह इस वेक्टर से प्रभावित नहीं होता है), एक पूरी तरह से निश्चित मीट्रिक मान से मेल खाता है - परीक्षण भार के तहत सिस्टम संचालन की गुणवत्ता का एक संकेतक।

यानी

आइए हम सिस्टम कॉन्फ़िगरेशन वेक्टर को इस रूप में निरूपित करें जहां ; कहाँ — सिस्टम कॉन्फ़िगरेशन पैरामीटर की संख्या, इनमें से कितने पैरामीटर हैं।

और इसके अनुरूप मीट्रिक का मान आइए इसे इस रूप में निरूपित करें
, तो हमें एक फ़ंक्शन मिलता है:

खैर, फिर: मेरे मामले में, सब कुछ तुरंत नीचे आ जाता है: मेरे छात्र दिनों से लगभग भूल गए, किसी फ़ंक्शन के चरम की खोज के लिए एल्गोरिदम।

ठीक है, लेकिन यहां एक संगठनात्मक और व्यावहारिक प्रश्न उठता है: किस एल्गोरिदम का उपयोग किया जाए।

इस अर्थ में - ताकि आप हाथ से कम कोड कर सकें।
और इसके काम करने के लिए, यानी चरम पाया गया (यदि कोई है), ठीक है, कम से कम समन्वय वंश की तुलना में तेज़।

पहला बिंदु संकेत देता है कि हमें कुछ ऐसे वातावरणों की ओर देखने की ज़रूरत है जिनमें ऐसे एल्गोरिदम पहले ही लागू किए जा चुके हैं, और किसी न किसी रूप में, कोड में उपयोग के लिए तैयार हैं।
मुझे पता है python и cran-r

दूसरे बिंदु का मतलब है कि आपको एल्गोरिदम के बारे में स्वयं पढ़ने की ज़रूरत है, वे क्या हैं, उनकी आवश्यकताएं क्या हैं, उनके काम की विशेषताएं क्या हैं।

और वे जो देते हैं वह उपयोगी दुष्प्रभाव हो सकते हैं - परिणाम, या सीधे एल्गोरिदम से ही।

या उन्हें एल्गोरिथम के परिणामों से प्राप्त किया जा सकता है।

बहुत कुछ इनपुट स्थितियों पर निर्भर करता है।

उदाहरण के लिए, यदि, किसी कारण से, आपको तेजी से परिणाम प्राप्त करने की आवश्यकता है, तो आपको ग्रेडिएंट डिसेंट एल्गोरिदम की ओर देखना होगा और उनमें से एक को चुनना होगा।

या, यदि समय इतना महत्वपूर्ण नहीं है, तो आप, उदाहरण के लिए, जेनेटिक एल्गोरिदम जैसे स्टोकेस्टिक अनुकूलन तरीकों का उपयोग कर सकते हैं।

मैं इस दृष्टिकोण के काम पर विचार करने का प्रस्ताव करता हूं, सिस्टम कॉन्फ़िगरेशन का चयन, आनुवंशिक एल्गोरिदम का उपयोग करके, अगले में, इसलिए बोलने के लिए: प्रयोगशाला कार्य।

स्रोत:

एक सेवा प्रणाली के रूप में वहाँ रहने दो: oracle xe 18c
इसे लेन-देन संबंधी गतिविधि और लक्ष्य पूरा करने दें: लेन-देन/सेकंड में उपडेटाबेस का उच्चतम संभव थ्रूपुट प्राप्त करना।
डेटा के साथ काम करने की प्रकृति और काम के संदर्भ में लेनदेन बहुत भिन्न हो सकते हैं।
आइए सहमत हों कि ये ऐसे लेनदेन हैं जो बड़ी मात्रा में सारणीबद्ध डेटा को संसाधित नहीं करते हैं।
इस अर्थ में कि वे पुनः करें की तुलना में अधिक पूर्ववत डेटा उत्पन्न नहीं करते हैं और पंक्तियों और बड़ी तालिकाओं के बड़े प्रतिशत को संसाधित नहीं करते हैं।

ये ऐसे लेनदेन हैं जो कम या ज्यादा बड़ी तालिका में एक पंक्ति को बदलते हैं, इस तालिका पर कम संख्या में सूचकांक होते हैं।

इस स्थिति में: लेनदेन को संसाधित करने के लिए उपडेटाबेस की उत्पादकता, आरक्षण के साथ, रेडॉक्स डेटाबेस द्वारा प्रसंस्करण की गुणवत्ता द्वारा निर्धारित की जाएगी।

अस्वीकरण - यदि हम विशेष रूप से सबडीबी सेटिंग्स के बारे में बात करते हैं।

क्योंकि, सामान्य स्थिति में, उदाहरण के लिए, सारणीबद्ध डेटा और/या सारणीबद्ध मॉडल के साथ उपयोगकर्ता के काम के डिज़ाइन के कारण, SQL सत्रों के बीच लेनदेन संबंधी ताले हो सकते हैं।

जो, निश्चित रूप से, टीपीएस मीट्रिक पर एक निराशाजनक प्रभाव डालेगा और यह उपडेटाबेस के सापेक्ष एक बहिर्जात कारक होगा: ठीक है, सारणीबद्ध मॉडल को इस तरह डिज़ाइन किया गया था और इसमें डेटा के साथ काम करने से रुकावटें आती हैं।

इसलिए, प्रयोग की शुद्धता के लिए, हम इस कारक को बाहर कर देंगे, और नीचे मैं स्पष्ट करूंगा कि वास्तव में कैसे।

आइए, निश्चितता के लिए, मान लें कि डेटाबेस में सबमिट किए गए 100% SQL कमांड डीएमएल कमांड हैं।
उपडेटाबेस के साथ उपयोगकर्ता के काम करने की विशेषताएं परीक्षणों में समान रहें।
अर्थात्: एसकेएल सत्रों की संख्या, सारणीबद्ध डेटा, एसकेएल सत्र उनके साथ कैसे काम करते हैं।
Subd में काम करता है FORCE LOGGING, ARCHIVELOG mods. फ्लैशबैक-डेटाबेस मोड सबडी स्तर पर बंद है।
लॉग दोबारा करें: एक अलग फ़ाइल सिस्टम में, एक अलग "डिस्क" पर स्थित;
डेटाबेस के शेष भौतिक घटक: दूसरे, अलग फ़ाइल सिस्टम में, एक अलग "डिस्क" पर:

भौतिक उपकरण के बारे में अधिक जानकारी. प्रयोगशाला डेटाबेस घटक

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

प्रारंभ में, इन लोड शर्तों के तहत, मैं लेनदेन सबड का उपयोग करना चाहता था एसएलओबी-उपयोगिता
इसमें इतनी अद्भुत विशेषता है, मैं लेखक को उद्धृत करूंगा:

एसएलओबी के केंद्र में "एसएलओबी विधि" है। एसएलओबी विधि का उद्देश्य प्लेटफार्मों का परीक्षण करना है
आवेदन विवाद के बिना. कोई अधिकतम हार्डवेयर प्रदर्शन नहीं चला सकता
एप्लिकेशन कोड का उपयोग करना, जो उदाहरण के लिए, एप्लिकेशन लॉकिंग या यहां तक कि बाध्य है
Oracle डेटाबेस ब्लॉक साझा करना। यह सही है—डेटा साझा करते समय ओवरहेड होता है
डेटा ब्लॉक में! लेकिन एसएलओबी-अपनी डिफ़ॉल्ट तैनाती में-इस तरह के विवाद से प्रतिरक्षित है।

यह घोषणा: मेल खाती है, यह है।
सीएल सत्रों की समानता की डिग्री को विनियमित करना सुविधाजनक है, यही कुंजी है -t उपयोगिता लॉन्च करें runit.sh एसएलओबी से
डीएमएल कमांड का प्रतिशत, सबड पर भेजे जाने वाले टेक्स्ट संदेशों की संख्या, प्रत्येक टेक्स्ट सत्र, पैरामीटर में नियंत्रित किया जाता है 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

प्रयोगशाला के काम पर लौटना.
हम, अन्य चीजें समान होने पर, प्रयोगशाला उपडेटाबेस के निम्नलिखित मापदंडों के मूल्यों को अलग-अलग करेंगे:

डेटाबेस लॉग समूहों का आकार. मूल्य सीमा: [32] एमबी;
डेटाबेस में जर्नल समूहों की संख्या. मूल्य सीमा: [2,32];
log_archive_max_processes मूल्य सीमा: [1,8];
commit_logging दो मानों की अनुमति है: batch|immediate;
commit_wait दो मानों की अनुमति है: wait|nowait;
log_buffer मूल्य सीमा: [2,128] एमबी।
log_checkpoint_timeout मान सीमा: [60,1200] सेकंड
db_writer_processes मूल्य सीमा: [1,4]
undo_retention मान सीमा: [30;300] सेकंड
transactions_per_rollback_segment मूल्य सीमा: [1,8]
disk_asynch_io दो मानों की अनुमति है: true|false;
filesystemio_options निम्नलिखित मानों की अनुमति है: none|setall|directIO|asynch;
db_block_checking निम्नलिखित मानों की अनुमति है: OFF|LOW|MEDIUM|FULL;
db_block_checksum निम्नलिखित मानों की अनुमति है: OFF|TYPICAL|FULL;

ओरेकल डेटाबेस को बनाए रखने में अनुभव रखने वाला व्यक्ति निश्चित रूप से पहले से ही बता सकता है कि डेटा के साथ काम करने के लिए डेटाबेस की अधिक उत्पादकता प्राप्त करने के लिए निर्दिष्ट पैरामीटर और उनके स्वीकार्य मूल्यों से क्या और कौन से मान सेट किए जाने चाहिए। एप्लिकेशन कोड, यहां ऊपर।

लेकिन.

प्रयोगशाला कार्य का उद्देश्य यह दिखाना है कि अनुकूलन एल्गोरिथ्म स्वयं हमारे लिए इसे अपेक्षाकृत जल्दी स्पष्ट कर देगा।

हमारे लिए, केवल अनुकूलन योग्य प्रणाली के माध्यम से दस्तावेज़ को देखना बाकी है, यह पता लगाने के लिए कि किन मापदंडों को बदलना है और किस सीमा में बदलना है।
और यह भी: उस कोड को कोड करें जिसका उपयोग चयनित अनुकूलन एल्गोरिदम के कस्टम सिस्टम के साथ काम करने के लिए किया जाएगा।

तो, अब कोड के बारे में।
इसके बारे में मैंने ऊपर बात की cran-r, अर्थात: अनुकूलित प्रणाली के साथ सभी जोड़-तोड़ एक आर स्क्रिप्ट के रूप में व्यवस्थित किए जाते हैं।

वास्तविक कार्य, विश्लेषण, मीट्रिक मान द्वारा चयन, सिस्टम स्थिति वैक्टर: यह एक पैकेज है GA (प्रलेखन)
पैकेज, इस मामले में, बहुत उपयुक्त नहीं है, इस अर्थ में कि यह वेक्टर (गुणसूत्र, यदि पैकेज के संदर्भ में) को भिन्नात्मक भाग के साथ संख्याओं की स्ट्रिंग के रूप में निर्दिष्ट करने की अपेक्षा करता है।

और मेरा वेक्टर, सेटिंग पैरामीटर के मानों से: ये 14 मात्राएँ हैं - पूर्णांक और स्ट्रिंग मान।

निस्संदेह, स्ट्रिंग मानों को कुछ विशिष्ट संख्याएँ निर्दिष्ट करके समस्या से आसानी से बचा जा सकता है।

इस प्रकार, अंत में, आर स्क्रिप्ट का मुख्य भाग इस तरह दिखता है:

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 अनिवार्य रूप से, खोज स्थान का एक क्षेत्र निर्दिष्ट किया जाता है, जिसके भीतर ऐसे वेक्टर (या वैक्टर) की खोज की जाएगी जिसके लिए फिटनेस फ़ंक्शन का अधिकतम मूल्य प्राप्त किया जाएगा।

जीए सबरूटीन फिटनेस फ़ंक्शन को अधिकतम करते हुए एक खोज करता है।

खैर, फिर, यह पता चला है कि, इस मामले में, यह आवश्यक है कि फिटनेस फ़ंक्शन, वेक्टर को उप के कुछ मापदंडों के लिए मानों के एक सेट के रूप में समझे, उप से एक मीट्रिक प्राप्त करे।

अर्थात्: कितने, किसी दिए गए सबड सेटअप और सबड पर दिए गए लोड के साथ: सबड प्रति सेकंड लेनदेन की प्रक्रिया करता है।

अर्थात्, खोलते समय, फिटनेस फ़ंक्शन के अंदर निम्नलिखित बहु-चरण का प्रदर्शन किया जाना चाहिए:

संख्याओं के इनपुट वेक्टर को संसाधित करना - इसे उपडेटा मापदंडों के लिए मानों में परिवर्तित करना।
किसी दिए गए आकार के दिए गए संख्या में पुनः समूह बनाने का प्रयास। इसके अलावा, प्रयास असफल हो सकता है.
पत्रिका समूह जो प्रयोग की शुद्धता के लिए, कुछ मात्रा में और कुछ आकार में पहले से ही उप-क्षेत्र में मौजूद थे - डी.बी. हटा दिया गया.
यदि पिछला बिंदु सफल है: डेटाबेस में कॉन्फ़िगरेशन पैरामीटर के मान निर्दिष्ट करना (फिर से: विफलता हो सकती है)
यदि पिछला चरण सफल होता है: सबड को रोकना, सबड को शुरू करना ताकि नए निर्दिष्ट पैरामीटर मान प्रभावी हो जाएं। (फिर: कोई गड़बड़ी हो सकती है)
यदि पिछला चरण सफल है: लोड परीक्षण करें। सबड से मेट्रिक्स प्राप्त करें।
उप को उसकी मूल स्थिति में लौटाएँ, अर्थात। अतिरिक्त लॉग समूह हटाएं, मूल उपडेटाबेस कॉन्फ़िगरेशन को काम पर लौटाएं।

फिटनेस फ़ंक्शन कोड

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)
}

वह। सभी कार्य: फिटनेस समारोह में किए गए।

गा-सबरूटीन वैक्टर, या, अधिक सही ढंग से, गुणसूत्रों को संसाधित करता है।
जिसमें, हमारे लिए जो सबसे महत्वपूर्ण है वह जीन के साथ गुणसूत्रों का चयन है जिसके लिए फिटनेस फ़ंक्शन बड़े मूल्य उत्पन्न करता है।

यह, संक्षेप में, एन-आयामी खोज स्थान में एक वेक्टर का उपयोग करके गुणसूत्रों के इष्टतम सेट की खोज करने की प्रक्रिया है।

बहुत स्पष्ट, विस्तृत व्याख्या, आर-कोड के उदाहरणों के साथ, एक आनुवंशिक एल्गोरिदम का कार्य।

मैं दो तकनीकी बिंदुओं पर अलग से ध्यान देना चाहूंगा।

फ़ंक्शन से सहायक कॉल 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 इसी नाम का आर पैकेज (प्रलेखन)
randomForest, जैसा कि मैं सामान्य रूप से उनके काम को समझता हूं और विशेष रूप से विशेषताओं के महत्व का आकलन करने के लिए उनका दृष्टिकोण, विशेषताओं पर प्रतिक्रिया चर की निर्भरता का एक निश्चित मॉडल बनाता है।

हमारे मामले में, प्रतिक्रिया चर लोड परीक्षणों में डेटाबेस से प्राप्त एक मीट्रिक है: tps;
और विशेषताएँ ट्यूनिंग वेक्टर के घटक हैं।

और ऐसा है randomForest दो संख्याओं के साथ प्रत्येक मॉडल विशेषता के महत्व का मूल्यांकन करता है: %IncMSE - किसी मॉडल में इस विशेषता की उपस्थिति/अनुपस्थिति इस मॉडल की एमएसई गुणवत्ता (मीन स्क्वैयर त्रुटि) को कैसे बदल देती है;

और IncNodePurity एक संख्या है जो दर्शाती है कि इस विशेषता के मूल्यों के आधार पर, अवलोकन वाले डेटासेट को कितनी अच्छी तरह विभाजित किया जा सकता है, ताकि एक भाग में मीट्रिक के एक मान के साथ डेटा समझाया जा सके, और दूसरे में मीट्रिक का एक और मान.
खैर, वह यह है: यह किस हद तक एक वर्गीकरण विशेषता है (मैंने रैंडमफॉरेस्ट पर सबसे स्पष्ट, रूसी भाषा में स्पष्टीकरण देखा यहां).

लोड परीक्षण के परिणामों के साथ डेटासेट को संसाधित करने के लिए श्रमिक-किसान आर-कोड:

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

आप सीधे अपने हाथों से एल्गोरिदम के हाइपरपैरामीटर का चयन कर सकते हैं और मॉडल की गुणवत्ता पर ध्यान केंद्रित करते हुए, एक मॉडल का चयन कर सकते हैं जो सत्यापन डेटासेट पर भविष्यवाणियों को अधिक सटीक रूप से पूरा करता है।
आप इस कार्य के लिए किसी प्रकार का फ़ंक्शन लिख सकते हैं (वैसे, फिर से, किसी प्रकार के अनुकूलन एल्गोरिदम का उपयोग करके)।

आप आर पैकेज का उपयोग कर सकते हैं caret, बात महत्वपूर्ण नहीं है.

परिणामस्वरूप, इस मामले में, विशेषताओं के महत्व की डिग्री का आकलन करने के लिए निम्नलिखित परिणाम प्राप्त होते हैं:

कुंआ। इस प्रकार, हम वैश्विक प्रतिबिंब शुरू कर सकते हैं:

यह पता चला है कि इन परीक्षण स्थितियों के तहत सबसे महत्वपूर्ण, पैरामीटर था commit_wait
तकनीकी रूप से, यह सबडीबी लॉग बफर से वर्तमान लॉग समूह में रीडो डेटा लिखने के आईओ ऑपरेशन के निष्पादन मोड को निर्दिष्ट करता है: सिंक्रोनस या एसिंक्रोनस।
मूल्य nowait जिसके परिणामस्वरूप टीपीएस मीट्रिक के मूल्य में लगभग लंबवत, कई गुना वृद्धि होती है: यह रीडो समूहों में एसिंक्रोनस आईओ मोड का समावेश है।
एक अलग प्रश्न यह है कि क्या आपको खाद्य डेटाबेस में ऐसा करना चाहिए या नहीं। यहां मैं खुद को केवल यह कहने तक ही सीमित रखता हूं: यह एक महत्वपूर्ण कारक है।
यह तर्कसंगत है कि सबड के लॉग बफ़र का आकार एक महत्वपूर्ण कारक बन जाता है।
लॉग बफ़र का आकार जितना छोटा होगा, इसकी बफ़रिंग क्षमता उतनी ही कम होगी, अधिक बार यह ओवरफ़्लो होगा और/या नए रेडॉक्स डेटा के एक हिस्से के लिए इसमें एक मुक्त क्षेत्र आवंटित करने में असमर्थता होगी।
इसका मतलब है: लॉग बफ़र में स्थान आवंटित करने और/या इससे रीडू डेटा को रीडू समूहों में डंप करने से जुड़ी देरी।
ये देरी, निश्चित रूप से, लेनदेन के लिए डेटाबेस के थ्रूपुट को प्रभावित करना चाहिए और करना भी चाहिए।
प्राचल db_block_checksum: ठीक है, साथ ही, सामान्य तौर पर यह स्पष्ट है - लेनदेन प्रसंस्करण से उपडेटाबेस के बफर कैश में डार्टी ब्लॉक का निर्माण होता है।
जो, जब डेटाब्लॉक के चेकसम की जांच सक्षम होती है, तो डेटाबेस को डेटाब्लॉक के मुख्य भाग से इन चेकसम की गणना करनी होती है, उन्हें डेटाब्लॉक हेडर में लिखी गई बातों से जांचना होता है: मेल खाता है / मेल नहीं खाता है।
ऐसा कार्य, फिर से, डेटा प्रोसेसिंग में देरी नहीं कर सकता है, और तदनुसार, इस पैरामीटर को सेट करने वाला पैरामीटर और तंत्र महत्वपूर्ण हो जाता है।
यही कारण है कि विक्रेता, इस पैरामीटर के लिए दस्तावेज़ में, इसके (पैरामीटर) के लिए अलग-अलग मान प्रदान करता है और नोट करता है कि हाँ, एक प्रभाव होगा, लेकिन, ठीक है, आप अलग-अलग मान चुन सकते हैं, "बंद" तक और अलग-अलग प्रभाव.

खैर, एक वैश्विक निष्कर्ष।

सामान्य तौर पर यह दृष्टिकोण काफी कारगर साबित होता है।

वह एक निश्चित सेवा प्रणाली के लोड परीक्षण के शुरुआती चरणों में, लोड के लिए इसके (सिस्टम) इष्टतम कॉन्फ़िगरेशन का चयन करने के लिए खुद को अनुमति देता है, न कि लोड के लिए सिस्टम की स्थापना की बारीकियों में बहुत अधिक गहराई तक जाने के लिए।

लेकिन यह इसे पूरी तरह से बाहर नहीं करता है - कम से कम समझ के स्तर पर: सिस्टम को "समायोजन घुंडी" और इन घुंडी के घूर्णन की अनुमेय सीमाओं के बारे में पता होना चाहिए।

तब दृष्टिकोण अपेक्षाकृत शीघ्रता से इष्टतम सिस्टम कॉन्फ़िगरेशन ढूंढ सकता है।
और परीक्षण के परिणामों के आधार पर, सिस्टम प्रदर्शन मेट्रिक्स और सिस्टम सेटिंग्स पैरामीटर के मूल्यों के बीच संबंध की प्रकृति के बारे में जानकारी प्राप्त करना संभव है।

जो, निश्चित रूप से, सिस्टम की इस बहुत गहरी समझ के उद्भव में योगदान देना चाहिए, कम से कम एक दिए गए भार के तहत इसका संचालन।

व्यवहार में, यह सिस्टम के ऐसे परीक्षण को तैयार करने की लागत के लिए अनुकूलित सिस्टम को समझने की लागत का आदान-प्रदान है।

मैं अलग से नोट करना चाहूंगा: इस दृष्टिकोण में, वाणिज्यिक संचालन में होने वाली परिचालन स्थितियों के लिए सिस्टम परीक्षण की पर्याप्तता की डिग्री गंभीर रूप से महत्वपूर्ण है।

आपके ध्यान और समय के लिए धन्यवाद.

स्रोत: www.habr.com

वैज्ञानिक पोक विधि, या बेंचमार्क और एक अनुकूलन एल्गोरिदम का उपयोग करके डेटाबेस कॉन्फ़िगरेशन का चयन कैसे करें

एक टिप्पणी जोड़ें उत्तर रद्द