Saluton
Mi decidis kunhavigi mian trovon - la frukton de penso, provo kaj eraro.
Ĝenerale: ĉi tio ne estas trovo, kompreneble - ĉio ĉi devus esti konata delonge, al tiuj, kiuj okupiĝas pri aplikata statistika datumtraktado kaj optimumigo de iuj sistemoj, ne nepre specife la DBMS.
Kaj: jes, ili scias, ili skribas interesajn artikolojn pri siaj esploroj, (UPD.: en la komentoj ili atentigis tre interesan projekton: )
Aliflanke: senprokraste mi ne vidas ĝeneraligitan mencion aŭ disvastigon de ĉi tiu aliro en Interreto inter IT-specialistoj, DBA.
Do, ĝis la punkto.
Ni supozu, ke ni havas taskon: starigi certan servosistemon por servi ian laboron.
Oni scias pri ĉi tiu laboro: kio ĝi estas, kiel la kvalito de ĉi tiu laboro estas mezurita, kaj kio estas la kriterio por mezuri ĉi tiun kvaliton.
Ni supozu ankaŭ, ke ĝi estas pli-malpli konata kaj komprenata: ĝuste kiel laboro estas farita en (aŭ kun) ĉi tiu servosistemo.
"Pli malpli" - tio signifas, ke eblas prepari (aŭ akiri ĝin de ie) certan ilon, utilecon, servon, kiu povas esti sintezita kaj aplikita al la sistemo kun testa ŝarĝo sufiĉe taŭga por tio, kio estos en produktado, en kondiĉoj sufiĉe taŭgaj por labori en produktado.
Nu, ni supozu, ke estas konata aro da alĝustigaj parametroj por ĉi tiu servosistemo, kiu povas esti uzata por agordi ĉi tiun sistemon laŭ la produktiveco de ĝia laboro.
Kaj kio estas la problemo - ne estas sufiĉe kompleta kompreno pri ĉi tiu servosistemo, kiu ebligas al vi kompetente agordi la agordojn de ĉi tiu sistemo por estonta ŝarĝo sur difinita platformo kaj akiri la bezonatan produktivecon de la sistemo.
Nu. Ĉi tio estas preskaŭ ĉiam la kazo.
Kion vi povas fari ĉi tie?
Nu, la unua afero, kiu venas al la menso, estas rigardi la dokumentaron por ĉi tiu sistemo. Komprenu, kiaj estas la akcepteblaj intervaloj por la valoroj de la alĝustigaj parametroj. Kaj, ekzemple, uzante la koordinatan descendan metodon, elektu valorojn por sistemaj parametroj en testoj.
Tiuj. donu al la sistemo ian agordon, en la formo de specifa aro de valoroj por ĝiaj agordaj parametroj.
Apliku testan ŝarĝon al ĝi, uzante ĉi tiun tre ilo-utilan ŝarĝgeneratoron.
Kaj rigardu la valoron - la respondon, aŭ metrikon de la kvalito de la sistemo.
La dua penso povas esti la konkludo, ke tio estas tre longa tempo.
Nu, tio estas: se estas multaj agordaj parametroj, se la intervaloj de iliaj valoroj estantaj rulitaj estas grandaj, se ĉiu individua ŝarĝtesto bezonas multan tempon por plenumi, tiam: jes, ĉio ĉi povas preni neakcepteble. longa tempo.
Nu, jen kion vi povas kompreni kaj memori.
Vi povas ekscii, ke en la aro de valoroj de la parametroj de agordoj de la servosistemo estas vektoro, kiel sekvenco de iuj valoroj.
Ĉiu tia vektoro, aliaj aferoj egalaj (en tio, ke ĝi ne estas tuŝita de ĉi tiu vektoro), respondas al tute difinita valoro de la metriko - indikilo de la kvalito de la funkciado de la sistemo sub testa ŝarĝo.
te
Ni notu la sisteman agordan vektoron kiel 
kie ; Kie — nombro da sistemaj agordaj parametroj, kiom da ĉi tiuj parametroj estas.
Kaj la valoro de la metriko responda al ĉi tio ni nomu ĝin kiel
, tiam ni ricevas funkcion:
Nu, do: ĉio tuj venas al, en mia kazo: preskaŭ forgesita de miaj studentaj tempoj, algoritmoj por serĉi la ekstremumon de funkcio.
Bone, sed ĉi tie aperas organiza kaj aplikata demando: kiun algoritmon uzi.
- En la senco - por ke vi povu kodi malpli mane.
- Kaj por ke ĝi funkciu, t.e. trovis la ekstremumon (se ekzistas unu), nu, almenaŭ pli rapide ol koordinata deveno.
La unua punkto sugestas ke ni devas rigardi al iuj medioj en kiuj tiaj algoritmoj jam estis efektivigitaj, kaj estas, iel, pretaj por uzi en kodo.
Nu, mi scias python и cran-r
La dua punkto signifas, ke vi devas legi pri la algoritmoj mem, kio ili estas, kiaj estas iliaj postuloj kaj la trajtoj de ilia laboro.
Kaj tio, kion ili donas, povas esti utilaj kromefikoj - rezultoj, aŭ rekte de la algoritmo mem.
Aŭ ili povas esti akiritaj de la rezultoj de la algoritmo.
Multe dependas de la enigokondiĉoj.
Ekzemple, se, ial, vi devas akiri rezulton pli rapide, nu, vi devas rigardi al gradienta descendo-algoritmoj kaj elekti unu el ili.
Aŭ, se tempo ne tiom gravas, vi povas, ekzemple, uzi stokastikajn optimumigajn metodojn, kiel genetikan algoritmon.
Mi proponas konsideri la laboron de ĉi tiu aliro, elektante la sisteman agordon, uzante genetikan algoritmon, en la sekva, por tiel diri: laboratoria laboro.
Originala:
- Estu, kiel servosistemo:
oracle xe 18c - Lasu ĝin servi transakcian agadon kaj la celon: akiri la plej altan eblan trairon de la subdatumbazo, en transakcioj/sek.
- Transakcioj povas esti tre malsamaj en la naturo de laborado kun datumoj kaj la kunteksto de laboro.
Ni konsentu, ke ĉi tiuj estas transakcioj, kiuj ne prilaboras grandan kvanton da tabelaj datumoj.
En la senco, ke ili ne generas pli da malfari datumoj ol refari kaj ne prilaboras grandajn procentojn de vicoj kaj grandaj tabeloj.
Ĉi tiuj estas transakcioj, kiuj ŝanĝas unu vicon en pli-malpli granda tabelo, kun malgranda nombro da indeksoj sur ĉi tiu tablo.
En ĉi tiu situacio: la produktiveco de la subdatumbazo por prilaborado de transakcioj estos, kun rezervo, determinita de la kvalito de pretigo de la redox-datumbazo.
Malgarantio - se ni parolas specife pri la subdb-agordoj.
Ĉar, en la ĝenerala kazo, povas ekzisti, ekzemple, transakciaj seruroj inter SQL-sesioj, pro la dezajno de uzantlaboro kun tabelaj datumoj kaj/aŭ la tabela modelo.
Kio, kompreneble, havos deprimigan efikon sur la TPS-metriko kaj ĉi tio estos eksogena faktoro, rilate al la subdatumbazo: nu, jen kiel la tabula modelo estis desegnita kaj la laboro kun datumoj en ĝi, ke blokado okazas.
Tial, por la pureco de la eksperimento, ni ekskludos ĉi tiun faktoron, kaj sube mi klarigos ĝuste kiel.
- Ni supozu, por certeco, ke 100% de la SQL-komandoj senditaj al la datumbazo estas DML-komandoj.
Lasu la karakterizaĵojn de uzantlaboro kun la subdatumbazo esti la samaj en testoj.
Nome: la nombro da skl-sesioj, tabelaj datumoj, kiel skl-sesioj funkcias kun ili. - Subd funkcias en
FORCE LOGGING,ARCHIVELOGmods. Flashback-datumbaza reĝimo estas malŝaltita, ĉe la subdnivelo. - Refari protokolojn: troviĝas en aparta dosiersistemo, sur aparta "disko";
La resto de la fizika komponanto de la datumbazo: en alia, aparta dosiersistemo, sur aparta "disko":
Pli da detaloj pri la fizika aparato. komponantoj de laboratoriaj datumbazoj
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 0Komence, sub ĉi tiuj ŝarĝaj kondiĉoj, mi volis uzi transakcian subd
Ĝi havas tiel mirindan funkcion, mi citos la aŭtoron:
Ĉe la koro de SLOB estas la "SLOB-metodo". La SLOB-Metodo celas testi platformojn
sen aplika disputo. Oni ne povas stiri maksimuman aparataron
uzante aplikaĵokodon kiu estas, ekzemple, ligita per aplikaĵoŝlosado aŭ eĉ
kundividante Oracle Database-blokojn. Ĝuste—estas supre dum kundivido de datumoj
en datumblokoj! Sed SLOB—en ĝia defaŭlta deplojo—estas imuna kontraŭ tia disputo.
Ĉi tiu deklaro: respondas, ĝi estas.
Estas oportune reguligi la gradon de paraleleco de cl-sesioj, ĉi tio estas la ŝlosilo -t lanĉi la utilecon runit.sh de SLOB
La procento de DML-komandoj estas reguligita, en la nombro da tekstmesaĝoj kiuj estas senditaj al la subd, ĉiu tekstsesio, parametro UPDATE_PCT
Aparte kaj tre oportune: SLOB mem, antaŭ kaj post la ŝarĝo-sesio - preparas statspack, aŭ awr-snapshots (kio estas preta).
Tamen, ĝi rezultis ke SLOB ne subtenas SQL-sesiojn kun daŭro de malpli ol 30 sekundoj.
Tial mi unue kodis mian propran, laboristan-kampanan version de la ŝargilo, kaj poste ĝi restis funkcianta.
Mi klarigu, kion faras la ŝargilo kaj kiel ĝi faras ĝin, por klareco.
Esence la ŝargilo aspektas jene:
Laborista kodo
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 dotxLaboristoj estas lanĉitaj jene:
Kurantaj laboristoj
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"
waitKaj tabloj por laboristoj estas preparitaj jene:
Kreante tabelojn
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"Tiuj. Por ĉiu laboristo (praktike: aparta SQL-sesio en la DB) estas kreita aparta tabelo, kun kiu la laboristo laboras.
Ĉi tio certigas la foreston de transakciaj seruroj inter laboristaj sesioj.
Ĉiu laboristo: faras la samon, per sia propra tablo, la tabloj estas ĉiuj samaj.
Ĉiuj laboristoj faras laboron dum la sama tempodaŭro.
Krome, por sufiĉe longa tempo por ke, ekzemple, protokolo-ŝaltilo nepre okazus, kaj pli ol unufoje.
Nu, sekve, rilataj kostoj kaj efikoj estiĝis.
En mia kazo, mi agordis la daŭron de la laboro de la laboristoj je 8 minutoj.
Peco de statspack-raporto priskribanta la funkciadon de la subdo sub ŝarĝo
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.1Revenante al la laboratoria laboro.
Ni, egale, variigos la valorojn de la sekvaj parametroj de la laboratoria subdatumbazo:
- Grandeco de datumbazaj protokolaj grupoj. valorintervalo: [32, 1024] MB;
- Nombro de ĵurnalaj grupoj en la datumbazo. valorintervalo: [2,32];
log_archive_max_processesvalorintervalo: [1,8];commit_loggingdu valoroj estas permesitaj:batch|immediate;commit_waitdu valoroj estas permesitaj:wait|nowait;log_buffervalorintervalo: [2,128] MB.log_checkpoint_timeoutvalorintervalo: [60,1200] sekundojdb_writer_processesvalorintervalo: [1,4]undo_retentionvalorintervalo: [30;300] sekundojtransactions_per_rollback_segmentvalorintervalo: [1,8]disk_asynch_iodu valoroj estas permesitaj:true|false;filesystemio_optionsla sekvaj valoroj estas permesitaj:none|setall|directIO|asynch;db_block_checkingla sekvaj valoroj estas permesitaj:OFF|LOW|MEDIUM|FULL;db_block_checksumla sekvaj valoroj estas permesitaj:OFF|TYPICAL|FULL;
Persono kun sperto pri prizorgado de Oracle-datumbazoj certe jam povas diri, kion kaj al kiaj valoroj oni devas agordi, el la specifitaj parametroj kaj iliaj akcepteblaj valoroj, por akiri pli grandan produktivecon de la datumbazo por la laboro kun datumoj indikitaj de. la aplika kodo, ĉi tie supre.
Sed.
La celo de la laboratoria laboro estas montri, ke la optimumigo-algoritmo mem klarigos tion al ni relative rapide.
Por ni restas nur rigardi la dokumenton, per la agordebla sistemo, nur sufiĉe por ekscii, kiajn parametrojn ŝanĝi kaj en kiaj intervaloj.
Kaj ankaŭ: kodu la kodon, kiu estos uzata por labori kun la kutima sistemo de la elektita optimumiga algoritmo.
Do, nun pri la kodo.
Mi parolis supre pri cran-r, t.e.: ĉiuj manipuladoj kun la personecigita sistemo estas reĝisoritaj en la formo de R-manuskripto.
La reala tasko, analizo, elekto per metrika valoro, sistemaj statovektoroj: ĉi tio estas pakaĵo GA ()
La pakaĵo, ĉi-kaze, ne estas tre taŭga, en la senco, ke ĝi atendas ke vektoroj (kromosomoj, se laŭ la pakaĵo) estu specifitaj en formo de ĉenoj de nombroj kun frakcia parto.
Kaj mia vektoro, el la valoroj de la agordaj parametroj: ĉi tiuj estas 14 kvantoj - entjeroj kaj kordaj valoroj.
La problemo, kompreneble, estas facile evitita asignante iujn specifajn nombrojn al kordaj valoroj.
Tiel, finfine, la ĉefa peco de la R-skripto aspektas jene:
Voku 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@solutionJen, kun la helpo lower и upper subrutinaj atributoj ga esence, areo de la serĉspaco estas specifita, ene de kiu serĉo estos farita por tia vektoro (aŭ vektoroj) por kiuj la maksimuma valoro de la taŭgeca funkcio estos akirita.
La ga-subrutino faras serĉon maksimumigante la taŭgecan funkcion.
Nu, do rezultas, ke en ĉi tiu kazo, necesas, ke la taŭgeca funkcio, komprenante la vektoron kiel aron de valoroj por iuj parametroj de la subd, ricevas metrikon de la subd.
Tio estas: kiom da, kun donita subd-aranĝo kaj antaŭfiksita ŝarĝo sur la subd: la subd procesas transakciojn je sekundo.
Tio estas, kiam disvolviĝas, la sekva plurpaŝo devas esti farita ene de la taŭgeca funkcio:
- Prilaborado de la eniga vektoro de nombroj - konverti ĝin en valorojn por la subdatumaj parametroj.
- Provo krei antaŭfiksitan nombron da refari grupojn de antaŭfiksita grandeco. Krome, la provo povas esti malsukcesa.
Revuaj grupoj, kiuj jam ekzistis en la subd, en iu kvanto kaj ia grandeco, por la pureco de la eksperimento - d.b. forigita. - Se la antaŭa punkto sukcesas: specifi la valorojn de agordaj parametroj al la datumbazo (denove: povas esti malsukceso)
- Se la antaŭa paŝo sukcesas: ĉesigi la subd, lanĉante la subd por ke la nove specifitaj parametraj valoroj ekvalidu. (denove: eble estas problemo)
- Se la antaŭa paŝo estas sukcesa: faru ŝarĝteston. akiri metrikojn de subd.
- Revenu la subdon al ĝia origina stato, t.e. forigu kromajn protokolgrupojn, resendi la originalan subdatumbazan agordon por funkcii.
Taŭgeca funkciokodo
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)
}Tio. ĉiu laboro: plenumita en la taŭgeca funkcio.
La ga-subrutino prilaboras vektorojn, aŭ, pli ĝuste, kromosomojn.
En kiu, kio plej gravas por ni estas la elekto de kromosomoj kun genoj por kiuj la taŭgeca funkcio produktas grandajn valorojn.
Tio, en esenco, estas la procezo de serĉado de la optimuma aro de kromosomoj uzante vektoron en N-dimensia serĉspaco.
Tre klara, detala , kun ekzemploj de R-kodo, la laboro de genetika algoritmo.
Mi ŝatus aparte noti du teknikajn punktojn.
Helpvokoj de la funkcio evaluate, ekzemple, halto-komenco, fiksante la valoron de la subd parametro, estas faritaj surbaze cran-r funkcioj system2
Kun la helpo de kiu: iu bash-skripto aŭ komando estas vokita.
Ekzemple:
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)
}
}La dua punkto estas la linio, evaluate funkcioj, kun konservado de specifa metrika valoro kaj ĝia ekvivalenta agorda vektoro al protokoldosiero:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Ĉi tio estas grava, ĉar de ĉi tiu datuma tabelo, estos eble akiri pliajn informojn pri kiu el la komponentoj de la agorda vektoro havas pli aŭ malpli grandan efikon al la metrika valoro.
Tio estas: eblos fari atribut-gravan analizon.
Kio do povas okazi?
En grafika formo, se vi ordigas la testojn en suprena metrika ordo, la bildo estas jena:
Iuj datumoj respondaj al la ekstremaj valoroj de la metriko:
Ĉi tie, en la ekrankopio kun la rezultoj, mi klarigos: la valoroj de la agorda vektoro estas donitaj laŭ la taŭgeca funkcio-kodo, ne laŭ la nombrolisto de parametroj/intervaloj de parametraj valoroj, kiu estis formulita. supre en la teksto.
Nu. Ĉu multe aŭ malmulte, ~8 mil tps: aparta demando.
En la kadro de laboratoria laboro, ĉi tiu figuro ne estas grava, kio gravas estas la dinamiko, kiel ĉi tiu valoro ŝanĝiĝas.
La dinamiko ĉi tie estas bona.
Estas evidente ke almenaŭ unu faktoro signife influas la valoron de la metriko, la ga-algoritmo, ordigante tra la kromosomaj vektoroj: kovritaj.
Juĝante laŭ la sufiĉe vigla dinamiko de la kurbaj valoroj, ekzistas almenaŭ unu plia faktoro, kiu, kvankam signife pli malgranda, havas influon.
Jen kie vi bezonas ĝin attribute-importance analizo por kompreni kiajn atributojn (nu, en ĉi tiu kazo, komponantoj de la agorda vektoro) kaj kiom ili influas la metrikan valoron.
Kaj el ĉi tiu informo: komprenu, kiajn faktorojn tuŝis ŝanĝoj en signifaj atributoj.
Ekzekutu attribute-importance ebla en malsamaj manieroj.
Por ĉi tiuj celoj, mi ŝatas la algoritmon randomForest R-pakaĵo de la sama nomo ()
randomForest, kiel mi komprenas lian laboron ĝenerale kaj lian aliron al taksado de la graveco de atributoj aparte, konstruas certan modelon de la dependeco de la respondvariablo sur la atributoj.
En nia kazo, la respondvariablo estas metriko akirita de la datumbazo en ŝarĝtestoj: tps;
Kaj atributoj estas komponantoj de la agorda vektoro.
Do jen randomForest taksas la gravecon de ĉiu modelatributo kun du nombroj: %IncMSE — kiel la ĉeesto/foresto de ĉi tiu atributo en modelo ŝanĝas la MSE-kvaliton de ĉi tiu modelo (Mean Squared Error);
Kaj IncNodePurity estas nombro, kiu reflektas kiom bone, surbaze de la valoroj de ĉi tiu atributo, datumaro kun observoj povas esti dividita, tiel ke en unu parto estas datumoj kun unu valoro de la metriko klarigita, kaj en la alia kun. alia valoro de la metriko.
Nu, tio estas: ĝis kia grado ĉi tio estas klasifika eco (mi vidis la plej klaran, ruslingvan klarigon ĉe RandomForest ).
Laboristo-kamparana R-kodo por prilaborado de datumaro kun la rezultoj de ŝarĝtestoj:
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$importanceVi povas rekte elekti la hiperparametrojn de la algoritmo per viaj manoj kaj, fokusante la kvaliton de la modelo, elekti modelon, kiu pli precize plenumas la antaŭdirojn pri la validiga datumaro.
Vi povas skribi ian funkcion por ĉi tiu laboro (cetere, denove, uzante ian optimumigan algoritmon).
Vi povas uzi R-pakaĵon caret, ne la punkto estas grava.
Kiel rezulto, en ĉi tiu kazo, la sekva rezulto estas akirita por taksi la gradon de graveco de la atributoj:
Nu. Tiel, ni povas komenci tutmondan pripensadon:
- Rezultas, ke la plej signifa, sub ĉi tiuj testaj kondiĉoj, estis la parametro
commit_wait
Teknike, ĝi specifas la ekzekutreĝimon de la io-operacio de skribi refari datumojn de la subdb-registra bufro al la nuna protokolo-grupo: sinkrona aŭ nesinkrona.
valoronowaitkiu rezultas en preskaŭ vertikala, multobla pliiĝo en la valoro de la tps-metriko: tio estas la inkludo de la nesinkrona io-reĝimo en refari grupojn.
Aparta demando estas ĉu aŭ ne vi devus fari tion en manĝdatumbazo. Ĉi tie mi limigas min nur konstati: ĉi tio estas signifa faktoro. - Estas logike, ke la grandeco de la protokolo-bufro de la subd: rezultas esti signifa faktoro.
Ju pli malgranda la grandeco de la ŝtipbufro, des malpli ĝia bufrokapacito, des pli ofte ĝi superfluas kaj/aŭ la malkapablo asigni liberan areon en ĝi por parto de novaj redox-datenoj.
Ĉi tio signifas: prokrastoj asociitaj kun asignado de spaco en la protokolo-bufro kaj/aŭ forĵetado de refari datumoj de ĝi en refari grupojn.
Ĉi tiuj prokrastoj, kompreneble, devus kaj influas la trairon de la datumbazo por transakcioj. - Parametro
db_block_checksum: nu, ankaŭ, ĝenerale estas klare - transakcia prilaborado kondukas al la formado de darty-blokoj en la bufrokaŝmemoro de la subdatumbazo.
Kiu, kiam kontrolado de kontrolsumoj de datumblokoj estas ebligita, la datumbazo devas prilabori - kalkuli tiujn kontrolsumojn el la korpo de la datumbloko, kontrolu ilin per kio estas skribita en la datumbloka kaplinio: kongruas/ne kongruas.
Tia laboro, denove, ne povas ne prokrasti datumtraktadon, kaj sekve, la parametro kaj la mekanismo, kiuj fiksas ĉi tiun parametron, montriĝas signifaj.
Tial la vendisto ofertas, en la dokumentado por ĉi tiu parametro, malsamajn valorojn por ĝi (la parametro) kaj notas, ke jes, estos efiko, sed, nu, vi povas elekti malsamajn valorojn, ĝis "malŝaltita" kaj malsamaj efikoj.
Nu, tutmonda konkludo.
La aliro, ĝenerale, montriĝas sufiĉe funkcia.
Li tute permesas al si, en la fruaj stadioj de ŝarĝo-testado de certa servosistemo, por elekti ĝian (sistemon) optimuman agordon por la ŝarĝo, ne tro enprofundiĝi en la specifaĵoj de agordo de la sistemo por la ŝarĝo.
Sed ĝi ne ekskludas ĝin tute - almenaŭ je la nivelo de kompreno: la sistemo devas esti konata pri la "ĝustigbutoj" kaj la permeseblaj rotaciaj gamoj de ĉi tiuj teniloj.
La aliro tiam povas relative rapide trovi la optimuman sisteman konfiguracion.
Kaj surbaze de la rezultoj de testado, eblas akiri informojn pri la naturo de la rilato inter la sistemaj agado-metrikoj kaj la valoroj de la parametroj de la sistemaj agordoj.
Kiu, kompreneble, devus kontribui al la apero de ĉi tiu tre profunda kompreno de la sistemo, ĝia funkciado, almenaŭ sub donita ŝarĝo.
En praktiko, ĉi tio estas interŝanĝo de la kostoj de kompreno de la personigita sistemo kontraŭ la kostoj de preparado de tia testado de la sistemo.
Mi ŝatus noti aparte: en ĉi tiu aliro, la grado de taŭgeco de sistema testado al la funkciaj kondiĉoj, kiujn ĝi havos en komerca operacio, estas grave grava.
Dankon pro via atento kaj tempo.
fonto: www.habr.com