Sveiki
Nusprendžiau pasidalinti savo atradimu – minčių, bandymų ir klaidų vaisiumi.
Apskritai: tai, žinoma, ne radinys – visa tai turėjo būti žinoma jau seniai tiems, kurie užsiima taikomuoju statistinių duomenų apdorojimu ir bet kokių sistemų, nebūtinai konkrečiai DBVS, optimizavimu.
Ir: taip, jie žino, rašo įdomius straipsnius apie savo tyrimus, (UPD.: komentaruose jie atkreipė dėmesį į labai įdomų projektą: )
Kita vertus: nematau tokio požiūrio plačiai paminėjimo ar platinimo internete tarp IT specialistų, DBA.
Taigi, prie esmės.
Tarkime, kad turime užduotį: sukurti tam tikrą paslaugų sistemą, kuri aptarnautų kokį nors darbą.
Apie šį darbą žinoma: kas tai yra, kaip matuojama šio darbo kokybė ir koks yra šios kokybės matavimo kriterijus.
Taip pat tarkime, kad daugiau ar mažiau žinoma ir suprantama: kaip tiksliai dirbama šioje paslaugų sistemoje (ar su ja).
„Daugiau ar mažiau“ – tai reiškia, kad galima paruošti (arba iš kažkur gauti) tam tikrą įrankį, komunalinį paslaugų paketą, paslaugą, kurią galima susintetinti ir pritaikyti sistemai bandomuoju krūviu, pakankamai adekvačiu tam, kas bus gamyboje, pakankamai tinkamomis dirbti gamyboje sąlygomis.
Na, tarkime, kad yra žinomas šios paslaugų sistemos reguliavimo parametrų rinkinys, kurį naudojant galima konfigūruoti šią sistemą, atsižvelgiant į jos darbo našumą.
Ir kame problema - nėra pakankamai išsamaus šios paslaugų sistemos supratimo, tokio, kuris leistų meistriškai sukonfigūruoti šios sistemos nustatymus būsimam apkrovimui tam tikroje platformoje ir gauti reikiamą sistemos produktyvumą.
Na. Taip būna beveik visada.
Ką čia galima padaryti?
Na, pirmas dalykas, kuris ateina į galvą, yra pažvelgti į šios sistemos dokumentaciją. Supraskite, kokie yra priimtini reguliavimo parametrų verčių diapazonai. Ir, pavyzdžiui, naudodamiesi koordinačių nusileidimo metodu, testuose pasirinkite sistemos parametrų reikšmes.
Tie. Suteikite sistemai tam tikrą konfigūraciją konkretaus konfigūracijos parametrų verčių rinkinio pavidalu.
Taikykite bandomąją apkrovą naudodami šį įrankį-įrankį, apkrovos generatorių.
Ir pažiūrėkite į vertę – atsaką arba sistemos kokybės metriką.
Antra mintis gali būti išvada, kad tai labai ilgas laikas.
Na, tai yra: jei yra daug nustatymo parametrų, jei jų reikšmių diapazonai yra dideli, jei kiekvienas atskiras apkrovos testas trunka daug laiko, tada: taip, visa tai gali užtrukti nepriimtinai ilgas laikas.
Na, štai ką galite suprasti ir atsiminti.
Galite sužinoti, kad paslaugų sistemos parametrų parametrų reikšmių rinkinyje yra vektorius, kaip kai kurių reikšmių seka.
Kiekvienas toks vektorius, kai kiti dalykai yra vienodi (tuo, kad jo neveikia šis vektorius), atitinka visiškai apibrėžtą metrikos reikšmę - sistemos veikimo kokybės pagal bandomąją apkrovą rodiklį.
Ty
Sistemos konfigūracijos vektorių pažymėkime kaip 
Kur ; Kur — sistemos konfigūracijos parametrų skaičius, kiek šių parametrų yra.
Ir tai atitinkanti metrikos reikšmė pažymėkime kaip
, tada gauname funkciją:
Na, o tada: viskas iš karto susiveda į, mano atveju: beveik pamirštus nuo studijų laikų, funkcijos ekstremumo paieškos algoritmus.
Gerai, bet čia iškyla organizacinis ir taikomas klausimas: kokį algoritmą naudoti.
- Ta prasme – kad mažiau galėtum koduoti ranka.
- O kad jis veiktų, t.y. surado ekstremumą (jei toks yra), na, bent jau greičiau nei koordinačių nusileidimas.
Pirmas punktas rodo, kad turime pažvelgti į kai kurias aplinkas, kuriose tokie algoritmai jau buvo įdiegti ir tam tikra forma yra paruošti naudoti kode.
Na, aš žinau python и cran-r
Antras punktas reiškia, kad reikia pasiskaityti apie pačius algoritmus, kokie jie yra, kokie jų reikalavimai ir darbo ypatybės.
Ir tai, ką jie duoda, gali būti naudingas šalutinis poveikis – rezultatai arba tiesiogiai iš paties algoritmo.
Arba juos galima gauti iš algoritmo rezultatų.
Daug kas priklauso nuo įvesties sąlygų.
Pavyzdžiui, jei dėl kokių nors priežasčių reikia greičiau gauti rezultatą, na, reikia pažvelgti į gradiento nusileidimo algoritmus ir pasirinkti vieną iš jų.
Arba, jei laikas nėra toks svarbus, galite, pavyzdžiui, naudoti stochastinius optimizavimo metodus, tokius kaip genetinis algoritmas.
Šio metodo darbą, pasirenkant sistemos konfigūraciją, naudojant genetinį algoritmą, siūlau apsvarstyti kitame, taip sakant: laboratoriniame darbe.
Originalus:
- Tebūnie kaip paslaugų sistema:
oracle xe 18c - Tegul tai tarnauja transakcinei veiklai ir tikslui: gauti kuo didesnį duomenų bazės pralaidumą, operacijose/sek.
- Sandoriai gali labai skirtis darbo su duomenimis pobūdžiu ir darbo kontekstu.
Sutikime, kad tai operacijos, kurios neapdoroja didelio kiekio lentelės duomenų.
Ta prasme, kad jie nesukuria daugiau anuliavimo duomenų nei perdaro ir neapdoroja didelių eilučių ir didelių lentelių procentų.
Tai operacijos, kurios pakeičia vieną eilutę daugiau ar mažiau didelėje lentelėje, o šioje lentelėje yra nedidelis indeksų skaičius.
Esant tokiai situacijai: operacijų apdorojimo subduomenų bazės produktyvumą su išlyga lems redokso duomenų bazės apdorojimo kokybė.
Atsakomybės apribojimas – jei kalbame konkrečiai apie subdb nustatymus.
Kadangi paprastai gali būti, pavyzdžiui, operacijų užraktai tarp SQL seansų dėl vartotojo darbo su lentelės duomenimis ir (arba) lentelės modelio dizaino.
Tai, žinoma, turės slegiantį poveikį TPS metrikai ir tai bus išorinis veiksnys, palyginti su subduomenų baze: na, taip buvo sukurtas lentelės modelis ir darbas su jame esančiais duomenimis, kad atsiranda blokavimų.
Todėl eksperimento grynumo sumetimais mes pašalinsime šį veiksnį, o toliau paaiškinsiu, kaip tiksliai.
- Tarkime, kad 100% duomenų bazei pateiktų SQL komandų yra DML komandos.
Tegul vartotojo darbo su subduomenų baze charakteristikos testuose būna vienodos.
Būtent: skl seansų skaičius, lentelės duomenys, kaip su jais veikia skl seansai. - Subd veikia
FORCE LOGGING,ARCHIVELOGmodifikacijos. „Flashback“ duomenų bazės režimas išjungtas antriniu lygiu. - Perdaryti žurnalus: yra atskiroje failų sistemoje, atskirame „diske“;
Likusi fizinė duomenų bazės dalis: kitoje, atskiroje failų sistemoje, atskirame „diske“:
Daugiau informacijos apie fizinį įrenginį. laboratorinių duomenų bazių komponentai
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š pradžių tokiomis apkrovos sąlygomis norėjau naudoti transakcijos subd
Jis turi tokią nuostabią savybę, pacituosiu autorių:
SLOB esmė yra „SLOB metodas“. SLOB metodu siekiama išbandyti platformas
be ginčo dėl paraiškos. Negalima pasiekti maksimalaus aparatūros našumo
naudojant programos kodą, kuris, pavyzdžiui, yra susietas su programos užraktu arba netgi
dalintis „Oracle“ duomenų bazės blokais. Teisingai – dalijantis duomenimis tenka patirti papildomų išlaidų
duomenų blokuose! Tačiau SLOB – pagal numatytąjį diegimą – yra atsparus tokiam ginčui.
Ši deklaracija: atitinka, tai yra.
Patogu reguliuoti cl seansų lygiagretumo laipsnį, tai yra raktas -t paleiskite programą runit.sh iš SLOB
DML komandų procentas reguliuojamas į subd siunčiamų tekstinių pranešimų skaičių, kiekvieną teksto seansą, parametrą UPDATE_PCT
Atskirai ir labai patogiai: SLOB pati, prieš ir po įkėlimo seanso – parengia statspack arba awr-snapshots (kas nustatyta parengti).
Tačiau paaiškėjo, kad SLOB nepalaiko SQL seansų, kurių trukmė yra trumpesnė nei 30 sekundžių.
Todėl pirmiausia užkodavau savo, darbininko-valstiečių krautuvo variantą, o paskui jis liko eksploatuoti.
Kad būtų aiškumo, paaiškinsiu, ką ir kaip veikia krautuvas.
Iš esmės krautuvas atrodo taip:
Darbuotojo kodas
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 dotxDarbuotojai paleidžiami tokiu būdu:
Bėgantys darbininkai
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"
waitO lentelės darbuotojams paruošiamos taip:
Lentelių kūrimas
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"Tie. Kiekvienam darbuotojui (praktiškai: atskira SQL sesija DB) sukuriama atskira lentelė, su kuria darbuotojas dirba.
Tai užtikrina, kad tarp darbuotojo seansų nėra operacijų užraktų.
Kiekvienas darbuotojas: daro tą patį, su savo stalu, visi stalai vienodi.
Visi darbuotojai darbus atlieka tiek pat laiko.
Be to, pakankamai ilgai, kad, pavyzdžiui, žurnalo perjungimas tikrai įvyktų, ir ne vieną kartą.
Na, atitinkamai atsirado susijusių išlaidų ir padarinių.
Mano atveju darbininkų darbo trukmę sukonfigūravau 8 minutes.
„Statspack“ ataskaitos dalis, aprašanti subd veikimą esant apkrovai
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.1Grįžtant prie laboratorinių darbų.
Jei kiti dalykai bus vienodi, pakeisime šių laboratorinių duomenų bazės parametrų reikšmes:
- Duomenų bazės žurnalų grupių dydis. verčių diapazonas: [32, 1024] MB;
- Žurnalų grupių skaičius duomenų bazėje. verčių diapazonas: [2,32];
log_archive_max_processesreikšmių diapazonas: [1,8];commit_loggingleidžiamos dvi vertės:batch|immediate;commit_waitleidžiamos dvi vertės:wait|nowait;log_bufferverčių diapazonas: [2,128] MB.log_checkpoint_timeoutverčių diapazonas: [60,1200 XNUMX] sekundžiųdb_writer_processesverčių diapazonas: [1,4]undo_retentionverčių diapazonas: [30;300] sekundžiųtransactions_per_rollback_segmentverčių diapazonas: [1,8]disk_asynch_ioleidžiamos dvi vertės:true|false;filesystemio_optionsLeidžiamos šios vertės:none|setall|directIO|asynch;db_block_checkingLeidžiamos šios vertės:OFF|LOW|MEDIUM|FULL;db_block_checksumLeidžiamos šios vertės:OFF|TYPICAL|FULL;
Asmuo, turintis Oracle duomenų bazių priežiūros patirties, tikrai jau gali pasakyti, kokias ir į kokias reikšmes reikia nustatyti, iš nurodytų parametrų ir jų priimtinų reikšmių, kad būtų pasiektas didesnis duomenų bazės produktyvumas darbui su nurodytais duomenimis. programos kodas , čia aukščiau.
Tačiau.
Laboratorinio darbo esmė – parodyti, kad pats optimizavimo algoritmas mums tai paaiškins gana greitai.
Mums belieka tik pažvelgti į dokumentą per tinkinamą sistemą, kad sužinotume, kokius parametrus ir kokiuose diapazonuose keisti.
Taip pat: užkoduokite kodą, kuris bus naudojamas darbui su pasirinkta optimizavimo algoritmo pasirinkta sistema.
Taigi, dabar apie kodą.
Aukščiau kalbėjau apie cran-r, t. y.: visos manipuliacijos su pritaikyta sistema yra surengtos R scenarijaus forma.
Faktinė užduotis, analizė, pasirinkimas pagal metrinę vertę, sistemos būsenos vektoriai: tai yra paketas GA ()
Paketas šiuo atveju nėra labai tinkamas ta prasme, kad jis tikisi, kad vektoriai (chromosomos, jei kalbant apie paketą) bus nurodyti skaičių eilučių su trupmenine dalimi forma.
Ir mano vektorius, iš nustatymo parametrų verčių: tai yra 14 dydžių - sveikieji skaičiai ir eilučių reikšmės.
Žinoma, problemos galima lengvai išvengti priskiriant tam tikrus konkrečius skaičius eilutės reikšmėms.
Taigi, galiausiai, pagrindinė R scenarijaus dalis atrodo taip:
Skambinti 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@solutionČia su pagalba lower и upper paprogramės atributai ga iš esmės yra nurodyta paieškos erdvės sritis, kurioje bus ieškoma tokio vektoriaus (ar vektorių), kuriam bus gauta maksimali tinkamumo funkcijos reikšmė.
ga paprogramė atlieka paiešką, maksimaliai padidindama kūno rengybos funkciją.
Na, tada paaiškėja, kad šiuo atveju būtina, kad tinkamumo funkcija, suprasdama vektorių kaip tam tikrų subd parametrų reikšmių rinkinį, gautų metriką iš subd.
Tai yra: kiek, su tam tikra subd sąranka ir tam tikra apkrova subd: subd apdoroja operacijas per sekundę.
Tai reiškia, kad išskleidžiant kūno rengybos funkciją reikia atlikti šiuos kelis veiksmus:
- Skaičių įvesties vektoriaus apdorojimas - konvertavimas į antrinių duomenų parametrų reikšmes.
- Bandymas sukurti tam tikrą skaičių perdarymo grupių tam tikro dydžio. Be to, bandymas gali būti nesėkmingas.
Žurnalų grupės, kurios jau egzistavo subd, tam tikru kiekiu ir tam tikru dydžiu, eksperimento grynumui - d.b. ištrintas. - Jei ankstesnis punktas buvo sėkmingas: konfigūracijos parametrų reikšmių nurodymas duomenų bazėje (dar kartą: gali būti gedimas)
- Jei ankstesnis veiksmas sėkmingas: subd sustabdymas, subd paleidimas, kad įsigaliotų naujai nurodytos parametrų reikšmės. (vėl: gali būti gedimas)
- Jei ankstesnis veiksmas sėkmingas: atlikite apkrovos testą. gauti metriką iš subd.
- Grąžinkite subd į pradinę būseną, t.y. ištrinti papildomas žurnalų grupes, grąžinti pradinę duomenų bazės konfigūraciją, kad ji veiktų.
Fitneso funkcijos kodas
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)
}Tai. visi darbai: atliekami fitneso funkcijoje.
Ga-paprogramė apdoroja vektorius arba, tiksliau, chromosomas.
Kuriame mums svarbiausia yra atrinkti chromosomas su genais, kurių kūno rengybos funkcija sukuria dideles reikšmes.
Iš esmės tai yra optimalaus chromosomų rinkinio paieškos procesas naudojant vektorių N matmenų paieškos erdvėje.
Labai aiškus, detalus , su R kodo pavyzdžiais, genetinio algoritmo darbas.
Atskirai norėčiau atkreipti dėmesį į du techninius dalykus.
Pagalbiniai iškvietimai iš funkcijos evaluate, pavyzdžiui, stop-start, subd parametro reikšmės nustatymas, atliekami remiantis cran-r funkcijas system2
Kurios pagalba: iškviečiamas koks nors bash scenarijus ar komanda.
Pavyzdžiui:
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)
}
}Antras taškas yra linija, evaluate funkcijos, įrašant konkrečią metrikos reikšmę ir atitinkamą derinimo vektorių žurnalo faile:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Tai svarbu, nes iš šio duomenų masyvo bus galima gauti papildomos informacijos apie tai, kuris derinimo vektoriaus komponentas turi didesnį ar mažesnį poveikį metrinei vertei.
Tai yra: bus galima atlikti atributų ir svarbos analizę.
Taigi, kas gali atsitikti?
Diagramos pavidalu, jei užsakote testus didėjančia metrikos tvarka, vaizdas yra toks:
Kai kurie duomenys, atitinkantys kraštutines metrikos vertes:
Čia, ekrano kopijoje su rezultatais, paaiškinsiu: derinimo vektoriaus reikšmės pateikiamos pagal tinkamumo funkcijos kodą, o ne pagal suformuluotą parametrų / parametrų reikšmių diapazonų skaičių. aukščiau tekste.
Na. Ar daug ar mažai, ~8 tūkst.tps: atskiras klausimas.
Laboratorinių darbų rėmuose šis skaičius nėra svarbus, svarbu yra dinamika, kaip ši reikšmė kinta.
Dinamika čia gera.
Akivaizdu, kad bent vienas veiksnys reikšmingai įtakoja metrikos reikšmę, ga-algoritmas, rūšiuojant chromosomų vektorius: padengtas.
Sprendžiant iš gana stiprios kreivės reikšmių dinamikos, yra dar bent vienas veiksnys, kuris, nors ir žymiai mažesnis, turi įtakos.
Čia jums to reikia attribute-importance analizę, kad suprastumėte, kokie atributai (na, šiuo atveju derinimo vektoriaus komponentai) ir kiek jie daro įtaką metrinei vertei.
Ir iš šios informacijos: supraskite, kokius veiksnius paveikė reikšmingų savybių pokyčiai.
Vykdyti attribute-importance galima įvairiais būdais.
Šiais tikslais man patinka algoritmas randomForest R paketas tuo pačiu pavadinimu ()
randomForest, kaip aš suprantu jo darbą apskritai ir jo požiūrį į atributų svarbos vertinimą konkrečiai, sukuria tam tikrą atsako kintamojo priklausomybės nuo atributų modelį.
Mūsų atveju atsako kintamasis yra metrika, gauta iš duomenų bazės atliekant apkrovos testus: tps;
O atributai yra derinimo vektoriaus komponentai.
Taigi čia randomForest įvertina kiekvieno modelio atributo svarbą dviem skaičiais: %IncMSE — kaip šio požymio buvimas/nebuvimas modelyje keičia šio modelio MSE kokybę (Mean Squared Error);
O IncNodePurity yra skaičius, atspindintis, kaip gerai, remiantis šio požymio reikšmėmis, galima padalinti duomenų rinkinį su stebėjimais taip, kad vienoje dalyje būtų duomenys su viena paaiškinamos metrikos reikšme, o kitoje su kita metrikos reikšmė.
Na, tai yra: kiek tai yra klasifikacinis požymis (aiškiausią paaiškinimą rusų kalba mačiau RandomForest ).
Darbuotojo ir valstiečio R kodas, skirtas apdoroti duomenų rinkinį su apkrovos testų rezultatais:
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$importanceGalite tiesiogiai savo rankomis pasirinkti algoritmo hiperparametrus ir, sutelkdami dėmesį į modelio kokybę, pasirinkti modelį, kuris tiksliau atitinka patvirtinimo duomenų rinkinio prognozes.
Šiam darbui galite parašyti kokią nors funkciją (beje, vėlgi, naudojant kažkokį optimizavimo algoritmą).
Galite naudoti R paketą caret, ne esmė svarbi.
Dėl to šiuo atveju, norint įvertinti atributų svarbą, gaunamas toks rezultatas:
Na. Taigi galime pradėti globalius apmąstymus:
- Pasirodo, šiomis bandymo sąlygomis svarbiausias buvo parametras
commit_wait
Techniškai jis nurodo io operacijos, kai įrašomi redo duomenys iš subdb žurnalo buferio į esamą žurnalo grupę, vykdymo režimą: sinchroninis arba asinchroninis.
Vertėnowaitdėl to beveik vertikalus, daugkartinis tps metrikos vertės padidėjimas: tai asinchroninio io režimo įtraukimas į perdarymo grupes.
Atskiras klausimas, ar turėtumėte tai padaryti maisto duomenų bazėje. Čia apsiriboju teiginiu: tai yra svarbus veiksnys. - Logiška, kad subd: žurnalo buferio dydis yra reikšmingas veiksnys.
Kuo mažesnis žurnalo buferio dydis, tuo mažesnė jo buferio talpa, tuo dažniau jis persipildo ir (arba) nesugebėjimas jame skirti laisvos vietos daliai naujų redokso duomenų.
Tai reiškia: delsa, susijusi su vietos paskirstymu žurnalo buferyje ir (arba) perdarymo duomenų išmetimu iš jo į perdarymo grupes.
Žinoma, šie vėlavimai turėtų turėti įtakos ir turi įtakos operacijų duomenų bazės pralaidumui. - Parametras
db_block_checksum: na, taip pat apskritai aišku – apdorojant operaciją subduomenų bazės buferio talpykloje susidaro darty blokai.
Kurią, kai įjungta duomenų blokų kontrolinių sumų patikra, turi apdoroti duomenų bazė - apskaičiuokite šias kontrolines sumas iš duomenų bloko korpuso, patikrinkite jas su tuo, kas parašyta duomenų bloko antraštėje: atitinka/neatitinka.
Toks darbas vėlgi negali atidėti duomenų apdorojimo, todėl parametras ir mechanizmas, kuris nustato šį parametrą, yra reikšmingi.
Štai kodėl pardavėjas šio parametro dokumentacijoje siūlo skirtingas reikšmes ir pažymi, kad taip, poveikis bus, bet jūs galite pasirinkti skirtingas vertes, net „išjungtas“ ir skirtingus poveikius.
Na, visuotinė išvada.
Apskritai, metodas yra gana veiksmingas.
Jis gana leidžia sau, pradiniame tam tikros aptarnavimo sistemos apkrovos testavimo etape, norėdamas parinkti jos (sistemos) optimalią apkrovai konfigūraciją, per daug nesigilinti į sistemos nustatymo apkrovai specifiką.
Tačiau tai visiškai neatmeta - bent jau supratimo lygiu: sistema turi būti žinoma apie „reguliavimo rankenėles“ ir leistinus šių rankenėlių sukimosi diapazonus.
Tada metodas gali palyginti greitai rasti optimalią sistemos konfigūraciją.
Remiantis testavimo rezultatais, galima gauti informacijos apie sistemos veikimo metrikos ir sistemos nustatymų parametrų reikšmių ryšio pobūdį.
Kas, žinoma, turėtų prisidėti prie šio labai gilaus sistemos, jos veikimo supratimo atsiradimo bent jau esant tam tikram apkrovimui.
Praktiškai tai yra pritaikytos sistemos supratimo kaštų keitimasis tokio sistemos testavimo parengimo išlaidomis.
Atskirai norėčiau pažymėti: taikant šį metodą, sistemos testavimo tinkamumo laipsnis eksploatacinėms sąlygoms, kurias ji turės komercinėje veikloje, yra labai svarbus.
Dėkojame už dėmesį ir laiką.
Šaltinis: www.habr.com