Ahoj
Rozhodol som sa podeliť o svoj nález – ovocie myslenia, pokusov a omylov.
Celkovo vzaté: toto samozrejme nie je nález – toto všetko malo byť už dávno známe tým, ktorí sa zaoberajú aplikovaným štatistickým spracovaním údajov a optimalizáciou akýchkoľvek systémov, nie nevyhnutne konkrétne DBMS.
A: áno, vedia, píšu zaujímavé články o svojom výskume, (UPD.: v komentároch upozornili na veľmi zaujímavý projekt: )
Na druhej strane: mimochodom nevidím žiadnu všeobecnú zmienku alebo šírenie tohto prístupu na internete medzi IT špecialistami, DBA.
Takže k veci.
Predpokladajme, že máme úlohu: nastaviť určitý systém služieb na obsluhu nejakého druhu práce.
O tejto práci je známe: čo to je, ako sa meria kvalita tejto práce a aké je kritérium na meranie tejto kvality.
Predpokladajme tiež, že je to viac-menej známe a pochopené: presne ako sa práca vykonáva v (alebo s) týmto servisným systémom.
„Viac-menej“ - to znamená, že je možné pripraviť (alebo získať odniekiaľ) určitý nástroj, pomôcku, službu, ktorú je možné syntetizovať a aplikovať na systém s testovacím zaťažením dostatočne primeraným tomu, čo bude vo výrobe, v podmienkach dostatočne vhodných na prácu vo výrobe.
Predpokladajme, že je známa sada parametrov nastavenia pre tento servisný systém, pomocou ktorých je možné nakonfigurovať tento systém z hľadiska produktivity jeho práce.
A v čom je problém - nie je dostatočne úplné pochopenie tohto servisného systému, ktorý vám umožní odborne nakonfigurovať nastavenia tohto systému pre budúce zaťaženie na danej platforme a získať požadovanú produktivitu systému.
Dobre. Je to tak takmer vždy.
Čo tu môžete robiť?
Prvá vec, ktorá vás napadne, je pozrieť si dokumentáciu k tomuto systému. Pochopte, aké sú prijateľné rozsahy pre hodnoty parametrov nastavenia. A napríklad pomocou metódy zostupu súradníc vyberte hodnoty pre systémové parametre v testoch.
Tie. dať systému nejaký druh konfigurácie vo forme špecifickej sady hodnôt pre jeho konfiguračné parametre.
Aplikujte naň testovacie zaťaženie pomocou tohto nástroja - generátora zaťaženia.
A pozrite sa na hodnotu - odozvu, alebo metriku kvality systému.
Druhou myšlienkou môže byť záver, že je to veľmi dlhá doba.
To znamená: ak existuje veľa parametrov nastavenia, ak sú rozsahy ich spustených hodnôt veľké, ak dokončenie každého jednotlivého záťažového testu trvá veľa času, potom: áno, toto všetko môže trvať neprijateľne dlho.
Tu je to, čo môžete pochopiť a zapamätať si.
Môžete zistiť, že v množine hodnôt parametrov nastavenia servisného systému je vektor ako postupnosť niektorých hodnôt.
Každý takýto vektor, ak sú ostatné veci rovnaké (v tom, že nie je ovplyvnený týmto vektorom), zodpovedá úplne určitej hodnote metriky - indikátoru kvality prevádzky systému pri testovacej záťaži.
Ie
Označme vektor konfigurácie systému ako 
Kde ; Kde — počet parametrov konfigurácie systému, koľko týchto parametrov je.
A tomu zodpovedajúca hodnota metriky označme to ako
, potom dostaneme funkciu:
No, potom: všetko sa okamžite zvrhne na, v mojom prípade: takmer zabudnuté zo študentských čias, algoritmy na hľadanie extrému funkcie.
Dobre, ale tu vyvstáva organizačná a aplikovaná otázka: ktorý algoritmus použiť.
- V zmysle - aby ste mohli menej kódovať ručne.
- A aby to fungovalo, t.j. našiel extrém (ak existuje), no, aspoň rýchlejšie ako súradnicový zostup.
Prvý bod naznačuje, že sa musíme pozrieť na niektoré prostredia, v ktorých už boli takéto algoritmy implementované a sú v určitej forme pripravené na použitie v kóde.
No ja viem python и cran-r
Druhý bod znamená, že si musíte prečítať o samotných algoritmoch, čo sú, aké sú ich požiadavky a vlastnosti ich práce.
A to, čo dávajú, môžu byť užitočné vedľajšie účinky - výsledky alebo priamo zo samotného algoritmu.
Alebo ich možno získať z výsledkov algoritmu.
Veľa závisí od vstupných podmienok.
Napríklad, ak z nejakého dôvodu potrebujete získať výsledok rýchlejšie, musíte sa pozrieť na algoritmy gradientového zostupu a vybrať si jeden z nich.
Alebo, ak čas nie je taký dôležitý, môžete napríklad použiť metódy stochastickej optimalizácie, ako je genetický algoritmus.
Navrhujem zvážiť prácu tohto prístupu, výber konfigurácie systému pomocou genetického algoritmu, v ďalšej, takpovediac, laboratórnej práci.
Originál:
- Nech existuje ako systém služieb:
oracle xe 18c - Nech slúži transakčnej činnosti a cieľu: získať čo najvyššiu priepustnosť subdatabázy, v transakciách/sek.
- Transakcie sa môžu veľmi líšiť v povahe práce s údajmi a kontexte práce.
Dohodnime sa, že ide o transakcie, ktoré nespracúvajú veľké množstvo tabuľkových údajov.
V tom zmysle, že negenerujú viac údajov o vrátení ako o opätovnom vykonaní a nespracúvajú veľké percentá riadkov a veľkých tabuliek.
Ide o transakcie, ktoré menia jeden riadok vo viac-menej veľkej tabuľke s malým počtom indexov v tejto tabuľke.
V tejto situácii: produktivita subdatabázy na spracovanie transakcií bude s výhradou určená kvalitou spracovania redox databázou.
Disclaimer - ak hovoríme konkrétne o nastaveniach subdb.
Pretože vo všeobecnom prípade môže dôjsť napríklad k transakčným zámkom medzi reláciami SQL, kvôli návrhu používateľskej práce s tabuľkovými údajmi a/alebo tabuľkovým modelom.
Čo, samozrejme, bude mať deprimujúci vplyv na metriku TPS a bude to exogénny faktor vzhľadom na subdatabázu: dobre, takto bol navrhnutý tabuľkový model a práca s údajmi v ňom, že dochádza k blokovaniu.
Preto pre čistotu experimentu tento faktor vylúčime a nižšie presne objasním ako.
- Predpokladajme pre istotu, že 100% SQL príkazov odoslaných do databázy sú DML príkazy.
Charakteristiky používateľskej práce s poddatabázou nech sú v testoch rovnaké.
A to: počet skl sedení, tabuľkové údaje, ako s nimi skl sedenia pracujú. - Subd pracuje v
FORCE LOGGING,ARCHIVELOGmods. Režim databázy Flashback je na nižšej úrovni vypnutý. - Redo logs: umiestnené v samostatnom súborovom systéme, na samostatnom „disku“;
Zvyšok fyzického komponentu databázy: v inom, samostatnom súborovom systéme, na samostatnom „disku“:
Ďalšie podrobnosti o fyzickom zariadení. komponenty laboratórnej databázy
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 0Spočiatku som pri týchto podmienkach zaťaženia chcel použiť transakciu subd
Má takú úžasnú vlastnosť, citujem autora:
Základom SLOB je „metóda SLOB“. Metóda SLOB sa zameriava na testovanie platforiem
bez sporu o aplikáciu. Nie je možné dosiahnuť maximálny výkon hardvéru
pomocou kódu aplikácie, ktorý je napríklad viazaný uzamknutím aplikácie alebo dokonca
zdieľanie blokov databázy Oracle. Správne – pri zdieľaní údajov vzniká réžia
v dátových blokoch! Ale SLOB - vo svojom predvolenom nasadení - je imúnny voči takémuto tvrdeniu.
Toto vyhlásenie: zodpovedá, je.
Je vhodné regulovať stupeň paralelizmu cl relácií, to je kľúč -t spustite pomôcku runit.sh od SLOB
Percento príkazov DML je regulované v počte textových správ, ktoré sa odosielajú subd, každá textová relácia, parameter UPDATE_PCT
Samostatne a veľmi pohodlne: SLOB sám, pred a po relácii načítania - pripraví statspack alebo awr-snapshots (čo je nastavené na prípravu).
Ukázalo sa však, že SLOB nepodporuje relácie SQL s trvaním kratším ako 30 sekúnd.
Najprv som si preto nakódoval vlastnú, robotnícko-roľnícku verziu nakladača a potom zostal v prevádzke.
Dovoľte mi objasniť, čo robí nakladač a ako to robí, kvôli prehľadnosti.
V podstate nakladač vyzerá takto:
Kód pracovníka
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 dotxPracovníci sa spúšťajú takto:
Bežiaci pracovníci
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"
waitA stoly pre pracovníkov sú pripravené takto:
Vytváranie tabuliek
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. Pre každého pracovníka (prakticky: samostatná SQL relácia v DB) je vytvorená samostatná tabuľka, s ktorou pracovník pracuje.
To zaisťuje absenciu transakčných zámkov medzi pracovnými reláciami.
Každý pracovník: robí to isté, s vlastným stolom sú všetky stoly rovnaké.
Všetci pracovníci vykonávajú prácu rovnako dlho.
Navyše na dostatočne dlhý čas, aby napríklad k prepínaniu logu určite došlo a viackrát.
V dôsledku toho vznikli súvisiace náklady a efekty.
V mojom prípade som nastavil trvanie práce robotníkov na 8 minút.
Časť zostavy statspack popisujúca činnosť subd pri zaťažení
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.1Návrat k laboratórnej práci.
Za rovnakých okolností budeme meniť hodnoty nasledujúcich parametrov laboratórnej subdatabázy:
- Veľkosť skupín denníkov databázy. rozsah hodnôt: [32, 1024] MB;
- Počet skupín denníkov v databáze. rozsah hodnôt: [2,32];
log_archive_max_processesrozsah hodnôt: [1,8];commit_loggingsú povolené dve hodnoty:batch|immediate;commit_waitsú povolené dve hodnoty:wait|nowait;log_bufferrozsah hodnôt: [2,128] MB.log_checkpoint_timeoutrozsah hodnôt: [60,1200 XNUMX] sekúnddb_writer_processesrozsah hodnôt: [1,4]undo_retentionrozsah hodnôt: [30;300] sekúndtransactions_per_rollback_segmentrozsah hodnôt: [1,8]disk_asynch_iosú povolené dve hodnoty:true|false;filesystemio_optionspovolené sú nasledujúce hodnoty:none|setall|directIO|asynch;db_block_checkingpovolené sú nasledujúce hodnoty:OFF|LOW|MEDIUM|FULL;db_block_checksumpovolené sú nasledujúce hodnoty:OFF|TYPICAL|FULL;
Osoba so skúsenosťami s údržbou databáz Oracle už určite vie povedať, čo a na aké hodnoty by sa malo zo zadaných parametrov a ich prijateľných hodnôt nastaviť, aby sa dosiahla vyššia produktivita databázy pre prácu s údajmi, ktoré sú označené kód aplikácie, tu vyššie.
Ale.
Cieľom laboratórnej práce je ukázať, že samotný optimalizačný algoritmus nám to pomerne rýchlo objasní.
Nám ostáva už len nahliadnuť do dokumentu cez prispôsobiteľný systém, aby sme zistili, aké parametre a v akom rozsahu zmeniť.
A tiež: nakódujte kód, ktorý sa použije na prácu s vlastným systémom zvoleného optimalizačného algoritmu.
Takže teraz o kóde.
Hovoril som o tom vyššie cran-rt.j.: všetky manipulácie s prispôsobeným systémom sú organizované vo forme R skriptu.
Aktuálna úloha, analýza, výber podľa metrickej hodnoty, vektory stavu systému: toto je balík GA ()
Balík v tomto prípade nie je príliš vhodný v tom zmysle, že očakáva, že vektory (chromozómy, ak ide o balík) budú špecifikované vo forme reťazcov čísel s zlomkovou časťou.
A môj vektor z hodnôt parametrov nastavenia: toto je 14 veličín - celé čísla a hodnoty reťazca.
Problému sa, samozrejme, dá ľahko vyhnúť priradením niektorých konkrétnych čísel k hodnotám reťazca.
Nakoniec teda hlavná časť R skriptu vyzerá takto:
Volajte 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@solutionTu, s pomocou lower и upper atribúty podprogramu ga v podstate je špecifikovaná oblasť vyhľadávacieho priestoru, v rámci ktorej sa bude hľadať taký vektor (alebo vektory), pre ktorý sa získa maximálna hodnota fitness funkcie.
Podprogram ga vykonáva vyhľadávanie maximalizujúce funkciu fitness.
Potom sa ukazuje, že v tomto prípade je potrebné, aby funkcia fitness, ktorá chápe vektor ako množinu hodnôt pre určité parametre subd, dostala metriku z subd.
To znamená: koľko, s daným nastavením subd a daným zaťažením subd: subd spracováva transakcie za sekundu.
To znamená, že keď sa rozloží, musí sa v rámci fitness funkcie vykonať nasledujúci viackrokový krok:
- Spracovanie vstupného vektora čísel - jeho prevod na hodnoty parametrov podúdajov.
- Pokus o vytvorenie daného počtu opakovaných skupín danej veľkosti. Okrem toho môže byť pokus neúspešný.
Skupiny časopisov, ktoré už existovali v subd, v určitom množstve a určitej veľkosti, pre čistotu experimentu - d.b. vymazané. - Ak je predchádzajúci bod úspešný: zadanie hodnôt konfiguračných parametrov do databázy (opäť: môže dôjsť k zlyhaniu)
- Ak je predchádzajúci krok úspešný: zastavenie subd, spustenie subd, aby sa prejavili novo špecifikované hodnoty parametrov. (opäť: môže nastať chyba)
- Ak je predchádzajúci krok úspešný: vykonajte záťažový test. získať metriky zo subd.
- Vráťte subd do pôvodného stavu, t.j. odstrániť ďalšie skupiny protokolov, vrátiť pôvodnú konfiguráciu poddatabázy do práce.
Kód fitness funkcie
evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")
opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")
opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
opn$disk_asynch_io="false"
}
opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
opn$filesystemio_options="asynch"
}
opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
opn$db_block_checking="FULL"
}
opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
opn$db_block_checksum="FULL"
}
v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)
rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
return (0)
}
v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) { v_rc=1 }
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("abort")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=run_test()
v_metric=getmetric()
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}To. všetky práce: vykonávané vo funkcii fitness.
Ga-podprogram spracováva vektory, alebo presnejšie, chromozómy.
V ktorých je pre nás najdôležitejší výber chromozómov s génmi, pre ktoré fitness funkcia produkuje veľké hodnoty.
Toto je v podstate proces hľadania optimálnej sady chromozómov pomocou vektora v N-rozmernom vyhľadávacom priestore.
Veľmi prehľadné, podrobné s príkladmi R-kódu, práce genetického algoritmu.
Chcel by som osobitne poznamenať dva technické body.
Pomocné volania z funkcie evaluate, napríklad stop-štart, nastavenie hodnoty parametra subd, sa vykonávajú na základe cran-r funkcie system2
Pomocou čoho: sa volá nejaký bash skript alebo príkaz.
napríklad:
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)
}
}Druhým bodom je čiara, evaluate funkcie s uložením špecifickej hodnoty metriky a jej zodpovedajúceho ladiaceho vektora do súboru denníka:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Je to dôležité, pretože z tohto dátového poľa bude možné získať ďalšie informácie o tom, ktorá zo zložiek ladiaceho vektora má väčší alebo menší vplyv na metrickú hodnotu.
To znamená: bude možné vykonať analýzu atribútov a importu.
Čo sa teda môže stať?
Ak vo forme grafu zoradíte testy vo vzostupnom metrickom poradí, obrázok je takýto:
Niektoré údaje zodpovedajúce extrémnym hodnotám metriky:
Tu, na snímke obrazovky s výsledkami, objasním: hodnoty ladiaceho vektora sú uvedené v zmysle kódu fitness funkcie, nie v zmysle číselného zoznamu parametrov/rozsahov hodnôt parametrov, ktorý bol formulovaný vyššie v texte.
Dobre. Je to veľa alebo málo, ~ 8 tisíc tps: samostatná otázka.
V rámci laboratórnych prác tento údaj nie je dôležitý, dôležitá je dynamika, ako sa táto hodnota mení.
Dynamika je tu dobrá.
Je zrejmé, že minimálne jeden faktor významne ovplyvňuje hodnotu metriky, ga-algoritmus, triedenie cez chromozómové vektory: pokryté.
Súdiac podľa pomerne silnej dynamiky hodnôt kriviek, je tu ešte aspoň jeden faktor, ktorý, aj keď je výrazne menší, má vplyv.
Tu to potrebujete attribute-importance analýzu, aby ste pochopili, aké atribúty (v tomto prípade zložky ladiaceho vektora) a do akej miery ovplyvňujú metrickú hodnotu.
A z týchto informácií: pochopiť, aké faktory boli ovplyvnené zmenami významných atribútov.
beh attribute-importance možno vykonať rôznymi spôsobmi.
Pre tieto účely sa mi páči algoritmus randomForest R balík s rovnakým názvom ()
randomForest, keďže chápem jeho prácu vo všeobecnosti a najmä jeho prístup k posudzovaniu dôležitosti atribútov, buduje určitý model závislosti premennej odpovede od atribútov.
V našom prípade je premenná odozvy metrikou získanou z databázy v záťažových testoch: tps;
A atribúty sú komponentmi ladiaceho vektora.
Tak tu randomForest vyhodnotí dôležitosť každého atribútu modelu dvoma číslami: %IncMSE — ako prítomnosť/neprítomnosť tohto atribútu v modeli mení kvalitu MSE tohto modelu (stredná štvorcová chyba);
A IncNodePurity je číslo, ktoré vyjadruje, ako dobre možno na základe hodnôt tohto atribútu rozdeliť množinu údajov s pozorovaniami tak, že v jednej časti sú údaje s jednou vysvetlenou hodnotou metriky a v druhej s inú hodnotu metriky.
Teda, do akej miery je to klasifikačný atribút (najjasnejšie vysvetlenie v ruskom jazyku som videl na RandomForest ).
Robotnícko-roľnícky R-kód na spracovanie súboru údajov s výsledkami záťažových testov:
x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')
idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]
library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importanceMôžete priamo vybrať hyperparametre algoritmu rukami a so zameraním na kvalitu modelu vybrať model, ktorý presnejšie spĺňa predpovede na overovacom súbore údajov.
Pre túto prácu môžete napísať nejakú funkciu (mimochodom, opäť pomocou nejakého optimalizačného algoritmu).
Môžete použiť balík R caret, nie je dôležitá pointa.
V dôsledku toho sa v tomto prípade získa nasledujúci výsledok na posúdenie stupňa dôležitosti atribútov:
Dobre. Môžeme teda začať globálnu reflexiu:
- Ukazuje sa, že najvýznamnejší bol pri týchto testovacích podmienkach parameter
commit_wait
Technicky špecifikuje režim vykonávania operácie io zápisu redo údajov z vyrovnávacej pamäte protokolu subdb do aktuálnej skupiny protokolov: synchrónny alebo asynchrónny.
Hodnotanowaitčo má za následok takmer vertikálne, viacnásobné zvýšenie hodnoty metriky tps: ide o zahrnutie asynchrónneho režimu io do skupín redo.
Samostatnou otázkou je, či by ste to mali alebo nemali robiť v databáze potravín. Tu sa obmedzím len na konštatovanie: toto je významný faktor. - Je logické, že veľkosť vyrovnávacej pamäte protokolu subd: sa ukazuje ako významný faktor.
Čím menšia je veľkosť vyrovnávacej pamäte protokolu, tým menšia je jej kapacita vyrovnávacej pamäte, tým častejšie dochádza k pretečeniu a/alebo nemožnosti vyčleniť v nej voľnú oblasť pre časť nových redoxných údajov.
To znamená: oneskorenia spojené s prideľovaním priestoru vo vyrovnávacej pamäti protokolu a/alebo ukladaním údajov o opakovaní z nej do skupín opakovania.
Tieto oneskorenia by, samozrejme, mali a ovplyvňujú priepustnosť databázy pre transakcie. - Parameter
db_block_checksum: vo všeobecnosti je to jasné - spracovanie transakcií vedie k vytvoreniu darty blokov vo vyrovnávacej pamäti subdatabázy.
Ktoré, keď je povolená kontrola kontrolných súčtov datablokov, musí databáza spracovať - tieto kontrolné súčty vypočítať z tela databloku, skontrolovať ich podľa toho, čo je napísané v hlavičke databloku: zhoduje sa/nezhoduje sa.
Takáto práca opäť nemôže oddialiť spracovanie údajov, a preto sa parameter a mechanizmus, ktorý tento parameter nastavuje, ukazujú ako významné.
Preto predajca ponúka v dokumentácii pre tento parameter rôzne hodnoty pre tento parameter (parameter) a poznamenáva, že áno, bude to mať vplyv, ale môžete si vybrať rôzne hodnoty, až po „vypnuté“ a rôzne dopady.
No, globálny záver.
Tento prístup sa vo všeobecnosti ukazuje ako celkom funkčný.
V počiatočných fázach testovania záťaže určitého servisného systému si celkom dovoľuje vybrať jeho (systémovú) optimálnu konfiguráciu pre záťaž, neponárať sa príliš do špecifík nastavenia systému pre záťaž.
Nevylučuje to však úplne - aspoň na úrovni chápania: systém musí byť známy o „nastavovacích gombíkoch“ a prípustných rozsahoch otáčania týchto gombíkov.
Prístup potom dokáže pomerne rýchlo nájsť optimálnu konfiguráciu systému.
A na základe výsledkov testovania je možné získať informácie o povahe vzťahu medzi metrikami výkonu systému a hodnotami parametrov nastavenia systému.
Čo by, samozrejme, malo prispieť k vzniku tohto veľmi hlbokého pochopenia systému, jeho fungovania, aspoň pri danej záťaži.
V praxi ide o výmenu nákladov na pochopenie prispôsobeného systému za náklady na prípravu takéhoto testovania systému.
Samostatne by som chcel poznamenať: v tomto prístupe je kriticky dôležitý stupeň primeranosti testovania systému k prevádzkovým podmienkam, ktoré bude mať v komerčnej prevádzke.
Ďakujem za pozornosť a čas.
Zdroj: hab.com