🥇वैज्ञानिक पोकिंग पद्धत, किंवा बेंचमार्क आणि ऑप्टिमायझेशन अल्गोरिदम वापरून सबडेटाबेस कॉन्फिगरेशन कसे निवडायचे

Здравствуйте.

मी माझा शोध सामायिक करण्याचा निर्णय घेतला - विचार, चाचणी आणि त्रुटीचे फळ.
मोठ्या प्रमाणावर: हा शोध नाही, अर्थातच - हे सर्व बर्याच काळापासून माहित असले पाहिजे जे लागू सांख्यिकीय डेटा प्रक्रिया आणि कोणत्याही सिस्टमच्या ऑप्टिमायझेशनमध्ये गुंतलेले आहेत, विशेषतः DBMS आवश्यक नाही.
आणि: होय, त्यांना माहित आहे, ते त्यांच्या संशोधनावर मनोरंजक लेख लिहितात, उदाहरण (UPD.: टिप्पण्यांमध्ये त्यांनी एक अतिशय मनोरंजक प्रकल्प दर्शविला: ottertune )
दुसरीकडे: आयटी तज्ञ, DBA मध्ये इंटरनेटवर या दृष्टिकोनाचा कोणताही व्यापक उल्लेख किंवा प्रसार मला दिसत नाही.

तर, बिंदूपर्यंत.

चला असे गृहीत धरू की आमच्याकडे एक कार्य आहे: काही प्रकारचे काम करण्यासाठी विशिष्ट सेवा प्रणाली सेट करणे.

या कामाबद्दल माहिती आहे: ते काय आहे, या कामाची गुणवत्ता कशी मोजली जाते आणि ही गुणवत्ता मोजण्यासाठी निकष काय आहेत.

चला हे देखील गृहीत धरू की ते कमी-अधिक प्रमाणात ज्ञात आणि समजले आहे: या सेवा प्रणालीमध्ये (किंवा सह) कार्य कसे केले जाते.

"अधिक किंवा कमी" - याचा अर्थ असा की विशिष्ट साधन, उपयुक्तता, सेवा तयार करणे शक्य आहे (किंवा ते कोठून तरी मिळू शकते) ज्याचे संश्लेषण केले जाऊ शकते आणि चाचणी लोडसह सिस्टमवर लागू केले जाऊ शकते जे उत्पादनात काय असेल ते पुरेसे आहे, उत्पादनात काम करण्यासाठी पुरेशा परिस्थितीत.

बरं, या सेवा प्रणालीसाठी समायोजन पॅरामीटर्सचा संच ज्ञात आहे असे गृहीत धरू या, ज्याचा वापर या प्रणालीच्या कार्याच्या उत्पादकतेच्या दृष्टीने कॉन्फिगर करण्यासाठी केला जाऊ शकतो.

आणि समस्या काय आहे - या सेवा प्रणालीची पुरेशी पूर्ण माहिती नाही, जी तुम्हाला दिलेल्या प्लॅटफॉर्मवर भविष्यातील लोडसाठी या सिस्टमची सेटिंग्ज कुशलतेने कॉन्फिगर करण्याची आणि सिस्टमची आवश्यक उत्पादकता मिळविण्याची परवानगी देते.

विहीर. हे जवळजवळ नेहमीच असते.

तुम्ही इथे काय करू शकता?

बरं, मनात येणारी पहिली गोष्ट म्हणजे या प्रणालीसाठी कागदपत्रे पाहणे. समायोजन पॅरामीटर्सच्या मूल्यांसाठी स्वीकार्य श्रेणी काय आहेत ते समजून घ्या. आणि, उदाहरणार्थ, कोऑर्डिनेट डिसेंट पद्धत वापरून, चाचण्यांमध्ये सिस्टम पॅरामीटर्ससाठी मूल्ये निवडा.

त्या. सिस्टमला त्याच्या कॉन्फिगरेशन पॅरामीटर्ससाठी विशिष्ट मूल्यांच्या संचाच्या रूपात काही प्रकारचे कॉन्फिगरेशन द्या.

हेच टूल-युटिलिटी, लोड जनरेटर वापरून, त्यावर चाचणी लोड लागू करा.
आणि मूल्य पहा - प्रतिसाद, किंवा सिस्टमच्या गुणवत्तेचा मेट्रिक.

