🥇Գիտական պոկման մեթոդ, կամ ինչպես ընտրել ենթաբազայի կոնֆիգուրացիան՝ օգտագործելով հենանիշներ և օպտիմալացման ալգորիթմ

Բարեւ Ձեզ

Ես որոշեցի կիսվել իմ գտածոնով՝ մտքի, փորձության և սխալի պտուղը:
Սա, իհարկե, գտածո չէ. այս ամենը վաղուց պետք է հայտնի լիներ նրանց, ովքեր զբաղվում են ցանկացած համակարգերի կիրառական վիճակագրական տվյալների մշակմամբ և օպտիմիզացմամբ, ոչ թե հատկապես DBMS-ի:
Եվ. այո, նրանք գիտեն, նրանք գրում են հետաքրքիր հոդվածներ իրենց հետազոտության վերաբերյալ, օրինակ (UPD.: Մեկնաբանություններում նրանք նշել են մի շատ հետաքրքիր նախագիծ. այլասերվածություն )
Մյուս կողմից, ես չեմ տեսնում այս մոտեցման որևէ տարածված հիշատակում կամ տարածում ինտերնետում ՏՏ մասնագետների, DBA-ի շրջանում:

Այսպիսով, կետին:

Ենթադրենք, մենք խնդիր ունենք՝ ստեղծել որոշակի սպասարկման համակարգ՝ ինչ-որ աշխատանք սպասարկելու համար։

Հայտնի է այս աշխատանքի մասին՝ ինչ է դա, ինչպես է չափվում այս աշխատանքի որակը, և որն է այս որակը չափելու չափանիշը։

Ենթադրենք նաև, որ քիչ թե շատ հայտնի և հասկանալի է, թե կոնկրետ ինչպես է աշխատանքը կատարվում այս ծառայության համակարգում (կամ հետ):

«Քիչ թե շատ» - սա նշանակում է, որ հնարավոր է պատրաստել (կամ ստանալ այն ինչ-որ տեղից) որոշակի գործիք, օգտակարություն, ծառայություն, որը կարող է սինթեզվել և կիրառվել համակարգի վրա՝ բավականաչափ համարժեք փորձնական բեռով, ինչը կլինի արտադրության մեջ, արտադրության մեջ աշխատելու համար բավականաչափ բավարար պայմաններում։

Դե, եկեք ենթադրենք, որ այս ծառայության համակարգի ճշգրտման պարամետրերի մի շարք հայտնի է, որը կարող է օգտագործվել այս համակարգը կարգավորելու համար իր աշխատանքի արտադրողականության առումով:

Եվ ինչն է խնդիրը. չկա բավականաչափ ամբողջական պատկերացում այս սպասարկման համակարգի մասին, որը թույլ է տալիս Ձեզ հմտորեն կարգավորել այս համակարգի կարգավորումները տվյալ հարթակի վրա ապագա բեռնվածության համար և ստանալ համակարգի պահանջվող արտադրողականությունը:

Դե, Գրեթե միշտ այդպես է:

Ի՞նչ կարող ես անել այստեղ:

Դե, առաջին բանը, որ գալիս է մտքում, այս համակարգի փաստաթղթերին նայելն է: Հասկացեք, թե որոնք են ընդունելի միջակայքերը ճշգրտման պարամետրերի արժեքների համար: Եվ, օրինակ, օգտագործելով կոորդինատային ծագման մեթոդը, թեստերում ընտրեք արժեքներ համակարգի պարամետրերի համար:

Նրանք. համակարգին տալ որոշակի կոնֆիգուրացիա՝ իր կազմաձևման պարամետրերի արժեքների որոշակի հավաքածուի տեսքով:

Կիրառեք փորձնական բեռ դրա վրա՝ օգտագործելով հենց այս գործիքակազմը՝ բեռների գեներատորը:
Եվ նայեք արժեքին՝ արձագանքին կամ համակարգի որակի չափմանը:

