🥇वैज्ञानिक पोकिङ विधि, वा बेन्चमार्क र अप्टिमाइजेसन एल्गोरिथ्म प्रयोग गरेर सबडेटाबेस कन्फिगरेसन कसरी चयन गर्ने

नमस्ते।

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

त्यसैले, बिन्दुमा।

मानौं कि हामीसँग एउटा कार्य छ: कुनै प्रकारको कामको सेवा गर्न निश्चित सेवा प्रणाली सेटअप गर्न।

यो कामको बारेमा थाहा छ: यो के हो, यो कामको गुणस्तर कसरी मापन गरिन्छ, र यो गुणस्तर नाप्ने मापदण्ड के हो।

यो पनि मानौं कि यो कम वा कम ज्ञात र बुझिएको छ: यो सेवा प्रणालीमा (वा संग) काम कसरी गरिन्छ।

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

खैर, मानौं कि यो सेवा प्रणालीको लागि समायोजन प्यारामिटरहरूको सेट ज्ञात छ, जुन यस प्रणालीलाई यसको कामको उत्पादकताको सन्दर्भमा कन्फिगर गर्न प्रयोग गर्न सकिन्छ।

र समस्या के हो - यस सेवा प्रणालीको पर्याप्त रूपमा पूर्ण बुझाइ छैन, जसले तपाइँलाई दिइएको प्लेटफर्ममा भविष्यको लोडको लागि यो प्रणालीको सेटिङहरू कुशलतापूर्वक कन्फिगर गर्न र प्रणालीको आवश्यक उत्पादकता प्राप्त गर्न अनुमति दिन्छ।

राम्रो। यो लगभग सधैं मामला हो।

तपाईं यहाँ के गर्न सक्नुहुन्छ?

ठिक छ, दिमागमा आउने पहिलो कुरा यो प्रणालीको लागि कागजातहरू हेर्नु हो। समायोजन प्यारामिटरहरूको मानहरूको लागि स्वीकार्य दायराहरू के हुन् बुझ्नुहोस्। र, उदाहरणका लागि, समन्वय वंश विधि प्रयोग गरेर, परीक्षणहरूमा प्रणाली प्यारामिटरहरूको लागि मानहरू चयन गर्नुहोस्।

ती। प्रणालीलाई कुनै प्रकारको कन्फिगरेसन दिनुहोस्, यसको कन्फिगरेसन प्यारामिटरहरूको लागि मानहरूको विशिष्ट सेटको रूपमा।

यो धेरै उपकरण-उपयोगिता, लोड जनरेटर प्रयोग गरेर, यसलाई परीक्षण लोड लागू गर्नुहोस्।
र मान हेर्नुहोस् - प्रतिक्रिया, वा प्रणालीको गुणस्तरको मेट्रिक।

दोस्रो विचार यो धेरै लामो समय हो भन्ने निष्कर्ष हुन सक्छ।

ठीक छ, त्यो हो: यदि त्यहाँ धेरै सेटिङ प्यारामिटरहरू छन्, यदि तिनीहरूका मानहरूको दायराहरू ठूला छन् भने, यदि प्रत्येक व्यक्तिगत लोड परीक्षण पूरा गर्न धेरै समय लाग्छ भने, त्यसपछि: हो, यो सबै अस्वीकार्य रूपमा लिन सक्छ। लामो समय।

ठिक छ, यहाँ तपाईंले बुझ्न र सम्झन सक्नुहुन्छ।

तपाईंले पत्ता लगाउन सक्नुहुन्छ कि सेवा प्रणाली सेटिङ प्यारामिटरहरूको मानहरूको सेटमा केही मानहरूको अनुक्रमको रूपमा भेक्टर छ।

प्रत्येक यस्तो भेक्टर, अन्य चीजहरू बराबर छन् (यस वेक्टरबाट प्रभावित छैन), मेट्रिकको पूर्ण रूपमा निश्चित मानसँग मेल खान्छ - परीक्षण लोड अन्तर्गत प्रणालीको सञ्चालनको गुणस्तरको सूचक।

अर्थात्

