🥇Teadusliku katsetamise meetod, või kuidas valida andmebaasi konfiguratsioon bänšmarkide ja optimeerimisalgoritmi abil

Tere.

Otsustasin jagada oma leid, mõtetes, katsetes ja vigades sündinud vilja.
Aga suuresti: see ei ole mingi leid, muidugi — see peaks olema ammu teada neile, kes tegelevad rakendusliku andmete töötlemise ja mingi süsteemi, mitte tingimata andmebaasi, optimeerimisega.
Ja: jah, nad teavad, kirjutavad huvitavaid artikleid oma uurimistöödest, näide (UPD.: kommentaarides viidati väga huvitavale projektile: ottertune )
Teiselt poolt: esmapilgul ei tundu, et sellist lähenemist oleks internetis, IT-spetsialistide seas, laialdaselt mainitud või levinud.

Nii et, asja tuum.

Oletame, et meil on ülesanne: seadistada mingi teenussüsteem, et teenindada mingit tööd.

Selle töö kohta — on teada: milline see on, milles mõõdetakse selle töö kvaliteeti ja milline on kvaliteedi mõõtmisnäitaja.

Samuti oletame, et enam-vähem on teada, kuidas töö sellise teenussüsteemiga toimub (või milles see toimub).

"Enam-vähem" — see tähendab, et on võimalik ette valmistada (või kuskilt hankida) mingi tööriista, utiliidi, teenuse, millega saab sünteesida ja esitada süsteemile testkoormuse, mis on piisavalt adekvaatne sellele, mis toimub tootmises, piisavalt adekvaatsetes tingimustes tootmises.

Noh ja oletame, et on teada selle teenussüsteemi reguleeritavate parameetrite kogum, millega saab seda süsteemi seadistada, mõttes selle töö efektiivsust.

Ja probleem on selles — ei ole piisavalt täielikku arusaamist sellest teenussüsteemist, mis võimaldaks eksperdina seadistada selle süsteemi koormuse jaoks, antud platvormil ja saavutada vajaliku süsteemi töö efektiivsus.

Noh. Nii see peaaegu alati on.

Mis siin teha saab.

Noh, esimene mõte, mis tuleb meelde: piiluda selle süsteemi dokumentatsiooni. Mõista — millised seal on lubatud vahemikud reguleeritavate parameetrite väärtustele. Ja näiteks, koordinaatide laskumise meetodil, sobitada parameetrite väärtusi testides.

T.e. seadistada süsteemile mingi konfiguratsioon, konkreetsete väärtuste komplektina selle seadistamisparameetrite kohta.

Esitada sellele testkoormus, selle tööriista-utiliidi, koormuse generaatori abil.
Ja vaadata väärtust — vastust, noh või süsteemi töö kvaliteedi mõõdik.

Teine mõte võiks olla järeldus, et — see on ju väga ajamahukas.

Noh, see tähendab: kui seadistamise parameetreid on palju, kui nende väärtuste läbimise vahemikud on suured, kui iga eraldi koormustesti täidetakse kaua aega, siis: jah, see kõik võib võtta ebanormaalselt palju aega.

Noh ja siin on, mida saab mõista ja meenutada.

Saab teada, et teenuse süsteemi seadistusparameetrite väärtuste komplektis on vektor, mis on mingite väärtuste järjestus.

Iga sellise vektori puhul, kui kõik muud aspektid on võrdsed (kui see vektor ei mõjuta), vastab sellele kindlasti määratud mõõdik — süsteemi töö kvaliteedi näitaja koormustesti all.

St.

Määrame süsteemi konfiguratsiooni vektori kui , kus ; Kus on süsteemi konfiguratsiooni parameetrite arv.

Ja mõõdiku väärtus, mis vastab sellele määra kui
, siis saame funktsiooni:

Noh ja siis: kõik vähendab tagasi, minu puhul: peaaegu unustatud ülikooli pingilt, funktsiooni äärmuste otsimise algoritmid.

Hästi, aga siin tekib organisatsiooniline ja praktiline küsimus: millist konkreetselt algoritmi kasutada.

