Zdravo
Odlučio sam podijeliti svoje otkriće - plod razmišljanja, pokušaja i grešaka.
Uglavnom: ovo, naravno, nije otkriće – sve je to trebalo odavno znati onima koji se bave primijenjenom statističkom obradom podataka i optimizacijom bilo kojeg sistema, ne nužno konkretno DBMS-a.
I: da, znaju, pišu zanimljive članke o svom istraživanju, (UPD.: u komentarima su istakli veoma zanimljiv projekat: )
S druge strane: beznačajno ne vidim nikakvo rašireno spominjanje ili širenje ovog pristupa na internetu među IT stručnjacima, DBA.
Dakle, na stvar.
Pretpostavimo da imamo zadatak: postaviti određeni uslužni sistem da servisira neku vrstu posla.
O ovom djelu se zna: šta je, kako se mjeri kvalitet ovog rada i koji je kriterij za mjerenje tog kvaliteta.
Pretpostavimo i da je manje-više poznato i shvaćeno: kako se tačno obavlja rad u (ili sa) ovom uslužnom sistemu.
„Manje ili više“ – to znači da je moguće pripremiti (ili ga odnekud nabaviti) određeni alat, uslužni program, uslugu koji se može sintetizirati i primijeniti na sistem sa testnim opterećenjem koje je dovoljno adekvatno onome što će biti u proizvodnji, u uslovima dovoljno adekvatnim za rad u proizvodnji.
Pa, pretpostavimo da je poznat skup parametara podešavanja za ovaj uslužni sistem, koji se mogu koristiti za konfigurisanje ovog sistema u smislu produktivnosti njegovog rada.
I u čemu je problem - ne postoji dovoljno potpuno razumijevanje ovog servisnog sistema, koje vam omogućava da stručno konfigurirate postavke ovog sistema za buduće opterećenje na datoj platformi i dobijete potrebnu produktivnost sistema.
Pa. To je gotovo uvijek slučaj.
sta mozes da radis ovde?
Pa, prvo što vam pada na pamet je da pogledate dokumentaciju za ovaj sistem. Shvatite koji su prihvatljivi rasponi za vrijednosti parametara podešavanja. I, na primjer, koristeći metodu koordinatnog spuštanja, odaberite vrijednosti za sistemske parametre u testovima.
One. dati sistemu neku vrstu konfiguracije, u obliku određenog skupa vrijednosti za njegove konfiguracijske parametre.
Primijenite probno opterećenje na njega, koristeći ovaj alat, generator opterećenja.
I pogledajte vrijednost - odziv, ili metriku kvaliteta sistema.
Druga pomisao može biti zaključak da je ovo jako dugo.
Pa, to jest: ako postoji mnogo parametara podešavanja, ako su rasponi njihovih vrijednosti koje se pokreću veliki, ako je svakom pojedinačnom testu opterećenja potrebno puno vremena da se završi, onda: da, sve ovo može trajati neprihvatljivo dugo vrijeme.
Pa, evo šta možete razumjeti i zapamtiti.
Možete saznati da u skupu vrijednosti parametara postavki servisnog sistema postoji vektor, kao niz nekih vrijednosti.
Svaki takav vektor, uz ostale jednake stvari (u smislu da ovaj vektor ne utiče na njega), odgovara potpuno određenoj metričkoj vrijednosti - pokazatelju kvaliteta rada sistema pod testnim opterećenjem.
Ie
Označimo vektor konfiguracije sistema kao 
gde ; Gdje — broj parametara konfiguracije sistema, koliko ovih parametara postoji.
I vrijednost metrike koja odgovara ovome označimo ga kao
, tada dobijamo funkciju:
Pa, onda: sve se odmah svodi na, u mom slučaju: skoro zaboravljeni iz studentskih dana, algoritmi za traženje ekstrema funkcije.
U redu, ali ovdje se postavlja organizacijsko i primijenjeno pitanje: koji algoritam koristiti.
- U smislu - tako da možete manje kodirati ručno.
- I da bi to funkcioniralo, tj. pronašao ekstrem (ako ga ima), pa, barem brže od koordinatnog spuštanja.
Prva tačka nagovještava da se trebamo osvrnuti na neka okruženja u kojima su takvi algoritmi već implementirani, te su, u nekom obliku, spremni za upotrebu u kodu.
Pa, znam python и cran-r
Druga tačka znači da morate pročitati o samim algoritmima, šta su oni, koji su njihovi zahtjevi i karakteristike njihovog rada.
A ono što daju mogu biti korisne nuspojave - rezultati ili direktno iz samog algoritma.
Ili se mogu dobiti iz rezultata algoritma.
Mnogo zavisi od ulaznih uslova.
Na primjer, ako iz nekog razloga trebate dobiti rezultat brže, pa, morate pogledati prema algoritmima gradijenta spuštanja 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 se rad ovog pristupa, odabirom konfiguracije sistema, korištenjem genetskog algoritma, razmotri u sljedećem, da tako kažem: laboratorijskom radu.
original:
- Neka postoji, kao uslužni sistem:
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 se radi o transakcijama koje ne obrađuju veliku količinu tabelarnih podataka.
U smislu da oni ne generišu više podataka za poništavanje nego redo i ne obrađuju veliki procenat redova i velikih tabela.
To su transakcije koje mijenjaju jedan red u manje ili više velikoj tablici, s malim brojem indeksa u ovoj tablici.
U ovoj situaciji: produktivnost podbaze za obradu transakcija će, uz rezervu, biti određena kvalitetom obrade redoks bazom 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 sa tabelarnim podacima i/ili tabelarnog modela.
Što će, naravno, imati depresivan učinak na TPS metriku i to će biti egzogeni faktor, u odnosu na podbazu podataka: pa, ovako je dizajniran tabelarni model i rad sa podacima u njemu dolazi do blokada.
Stoga ćemo, radi čistoće eksperimenta, isključiti ovaj faktor, a u nastavku ću pojasniti kako.
- Pretpostavimo, radi određenosti, da su 100% SQL naredbi koje se dostavljaju bazi podataka DML naredbe.
Neka karakteristike rada korisnika sa podbazom podataka budu iste u testovima.
Naime: broj skl sesija, tabelarni podaci, kako skl sesije rade sa njima. - Subd radi u
FORCE LOGGING,ARCHIVELOGmods. Režim Flashback-baze podataka je isključen, na nižem nivou. - Redo logs: nalaze se u zasebnom sistemu datoteka, na posebnom “disk”;
Ostatak fizičke komponente baze podataka: u drugom, zasebnom sistemu datoteka, na posebnom „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 uslovima učitavanja, želeo sam da koristim transakciju subd
Ima tako divnu osobinu, citirat ću autora:
U srcu SLOB-a je “SLOB metoda”. SLOB metoda ima za cilj testiranje platformi
bez prepirke za primjenu. Ne može se postići maksimalne performanse hardvera
koristeći kod aplikacije koji je, na primjer, vezan zaključavanjem aplikacije ili čak
dijeljenje blokova Oracle baze podataka. Tako je – postoje troškovi prilikom dijeljenja podataka
u blokovima podataka! Ali SLOB – u svom standardnom rasporedu – je imun na takvu svađu.
Ova izjava: odgovara, jeste.
Pogodno je regulisati stepen paralelizma cl sesija, to je ključ -t pokrenuti uslužni program runit.sh od SLOB
Procenat DML komandi je regulisan, u broju tekstualnih poruka koje se šalju na subd, svakoj tekstualnoj sesiji, parametru UPDATE_PCT
Odvojeno i vrlo povoljno: SLOB sam, prije i nakon sesije učitavanja - priprema statspack, ili awr-snapshots (ono što je postavljeno za pripremu).
Međutim, ispostavilo se da SLOB ne podržava SQL sesije koje traju kraće od 30 sekundi.
Stoga sam prvo kodirao svoju, radničko-seljačku verziju utovarivača, a onda je ostao u funkciji.
Dozvolite mi da pojasnim šta loader radi i kako to radi, radi jasnoće.
U suštini loader izgleda ovako:
Radnička šifra
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 lansiraju na ovaj način:
Radnici koji rade
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 tabele za radnike pripremaju se ovako:
Kreiranje tabela
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"One. Za svakog radnika (praktično: zasebna SQL sesija u DB) kreira se posebna tabela sa kojom radnik radi.
Ovo osigurava odsustvo transakcijskih zaključavanja između sesija radnika.
Svaki radnik: radi istu stvar, sa svojim stolom, stolovi su svi isti.
Svi radnici obavljaju posao u istom vremenu.
Štaviše, dovoljno dugo da bi se, na primjer, log switch definitivno dogodio, i to više puta.
Pa, shodno tome, nastali su povezani troškovi i efekti.
U mom slučaju sam konfigurisao trajanje rada radnika na 8 minuta.
Deo izveštaja statspack-a 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.1Vraćanje na laboratorijske radove.
Mi ćemo, pod istim uslovima, mijenjati vrijednosti sljedećih parametara laboratorijske podbaze:
- 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_loggingdvije vrijednosti su dozvoljene:batch|immediate;commit_waitdvije vrijednosti su dozvoljene: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_iodvije vrijednosti su dozvoljene:true|false;filesystemio_optionsdozvoljene su sljedeće vrijednosti:none|setall|directIO|asynch;db_block_checkingdozvoljene su sljedeće vrijednosti:OFF|LOW|MEDIUM|FULL;db_block_checksumdozvoljene su sljedeće vrijednosti:OFF|TYPICAL|FULL;
Osoba sa iskustvom u održavanju Oracle baza podataka sigurno već može reći šta i na koje vrijednosti treba postaviti, od navedenih parametara i njihovih prihvatljivih vrijednosti, kako bi se postigla veća produktivnost baze podataka za rad sa podacima koji su označeni kod aplikacije, ovdje iznad.
Ali.
Smisao laboratorijskog rada je pokazati da će nam sam algoritam optimizacije to relativno brzo razjasniti.
Nama ostaje samo da pogledamo dokument, kroz prilagodljivi sistem, tek toliko da saznamo koje parametre iu kojim rasponima treba promijeniti.
Takođe: kodirajte kod koji će se koristiti za rad sa prilagođenim sistemom izabranog algoritma optimizacije.
Dakle, sada o kodu.
Govorio sam gore o tome cran-r, tj.: sve manipulacije sa prilagođenim sistemom su orkestrirane u obliku R skripte.
Stvarni zadatak, analiza, odabir prema metričkoj vrijednosti, vektori stanja sistema: ovo je paket GA ()
Paket, u ovom slučaju, nije baš prikladan, u smislu da očekuje da vektori (hromozomi, ako se radi o paketu) budu specificirani u obliku nizova brojeva sa razlomkom.
I moj vektor, od vrijednosti parametara podešavanja: ovo su 14 veličina - cijeli brojevi i vrijednosti niza.
Problem se, naravno, lako može izbjeći dodjeljivanjem određenih brojeva vrijednostima niza.
Dakle, na kraju, glavni dio R skripte izgleda ovako:
Pozovite 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 suštini, specificira se područje prostora za pretraživanje unutar koje će se izvršiti pretraga takvog vektora (ili vektora) za koje će se dobiti maksimalna vrijednost funkcije fitnesa.
Ga potprogram obavlja pretragu maksimizirajući funkciju fitnesa.
Pa, onda, ispada da je u ovom slučaju potrebno da funkcija fitnesa, razumijevajući vektor kao skup vrijednosti za određene parametre subd, primi metriku od subd.
To je: koliko, sa datim podešavanjem subd i datim opterećenjem na subd: subd obrađuje transakcije u sekundi.
Odnosno, prilikom rasklapanja, unutar fitnes funkcije se mora izvesti sljedeći više koraka:
- Obrada ulaznog vektora brojeva - pretvaranje u vrijednosti za parametre podpodataka.
- Pokušaj kreiranja određenog broja redo grupa zadane veličine. Štaviše, pokušaj može biti neuspješan.
Grupe časopisa koje su već postojale u subd, u određenoj količini i neke veličine, radi čistoće eksperimenta - d.b. obrisano. - Ako je prethodna točka uspješna: navođenje vrijednosti konfiguracijskih parametara u bazu podataka (opet: može doći do kvara)
- Ako je prethodni korak uspješan: zaustavljanje subd-a, pokretanje subd-a kako bi novo specificirane vrijednosti parametara stupile na snagu. (opet: možda postoji kvar)
- Ako je prethodni korak uspješan: izvršite test opterećenja. dobiti metriku od subd.
- Vratite subd u prvobitno stanje, tj. obrišite dodatne grupe dnevnika, vratite originalnu konfiguraciju podbaze na rad.
Kod fitness funkcije
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. sav rad: izvodi se u fitnes funkciji.
Ga-podprogram obrađuje vektore, ili, tačnije, hromozome.
Pri čemu nam je najvažniji odabir kromosoma s genima za koje fitnes funkcija proizvodi velike vrijednosti.
Ovo je, u suštini, proces traženja optimalnog skupa hromozoma pomoću vektora u N-dimenzionalnom prostoru pretraživanja.
Vrlo jasno, detaljno , sa primjerima R-koda, rad genetskog algoritma.
Želio bih posebno napomenuti dvije tehničke tačke.
Pomoćni pozivi iz funkcije evaluate, na primjer, stop-start, postavljanje vrijednosti subd parametra, se izvode na osnovu cran-r funkcije system2
Uz pomoć kojih se: poziva neka bash skripta ili naredba.
Na primjer:
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)
}
}Druga tačka je linija, evaluate funkcije, sa spremanjem određene metričke vrijednosti i njenog 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 podešavanja ima veći ili manji utjecaj na metričku vrijednost.
To jest: biće moguće provesti analizu važnosti atributa.
Pa šta se može dogoditi?
U obliku grafikona, ako poredite testove uzlaznim metričkim redoslijedom, slika je sljedeća:
Neki podaci koji odgovaraju ekstremnim vrijednostima metrike:
Ovdje, na snimku ekrana s rezultatima, pojasnit ću: vrijednosti vektora podešavanja su date u smislu koda funkcije fitnesa, a ne u smislu numeričke liste parametara/opsegova vrijednosti parametara, koja je formulirana gore u tekstu.
Pa. Da li je to puno ili malo, ~8 hiljada tps: posebno pitanje.
U okviru laboratorijskog rada ova cifra nije bitna, bitna je dinamika, kako se ta vrijednost mijenja.
Dinamika je ovdje dobra.
Očigledno je da barem jedan faktor značajno utiče na vrijednost metrike, ga-algoritam, sortiranje kroz hromozomske vektore: pokriveno.
Sudeći po prilično snažnoj dinamici vrijednosti krive, postoji barem još jedan faktor koji, iako znatno manji, ima utjecaj.
Ovdje vam treba attribute-importance analizu da bi se razumelo koji atributi (u ovom slučaju, komponente vektora podešavanja) i koliko utiču na metričku vrednost.
I iz ovih informacija: shvatite na koje su faktore utjecale promjene značajnih atributa.
trčanje attribute-importance mogu se raditi na različite načine.
Za ove svrhe mi se sviđa algoritam randomForest R paket istog imena ()
randomForest, kako ja razumijem njegov rad općenito, a posebno njegov pristup procjeni važnosti atributa, gradi određeni model zavisnosti 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 podešavanja.
I tako randomForest procjenjuje važnost svakog atributa modela s dva broja: %IncMSE — kako prisustvo/odsustvo ovog atributa u modelu mijenja MSE kvalitet ovog modela (srednja kvadratna greška);
A IncNodePurity je broj koji odražava koliko dobro, na osnovu vrijednosti ovog atributa, skup podataka sa zapažanjima može biti podijeljen, tako da se u jednom dijelu nalaze podaci s jednom vrijednošću metrike koja se objašnjava, a u drugom sa drugu vrijednost metrike.
Pa, to jest: u kojoj meri je ovo klasifikacioni atribut (video sam najjasnije objašnjenje na ruskom jeziku na RandomForestu ).
Radnik-seljak R-kod za obradu skupa podataka sa 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$importanceSvojim rukama možete direktno odabrati hiperparametre algoritma i, fokusirajući se na kvalitetu modela, odabrati model koji preciznije ispunjava predviđanja na skupu podataka za validaciju.
Možete napisati neku vrstu funkcije za ovaj posao (usput, opet, koristeći neku vrstu optimizacijskog algoritma).
Možete koristiti R paket caret, nije bitna poenta.
Kao rezultat toga, u ovom slučaju, dobije se sljedeći rezultat za procjenu stepena važnosti atributa:
Pa. Dakle, možemo započeti globalnu refleksiju:
- Ispostavilo se da je najznačajniji, u ovim uslovima testiranja, bio parametar
commit_wait
Tehnički, on specificira način izvršavanja io operacije upisivanja podataka o ponavljanju iz subdb log bafera u trenutnu grupu dnevnika: sinhroni ili asinhroni.
vrijednostnowaitšto rezultira gotovo vertikalnim, višestrukim povećanjem vrijednosti tps metrike: ovo je uključivanje asinhronog io moda u redo grupe.
Zasebno pitanje je da li to treba da radite u bazi podataka o hrani. Ovdje se ograničavam samo na konstataciju: ovo je značajan faktor. - Logično je da se veličina bafera dnevnika subd: pokaže kao značajan faktor.
Što je manja veličina bafera dnevnika, manji je njegov kapacitet međuspremnika, češće se on prelijeva i/ili nemogućnost da se u njemu dodijeli slobodna površina za dio novih redoks podataka.
To znači: kašnjenja povezana s dodjelom prostora u baferu dnevnika i/ili izbacivanjem podataka o ponovnom izvršavanju iz njega u redo grupe.
Ova kašnjenja, naravno, treba da utiču i utiču na propusnost baze podataka za transakcije. - Parametar
db_block_checksum: pa, također, općenito je jasno - obrada transakcija dovodi do formiranja blokova darty u kešu bafera podbaze podataka.
Koje, kada je omogućena provjera kontrolnih suma blokova podataka, baza podataka mora obraditi - izračunati ove kontrolne sume iz tijela bloka podataka, provjeriti ih onim što je napisano u zaglavlju bloka podataka: odgovara/ne poklapa se.
Takav rad, opet, ne može a da ne odloži obradu podataka, pa se shodno tome parametar i mehanizam koji postavlja ovaj parametar ispostavlja značajnim.
Zato dobavljač u dokumentaciji za ovaj parametar nudi različite vrijednosti i napominje da da, bit će utjecaja, ali možete odabrati različite vrijednosti, čak i „isključeno“ i različite utjecaje.
Pa, globalni zaključak.
Pristup se, generalno gledano, pokazao prilično funkcionalnim.
On sebi sasvim dozvoljava, u ranim fazama testiranja opterećenja određenog servisnog sistema, da bi odabrao njegovu (sistemsku) optimalnu konfiguraciju za opterećenje, da ne ulazi previše u specifičnosti podešavanja sistema za opterećenje.
Ali to ne isključuje to u potpunosti - barem na nivou razumijevanja: sistem mora biti poznat o "dugmadima za podešavanje" i dozvoljenim rasponima rotacije ovih dugmića.
Pristup tada može relativno brzo pronaći optimalnu konfiguraciju sistema.
A na osnovu rezultata testiranja, moguće je dobiti informacije o prirodi odnosa između metrike performansi sistema i vrijednosti parametara postavki sistema.
Što bi, naravno, trebalo da doprinese nastanku ovog veoma dubokog razumevanja sistema, njegovog rada, barem pod datim opterećenjem.
U praksi, ovo je razmjena troškova razumijevanja prilagođenog sistema za troškove pripreme takvog testiranja sistema.
Napominjem posebno: u ovom pristupu kritično je važan stepen adekvatnosti testiranja sistema radnim uslovima koje će imati u komercijalnom radu.
Hvala vam na pažnji i vremenu.
izvor: www.habr.com