दुसरा विचार असा निष्कर्ष असू शकतो की हा बराच काळ आहे.

बरं, ते म्हणजे: जर तेथे बरेच सेटिंग पॅरामीटर्स असतील, जर त्यांच्या मूल्यांच्या श्रेणी मोठ्या असतील, जर प्रत्येक वैयक्तिक लोड चाचणी पूर्ण होण्यास बराच वेळ लागतो, तर: होय, हे सर्व अस्वीकार्यपणे लागू शकते. बराच वेळ

बरं, तुम्ही काय समजू शकता आणि लक्षात ठेवू शकता ते येथे आहे.

आपण हे शोधू शकता की सेवा सिस्टम सेटिंग्ज पॅरामीटर्सच्या मूल्यांच्या संचामध्ये काही मूल्यांचा क्रम म्हणून एक वेक्टर आहे.

असे प्रत्येक वेक्टर, इतर गोष्टी समान असतात (त्यावर या वेक्टरचा परिणाम होत नाही), मेट्रिकच्या पूर्णपणे निश्चित मूल्याशी संबंधित आहे - चाचणी लोड अंतर्गत सिस्टमच्या ऑपरेशनच्या गुणवत्तेचे सूचक.

म्हणजे

सिस्टम कॉन्फिगरेशन व्हेक्टर असे दर्शवू कुठे ; कुठे — सिस्टम कॉन्फिगरेशन पॅरामीटर्सची संख्या, यापैकी किती पॅरामीटर्स आहेत.

आणि याशी संबंधित मेट्रिकचे मूल्य ते असे दर्शवू
, नंतर आम्हाला एक फंक्शन मिळेल:

बरं, मग: माझ्या बाबतीत, सर्वकाही लगेच खाली येते: माझ्या विद्यार्थी दिवसांपासून जवळजवळ विसरलेले, फंक्शनच्या टोकाचा शोध घेण्यासाठी अल्गोरिदम.

ठीक आहे, परंतु येथे एक संस्थात्मक आणि लागू प्रश्न उद्भवतो: कोणता अल्गोरिदम वापरायचा.

अर्थाने - जेणेकरून आपण हाताने कमी कोड करू शकता.
आणि ते कार्य करण्यासाठी, म्हणजे. extremum (एखादे असल्यास) आढळले, तसेच, समन्वय वंशापेक्षा कमीत कमी वेगवान.

पहिला मुद्दा सूचित करतो की आपल्याला अशा काही वातावरणाकडे लक्ष देणे आवश्यक आहे ज्यामध्ये अशा अल्गोरिदमची अंमलबजावणी आधीच केली गेली आहे, आणि काही स्वरूपात, कोडमध्ये वापरण्यासाठी तयार आहेत.
बरं, मला माहीत आहे python и cran-r

दुसऱ्या मुद्द्याचा अर्थ असा आहे की आपल्याला अल्गोरिदम स्वतःच, ते काय आहेत, त्यांच्या आवश्यकता काय आहेत आणि त्यांच्या कार्याची वैशिष्ट्ये याबद्दल वाचणे आवश्यक आहे.

आणि ते जे देतात ते उपयुक्त साइड इफेक्ट्स असू शकतात - परिणाम किंवा थेट अल्गोरिदममधूनच.

किंवा ते अल्गोरिदमच्या परिणामांमधून मिळू शकतात.

इनपुट अटींवर बरेच काही अवलंबून असते.

उदाहरणार्थ, जर काही कारणास्तव, तुम्हाला परिणाम जलद मिळण्याची आवश्यकता असेल, तर तुम्हाला ग्रेडियंट डिसेंट अल्गोरिदमकडे लक्ष द्यावे लागेल आणि त्यापैकी एक निवडावा लागेल.

किंवा, वेळ तितका महत्त्वाचा नसल्यास, आपण, उदाहरणार्थ, अनुवांशिक अल्गोरिदम सारख्या स्टोकास्टिक ऑप्टिमायझेशन पद्धती वापरू शकता.

मी या दृष्टिकोनाचे कार्य विचारात घेण्याचा प्रस्ताव देतो, सिस्टम कॉन्फिगरेशन निवडणे, अनुवांशिक अल्गोरिदम वापरुन, पुढील, म्हणजे: प्रयोगशाळेचे कार्य.

