Hello.
Ik besleat om myn fynst te dielen - de frucht fan tinken, probearjen en flater.
By en grut: dit is gjin fynst, fansels - dit alles soe al lang bekend wêze moatte, oan dyjingen dy't belutsen binne by tapaste statistyske gegevensferwurking en optimisaasje fan alle systemen, net needsaaklik spesifyk de DBMS.
En: ja, se witte, se skriuwe nijsgjirrige artikels oer har ûndersyk, (UPD.: yn 'e opmerkingen wiisden se op in heul ynteressant projekt: )
Oan 'e oare kant: offhand ik sjoch gjin wiidferspraat fermelding of fersprieding fan dizze oanpak op it ynternet ûnder IT-spesjalisten, DBA.
Dus, nei it punt.
Lit ús oannimme dat wy in taak hawwe: in beskaat tsjinstsysteem ynstelle om in soarte fan wurk te tsjinjen.
Oer dit wurk is bekend: wat it is, hoe't de kwaliteit fan dit wurk metten wurdt en wat is it kritearium foar it mjitten fan dy kwaliteit.
Lit ús ek oannimme dat it min of mear bekend en begrepen is: krekt hoe't der yn (of mei) dit tsjinstsysteem wurke wurdt.
"Mear of minder" - dit betsjut dat it mooglik is om in bepaald ark, nutsbedriuw, tsjinst te tarieden (of earne te krijen) dat kin wurde synthesisearre en tapast op it systeem mei in testlading genôch genôch foar wat yn produksje sil wêze, ûnder betingsten dy't genôch genôch binne om yn produksje te wurkjen.
No, lit ús oannimme dat in set oanpassingsparameters foar dit tsjinstsysteem bekend is, dat kin wurde brûkt om dit systeem te konfigurearjen yn termen fan 'e produktiviteit fan har wurk.
En wat is it probleem - d'r is net in foldwaande folslein begryp fan dit tsjinstsysteem, ien wêrmei jo de ynstellings fan dit systeem saakkundich kinne konfigurearje foar takomstige lading op in bepaald platfoarm en de fereaske produktiviteit fan it systeem krije.
Goed. Dit is hast altyd it gefal.
Wat kinne jo hjir dwaan?
No, it earste ding dat yn 't sin komt is om te sjen nei de dokumintaasje foar dit systeem. Begryp wat de akseptabele berik binne foar de wearden fan 'e oanpassingsparameters. En selektearje bygelyks wearden foar systeemparameters yn tests mei help fan 'e metoade fan koördinaasje-ôfstamming.
Dy. jou it systeem in soarte fan konfiguraasje, yn 'e foarm fan in spesifike set wearden foar syn konfiguraasjeparameters.
Tapasse der in testlading op, mei dizze heul tool-utility, loadgenerator.
En sjoch nei de wearde - it antwurd, as in metrysk fan 'e kwaliteit fan it systeem.
De twadde gedachte kin de konklúzje wêze dat dit in heul lange tiid is.
No, dat is: as d'r in protte ynstelparameters binne, as de berikken fan har wearden dy't wurde útfierd grut binne, as elke yndividuele loadtest in protte tiid nimt om te foltôgjen, dan: ja, dit alles kin in unakseptabel nimme lange tiid.
No, hjir is wat jo kinne begripe en ûnthâlde.
Jo kinne útfine dat yn 'e set wearden fan parameters fan' e tsjinstsysteemynstellingen in fektor is, as in folchoarder fan guon wearden.
Elke sa'n fektor, as oare dingen lykweardich binne (yn dat it net wurdt beynfloede troch dizze fektor), komt oerien mei in folslein definitive wearde fan 'e metryske - in yndikator fan' e kwaliteit fan 'e wurking fan it systeem ûnder in testlading.
ie
Lit ús oantsjutte it systeem konfiguraasje vector as 
wêr ; Wêr - oantal systeemkonfiguraasjeparameters, hoefolle fan dizze parameters binne.
En de wearde fan 'e metrik dy't oerienkomt mei dit lit ús it oantsjutte as
, dan krije wy in funksje:
No, dan: alles komt yn myn gefal daliks del op: hast fergetten út myn studintetiid, algoritmen foar it sykjen nei it uterste fan in funksje.
Goed, mar hjir ûntstiet in organisatoaryske en tapaste fraach: hokker algoritme te brûken.
- Yn 'e sin - sadat jo minder mei de hân koade kinne.
- En om it te wurkjen, d.w.s. fûn it ekstremum (as d'r ien is), goed, op syn minst flugger as koördinearje ôfstamming.
It earste punt jout oan dat wy moatte sjen nei guon omjouwings dêr't sokke algoritmen binne al ymplemintearre, en binne, yn guon foarm, klear foar gebrûk yn koade.
No, ik wit it python и cran-r
It twadde punt betsjut dat jo moatte lêze oer de algoritmen sels, wat se binne, wat har easken binne, en de funksjes fan har wurk.
En wat se jouwe kinne nuttige side-effekten wêze - resultaten, of direkt fan it algoritme sels.
Of se kinne wurde krigen fan 'e resultaten fan it algoritme.
In soad hinget ôf fan de ynfier betingsten.
Bygelyks, as jo om ien of oare reden in resultaat rapper moatte krije, goed, jo moatte sjen nei algoritmen foar gradient-ôfstamming en ien fan har kieze.
Of, as de tiid net sa wichtich is, kinne jo bygelyks stochastyske optimisaasjemetoaden brûke, lykas in genetysk algoritme.
Ik stel foar om it wurk fan dizze oanpak te beskôgjen, de systeemkonfiguraasje te selektearjen, mei in genetysk algoritme, yn 'e folgjende, sa te sizzen: laboratoariumwurk.
Oarspronklik:
- Lit der wêze, as in tsjinstsysteem:
oracle xe 18c - Lit it transaksjeaktiviteiten tsjinje en it doel: de heechst mooglike trochstreaming fan 'e subdatabase te krijen, yn transaksjes / sek.
- Transaksjes kinne heul ferskillend wêze yn 'e aard fan wurkjen mei gegevens en de kontekst fan wurk.
Litte wy it iens wêze dat dit transaksjes binne dy't gjin grutte hoemannichte tabelgegevens ferwurkje.
Yn 'e sin dat se net mear undo-gegevens generearje as opnij meitsje en gjin grutte persintaazjes fan rigen en grutte tabellen ferwurkje.
Dit binne transaksjes dy't ien rige feroarje yn in min of mear grutte tabel, mei in lyts oantal yndeksen op dizze tabel.
Yn dizze situaasje: de produktiviteit fan 'e subdatabase foar it ferwurkjen fan transaksjes sil, mei in reservearring, bepaald wurde troch de kwaliteit fan ferwurking troch de redox-database.
Disclaimer - as wy spesifyk prate oer de subdb-ynstellingen.
Om't der yn it algemien gefal bygelyks transaksjeslûzen tusken SQL-sesjes kinne wêze, troch it ûntwerp fan brûkerswurk mei tabelgegevens en/of it tabelmodel.
Wat fansels in deprimearjend effekt sil hawwe op 'e TPS-metriek en dit sil in eksogene faktor wêze, relatyf oan de subdatabase: goed, dit is hoe't it tabelmodel ûntwurpen is en it wurk mei gegevens deryn dat blokkades foarkomme.
Dêrom, foar de suverens fan it eksperimint, sille wy dizze faktor útslute, en hjirûnder sil ik krekt dúdlik meitsje hoe.
- Lit ús foar definityfens oannimme dat 100% fan 'e SQL-kommando's dy't oan 'e databank binne yntsjinne DML-kommando's binne.
Lit de skaaimerken fan brûker wurkje mei de subdatabase itselde wêze yn tests.
Nammentlik: it oantal skl-sesjes, tabelgegevens, hoe't skl-sesjes dêrmei wurkje. - Subd wurket yn
FORCE LOGGING,ARCHIVELOGmods. Flashback-database-modus is útskeakele, op it subd-nivo. - Redo logs: leit yn in apart bestânsysteem, op in aparte "skiif";
De rest fan 'e fysike komponint fan' e databank: yn in oar, apart bestânsysteem, op in aparte "skiif":
Mear details oer it fysike apparaat. laboratoarium databank komponinten
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 0Yn it earstoan, ûnder dizze loadbetingsten, woe ik transaksje subd brûke
It hat sa'n prachtige funksje, ik sil de skriuwer sitearje:
Yn it hert fan SLOB is de "SLOB-metoade." De SLOB-metoade hat as doel om platfoarms te testen
sûnder tapassingskonflikt. Men kin net ride maksimale hardware prestaasjes
mei help fan applikaasje koade dat is, bygelyks, bûn troch applikaasje beskoatteljen of sels
dielen fan Oracle Database-blokken. Dat is krekt - d'r is overhead by it dielen fan gegevens
yn datablokken! Mar SLOB - yn syn standert ynset - is ymmún foar sa'n striid.
Dizze ferklearring: komt oerien, it is.
It is handich om de mjitte fan parallelisme fan cl-sesjes te regeljen, dit is de kaai -t start it nut runit.sh fan SLOB
It persintaazje DML-kommando's wurdt regele, yn it oantal tekstberjochten dat nei de subd stjoerd wurdt, elke tekstsesje, parameter UPDATE_PCT
Apart en hiel handich: SLOB sels, foar en nei de load sesje - taret in statspack, of awr-snapshots (wat is ynsteld om te wurde taret).
Dat die lykwols bliken SLOB stipet gjin SQL-sesjes mei in doer fan minder dan 30 sekonden.
Dêrom kodearre ik earst myn eigen, arbeider-boerferzje fan 'e loader, en doe bleau it yn wurking.
Lit my dúdlik meitsje wat de loader docht en hoe't it docht, foar dúdlikens.
Yn essinsje sjocht de loader der sa út:
Worker koade
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 dotxArbeiders wurde op dizze manier lansearre:
Running arbeiders
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"
waitEn tabellen foar arbeiders wurde sa taret:
It meitsjen fan tabellen
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"Dy. Foar elke arbeider (praktysk: in aparte SQL-sesje yn 'e DB) wurdt in aparte tabel makke, wêrmei't de arbeider wurket.
Dit soarget foar it ûntbrekken fan transaksjeslûzen tusken arbeiderssesjes.
Elke arbeider: docht itselde, mei syn eigen tafel, de tafels binne allegear itselde.
Alle arbeiders dogge wurk foar deselde tiid.
Boppedat, foar in lang genôch tiid sadat, bygelyks, in log switch soe definityf foarkomme, en mear as ien kear.
No, dêrtroch ûntstiene byhearrende kosten en effekten.
Yn myn gefal haw ik de doer fan it wurk fan 'e arbeiders ynsteld op 8 minuten.
In stik fan in statspackrapport dat de wurking fan 'e subd ûnder load beskriuwt
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.1Werom nei it laboratoarium wurk.
Wy sille, mei oare dingen lykweardich, de wearden fan 'e folgjende parameters fan' e laboratoariumsubdatabase feroarje:
- Grutte fan database log groepen. wearde berik: [32, 1024] MB;
- Oantal tydskriftgroepen yn 'e databank. wearde berik: [2,32];
log_archive_max_processeswearde berik: [1,8];commit_loggingtwa wearden binne tastien:batch|immediate;commit_waittwa wearden binne tastien:wait|nowait;log_bufferwearde berik: [2,128] MB.log_checkpoint_timeoutwearde berik: [60,1200] sekondendb_writer_processesweardeberik: [1,4]undo_retentionwearde berik: [30;300] sekondentransactions_per_rollback_segmentweardeberik: [1,8]disk_asynch_iotwa wearden binne tastien:true|false;filesystemio_optionsde folgjende wearden binne tastien:none|setall|directIO|asynch;db_block_checkingde folgjende wearden binne tastien:OFF|LOW|MEDIUM|FULL;db_block_checksumde folgjende wearden binne tastien:OFF|TYPICAL|FULL;
In persoan mei ûnderfining yn it ûnderhâlden fan Oracle-databases kin grif al sizze wat en op hokker wearden moatte wurde ynsteld, fan 'e oantsjutte parameters en har akseptabele wearden, om gruttere produktiviteit fan' e database te krijen foar it wurk mei gegevens dy't oanjûn binne troch de applikaasje koade, hjir boppe.
Mar.
It punt fan it laboratoariumwurk is om sjen te litten dat it optimisaasjealgoritme sels dit relatyf fluch foar ús dúdlik meitsje sil.
Foar ús bliuwt it allinich om it dokumint te besjen, fia it oanpasbere systeem, krekt genôch om út te finen hokker parameters te feroarjen en yn hokker berik.
En ek: koade de koade dy't sil wurde brûkt om te wurkjen mei it oanpaste systeem fan it selekteare optimisaasjealgoritme.
Dus, no oer de koade.
Ik hie it hjirboppe oer cran-r, d.w.s.: alle manipulaasjes mei it oanpaste systeem wurde orkestreare yn 'e foarm fan in R-skript.
De eigentlike taak, analyze, seleksje troch metryske wearde, systeem steat vectors: dit is in pakket GA ()
It pakket, yn dit gefal, is net hiel geskikt, yn 'e sin dat it ferwachtet dat vectoren (chromosomen, as yn termen fan it pakket) wurde spesifisearre yn' e foarm fan snaren fan nûmers mei in fraksjoneel diel.
En myn fektor, fan 'e wearden fan' e ynstellingsparameters: dit binne 14 kwantiteiten - heule getallen en stringwearden.
It probleem is fansels maklik te foarkommen troch guon spesifike nûmers ta te jaan oan stringwearden.
Sa, op it lêst, sjocht it haadstik fan it R-skript der sa út:
Skilje 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@solutionHjir, mei help lower и upper subroutine attributen ga yn essinsje is in gebiet fan 'e sykromte spesifisearre, wêryn in sykopdracht sil wurde útfierd foar sa'n fektor (as vectoren) wêrfoar de maksimale wearde fan 'e fitnessfunksje sil wurde krigen.
De ga subroutine fiert in sykaksje maksimalisearjen de fitness funksje.
No, dan docht bliken dat it yn dit gefal nedich is dat de fitnessfunksje, it begripen fan 'e fektor as in set wearden foar bepaalde parameters fan' e subd, in metrysk fan 'e subd krijt.
Dat is: hoefolle, mei in opjûne subd opset en in opjûne lading op de subd: de subd ferwurket transaksjes per sekonde.
Dat is, by it ûntbrekken moat de folgjende multi-stap wurde útfierd binnen de fitnessfunksje:
- It ferwurkjen fan de ynfierfektor fan sifers - it konvertearjen yn wearden foar de subdataparameters.
- In besykjen om in opjûn oantal redo-groepen fan in opjûne grutte te meitsjen. Boppedat kin it besykjen mislearre.
Tydskriftgroepen dy't al yn 'e subd bestienen, yn guon kwantiteit en fan wat grutte, foar de suverens fan it eksperimint - d.b. wiske. - As it foarige punt suksesfol is: it opjaan fan de wearden fan konfiguraasjeparameters oan 'e databank (wer: d'r kin in mislearring wêze)
- As de foarige stap suksesfol is: de subd stopje, de subd begjinne, sadat de nij opjûne parameterwearden effekt wurde. (wer: der kin in flater wêze)
- As de foarige stap is suksesfol: fier in load test. krije metriken fan subd.
- Werom de subd werom nei syn oarspronklike steat, d.w.s. wiskje ekstra log groepen, werom de oarspronklike subdatabase konfiguraasje om te wurkjen.
Fitness funksje koade
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)
}Dat. alle wurk: útfierd yn de fitness funksje.
De ga-subroutine ferwurket vectoren, of, krekter, chromosomen.
Yn hokker, wat is it wichtichste foar ús is de seleksje fan chromosomen mei genen dêr't de fitness funksje produsearret grutte wearden.
Dit, yn essinsje, is it proses fan it sykjen nei de optimale set chromosomen mei in fektor yn in N-diminsjonale sykromte.
Hiel dúdlik, detaillearre , mei foarbylden fan R-koade, it wurk fan in genetysk algoritme.
Ik wol apart twa technyske punten opmerke.
Auxiliary oproppen fan de funksje evaluate, Bygelyks, stop-start, it ynstellen fan de wearde fan de subd parameter, wurde útfierd basearre op cran-r funksjes system2
Mei help wêrfan: wat bash skript of kommando wurdt neamd.
Bygelyks:
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)
}
}It twadde punt is de line, evaluate funksjes, mei it bewarjen fan in spesifike metryske wearde en de oerienkommende tuningvektor yn in logtriem:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Dit is wichtich, om't fan dizze gegevensarray sil it mooglik wêze om ekstra ynformaasje te krijen oer hokker fan 'e komponinten fan' e tuningvektor in grutter of minder effekt hat op 'e metryske wearde.
Dat is: it sil mooglik wêze om attribút-ynportamce-analyze te fieren.
Dus wat kin barre?
Yn grafyske foarm, as jo de tests bestelle yn opkommende metryske folchoarder, is de ôfbylding as folget:
Guon gegevens dy't oerienkomme mei de ekstreme wearden fan 'e metrike:
Hjir, yn it skermôfbylding mei de resultaten, sil ik dúdlik meitsje: de wearden fan 'e tuningvektor wurde jûn yn termen fan' e fitnessfunksjekoade, net yn termen fan 'e nûmerlist fan parameters / berik fan parameterwearden, dy't formulearre is boppe yn 'e tekst.
Goed. Is it in protte of in bytsje, ~ 8 tûzen tps: in aparte fraach.
Yn it ramt fan laboratoariumwurk is dit figuer net wichtich, wat wichtich is is de dynamyk, hoe't dizze wearde feroaret.
De dynamyk hjir is goed.
It is fanselssprekkend dat op syn minst ien faktor signifikant beynfloedet de wearde fan 'e metrike, it ga-algoritme, sortearjen troch de chromosoomvectors: bedutsen.
Te oardieljen nei de frij krêftige dynamyk fan 'e kromwearden, is der op syn minst noch ien faktor dy't, hoewol signifikant lytser, in ynfloed hat.
Dit is wêr't jo it nedich hawwe attribute-importance analyze om te begripen hokker attributen (goed, yn dit gefal, komponinten fan 'e tuningvektor) en hoefolle se de metryske wearde beynfloedzje.
En út dizze ynformaasje: begripe hokker faktoaren waarden beynfloede troch feroarings yn wichtige attributen.
run attribute-importance op ferskate wizen mooglik.
Foar dizze doelen hâld ik fan it algoritme randomForest R pakket mei deselde namme ()
randomForest, lykas ik begryp syn wurk yn it algemien en syn oanpak foar it beoardieljen fan it belang fan attributen yn it bysûnder, bout in bepaald model fan de ôfhinklikens fan de antwurd fariabele op de attributen.
Yn ús gefal is de antwurdfariabele in metrik krigen fan 'e databank yn loadtests: tps;
En attributen binne ûnderdielen fan de tuning vector.
Hjir dus randomForest evaluearret it belang fan elk model attribút mei twa nûmers: %IncMSE - hoe't de oanwêzigens / ôfwêzigens fan dit attribút yn in model de MSE-kwaliteit fan dit model feroaret (Mean Squared Error);
En IncNodePurity is in nûmer dat wjerspegelet hoe goed, basearre op de wearden fan dit attribút, in dataset mei observaasjes kin wurde ferdield, sadat yn ien diel gegevens binne mei ien wearde fan 'e metrike dy't wurdt ferklearre, en yn 'e oare mei in oare wearde fan 'e metryske.
No, dat is: yn hoefier is dit in klassifisearjend attribút (ik seach de dúdlikste, Russysktalige útlis op RandomForest ).
Arbeider-boer R-koade foar it ferwurkjen fan in dataset mei de resultaten fan loadtests:
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$importanceJo kinne direkt de hyperparameters fan it algoritme selektearje mei jo hannen en, rjochte op 'e kwaliteit fan it model, selektearje in model dat krekter foldocht oan de foarsizzingen op' e falidaasjedataset.
Jo kinne in soarte fan funksje foar dit wurk skriuwe (troch de manier, wer, mei in soarte fan optimisaasjealgoritme).
Jo kinne R-pakket brûke caret, net it punt is wichtich.
As resultaat wurdt yn dit gefal it folgjende resultaat krigen om de graad fan belang fan 'e attributen te beoardieljen:
Goed. Sa kinne wy globale refleksje begjinne:
- It docht bliken dat de wichtichste, ûnder dizze testbetingsten, de parameter wie
commit_wait
Technysk spesifisearret it de útfieringsmodus fan 'e io-operaasje fan it skriuwen fan redo-gegevens fan' e subdb-logbuffer nei de hjoeddeistige loggroep: syngroan of asynchronous.
weardenowaitwat resulteart yn in hast fertikale, meardere ferheging fan 'e wearde fan' e tps-metryske: dit is it opnimmen fan 'e asynchrone io-modus yn redo-groepen.
In aparte fraach is oft jo dit dwaan moatte yn in itendatabase. Hjir behein ik my ta gewoan te sizzen: dit is in wichtige faktor. - It is logysk dat de grutte fan 'e logbuffer fan' e subd: in wichtige faktor blykt te wêzen.
Hoe lytser de grutte fan 'e logbuffer, hoe minder syn bufferkapasiteit, hoe faker it oerstreamt en / of it ûnfermogen om in frije gebiet dêryn te tawizen foar in diel fan nije redoxgegevens.
Dit betsjut: fertragingen dy't ferbûn binne mei it tawizen fan romte yn 'e logbuffer en / of it dumpen fan redo-gegevens derfan yn redo-groepen.
Dizze fertragingen, fansels, moatte en hawwe ynfloed op de trochfier fan 'e databank foar transaksjes. - Parameter
db_block_checksum: goed, ek, yn 't algemien is it dúdlik - transaksjeferwurking liedt ta de foarming fan darty-blokken yn' e buffercache fan 'e subdatabase.
Wat, as it kontrolearjen fan kontrôlesummen fan datablokken ynskeakele is, de databank moat ferwurkje - dizze kontrôlesummen berekkenje út it lichem fan it datablok, kontrolearje se mei wat skreaun is yn 'e datablokkoptekst: komt oerien / komt net oerien.
Sa'n wurk, wer, kin net oars as fertrage gegevens ferwurking, en dêrom, de parameter en it meganisme dat stelt dizze parameter bliken te wêzen wichtich.
Dêrom biedt de ferkeaper, yn 'e dokumintaasje foar dizze parameter, ferskate wearden foar it (de parameter) en merkt op dat ja, d'r sil ynfloed wêze, mar goed, jo kinne ferskate wearden kieze, oant "út" en ferskate effekten.
No, in globale konklúzje.
De oanpak, yn 't algemien, blykt frij te wurkjen.
Hy lit himsels, yn 'e iere stadia fan' e ladingstest fan in bepaald tsjinstsysteem, om syn (systeem) optimale konfiguraasje foar de lading te selektearjen, net te folle te ferdjipjen yn 'e spesifikaasjes fan it ynstellen fan it systeem foar de lading.
Mar it slút it net folslein út - teminsten op it nivo fan begryp: it systeem moat bekend wêze oer de "oanpassingsknoppen" en it tastiene berik fan rotaasje fan dizze knoppen.
De oanpak kin dan relatyf fluch de optimale systeemkonfiguraasje fine.
En basearre op de resultaten fan testen, is it mooglik om ynformaasje te krijen oer de aard fan 'e relaasje tusken de systeemprestaasjesmetriken en de wearden fan' e systeemynstellingsparameters.
Wat, fansels, moat bydrage oan it ûntstean fan dit tige djippe begryp fan it systeem, syn wurking, op syn minst ûnder in bepaalde lading.
Yn 'e praktyk is dit in útwikseling fan' e kosten foar it begripen fan it oanpaste systeem foar de kosten fan it tarieden fan sokke testen fan it systeem.
Ik wol apart opmerke: yn dizze oanpak is de mjitte fan adekwaatheid fan systeemtesten foar de bedriuwsbetingsten dy't it sil hawwe yn kommersjele operaasje kritysk wichtich.
Tankewol foar jo oandacht en tiid.
Boarne: www.habr.com