प्रणाली कन्फिगरेसन भेक्टरलाई यस रूपमा बुझौं कहाँ ; कहाँ — प्रणाली कन्फिगरेसन प्यारामिटरहरूको संख्या, यी मापदण्डहरू कति छन्।

र यो संगत मेट्रिक को मान को रूपमा बुझौं
, त्यसपछि हामीले एउटा प्रकार्य पाउँछौं:

ठिक छ, त्यसोभए: सबै कुरा तुरुन्तै तल आउँछ, मेरो मामलामा: लगभग मेरो विद्यार्थी दिनदेखि बिर्सिएको, प्रकार्यको चरम खोजको लागि एल्गोरिदम।

ठीक छ, तर यहाँ एउटा संगठनात्मक र लागू प्रश्न उठ्छ: कुन एल्गोरिदम प्रयोग गर्ने।

अर्थमा - ताकि तपाईं हातले कम कोड गर्न सक्नुहुन्छ।
र यो काम गर्न को लागी, i.e. extremum (यदि त्यहाँ छ भने), राम्रो, कम्तिमा समन्वय वंश भन्दा छिटो फेला पार्यो।

पहिलो बिन्दुले संकेत गर्दछ कि हामीले केहि वातावरणहरू तिर हेर्नु पर्छ जसमा त्यस्ता एल्गोरिदमहरू पहिले नै लागू भइसकेका छन्, र कुनै न कुनै रूपमा, कोडमा प्रयोगको लागि तयार छन्।
खैर, मलाई थाहा छ python и cran-r

दोस्रो बिन्दुको अर्थ हो कि तपाईंले एल्गोरिदमहरू आफैं, तिनीहरू के हुन्, तिनीहरूका आवश्यकताहरू र तिनीहरूको कामका सुविधाहरूको बारेमा पढ्न आवश्यक छ।

र तिनीहरूले के दिन्छन् उपयोगी साइड इफेक्ट हुन सक्छ - परिणामहरू, वा सीधा एल्गोरिदमबाट।

वा तिनीहरू एल्गोरिथ्मको नतिजाबाट प्राप्त गर्न सकिन्छ।

धेरै इनपुट सर्तहरूमा निर्भर गर्दछ।

उदाहरण को लागी, यदि, केहि कारण को लागी, तपाईले छिटो नतिजा प्राप्त गर्न आवश्यक छ, राम्रो छ, तपाईले ग्रेडियन्ट डिसेन्ट एल्गोरिदम तिर हेर्नु पर्छ र ती मध्ये एक छनोट गर्न आवश्यक छ।

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

म यस दृष्टिकोणको कामलाई विचार गर्न प्रस्ताव गर्दछु, प्रणाली कन्फिगरेसन चयन गर्दै, आनुवंशिक एल्गोरिथ्म प्रयोग गरेर, अर्कोमा, त्यसोभए: प्रयोगशाला काम।

मूल:

सेवा प्रणालीको रूपमा त्यहाँ हुन दिनुहोस्: oracle xe 18c
यसलाई लेनदेन गतिविधि र लक्ष्य प्रदान गर्न दिनुहोस्: लेनदेन/सेकेन्डमा सबडेटाबेसको उच्चतम सम्भावित थ्रुपुट प्राप्त गर्न।
डेटासँग काम गर्ने प्रकृति र कामको सन्दर्भमा लेनदेनहरू धेरै फरक हुन सक्छन्।
सहमत गरौं कि यी लेनदेनहरू हुन् जसले ट्याबुलर डेटाको ठूलो मात्रामा प्रशोधन गर्दैन।
यस अर्थमा कि तिनीहरूले रिडू भन्दा बढी अनडू डाटा उत्पन्न गर्दैनन् र पङ्क्तिहरू र ठूला तालिकाहरूको ठूलो प्रतिशत प्रक्रिया गर्दैनन्।

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

यस अवस्थामा: प्रशोधन लेनदेनको लागि सबडेटाबेसको उत्पादकता, रिजर्भेसनको साथ, रेडक्स डाटाबेस द्वारा प्रशोधनको गुणस्तर द्वारा निर्धारण गरिनेछ।

अस्वीकरण - यदि हामी विशेष रूपमा subdb सेटिङहरूको बारेमा कुरा गर्छौं।