मूळ:

सेवा प्रणाली म्हणून असू द्या: oracle xe 18c
यास व्यवहारात्मक क्रियाकलाप आणि उद्दिष्ट पूर्ण करू द्या: व्यवहार/सेकंदात, सबडेटाबेसचे जास्तीत जास्त संभाव्य थ्रूपुट प्राप्त करण्यासाठी.
डेटासह कार्य करण्याचे स्वरूप आणि कामाच्या संदर्भामध्ये व्यवहार खूप भिन्न असू शकतात.
चला मान्य करूया की हे असे व्यवहार आहेत जे मोठ्या प्रमाणात सारणीबद्ध डेटावर प्रक्रिया करत नाहीत.
या अर्थाने की ते रीडू पेक्षा अधिक पूर्ववत डेटा व्युत्पन्न करत नाहीत आणि मोठ्या टक्के पंक्ती आणि मोठ्या सारण्यांवर प्रक्रिया करत नाहीत.

हे असे व्यवहार आहेत जे कमी-अधिक मोठ्या टेबलमध्ये एक पंक्ती बदलतात, या टेबलवर कमी संख्येने निर्देशांक असतात.

या परिस्थितीत: प्रक्रिया व्यवहारांसाठी सबडेटाबेसची उत्पादकता, आरक्षणासह, रेडॉक्स डेटाबेसद्वारे प्रक्रियेच्या गुणवत्तेद्वारे निर्धारित केली जाईल.

अस्वीकरण - जर आम्ही विशेषतः सबडीबी सेटिंग्जबद्दल बोललो.

कारण, सर्वसाधारण बाबतीत, टॅब्युलर डेटा आणि/किंवा टॅब्युलर मॉडेलसह वापरकर्त्याच्या कार्याच्या डिझाइनमुळे, SQL सत्रांमधील व्यवहार लॉक असू शकतात.

ज्याचा, अर्थातच, TPS मेट्रिकवर निराशाजनक प्रभाव पडेल आणि हा सबडेटाबेसच्या तुलनेत एक बाह्य घटक असेल: बरं, सारणी मॉडेलची रचना अशा प्रकारे केली गेली आणि त्यात डेटासह कार्य ज्यामध्ये अडथळे येतात.

म्हणून, प्रयोगाच्या शुद्धतेसाठी, आम्ही हा घटक वगळू आणि खाली मी ते कसे स्पष्ट करू.

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

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

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

सुरुवातीला, या लोड परिस्थितीत, मला व्यवहार subd वापरायचा होता SLOB-उपयुक्तता
यात एक अद्भुत वैशिष्ट्य आहे, मी लेखकाला उद्धृत करेन:

SLOB च्या केंद्रस्थानी "SLOB पद्धत" आहे. SLOB पद्धतीचा उद्देश प्लॅटफॉर्मची चाचणी घेणे आहे
अर्ज वादविना. एक जास्तीत जास्त हार्डवेअर कामगिरी चालवू शकत नाही
ऍप्लिकेशन कोड वापरणे जे, उदाहरणार्थ, ऍप्लिकेशन लॉकिंग किंवा अगदी बद्ध आहे
ओरॅकल डेटाबेस ब्लॉक्स सामायिक करणे. ते बरोबर आहे—डेटा शेअर करताना ओव्हरहेड असते
डेटा ब्लॉक्समध्ये! परंतु SLOB-त्याच्या डिफॉल्ट तैनातीमध्ये-अशा वादापासून मुक्त आहे.

ही घोषणा: अनुरूप आहे, ती आहे.
cl सत्रांच्या समांतरतेच्या डिग्रीचे नियमन करणे सोयीचे आहे, ही की आहे -t युटिलिटी लाँच करा runit.sh SLOB कडून
डीएमएल कमांडची टक्केवारी नियमन केली जाते, सबडीवर पाठवलेल्या मजकूर संदेशांच्या संख्येनुसार, प्रत्येक मजकूर सत्र, पॅरामीटर UPDATE_PCT
स्वतंत्रपणे आणि अतिशय सोयीस्करपणे: SLOB स्वतः, लोड सत्रापूर्वी आणि नंतर - स्टॅटस्पॅक, किंवा awr-स्नॅपशॉट्स (जे तयार करायचे आहे) तयार करते.

