Përshëndetje.
Vendosa tĂ« ndaja gjetjen time â njĂ« fryt i mendimeve, provave dhe gabimeve.
NĂ« thelb: kjo nuk Ă«shtĂ« ndonjĂ« gjetje, natyrisht â gjithçka kjo duhet tĂ« jetĂ« e njohur prej kohĂ«sh pĂ«r ata qĂ« merren me trajtimin e tĂ« dhĂ«nave dhe optimizimin e ndonjĂ« sistemi, e jo domosdoshmĂ«risht tĂ« bazave tĂ« tĂ« dhĂ«nave.
Dhe: po, ata e dinë, shkruajnë artikuj interesantë për kërkimet e tyre, (UPD.: në komente u përmend një projekt shumë interesant: )
Nga ana tjetër: në një shikim të parë nuk shoh përhapje të gjerë të këtij qasjes, në internet, midis specialistëve IT, DBA.
Pra, për të shkuar te thelbi.
Supozoni se kemi një detyrë: të konfigurojmë një sistem shërbimi, për austri të caktuar.
PĂ«r kĂ«tĂ« punĂ« â dihet: çfarĂ« Ă«shtĂ«, si matet cilĂ«sia e kĂ«saj punĂ« dhe cili Ă«shtĂ« kriteri pĂ«r matjet e kĂ«saj cilĂ«sie.
Po ashtu le të supozojmë se, më shumë ose më pak e dimë: si po kryhet puna në (ose me) këtë sistem shërbimi.
"MĂ« shumĂ« ose mĂ« pak" â do tĂ« thotĂ« se ka mundĂ«si tĂ« pĂ«rgatitet (ose tĂ« merret ndonjĂ«herĂ«) njĂ« mjet, utilit, shĂ«rbim me tĂ« cilin mund tĂ« sintetizohet dhe tĂ« ofrohet njĂ« ngarkesĂ« testuese mjaft adekuate pĂ«r atĂ« qĂ« do tĂ« jetĂ« nĂ« prodhim, nĂ« kushte mjaft adekuate pĂ«r punĂ«n nĂ« prodhim.
Dhe le të supozojmë se dihet seti i parametrave rregullues të këtij sistemi shërbimi, me të cilët mund të konfigurohet ky sistem, në kuptimin e produktivitetit të punës së tij.
Dhe, ku Ă«shtĂ« problemi â nuk ka njĂ« kuptim tĂ« mjaftueshĂ«m tĂ« kĂ«tij sistemi shĂ«rbimi, njĂ« atĂ« qĂ« lejon tĂ« pĂ«rcaktohet ekspertikisht konfigurimi i kĂ«tij sistemi, pĂ«r ngarkesĂ«n e ardhshme, nĂ« kĂ«tĂ« platformĂ« dhe tĂ« merret produktiviteti i nevojshĂ«m i punĂ«s sĂ« sistemit.
Mirë. Kështu ndodh pothuajse gjithmonë.
ĂfarĂ« mund tĂ« bĂ«het kĂ«tu.
E para qĂ« mĂ« vjen nĂ« mendje: tĂ« shikojmĂ« dokumentacionin pĂ«r kĂ«tĂ« sistem. TĂ« kuptojmĂ« â cilat janĂ« intervalet e pranueshme pĂ«r vlerat e parametrave rregullues. Dhe, pĂ«r shembull, me metodĂ«n e zbritjes koordinative, tĂ« zgjidhim vlerat pĂ«r parametrat e sistemit, nĂ« teste.
Këtë do të thotë të caktojmë sistemit një konfigurim, në formën e një grumbulli të caktuar vlerash të parametrave të tij.
T'i japim ngarkesë testuese, me këtë mjet-utility, gjenerator ngarkese.
Dhe tĂ« shohim madhĂ«sinĂ« â pĂ«rgjigjen, ose metrikĂ«n e cilĂ«sisĂ« sĂ« punĂ«s sĂ« sistemit.
Mendimi i dytĂ« mund tĂ« jetĂ« njĂ« pĂ«rfundim se â kjo Ă«shtĂ« shumĂ« e gjatĂ«.
QĂ« do tĂ« thotĂ«: nĂ«se parametrat rregullues janĂ« shumĂ«, nĂ«se intervalet e vlerave tĂ« tyre janĂ« tĂ« mĂ«dha, nĂ«se çdo test i veçantĂ« ngarkese â zgjat shumĂ«, atĂ«herĂ«: po, gjithçka kjo mund tĂ« marrĂ« njĂ« kohĂ« tĂ« papĂ«rshtatshme shumĂ«.
Dhe këtu çfarë mund të kuptojmë dhe të kujtojmë.
Mund tĂ« mĂ«sojmĂ«, nĂ« setin e vlerave tĂ« parametrave rregullues tĂ« sistemit shĂ«rbimi â njĂ« vektor, si njĂ« sekuencĂ« ndonjĂ« vlerash.
Ădo njĂ«ri prej kĂ«tyre vektorĂ«ve, duke supozuar se gjithçka tjetĂ«r Ă«shtĂ« e barabartĂ« (nĂ« atĂ« qĂ« ky vektor nuk preket) i korrespondon njĂ« vlerĂ« tĂ« caktuar metrikĂ« â indikator i cilĂ«sisĂ« sĂ« punĂ«s sĂ« sistemit, nĂ«n ngarkesĂ«n testuese.
Që do të thotë.
Le të shënojmë vektorin e konfigurimit të sistemit, si 
, ku 
; Ku 
â numri i parametrave tĂ« konfigurimit tĂ« sistemit, sa janĂ«, kĂ«ta parametra.
Dhe vlera e metrikës, që përputhet me këtë 
e shënojmë si
, atëherë, ne kemi një funksion: 
Dhe, atëherë: gjithçka reduktohet menjëherë në, në rastin tim: pothuajse të harrohen algoritmet e kërkimit të ekstremumit të funksionit.
Mirë, por këtu lind një pyetje organizative-aplikuese: cila strategji të përdorim.
- QĂ« do tĂ« thotĂ« â pĂ«r tĂ« koduar sa mĂ« pak me duar.
- Dhe qĂ« tĂ« punojĂ«, pra, tĂ« gjendet ekstremumi (nĂ«se ekziston), gjithsesi â mĂ« shpejt se zbritja koordinative.
Momenti i parĂ« sugjeron qĂ« duhet tĂ« shikojmĂ« nĂ« drejtim tĂ« disa mjeteve, nĂ« tĂ« cilat kĂ«to algoritme â janĂ« tashmĂ« tĂ« realizuara, dhe ka, nĂ« njĂ« formĂ« tĂ« gatshme pĂ«r pĂ«rdorim nĂ« kod.
Mirë, unë e njoh python dhe cran-r
Momenti i dytë tregon se duhet të lexojmë rreth algoritmeve të vetë, se cilat janë, çfarë kërkesash kanë, karakteristikat në punë.
Dhe se çfarë ofrojnë, mund të kenë efekte apo rezultate anësore të dobishme, ose direkt, nga algoritmi vetë.
Ose ato mund të merren nga rezultatet e punës së algoritmit.
Këtu shumë varet nga kushtet hyrëse.
Për shembull nëse, për ndonjë arsye, duhen rezultate më të shpejta, duhet të shikojmë në algoritmet e zbritjes gradienti, të zgjedhim ndonjë prej tyre.
Ose, nëse nuk ka rëndësi shumë koha, mund të përdorim për shembull metodat e optimizimit stohastik, si algoritmin gjenetik.
Propozoj që të shqyrtojmë punën e këtij qasjeje, për përcaktimin e konfigurimit të sistemit, duke përdorur algoritmin gjenetik, në këtë punë, për ta thënë kështu: laboratorike.
Materialet:
- Le të ketë, si një sistem shërbimi:
oracle xe 18c - Le të përfshihet ajo - për të mbuluar aktivitetin transaksional dhe qëllimi: të arrihet një kapacitet sa më të madh kalimtar të bazës së të dhënave, për transaksionet/sekondë.
- Transaksionet - janë shumë të ndryshme, në mënyrën e tyre të punës me të dhënat dhe kontekstit të punës.
Le të bien dakord se këto janë transaksione që nuk përpunojnë një numër të madh tabelash të dhënash.
Në kuptimin që nuk gjenerojnë të dhëna të shfuqizuara më shumë se sa të dhëna të rikuperuara dhe nuk përpunojnë një përqindje të madhe rreshtash, tabelave të mëdha.
Këto janë transaksione që ndryshojnë një rresht në një tabelë më të madhe, me një numër të vogël indeksesh mbi këtë tabelë.
Në këtë rast: produktiviteti i bazës së të dhënave për përpunimin e transaksioneve do të përcaktohet, me kusht, nga cilësia e përpunimit të bazës së të dhënave të rikuperuara.
Kushti - nëse flasim pikërisht rreth konfigurimeve të bazës së të dhënave.
Sepse, në rastin e përgjithshëm, mund të ketë, për shembull, bllokime transaksionale, midis seancave SQL, për shkak të, dizajnit të punës së përdoruesit me të dhënat tabelare dhe/ose modelit tabelar.
Këto, sigurisht, do të ndikojnë negativisht në metrikën TPS dhe kjo do të jetë një faktor egzogjen, përsa i përket bazës së të dhënave: ashtu u dizajnuar modeli tabelar dhe puna me të dhënat në të sa që ndodhin bllokime.
Prandaj, për pastërtinë e eksperimentit, do të përjashtojmë këtë faktor, më poshtë do të sqariot si pikërisht.
- Le të supozojmë, për qartësi, se 100% e komandave SQL të dorëzuara në bazën e të dhënave: janë komandat DML.
Le të supozojmë që karakteristikat e punës së përdoruesit me bazën e të dhënave: janë të njëjta, në testime.
Dhe saktësisht: numri i seancave SQL, të dhënat tabelare, si punojnë me to seancat SQL. - Baza e të dhënave punon në
FORCE LOGGING,ARCHIVELOGmodet. ReĆŸimi Flashback Ă«shtĂ« i çaktivizuar, nĂ« nivelin e bazĂ«s sĂ« tĂ« dhĂ«nave. - TĂ« dhĂ«nat e rikuperuara: vendosen nĂ« njĂ« sistem tĂ« veçantĂ« skedarĂ«sh, nĂ« njĂ« "disk" tĂ« veçantĂ«;
Gjithë pjesa tjetër e komponentës fizike të bazës së të dhënave: në një sistem të veçantë skedarësh, në një "disk" të veçantë:
Më shumë, rreth strukturës së komponentës fizike të bazës së të dhënave laboratorike
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 0Fillimisht, nën këto kushte ngarkese, doja të përdorja bazën e të dhënave për transaksionet
Ajo ka një cilësi të edhe më të mirë, citoj autorin:
Në thelb të SLOB-it është "Metoda SLOB." Metoda SLOB ka për qëllim të testojë platformat
pa konteste aplikacioni. Nuk mund të arrihet performanca maksimale e harduerit
duke përdorur kod aplikacioni që është, për shembull, i bllokuar nga bllokimi i aplikacionit apo madje
ndarjen e bllokëve të Oracle Database. Këtë e keni të saktë - ka dhe kosto tek ndarja e të dhënave
në blloqe të dhënash! Por SLOB - në vendosjen e tij të paracaktuar - është imun ndaj një kontestimi të tillë.
Kjo deklaratë: është siç është.
ĂshtĂ« e lehtĂ« tĂ« rregullosh shkallĂ«n e paralelizmit tĂ« seancave SQL, ky Ă«shtĂ« çelĂ«si -t i aktivizimit tĂ« mjetit runit.sh nga grupi SLOB
Rregullohet përqindja e komandave DML, në atë numër seancash SQL që dërgon në bazën e të dhënave, çdo seancë SQL, parametri UPDATE_PCT
Veçmas dhe shumë rehat: SLOB vetë, përpara dhe pas seancës së ngarkesës - përgatit statistikat e paketës, ose snapshot-et AWR (çfarë është caktuar të përgatitet).
Megjithatë, u zbuluar se SLOB nuk mbështet funksionimin e seancave SQL me kohëzgjatje më pak se 30 sekonda.
Prandaj, në fillim e kodova versionin tim, punë-krah, të ngarkuesit, dhe më pas ai mbeti në punë.
Do të sqaroj për ngarkuesin - se çfarë dhe si bën, për qartësi.
Në thelb ngarkuesi duket kështu:
Kodi i punëtorit
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 dotxPunëtorët fillojnë kështu:
Fillimi i punëtorëve
echo "duke filluar testin, kohëzgjatja: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i> "$v_logfile"
dotx "$i" "${TEST_DURATION}" &
done
echo "duke pritur..." >> "$v_logfile"
waitDhe tabelat për punëtorët përgatiten kështu:
Krijimi i tabelave
funktion 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> "$v_logfile"Pra ta çdo punëtor (praktikisht: një sesion i veçantë SQL në DB) krijohet një tabelë e veçantë, me të cilën punon punëtori.
Kjo arrihet duke shmangur bllokimet transaksionale, mes sesioneve SQL të punëtorëve.
Ădo punĂ«tor: bĂ«n tĂ« njĂ«jtĂ«n gjĂ«, me tabelĂ«n e tij, tĂ« gjitha tabelat janĂ« tĂ« njĂ«jta.
Të gjithë punëtorët kryejnë punën në një kohë të njëjtë.
Për më tepër - koha është e mjaftueshme për të siguruar se, për shembull, ka ndodhur një ndryshim i log-ut, dhe jo vetëm një herë.
Po ashtu, lidhen shpenzime dhe efekte të lidhura me këtë.
Në rastin tim - koha e punës së punëtorëve është caktuar në 8 minuta.
Një fragment i raportit të statspak, me përshkrimin e punës së DB nën ngarkesë
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.1Kthehu në formulimin e punës laboratorike.
Ne do të ndryshojmë vlerat e parametrave të laboratorit të DB-së në kushte të njëjta:
- Madhësia e grupeve të regjistrimit të DB. diapazoni i vlerave: [32, 1024] MByte;
- Numri i grupeve të regjistrimit të DB. diapazoni i vlerave: [2,32];
log_archive_max_processesdiapazoni i vlerave: [1,8];commit_loggingpranohet dy vlera:batch|immediate;commit_waitpranohet dy vlera:wait|nowait;log_bufferdiapazoni i vlerave: [2,128] MByte.log_checkpoint_timeoutdiapazoni i vlerave: [60,1200] sekondadb_writer_processesdiapazoni i vlerave: [1,4]undo_retentiondiapazoni i vlerave: [30;300] sekondatransactions_per_rollback_segmentdiapazoni i vlerave: [1,8]disk_asynch_iopranohet dy vlera:true|false;filesystemio_optionspranohet këto vlera:none|setall|directIO|asynch;db_block_checkingpranohet këto vlera:OFF|LOW|MEDIUM|FULL;db_block_checksumpranohet këto vlera:OFF|TYPICAL|FULL;
Një person, me përvojë në mbështetje të bazave të të dhënave oracle, sigurisht që tani mund të thotë - se çfarë dhe çfarë vlerash duhet të angazhohen nga parametrat e dhënë dhe vlerat e tyre të lejuara, për të arritur një produktivitet më të lartë të DB-së, për atë punë me të dhëna, e cila është përcaktuar nga kodi aplikativ, këtu, më lart.
Por.
Qëllimi i punës laboratorike është të tregojë se algoritmi optimizues do na sqarojë atë shpejt.
Na mbetet vetëm të shikojmë në dokumentacionin për sistemin e konfigurueshëm, pikërisht aq sa nevojitet për të zbuluar: cilat parametra dhe në cilat diapazone duhet të ndryshohen.
Po ashtu: të kodojmë kodin, me të cilin do të implementohet puna me sistemin e konfigurueshëm në algoritmin e zgjedhur të optimizimit.
Pra, tani për kodin.
Më lart kam folur për cran-r, domethënë: të gjitha manipulimet me sistemin e konfigurueshëm - organizohen si një skriptë R.
Detyra, analiza, përzgjedhja sipas vlerave të matjes, vektorëve të gjendjes së sistemit: është paketa GA ()
Paketa, në këtë rast, nuk përshtatet shumë, në kuptimin se ajo pret të dhëna për vektorët (kromozome, në terminologjinë e paketës) në formën e numrave të vazhdueshëm me pjesë të thjeshta.
Dhe vektori im, nga vlerat e parametrave të konfigurimit: janë 14 madhësi - numra të plotë dhe vlera string.
Problemi, natyrisht, lehtë mund të rregullohet, me caktimin e vlerave string - ndonjë numri të caktuar.
Pra, në përfundim, pjesa kryesore e skriptit R duket kështu:
Thirri 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@solutionKëtu, me ndihmën e lower dhe upper atributëve të nënprogramit ga caktohet, në thelb, zona e hapësirës kërkuese, brenda së cilës do të kryhet kërkimi për një vektor (ose vektorë) për të cilët do të arrihet vlera maksimale e funksionit të përshtatshmërisë.
Nënprogrami ga kryen kërkimin duke maksimizuar funksionin e përshtatshmërisë.
Kështu, rezulton që, në këtë rast, duhet që funksioni i përshtatshmërisë, duke e kuptuar vektorin si një grup vlerash për parametrat e DB-së, të arrijë një metrikë nga DB.
Dmth: sa, me këtë konfigurim të DB-së dhe këtë ngarkesë në DB: DB përpunon transaksione në sekondë.
Pra, duke e shpjeguar, duhet që brenda funksionit të përshtatshmërisë të kryhet një procedurë e caktuar:
- PĂ«rpunimi i vektorit hyrĂ«s tĂ« numrave â transformimi i tij nĂ« vlera pĂ«r parametrat e DB-sĂ«.
- Përpjekja për të krijuar një numër të caktuar grupesh redo, me madhësinë e caktuar. Kurse përpjekja: mund të mos ketë sukses.
Grupet e dosjeve tĂ« DB-sĂ« qĂ« ekzistonin mĂ« parĂ«, nĂ« njĂ« sasi tĂ« caktuar dhe tĂ« njĂ« madhĂ«sie tĂ« caktuar, pĂ«r pastĂ«rtinĂ« e eksperimentit â duhen fshirĂ«. - NĂ«se arrin suksesin e pikĂ«s sĂ« mĂ«parshme: caktimi i bazĂ«s sĂ« vlerave tĂ« parametrave konfigurues (po ashtu: ka mundĂ«si dĂ«shtimi)
- Nëse arrin suksesin e pikës së mëparshme: ndalimi i DB-së, fillimi i DB-së që të hyjnë në fuqi vlerat e reja të parametrave. (po ashtu: ka mundësi dështimi)
- Nëse arrin suksesin e pikës së mëparshme: kryerja e një testi ngarkese. Marrja e metrikës nga DB.
- Kthejeni DB-në në gjendjen e saj fillestare, dmth hiqni grupet e përziera, kthejeni në punë konfigurimin fillestar të DB-së.
Kodi i funksionit të përshtatshmërisë
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 && 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 && 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="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)
}Kështu, gjithë puna: kryhet në funksionin e përshtatshmërisë.
NĂ«nprogrami ga, pĂ«rpunon vektorĂ«t, ose, mĂ« saktĂ«, duhet thĂ«nĂ« â kromozomet.
Në të cilën, na intereson më së shumti: seleksioni i kromozomeve me këto gjene, për të cilat funksioni i përshtatshmërisë shkakton vlera të larta.
Kjo, në thelb, është procesi i gjetjes së grupit optimal të kromozomeve në një hapësirë kërkimi N-dimensionale.
Shumë e qartë, e detajuar , me shembuj të kodit R, funksionimin e algoritmit gjenetik.
Veçmas do të theksoj dy aspekte teknikë.
Thirrjet ndihmëse, nga funksioni evaluate, për shembull ndalimi-aktivizimi, caktimi i vlerës së parametrave të DB, kryhen në bazë të cran-r funksionit system2
Me të cilin: thirret ndonjë skenar bash, ose komandë.
PĂ«r shembull:
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," dështoi me: ",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)
}
}Momenti i dytĂ« â vargu, evaluate i funksionit, me ruajtjen e vlerĂ«s specifike tĂ« metrikĂ«s dhe vektorit pĂ«rkatĂ«s tĂ« konfigurimit, nĂ« skedarin e log-ut:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Kjo është e rëndësishme, sepse nga ky grup të dhënash, do të jetë e mundur të merret informacion shtesë mbi se cili nga komponentët e vektorit të konfigurimit ndikon më shumë, ose më pak në vlerën e metrikës.
Pra: do të jetë e mundur të kryhet një analizë të rëndësisë së atributeve.
Pra, çfarë mund të ndodhë.
Në formën e një grafiku, nëse renditen testet në rritje të metrikës, pamja është kështu:
Disa të dhëna, përkatëse me vlerat ekstreme të metrikës:
KĂ«tu, nĂ« screenshot-in me rezultatet, do ta saktĂ«soj: vlerat e vektorit tĂ« konfigurimit â jepen nĂ« terma tĂ« kodit tĂ« funksionit tĂ« pĂ«rshtatshmĂ«risĂ«, jo nĂ« terma tĂ« listĂ«s sĂ« numrave tĂ« parametrave/rangjeve tĂ« vlerave tĂ« parametrave, qĂ« u formulua mĂ« lart nĂ« tekst.
Pra. Shumë është kjo, apo pak, ~8,000 tps: është një pyetje tjetër.
NĂ« kuadĂ«r tĂ« punĂ«s laboratorike â nuk Ă«shtĂ« e rĂ«ndĂ«sishme kjo numĂ«r, e rĂ«ndĂ«sishme Ă«shtĂ« dinamika, si ndryshon kjo vlerĂ«.
Dinamikë e mirë këtu.
ĂshtĂ« e qartĂ« se, tĂ« paktĂ«n njĂ« faktor, qĂ« ndikon ndjeshĂ«m nĂ« vlerĂ«n e metrikĂ«s, algoritmi ga, duke i provuar vektorĂ«t-kromozome: e ka mbuluar.
Duke marrĂ« parasysh dinamikĂ«n mjaft tĂ« shpejtĂ« tĂ« vlerave tĂ« krivĂ«s â ka edhe tĂ« paktĂ«n njĂ« faktor tjetĂ«r, i cili, edhe pse ndjeshĂ«m mĂ« i vogĂ«l, ndikon.
KĂ«tu nevojitet analiza e rĂ«ndĂ«sisĂ« sĂ« atributeve pĂ«r tĂ« kuptuar: cilat atribute (pra, nĂ« kĂ«tĂ« rast â komponentĂ«t e vektorit tĂ« konfigurimit) dhe sa fuqishĂ«m ndikon nĂ« vlerĂ«n e metrikĂ«s.
Nga kjo informacion: kuptohet se cilat faktorë ishin të përfshira në ndryshimet e atributëve të rëndësishëm.
Kryej analiza e rëndësisë së atributeve mund të jenë të ndryshme.
Mua, për këto qëllime, më pëlqen algoritmi randomForest i të njëjtit paketë R ()
randomForest, siç e kuptoj punën e tij në përgjithësi dhe qasjen e tij ndaj vlerësimit të rëndësisë së atributëve në veçanti, ndërtuon një model varësie të variablit të përgjigjes nga atributet.
Në rastin tonë, variabli i përgjigjes është një metrikë e marrë nga databazat, në testet e ngarkesës: tps;
Dhe atributet janë komponentët e vektorit të konfigurimit.
Pra randomForest vlerĂ«son rĂ«ndĂ«sinĂ« e secilit atribut tĂ« modelit me dy numra: %IncMSE â si prania/faqja e kĂ«tij atributi nĂ« model, ndikon nĂ« cilĂ«sinĂ« MSE tĂ« kĂ«tij modeli (Mesatarja Katrore e Gabimeve);
Dhe IncNodePurity është numri që tregon se sa mirë, nëpërmjet vlerave të këtij atributi, mund të ndahet dataset-i me vëzhgime, në mënyrë që në një pjesë të jenë të dhënat me një vlerë të caktuar të metrikës së shpjeguar, ndërsa në tjetrën me një vlerë tjetër të metrikës.
Pra, sa një atribut klasifikues është (së paku, kjo është shpjegimi më i qartë në rusisht për random forest). ).
Kodi R për punëtorët dhe bujqit, për përpunimin e dataset-it me rezultatet e testeve të ngarkesës:
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$importanceMund ta ndihmoni vetë për të përshtatur hiperpërmasat e algoritmit dhe, duke u bazuar në cilësinë e modelit, të zgjidhni një model më të saktë që bën parashikime në dataset-in e validimit.
Mund të shkruani ndonjë funksion për këtë punë (mbase përsëri, në ndonjë algoritëm optimizimi).
Mund të përdorni paketën R caret, nuk ka rëndësi.
Në fund, në këtë rast, rezultati për vlerësimin e shkallës së rëndësisë së atributëve është këtu:
Pra. Kështu, mund të fillojmë me reflektime të gjera:
- Kështu duket se atributi më i rëndësishëm, në këto kushte provash, doli të jetë parametri
commit_wait
Teknikisht, ai përcakton modin e ekzekutimit të operacioneve io të shkrimit të të dhënave redo, nga log-buffer i sistemit të menaxhimit të të dhënave, në grupin aktual të regjistrit: sinhron, ose asinkron.
Vleranowaitku arrihet një rritje praktikisht vertikale, shumëfish për treguesin tps: ky është përfshirja e asinkronizimit në io në grupet redo.
NjĂ« pyetje e veçantĂ« Ă«shtĂ« nĂ«se duhet ose nuk duhet bĂ«rĂ« kĂ«shtu nĂ« bazĂ«n e tĂ« dhĂ«nave prodhuese. KĂ«tu nuk e tejkaloj vetĂ«m konstatimin: kjo Ă«shtĂ« njĂ« faktor i rĂ«ndĂ«sishĂ«m. - ĂshtĂ« logjike qĂ« madhĂ«sia e log-buffer-it tĂ« sistemit tĂ« menaxhimit tĂ« tĂ« dhĂ«nave: rezulton tĂ« jetĂ« njĂ« faktor i rĂ«ndĂ«sishĂ«m.
Sa më e vogël të jetë madhësia e log-buffer-it, aq më e vogël është kapaciteti i tij buferizues, aq më shpesh ndodhin mbushje dhe/ose pamundësia për të dedikuar hapësirë të lirë për një sasi të re të dhënash redo.
Dhe gjithashtu: vonesat e lidhura me alokimin e hapësirës në log-buffer dhe/ose shkarkimin e të dhënave redo prej tij në grupet redo.
Këto vonesa, sigurisht që duhet të ndikojnë dhe ndikojnë në kapacitetin përpunues të sistemit të menaxhimit të të dhënave për transaksionet. - Parametri
db_block_checksum: po, gjithashtu, nĂ« pĂ«rgjithĂ«si Ă«shtĂ« e qartĂ« â pĂ«rpunimi i transaksioneve çon nĂ« krijimin e bllokave dart nĂ« cache-in bufer tĂ« sistemit tĂ« menaxhimit tĂ« tĂ« dhĂ«nave.
TĂ« cilat, me kontrollin e pĂ«rllogaritjes sĂ« checksum-eve tĂ« bllokimeve tĂ« tĂ« dhĂ«nave tĂ« aktivizuar, baza ka pĂ«r tĂ« pĂ«rpunuar â pĂ«r tĂ« llogaritur kĂ«to checksum-e nga trupi i bllokut tĂ« tĂ« dhĂ«nave, pĂ«r t'i krahasuar ato me atĂ« qĂ« Ă«shtĂ« shkruar nĂ« header-in e bllokut tĂ« tĂ« dhĂ«nave: pĂ«rputhet/nuk pĂ«rputhet.
Kjo punĂ«, pĂ«rsĂ«ri, nuk mund tĂ« mos vonojĂ« pĂ«rpunimin e tĂ« dhĂ«nave, dhe pĂ«r pasojĂ«, parametri dhe mekanizmi qĂ« pĂ«rcakton kĂ«tĂ« parametĂ«r â rezulton tĂ« jenĂ« tĂ« rĂ«ndĂ«sishĂ«m.
Prandaj, furnizuesi propozon, nĂ« dokumentacionin pĂ«r kĂ«tĂ« parametĂ«r, vlera tĂ« ndryshme pĂ«r tĂ« (parametrin) dhe thekson se â po, do tĂ« ketĂ« ndikim, por, ja, ka vlera tĂ« ndryshme, deri nĂ« "çaktivizuar" dhe ndikim tĂ« ndryshĂ«m, mund tĂ« zgjidhni.
Dhe tani një përfundim global.
Qasja, në përgjithësi: rezulton të jetë krejtësisht funksionale.
Ajo lejon, në etapa të hershme të testimit të ngarkesës së një sistemi shërbimi, të zgjidhni konfigurimin optimal të tij (sistemit) për ngarkesë pa u fut shumë në detajet e konfigurimit të sistemit për ngarkesë.
Por nuk pĂ«rjashton plotĂ«sisht â sĂ« paku nĂ« nivelin e kuptimit: "ruletat rregulluese" dhe gamat e pranuara tĂ« rrotullimit tĂ« kĂ«tyre ruletave, duhet tĂ« dihet pĂ«r sistemin.
Më pas, qasja mund të gjejë mjaft shpejt konfigurimin optimal të sistemit.
Dhe mund të merrni, pas testimit, informacion mbi natyrën e lidhjes midis treguesit të cilësisë së punës së sistemit dhe vlerave të parametërve të rregullimit të sistemit.
Kjo, sigurisht, duhet tĂ« kontribuojĂ« nĂ« krijimin e atij kuptimi tĂ« thellĂ« tĂ« sistemit, punĂ«s sĂ« saj, tĂ« paktĂ«n â nĂ«n kĂ«tĂ« ngarkesĂ«.
Praktikisht është: ndarja e kostove për të kuptuar sistemin e rregullueshëm, nga kostot e përgatitjes së testimit të tillë të punës së sistemit.
VeçanĂ«risht theksoj: nĂ« kĂ«tĂ« qasje â Ă«shtĂ« kritikisht e rĂ«ndĂ«sishme shkalla e pĂ«rshtatshmĂ«risĂ« sĂ« testimit tĂ« sistemit pĂ«r kushtet e punĂ«s qĂ« do tĂ« ketĂ« nĂ« shfrytĂ«zimin e saj nĂ« prodhim.
Faleminderit për vëmendjen tuaj, kohën.
Burimi: habr.com