किनभने, सामान्य अवस्थामा, त्यहाँ हुन सक्छ, उदाहरणका लागि, SQL सत्रहरू बीचको लेनदेन लकहरू, ट्याबुलर डेटा र/वा ट्याबुलर मोडेलसँग प्रयोगकर्ताको कामको डिजाइनको कारणले।

जसको, निस्सन्देह, TPS मेट्रिकमा निराशाजनक प्रभाव हुनेछ र यो सबडेटाबेसको सापेक्ष एक एक्सोजेनस कारक हुनेछ: ठीक छ, यसरी टेबुलर मोडेल डिजाइन गरिएको थियो र यसमा डेटाको साथ काम जुन अवरोधहरू उत्पन्न हुन्छ।

त्यसकारण, प्रयोगको शुद्धताको लागि, हामी यो कारकलाई बहिष्कार गर्नेछौं, र तल म कसरी स्पष्ट गर्नेछु।

हामी मानौं, निश्चितताका लागि, डेटाबेसमा पेश गरिएका SQL आदेशहरूको १००% DML आदेशहरू हुन्।
उपडाटाबेससँग प्रयोगकर्ताको कामका विशेषताहरूलाई परीक्षणहरूमा समान हुन दिनुहोस्।
अर्थात्: skl सत्रहरूको संख्या, तालिका डेटा, तिनीहरूसँग कसरी skl सत्रहरू काम गर्छन्।
Subd मा काम गर्नुहुन्छ FORCE LOGGING, ARCHIVELOG मोडहरू। फ्ल्यासब्याक-डेटाबेस मोड बन्द छ, subd स्तरमा।
लगहरू पुन: गर्नुहोस्: छुट्टै फाइल प्रणालीमा अवस्थित, छुट्टै "डिस्क" मा;
डाटाबेसको बाँकी भौतिक कम्पोनेन्ट: अर्कोमा, छुट्टै फाइल प्रणाली, छुट्टै "डिस्क" मा:

भौतिक उपकरण बारे थप विवरण। प्रयोगशाला डाटाबेस घटक

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 बाट
DML आदेशहरूको प्रतिशत विनियमित हुन्छ, पाठ सन्देशहरूको संख्यामा जुन subd मा पठाइन्छ, प्रत्येक पाठ सत्र, प्यारामिटर 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"

ती। प्रत्येक कार्यकर्ताको लागि (व्यावहारिक रूपमा: DB मा छुट्टै SQL सत्र) एउटा छुट्टै तालिका बनाइन्छ, जससँग कार्यकर्ताले काम गर्छ।

यसले कार्यकर्ता सत्रहरू बीचको लेनदेन लकहरूको अनुपस्थिति सुनिश्चित गर्दछ।
प्रत्येक कार्यकर्ता: एउटै कुरा गर्छ, आफ्नै टेबलसँग, टेबलहरू सबै उस्तै छन्।
सबै कामदारहरूले समान समयको लागि काम गर्छन्।
यसबाहेक, पर्याप्त लामो समयको लागि ताकि, उदाहरणका लागि, लग स्विच निश्चित रूपमा देखा पर्नेछ, र एक पटक भन्दा बढी।
ठीक छ, तदनुसार, सम्बन्धित लागत र प्रभाव उत्पन्न भयो।
मेरो मामलामा, मैले कामदारहरूको कामको अवधि 8 मिनेटमा कन्फिगर गरें।

एक statspack रिपोर्ट को एक टुक्रा लोड अन्तर्गत subd को सञ्चालन वर्णन

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 मान दायरा: [60,1200] सेकेन्ड
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 मात्राहरू हुन् - पूर्णांक र स्ट्रिङ मानहरू।

समस्या, निस्सन्देह, स्ट्रिङ मानहरूमा केही विशिष्ट संख्याहरू असाइन गरेर सजिलै बेवास्ता गरिन्छ।

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

ga सबरुटिनले फिटनेस प्रकार्यलाई अधिकतम बनाउँदै खोज प्रदर्शन गर्दछ।