तथापि, ते बाहेर वळले SLOB ३० सेकंदांपेक्षा कमी कालावधीच्या 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"

त्या. प्रत्येक कामगारासाठी (व्यावहारिकपणे: डीबीमध्ये एक वेगळे 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

प्रयोगशाळेच्या कामाकडे परत येत आहे.
आम्ही, इतर गोष्टी समान असल्याने, प्रयोगशाळा सबडेटाबेसच्या खालील पॅरामीटर्सची मूल्ये बदलू:

डेटाबेस लॉग गटांचा आकार. मूल्य श्रेणी: [३२, १०२४] एमबी;
डेटाबेसमधील जर्नल गटांची संख्या. मूल्य श्रेणी: [२,३२];
log_archive_max_processes मूल्य श्रेणी: [१,८];
commit_logging दोन मूल्यांना परवानगी आहे: batch|immediate;
commit_wait दोन मूल्यांना परवानगी आहे: wait|nowait;
log_buffer मूल्य श्रेणी: [२.१२८] एमबी.
log_checkpoint_timeout मूल्य श्रेणी: [६०,१२००] सेकंद
db_writer_processes मूल्य श्रेणी: [१,४]
undo_retention मूल्य श्रेणी: [३०;३००] सेकंद
transactions_per_rollback_segment मूल्य श्रेणी: [१,४]
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 मूलत:, शोध जागेचे क्षेत्र निर्दिष्ट केले आहे, ज्यामध्ये अशा वेक्टर (किंवा वेक्टर) साठी शोध केला जाईल ज्यासाठी फिटनेस फंक्शनचे कमाल मूल्य प्राप्त केले जाईल.

ga subroutine फिटनेस फंक्शन जास्तीत जास्त शोधते.

बरं, मग, असे दिसून आले की, या प्रकरणात, फिटनेस फंक्शन, सबडीच्या विशिष्ट पॅरामीटर्ससाठी व्हॅल्यूजचा संच म्हणून वेक्टर समजून घेणे आवश्यक आहे, सबडीकडून मेट्रिक प्राप्त करणे आवश्यक आहे.

म्हणजे: दिलेल्या subd सेटअपसह किती आणि subd वर दिलेल्या लोडसह: subd प्रति सेकंद व्यवहार प्रक्रिया करते.

म्हणजेच, उलगडताना, फिटनेस फंक्शनमध्ये खालील मल्टी-स्टेप करणे आवश्यक आहे:

संख्यांच्या इनपुट वेक्टरवर प्रक्रिया करणे - सबडेटा पॅरामीटर्ससाठी मूल्यांमध्ये रूपांतरित करणे.
दिलेल्या आकाराच्या रीडू गटांची संख्या तयार करण्याचा प्रयत्न. शिवाय, प्रयत्न अयशस्वी होऊ शकतात.
प्रयोगाच्या शुद्धतेसाठी subd मध्ये आधीपासून अस्तित्वात असलेले मासिक गट, काही प्रमाणात आणि काही आकाराचे - d.b. हटवले.
मागील बिंदू यशस्वी झाल्यास: डेटाबेसमध्ये कॉन्फिगरेशन पॅरामीटर्सची मूल्ये निर्दिष्ट करणे (पुन्हा: एक अपयश असू शकते)
मागील पायरी यशस्वी झाल्यास: subd थांबवणे, subd सुरू करणे जेणेकरून नवीन निर्दिष्ट पॅरामीटर मूल्ये प्रभावी होतील. (पुन्हा: एक त्रुटी असू शकते)
मागील पायरी यशस्वी झाल्यास: लोड चाचणी करा. subd वरून मेट्रिक्स मिळवा.
subd त्याच्या मूळ स्थितीत परत करा, उदा. अतिरिक्त लॉग गट हटवा, मूळ सबडेटाबेस कॉन्फिगरेशन कार्य करण्यासाठी परत करा.

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

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 वेक्टर किंवा, अधिक योग्यरित्या, गुणसूत्रांवर प्रक्रिया करते.
ज्यामध्ये, आपल्यासाठी सर्वात महत्त्वाचे म्हणजे जीन्ससह गुणसूत्रांची निवड ज्यासाठी फिटनेस फंक्शन मोठ्या मूल्यांची निर्मिती करते.

ही, थोडक्यात, एन-डीमेन्शनल शोध स्पेसमध्ये वेक्टर वापरून गुणसूत्रांचा इष्टतम संच शोधण्याची प्रक्रिया आहे.

अगदी स्पष्ट, तपशीलवार स्पष्टीकरण, आर-कोडच्या उदाहरणांसह, अनुवांशिक अल्गोरिदमचे कार्य.

मी स्वतंत्रपणे दोन तांत्रिक मुद्दे लक्षात घेऊ इच्छितो.

फंक्शनमधून सहाय्यक कॉल 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 हजार टीपीएस: एक वेगळा प्रश्न.
प्रयोगशाळेच्या कार्याच्या चौकटीत, ही आकृती महत्त्वाची नाही, गतिशीलता काय आहे, हे मूल्य कसे बदलते.

येथील गतिशीलता चांगली आहे.
हे स्पष्ट आहे की कमीत कमी एक घटक मेट्रिकच्या मूल्यावर, ga-अल्गोरिदमवर लक्षणीय प्रभाव टाकतो, गुणसूत्र वेक्टरद्वारे क्रमवारी लावतो: झाकलेले.
वक्र मूल्यांच्या बर्‍यापैकी जोमदार गतिशीलतेचा आधार घेत, आणखी एक घटक आहे जो लक्षणीयरीत्या लहान असला तरी त्याचा प्रभाव आहे.

तुम्हाला त्याची गरज आहे attribute-importance कोणते गुणधर्म (चांगले, या प्रकरणात, ट्यूनिंग वेक्टरचे घटक) आणि ते मेट्रिक मूल्यावर किती प्रभाव पाडतात हे समजून घेण्यासाठी विश्लेषण.
आणि या माहितीवरून: महत्त्वपूर्ण गुणधर्मांमधील बदलांमुळे कोणते घटक प्रभावित झाले ते समजून घ्या.

अंमलात आणा attribute-importance वेगवेगळ्या प्रकारे शक्य.

या हेतूंसाठी, मला अल्गोरिदम आवडतो randomForest त्याच नावाचे आर पॅकेज (दस्तऐवजीकरण)
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, मुद्दा महत्वाचा नाही.

परिणामी, या प्रकरणात, गुणधर्मांच्या महत्त्वाच्या डिग्रीचे मूल्यांकन करण्यासाठी खालील परिणाम प्राप्त केले जातात:

विहीर. अशा प्रकारे, आम्ही जागतिक प्रतिबिंब सुरू करू शकतो:

हे दिसून आले की या चाचणी परिस्थितीत सर्वात लक्षणीय, पॅरामीटर होते commit_wait
तांत्रिकदृष्ट्या, ते सबडीबी लॉग बफरवरून वर्तमान लॉग ग्रुपवर रीडो डेटा लिहिण्याच्या io ऑपरेशनचा एक्झिक्युशन मोड निर्दिष्ट करते: सिंक्रोनस किंवा एसिंक्रोनस.
मूल्य nowait ज्याचा परिणाम जवळजवळ उभ्या, tps मेट्रिकच्या मूल्यामध्ये एकाधिक वाढ होतो: हे रिडू गटांमध्ये असिंक्रोनस io मोडचा समावेश आहे.
आपण अन्न डेटाबेसमध्ये हे करावे की नाही हा एक वेगळा प्रश्न आहे. येथे मी स्वतःला फक्त सांगण्यापुरते मर्यादित ठेवतो: हा एक महत्त्वाचा घटक आहे.
हे तार्किक आहे की सबडीच्या लॉग बफरचा आकार एक महत्त्वपूर्ण घटक आहे.
लॉग बफरचा आकार जितका लहान असेल तितकी त्याची बफरिंग क्षमता कमी होईल, अधिक वेळा ते ओव्हरफ्लो होईल आणि/किंवा नवीन रेडॉक्स डेटाच्या एका भागासाठी मोकळे क्षेत्र वाटप करण्यास असमर्थता.
याचा अर्थ: लॉग बफरमध्‍ये जागा वाटप करण्‍याशी संबंधित विलंब आणि/किंवा त्‍यामधून रीडो डेटा रिडू ग्रुपमध्‍ये डंप करणे.
या विलंबांचा, अर्थातच, व्यवहारांसाठी डेटाबेसच्या थ्रूपुटवर परिणाम व्हायला हवा आणि होतो.
पॅरामीटर db_block_checksum: तसेच, सर्वसाधारणपणे हे स्पष्ट आहे - व्यवहार प्रक्रियेमुळे सबडेटाबेसच्या बफर कॅशेमध्ये डार्टी ब्लॉक्स तयार होतात.
जे, डेटाब्लॉकचे चेकसम तपासणे सक्षम असताना, डेटाबेसला प्रक्रिया करावी लागते - या चेकसमची डेटाब्लॉकच्या मुख्य भागावरून गणना करा, डेटाब्लॉक शीर्षलेखात काय लिहिले आहे ते तपासा: जुळते/जुळत नाही.
असे कार्य, पुन्हा, डेटा प्रक्रियेस विलंब करू शकत नाही आणि त्यानुसार, पॅरामीटर आणि हे पॅरामीटर सेट करणारी यंत्रणा महत्त्वपूर्ण असल्याचे दिसून येते.
म्हणूनच विक्रेता ऑफर करतो, या पॅरामीटरच्या दस्तऐवजीकरणात, त्याच्यासाठी भिन्न मूल्ये (पॅरामीटर) आणि लक्षात ठेवा की होय, प्रभाव पडेल, परंतु, आपण "बंद" पर्यंत भिन्न मूल्ये निवडू शकता आणि विविध प्रभाव.

बरं, जागतिक निष्कर्ष.

दृष्टीकोन, सर्वसाधारणपणे, बर्‍यापैकी कार्यरत असल्याचे दिसून येते.

एखाद्या विशिष्ट सेवा प्रणालीच्या लोड चाचणीच्या सुरुवातीच्या टप्प्यात, लोडसाठी त्याचे (सिस्टम) इष्टतम कॉन्फिगरेशन निवडण्यासाठी, लोडसाठी सिस्टम सेट करण्याच्या वैशिष्ट्यांमध्ये जास्त शोध न घेण्याकरिता तो स्वत: ला परवानगी देतो.

परंतु ते पूर्णपणे वगळत नाही - किमान समजण्याच्या पातळीवर: सिस्टमला "अ‍ॅडजस्टमेंट नॉब्स" आणि या नॉब्सच्या रोटेशनच्या अनुज्ञेय श्रेणींबद्दल माहिती असणे आवश्यक आहे.

त्यानंतर दृष्टिकोन तुलनेने त्वरीत इष्टतम सिस्टम कॉन्फिगरेशन शोधू शकतो.
आणि चाचणीच्या परिणामांवर आधारित, सिस्टम कार्यप्रदर्शन मेट्रिक्स आणि सिस्टम सेटिंग्ज पॅरामीटर्सच्या मूल्यांमधील संबंधांच्या स्वरूपाबद्दल माहिती मिळवणे शक्य आहे.

जे, अर्थातच, किमान दिलेल्या लोड अंतर्गत, प्रणाली, त्याचे ऑपरेशन या अतिशय खोल समजून उदय योगदान पाहिजे.

सराव मध्ये, ही प्रणालीची चाचणी तयार करण्याच्या खर्चासाठी सानुकूलित प्रणाली समजून घेण्याच्या खर्चाची देवाणघेवाण आहे.

मी स्वतंत्रपणे लक्षात घेऊ इच्छितो: या दृष्टिकोनामध्ये, व्यावसायिक ऑपरेशनमध्ये असलेल्या ऑपरेटिंग परिस्थितींसाठी सिस्टम चाचणीची पर्याप्तता गंभीरपणे महत्त्वपूर्ण आहे.

तुमचे लक्ष आणि वेळ दिल्याबद्दल धन्यवाद.

स्त्रोत: www.habr.com

वैज्ञानिक पोक पद्धत, किंवा बेंचमार्क आणि ऑप्टिमायझेशन अल्गोरिदम वापरून डेटाबेस कॉन्फिगरेशन कसे निवडायचे

एक टिप्पणी जोडा Отменить ответ