Mõttes — et ise vähem koodi kirjutada.
Ja et see töötaks, st et leiaks äärmuse (kui see on olemas), noh, vähemalt — kiiremini kui koordinaatide langus.

Esimene punkt viitab sellele, et tuleb vaadata selliste keskkondade poole, kus sellised algoritmid on juba rakendatud ja olemas mingis vormis, valmis koodis kasutamiseks.
Noh, mulle on teada python ja cran-r

Teine punkt tähendab, et tuleb lugeda tegelikult algoritmide kohta, millised need on, millised on nende nõuded, töö eripärad.

Ja mida need annavad, võivad olla kasulikud kõrvalmõjud - tulemused, kas otseselt, algoritmist endast.

Või need võivad tulla algoritmi töö tulemustest.

Siin sõltub palju sisetingimustest.

Näiteks, kui mingitel põhjustel tuleb tulemust kiiremini saada, noh, tuleb vaadata gradientide languse algoritmide poole, valida mõni neist.

Või, kui aeg ei ole nii oluline, võib näiteks kasutada stohhastilise optimeerimise meetodeid, nagu geneetiline algoritm.

Pakun vaadata sellise lähenemise tööd, süsteemi konfiguratsiooni valiku osas, geneetilise algoritmi kasutamisega, järgmisel, nii-öelda: laboris.

Algandmed:

Olgu see nii, kui teenindussüsteem: oracle xe 18c
Olgu selle eesmärk: saada võimalikult suur andmebaasi läbilaskvus tehingute/sek.
Tehingud on oma olemuselt ja andmete töötlemise kontekstis väga erinevad.
Kokkuleppel on need tehingud, mis ei töötle suures mahus tabeliandmeid.
Selle all mõtleme, et need ei genereeri kinnitusandeid rohkem kui taastamisandeid ega töödelda suurt protsenti ridade, suurte tabelite hulgast.

Need on tehingud, mis muudavad ühte rida enam-vähem suures tabelis, millel on vähe indekseid üle selle tabeli.

Sellisel juhul määrab andmebaasi produktiivsus tehingute töötlemisel, tingimusel, kvaliteedi taastamisandmete töötlemise poolt.

Kvaliteet - kui arvestada täpselt andmebaasi seadistuste kontekstis.

Sest üldiselt võivad esineda näiteks tehingu lukustused, SQL-seansside vahel, olenevalt kasutajate töö tehingute andmetega ja/või tabeli mudeliga.

Need mõjutavad kindlasti tps-mõõtmist ja see on eksogeenine, andmebaasi suhtes, tegur: nii on tabeli mudel ja andmetöötlus üles ehitatud, et tekivad lukustused.

Seetõttu välistame eksperimentaalselt selle teguri, selgitame allpool, kuidas täpselt.

Oletame, et kahtlusteta, et 100% andmebaasi edastatud SQL-käskudest: on DML-käskud.
Olgu andmebaasi kasutajate töö omadused: samad, testides.
Nimelt: SQL-seansside arv, tabeliandmed, see, kuidas SQL-seanssid nendega töötavad.
Andmebaas töötab FORCE LOGGING, ARCHIVELOG režiimides. Flashback-andmebaasi režiim on keelatud andmebaasi tasemel.
Taastamislogid: asuvad eraldi failisüsteemis, eraldi "ketasel";
Kogu ülejäänud füüsiline andmebaasi komponent: on teises, eraldi FS-is, eraldi "ketasel":

Rohkem teavet labori andmebaasi füüsilise komponendi seadmest

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 0

Alguses soovisin kasutada seda andmebaasi, et jõuda nende koormustingimusteni. SLOB eesmärk
Sellel on selline tähelepanuväärne omadus, tsiteerin autorit:

SLOBi keskmes on "SLOB meetod". SLOB meetodi eesmärk on testida platvorme
ilma rakenduse konfliktita. Maksimaalset riistvara jõudlust ei saa saavutada
rakenduskoodiga, mis näiteks sõltub rakenduse lukustamisest või isegi
Oracle Database'i plokkide jagamisest. Just nii – andmeblokki jagamisel on ülevaade!
Kuid SLOB – oma vaikimisi seadistuses – on selliste konfliktide suhtes immuunne.

