Bonghjornu
Aghju decisu di sparte a mo scuperta - u fruttu di u pensamentu, a prova è l'errore.
In generale: questu ùn hè micca un scupertu, sicuru - tuttu questu duverebbe esse cunnisciutu per un bellu pezzu, à quelli chì sò implicati in u processu di dati statistichi applicati è ottimisazione di qualsiasi sistemi, micca necessariamente specificamente u DBMS.
È: iè, sanu, scrivenu articuli interessanti nantu à a so ricerca, (UPD.: in i cumenti anu indicatu un prughjettu assai interessante: )
Per d 'altra banda: offhand ùn vecu micca una menzione diffusa o diffusione di stu approcciu in Internet trà i spezialisti IT, DBA.
Allora, à u puntu.
Assumimu chì avemu un compitu: stallà un certu sistema di serviziu per serve un tipu di travagliu.
Hè cunnisciutu di stu travagliu: ciò chì hè, cumu a qualità di stu travagliu hè misurata, è quale hè u criteriu per a misurazione di sta qualità.
Assumimu ancu chì hè più o menu cunnisciutu è capitu: esattamente cumu u travagliu hè realizatu in (o cù) stu sistema di serviziu.
"Più o menu" - questu significa chì hè pussibule di preparà (o uttene da un locu) un certu strumentu, utilità, serviziu chì pò esse sintetizatu è appiicatu à u sistema cù una carica di prova chì hè abbastanza adatta à ciò chì serà in u sistema. pruduzzione, in cundizioni abbastanza adatti per travaglià in a produzzione.
Eppo, supponemu chì un settore di parametri di regulazione per stu sistema di serviziu hè cunnisciutu, chì pò esse usatu per cunfigurà stu sistema in quantu à a produtividade di u so travagliu.
E quale hè u prublema - ùn ci hè micca una cunniscenza abbastanza cumpleta di stu sistema di serviziu, quellu chì vi permette di cunfigurà in modu espertu i paràmetri di stu sistema per carica futura nantu à una determinata piattaforma è uttene a produtividade necessaria di u sistema.
Ebbè. Questu hè quasi sempre u casu.
Chì pudete fà quì ?
Ebbè, a prima cosa chì vene in mente hè di guardà a documentazione di stu sistema. Capisce ciò chì i intervalli accettabili sò per i valori di i paràmetri di aghjustamentu. È, per esempiu, utilizendu u metudu di discendenza di coordenate, selezziunate i valori per i paràmetri di u sistema in teste.
Quelli. dà u sistema un tipu di cunfigurazione, in forma di un set specificu di valori per i so paràmetri di cunfigurazione.
Applicà una carica di prova à questu, utilizendu questu assai strumentu-utilità, generatore di carica.
E fighjate u valore - a risposta, o una metrica di a qualità di u sistema.
U sicondu pensamentu pò esse a cunclusione chì questu hè un tempu assai longu.
Ebbè, questu hè: s'ellu ci sò assai paràmetri di paràmetri, se l'intervalli di i so valori chì sò eseguiti sò grandi, se ogni prova di carica individuale piglia assai tempu per compie, allora: iè, tuttu questu pò piglià un inaccettabile. longu tempu.
Ebbè, quì hè ciò chì pudete capisce è ricurdate.
Pudete scopre chì in u settore di i valori di i paràmetri di u sistema di serviziu di serviziu ci hè un vettore, cum'è una sequenza di qualchi valori.
Ogni tali vettore, altre cose esse uguali (in quantu ùn hè micca affettatu da stu vettore), currisponde à un valore cumpletamente definitu di a metrica - un indicatore di a qualità di u funziunamentu di u sistema sottu una carica di prova.
vale à dì
Denotemu u vettore di cunfigurazione di u sistema cum'è 
induve ; Induve - numeru di paràmetri di cunfigurazione di u sistema, quanti di sti paràmetri ci sò.
È u valore di a metrica chì currisponde à questu denotemu cum'è
, allora avemu una funzione:
Ebbè, allora: tuttu scende immediatamente à, in u mo casu: quasi scurdatu da i mo studianti, algoritmi per a ricerca di l'estremu di una funzione.
Va bè, ma quì nasce una quistione organizativa è applicata: quale algoritmu aduprà.
- In u sensu - cusì chì pudete codificà menu a manu.
- È per u travagliu, i.e. truvò l'estremu (se ci hè unu), bè, almenu più veloce di a discendenza di coordenate.
U primu puntu suggerisce chì avemu bisognu di circà à certi ambienti in quale tali algoritmi sò digià implementati, è sò, in una certa forma, pronti per l'usu in codice.
Ebbè, a so python и cran-r
U sicondu puntu significa chì avete bisognu di leghje nantu à l'algoritmi stessi, ciò chì sò, quale sò e so esigenze, è e caratteristiche di u so travagliu.
È ciò chì dà pò esse utili effetti latu - risultati, o direttamente da l'algoritmu stessu.
O ponu esse ottenuti da i risultati di l'algoritmu.
Assai dipende di e cundizioni di input.
Per esempiu, se, per una certa ragione, avete bisognu di ottene un risultatu più veloce, bè, avete bisognu di circà l'algoritmi di discendenza di gradiente è sceglite unu di elli.
O, se u tempu ùn hè micca cusì impurtante, pudete, per esempiu, utilizà metudi di ottimisazione stochastic, cum'è un algoritmu geneticu.
Proponi di cunsiderà u travagliu di questu approcciu, selezziunate a cunfigurazione di u sistema, utilizendu un algoritmu geneticu, in u prossimu, per dì cusì: travagliu di laboratoriu.
Originale:
- Chì ci sia, cum'è un sistema di serviziu:
oracle xe 18c - Chì serve l'attività transazzione è u scopu: per ottene u più altu throughput pussibule di a subdatabase, in transacciones / sec.
- E transazzione ponu esse assai diffirenti in a natura di travaglià cù dati è u cuntestu di u travagliu.
Accordemu chì questi sò transacciones chì ùn trattanu micca una grande quantità di dati tabulari.
In u sensu chì ùn generanu micca più dati di annullamentu chì redonu è ùn processanu micca grandi percentuali di fila è grande tavule.
Quessi sò transacciones chì cambianu una fila in una tavula più o menu grande, cù un pocu nùmeru d'indici nantu à sta tavula.
In questa situazione: a produtividade di a subdatabase per processà e transazzione serà, cù una riservazione, determinata da a qualità di trasfurmazioni da a basa di dati redox.
Disclaimer - se parlemu specificamente di i paràmetri subdb.
Perchè, in u casu generale, pò esse, per esempiu, chjusi transazzione trà e sessioni SQL, per via di u disignu di u travagliu di l'utilizatori cù dati tabulari è / o u mudellu tabulare.
Chì, sicuru, avarà un effettu deprimente nantu à a metrica TPS è questu serà un fattore esogenu, relative à a subdatabase: bè, questu hè cumu u mudellu tabulare hè statu cuncepitu è u travagliu cù e dati in questu chì i blocchi succedi.
Per quessa, per a purità di l'esperimentu, escluderemu stu fattore, è quì sottu chjarificà esattamente cumu.
- Assumimu, per a definizione, chì 100% di i cumandamenti SQL sottumessi à a basa di dati sò cumandamenti DML.
Chì e caratteristiche di u travagliu di l'utilizatori cù a subdatabase sò listessi in testi.
Vale à dì: u numeru di sessioni skl, dati tabulari, cumu e sessioni skl travaglianu cun elli. - Subd travaglia in
FORCE LOGGING,ARCHIVELOGmods. U modu Flashback-database hè disattivatu, à u livellu subd. - Redo logs: situatu in un sistema di schedari separatu, nantu à un "discu" separatu;
U restu di u cumpunente fisicu di a basa di dati: in un altru sistema di fugliale separatu, nantu à un "discu" separatu:
Più dettagli nantu à u dispusitivu fisicu. cumpunenti di basa di dati di laboratoriu
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 0In principiu, sottu à sti cundizioni di carica, vulia aduprà transazzione subd
Hà una caratteristica cusì maravigliosa, citeraghju l'autore:
À u core di SLOB hè u "metudu SLOB". U Metudu SLOB hà per scopu di pruvà e plataforme
senza contestazione di l'applicazione. Un ùn pò micca guidà u massimu rendimentu hardware
aduprendu u codice di l'applicazione chì hè, per esempiu, ligatu da u bloccu di l'applicazione o ancu
spartera di blocchi di basa di dati Oracle. Hè propiu - ci hè sopratuttu quandu si sparte dati
in blocchi di dati! Ma SLOB - in a so implementazione predeterminata - hè immune à una tale disputa.
Sta dichjarazione : currisponde, hè.
Hè cunvenutu per regulà u gradu di parallelismu di sessioni cl, questu hè a chjave -t lanciari l'utilità runit.sh da SLOB
U percentuale di cumandamenti DML hè regulatu, in u numeru di missaghji di testu chì sò mandati à u subd, ogni sessione di testu, paràmetru UPDATE_PCT
Separatamente è assai convenientu: SLOB stessu, prima è dopu a sessione di carica - prepara un pacchettu di statistiche, o awr snapshots (ciò chì hè stallatu per esse preparatu).
Tuttavia, hè risultatu chì SLOB ùn sustene micca e sessioni SQL cù una durata di menu di 30 seconde.
Per quessa, aghju prima codificatu a mo propria versione, u travagliu-paesano di u caricatore, è dopu hè stata in opera.
Lasciami chjarificà ciò chì u caricatore faci è cumu si fa, per a chiarezza.
Essenzialmente, u caricatore si vede cusì:
codice di u travagliu
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 dotxI travagliadori sò lanciati in questu modu:
I travagliadori in corsa
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"
waitE tavule per i travagliadori sò preparati cusì:
Creazione di tavule
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"Quelli. Per ogni travagliadore (praticamenti: una sessione SQL separata in a DB) una tavola separata hè creata, cù quale u travagliu travaglia.
Questu assicura l'absenza di chjusi transazzione trà e sessioni di u travagliu.
Ogni travagliadore : face a listessa cosa, cù a so propria tavola, e tavule sò tutte listessi.
Tutti i travagliadori facenu u travagliu per u listessu tempu.
Inoltre, per un tempu abbastanza longu per chì, per esempiu, un cambiamentu di logu avaristi sicuramente, è più di una volta.
Eppo, per quessa, i costi è l'effetti assuciati sò ghjunti.
In u mo casu, aghju cunfiguratu a durata di u travagliu di i travagliadori à 8 minuti.
Un pezzu di un rapportu di statspack chì descrive l'operazione di u subd sottu carica
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.1Riturnà à u travagliu di u laboratoriu.
Avemu da altre cose uguali, varià i valori di i seguenti parametri di a basa di dati di u laboratoriu:
- Dimensione di i gruppi di log di basa di dati. intervallu di valori: [32, 1024] MB;
- Numero di gruppi di ghjurnali in a basa di dati. intervallu di valori: [2,32];
log_archive_max_processesintervallu di valori: [1,8];commit_loggingdui valori sò permessi:batch|immediate;commit_waitdui valori sò permessi:wait|nowait;log_bufferintervallu di valori: [2,128] MB.log_checkpoint_timeoutintervallu di valori: [60,1200] secondedb_writer_processesintervallu di valori: [1,4]undo_retentionintervallu di valori: [30;300] secondetransactions_per_rollback_segmentintervallu di valori: [1,8]disk_asynch_iodui valori sò permessi:true|false;filesystemio_optionsi seguenti valori sò permessi:none|setall|directIO|asynch;db_block_checkingi seguenti valori sò permessi:OFF|LOW|MEDIUM|FULL;db_block_checksumi seguenti valori sò permessi:OFF|TYPICAL|FULL;
Una persona cù sperienza in u mantenimentu di basa di dati Oracle pò certamente digià dì ciò chì è à quali valori deve esse stabilitu, da i paràmetri specificati è i so valori accettabili, per ottene una produttività più grande di a basa di dati per u travagliu cù e dati chì hè indicatu da u codice di l'applicazione, quì sopra.
Ma.
U puntu di u travagliu di u laboratoriu hè di dimustrà chì l'algoritmu d'ottimisazione stessu clarificà questu per noi relativamente rapidamente.
Per noi, tuttu ciò chì resta hè di guardà in u documentu, attraversu u sistema persunalizabile, basta à sapè chì paràmetri à cambià è in quale intervalli.
È ancu: codificà u codice chì serà utilizatu per travaglià cù u sistema persunalizatu di l'algoritmu di ottimisazione sceltu.
Allora, avà nantu à u codice.
Aghju parlatu sopra cran-r, vale à dì: tutte e manipulazioni cù u sistema persunalizatu sò orchestrate in a forma di un script R.
U compitu attuale, analisi, selezzione per valore metricu, vettori di u statu di u sistema: questu hè un pacchettu GA ()
U pacchettu, in questu casu, ùn hè micca assai adattatu, in u sensu chì aspetta chì i vettori (cromusomi, se in quantu à u pacchettu) sò specificati in forma di stringhe di numeri cù una parte fraccionaria.
È u mo vettore, da i valori di i paràmetri di paràmetri: questi sò 14 quantità - interi è valori di stringa.
U prublema, sicuru, hè facilmente evitata assignendu certi numeri specifichi à i valori di stringa.
Cusì, à a fine, u pezzu principale di u script R s'assumiglia cusì:
Chjamate 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@solutionQuì, cù l'aiutu lower и upper attributi di subrutina ga essenzialmente, hè specificatu una zona di u spaziu di ricerca, in u quale una ricerca serà realizata per un tali vettore (o vettori) per quale u valore massimu di a funzione di fitness serà ottenuta.
A subrutina ga realiza una ricerca chì maximizeghja a funzione di fitness.
Eppo, allora, risulta chì, in questu casu, hè necessariu chì a funzione di fitness, cumprendendu u vettore cum'è un inseme di valori per certi parametri di u subd, riceve una metrica da u subd.
Questu hè: quantu, cù una cunfigurazione di subd datu è una carica data nantu à u subd: u subd processa transazzione per seconda.
Vale à dì, quandu si sviluppa, i seguenti multi-passu deve esse realizatu in a funzione di fitness:
- Trattamentu di u vettore di input di numeri - cunvertisce in valori per i paràmetri di subdata.
- Un tentativu di creà un certu numaru di gruppi di redotte di una certa dimensione. Inoltre, u tentativu pò esse senza successu.
Gruppi di rivista chì esistenu digià in u subd, in qualchì quantità è di qualchì grandezza, per a purità di l'esperimentu - d.b. sguassatu. - Se u puntu precedente hè successu: specificà i valori di i paràmetri di cunfigurazione à a basa di dati (di novu: pò esse un fallimentu)
- Se u passu precedente hè successu: piantà u subd, cumincendu u subd in modu chì i valori di i paràmetri appena specificati anu effettu. (di novu: pò esse un glitch)
- Se u passu precedente hè successu: fà una prova di carica. uttene metriche da subd.
- Ritorna u subd à u so statu originale, i.e. sguassate i gruppi di log supplementari, rinviate a cunfigurazione di a subdatabase originale per travaglià.
Codice di funzione fitness
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)
}Chì. tuttu u travagliu: realizatu in a funzione fitness.
U ga-subroutine prucessi vettori, o, più currettamente, cromusomi.
In quale, ciò chì hè più impurtante per noi hè a selezzione di cromusomi cù geni per quale a funzione di fitness produce grandi valori.
Questu, in essenza, hè u prucessu di ricerca di u settore ottimali di cromusomi utilizendu un vettore in un spaziu di ricerca N-dimensionale.
Moltu chjaru, detallatu , cù esempi di R-code, u travagliu di un algoritmu geneticu.
Vogliu nutà separatamente dui punti tecnichi.
Chjama ausiliaria da a funzione evaluate, per esempiu, stop-start, stabilisce u valore di u paràmetru subd, sò realizati basatu nantu cran-r funzioni system2
Cù l'aiutu di quale: qualchì script bash o cumanda hè chjamatu.
Per esempiu:
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)
}
}U sicondu puntu hè a linea, evaluate funzioni, cun salvà un valore metricu specificu è u so vettore di sintonizazione currispundente à un schedariu di log:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Questu hè impurtante, perchè da questu array di dati, serà pussibule ottene infurmazioni supplementari nantu à quale di i cumpunenti di u vettore di sintonizazione hà un effettu più grande o menu nantu à u valore metricu.
Questu hè: serà pussibule di fà l'analisi attributu-impurtanza.
Allora chì pò succede?
In forma di graficu, se urdinate e teste in ordine metricu crescente, a stampa hè a siguenti:
Certi dati chì currispondenu à i valori estremi di a metrica:
Eccu, in a screenshot cù i risultati, chjarificu: i valori di u vettore di sintonizazione sò dati in quantu à u codice di a funzione di fitness, micca in quantu à a lista numerica di parametri / intervalli di valori di parametri, chì hè statu formulatu. sopra in u testu.
Ebbè. Hè assai o pocu, ~ 8 mila tps: una quistione separata.
In u quadru di u travagliu di labburatoriu, sta figura ùn hè micca impurtante, ciò chì hè impurtante hè a dinamica, cumu cambia stu valore.
A dinamica quì hè bona.
Hè ovvi chì almenu un fattore influenza significativamente u valore di a metrica, l'algoritmu ga, sortendu à traversu i vettori di cromusomi: coperto.
A ghjudicà da a dinamica abbastanza vigorosa di i valori di a curva, ci hè almenu un fattore più chì, ancu s'ellu hè significativamente più chjucu, hà una influenza.
Questu hè induve avete bisognu attribute-importance analisi per capisce ciò chì attributi (bene, in questu casu, cumpunenti di u vettore di sintonizazione) è quantu influenzanu u valore metricu.
E da questa infurmazione: capisce chì fattori sò stati affettati da cambiamenti in attributi significativi.
Run attribute-importance pussibule in modi diffirenti.
Per questi scopi, mi piace l'algoritmu randomForest pacchettu R di u listessu nome ()
randomForest, cum'è aghju capitu u so travagliu in generale è u so accostu à evaluà l'impurtanza di l'attributi in particulare, custruisce un certu mudellu di a dependenza di a variabile di risposta à l'attributi.
In u nostru casu, a variabile di risposta hè una metrica ottenuta da a basa di dati in teste di carica: tps;
È l'attributi sò cumpunenti di u vettore di sintonizazione.
Allora quì randomForest valuta l'impurtanza di ogni attributu mudellu cù dui numeri: %IncMSE - cumu a presenza / assenza di questu attributu in un mudellu cambia a qualità MSE di stu mudellu (Mean Squared Error);
È IncNodePurity hè un numeru chì riflette quantu bè, basatu annantu à i valori di questu attributu, un inseme di dati cù osservazioni pò esse divisu, in modu chì in una parte ci sò dati cù un valore di a metrica esse spiegata, è in l'altra cù un altru valore di a metrica.
Ebbè, questu hè: in chì puntu hè questu un attributu di classificazione (aghju vistu a spiegazione più chjara, in lingua russa in RandomForest ).
U codice R di u travagliu-paesanu per trasfurmà un set di dati cù i risultati di e teste di carica:
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$importancePudete direttamente selezziunà l'iperparametri di l'algoritmu cù e vostre mani è, cuncintratu nantu à a qualità di u mudellu, selezziunate un mudellu chì cumpre più precisamente e predizioni nantu à u dataset di validazione.
Pudete scrive un tipu di funzione per questu travagliu (per via, di novu, utilizendu un algoritmu di ottimisazione).
Pudete aduprà u pacchettu R caret, micca u puntu hè impurtante.
In u risultatu, in questu casu, u risultatu seguente hè ottenutu per valutà u gradu d'impurtanza di l'attributi:
Ebbè. Cusì, pudemu inizià a riflessione globale:
- Ci hè chì u più significativu, in queste cundizioni di prova, era u paràmetru
commit_wait
Tecnicamente, specifica u modu d'esekzione di l'operazione io di scrittura di redo data da u buffer di log subdb à u gruppu di logu attuale: sincronu o asincronu.
valorenowaitchì risultatu in un casi verticali, multiplicità aumentu di u valore di a metrica tps: questu hè l'inclusione di u modu io asincronu in i gruppi redo.
Una quistione separata hè se duvete fà questu in una basa di dati alimentari. Quì mi limito à dì solu: questu hè un fattore significativu. - Hè logicu chì a dimensione di u buffer di log di u subd: diventa un fattore significativu.
A più chjuca hè a dimensione di u buffer di log, u menu a so capacità di buffering, u più spessu overflows è / o l'incapacità di assignà una zona libera in questu per una parte di novi dati redox.
Questu significa: ritardi assuciati cù l'assignazione di spaziu in u buffer di log è / o dumping dati di redo da ellu in gruppi di redo.
Questi ritardi, sicuru, duveranu è affettanu u throughput di a basa di dati per e transazzione. - Parameter
db_block_checksum: bè, ancu, in generale hè chjaru - u prucessu di transazzione porta à a furmazione di blocchi di darty in u buffer cache di a subdatabase.
Chì, quandu cuntrollà i checksums di datablock hè attivatu, a basa di dati hà da processà - calculate sti checksums da u corpu di u datablock, verificate cù ciò chì hè scrittu in l'intestazione di datablock: matchs/n't match.
Un tali travagliu, di novu, ùn pò micca ritardà u prucessu di dati, è per quessa, u paràmetru è u mecanismu chì stabilisce stu paràmetru diventanu significativu.
Hè per quessa chì u vinditore prupone, in a documentazione per stu paràmetru, diversi valori è nota chì sì, ci sarà un impattu, ma pudete sceglie diversi valori, ancu "off" è sfarenti impatti.
Ebbè, una cunclusione globale.
L'approcciu, in generale, risulta esse abbastanza travagliu.
Hè abbastanza permette, in i primi fasi di a prova di carica di un certu sistema di serviziu, per selezziunà a so cunfigurazione ottimale (sistema) per a carica, per ùn sfondà micca troppu in e specifiche di a stallazione di u sistema per a carica.
Ma ùn l'esclude micca cumplettamente - almenu à u livellu di capiscitura: u sistema deve esse cunnisciutu di i "coppii d'ajustamentu" è i intervalli permissibili di rotazione di questi pomi.
L'approcciu pò dunque truvà relativamente rapidamente a cunfigurazione ottima di u sistema.
È basatu annantu à i risultati di a prova, hè pussibule di ottene infurmazioni nantu à a natura di a relazione trà e metriche di u rendiment di u sistema è i valori di i paràmetri di i paràmetri di u sistema.
Chì, sicuru, deve cuntribuisce à l'emergenza di sta cunniscenza assai prufonda di u sistema, u so funziunamentu, almenu sottu à una carica data.
In pratica, questu hè un scambiu di i costi di capiscenu u sistema persunalizatu per i costi di preparazione di tali teste di u sistema.
Vogliu nutà separatamente: in questu approcciu, u gradu d'adeguatezza di a prova di u sistema à e cundizioni di u funziunamentu chì avarà in l'operazione cummerciale hè criticamente impurtante.
Grazie per a vostra attenzione è u tempu.
Source: www.habr.com