Hallo
Ek het besluit om my vonds te deel – die vrug van denke, beproewing en fout.
Oor die algemeen: dit is natuurlik nie 'n vonds nie - dit alles moes al lankal bekend gewees het aan diegene wat betrokke is by toegepaste statistiese dataverwerking en optimering van enige stelsels, nie noodwendig spesifiek die DBBS nie.
En: ja, hulle weet, hulle skryf interessante artikels oor hul navorsing, (UPD.: in die kommentaar het hulle 'n baie interessante projek uitgewys: )
Aan die ander kant: vanselfsprekend sien ek geen wydverspreide vermelding of verspreiding van hierdie benadering op die internet onder IT-spesialiste, DBA nie.
So, tot die punt.
Kom ons neem aan dat ons 'n taak het: om 'n sekere diensstelsel op te stel om 'n soort werk te bedien.
Dit is bekend oor hierdie werk: wat dit is, hoe die kwaliteit van hierdie werk gemeet word, en wat is die maatstaf om hierdie kwaliteit te meet.
Kom ons neem ook aan dat dit min of meer bekend en verstaan word: presies hoe werk in (of met) hierdie diensstelsel verrig word.
"Min of meer" - dit beteken dat dit moontlik is om 'n sekere instrument, nut, diens voor te berei (of dit van iewers af te kry) wat gesintetiseer kan word en op die stelsel toegepas kan word met 'n toetslading wat voldoende is vir wat in produksie sal wees, in toestande wat voldoende genoeg is om in produksie te werk.
Wel, kom ons neem aan dat 'n stel aanpassingsparameters vir hierdie diensstelsel bekend is, wat gebruik kan word om hierdie stelsel in terme van die produktiwiteit van sy werk op te stel.
En wat is die probleem - daar is nie 'n voldoende volledige begrip van hierdie diensstelsel nie, een wat jou toelaat om die instellings van hierdie stelsel kundig op te stel vir toekomstige lading op 'n gegewe platform en die vereiste produktiwiteit van die stelsel te kry.
Wel. Dit is byna altyd die geval.
Wat kan jy hier doen?
Wel, die eerste ding wat by jou opkom, is om na die dokumentasie vir hierdie stelsel te kyk. Verstaan wat die aanvaarbare reekse is vir die waardes van die aanpassingsparameters. En, byvoorbeeld, met behulp van die koördinaat-afkomsmetode, kies waardes vir stelselparameters in toetse.
Dié. gee die stelsel 'n soort konfigurasie, in die vorm van 'n spesifieke stel waardes vir sy konfigurasieparameters.
Pas 'n toetslading daarop toe met behulp van hierdie baie gereedskap-hulpmiddel, lasgenerator.
En kyk na die waarde - die reaksie, of 'n maatstaf van die kwaliteit van die stelsel.
Die tweede gedagte kan die gevolgtrekking wees dat dit 'n baie lang tyd is.
Wel, dit wil sê: as daar baie instelparameters is, as die reekse van hul waardes wat gedek word groot is, as elke individuele vragtoets baie tyd neem om te voltooi, dan: ja, dit kan alles onaanvaarbaar lank neem tyd.
Wel, hier is wat jy kan verstaan en onthou.
U kan uitvind dat daar in die stel waardes van die diensstelselinstellingsparameters 'n vektor is, as 'n volgorde van sommige waardes.
Elke so 'n vektor, terwyl ander dinge gelyk is (in die feit dat dit nie deur hierdie vektor geraak word nie), stem ooreen met 'n heeltemal definitiewe waarde van die metrieke - 'n aanduiding van die kwaliteit van die stelsel se werking onder 'n toetslading.
Dws
Kom ons dui die stelselkonfigurasievektor aan as 
Waar ; Waar — aantal stelselkonfigurasieparameters, hoeveel van hierdie parameters daar is.
En die waarde van die metrieke wat hiermee ooreenstem kom ons dui dit aan as
, dan kry ons 'n funksie:
Wel, dan: alles kom dadelik neer op, in my geval: amper vergete uit my studentedae, algoritmes om na die uiterste van 'n funksie te soek.
Goed, maar hier ontstaan 'n organisatoriese en toegepaste vraag: watter algoritme om te gebruik.
- In die sin – sodat jy minder met die hand kan kodeer.
- En vir dit om te werk, m.a.w. het die ekstremum gevind (as daar een is), wel, ten minste vinniger as koördinaatafkoms.
Die eerste punt dui daarop dat ons moet kyk na sommige omgewings waarin sulke algoritmes reeds geïmplementeer is, en in een of ander vorm gereed is vir gebruik in kode.
Wel, ek weet python и cran-r
Die tweede punt beteken dat jy moet lees oor die algoritmes self, wat hulle is, wat hul vereistes is en die kenmerke van hul werk.
En wat hulle gee, kan nuttige newe-effekte wees - resultate, of direk van die algoritme self.
Of hulle kan verkry word uit die resultate van die algoritme.
Baie hang af van die insettoestande.
Byvoorbeeld, as jy om een of ander rede 'n resultaat vinniger moet kry, wel, moet jy na gradiënt-afkomsalgoritmes kyk en een van hulle kies.
Of, as tyd nie so belangrik is nie, kan jy byvoorbeeld stogastiese optimeringsmetodes, soos 'n genetiese algoritme, gebruik.
Ek stel voor om die werk van hierdie benadering te oorweeg, die keuse van die stelselkonfigurasie, met behulp van 'n genetiese algoritme, in die volgende, so te sê: laboratoriumwerk.
Oorspronklik:
- Laat daar as 'n diensstelsel wees:
oracle xe 18c - Laat dit dien transaksionele aktiwiteit en die doel: om die hoogste moontlike deurset van die subdatabasis te verkry, in transaksies/sek.
- Transaksies kan baie verskil in die aard van werk met data en die konteks van werk.
Kom ons stem saam dat dit transaksies is wat nie 'n groot hoeveelheid tabeldata verwerk nie.
In die sin dat hulle nie meer ongedaan-data genereer as oordoen nie en nie groot persentasies rye en groot tabelle verwerk nie.
Dit is transaksies wat een ry in 'n min of meer groot tabel verander, met 'n klein aantal indekse op hierdie tabel.
In hierdie situasie: die produktiwiteit van die subdatabasis vir die verwerking van transaksies sal, met 'n voorbehoud, bepaal word deur die kwaliteit van verwerking deur die redoksdatabasis.
Disclaimer - as ons spesifiek oor die subdb-instellings praat.
Omdat daar in die algemene geval byvoorbeeld transaksionele slotte tussen SQL-sessies kan wees, as gevolg van die ontwerp van gebruikerswerk met tabeldata en/of die tabelmodel.
Wat natuurlik 'n neerdrukkende effek op die TPS-metriek sal hê en dit sal 'n eksogene faktor wees, relatief tot die subdatabasis: wel, dit is hoe die tabelmodel ontwerp is en die werk met data daarin dat blokkasies voorkom.
Daarom, vir die suiwerheid van die eksperiment, sal ons hierdie faktor uitsluit, en hieronder sal ek presies verduidelik hoe.
- Kom ons aanvaar, vir seker, dat 100% van die SQL-opdragte wat aan die databasis gestuur word, DML-opdragte is.
Laat die kenmerke van gebruikerswerk met die subdatabasis dieselfde wees in toetse.
Naamlik: die aantal skl-sessies, tabeldata, hoe skl-sessies daarmee werk. - Subd werk in
FORCE LOGGING,ARCHIVELOGmods. Terugflits-databasismodus is afgeskakel, op die subd-vlak. - Herdoen logs: geleë in 'n aparte lêerstelsel, op 'n aparte "skyf";
Die res van die fisiese komponent van die databasis: in 'n ander, aparte lêerstelsel, op 'n aparte "skyf":
Meer besonderhede oor die fisiese toestel. laboratorium databasis komponente
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 0Aanvanklik, onder hierdie lastoestande, wou ek transaksie subd gebruik
Dit het so 'n wonderlike kenmerk, ek sal die skrywer aanhaal:
Die kern van SLOB is die "SLOB-metode." Die SLOB-metode het ten doel om platforms te toets
sonder aansoek betwisting. Mens kan nie maksimum hardeware werkverrigting bestuur nie
gebruik toepassingskode wat byvoorbeeld gebind word deur toepassingssluiting of selfs
deel van Oracle-databasisblokke. Dit is reg—daar is bokoste wanneer data gedeel word
in datablokke! Maar SLOB - in sy standaardontplooiing - is immuun teen sulke twis.
Hierdie verklaring: stem ooreen, dit is.
Dit is gerieflik om die mate van parallelisme van cl-sessies te reguleer, dit is die sleutel -t begin die hulpprogram runit.sh van SLOB
Die persentasie DML-opdragte word gereguleer in die aantal teksboodskappe wat na die subd gestuur word, elke tekssessie, parameter UPDATE_PCT
Afsonderlik en baie gerieflik: SLOB self, voor en na die laaisessie - berei 'n statspack voor, of awr-kiekies (wat gereed is om voorberei te word).
Dit het egter geblyk dat SLOB ondersteun nie SQL-sessies met 'n duur van minder as 30 sekondes nie.
Daarom het ek eers my eie, arbeider-boer-weergawe van die laaier gekodeer, en toe het dit in werking gebly.
Kom ek verduidelik wat die laaier doen en hoe dit dit doen, vir duidelikheid.
In wese lyk die laaier so:
Werker kode
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 dotxWerkers word op hierdie manier van stapel gestuur:
Lopende werkers
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 tafels vir werkers word so voorberei:
Die skep van tabelle
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"Dié. Vir elke werker (prakties: 'n aparte SQL-sessie in die DB) word 'n aparte tabel geskep, waarmee die werker werk.
Dit verseker die afwesigheid van transaksionele slotte tussen werkersessies.
Elke werker: doen dieselfde ding, met sy eie tafel is die tafels almal dieselfde.
Alle werkers verrig werk vir dieselfde tyd.
Verder, vir 'n lang genoeg tyd sodat, byvoorbeeld, 'n logskakelaar beslis sou plaasvind, en meer as een keer.
Wel, dienooreenkomstig het gepaardgaande koste en gevolge ontstaan.
In my geval het ek die tydsduur van die werkers se werk op 8 minute gekonfigureer.
'n Stukkie van 'n statspack-verslag wat die werking van die subd onder lading beskryf
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.1Keer terug na die laboratoriumwerk.
Ons sal, andersins gelyk, die waardes van die volgende parameters van die laboratoriumsubdatabasis verander:
- Grootte van databasisloggroepe. waardereeks: [32, 1024] MB;
- Aantal joernaalgroepe in die databasis. waardereeks: [2,32];
log_archive_max_processeswaardereeks: [1,8];commit_loggingtwee waardes word toegelaat:batch|immediate;commit_waittwee waardes word toegelaat:wait|nowait;log_bufferwaardereeks: [2,128] MB.log_checkpoint_timeoutwaardereeks: [60,1200] sekondesdb_writer_processeswaardereeks: [1,4]undo_retentionwaardereeks: [30;300] sekondestransactions_per_rollback_segmentwaardereeks: [1,8]disk_asynch_iotwee waardes word toegelaat:true|false;filesystemio_optionsdie volgende waardes word toegelaat:none|setall|directIO|asynch;db_block_checkingdie volgende waardes word toegelaat:OFF|LOW|MEDIUM|FULL;db_block_checksumdie volgende waardes word toegelaat:OFF|TYPICAL|FULL;
'n Persoon met ervaring in die instandhouding van Oracle-databasisse kan beslis reeds sê wat en tot watter waardes gestel moet word, uit die gespesifiseerde parameters en hul aanvaarbare waardes, om groter produktiwiteit van die databasis te verkry vir die werk met data wat aangedui word deur die toepassingskode, hier bo.
Maar.
Die punt van die laboratoriumwerk is om te wys dat die optimeringsalgoritme self dit relatief vinnig vir ons sal opklaar.
Vir ons is al wat oorbly om deur die aanpasbare stelsel na die dokument te kyk, net genoeg om uit te vind watter parameters om te verander en in watter reekse.
En ook: kodeer die kode wat gebruik sal word om met die pasgemaakte stelsel van die geselekteerde optimaliseringsalgoritme te werk.
So, nou oor die kode.
Ek het hierbo gepraat oor cran-r, dit wil sê: alle manipulasies met die pasgemaakte stelsel word in die vorm van 'n R-skrif georkestreer.
Die werklike taak, analise, seleksie volgens metrieke waarde, stelseltoestandvektore: dit is 'n pakket GA ()
Die pakket, in hierdie geval, is nie baie geskik nie, in die sin dat dit verwag dat vektore (chromosome, indien in terme van die pakket) gespesifiseer moet word in die vorm van stringe getalle met 'n breukdeel.
En my vektor, van die waardes van die instellingsparameters: dit is 14 hoeveelhede - heelgetalle en stringwaardes.
Die probleem word natuurlik maklik vermy deur 'n paar spesifieke nommers aan stringwaardes toe te ken.
Dus, op die ou end lyk die hoofstuk van die R-skrif so:
Bel 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@solutionHier, met die hulp lower и upper subroetine eienskappe ga in wese word 'n area van die soekruimte gespesifiseer, waarbinne 'n soektog uitgevoer sal word vir so 'n vektor (of vektore) waarvoor die maksimum waarde van die fiksheidsfunksie verkry sal word.
Die ga-subroetine voer 'n soektog uit wat die fiksheidsfunksie maksimeer.
Wel, dan blyk dit dat dit in hierdie geval nodig is dat die fiksheidsfunksie, wat die vektor verstaan as 'n stel waardes vir sekere parameters van die subd, 'n metrieke van die subd ontvang.
Dit is: hoeveel, met 'n gegewe subd-opstelling en 'n gegewe las op die subd: die subd verwerk transaksies per sekonde.
Dit wil sê, wanneer dit ontvou, moet die volgende multi-stap binne die fiksheidsfunksie uitgevoer word:
- Verwerking van die invoervektor van getalle - omskep dit in waardes vir die subdataparameters.
- 'n Poging om 'n gegewe aantal oordoen groepe van 'n gegewe grootte te skep. Boonop kan die poging onsuksesvol wees.
Tydskrifgroepe wat reeds in die subd bestaan het, in een of ander hoeveelheid en van een of ander grootte, vir die suiwerheid van die eksperiment - d.b. geskrap. - As die vorige punt suksesvol is: spesifiseer die waardes van konfigurasieparameters aan die databasis (weereens: daar kan 'n mislukking wees)
- As die vorige stap suksesvol is: stop die subd, begin die subd sodat die nuut gespesifiseerde parameterwaardes in werking tree. (weereens: daar kan 'n fout wees)
- As die vorige stap suksesvol is: voer 'n lastoets uit. kry statistieke van subd.
- Stel die subd terug na sy oorspronklike toestand, d.w.s. verwyder addisionele loggroepe, laat die oorspronklike subdatabasiskonfigurasie terug werk.
Fiksheidsfunksie kode
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)
}Daardie. alle werk: uitgevoer in die fiksheidsfunksie.
Die ga-subroetine verwerk vektore, of, meer korrek, chromosome.
Waarin, wat vir ons die belangrikste is, is die keuse van chromosome met gene waarvoor die fiksheidsfunksie groot waardes produseer.
Dit is in wese die proses om na die optimale stel chromosome te soek deur 'n vektor in 'n N-dimensionele soekruimte te gebruik.
Baie duidelik, gedetailleerd , met voorbeelde van R-kode, die werk van 'n genetiese algoritme.
Ek wil afsonderlik op twee tegniese punte let.
Hulpoproepe vanaf die funksie evaluate, byvoorbeeld, stop-begin, wat die waarde van die subd parameter stel, word uitgevoer op grond van cran-r funksies system2
Met die hulp waarvan: een of ander bash script of bevel genoem word.
Byvoorbeeld:
stel_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)
}
}Die tweede punt is die lyn, evaluate funksies, met die stoor van 'n spesifieke metrieke waarde en die ooreenstemmende tuning vektor na 'n log lêer:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Dit is belangrik, want uit hierdie dataskikking sal dit moontlik wees om bykomende inligting te verkry oor watter van die komponente van die instemmingsvektor 'n groter of mindere effek op die metrieke waarde het.
Dit wil sê: dit sal moontlik wees om kenmerk-belangrikheid-analise uit te voer.
So wat kan gebeur?
In grafiekvorm, as jy die toetse in stygende metrieke volgorde bestel, is die prentjie soos volg:
Sommige data wat ooreenstem met die uiterste waardes van die metrieke:
Hier, in die skermkiekie met die resultate, sal ek verduidelik: die waardes van die tuning vektor word gegee in terme van die fiksheid funksie kode, nie in terme van die getal lys van parameters / reekse van parameter waardes, wat geformuleer is hierbo in die teks.
Wel. Is dit baie of 'n bietjie, ~8 duisend tps: 'n aparte vraag.
Binne die raamwerk van laboratoriumwerk is hierdie syfer nie belangrik nie, wat belangrik is, is die dinamika, hoe hierdie waarde verander.
Die dinamika hier is goed.
Dit is voor die hand liggend dat ten minste een faktor die waarde van die metriek, die ga-algoritme, wat deur die chromosoomvektore sorteer, aansienlik beïnvloed: bedek.
Te oordeel aan die taamlik kragtige dinamika van die krommewaardes, is daar ten minste nog een faktor wat, hoewel aansienlik kleiner, 'n invloed het.
Dit is waar jy dit nodig het attribute-importance analise om te verstaan watter eienskappe (wel, in hierdie geval, komponente van die instemmingsvektor) en hoeveel hulle die metrieke waarde beïnvloed.
En uit hierdie inligting: verstaan watter faktore geraak is deur veranderinge in beduidende eienskappe.
Voer uit attribute-importance op verskillende maniere moontlik.
Vir hierdie doeleindes hou ek van die algoritme randomForest R pakket met dieselfde naam ()
randomForest, soos ek sy werk in die algemeen verstaan en sy benadering tot die beoordeling van die belangrikheid van eienskappe in die besonder, bou 'n sekere model van die afhanklikheid van die responsveranderlike op die eienskappe.
In ons geval is die responsveranderlike 'n maatstaf wat uit die databasis in lastoetse verkry word: tps;
En eienskappe is komponente van die instemmingsvektor.
En so randomForest evalueer die belangrikheid van elke modelkenmerk met twee nommers: %IncMSE — hoe die teenwoordigheid/afwesigheid van hierdie eienskap in 'n model die MSE-kwaliteit van hierdie model verander (Mean Squared Error);
En IncNodePurity is 'n getal wat weerspieël hoe goed, gebaseer op die waardes van hierdie kenmerk, 'n datastel met waarnemings verdeel kan word, sodat daar in een deel data is met een waarde van die metrieke wat verduidelik word, en in die ander met 'n ander waarde van die metriek.
Wel, dit is: tot watter mate is dit 'n klassifiserende eienskap (ek het die duidelikste, Russies-talige verduideliking op RandomForest gesien ).
Werker-boer R-kode vir die verwerking van 'n datastel met die resultate van lastoetse:
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$importanceU kan die hiperparameters van die algoritme direk met u hande kies en, met die fokus op die kwaliteit van die model, 'n model kies wat meer akkuraat aan die voorspellings op die valideringsdatastel voldoen.
Jy kan 'n soort funksie vir hierdie werk skryf (terloops, weereens, deur 'n soort optimeringsalgoritme te gebruik).
Jy kan R-pakket gebruik caret, nie die punt is belangrik nie.
As gevolg hiervan, in hierdie geval, word die volgende resultaat verkry om die mate van belangrikheid van die eienskappe te bepaal:
Wel. So kan ons globale refleksie begin:
- Dit blyk dat die belangrikste, onder hierdie toetstoestande, die parameter was
commit_wait
Tegnies spesifiseer dit die uitvoeringsmodus van die io-bewerking vir die skryf van oordoendata vanaf die subdb-logbuffer na die huidige loggroep: sinchrone of asynchrone.
Waardenowaitwat 'n byna vertikale, veelvuldige toename in die waarde van die tps-metriek tot gevolg het: dit is die insluiting van die asynchrone io-modus in oordoen-groepe.
'n Aparte vraag is of jy dit in 'n voedseldatabasis moet doen of nie. Hier beperk ek my tot net om te sê: dit is 'n beduidende faktor. - Dit is logies dat die grootte van die logbuffer van die subd: 'n beduidende faktor blyk te wees.
Hoe kleiner die grootte van die logbuffer, hoe minder is die bufferkapasiteit daarvan, hoe meer dikwels loop dit oor en/of die onvermoë om 'n vrye area daarin toe te ken vir 'n gedeelte van nuwe redoksdata.
Dit beteken: vertragings wat verband hou met die toekenning van spasie in die logbuffer en/of die storting van oordoen data daaruit in oordoen groepe.
Hierdie vertragings moet en moet natuurlik die deurset van die databasis vir transaksies beïnvloed. - Parameter
db_block_checksum: wel, ook, in die algemeen is dit duidelik - transaksieverwerking lei tot die vorming van darty-blokke in die subdatabasisbufferkas.
Wat, wanneer kontrolering van kontrolesomme van datablokke geaktiveer is, die databasis moet verwerk - bereken hierdie kontrolesomme uit die liggaam van die datablok, kontroleer dit met wat in die datablokopskrif geskryf is: pas/pas nie.
Sulke werk kan weereens nie anders as om dataverwerking te vertraag nie, en dienooreenkomstig blyk die parameter en die meganisme wat hierdie parameter stel betekenisvol te wees.
Daarom bied die verkoper, in die dokumentasie vir hierdie parameter, verskillende waardes daarvoor (die parameter) en merk op dat ja, daar sal 'n impak wees, maar wel, jy kan verskillende waardes kies, tot "af" en verskillende impakte.
Wel, 'n globale gevolgtrekking.
Die benadering blyk oor die algemeen nogal te werk.
Hy laat homself nogal toe, in die vroeë stadiums van vragtoetsing van 'n sekere diensstelsel, om sy (stelsel) optimale konfigurasie vir die vrag te kies, om nie te veel in die besonderhede van die opstel van die stelsel vir die vrag te delf nie.
Maar dit sluit dit nie heeltemal uit nie - ten minste op die vlak van begrip: die stelsel moet bekend wees oor die "verstellingsknoppies" en die toelaatbare rotasiegebiede van hierdie knoppies.
Die benadering kan dan relatief vinnig die optimale stelselkonfigurasie vind.
En op grond van die resultate van toetsing, is dit moontlik om inligting te bekom oor die aard van die verhouding tussen die stelselprestasiemaatstawwe en die waardes van die stelselinstellingsparameters.
Wat natuurlik moet bydra tot die ontstaan van hierdie baie diep begrip van die stelsel, sy werking, ten minste onder 'n gegewe las.
In die praktyk is dit 'n uitruil van die koste om die pasgemaakte stelsel te verstaan vir die koste van die voorbereiding van sodanige toetsing van die stelsel.
Ek wil afsonderlik opmerk: in hierdie benadering is die graad van toereikendheid van stelseltoetsing vir die bedryfstoestande wat dit in kommersiële bedryf sal hê, krities belangrik.
Dankie vir jou aandag en tyd.
Bron: will.com