Helo
Penderfynais rannu fy nghanfyddiad - ffrwyth meddwl, prawf a chamgymeriad.
Ar y cyfan: nid yw hwn yn ddarganfyddiad, wrth gwrs - dylai hyn i gyd fod wedi bod yn hysbys ers amser maith, i'r rhai sy'n ymwneud â phrosesu data ystadegol cymhwysol ac optimeiddio unrhyw systemau, nid o reidrwydd yn benodol y DBMS.
Ac: ydyn, maen nhw'n gwybod, maen nhw'n ysgrifennu erthyglau diddorol ar eu hymchwil, (UPD.: yn y sylwadau fe wnaethon nhw dynnu sylw at brosiect diddorol iawn: )
Ar y llaw arall: oddi ar y llaw arall, ni welaf unrhyw sôn na lledaeniad eang o'r dull hwn ar y Rhyngrwyd ymhlith arbenigwyr TG, DBA.
Felly, i'r pwynt.
Gadewch i ni dybio bod gennym dasg: sefydlu system wasanaeth benodol i wasanaethu rhyw fath o waith.
Mae'n hysbys am y gwaith hwn: beth ydyw, sut mae ansawdd y gwaith hwn yn cael ei fesur, a beth yw'r maen prawf ar gyfer mesur yr ansawdd hwn.
Gadewch i ni hefyd dybio ei fod yn fwy neu lai yn hysbys ac yn cael ei ddeall: yn union sut mae gwaith yn cael ei berfformio yn (neu gyda) y system gwasanaeth hon.
“Mwy neu lai” - mae hyn yn golygu ei bod hi'n bosibl paratoi (neu ei gael o rywle) offeryn, cyfleustodau, gwasanaeth penodol y gellir ei syntheseiddio a'i gymhwyso i'r system gyda llwyth prawf sy'n ddigon digonol i'r hyn a fydd yn cael ei gynhyrchu, mewn amodau digon digonol ar gyfer gweithio ym maes cynhyrchu .
Wel, gadewch i ni dybio bod set o baramedrau addasu ar gyfer y system wasanaeth hon yn hysbys, y gellir eu defnyddio i ffurfweddu'r system hon o ran cynhyrchiant ei waith.
A beth yw'r broblem - nid oes dealltwriaeth ddigon cyflawn o'r system wasanaeth hon, un sy'n eich galluogi i ffurfweddu gosodiadau'r system hon yn arbenigol ar gyfer llwyth yn y dyfodol ar lwyfan penodol a chael cynhyrchiant gofynnol y system.
Wel. Mae hyn bron bob amser yn wir.
Beth allwch chi ei wneud yma?
Wel, y peth cyntaf sy'n dod i'r meddwl yw edrych ar y dogfennau ar gyfer y system hon. Deall beth yw'r ystodau derbyniol ar gyfer gwerthoedd y paramedrau addasu. Ac, er enghraifft, gan ddefnyddio'r dull disgyniad cydlynu, dewiswch werthoedd ar gyfer paramedrau system mewn profion.
Y rhai. rhoi rhyw fath o ffurfweddiad i'r system, ar ffurf set benodol o werthoedd ar gyfer ei baramedrau cyfluniad.
Gwneud cais llwyth prawf iddo, gan ddefnyddio hwn iawn offeryn-cyfleustodau, generadur llwyth.
Ac edrychwch ar y gwerth - yr ymateb, neu fetrig o ansawdd y system.
Efallai mai'r ail feddwl yw'r casgliad bod hwn yn amser hir iawn.
Wel, hynny yw: os oes llawer o osod paramedrau, os yw ystodau eu gwerthoedd sy'n cael eu rhedeg yn fawr, os yw pob prawf llwyth unigol yn cymryd llawer o amser i'w gwblhau, yna: ie, gall hyn i gyd gymryd yn annerbyniol amser hir.
Wel, dyma beth allwch chi ei ddeall a'i gofio.
Gallwch ddarganfod bod yna fector yn y set o werthoedd o baramedrau gosodiadau'r system gwasanaeth, fel dilyniant o rai gwerthoedd.
Mae pob fector o'r fath, gyda phethau eraill yn gyfartal (yn yr ystyr nad yw'r fector hwn yn effeithio arno), yn cyfateb i werth cwbl bendant y metrig - dangosydd o ansawdd gweithrediad y system o dan lwyth prawf.
Hy
Gadewch inni ddynodi fector cyfluniad y system fel 
lle ; Lle — nifer y paramedrau cyfluniad system, faint o'r paramedrau hyn sydd.
A gwerth y metrig sy'n cyfateb i hyn gadewch i ni ei ddynodi fel
, yna rydym yn cael swyddogaeth:
Wel, felly: mae popeth yn syth i lawr i, yn fy achos i: bron wedi anghofio o fy nyddiau myfyriwr, algorithmau ar gyfer chwilio am eithaf swyddogaeth.
Iawn, ond yma mae cwestiwn sefydliadol a chymhwysol yn codi: pa algorithm i'w ddefnyddio.
- Yn yr ystyr - fel y gallwch chi godio llai â llaw.
- Ac iddo weithio, h.y. dod o hyd i'r eithaf (os oes un), yn dda, o leiaf yn gyflymach na disgyniad cyfesurynnol.
Mae'r pwynt cyntaf yn awgrymu bod angen inni edrych tuag at rai amgylcheddau lle mae algorithmau o'r fath eisoes wedi'u gweithredu, a'u bod, ar ryw ffurf, yn barod i'w defnyddio mewn cod.
Wel, dwi'n gwybod python и cran-r
Mae'r ail bwynt yn golygu bod angen i chi ddarllen am yr algorithmau eu hunain, beth ydyn nhw, beth yw eu gofynion, a nodweddion eu gwaith.
A gall yr hyn y maent yn ei roi fod yn sgîl-effeithiau defnyddiol - canlyniadau, neu'n uniongyrchol o'r algorithm ei hun.
Neu gellir eu cael o ganlyniadau'r algorithm.
Mae llawer yn dibynnu ar yr amodau mewnbwn.
Er enghraifft, os, am ryw reswm, mae angen i chi gael canlyniad yn gyflymach, wel, mae angen ichi edrych tuag at algorithmau disgyniad graddiant a dewis un ohonynt.
Neu, os nad yw amser mor bwysig, gallwch, er enghraifft, ddefnyddio dulliau optimeiddio stochastig, megis algorithm genetig.
Rwy'n cynnig ystyried gwaith y dull hwn, gan ddewis cyfluniad y system, gan ddefnyddio algorithm genetig, yn y nesaf, fel petai: gwaith labordy.
Gwreiddiol:
- Gadewch i ni fod, fel system gwasanaeth:
oracle xe 18c - Gadewch iddo wasanaethu gweithgaredd trafodion a'r nod: cael y trwybwn uchaf posibl o'r is-gronfa ddata, mewn trafodion/eiliad.
- Gall trafodion fod yn wahanol iawn o ran natur gweithio gyda data a chyd-destun gwaith.
Gadewch i ni gytuno bod y rhain yn drafodion nad ydynt yn prosesu llawer iawn o ddata tabl.
Yn yr ystyr nad ydynt yn cynhyrchu mwy o ddadwneud data nag ail-wneud ac nid ydynt yn prosesu canrannau mawr o resi a thablau mawr.
Trafodion yw’r rhain sy’n newid un rhes mewn tabl mwy neu lai mawr, gyda nifer fach o fynegeion ar y tabl hwn.
Yn y sefyllfa hon: bydd cynhyrchiant yr is-gronfa ddata ar gyfer prosesu trafodion yn cael ei bennu, gydag archeb, gan ansawdd y prosesu gan y gronfa ddata redox.
Ymwadiad - os ydym yn siarad yn benodol am y gosodiadau subdb.
Oherwydd, yn gyffredinol, efallai y bydd cloeon trafodaethol rhwng sesiynau SQL, er enghraifft, oherwydd dyluniad gwaith defnyddwyr gyda data tabl a/neu'r model tabl.
A fydd, wrth gwrs, yn cael effaith ddigalon ar y metrig TPS a bydd hyn yn ffactor alldarddol, o'i gymharu â'r is-gronfa ddata: wel, dyma sut y cynlluniwyd y model tabl a'r gwaith gyda data ynddo y mae rhwystrau'n digwydd.
Felly, ar gyfer purdeb yr arbrawf, byddwn yn eithrio'r ffactor hwn, ac isod byddaf yn egluro'n union sut.
- Gadewch i ni dybio, yn bendant, bod 100% o'r gorchmynion SQL a gyflwynir i'r gronfa ddata yn orchmynion DML.
Gadewch i nodweddion gwaith defnyddwyr gyda'r is-gronfa ddata fod yr un fath mewn profion.
Sef: nifer y sesiynau skl, data tabl, sut mae sesiynau skl yn gweithio gyda nhw. - Mae Subd yn gweithio yn
FORCE LOGGING,ARCHIVELOGmodiau. Modd Flashback-cronfa ddata wedi'i ddiffodd, ar y lefel is. - Logiau ail-wneud: wedi'u lleoli mewn system ffeiliau ar wahân, ar “ddisg” ar wahân;
Gweddill cydran ffisegol y gronfa ddata: mewn system ffeiliau ar wahân arall, ar “ddisg” ar wahân:
Mwy o fanylion am y ddyfais gorfforol. cydrannau cronfa ddata labordy
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 0I ddechrau, o dan yr amodau llwyth hyn, roeddwn i eisiau defnyddio subd trafodiad
Mae ganddo nodwedd mor wych, dyfynnaf yr awdur:
Wrth wraidd SLOB mae'r “dull SLOB.” Nod y Dull SLOB yw profi llwyfannau
heb gynnen cais. Ni all un yrru perfformiad caledwedd uchaf
defnyddio cod cais sydd, er enghraifft, wedi'i rwymo gan gloi cais neu hyd yn oed
rhannu blociau Cronfa Ddata Oracle. Mae hynny'n iawn—mae yna orbenion wrth rannu data
mewn blociau data! Ond mae SLOB - yn ei ddefnydd diofyn - yn imiwn i gynnen o'r fath.
Mae'r datganiad hwn: yn cyfateb, y mae.
Mae'n gyfleus i reoleiddio graddau paraleliaeth sesiynau cl, dyma'r allwedd -t lansio'r cyfleustodau runit.sh oddi wrth SLOB
Mae canran y gorchmynion DML yn cael ei reoleiddio, yn nifer y negeseuon testun sy'n cael eu hanfon i'r subd, pob sesiwn testun, paramedr UPDATE_PCT
Ar wahân ac yn gyfleus iawn: SLOB ei hun, cyn ac ar ôl y sesiwn llwytho - paratoi statspack, neu awr-cipluniau (yr hyn sydd i'w baratoi).
Fodd bynnag, mae'n troi allan hynny SLOB nid yw'n cefnogi sesiynau SQL sy'n para llai na 30 eiliad.
Felly, yn gyntaf fe wnes i godio fy fersiwn gweithiwr-gwerinol fy hun o'r llwythwr, ac yna fe arhosodd ar waith.
Gadewch imi egluro beth mae'r llwythwr yn ei wneud a sut mae'n ei wneud, er eglurder.
Yn y bôn mae'r llwythwr yn edrych fel hyn:
Cod gweithiwr
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 dotxMae gweithwyr yn cael eu lansio fel hyn:
Gweithwyr rhedeg
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"
waitAc mae byrddau ar gyfer gweithwyr yn cael eu paratoi fel hyn:
Creu tablau
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"Y rhai. Ar gyfer pob gweithiwr (yn ymarferol: sesiwn SQL ar wahân yn y DB) mae tabl ar wahân yn cael ei greu, y mae'r gweithiwr yn gweithio gydag ef.
Mae hyn yn sicrhau absenoldeb cloeon trafodaethol rhwng sesiynau gweithwyr.
Pob gweithiwr: yn gwneud yr un peth, gyda'i fwrdd ei hun, mae'r byrddau i gyd yr un peth.
Mae pob gweithiwr yn perfformio gwaith am yr un faint o amser.
Ar ben hynny, am gyfnod digon hir fel bod, er enghraifft, switsh log yn bendant yn digwydd, a mwy nag unwaith.
Wel, yn unol â hynny, cododd costau ac effeithiau cysylltiedig.
Yn fy achos i, fe wnes i ffurfweddu hyd gwaith y gweithwyr ar 8 munud.
Darn o adroddiad statspack yn disgrifio gweithrediad y subd dan lwyth
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.1Dychwelyd i'r gwaith labordy.
Os bydd pethau eraill yn gyfartal, byddwn yn amrywio gwerthoedd paramedrau canlynol yr is-gronfa ddata labordy:
- Maint grwpiau log cronfa ddata. ystod gwerth: [32, 1024] MB;
- Nifer y grwpiau cyfnodolion yn y gronfa ddata. ystod gwerth: [2,32];
log_archive_max_processesystod gwerth: [1,8];commit_loggingcaniateir dau werth:batch|immediate;commit_waitcaniateir dau werth:wait|nowait;log_bufferystod gwerth: [2,128] MB.log_checkpoint_timeoutamrediad gwerth: [60,1200] eiliaddb_writer_processesystod gwerth: [1,4]undo_retentionystod gwerth: [30; 300] eiliadtransactions_per_rollback_segmentystod gwerth: [1,8]disk_asynch_iocaniateir dau werth:true|false;filesystemio_optionscaniateir y gwerthoedd canlynol:none|setall|directIO|asynch;db_block_checkingcaniateir y gwerthoedd canlynol:OFF|LOW|MEDIUM|FULL;db_block_checksumcaniateir y gwerthoedd canlynol:OFF|TYPICAL|FULL;
Yn sicr, gall person sydd â phrofiad o gynnal cronfeydd data Oracle eisoes ddweud beth ac i ba werthoedd y dylid eu gosod, o'r paramedrau penodedig a'u gwerthoedd derbyniol, er mwyn cael mwy o gynhyrchiant y gronfa ddata ar gyfer y gwaith gyda data a nodir gan cod y cais , yma uchod.
Ond.
Pwynt y gwaith labordy yw dangos y bydd yr algorithm optimeiddio ei hun yn egluro hyn i ni yn gymharol gyflym.
I ni, y cyfan sydd ar ôl yw edrych i mewn i'r ddogfen, trwy'r system y gellir ei haddasu, dim ond digon i ddarganfod pa baramedrau i'w newid ac ym mha ystodau.
A hefyd: codwch y cod a fydd yn cael ei ddefnyddio i weithio gyda system arfer yr algorithm optimeiddio a ddewiswyd.
Felly, yn awr am y cod.
Soniais uchod am cran-r, h.y.: mae pob triniaeth â'r system wedi'i haddasu yn cael ei threfnu ar ffurf sgript R.
Y dasg wirioneddol, dadansoddi, dewis yn ôl gwerth metrig, fectorau cyflwr system: pecyn yw hwn GA ()
Nid yw'r pecyn, yn yr achos hwn, yn addas iawn, yn yr ystyr ei fod yn disgwyl i fectorau (cromosomau, os o ran y pecyn) gael eu nodi ar ffurf llinynnau rhifau â rhan ffracsiynol.
A fy fector, o werthoedd y paramedrau gosod: mae'r rhain yn 14 meintiau - cyfanrifau a gwerthoedd llinynnol.
Mae'n hawdd osgoi'r broblem, wrth gwrs, trwy neilltuo rhai rhifau penodol i werthoedd llinynnol.
Felly, yn y diwedd, mae prif ddarn y sgript R yn edrych fel hyn:
Ffoniwch 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@solutionYma, gyda chymorth lower и upper priodoleddau is-reolwaith ga yn y bôn, mae ardal o'r gofod chwilio wedi'i nodi, ac o fewn hynny bydd chwiliad yn cael ei berfformio ar gyfer fector (neu fectorau) o'r fath y ceir gwerth mwyaf y swyddogaeth ffitrwydd ar ei gyfer.
Mae'r is-reolwaith ga yn perfformio chwiliad gan wneud y gorau o'r swyddogaeth ffitrwydd.
Wel, felly, mae'n ymddangos, yn yr achos hwn, bod angen i'r swyddogaeth ffitrwydd, gan ddeall y fector fel set o werthoedd ar gyfer paramedrau penodol yr subd, dderbyn metrig o'r subd.
Hynny yw: faint, gyda gosodiad subd penodol a llwyth penodol ar yr subd: mae'r subd yn prosesu trafodion yr eiliad.
Hynny yw, wrth ddatblygu, rhaid cyflawni'r aml-gam canlynol y tu mewn i'r swyddogaeth ffitrwydd:
- Prosesu fector mewnbwn rhifau - ei drawsnewid yn werthoedd ar gyfer paramedrau'r is-ddata.
- Ymgais i greu nifer penodol o grwpiau ail-wneud o faint penodol. Ar ben hynny, gall yr ymgais fod yn aflwyddiannus.
Grwpiau cylchgronau a fodolai eisoes yn y subd, mewn rhyw faint ac o ryw faint, er purdeb yr arbrawf — d.b. dileu. - Os yw'r pwynt blaenorol yn llwyddiannus: nodi gwerthoedd paramedrau cyfluniad i'r gronfa ddata (eto: efallai y bydd methiant)
- Os yw'r cam blaenorol yn llwyddiannus: atal yr subd, cychwyn yr subd fel bod y gwerthoedd paramedr sydd newydd eu pennu yn dod i rym. (eto: efallai bod yna glitch)
- Os yw'r cam blaenorol yn llwyddiannus: gwnewch brawf llwyth. cael metrigau o subd.
- Dychwelyd yr subd i'w gyflwr gwreiddiol, h.y. dileu grwpiau log ychwanegol, dychwelyd ffurfweddiad yr is-gronfa ddata wreiddiol i weithio.
Cod swyddogaeth ffitrwydd
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)
}Hynny. holl waith: perfformio yn y swyddogaeth ffitrwydd.
Mae'r ga-suboutine yn prosesu fectorau, neu, yn fwy cywir, cromosomau.
Yn yr hwn, yr hyn sydd bwysicaf i ni yw dewis cromosomau â genynnau y mae'r swyddogaeth ffitrwydd yn cynhyrchu gwerthoedd mawr ar eu cyfer.
Dyma, yn ei hanfod, y broses o chwilio am y set orau o gromosomau gan ddefnyddio fector mewn gofod chwilio N-dimensiwn.
Yn glir iawn, yn fanwl , gydag enghreifftiau o god-R, gwaith algorithm genetig.
Hoffwn nodi dau bwynt technegol ar wahân.
Galwadau ategol o'r swyddogaeth evaluate, er enghraifft, stop-cychwyn, gosod gwerth y paramedr subd, yn cael eu perfformio yn seiliedig ar cran-r swyddogaethau system2
Gyda chymorth pa: gelwir rhywfaint o sgript bash neu orchymyn.
Er enghraifft:
set_db_paramedr
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)
}
}Yr ail bwynt yw'r llinell, evaluate swyddogaethau, gydag arbed gwerth metrig penodol a'i fector tiwnio cyfatebol i ffeil log:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Mae hyn yn bwysig, oherwydd o'r casgliad data hwn, bydd yn bosibl cael gwybodaeth ychwanegol am ba rai o gydrannau'r fector tiwnio sy'n cael effaith fwy neu lai ar y gwerth metrig.
Hynny yw: bydd yn bosibl cynnal dadansoddiad o bwysigrwydd priodoledd.
Felly beth all ddigwydd?
Ar ffurf graff, os ydych chi'n archebu'r profion mewn trefn fetrig esgynnol, mae'r llun fel a ganlyn:
Peth data sy'n cyfateb i werthoedd eithafol y metrig:
Yma, yn y sgrinlun gyda'r canlyniadau, byddaf yn egluro: rhoddir gwerthoedd y fector tiwnio yn nhermau'r cod swyddogaeth ffitrwydd, nid yn nhermau'r rhestr nifer o baramedrau / ystodau o werthoedd paramedr, a luniwyd uchod yn y testun.
Wel. Ai llawer neu ychydig, ~8 mil tps: cwestiwn ar wahân.
O fewn fframwaith gwaith labordy, nid yw'r ffigur hwn yn bwysig, yr hyn sy'n bwysig yw'r ddeinameg, sut mae'r gwerth hwn yn newid.
Mae'r ddeinameg yma yn dda.
Mae'n amlwg bod o leiaf un ffactor yn dylanwadu'n sylweddol ar werth y metrig, y ga-algorithm, gan ddidoli trwy'r fectorau cromosom: gorchuddio.
A barnu yn ôl deinameg eithaf egnïol gwerthoedd y gromlin, mae o leiaf un ffactor arall sydd, er ei fod yn sylweddol llai, yn dylanwadu.
Dyma lle mae ei angen arnoch chi attribute-importance dadansoddiad i ddeall pa briodoleddau (wel, yn yr achos hwn, cydrannau'r fector tiwnio) a faint maent yn dylanwadu ar y gwerth metrig.
Ac o'r wybodaeth hon: deall pa ffactorau yr effeithiwyd arnynt gan newidiadau mewn priodoleddau arwyddocaol.
Run attribute-importance bosibl mewn gwahanol ffyrdd.
At y dibenion hyn, rwy'n hoffi'r algorithm randomForest pecyn R o'r un enw ()
randomForest, gan fy mod yn deall ei waith yn gyffredinol a’i ddull o asesu pwysigrwydd priodoleddau yn benodol, yn adeiladu model penodol o ddibyniaeth y newidyn ymateb ar y priodoleddau.
Yn ein hachos ni, mae'r newidyn ymateb yn fetrig a geir o'r gronfa ddata mewn profion llwyth: tps;
Ac mae priodoleddau yn gydrannau o'r fector tiwnio.
Felly yma randomForest yn gwerthuso pwysigrwydd pob nodwedd enghreifftiol gyda dau rif: %IncMSE — sut mae presenoldeb/absenoldeb y nodwedd hon mewn model yn newid ansawdd MSE y model hwn (Gwall Sgwâr Cymedrig);
Ac mae IncNodePurity yn nifer sy'n adlewyrchu pa mor dda, yn seiliedig ar werthoedd y nodwedd hon, y gellir rhannu set ddata gydag arsylwadau, fel bod data mewn un rhan gydag un gwerth o'r metrig yn cael ei esbonio, ac yn y llall gyda gwerth arall y metrig.
Wel, hynny yw: i ba raddau y mae hon yn nodwedd ddosbarthu (gwelais yr esboniad mwyaf clir yn yr iaith Rwsieg ar RandomForest ).
Cod R gweithiwr-gwerinwr ar gyfer prosesu set ddata gyda chanlyniadau profion llwyth:
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$importanceGallwch ddewis hyperparamedrau'r algorithm yn uniongyrchol â'ch dwylo ac, gan ganolbwyntio ar ansawdd y model, dewis model sy'n cyflawni'r rhagfynegiadau ar y set ddata ddilysu yn fwy cywir.
Gallwch chi ysgrifennu rhyw fath o swyddogaeth ar gyfer y gwaith hwn (gyda llaw, eto, gan ddefnyddio rhyw fath o algorithm optimeiddio).
Gallwch ddefnyddio pecyn R caret, nid yw'r pwynt yn bwysig.
O ganlyniad, yn yr achos hwn, ceir y canlyniad canlynol i asesu graddau pwysigrwydd y nodweddion:
Wel. Felly, gallwn ddechrau myfyrio byd-eang:
- Mae'n ymddangos mai'r mwyaf arwyddocaol, o dan yr amodau profi hyn, oedd y paramedr
commit_wait
Yn dechnegol, mae’n pennu dull gweithredu’r ‘gweithrediad’ o ysgrifennu data ail-wneud o’r byffer log subdb i’r grŵp log cyfredol: cydamserol neu asyncronig.
Gwerthnowaitsy'n arwain at gynnydd lluosog bron yn fertigol yng ngwerth y metrig tps: dyma gynnwys y modd io asyncronig mewn grwpiau ail-wneud.
Cwestiwn ar wahân yw a ddylech chi wneud hyn mewn cronfa ddata bwyd ai peidio. Yma rwy'n cyfyngu fy hun i ddweud: mae hwn yn ffactor arwyddocaol. - Mae'n rhesymegol bod maint y byffer log y subd: troi allan i fod yn ffactor arwyddocaol.
Po leiaf yw maint y byffer boncyff, y lleiaf yw ei allu clustogi, y mwyaf aml y mae'n gorlifo a/neu'r anallu i ddyrannu ardal rydd ynddi ar gyfer cyfran o ddata rhydocs newydd.
Mae hyn yn golygu: oedi sy'n gysylltiedig â dyrannu lle yn y byffer boncyffion a/neu ddympio data ail-wneud ohono yn grwpiau ail-wneud.
Dylai'r oedi hwn, wrth gwrs, effeithio ar lif y gronfa ddata ar gyfer trafodion, ac fe fydd yn gwneud hynny. - Paramedr
db_block_checksum: wel, hefyd, yn gyffredinol mae'n amlwg - mae prosesu trafodion yn arwain at ffurfio blociau darty yn storfa glustogi'r is-gronfa ddata.
Sydd, wrth alluogi gwirio symiau blociau data, mae'n rhaid i'r gronfa ddata brosesu - cyfrifo'r gwiriadau hyn o gorff y bloc data, eu gwirio gyda'r hyn sydd wedi'i ysgrifennu ym mhennyn y bloc data: yn cyfateb / ddim yn cyfateb.
Unwaith eto, ni all gwaith o'r fath ond oedi prosesu data, ac yn unol â hynny, mae'r paramedr a'r mecanwaith sy'n gosod y paramedr hwn yn arwyddocaol.
Dyna pam mae'r gwerthwr yn cynnig, yn y ddogfennaeth ar gyfer y paramedr hwn, wahanol werthoedd ar ei gyfer (y paramedr) ac yn nodi y bydd effaith, ond, wel, gallwch ddewis gwahanol werthoedd, hyd at "off" a effeithiau gwahanol.
Wel, casgliad byd-eang.
Mae'r dull, yn gyffredinol, yn troi allan i fod yn eithaf gweithio.
Mae'n caniatáu iddo'i hun, yn ystod camau cynnar profi llwyth system wasanaeth benodol, er mwyn dewis ei (system) y cyfluniad gorau posibl ar gyfer y llwyth, i beidio ag ymchwilio'n ormodol i fanylion sefydlu'r system ar gyfer y llwyth.
Ond nid yw'n ei eithrio'n gyfan gwbl - o leiaf ar lefel y ddealltwriaeth: mae'n rhaid i'r system fod yn hysbys am y "boniau addasu" a'r ystodau a ganiateir o gylchdroi'r nobiau hyn.
Yna gall y dull ddod o hyd i'r cyfluniad system gorau posibl yn gymharol gyflym.
Ac yn seiliedig ar ganlyniadau'r profion, mae'n bosibl cael gwybodaeth am natur y berthynas rhwng metrigau perfformiad y system a gwerthoedd paramedrau gosodiadau'r system.
A ddylai, wrth gwrs, gyfrannu at ymddangosiad y ddealltwriaeth ddofn iawn hon o'r system, ei gweithrediad, o leiaf o dan lwyth penodol.
Yn ymarferol, mae hyn yn gyfnewidiad o gostau deall y system wedi'i haddasu ar gyfer costau paratoi profion o'r fath ar y system.
Hoffwn nodi ar wahân: yn y dull hwn, mae graddau digonolrwydd y profion system i’r amodau gweithredu a fydd ganddo mewn gweithrediad masnachol yn hollbwysig.
Diolch am eich sylw a'ch amser.
Ffynhonnell: hab.com