See väide: vastab tõele.
Mugav on reguleerida paralleelsuse taset SQL-sessioonides, see on peamine -t utility käivitus runit.sh SLOB-i komplektist
Reguleeritakse DML-käskude protsent, milles SQL-sessioonid saadavad andmebaasi, iga SQL-sessiooni parameeter UPDATE_PCT
Eraldi ja väga mugav: SLOB ise valmistab enne ja pärast koormuse seanssi statsparimaid või AWR-lõike (kui on määratud ette valmistada).

Kuid selgus, et SLOB ei toeta SQL-sessioonide töötamist, mille pikkus on alla 30 sekundi.
Seetõttu programmeerisin esmalt oma versiooni koormustestijast, mis jäi tööle.

Selgitan koormustesti kohta — mida ja kuidas see teeb, et oleks selgem.
Tegelikult näeb koormustestija välja järgmiselt:

Töötaja kood

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;
\/\n
exit
__EOF__
}
export -f dotx

Töötajaid käivitatakse järgmiselt:

Töötajate käivitus

echo "alguse test, kestus: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i> "$v_logfile"
 dotx "$i" "${TEST_DURATION}" &
done
echo "ootamist oodatakse..." >> "$v_logfile"
wait

Ja töötajate tabelid valmistatakse nii:

Tabelite loomine

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;
\/\n
create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum> "$v_logfile"

See tähendab, et iga töötaja (peaaegu: eraldi SQL-seanss andmebaasis) loob eraldi tabeli, millega töötaja töötab.

Sellega saavutatakse tehingute lukustamise puudumine, töötajate SQL-seansside vahel.
Iga töötaja: teeb sama, oma tabeliga, kõik tabelid on identsed.
Kõik töötajad teevad tööd sama aja jooksul.
Ja seejuures piisavalt pika aja, et näiteks kindlasti toimuks ja mitte üks kord logi vahetus.
Noh ja vastavalt tekivad sellega seotud kulutused ja efektid.
Minu puhul olen seadnud töötajate töö kestuse 8 minutiks.

Tükk statspak-aruandest, koos kirjeldustega andmebaasi töö kohta koormuse all.

Andmebaas    DB Id    Instants     Inst Num  Käivitamise aeg   Vabastus     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          2929910313 XE                  1 07-Sep-20 23:12 18.0.0.0.0  EI

