Bok
Odlučio sam podijeliti svoje otkriće - plod razmišljanja, pokušaja i pogrešaka.
Uglavnom: ovo nije otkriće, naravno - sve je to trebalo biti poznato odavno, onima koji se bave primijenjenom statističkom obradom podataka i optimizacijom bilo kojeg sustava, ne nužno konkretno DBMS-a.
I: da, znaju, pišu zanimljive članke o svojim istraživanjima, (UPD.: u komentarima su istaknuli vrlo zanimljiv projekt: )
S druge strane: na brzinu ne vidim nikakvo široko spominjanje ili širenje ovog pristupa na internetu među IT stručnjacima, DBA.
Dakle, na stvar.
Pretpostavimo da imamo zadatak: postaviti određeni servisni sustav za servisiranje neke vrste posla.
O tom djelu se zna: što je, kako se mjeri kvaliteta tog rada i koji je kriterij za mjerenje te kvalitete.
Pretpostavimo također da je više-manje poznato i shvaćeno: kako se točno obavlja rad u (ili s) ovim uslužnim sustavom.
"Manje-više" - to znači da je moguće pripremiti (ili nabaviti odnekud) određeni alat, uslužni program, uslugu koji se može sintetizirati i primijeniti na sustav s testnim opterećenjem dovoljno adekvatnim onome što će biti u proizvodnji, u uvjetima dovoljnim za rad u proizvodnji.
Pa, pretpostavimo da je poznat skup parametara podešavanja za ovaj servisni sustav, koji se mogu koristiti za konfiguraciju ovog sustava u smislu produktivnosti njegovog rada.
I u čemu je problem - ne postoji dovoljno cjelovito razumijevanje ovog uslužnog sustava, ono koje vam omogućuje da stručno konfigurirate postavke ovog sustava za buduće opterećenje na određenoj platformi i dobijete potrebnu produktivnost sustava.
Dobro. To je gotovo uvijek slučaj.
Što možete učiniti ovdje?
Pa, prvo što pada na pamet je pogledati dokumentaciju za ovaj sustav. Shvatite koji su prihvatljivi rasponi za vrijednosti parametara prilagodbe. I, na primjer, koristeći metodu koordinatnog spuštanja, odaberite vrijednosti za parametre sustava u testovima.
Oni. dati sustavu neku vrstu konfiguracije, u obliku određenog skupa vrijednosti za njegove konfiguracijske parametre.
Primijenite probno opterećenje na njega pomoću ovog alata, generatora opterećenja.
I pogledajte vrijednost - odziv, ili metriku kvalitete sustava.
Druga misao može biti zaključak da je to jako dugo vrijeme.
Pa, to jest: ako postoji mnogo parametara za podešavanje, ako su rasponi njihovih pokrivenih vrijednosti veliki, ako je za svaki pojedinačni test opterećenja potrebno puno vremena da se dovrši, tada: da, sve ovo može trajati neprihvatljivo mnogo od vremena.
Pa, evo što možete razumjeti i zapamtiti.
Možete saznati da u skupu vrijednosti parametara postavki servisnog sustava postoji vektor, kao niz nekih vrijednosti.
Svaki takav vektor, pod jednakim uvjetima (utoliko što ovaj vektor na njega ne utječe), odgovara potpuno određenoj metričkoj vrijednosti - pokazatelju kvalitete rada sustava pod testnim opterećenjem.
Oni.
Označimo vektor konfiguracije sustava kao 
Gdje ; Gdje — broj parametara konfiguracije sustava, koliko tih parametara postoji.
I vrijednost metrike koja odgovara ovome označimo to kao
, tada dobivamo funkciju:
Pa onda: sve se odmah svodi na, u mom slučaju: gotovo zaboravljene iz studentskih dana, algoritme za traženje ekstrema funkcije.
U redu, ali ovdje se postavlja jedno organizacijsko i primijenjeno pitanje: koji algoritam koristiti.
- U smislu - da manje možete kodirati ručno.
- A da bi radilo, tj. pronašao ekstrem (ako postoji), dobro, barem brže od koordinatnog spuštanja.
Prva točka nagovještava da moramo gledati prema nekim okruženjima u kojima su takvi algoritmi već implementirani, te su, u nekom obliku, spremni za upotrebu u kodu.
Pa, znam python и cran-r
Druga točka znači da trebate pročitati o samim algoritmima, što su oni, koji su njihovi zahtjevi, značajke njihovog rada.
A ono što daju mogu biti korisne nuspojave – rezultati, ili izravno iz samog algoritma.
Ili se mogu dobiti iz rezultata algoritma.
Puno ovisi o uvjetima unosa.
Na primjer, ako iz nekog razloga trebate brže dobiti rezultat, pa, trebate pogledati prema algoritmima za spuštanje s gradijentom i odabrati jedan od njih.
Ili, ako vrijeme nije toliko važno, možete, na primjer, koristiti metode stohastičke optimizacije, kao što je genetski algoritam.
Predlažem da razmotrimo rad ovog pristupa, odabir konfiguracije sustava, koristeći genetski algoritam, u sljedećem, da tako kažem: laboratorijskom radu.
Izvornik:
- Neka bude, kao sustav usluga:
oracle xe 18c - Neka služi transakcijskoj aktivnosti i cilju: postići najveću moguću propusnost podbaze podataka, u transakcijama/sek.
- Transakcije mogu biti vrlo različite po prirodi rada s podacima i kontekstu rada.
Složimo se da su to transakcije koje ne obrađuju veliku količinu tabličnih podataka.
U smislu da ne generiraju više podataka za poništavanje nego za ponavljanje i ne obrađuju velike postotke redaka i velikih tablica.
To su transakcije koje mijenjaju jedan red u više ili manje velikoj tablici, s malim brojem indeksa na ovoj tablici.
U ovoj situaciji: produktivnost podbaze podataka za obradu transakcija će, uz rezervu, biti određena kvalitetom obrade od strane redoks baze podataka.
Odricanje od odgovornosti - ako govorimo konkretno o postavkama subdb.
Jer, u općem slučaju, može doći do, na primjer, transakcijskih zaključavanja između SQL sesija, zbog dizajna korisničkog rada s tabličnim podacima i/ili tabličnim modelom.
Što će, naravno, imati depresivan učinak na TPS metriku i to će biti egzogeni čimbenik, u odnosu na podbazu podataka: pa, ovako je dizajniran tablični model i rad s podacima u njemu da dolazi do blokada.
Stoga ćemo, radi čistoće eksperimenta, isključiti ovaj faktor, au nastavku ću pojasniti kako točno.
- Pretpostavimo, za sigurnost, da su 100% SQL naredbi poslanih u bazu DML naredbe.
Neka karakteristike rada korisnika s podbazom budu iste u testovima.
Naime: broj skl sesija, tablični podaci, kako skl sesije rade s njima. - Subd radi u
FORCE LOGGING,ARCHIVELOGmodovi. Način flashback-baze podataka je isključen, na subd razini. - Redo zapisnici: nalaze se u zasebnom datotečnom sustavu, na zasebnom “disku”;
Ostatak fizičke komponente baze podataka: u drugom, zasebnom datotečnom sustavu, na zasebnom “disku”:
Više detalja o fizičkom uređaju. komponente laboratorijske baze podataka
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 0U početku, pod ovim uvjetima opterećenja, želio sam upotrijebiti transakcijski subd
Ima tako divnu značajku, citirat ću autora:
Srce SLOB-a je "SLOB metoda". SLOB metoda ima za cilj testiranje platformi
bez prijepora za prijavu. Ne može se postići maksimalna izvedba hardvera
pomoću aplikacijskog koda koji je, primjerice, vezan zaključavanjem aplikacije ili čak
dijeljenje blokova Oracle baze podataka. Tako je - prilikom dijeljenja podataka dolazi do dodatnih troškova
u podatkovnim blokovima! Ali SLOB - u svojoj zadanoj implementaciji - imun je na takve sukobe.
Ova izjava: odgovara, jest.
Prikladno je regulirati stupanj paralelizma cl sesija, to je ključ -t pokrenite uslužni program runit.sh od SLOB
Postotak DML naredbi je reguliran, u broju tekstualnih poruka koje se šalju subd-u, svakoj tekstualnoj sesiji, parametru UPDATE_PCT
Odvojeno i vrlo povoljno: SLOB sam, prije i poslije sesije učitavanja - priprema statspack, ili awr-snapshots (ono što je postavljeno za pripremu).
Međutim, pokazalo se da SLOB ne podržava SQL sesije u trajanju kraćem od 30 sekundi.
Stoga sam prvo kodirao svoju, radničko-seljačku verziju utovarivača, a onda je ostao u pogonu.
Dopustite mi da pojasnim što loader radi i kako to radi, radi jasnoće.
U suštini program za učitavanje izgleda ovako:
Kod radnika
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 dotxRadnici se pokreću na sljedeći način:
Trčanje radnika
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 stolovi za radnike pripremljeni su ovako:
Izrada tablica
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"Oni. Za svakog radnika (praktično: zasebna SQL sesija u DB) kreira se zasebna tablica, s kojom radnik radi.
To osigurava odsutnost transakcijskih zaključavanja između radnih sesija.
Svaki radnik: radi isto, sa svojim stolom, svi su stolovi isti.
Svi radnici obavljaju posao jednako dugo.
Štoviše, dovoljno dugo da bi npr. sigurno došlo do prebacivanja dnevnika, i to više puta.
Pa, sukladno tome, nastali su povezani troškovi i učinci.
U mom slučaju konfigurirao sam trajanje rada radnika na 8 minuta.
Dio izvješća statspacka koji opisuje rad subd-a pod opterećenjem
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.1Povratak na laboratorijski rad.
Mi ćemo, pod istim uvjetima, mijenjati vrijednosti sljedećih parametara laboratorijske podbaze podataka:
- Veličina grupa dnevnika baze podataka. raspon vrijednosti: [32, 1024] MB;
- Broj grupa časopisa u bazi podataka. raspon vrijednosti: [2,32];
log_archive_max_processesraspon vrijednosti: [1,8];commit_loggingdopuštene su dvije vrijednosti:batch|immediate;commit_waitdopuštene su dvije vrijednosti:wait|nowait;log_bufferraspon vrijednosti: [2,128] MB.log_checkpoint_timeoutraspon vrijednosti: [60,1200] sekundidb_writer_processesraspon vrijednosti: [1,4]undo_retentionraspon vrijednosti: [30;300] sekunditransactions_per_rollback_segmentraspon vrijednosti: [1,8]disk_asynch_iodopuštene su dvije vrijednosti:true|false;filesystemio_optionsdopuštene su sljedeće vrijednosti:none|setall|directIO|asynch;db_block_checkingdopuštene su sljedeće vrijednosti:OFF|LOW|MEDIUM|FULL;db_block_checksumdopuštene su sljedeće vrijednosti:OFF|TYPICAL|FULL;
Osoba s iskustvom u održavanju Oracle baza sigurno već sada može reći što i na koje vrijednosti treba postaviti, od navedenih parametara i njihovih prihvatljivih vrijednosti, kako bi se dobila veća produktivnost baze za rad s podacima koji su označeni sa kod aplikacije, ovdje gore.
No.
Smisao laboratorijskog rada je pokazati da će nam sam algoritam optimizacije to relativno brzo razjasniti.
Nama preostaje samo pogledati u dokument, kroz prilagodljivi sustav, tek toliko da saznamo koje parametre mijenjati iu kojim rasponima.
I također: kodirajte kod koji će se koristiti za rad s prilagođenim sustavom odabranog optimizacijskog algoritma.
Dakle, sada o kodu.
Govorio sam gore o cran-r, tj.: sve manipulacije s prilagođenim sustavom orkestrirane su u obliku R skripte.
Stvarni zadatak, analiza, odabir prema metričkoj vrijednosti, vektori stanja sustava: ovo je paket GA ()
Paket, u ovom slučaju, nije baš prikladan, u smislu da očekuje da vektori (kromosomi, ako je riječ o paketu) budu navedeni u obliku nizova brojeva s razlomkom.
I moj vektor, iz vrijednosti parametara postavke: ovo je 14 veličina - cijeli brojevi i vrijednosti niza.
Problem se, naravno, lako može izbjeći dodjeljivanjem nekih specifičnih brojeva vrijednostima nizova.
Dakle, na kraju, glavni dio R skripte izgleda ovako:
Zovite 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@solutionEvo, uz pomoć lower и upper atributi potprograma ga u biti je određeno područje prostora pretraživanja unutar kojeg će se tražiti takav vektor (ili vektori) za koje će se dobiti maksimalna vrijednost funkcije prikladnosti.
Potprogram ga izvodi pretraživanje maksimizirajući funkciju prikladnosti.
Pa, onda se ispostavlja da je, u ovom slučaju, neophodno da funkcija fitnessa, shvaćajući vektor kao skup vrijednosti za određene parametre subd-a, primi metriku od subd-a.
To jest: koliko, s danim postavkama subd-a i danim opterećenjem subd-a: subd obrađuje transakcije u sekundi.
Odnosno, prilikom rasklapanja, sljedeći višestruki korak mora se izvesti unutar funkcije fitnessa:
- Obrada ulaznog vektora brojeva - pretvaranje u vrijednosti za parametre podpodataka.
- Pokušaj stvaranja zadanog broja grupa ponavljanja zadane veličine. Štoviše, pokušaj može biti neuspješan.
Grupe časopisa koje su već postojale u subd, u određenoj količini i određenoj veličini, radi čistoće eksperimenta - d.b. izbrisano. - Ako je prethodna točka uspješna: navođenje vrijednosti konfiguracijskih parametara u bazu podataka (opet: može doći do greške)
- Ako je prethodni korak uspješan: zaustavljanje subd-a, pokretanje subd-a tako da novonavedene vrijednosti parametra stupe na snagu. (opet: možda postoji greška)
- Ako je prethodni korak uspješan: izvršite test opterećenja. dobiti metriku od subd.
- Vratite subd u prvobitno stanje, tj. brisanje dodatnih grupa dnevnika, povratak izvorne konfiguracije podbaze podataka na rad.
Kod funkcije fitnessa
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)
}Da. sav rad: obavlja se u kondicijskoj funkciji.
Ga-potrutina obrađuje vektore, ili, točnije, kromosome.
Pri čemu je, što nam je najvažnije, selekcija kromosoma s genima za koje funkcija fitnessa daje velike vrijednosti.
Ovo je, u biti, proces traženja optimalnog skupa kromosoma pomoću vektora u N-dimenzionalnom prostoru pretraživanja.
Vrlo jasno, detaljno , s primjerima R-koda, rada genetskog algoritma.
Želio bih posebno istaknuti dvije tehničke točke.
Pomoćni pozivi iz funkcije evaluate, na primjer, stop-start, postavljanje vrijednosti parametra subd, izvode se na temelju cran-r funkcije system2
Uz pomoć kojih se: poziva neka bash skripta ili naredba.
Na primjer:
set_db_parametar
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)
}
}Druga točka je linija, evaluate funkcije, sa spremanjem određene metričke vrijednosti i njezinog odgovarajućeg vektora podešavanja u datoteku dnevnika:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Ovo je važno jer će iz ovog niza podataka biti moguće dobiti dodatne informacije o tome koja od komponenti vektora ugađanja ima veći ili manji učinak na metričku vrijednost.
Odnosno: bit će moguće provesti atributno-importamce analizu.
Dakle, što se može dogoditi?
U obliku grafikona, ako poredate testove uzlaznim metričkim redoslijedom, slika je sljedeća:
Neki podaci koji odgovaraju ekstremnim vrijednostima metrike:
Ovdje, na snimci zaslona s rezultatima, pojasnit ću: vrijednosti vektora podešavanja dane su u smislu koda funkcije fitnessa, a ne u smislu popisa brojeva parametara/raspona vrijednosti parametara, koji je formuliran gore u tekstu.
Dobro. Je li to puno ili malo, ~8 tisuća tps: zasebno pitanje.
U okviru laboratorijskog rada ta brojka nije bitna, bitna je dinamika, kako se ta vrijednost mijenja.
Dinamika je ovdje dobra.
Očito je da barem jedan čimbenik značajno utječe na vrijednost metrike, ga-algoritam, razvrstavanje kromosomskih vektora: pokriveno.
Sudeći po prilično snažnoj dinamici vrijednosti krivulje, postoji barem još jedan faktor koji, iako znatno manji, ima utjecaj.
Ovdje vam treba attribute-importance analizu kako biste razumjeli koji atributi (dobro, u ovom slučaju, komponente vektora ugađanja) i koliko utječu na metričku vrijednost.
I iz ovih informacija: shvatite na koje čimbenike su utjecale promjene značajnih atributa.
trčanje attribute-importance moguće na različite načine.
Za ove svrhe, sviđa mi se algoritam randomForest R paket istog imena ()
randomForest, kako razumijem njegov rad općenito i njegov pristup procjeni važnosti atributa posebno, gradi određeni model ovisnosti varijable odgovora o atributima.
U našem slučaju, varijabla odgovora je metrika dobivena iz baze podataka u testovima opterećenja: tps;
A atributi su komponente vektora ugađanja.
Dakle ovdje randomForest procjenjuje važnost svakog atributa modela s dva broja: %IncMSE — kako prisutnost/odsutnost ovog atributa u modelu mijenja MSE kvalitetu ovog modela (srednja kvadratna pogreška);
A IncNodePurity je broj koji odražava koliko se dobro, na temelju vrijednosti ovog atributa, skup podataka s opažanjima može podijeliti, tako da u jednom dijelu postoje podaci s jednom vrijednošću metrike koja se objašnjava, a u drugom s drugu vrijednost metrike.
Pa, to jest: u kojoj je mjeri ovo klasificirajući atribut (vidio sam najjasnije objašnjenje na ruskom jeziku na RandomForestu ).
Radničko-seljački R-kod za obradu skupa podataka s rezultatima testova opterećenja:
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$importanceMožete izravno odabrati hiperparametre algoritma svojim rukama i, usredotočujući se na kvalitetu modela, odabrati model koji točnije ispunjava predviđanja na validacijskom skupu podataka.
Možete napisati neku vrstu funkcije za ovaj rad (usput, opet, koristeći neku vrstu optimizacijskog algoritma).
Možete koristiti R paket caret, nije bitna poanta.
Kao rezultat toga, u ovom slučaju, dobiven je sljedeći rezultat za procjenu stupnja važnosti atributa:
Dobro. Dakle, možemo započeti globalnu refleksiju:
- Ispostavilo se da je najvažniji, u ovim uvjetima testiranja, bio parametar
commit_wait
Tehnički, specificira način izvršenja io operacije pisanja podataka ponavljanja iz međuspremnika dnevnika subdb u trenutnu grupu dnevnika: sinkrono ili asinkrono.
Vrijednostnowaitšto rezultira gotovo okomitim, višestrukim povećanjem vrijednosti tps metrike: to je uključivanje asinkronog io načina rada u redo grupama.
Zasebno je pitanje trebate li to učiniti u bazi podataka o hrani ili ne. Ovdje se ograničavam samo na konstataciju: ovo je značajan faktor. - Logično je da se veličina međuspremnika dnevnika subd: pokazuje kao značajan faktor.
Što je manja veličina međuspremnika zapisa, manji je njegov kapacitet međuspremnika, češće se prelijeva i/ili nemogućnost dodjele slobodnog područja u njemu za dio novih redoks podataka.
To znači: kašnjenja povezana s dodjelom prostora u međuspremniku dnevnika i/ili izbacivanjem podataka o ponavljanju iz njega u grupe za ponavljanje.
Ova kašnjenja bi, naravno, trebala utjecati i utječu na propusnost baze podataka za transakcije. - Parametar
db_block_checksum: pa, također, općenito je jasno - obrada transakcija dovodi do stvaranja blokova darty u međuspremniku podbaze podataka.
Koje, kada je uključena provjera kontrolnih zbrojeva blokova podataka, baza mora obraditi - izračunati te kontrolne zbrojeve iz tijela bloka podataka, provjeriti ih s onim što je napisano u zaglavlju bloka podataka: podudara se/ne podudara se.
Takav rad, opet, ne može a da ne odgodi obradu podataka, pa se u skladu s tim parametar i mehanizam koji postavlja taj parametar pokazuju značajnim.
Zato dobavljač nudi, u dokumentaciji za ovaj parametar, različite vrijednosti za njega (parametar) i napominje da da, bit će utjecaja, ali, dobro, možete odabrati različite vrijednosti, do "isključeno" i različite utjecaje.
Pa, globalni zaključak.
Pristup se, općenito, pokazao prilično učinkovitim.
On si sasvim dopušta da u ranim fazama testiranja opterećenja određenog uslužnog sustava, kako bi odabrao njegovu (sustava) optimalnu konfiguraciju za opterećenje, ne ulazi previše u specifičnosti postavljanja sustava za opterećenje.
Ali ne isključuje ga u potpunosti - barem na razini razumijevanja: sustav mora biti poznat o "gumbima za podešavanje" i dopuštenim rasponima rotacije tih gumba.
Pristup tada može relativno brzo pronaći optimalnu konfiguraciju sustava.
A na temelju rezultata testiranja moguće je dobiti informacije o prirodi odnosa između metrike performansi sustava i vrijednosti parametara postavki sustava.
Što bi, naravno, trebalo pridonijeti nastanku tog vrlo dubokog razumijevanja sustava, njegovog funkcioniranja, barem pod određenim opterećenjem.
U praksi se radi o zamjeni troškova razumijevanja prilagođenog sustava za troškove pripreme takvog testiranja sustava.
Želio bih posebno napomenuti: u ovom pristupu kritično je važan stupanj primjerenosti testiranja sustava radnim uvjetima koje će imati u komercijalnom radu.
Hvala vam na pažnji i vremenu.
Izvor: www.habr.com