Երկրորդ միտքը կարող է լինել այն եզրակացությունը, որ սա շատ երկար ժամանակ է։

Եթե կան շատ պարամետրերի պարամետրեր, եթե դրանց գործարկվող արժեքների միջակայքերը մեծ են, եթե յուրաքանչյուր անհատական բեռնման թեստ ավարտելու համար շատ ժամանակ է պահանջվում, ապա՝ այո, այս ամենը կարող է անընդունելի տևել։ երկար ժամանակ.

Դե, ահա թե ինչ կարող եք հասկանալ և հիշել.

Դուք կարող եք պարզել, որ ծառայության համակարգի պարամետրերի պարամետրերի արժեքների հավաքածուում կա վեկտոր, որպես որոշ արժեքների հաջորդականություն:

Յուրաքանչյուր նման վեկտոր, մյուսները հավասար են (այնով, որ դրա վրա չի ազդում այս վեկտորը), համապատասխանում է միանգամայն որոշակի մետրային արժեքի՝ փորձնական բեռի տակ համակարգի աշխատանքի որակի ցուցիչ:

Այսինքն,

Եկեք նշանակենք համակարգի կազմաձևման վեկտորը որպես Որտեղ ; Որտեղ — համակարգի կազմաձևման պարամետրերի քանակը, այդ պարամետրերից քանիսն են:

Եվ սրան համապատասխան չափիչի արժեքը նշենք որպես
, ապա ստանում ենք ֆունկցիա.

Դե, ուրեմն. ամեն ինչ անմիջապես հանգում է իմ դեպքում՝ գրեթե մոռացված իմ ուսանողական տարիներից, ֆունկցիայի էքստրեմում փնտրելու ալգորիթմներին:

Լավ, բայց այստեղ կազմակերպչական և կիրառական հարց է առաջանում՝ ո՞ր ալգորիթմն օգտագործել։

Այն իմաստով, որ դուք կարող եք ավելի քիչ կոդավորել ձեռքով:
Եվ որպեսզի այն աշխատի, այսինքն. գտել է էքստրեմումը (եթե այդպիսին կա), լավ, առնվազն ավելի արագ, քան կոորդինատային ծագումը:

Առաջին կետը հուշում է, որ մենք պետք է նայենք դեպի որոշ միջավայրեր, որտեղ նման ալգորիթմներն արդեն ներդրվել են և ինչ-որ ձևով պատրաստ են կոդում օգտագործելու համար:
Դե, ես գիտեմ python и cran-r

Երկրորդ կետը նշանակում է, որ դուք պետք է կարդաք հենց ալգորիթմների մասին, թե որոնք են դրանք, ինչ պահանջներ ունեն, ինչպես նաև դրանց աշխատանքի առանձնահատկությունները:

Իսկ այն, ինչ նրանք տալիս են, կարող է օգտակար կողմնակի էֆեկտներ լինել՝ արդյունքներ, կամ ուղղակիորեն հենց ալգորիթմից:

Կամ դրանք կարելի է ստանալ ալգորիթմի արդյունքներից։

Շատ բան կախված է մուտքային պայմաններից:

Օրինակ, եթե ինչ-ինչ պատճառներով ձեզ անհրաժեշտ է ավելի արագ արդյունք ստանալ, լավ, դուք պետք է նայեք դեպի գրադիենտ ծագման ալգորիթմներ և ընտրեք դրանցից մեկը:

Կամ, եթե ժամանակն այնքան էլ կարևոր չէ, կարող եք, օրինակ, օգտագործել ստոխաստիկ օպտիմալացման մեթոդներ, օրինակ՝ գենետիկական ալգորիթմ։

Առաջարկում եմ դիտարկել այս մոտեցման աշխատանքը՝ ընտրելով համակարգի կոնֆիգուրացիան, օգտագործելով գենետիկական ալգորիթմը, այսպես ասած՝ լաբորատոր աշխատանքում:

Բնօրինակը:

Թող լինի, որպես սպասարկման համակարգ. oracle xe 18c
Թող այն ծառայի գործարքային գործունեությանը և նպատակին. ստանալ ենթաբազայի հնարավոր առավելագույն թողունակությունը՝ գործարքների/վրկ.
Գործարքները կարող են շատ տարբեր լինել տվյալների հետ աշխատելու բնույթով և աշխատանքի համատեքստով:
Համաձայնենք, որ դրանք գործարքներ են, որոնք չեն մշակում մեծ քանակությամբ աղյուսակային տվյալներ։
Այն իմաստով, որ նրանք չեն առաջացնում ավելի շատ հետարկել տվյալները, քան կրկնել, և չեն մշակում տողերի և մեծ աղյուսակների մեծ տոկոսներ:

Սրանք գործարքներ են, որոնք փոխում են մեկ տող քիչ թե շատ մեծ աղյուսակում, այս աղյուսակում ինդեքսների փոքր քանակով:

Այս իրավիճակում գործարքների մշակման ենթաբազայի արտադրողականությունը, վերապահումով, որոշվելու է ռեդոքս տվյալների բազայի կողմից մշակման որակով:

Հրաժարում - եթե խոսենք կոնկրետ subdb-ի կարգավորումների մասին:

Քանի որ, ընդհանուր դեպքում, կարող են լինել, օրինակ, գործարքային կողպումներ SQL նիստերի միջև՝ աղյուսակային տվյալների և/կամ աղյուսակային մոդելի հետ օգտագործողի աշխատանքի նախագծման պատճառով։

Ինչն, իհարկե, ճնշող ազդեցություն կունենա TPS-ի չափման վրա, և սա կլինի էկզոգեն գործոն՝ ենթաբազայի համեմատ. լավ, այսպես է նախագծվել աղյուսակային մոդելը և աշխատել դրա հետ կապված տվյալների հետ, երբ խցանումներ են առաջանում:

Հետևաբար, փորձի մաքրության համար մենք կբացառենք այս գործոնը, իսկ ստորև կհստակեցնեմ, թե ինչպես։

Հստակության համար ենթադրենք, որ տվյալների բազա ներկայացված SQL հրամանների 100%-ը DML հրամաններ են:
Թող ենթաբազայի հետ օգտագործողի աշխատանքի բնութագրերը նույնը լինեն թեստերում:
Մասնավորապես՝ skl նիստերի քանակը, աղյուսակային տվյալները, ինչպես են աշխատում skl նիստերը դրանց հետ:
Subd-ն աշխատում է FORCE LOGGING, ARCHIVELOG ռեժիմներ. Flashback-ի տվյալների բազայի ռեժիմն անջատված է, ենթադ մակարդակում:
Կրկնել տեղեկամատյանները. գտնվում է առանձին ֆայլային համակարգում, առանձին «սկավառակի» վրա;
Տվյալների բազայի մնացած ֆիզիկական բաղադրիչը՝ մեկ այլ, առանձին ֆայլային համակարգում, առանձին «սկավառակի» վրա.

Լրացուցիչ մանրամասներ ֆիզիկական սարքի մասին: լաբորատոր բազայի բաղադրիչներ

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 մեթոդը նպատակ ունի փորձարկել հարթակներ
առանց հայտի վեճի: Չի կարելի ապահովել ապարատային առավելագույն կատարողականություն
օգտագործելով հավելվածի կոդը, որը, օրինակ, կապված է հավելվածի կողպման կամ նույնիսկ
Oracle Database բլոկների փոխանակում: Դա ճիշտ է. տվյալների փոխանակման ժամանակ ավելորդ ծախսեր կան
տվյալների բլոկներում! Բայց SLOB-ն իր լռելյայն տեղակայման մեջ անձեռնմխելի է նման վեճերից:

Այս հայտարարությունը. համապատասխանում է, այդպես է:
Հարմար է կարգավորել cl նիստերի զուգահեռության աստիճանը, սա է բանալին -t գործարկել կոմունալ ծրագիրը runit.sh SLOB-ից
DML հրամանների տոկոսը կարգավորվում է ստորադասին ուղարկվող տեքստային հաղորդագրությունների քանակով, յուրաքանչյուր տեքստային նստաշրջան, պարամետր: UPDATE_PCT
Առանձին և շատ հարմար. SLOB ինքը, բեռնման նիստից առաջ և հետո - պատրաստում է statspack կամ awr-snapshots (այն, ինչ նախատեսված է պատրաստվելու):

Սակայն պարզվեց, որ SLOB չի աջակցում SQL նիստերը 30 վայրկյանից պակաս տևողությամբ:
Ուստի ես նախ կոդավորեցի բեռնիչի սեփական, բանվոր-գյուղացիական տարբերակը, հետո այն մնաց գործի մեջ։

Պարզության համար պարզաբանեմ, թե ինչ է անում բեռնիչը և ինչպես է դա անում:
Ըստ էության, բեռնիչը հետևյալ տեսքն ունի.

Աշխատողի կոդը

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 նիստ DB-ում) ստեղծվում է առանձին աղյուսակ, որով աշխատողն աշխատում է։

Սա ապահովում է աշխատողների նիստերի միջև գործարքային կողպեքների բացակայությունը:
Յուրաքանչյուր աշխատող. նույն բանն է անում, իր սեղանով, սեղանները նույնն են։
Բոլոր աշխատողները աշխատանքը կատարում են նույն ժամանակահատվածում:
Ավելին, բավական երկար ժամանակ, որպեսզի, օրինակ, լոգերի անջատումը անպայման տեղի ունենա, և ավելի քան մեկ անգամ:
Դե, համապատասխանաբար, առաջացան հարակից ծախսերն ու հետևանքները:
Իմ դեպքում ես կարգավորեցի աշխատողների աշխատանքի տևողությունը 8 րոպե:

statspack հաշվետվության մի հատված, որը նկարագրում է ենթադ-ի աշխատանքը բեռի տակ

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, 1024] ՄԲ;
Տվյալների բազայում ամսագրերի խմբերի քանակը: արժեքի միջակայք՝ [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;

Oracle-ի տվյալների շտեմարանների պահպանման փորձ ունեցող անձը, անշուշտ, արդեն կարող է ասել, թե ինչ և ինչ արժեքներ պետք է սահմանվեն՝ նշված պարամետրերից և դրանց ընդունելի արժեքներից, որպեսզի տվյալների բազայի ավելի մեծ արտադրողականություն ստանա տվյալների հետ աշխատանքի համար, որոնք նշված են. դիմումի կոդը, այստեղ վերևում:

Սակայն

Լաբորատոր աշխատանքի նպատակն է ցույց տալ, որ օպտիմալացման ալգորիթմն ինքնին համեմատաբար արագ կպարզաբանի դա մեզ համար:

Մեզ մնում է միայն փաստաթղթի մեջ դիտարկել՝ հարմարեցվող համակարգի միջոցով, բավական է պարզել, թե ինչ պարամետրեր պետք է փոխել և ինչ տիրույթներում:
Եվ նաև՝ կոդավորեք կոդը, որը կօգտագործվի ընտրված օպտիմալացման ալգորիթմի մաքսային համակարգի հետ աշխատելու համար:

Այսպիսով, հիմա կոդի մասին:
Ես վերևում խոսեցի դրա մասին cran-r, այսինքն՝ հարմարեցված համակարգի հետ բոլոր մանիպուլյացիաները կազմակերպվում են R գրագրի տեսքով:

Փաստացի առաջադրանք, վերլուծություն, ընտրություն ըստ մետրային արժեքների, համակարգի վիճակի վեկտորներ. սա փաթեթ է GA (փաստաթղթերը)
Փաթեթը, այս դեպքում, այնքան էլ հարմար չէ, այն առումով, որ ակնկալում է, որ վեկտորները (քրոմոսոմները, եթե փաթեթի առումով) պետք է նշվեն կոտորակային մասով թվերի տողերի տեսքով։

Եվ իմ վեկտորը, պարամետրերի պարամետրերի արժեքներից. սրանք 14 մեծություններ են՝ ամբողջ թվեր և լարային արժեքներ:

Խնդիրն, իհարկե, հեշտությամբ կարելի է խուսափել՝ լարային արժեքներին որոշակի թվեր վերագրելով։

Այսպիսով, ի վերջո, R սցենարի հիմնական հատվածն այսպիսի տեսք ունի.

Զանգահարեք ԳԱ::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 ենթածրագրը կատարում է որոնում՝ առավելագույնի հասցնելով ֆիթնեսի ֆունկցիան:

Դե, ուրեմն, պարզվում է, որ այս դեպքում անհրաժեշտ է, որ ֆիթնես ֆունկցիան, հասկանալով վեկտորը որպես subd-ի որոշակի պարամետրերի արժեքների հավաքածու, ստանա չափիչ subd-ից:

Այսինքն՝ քանիսը, տվյալ subd-ի կարգավորումով և 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-ը մշակում է վեկտորները, կամ ավելի ճիշտ՝ քրոմոսոմները։
Որում մեզ համար ամենակարևորը գեներով քրոմոսոմների ընտրությունն է, որոնց համար ֆիթնես ֆունկցիան մեծ արժեքներ է տալիս:

Սա, ըստ էության, քրոմոսոմների օպտիմալ հավաքածուի որոնման գործընթացն է՝ օգտագործելով վեկտորը N ծավալային որոնման տարածքում:

Շատ պարզ, մանրամասն բացատրություն, R-կոդի օրինակներով, գենետիկական ալգորիթմի աշխատանք։

Առանձին-առանձին կցանկանայի նշել երկու տեխնիկական կետ.

Օժանդակ զանգեր գործառույթից evaluate, օրինակ, stop-start, սահմանելով 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 գործառույթները՝ պահպանելով որոշակի մետրային արժեք և դրա համապատասխան թյունինգ վեկտորը log ֆայլում.

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

Սա կարևոր է, քանի որ այս տվյալների զանգվածից հնարավոր կլինի լրացուցիչ տեղեկատվություն ստանալ այն մասին, թե թյունինգ վեկտորի բաղադրիչներից որն է ավելի մեծ կամ փոքր ազդեցություն թողնում մետրային արժեքի վրա:

Այսինքն՝ հնարավոր կլինի իրականացնել ատրիբուտ-կարևոր վերլուծություն։

Այսպիսով, ինչ կարող է լինել:

Գրաֆիկական ձևով, եթե թեստերը պատվիրում եք աճման մետրական կարգով, ապա պատկերը հետևյալն է.

Որոշ տվյալներ, որոնք համապատասխանում են չափման ծայրահեղ արժեքներին.

Այստեղ, արդյունքների հետ կապված սքրինշոթում, ես կպարզաբանեմ. թյունինգ վեկտորի արժեքները տրված են ֆիթնես ֆունկցիայի կոդի առումով, այլ ոչ թե պարամետրերի թվային ցանկի/պարամետրերի արժեքների միջակայքի, որը ձևակերպվել է: վերը նշված տեքստում:

Դե, Շա՞տ է, թե՞ քիչ, ~8 հազար տ/վ. առանձին հարց.
Լաբորատոր աշխատանքների շրջանակներում այս ցուցանիշը էական չէ, կարեւորը դինամիկան է, թե ինչպես է փոխվում այդ արժեքը։

Այստեղ դինամիկան լավ է։
Ակնհայտ է, որ առնվազն մեկ գործոն էապես ազդում է մետրիկի արժեքի վրա՝ ga-ալգորիթմը, որը դասավորում է քրոմոսոմային վեկտորների միջոցով՝ ծածկված։
Դատելով կորի արժեքների բավականին աշխույժ դինամիկայից, կա առնվազն ևս մեկ գործոն, որը թեև զգալիորեն փոքր է, բայց ազդեցություն ունի:

Սա այն վայրն է, որտեղ դուք դրա կարիքն ունեք attribute-importance վերլուծություն՝ հասկանալու համար, թե ինչ հատկանիշներ (այս դեպքում՝ թյունինգ վեկտորի բաղադրիչները) և որքանով են դրանք ազդում մետրային արժեքի վրա:
Եվ այս տեղեկատվությունից՝ հասկանալ, թե ինչ գործոնների վրա են ազդել էական հատկանիշների փոփոխությունները:

Կատարել attribute-importance հնարավոր է տարբեր ձևերով:

Այս նպատակների համար ինձ դուր է գալիս ալգորիթմը randomForest R համանուն փաթեթ (փաստաթղթերը)
randomForest, քանի որ ես հասկանում եմ նրա աշխատանքն ընդհանրապես և նրա մոտեցումը հատկապես ատրիբուտների կարևորությունը գնահատելու հարցում, կառուցում է ատրիբուտներից պատասխան փոփոխականի կախվածության որոշակի մոդել:

Մեր դեպքում, պատասխան փոփոխականը չափիչ է, որը ստացվում է բեռնվածության թեստերի տվյալների բազայից. tps;
Իսկ ատրիբուտները թյունինգ վեկտորի բաղադրիչներն են:

Այսպիսով randomForest գնահատում է յուրաքանչյուր մոդելի հատկանիշի կարևորությունը երկու թվով. %IncMSE — ինչպես է մոդելում այս հատկանիշի առկայությունը/բացակայությունը փոխում այս մոդելի MSE որակը (Mean Squared Error);

Եվ IncNodePurity-ն այն թիվն է, որն արտացոլում է, թե այս հատկանիշի արժեքների հիման վրա որքանով կարող է բաժանվել դիտարկումներով տվյալների բազան, այնպես որ մի մասում կան տվյալներ՝ բացատրվող չափման մեկ արժեքով, իսկ մյուսում՝ չափման մեկ այլ արժեք:
Դե, դա այն է, թե որքանով է սա դասակարգող հատկանիշ (ես տեսա ամենահստակ, ռուսալեզու բացատրությունը RandomForest-ում այստեղ).

Աշխատավոր-գյուղացիական R-կոդ՝ ծանրաբեռնվածության թեստերի արդյունքներով տվյալների բազա մշակելու համար.

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 գործողության կատարման ռեժիմը՝ subdb log բուֆերից ռեդո տվյալները գրելու ընթացիկ log խմբին՝ համաժամանակյա կամ ասինխրոն։
Արժեք nowait ինչը հանգեցնում է tps մետրի արժեքի գրեթե ուղղահայաց, բազմակի աճի. սա ասինխրոն io ռեժիմի ընդգրկումն է redo խմբերում:
Առանձին հարց է, թե արդյոք դուք պետք է դա անեք սննդի տվյալների բազայում, թե ոչ: Այստեղ ես սահմանափակվում եմ միայն նշելով. սա էական գործոն է։
Տրամաբանական է, որ subd-ի log buffer-ի չափը պարզվում է, որ նշանակալի գործոն է։
Որքան փոքր է լոգարիթմական բուֆերի չափը, այնքան քիչ է նրա բուֆերային հզորությունը, այնքան ավելի հաճախ է այն հորդում և/կամ անկարողությունը նրանում ազատ տարածք հատկացնել նոր ռեդոքսային տվյալների մի մասի համար։
Սա նշանակում է՝ ուշացումներ՝ կապված տեղեկամատյանների բուֆերում տարածք հատկացնելու և/կամ դրանից կրկնվող տվյալների վերափոխման խմբերի մեջ թափելու հետ:
Այս ուշացումները, իհարկե, պետք է և ազդում են գործարքների տվյալների բազայի թողունակության վրա:
Parameter db_block_checksumԴե, նաև, ընդհանուր առմամբ, պարզ է. գործարքների մշակումը հանգեցնում է ենթաբազայի բուֆերային քեշում darty բլոկների ձևավորմանը:
Որը, երբ տվյալների բլոկների ստուգման գումարները միացված են, տվյալների բազան պետք է մշակի - հաշվարկի այս ստուգիչ գումարները տվյալների բլոկի մարմնից, ստուգեք դրանք տվյալների բլոկի վերնագրում գրվածով. համընկնում է/չի համընկնում:
Նման աշխատանքը, կրկին, չի կարող չհետաձգել տվյալների մշակումը, և, համապատասխանաբար, այս պարամետրը սահմանող պարամետրը և մեխանիզմը նշանակալի են դառնում։
Ահա թե ինչու վաճառողը առաջարկում է այս պարամետրի փաստաթղթերում տարբեր արժեքներ և նշում, որ այո, ազդեցություն կլինի, բայց դուք կարող եք ընտրել տարբեր արժեքներ, նույնիսկ «անջատված» և տարբեր ազդեցություններ:

Դե, գլոբալ եզրակացություն.

Մոտեցումը, ընդհանուր առմամբ, բավականին աշխատունակ է ստացվում։

Նա բավականին թույլ է տալիս իրեն որոշակի սպասարկման համակարգի բեռնվածության փորձարկման վաղ փուլերում, որպեսզի ընտրի դրա (համակարգի) օպտիմալ կոնֆիգուրացիան բեռի համար, շատ չխորանա բեռի համար համակարգը կարգավորելու առանձնահատկությունների մեջ:

Բայց դա ամբողջությամբ չի բացառում, գոնե ըմբռնման մակարդակով. համակարգը պետք է հայտնի լինի «կարգավորման գլխիկների» և այդ կոճակների պտտման թույլատրելի միջակայքերի մասին:

Այնուհետև մոտեցումը կարող է համեմատաբար արագ գտնել համակարգի օպտիմալ կոնֆիգուրացիան:
Եվ թեստավորման արդյունքների հիման վրա հնարավոր է տեղեկատվություն ստանալ համակարգի կատարողականի չափանիշների և համակարգի պարամետրերի պարամետրերի արժեքների միջև կապի բնույթի մասին:

Ինչն, իհարկե, պետք է նպաստի համակարգի այս շատ խորը ըմբռնմանը, նրա գործունեությանը, թեկուզ տվյալ ծանրաբեռնվածության ներքո։

Գործնականում սա հարմարեցված համակարգը հասկանալու ծախսերի փոխանակում է համակարգի նման փորձարկման պատրաստման ծախսերի հետ:

Առանձին-առանձին կցանկանայի նշել. այս մոտեցման մեջ չափազանց կարևոր է համակարգի փորձարկման համարժեքության աստիճանը գործառնական պայմաններին, որոնք այն կունենա առևտրային շահագործման ընթացքում:

Շնորհակալություն ուշադրության և ժամանակի համար։

Source: www.habr.com

Գիտական պոկման մեթոդը կամ ինչպես ընտրել տվյալների բազայի կոնֆիգուրացիան՝ օգտագործելով հենանիշներ և օպտիմալացման ալգորիթմ

Добавить комментарий Չեղարկել պատասխանել

Գիտական ​​պոկման մեթոդը կամ ինչպես ընտրել տվյալների բազայի կոնֆիգուրացիան՝ օգտագործելով հենանիշներ և օպտիմալացման ալգորիթմ

Добавить комментарий Չեղարկել պատասխանել

Գիտական պոկման մեթոդը կամ ինչպես ընտրել տվյալների բազայի կոնֆիգուրացիան՝ օգտագործելով հենանիշներ և օպտիմալացման ալգորիթմ