Hosti nimi             Platvorm                CPU-d Cores Pesa   Mälu (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     billing.izhevsk1 Linux x86 64-bit           2     2       1         15.6

Kuvatõmmis       Snap Id     Snap Aeg      Sessioonid Curs/Sess Kommentaar
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Alusta Snap:       1630 07-Sep-20 23:12:27       55        .7
  Lõpeta Snap:       1631 07-Sep-20 23:20:29       62        .6
   Aeg:       8.03 (min) Keskmine aktiivne sessioon:       8.4
   DB aeg:      67.31 (min)      DB CPU:      15.01 (min)

Vahemälu suurused            Algus        Lõpp
~~~~~~~~~~~       ---------- ----------
    Puhvermälu:     1,392M              Std Block Size:         8K
     Jagatud bassein:       288M                  Logi puhvrimälu:   103,424K

Koormuse profiil              Sekundi kaupa    Tehingu kaupa    Täitmise kaupa    Kõne kaupa
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB aeg(d):                8.4                0.0        0.00        0.20
       DB CPU(d):                1.9                0.0        0.00        0.04
       Redo suurus:        7,685,765.6              978.4
   Loogilised lugemised:           60,447.0                7.7
   Ploki muutmised:           47,167.3                6.0
  Füüsilised lugemised:                8.3                0.0
 Füüsilised kirjutised:              253.4                0.0
      Kasutaja kõned:               42.6                0.0
          Parsee:               23.2                0.0
     Raske parse:                1.2                0.0
W/A MB töödeldud:                1.0                0.0
          Logimine:                0.5                0.0
        Täitmine:           15,756.5                2.0
       Tagasivõtmised:                0.0                0.0
    Tehingud:            7,855.1

Naastes labori töö määratlemise juurde.
Vaatame, et võrdselt, varieerida selliste laboratoorsete DB parameetrite väärtusi:

Andmebaasi logigruppide suurus. väärtuste vahemik: [32, 1024] MB;
Logigruppide arv. väärtuste vahemik: [2,32];
log_archive_max_processes väärtuste vahemik: [1,8];
commit_logging lubatud on kaks väärtust: batch|immediate;
commit_wait lubatud on kaks väärtust: wait|nowait;
log_buffer väärtuste vahemik: [2,128] MB.
log_checkpoint_timeout väärtuste vahemik: [60,1200] sekundit
db_writer_processes väärtuste vahemik: [1,4]
undo_retention väärtuste vahemik: [30;300] sekundit
transactions_per_rollback_segment väärtuste vahemik: [1,8]
disk_asynch_io lubatud on kaks väärtust: true|false;
filesystemio_options lubatud on järgmised väärtused: none|setall|directIO|asynch;
db_block_checking lubatud on järgmised väärtused: OFF|LOW|MEDIUM|FULL;
db_block_checksum lubatud on järgmised väärtused: OFF|TYPICAL|FULL;

Inimene, kellel on kogemus oracle-andmebaaside hooldamises, oskab kindlasti juba praegu öelda — milliseid ja milliseid väärtusi seada, antud parameetrite ja nende lubatud väärtuste seast, et saavutada suuremat andmebaasi tootlikkust, vastavalt siia, ülal toodud, rakenduskoodiga määratletud andmetöötlusele.

Aga.

Laboratoorse töö mõte on näidata, et optimeerimisalgoritm ise ning ka suhteliselt kiiresti selgub meile.

Meil jääb vaid vaadata dokumentatsiooni, muudetava süsteemi kohta, täpselt niipalju, kui vajalik, et välja selgitada: milliseid parameetreid ja millistes vahemikes muuta.
Ja samuti: kodeerida kood, millega rakendatakse valitud optimeerimisalgoritmi muudetava süsteemiga töötamist.

Nii et nüüd koodist.
Ülal mainisin cran-r, st: kõik manipuleerimised muudetava süsteemiga - orkestreeritakse R-skriptina.

Tegelikult on ülesanne, analüüs, parameetrite väärtuste valik, süsteemi olekute vektorid: see on paket. GA (dokumentatsioon)
Pakett, antud juhul, ei sobi väga hästi, kuna see ootab vektorite (kromosoomide, kui kasutada paketi termineid) määramist nagu reaalarvud, mis sisaldavad koma.

Ja minu vektor, seadistuste parameetrite väärtustest: see on 14 väärtust - täisarvud ja stringiväärtused.

Probleem, muidugi, kergesti lahendatakse, määrates stringiväärtustele teatud numbrid.

Nii et lõpuks, peamine R-skripti osa näeb välja selline:

Kutsu 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@solution

Siin, abiga lower ja upper alprogrammi atribuudid ga määratakse sisuliselt otsinguruumi ala, mille sees otsitakse vektorit (või vektoreid), mille jaoks saavutatakse maksimaalne fitness-funktsiooni väärtus.

ga-algoritm teostab otsingu maksimeerides fitness-funktsiooni.

Nii et, tulemuseks on see, et antud juhul peab olema nii, et fitness-funktsioon, mõistes vektorit kui teatud parameetrite väärtuste kogumit andmebaasi jaoks, saab mõõdikuks andmebaasi kohta.

St: kui palju, antud andmebaasi seadistuse ja antud andmebaasi koormuse korral: andmebaas töötleb tehinguid sekundis.

St, lahtiselt öeldes, on vajalik, et fitness-funktsiooni sees toimuks selline mitmeastmeline protsess:

Sisendi numbrivektori töötlemine - selle muutmine andmebaasi parameetrite väärtusteks.
Katse luua soovitud arvu redo-gruppe, soovitud suurusega. Ja katse: võib ebaõnnestuda.
Juba eksisteeritud andmebaasi ajakirjade grupid, mingis koguses ja mingis suuruses, eksperimentide puhtuse huvides - tuleb eemaldada.
Kui eelmine punkt õnnestus: määrata konfiguratsiooniparametrite väärtuste andmebaas (jällegi: võib esineda rike).
Kui eelmine punkt õnnestus: peatada andmebaas, käivitada andmebaas, et uuesti määratud parameetrite väärtused hakkaksid kehtima. (jällegi: võib esineda rike).
Kui eelmine punkt õnnestus: teostada koormustest, et saada mõõdikut andmebaasilt.
Tagastada andmebaas algsesse olekusse, s.t. eemaldada täiendavad ajakirjade grupid, taastada andmebaasi algne konfiguratsioon.

Funktsiooni koodi 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 && 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 && 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="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)
}