ठीक छ, त्यसपछि, यो बाहिर जान्छ कि, यस अवस्थामा, यो आवश्यक छ कि फिटनेस प्रकार्य, subd को निश्चित प्यारामिटरहरूको लागि मानहरूको सेटको रूपमा भेक्टर बुझ्न, 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, उदाहरण को लागी, स्टप-स्टार्ट, subd प्यारामिटर को मान सेट गर्दै, मा आधारित प्रदर्शन गरिन्छ cran-r कार्यहरू system2

जसको मद्दतले: केहि bash स्क्रिप्ट वा आदेश भनिन्छ।

उदाहरणका लागि:

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)

यो महत्त्वपूर्ण छ, किनभने यस डेटा एरेबाट, ट्युनिङ भेक्टरको कुन कम्पोनेन्टले मेट्रिक मानमा बढी वा कम प्रभाव पार्छ भन्ने बारे थप जानकारी प्राप्त गर्न सम्भव हुनेछ।

त्यो हो: विशेषता-importamce विश्लेषण सञ्चालन गर्न सम्भव हुनेछ।

त्यसोभए के हुन सक्छ?

ग्राफ फारममा, यदि तपाइँ आरोही मेट्रिक क्रममा परीक्षणहरू अर्डर गर्नुहुन्छ भने, चित्र निम्नानुसार छ:

मेट्रिकको चरम मानहरूसँग सम्बन्धित केही डेटा:

यहाँ, नतिजाहरूको साथ स्क्रिनसटमा, म स्पष्ट गर्नेछु: ट्युनिङ भेक्टरको मानहरू फिटनेस प्रकार्य कोडको सर्तमा दिइएको छ, प्यारामिटर मानहरूको परिमिति/ दायराहरूको संख्या सूचीको सर्तमा होइन, जुन तयार गरिएको थियो। माथिको पाठमा।

राम्रो। यो धेरै हो वा थोरै, ~8 हजार tps: एक अलग प्रश्न।
प्रयोगशाला कार्यको ढाँचा भित्र, यो आंकडा महत्त्वपूर्ण छैन, महत्त्वपूर्ण के गतिशीलता हो, यो मूल्य कसरी परिवर्तन हुन्छ।

यहाँको गतिशीलता राम्रो छ।
यो स्पष्ट छ कि कम्तिमा एउटा कारकले मेट्रिकको मान, ga-एल्गोरिथ्म, क्रोमोजोम भेक्टरहरू मार्फत क्रमबद्ध रूपमा प्रभाव पार्छ: कभर।
वक्र मानहरूको पर्याप्त बलियो गतिशीलता द्वारा न्याय गर्दै, त्यहाँ कम्तिमा एक थप कारक छ, यद्यपि महत्त्वपूर्ण रूपमा सानो, प्रभाव छ।

तपाईलाई चाहिने ठाउँ यही हो 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

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

तपाईं आर प्याकेज प्रयोग गर्न सक्नुहुन्छ caret, बिन्दु महत्त्वपूर्ण छैन।

नतिजाको रूपमा, यस अवस्थामा, निम्न नतिजाहरू विशेषताहरूको महत्त्वको डिग्री मूल्याङ्कन गर्न प्राप्त गरिन्छ:

राम्रो। यसरी, हामी विश्वव्यापी प्रतिबिम्ब सुरु गर्न सक्छौं:

यो बाहिर जान्छ कि सबैभन्दा महत्त्वपूर्ण, यी परीक्षण सर्तहरू अन्तर्गत, प्यारामिटर थियो commit_wait
प्राविधिक रूपमा, यसले subdb लग बफरबाट हालको लग समूहमा रिडू डाटा लेख्ने io सञ्चालनको कार्यान्वयन मोड निर्दिष्ट गर्दछ: सिंक्रोनस वा एसिन्क्रोनस।
मूल्य nowait जसको परिणाम लगभग ठाडो हुन्छ, tps मेट्रिकको मानमा धेरै वृद्धि हुन्छ: यो रिडो समूहहरूमा एसिन्क्रोनस io मोडको समावेश हो।
एउटा छुट्टै प्रश्न हो कि तपाईंले खाना डाटाबेसमा यो गर्नु पर्छ वा छैन। यहाँ म आफूलाई केवल बताउन सीमित गर्छु: यो एक महत्त्वपूर्ण कारक हो।
यो तार्किक छ कि subd को लग बफर को आकार: एक महत्वपूर्ण कारक हुन जान्छ।
लग बफरको साइज जति सानो हुन्छ, यसको बफरिङ क्षमता जति कम हुन्छ, त्यति नै यो ओभरफ्लो हुन्छ र/वा नयाँ रेडक्स डेटाको एक भागको लागि यसमा खाली क्षेत्र छुट्याउन असमर्थ हुन्छ।
यसको अर्थ हो: लग बफरमा स्पेस आवंटन गर्न र/वा त्यसबाट रिडू समूहहरूमा रिडू डेटा डम्पिङसँग सम्बन्धित ढिलाइ।
यी ढिलाइहरू, अवश्य पनि, लेनदेनको लागि डाटाबेसको थ्रुपुटलाई असर गर्नुपर्दछ।
परिमिति db_block_checksum: ठीक छ, साथै, सामान्यतया यो स्पष्ट छ - लेनदेन प्रशोधनले सबडेटाबेसको बफर क्यासमा डार्टी ब्लकहरूको गठन निम्त्याउँछ।
कुन, जब डाटाब्लकहरूको चेकसमहरू सक्षम पारिएको छ, डाटाबेसले प्रक्रिया गर्नुपर्छ - डाटाब्लकको मुख्य भागबाट यी चेकसमहरू गणना गर्नुहोस्, डाटाब्लक हेडरमा के लेखिएको छ भनेर जाँच गर्नुहोस्: मेल खान्छ/मिल्दैन।
यस्तो काम, फेरि, डाटा प्रोसेसिङ ढिलाइ गर्न सक्दैन, र तदनुसार, प्यारामिटर र यो प्यारामिटर सेट गर्ने संयन्त्र महत्त्वपूर्ण हुन जान्छ।
यसैले विक्रेताले यस प्यारामिटरको लागि कागजातमा, फरक मानहरू र नोटहरू प्रस्ताव गर्दछ कि हो, त्यहाँ प्रभाव हुनेछ, तर तपाइँ फरक मानहरू, "बन्द" र फरक प्रभावहरू पनि छनौट गर्न सक्नुहुन्छ।

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

दृष्टिकोण, सामान्यतया, धेरै काम गर्न बाहिर जान्छ।

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

तर यसले यसलाई पूर्ण रूपमा बहिष्कार गर्दैन - कम्तिमा बुझाइको स्तरमा: प्रणालीलाई "समायोजन नबहरू" र यी नबहरूको रोटेशनको अनुमतियोग्य दायराहरूको बारेमा थाहा हुनुपर्दछ।

दृष्टिकोणले अपेक्षाकृत चाँडै इष्टतम प्रणाली कन्फिगरेसन फेला पार्न सक्छ।
र परीक्षणको नतिजाको आधारमा, प्रणाली प्रदर्शन मेट्रिक्स र प्रणाली सेटिङ प्यारामिटरहरूको मानहरू बीचको सम्बन्धको प्रकृति बारे जानकारी प्राप्त गर्न सम्भव छ।

जुन, निस्सन्देह, प्रणाली को यो धेरै गहिरो समझ को उद्भव मा योगदान गर्नुपर्छ, यसको सञ्चालन, कम्तिमा दिइएको लोड अन्तर्गत।

अभ्यासमा, यो प्रणालीको यस्तो परीक्षण तयारीको लागतको लागि अनुकूलित प्रणाली बुझ्नको लागतको विनिमय हो।

म छुट्टै नोट गर्न चाहन्छु: यस दृष्टिकोणमा, व्यावसायिक सञ्चालनमा हुने सञ्चालन सर्तहरूमा प्रणाली परीक्षणको पर्याप्तताको डिग्री गम्भीर रूपमा महत्त्वपूर्ण छ।

तपाईंको ध्यान र समय को लागी धन्यवाद।

स्रोत: www.habr.com

वैज्ञानिक पोक विधि, वा बेन्चमार्क र एक अप्टिमाइजेसन एल्गोरिथ्म प्रयोग गरेर डाटाबेस कन्फिगरेसन कसरी चयन गर्ने

एक टिप्पणी थप्न Отменить ответ