Pozdravljeni
Odločil sem se, da delim svoje odkritje - plod razmišljanja, poskusov in napak.
Na splošno: to seveda ni najdba - vse to bi moralo biti že dolgo znano tistim, ki se ukvarjajo z uporabno statistično obdelavo podatkov in optimizacijo katerega koli sistema, ne nujno posebej DBMS.
In: ja, vedo, pišejo zanimive članke o svojih raziskavah, (UPD.: v komentarjih so izpostavili zelo zanimiv projekt: )
Po drugi strani pa: na prvi pogled ne vidim nobene razširjene omembe ali širjenja tega pristopa na internetu med IT strokovnjaki, DBA.
Torej, k bistvu.
Predpostavimo, da imamo nalogo: vzpostaviti določen servisni sistem za servisiranje neke vrste dela.
Za to delo se ve: kaj je, kako se meri kakovost tega dela in kaj je merilo za merjenje te kakovosti.
Predpostavimo tudi, da je bolj ali manj znano in razumljeno: kako natančno poteka delo v (ali z) tem servisnim sistemom.
"Bolj ali manj" - to pomeni, da je mogoče pripraviti (ali dobiti od nekje) določeno orodje, pripomoček, storitev, ki jo je mogoče sintetizirati in uporabiti v sistemu s testno obremenitvijo, ki je dovolj ustrezna temu, kar bo v proizvodnje, v razmerah, ki so dovolj primerne za delo v proizvodnji.
No, predpostavimo, da je nabor prilagoditvenih parametrov za ta storitveni sistem znan, s katerimi lahko konfiguriramo ta sistem glede na produktivnost njegovega dela.
In v čem je težava - ni dovolj popolnega razumevanja tega storitvenega sistema, ki bi vam omogočilo strokovno konfiguracijo nastavitev tega sistema za prihodnjo obremenitev na določeni platformi in doseganje zahtevane produktivnosti sistema.
No. To je skoraj vedno tako.
Kaj lahko počnete tukaj?
No, prva stvar, ki pride na misel, je, da pogledamo dokumentacijo za ta sistem. Razumeti, kateri so sprejemljivi razponi za vrednosti parametrov prilagajanja. In na primer z metodo koordinatnega spusta izberite vrednosti za sistemske parametre v testih.
Tisti. dajte sistemu neke vrste konfiguracijo v obliki določenega nabora vrednosti za njegove konfiguracijske parametre.
Uporabite testno obremenitev z uporabo prav tega orodja-pripomočka, generatorja obremenitve.
In poglejte vrednost - odziv ali metriko kakovosti sistema.
Druga misel je lahko sklep, da je to zelo dolga doba.
No, to je: če je parametrov za nastavitev veliko, če so razponi njihovih vrednosti, ki se izvajajo, veliki, če vsak posamezen test obremenitve vzame veliko časa za izvedbo, potem: da, vse to lahko traja nesprejemljivo dolgo časa.
No, tukaj je tisto, kar lahko razumete in si zapomnite.
Ugotovite lahko, da v nizu vrednosti parametrov nastavitev storitvenega sistema obstaja vektor kot zaporedje nekaterih vrednosti.
Vsak tak vektor, pri drugih enakih pogojih (v tem, da ta vektor nanj ne vpliva), ustreza popolnoma določeni vrednosti metrike - indikatorja kakovosti delovanja sistema pod preskusno obremenitvijo.
Ie
Vektor sistemske konfiguracije označimo kot 
Če ; Kje — število parametrov konfiguracije sistema, koliko teh parametrov obstaja.
In vrednost metrike, ki temu ustreza označimo kot
, potem dobimo funkcijo:
No, potem pa: vse se takoj skrči na, v mojem primeru: iz študentskih dni skoraj pozabljene algoritme za iskanje ekstrema funkcije.
V redu, ampak tukaj se pojavi organizacijsko in aplikativno vprašanje: kateri algoritem uporabiti.
- V smislu - da lahko manj kodirate ročno.
- In da deluje, tj. našel ekstrem (če obstaja), no, vsaj hitreje kot koordinatni spust.
Prva točka namiguje, da se moramo ozreti proti nekaterim okoljem, v katerih so takšni algoritmi že implementirani in so v neki obliki pripravljeni za uporabo v kodi.
No, vem python и cran-r
Druga točka pomeni, da morate prebrati o samih algoritmih, kaj so, kakšne so njihove zahteve in značilnosti njihovega dela.
In kar dajejo, so lahko koristni stranski učinki – rezultati ali neposredno iz samega algoritma.
Lahko pa jih pridobimo iz rezultatov algoritma.
Veliko je odvisno od pogojev vnosa.
Na primer, če morate iz nekega razloga hitreje doseči rezultat, se morate ozreti proti algoritmom gradientnega spuščanja in izbrati enega od njih.
Ali pa, če čas ni tako pomemben, lahko na primer uporabite metode stohastične optimizacije, kot je genetski algoritem.
Predlagam, da razmislimo o delu tega pristopa, izbiri konfiguracije sistema z uporabo genetskega algoritma, v naslednjem, tako rekoč: laboratorijskem delu.
Original:
- Naj bo kot servisni sistem:
oracle xe 18c - Naj služi transakcijski dejavnosti in cilju: doseči najvišjo možno prepustnost podbaze podatkov v transakcijah/s.
- Transakcije so lahko zelo različne glede na naravo dela s podatki in kontekst dela.
Strinjajmo se, da so to transakcije, ki ne obdelujejo velike količine tabelaričnih podatkov.
V smislu, da ne ustvarijo več podatkov za razveljavitev kot za ponovitev in ne obdelujejo velikih odstotkov vrstic in velikih tabel.
To so transakcije, ki spremenijo eno vrstico v bolj ali manj veliki tabeli z majhnim številom indeksov v tej tabeli.
V tej situaciji: produktivnost podbaze podatkov za obdelavo transakcij bo s pridržkom določena s kakovostjo obdelave baze podatkov redoks.
Izjava o omejitvi odgovornosti - če govorimo posebej o nastavitvah subdb.
Ker v splošnem primeru lahko pride na primer do transakcijskih zaklepov med sejami SQL zaradi zasnove uporabniškega dela s tabelarnimi podatki in/ali tabelarnim modelom.
Kar bo seveda imelo depresiven učinek na metriko TPS in to bo eksogeni dejavnik glede na podbazo podatkov: no, tako je bil zasnovan tabelarni model in delo s podatki v njem, da prihaja do blokad.
Zato bomo zaradi čistosti eksperimenta ta dejavnik izključili, spodaj pa bom natančno pojasnil, kako.
- Za določnost predpostavimo, da je 100 % ukazov SQL, poslanih v bazo podatkov, ukazov DML.
Naj bodo enake lastnosti dela uporabnika s podbazo pri testih.
In sicer: število skl sej, tabelarni podatki, kako skl seje delujejo z njimi. - Subd deluje v
FORCE LOGGING,ARCHIVELOGmods. Način Flashback-baze podatkov je izklopljen na ravni subd. - Redo dnevniki: nahajajo se v ločenem datotečnem sistemu, na ločenem "disku";
Preostali del fizične komponente baze podatkov: v drugem, ločenem datotečnem sistemu, na ločenem “disku”:
Več podrobnosti o fizični napravi. komponente laboratorijske zbirke podatkov
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 0Sprva sem pod temi pogoji obremenitve želel uporabiti transakcijski subd
Ima tako čudovito lastnost, da bom citiral avtorja:
V središču SLOB je "metoda SLOB." Metoda SLOB je namenjena testiranju platform
brez spora v aplikaciji. Ne moremo doseči največje zmogljivosti strojne opreme
z uporabo kode aplikacije, ki je na primer vezana z zaklepanjem aplikacije ali celo
deljenje blokov Oracle Database. Tako je – pri skupni rabi podatkov nastanejo režijski stroški
v podatkovnih blokih! Toda SLOB – v svoji privzeti umestitvi – je imun na takšne spore.
Ta izjava: ustreza, je.
Primerno je regulirati stopnjo vzporednosti sej cl, to je ključ -t zaženite pripomoček runit.sh od SLOB
Odstotek ukazov DML je reguliran v številu besedilnih sporočil, ki so poslana v subd, vsaki besedilni seji, parametru UPDATE_PCT
Ločeno in zelo priročno: SLOB sam, pred in po seji nalaganja - pripravi statspack ali awr-snapshots (kar je nastavljeno za pripravo).
Vendar se je izkazalo, da SLOB ne podpira sej SQL, krajših od 30 sekund.
Zato sem najprej kodiral svojo, delavsko-kmečko različico nakladalke, potem pa je ostala v pogonu.
Naj pojasnim, kaj nakladalnik počne in kako to počne, zaradi jasnosti.
Nalagalnik v bistvu izgleda takole:
Šifra delavca
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 dotxDelavci se zaženejo na ta način:
Tekaški delavci
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"
waitIn mize za delavce so pripravljene takole:
Izdelava tabel
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"Tisti. Za vsakega delavca (praktično: ločena SQL seja v DB) se ustvari posebna tabela, s katero delavec dela.
To zagotavlja odsotnost transakcijskih zaklepanja med delavskimi sejami.
Vsak delavec: dela isto, s svojo mizo, mize so vse enake.
Vsi delavci opravljajo delo enako dolgo.
Še več, dovolj dolgo, da bi na primer zagotovo prišlo do preklopa dnevnika, in to večkrat.
No, temu primerno so nastali povezani stroški in učinki.
V mojem primeru sem konfiguriral trajanje dela delavcev na 8 minut.
Del poročila statspack, ki opisuje delovanje subd pod obremenitvijo
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.1Vrnitev k laboratorijskemu delu.
Ob enakih drugih pogojih bomo spreminjali vrednosti naslednjih parametrov laboratorijske podbaze podatkov:
- Velikost skupin dnevnikov baze podatkov. obseg vrednosti: [32, 1024] MB;
- Število skupin revij v bazi. obseg vrednosti: [2,32];
log_archive_max_processesobmočje vrednosti: [1,8];commit_loggingdovoljeni sta dve vrednosti:batch|immediate;commit_waitdovoljeni sta dve vrednosti:wait|nowait;log_bufferobseg vrednosti: [2,128] MB.log_checkpoint_timeoutobseg vrednosti: [60,1200] sekunddb_writer_processesobseg vrednosti: [1,4]undo_retentionobseg vrednosti: [30;300] sekundtransactions_per_rollback_segmentobseg vrednosti: [1,8]disk_asynch_iodovoljeni sta dve vrednosti:true|false;filesystemio_optionsdovoljene so naslednje vrednosti:none|setall|directIO|asynch;db_block_checkingdovoljene so naslednje vrednosti:OFF|LOW|MEDIUM|FULL;db_block_checksumdovoljene so naslednje vrednosti:OFF|TYPICAL|FULL;
Oseba z izkušnjami pri vzdrževanju baz podatkov Oracle zagotovo že lahko pove, kaj in na katere vrednosti je treba nastaviti, od navedenih parametrov in njihovih sprejemljivih vrednosti, da bi pridobili večjo produktivnost baze za delo s podatki, ki jih označuje kodo aplikacije, tukaj zgoraj.
Toda
Bistvo laboratorijskega dela je pokazati, da nam bo to relativno hitro razjasnil sam optimizacijski algoritem.
Nam preostane le, da skozi prilagodljiv sistem pogledamo v dokument ravno toliko, da ugotovimo, katere parametre spremeniti in v kakšnih razponih.
In še: kodirajte kodo, ki bo uporabljena za delo s sistemom po meri izbranega optimizacijskega algoritma.
Torej, zdaj o kodi.
Zgoraj sem govoril o cran-r, tj.: vse manipulacije s prilagojenim sistemom so orkestrirane v obliki skripta R.
Dejanska naloga, analiza, izbira po vrednosti metrike, vektorji stanja sistema: to je paket GA ()
Paket v tem primeru ni preveč primeren, v smislu, da pričakuje, da so vektorji (kromosomi, če gre za paket) določeni v obliki nizov številk z ulomkom.
In moj vektor, iz vrednosti nastavitvenih parametrov: to je 14 količin - cela števila in vrednosti nizov.
Težavi se seveda zlahka izognemo tako, da vrednostim nizov dodelimo nekaj specifičnih števil.
Tako je na koncu glavni del skripta R videti takole:
Pokličite 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@solutionTukaj, s pomočjo lower и upper atributi podprograma ga v bistvu je določeno območje iskalnega prostora, znotraj katerega se bo iskalo takšen vektor (ali vektorji), za katerega bo pridobljena največja vrednost funkcije fitnesa.
Podprogram ga izvaja iskanje, ki maksimira funkcijo primernosti.
No, potem se izkaže, da je v tem primeru nujno, da fitnes funkcija, ki razume vektor kot niz vrednosti za določene parametre subd, prejme metriko od subd.
To je: koliko z dano nastavitvijo subd in dano obremenitvijo subd: subd obdela transakcije na sekundo.
To pomeni, da je treba pri odvijanju izvesti naslednje več korakov znotraj fitnes funkcije:
- Obdelava vhodnega vektorja števil - pretvorba v vrednosti za parametre podpodatkov.
- Poskus ustvarjanja danega števila skupin za ponavljanje dane velikosti. Poleg tega je poskus lahko neuspešen.
Revialne skupine, ki so že obstajale v subd, v določeni količini in določeni velikosti, za čistost eksperimenta - d.b. izbrisano. - Če je prejšnja točka uspešna: podajanje vrednosti konfiguracijskih parametrov v bazo podatkov (ponovno: lahko pride do napake)
- Če je prejšnji korak uspešen: ustavitev subd, zagon subd, tako da na novo določene vrednosti parametrov začnejo veljati. (še enkrat: lahko pride do napake)
- Če je prejšnji korak uspešen: izvedite preizkus obremenitve. pridobite meritve iz subd.
- Vrnite subd v prvotno stanje, tj. izbrišite dodatne skupine dnevnikov, vrnite prvotno konfiguracijo podbaze podatkov za delovanje.
Koda fitnes funkcije
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)
}to. vsa dela: opravljajo v funkciji fitnes.
Ga-podprogram obdeluje vektorje ali, pravilneje, kromosome.
Pri čemer je za nas najpomembnejša izbira kromosomov z geni, za katere funkcija fitnesa daje velike vrednosti.
To je v bistvu proces iskanja optimalnega nabora kromosomov z uporabo vektorja v N-dimenzionalnem iskalnem prostoru.
Zelo jasno, podrobno , s primeri R-kode, delo genetskega algoritma.
Ločeno bi rad opozoril na dve tehnični točki.
Pomožni klici iz funkcije evaluate, na primer, stop-start, nastavitev vrednosti parametra subd, se izvajajo na podlagi cran-r funkcije system2
S pomočjo katerega: se pokliče neka bash skripta ali ukaz.
Na primer:
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)
}
}Druga točka je črta, evaluate funkcij, s shranjevanjem določene metrične vrednosti in njenega ustreznega vektorja za uravnavanje v datoteko dnevnika:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)To je pomembno, ker bo iz tega podatkovnega niza mogoče pridobiti dodatne informacije o tem, katera od komponent uglaševalnega vektorja ima večji ali manjši vpliv na metrično vrednost.
To pomeni, da bo mogoče izvajati atributno-importamce analizo.
Torej, kaj se lahko zgodi?
V obliki grafa, če razvrstite teste v naraščajočem metričnem vrstnem redu, je slika naslednja:
Nekaj podatkov, ki ustrezajo skrajnim vrednostim metrike:
Tukaj, na posnetku zaslona z rezultati, bom pojasnil: vrednosti nastavitvenega vektorja so podane glede na kodo funkcije fitnesa, ne glede na številčni seznam parametrov/območij vrednosti parametrov, ki je bil oblikovan zgoraj v besedilu.
No. Ali je to veliko ali malo, ~8 tisoč tps: ločeno vprašanje.
V okviru laboratorijskega dela ta številka ni pomembna, pomembna je dinamika, kako se ta vrednost spreminja.
Dinamika tukaj je dobra.
Očitno je, da vsaj en dejavnik bistveno vpliva na vrednost metrike, ga-algoritem, ki razvršča kromosomske vektorje: prekriti.
Sodeč po dokaj živahni dinamiki vrednosti krivulje, obstaja vsaj še en dejavnik, ki ima, čeprav bistveno manjši vpliv.
Tukaj ga potrebujete attribute-importance analizo, da bi razumeli, kateri atributi (no, v tem primeru komponente vektorja uglaševanja) in koliko vplivajo na metrično vrednost.
In iz teh informacij: razumeti, na katere dejavnike so vplivale spremembe pomembnih atributov.
Run attribute-importance mogoče na različne načine.
Za te namene mi je všeč algoritem randomForest R paket z istim imenom ()
randomForest, kot razumem njegovo delo na splošno in njegov pristop k ocenjevanju pomembnosti atributov posebej, gradi določen model odvisnosti spremenljivke odziva od atributov.
V našem primeru je spremenljivka odziva metrika, pridobljena iz baze podatkov v obremenitvenih testih: tps;
In atributi so komponente vektorja uglaševanja.
Torej tukaj randomForest ovrednoti pomembnost vsakega atributa modela z dvema številkama: %IncMSE — kako prisotnost/odsotnost tega atributa v modelu spremeni kakovost MSE tega modela (srednja kvadratna napaka);
In IncNodePurity je število, ki odraža, kako dobro je na podlagi vrednosti tega atributa mogoče razdeliti nabor podatkov z opazovanji, tako da so v enem delu podatki z eno vrednostjo razložene metrike, v drugem pa z drugo vrednost metrike.
No, to je: v kolikšni meri je to klasifikacijski atribut (najbolj jasno razlago v ruskem jeziku sem videl na RandomForest ).
Delavsko-kmečka R-koda za obdelavo nabora podatkov z rezultati obremenitvenih testov:
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$importanceHiperparametre algoritma lahko neposredno izberete z rokami in s poudarkom na kakovosti modela izberete model, ki natančneje izpolnjuje napovedi v validacijskem nizu podatkov.
Za to delo lahko napišete kakšno funkcijo (mimogrede, spet z uporabo neke vrste optimizacijskega algoritma).
Uporabite lahko paket R caret, ni bistvo pomembno.
Posledično v tem primeru dobimo naslednji rezultat za oceno stopnje pomembnosti atributov:
No. Tako lahko začnemo globalno refleksijo:
- Izkazalo se je, da je bil v teh pogojih testiranja najpomembnejši parameter
commit_wait
Tehnično določa način izvajanja operacije io zapisovanja podatkov ponavljanja iz medpomnilnika dnevnika subdb v trenutno skupino dnevnikov: sinhrono ali asinhrono.
Vrednostnowaitkar ima za posledico skoraj navpično, večkratno povečanje vrednosti metrike tps: to je vključitev asinhronega načina io v redo skupine.
Ločeno vprašanje je, ali bi morali to storiti v zbirki podatkov o živilih. Tukaj se omejujem le na ugotovitev: to je pomemben dejavnik. - Logično je, da se velikost medpomnilnika dnevnika subd: izkaže za pomemben dejavnik.
Manjša kot je velikost vmesnega pomnilnika dnevnika, manjša je njegova zmogljivost vmesnega pomnilnika, pogostejše je prelivanje in/ali nezmožnost dodelitve prostega območja v njem za del novih redoks podatkov.
To pomeni: zamude, povezane z dodeljevanjem prostora v medpomnilniku dnevnika in/ali izpisovanjem podatkov za ponavljanje iz njega v skupine za ponavljanje.
Te zamude bi seveda morale in dejansko vplivajo na prepustnost baze podatkov za transakcije. - Parameter
db_block_checksum: no, tudi na splošno je jasno - obdelava transakcij vodi do oblikovanja blokov darty v predpomnilniku medpomnilnika podbaze podatkov.
Ko je omogočeno preverjanje kontrolnih vsot podatkovnih blokov, jih mora obdelati baza podatkov - izračunati te kontrolne vsote iz telesa podatkovnega bloka, jih preveriti s tem, kar piše v glavi podatkovnega bloka: se ujema/ne ujema.
Takšno delo spet ne more zadrževati obdelave podatkov, zato sta parameter in mehanizem, ki določa ta parameter, pomembna.
Zato prodajalec v dokumentaciji za ta parameter ponuja različne vrednosti zanj (parameter) in ugotavlja, da da, vpliv bo, vendar lahko izberete različne vrednosti, do »izklopljeno« in različne vplive.
No, globalni zaključek.
Pristop se na splošno izkaže za precej delujočega.
Precej si dovoli, da se v zgodnjih fazah obremenitvenega testiranja določenega storitvenega sistema, da bi izbral njegovo (sistemsko) optimalno konfiguracijo za obremenitev, ne poglablja preveč v specifike nastavitve sistema za obremenitev.
Vendar ga ne izključuje v celoti - vsaj na ravni razumevanja: sistem mora poznati "gumbe za nastavitev" in dovoljena območja vrtenja teh gumbov.
Pristop lahko nato relativno hitro najde optimalno konfiguracijo sistema.
Na podlagi rezultatov testiranja je mogoče pridobiti informacije o naravi razmerja med meritvami delovanja sistema in vrednostmi parametrov sistemskih nastavitev.
Kar bi seveda moralo prispevati k nastanku tega zelo globokega razumevanja sistema, njegovega delovanja, vsaj pri dani obremenitvi.
V praksi gre za menjavo stroškov razumevanja prilagojenega sistema za stroške priprave takšnega testiranja sistema.
Ločeno želim opozoriti: pri tem pristopu je kritično pomembna stopnja ustreznosti testiranja sistema obratovalnim pogojem, ki jih bo imel v komercialnem delovanju.
Hvala za vašo pozornost in čas.
Vir: www.habr.com