Seega, kogu töö: toimub fitness-funktsiooni raames.

ga-alamprogramm, teostab vektoreid või, täpsemalt öeldes - kromosoome.
Kus on meile kõige olulisem: kromosoomide selektsioon, mille geenid annavad fitness-funktsiooni suured väärtused.

See on sisuliselt protsess optimaalse kromosoomide kogumi otsimisel vektorina N-dimensionaalses otsinguruumis.

Väga selge, detailne selgitus, koos näidetega R-koodist, geneetilise algoritmi töö kohta.

Erikena tahan rõhutada kahte tehnilist hetke.

Abikutsed, funktsioonist evaluate, näiteks peatamine-alustamine, parametri väärtuse määramine, toimuvad cran-r funktsiooni system2

Millega: kutsutakse üles mõni bash-skript või käsk.

Näiteks:

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)
}
}

Teine punkt - rida, evaluate funktsioon, säilitades konkreetse mõõdiku väärtuse ja vastava seadistuste vektori logifailis:

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)

See on oluline, kuna sellest andmemassist on võimalik saada täiendavat teavet selle kohta, milline seadistuste vektori komponent rohkem või vähem mõjutab mõõdiku väärtust.

Teisisõnu: on võimalik läbi viia feature-importance analüüs.

Nii et, mis võib välja tulla.

Graafikuna, kui järjestada testid mõõdiku kasvamise järjekorras, on pilt järgmine:

Mõned andmed, mis vastavad mõõdiku äärmuslikele väärtustele:

Siin, ekraanipildil tulemustest, täpsustan: seadistuste vektori väärtused on antud fitness-funktsiooni koodi mõistes, mitte numbriliste parameetrite/näitajate väärtuste loendi mõistes, mille formuleerisin tekstis varem.

No. Kas see on palju või vähe, ~8 tuhat tps: eraldi küsimus.
Laboritöö raames - see number ei ole oluline, tähtis on dünaamika, kuidas see väärtus muutub.

Dünaamika on siin hea.
On selge, et vähemalt üks tegur, mis mõjutab mõõdiku väärtust, ga-algoritm, läbides vektoreid-kromosoome: on tehtud.
Tuginedes, et muutuja kõverad on piisavalt elujõulised, on veel vähemalt üks tegur, mis, kuigi see on oluliselt väiksem, mõjutab.

Siin on vajalik attribute-importance analüüs, et mõista: millised atribuudid (antud juhul - seadistusteral) ja kui tugevalt nad mõjutavad meetrika väärtust.
Ja selle info põhjal: mõista - millised tegurid olid seotud oluliste atribuutide muutustega.

Teha attribute-importance võib erinevate viisidega.

Minu jaoks meeldib nende eesmärkide saavutamiseks algoritm randomForest samanimelisest R-paketist (dokumentatsioon)
randomForest, nagu ma mõistan, toimib see nii, et see loob mudeli, kuidas sõltuv muutuja sõltub atribuutidest.

Meie puhul on sõltuv muutuja - meetrika, mida saame andmebaasidest koormustestide käigus: tps;
Ja atribuudid on - seadistustera koostisosad.

Nii et randomForest hindab iga mudeli atribuudi tähtsust kahe numbriga: %IncMSE — kuidas selle atribuudi olemasolu/puudumine mudelis muudab MSE kvaliteeti (Keskmine ruutviga);

Ja IncNodePurity - see number näitab, kui hästi võib selle atribuudi väärtuste põhjal andmestikku jagada, nii et ühes osas oleksid andmed ühe selgitava meetrika väärtusega ja teises poleks.
Noh, see tähendab: kui klassifitseeriv atribuut see on (kõige arusaadavam, venekeelne selgitus randomforesti kohta, mida olen näinud siit).

Töömees-kodanik R-kood, et töödelda andmestikku koormustestide tulemustega:

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$importance

Saab otse kätega hüperparameetreid kohandada ja tuginedes mudeli kvaliteedile valida täpsemaid mudelit, mis teeb ennustusi valideerimisandmestikus.
Saab kirjutada mingi funktsiooni selle töö jaoks (muide, jälle, mingi optimeerimisalgoritmiga).

Saab kasutada R-paketti caret, ei ole oluline.

Kokkuvõttes saame sellise tulemuse atribuudi olulisuse hindamiseks:

Nii et, saame alustada globaalsete mõtete väljatöötamisega:

Selgub, et kõige olulisem parameeter antud testimise tingimustes on commit_wait
Tehniliselt määrab see io-operatsiooni režiimi, mille käigus kirjutatakse redo-andmed subd logi puhtasse ajakirja gruppi: sünkroonne või asünkroonne.
Tähendus nowait , mille tulemusena saavutatakse praktiliselt vertikaalne, korduvalt kasvav tps-mõõdik: see on io asünkroonne režiim redo-gruppides.
Erinev küsimus on, kas seda on vaja või mitte tootmisandmebaasis. Siin piirdun vaid konstateerimisega: see on oluline faktor.
On loogiline, et subd logi puhvri suurus on oluline faktor.
Mida väiksem on logi puhvri suurus, seda väiksem on selle puhverdamisvõime, seda sagedamini juhtuvad selle ületäitumised ja/või ei ole võimalik eraldada seal vaba ruumi uute redo-andmete jaoks.
Ja see tähendab: viivitused, mis on seotud ruumi eraldamisega logi puhvris ja/või redo-andmete väljaviskamisega sealt redo-gruppidesse.
Need viivitused peavad loomulikult mõjutama ja mõjutavad subd läbilaskevõimet tehingute osas.
Parameeter db_block_checksum: no, see on ka üsna arusaadav — tehingute töötlemine toob kaasa darti-blokke subd puhverkasutuses.
Need, kui kontrollitakse andmeplokkide tšekksumme, tuleb andmebaasil töödelda - arvutada need tšekksummad andmeploki kehast, võrrelda neid andmeploki päises kirjutatuga: vastab / ei vasta.
Selline töö ei saa jälle mitte venitada andmete töötlemist ja seega on parameeter ja mehanism, mis selle parameetri määrab, märkimisväärsed.
Seetõttu pakub tootja selle parameetri dokumentatsioonis erinevaid väärtusi ja rõhutab, et jah, mõju on, kuid siin on erinevad väärtused, isegi "välja", ja erinev mõju, mida saate valida.

Ja globaalne järeldus.

Lähtepunkt on üldiselt toimiv.

See võimaldab tugivõrgu testimise varases etapis, et valida selle (süsteemi) optimaalselt koormuseks konfigureerimist mitte liiga sügavale siseneda süsteemi seadistamise eripäradesse koormuse all.

Kuid see ei välista täiesti — vähemalt mõistmise tasemel: süsteem peab teadma "reguleerimisnuppe" ja nende pöörlemise lubatud vahemike väärtusi.

Edasi võib lähenemine üsna kiiresti leida süsteemi jaoks optimaalse konfiguratsiooni.
Ja testimise tulemuste põhjal saab teavet süsteemi töö kvaliteedi mõõdikute ja süsteemi seadistusparameetrite väärtuste vaheliste seoste kohta.

Mis peaks loomulikult soodustama sügava arusaama tekkimist süsteemist, selle töötamisest, vähemalt — antud koormuse tingimustes.

Praktiliselt tähendab see: kulutused süsteemi seadistamise mõistmiseks ja sellise testimise ettevalmistamise kulud.

Eraldi mainin: selles lähenemises on kriitiliselt oluline testimise adekvaatsuse määr süsteemi töötingimustele, millega see käib tootmiseksploitatsioonis.

Aitäh teie tähelepanu eest, aega.

Allikas: habr.com

Teadusliku meetodi kasutamine ehk kuidas leida andmebaasi konfiguratsioon benchmarkide ja optimeerimisalgoritmi abil