Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen

Hallo

Ech hu beschloss meng Fannt ze deelen - d'Fruucht vum Gedanken, Versuch a Feeler.
Am grousse Ganzen: dëst ass natierlech kee Fonnt - dat alles sollt scho laang bekannt gewiescht sinn, fir déi, déi an der applizéierter statistescher Dateveraarbechtung an der Optimiséierung vun all System, net onbedéngt speziell dem DBMS, involvéiert sinn.
An: Jo, si wëssen, si schreiwen interessant Artikelen iwwer hir Fuerschung, Beispill (UPD.: Si hunn an de Kommentaren op e ganz interessante Projet higewisen: ottertune )
Op der anerer Säit: offhand gesinn ech keng verbreet Ernimmung oder Verbreedung vun dëser Approche um Internet ënnert IT Spezialisten, DBA.

Also, zum Punkt.

Loosst eis dovun ausgoen, datt mir eng Aufgab hunn: e bestëmmte Servicesystem op d'Been ze stellen fir eng Zort Aarbecht ze servéieren.

Et ass bekannt iwwer dëst Wierk: wat et ass, wéi d'Qualitéit vun dëser Aarbecht gemooss gëtt, a wat ass de Critère fir dës Qualitéit ze moossen.

Loosst eis och unhuelen datt et méi oder manner bekannt a verständlech ass: genee wéi d'Aarbecht an (oder mat) dësem Servicesystem gemaach gëtt.

"Méi oder manner" - dat heescht datt et méiglech ass e bestëmmten Tool, Utility, Service ze preparéieren (oder iergendwou ze kréien) dee synthetiséiert ka ginn an op de System applizéiert ginn mat enger Testlaascht déi genuch adäquat ass fir dat wat wäert sinn Produktioun, ënner Bedéngungen genuch adäquat fir an der Produktioun ze schaffen.

Gutt, loosst eis unhuelen datt eng Rei vun Upassungsparameter fir dëse Servicesystem bekannt ass, wat benotzt ka ginn fir dëse System a punkto Produktivitéit vu senger Aarbecht ze konfiguréieren.

A wat ass de Problem - et gëtt net e genuch komplett Verständnis vun dësem Servicesystem, een deen Iech erlaabt Iech d'Astellunge vun dësem System fir zukünfteg Laascht op enger bestëmmter Plattform kompetent ze konfiguréieren an déi erfuerderlech Produktivitéit vum System ze kréien.

Gutt. Dëst ass bal ëmmer de Fall.

Wat kënnt Dir hei maachen?

Gutt, déi éischt Saach déi am Kapp kënnt ass d'Dokumentatioun fir dëse System ze kucken. Verstinn wat déi akzeptabel Beräicher fir d'Wäerter vun den Upassungsparameter sinn. An, zum Beispill, mat der Koordinaten Ofstamungsmethod, wielt Wäerter fir Systemparameter an Tester.

Déi. gitt de System eng Aart vu Konfiguratioun, a Form vun engem spezifesche Set vu Wäerter fir seng Konfiguratiounsparameter.

Gitt eng Testlaascht op et mat dësem Tool-Utility, Lastgenerator.
A kuckt de Wäert - d'Äntwert, oder eng Metrik vun der Qualitéit vum System.

Déi zweet Gedanke kann d'Konklusioun sinn datt dëst eng ganz laang Zäit ass.

Gutt, dat ass: wann et vill Tuning-Parameteren sinn, wann d'Beräicher vun hire Wäerter ofgedeckt sinn grouss, wann all eenzel Lasttest vill Zäit dauert fir ze kompletéieren, dann: jo, all dëst kann en inakzeptable Betrag huelen vun Zäit.

Gutt, hei ass wat Dir kënnt verstoen an erënneren.

Dir kënnt erausfannen datt am Set vu Wäerter vun de Service System Astellungsparameter e Vektor ass, als Sequenz vun e puer Wäerter.

All esou Vecteure, aner Saachen déi gläich sinn (an datt et net vun dësem Vecteure beaflosst ass), entsprécht engem komplett definitive Wäert vun der Metrik - en Indikator fir d'Qualitéit vun der Operatioun vum System ënner enger Testlaascht.

dh

Loosst eis de Systemkonfiguratiounsvektor als Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielenwou Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen; Wou Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen - Zuel vu Systemkonfiguratiounsparameter, wéi vill vun dëse Parameteren et ginn.

An de Wäert vun der Metrik entsprécht deem Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen loosst eis et als
Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen, da kréie mir eng Funktioun: Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen

Ma, dann: alles kënnt direkt erof, a mengem Fall: bal vergiess aus menger Studentenzäit, Algorithmen fir no der Extremum vun enger Funktioun ze sichen.

Okay, awer hei stellt sech eng organisatoresch an applizéiert Fro: wéi en Algorithmus ze benotzen.

  1. Am Sënn - sou datt Dir manner mat der Hand ka codéieren.
  2. A fir datt et funktionéiert, d.h. den Extremum fonnt (wann et een ass), gutt, op d'mannst méi séier wéi d'Koordinaten Ofstamung.

Den éischte Punkt weist datt mir mussen no e puer Ëmfeld kucken, an deenen esou Algorithmen scho implementéiert goufen, a sinn, an enger Form, prett fir am Code ze benotzen.
Gutt, ech weess python и cran-r

Den zweete Punkt bedeit datt Dir iwwer d'Algorithmen selwer liesen musst, wat se sinn, wat hir Ufuerderunge sinn an d'Features vun hirer Aarbecht.

A wat se ginn kann nëtzlech Säit Effekter - Resultater, oder direkt aus dem Algorithmus selwer.

Oder se kënnen aus de Resultater vum Algorithmus kritt ginn.

Vill hänkt vun den Inputbedéngungen of.

Zum Beispill, wann Dir aus irgendege Grënn e Resultat méi séier muss kréien, gutt, Dir musst no Gradient Ofstamung Algorithmen kucken an ee vun hinnen wielen.

Oder, wann d'Zäit net sou wichteg ass, kënnt Dir zum Beispill stochastesch Optimiséierungsmethoden benotzen, wéi zum Beispill e geneteschen Algorithmus.

Ech proposéieren d'Aarbecht vun dëser Approche ze berücksichtegen, d'Systemkonfiguratioun auswielen, mat engem geneteschen Algorithmus, an der nächster, souzesoen: Laboraarbecht.

Original:

  1. Loosst et ginn, als Service System: oracle xe 18c
  2. Loosst et d'Transaktiounsaktivitéit an d'Zil déngen: den héchste méiglechen Duerchsatz vun der Subdatabase ze kréien, an Transaktiounen / sec.
  3. Transaktioune kënne ganz ënnerschiddlech sinn an der Natur vun der Aarbecht mat Daten an dem Kontext vun der Aarbecht.
    Loosst eis d'accord sinn datt dëst Transaktiounen sinn déi net eng grouss Quantitéit vun Tabulärdaten veraarbecht.
    Am Sënn datt se net méi Undoen Daten generéieren wéi nei maachen an net grouss Prozentzuelen vu Reihen a grouss Dëscher veraarbechten.

Dëst sinn Transaktiounen déi eng Zeil an engem méi oder manner groussen Dësch änneren, mat enger klenger Zuel vun Indexen op dësem Dësch.

An dëser Situatioun: d'Produktivitéit vun der Subdatabase fir d'Veraarbechtung vun Transaktiounen gëtt, mat enger Reservatioun, vun der Qualitéit vun der Veraarbechtung vun der Redox-Datebank bestëmmt.

Verzichterklärung - wa mir speziell iwwer d'subdb Astellunge schwätzen.

Well am allgemenge Fall kann et zum Beispill Transaktiounsspären tëscht SQL Sessiounen sinn, wéinst dem Design vun der Benotzeraarbecht mat Tabulardaten an / oder dem Tabularmodell.

Wat selbstverständlech en depressiven Effekt op d'TPS Metrik wäert hunn an dëst en exogene Faktor wäert sinn, par rapport zu der Subdatabase: gutt, sou ass den Tabellemodell entworf an d'Aarbecht mat Daten dran datt Blockaden optrieden.

Dofir, fir d'Rengheet vum Experiment, wäerte mir dëse Faktor ausschléissen, an hei ënnen wäert ech genau klären wéi.

  1. Loosst eis unhuelen, fir Definitivitéit, datt 100% vun de SQL Kommandoen, déi an d'Datebank ofginn, DML Kommandoen sinn.
    Loosst d'Charakteristiken vum Benotzer mat der Ënnerdatabase d'selwecht sinn an Tester.
    Nämlech: d'Zuel vun de skl Sessiounen, Tabulardaten, wéi Skl Sessiounen mat hinnen funktionnéieren.
  2. Subd schafft an FORCE LOGGING, ARCHIVELOG mods. Flashback-Datebank Modus ass ausgeschalt, um subd Niveau.
  3. Redo Logbicher: läit an engem separaten Dateiesystem, op enger separater "Disk";
    De Rescht vun der kierperlecher Komponent vun der Datebank: an engem aneren, getrennten Dateiesystem, op enger separater "Disk":

Méi Detailer iwwer de kierperlechen Apparat. Laboratoire Datebank Komponente

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

Am Ufank, ënner dëse Laaschtbedéngungen, wollt ech Transaktiounssubd benotzen SLOB-Utility
Et huet sou eng wonnerbar Feature, ech zitéieren den Auteur:

Am Häerz vum SLOB ass d'"SLOB Method." D'SLOB Method zielt fir Plattformen ze testen
ouni Applikatioun Sträit. Eent kann net maximal Hardware Leeschtung fueren
benotzt Applikatioun Code datt, zum Beispill, vun Applikatioun Spär gebonnen oder souguer
Deelen Oracle Datebank Blocks. Dat ass richteg - et gëtt Overhead wann Dir Daten deelt
an Dateblocken! Awer SLOB - a senger Default Deployment - ass immun géint sou Sträit.

Dës Deklaratioun: entsprécht, et ass.
Et ass bequem de Grad vun der Parallelismus vu cl Sessiounen ze regléieren, dëst ass de Schlëssel -t den Utility starten runit.sh vum SLOB
De Prozentsaz vun DML Befehle gëtt geregelt, an der Unzuel vun SMSen, déi un d'Subd geschéckt ginn, all Text Sessioun, Parameter UPDATE_PCT
Separat a ganz bequem: SLOB selwer, virun an no der Laascht Sëtzung - preparéiert e statspack, oder awr-Snapshots (wat bereet ass ze preparéieren).

Et huet sech awer erausgestallt SLOB ënnerstëtzt net SQL Sessiounen mat enger Dauer vu manner wéi 30 Sekonnen.
Dofir hunn ech fir d'éischt meng eegen, Aarbechter-Bauer Versioun vum Loader kodéiert, an dunn ass et am Operatioun bliwwen.

Loosst mech klären wat de Loader mécht a wéi et et mécht, fir Kloerheet.
Wesentlech gesäit de Loader esou aus:

Aarbechter Code

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 dotx

Aarbechter ginn op dës Manéier gestart:

Lafen Aarbechter

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"
wait

An Dëscher fir Aarbechter sinn esou virbereet:

Schafen Dëscher

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"

Déi. Fir all Aarbechter (praktesch: eng separat SQL Sessioun an der DB) gëtt eng separat Tabell erstallt, mat där den Aarbechter schafft.

Dëst garantéiert d'Feele vu Transaktiounsspären tëscht Aarbechter Sessiounen.
All Aarbechter: mécht déi selwecht Saach, mat sengem eegenen Dësch, d'Dëscher sinn all déi selwecht.
All Aarbechter maachen Aarbecht fir déi selwecht Zäit.
Desweideren, fir eng laang genuch Zäit sou datt zum Beispill e Logschalter definitiv optrieden, a méi wéi eemol.
Gutt, deementspriechend sinn verbonne Käschten an Effekter entstanen.
A mengem Fall hunn ech d'Dauer vun der Aarbecht vun den Aarbechter op 8 Minutten konfiguréiert.

E Stéck vun engem Statspack Bericht deen d'Operatioun vum Subd ënner Belaaschtung beschreift

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.1

Zréck op d'Laboraarbecht.
Mir wäerten, soss d'selwecht sinn, d'Wäerter vun de folgende Parameteren vun der Labo-Subdatabase variéieren:

  1. Gréisst vun Datebank Log Gruppen. Wäertberäich: [32, 1024] MB;
  2. Zuel vun Journal Gruppen an der Datebank. Wäertberäich: [2,32];
  3. log_archive_max_processes Wäertberäich: [1,8];
  4. commit_logging zwee Wäerter sinn erlaabt: batch|immediate;
  5. commit_wait zwee Wäerter sinn erlaabt: wait|nowait;
  6. log_buffer Wäert Beräich: [2,128] MB.
  7. log_checkpoint_timeout Wäertberäich: [60,1200] Sekonnen
  8. db_writer_processes Wäertbereich: [1,4]
  9. undo_retention Wäertbereich: [30;300] Sekonnen
  10. transactions_per_rollback_segment Wäertbereich: [1,8]
  11. disk_asynch_io zwee Wäerter sinn erlaabt: true|false;
  12. filesystemio_options déi folgend Wäerter sinn erlaabt: none|setall|directIO|asynch;
  13. db_block_checking déi folgend Wäerter sinn erlaabt: OFF|LOW|MEDIUM|FULL;
  14. db_block_checksum déi folgend Wäerter sinn erlaabt: OFF|TYPICAL|FULL;

Eng Persoun mat Erfarung am Erhalen vun Oracle Datenbanken kann sécherlech scho soen wat a wéi eng Wäerter solle festgeluecht ginn, vun de spezifizéierte Parameteren an hiren akzeptable Wäerter, fir eng méi grouss Produktivitéit vun der Datebank fir d'Aarbecht mat Daten ze kréien, déi uginn ass den Applikatiounscode, hei uewen.

Awer.

De Punkt vun der Laboraarbecht ass et ze weisen datt den Optimisatiounsalgorithmus selwer dat relativ séier fir eis kläre wäert.

Fir eis bleift et nëmmen d'Dokument ze kucken, duerch de personaliséierbare System, just genuch fir erauszefannen wéi eng Parameteren ze änneren an a wéi enge Beräicher.
An och: Code de Code dee benotzt gëtt fir mam personaliséierte System vum gewielten Optimisatiounsalgorithmus ze schaffen.

Also, elo iwwer de Code.
Ech geschwat uewen iwwer cran-r, dh: all Manipulatioune mam personaliséierte System sinn a Form vun engem R-Skript orchestréiert.

Déi aktuell Aufgab, Analyse, Selektioun no metresche Wäert, Systemstatvektoren: dëst ass e Package GA (Dokumentatioun)
De Package, an dësem Fall, ass net ganz gëeegent, am Sënn datt et erwaart datt Vecteure (Chromosomen, wann am Sënn vum Package) an der Form vun Zuelen vun Zuelen mat engem fractional Deel spezifizéiert ginn.

A mäi Vektor, aus de Wäerter vun den Astellungsparameter: dëst sinn 14 Quantitéiten - ganz Zuelen a Stringwäerter.

De Problem gëtt natierlech einfach vermeit andeems Dir e puer spezifesch Zuelen un Stringwäerter zouginn.

Also um Enn gesäit d'Haaptstéck vum R Skript esou aus:

Call 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

Hei, mat der Hëllef lower и upper subroutine Attributer ga am Wesentlechen ass e Gebitt vum Sichraum spezifizéiert, an deem eng Sich no sou engem Vektor (oder Vecteure) gemaach gëtt, fir deen de maximale Wäert vun der Fitnessfunktioun kritt gëtt.

D'Ga Subroutine mécht eng Sich déi d'Fitnessfunktioun maximéiert.

Gutt, dann stellt sech eraus datt et an dësem Fall néideg ass datt d'Fitnessfunktioun, de Vecteur als Set vu Wäerter fir gewësse Parameteren vun der Subd verstoen, eng Metrik vun der Subd kritt.

Dat ass: wéi vill, mat engem bestëmmte Subd-Setup an enger bestëmmter Belaaschtung op der Subd: de Subd veraarbecht Transaktiounen pro Sekonn.

Dat ass, beim Ausklappen, muss de folgende Multi-Schrëtt an der Fitnessfunktioun ausgefouert ginn:

  1. Veraarbechtung vum Inputvektor vun Zuelen - Ëmwandlung et a Wäerter fir d'Ënnerdatenparameter.
  2. E Versuch eng bestëmmte Zuel vun Redaktioun Gruppen vun enger bestëmmter Gréisst ze schafen. Ausserdeem kann de Versuch net erfollegräich sinn.
    Magazingruppen déi schonn an der Subd existéiert hunn, an enger Quantitéit a vun enger Gréisst, fir d'Rengheet vum Experiment - d.b. geläscht.
  3. Wann de fréiere Punkt erfollegräich ass: d'Wäerter vun de Konfiguratiounsparameter an d'Datebank spezifizéieren (erëm: et kann e Feeler sinn)
  4. Wann de virege Schrëtt erfollegräich ass: d'Subd stoppen, d'Subd starten, sou datt déi nei spezifizéiert Parameterwäerter a Kraaft trieden. (erëm: et kann e Feeler sinn)
  5. Wann de virege Schrëtt erfollegräich ass: maacht e Laaschtest. kréien Metriken aus subd.
  6. Zréck de Subd an säin ursprénglechen Zoustand, d.h. läscht zousätzlech Loggruppen, gitt d'Original Ënnerdatabasekonfiguratioun zréck fir ze schaffen.

Fitness Funktioun Code

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

Dat. all Aarbecht: am Fitness Funktioun duerchgefouert.

D'ga-Subroutine veraarbecht Vektoren, oder, méi korrekt, Chromosomen.
An deem, wat fir eis am wichtegsten ass, ass d'Auswiel vu Chromosomen mat Genen, fir déi d'Fitnessfunktioun grouss Wäerter produzéiert.

Dëst, am Wesentlechen, ass de Prozess fir no der optimaler Set vu Chromosomen ze sichen mat engem Vektor an engem N-dimensionalen Sichraum.

Ganz kloer, detailléiert Erklärung, mat Beispiller vum R-Code, d'Aarbecht vun engem geneteschen Algorithmus.

Ech wéilt separat zwee technesch Punkten notéieren.

Auxiliary Appellen aus der Funktioun evaluate, Zum Beispill, Stop-Start, de Wäert vun der subd Parameter Kader, sinn duerchgefouert baséiert op cran-r Funktiounen system2

Mat der Hëllef vun deem: e puer Bash-Skript oder Kommando gëtt genannt.

Zum Beispill:

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

Den zweete Punkt ass d'Linn, evaluate Funktiounen, mat engem spezifesche metresche Wäert a sengem entspriechende Tuningvektor an eng Logdatei ze späicheren:

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

Dëst ass wichteg, well aus dëser Donnéeën Array ass et méiglech zousätzlech Informatiounen ze kréien iwwer déi Komponente vun der Tuning Vecteure méi oder manner Effekt op de metresche Wäert huet.

Dat ass: et wäert méiglech sinn Attributer-Importamce Analyse ze maachen.

Also wat ka geschéien?

A Grafikform, wann Dir d'Tester an opsteigend metrescher Uerdnung bestellt, ass d'Bild wéi follegt:

Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen

E puer Donnéeën entspriechend den extremen Wäerter vun der Metrik:
Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen
Hei, am Screenshot mat de Resultater, wäert ech klären: d'Wäerter vum Tuningvektor ginn am Sënn vum Fitnessfunktiounscode uginn, net wat d'Zuel Lëscht vun de Parameteren / Palette vun de Parameterwäerter ugeet, déi formuléiert gouf uewen am Text.

Gutt. Ass et vill oder e bëssen, ~ 8 dausend tps: eng separat Fro.
Am Kader vun der Laboraarbecht ass dës Figur net wichteg, wat wichteg ass d'Dynamik, wéi dëse Wäert ännert.

D'Dynamik hei ass gutt.
Et ass offensichtlech datt op d'mannst ee Faktor wesentlech de Wäert vun der Metrik beaflosst, de ga-Algorithmus, duerch d'Chromosomvektoren ze sortéieren: bedeckt.
No der zimlech kräfteg Dynamik vun de Kurvewäerter ze beurteelen, gëtt et op d'mannst ee Faktor méi deen, obwuel däitlech méi kleng ass, en Afloss huet.

Dëst ass wou Dir et braucht attribute-importance Analyse fir ze verstoen wéi eng Attributer (gutt, an dësem Fall Komponente vum Tuningvektor) a wéi vill se de metresche Wäert beaflossen.
A vun dëser Informatioun: verstoen wat Faktoren duerch Ännerungen an bedeitendst Attributer betraff waren.

Ausféieren attribute-importance kann op verschidde Weeër gemaach ginn.

Fir dës Zwecker hunn ech den Algorithmus gär randomForest R Package mam selwechten Numm (Dokumentatioun)
randomForest, wéi ech seng Aarbecht am Allgemengen verstoen a seng Approche fir d'Wichtegkeet vun Attributer besonnesch ze bewäerten, baut e bestëmmte Modell vun der Ofhängegkeet vun der Äntwertvariabel op den Attributer.

An eisem Fall ass d'Äntwert Variabel eng Metrik, déi aus der Datebank a Lasttester kritt gëtt: tps;
An Attributer si Komponente vum Tuningvektor.

An esou randomForest evaluéiert d'Wichtegkeet vun all Modellattributer mat zwou Zuelen: %IncMSE - wéi d'Präsenz / Feele vun dësem Attribut an engem Modell d'MSE Qualitéit vun dësem Modell ännert (Mean Squared Error);

An IncNodePurity ass eng Zuel déi reflektéiert wéi gutt, baséiert op de Wäerter vun dësem Attribut, en Dataset mat Beobachtungen opgedeelt ka ginn, sou datt et an engem Deel Daten mat engem Wäert vun der Metrik gëtt erkläert, an am aneren mat en anere Wäert vun der Metrik.
Gutt, dat ass: a wéi engem Ausmooss ass dëst e Klassifizéierungsattribut (ech hunn déi kloerst russeschsproocheg Erklärung um RandomForest gesinn hei).

Aarbechter-Bauer R-Code fir d'Veraarbechtung vun engem Dataset mat de Resultater vun de Laaschtester:

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

Dir kënnt direkt d'Hyperparameter vum Algorithmus mat Ären Hänn auswielen an, fokusséiert op d'Qualitéit vum Modell, wielt e Modell deen d'Prognosen op der Validatiounsdates méi präzis erfëllt.
Dir kënnt eng Zort Funktioun fir dës Aarbecht schreiwen (iwwregens, nach eng Kéier, mat enger Aart vun Optimisatiounsalgorithmus).

Dir kënnt R Package benotzen caret, net de Punkt ass wichteg.

Als Resultat gëtt an dësem Fall déi folgend Resultat kritt fir de Grad vun der Wichtegkeet vun den Attributer ze bewäerten:

Déi wëssenschaftlech Poke Method, oder wéi Dir eng Datebankkonfiguratioun mat Benchmarks an engem Optimisatiounsalgorithmus auswielen

Gutt. Also kënne mir global Reflexioun ufänken:

  1. Et stellt sech eraus datt de bedeitendsten, ënner dësen Testbedéngungen, de Parameter war commit_wait
    Technesch spezifizéiert et den Ausféierungsmodus vun der io-Operatioun fir Redo-Daten aus dem Subdb-Log-Puffer op déi aktuell Log-Grupp ze schreiwen: Synchron oder asynchron.
    Wäert nowait wat zu enger bal vertikaler, multiple Erhéijung vum Wäert vun der tps Metrik resultéiert: dëst ass d'Inklusioun vum asynchronen io Modus an Redogruppen.
    Eng separat Fro ass ob Dir dëst an engem Liewensmëttel Datebank maachen soll. Hei limitéieren ech mech just ze soen: dëst ass e wesentleche Faktor.
  2. Et ass logesch datt d'Gréisst vum Logbuffer vum Subd: e wesentleche Faktor ass.
    Wat méi kleng d'Gréisst vum Logbuffer ass, wat manner seng Pufferkapazitéit ass, wat méi dacks et iwwerfléisst an / oder d'Onméiglechkeet fir e fräie Gebitt dran ze verdeelen fir en Deel vun neie Redoxdaten.
    Dëst bedeit: Verspéidungen verbonne mat der Verdeelung vum Raum am Logbuffer an / oder Dumping vun neidaten dovunner an Redo-Gruppen.
    Dës Verspéidungen, natierlech, sollten a beaflossen den Duerchgang vun der Datebank fir Transaktiounen.
  3. Parameter db_block_checksum: gutt, och, am Allgemengen ass et kloer - Transaktiounsveraarbechtung féiert zu der Bildung vun Darty-Blöcke am Puffer-Cache vun der Ënnerdatabase.
    Wat, wann d'Kontrollsumme vun den Dateblocken aktivéiert ass, d'Datebank muss veraarbecht ginn - berechent dës Kontrollsummen aus dem Kierper vum Dateblock, kontrolléiert se mat deem wat am Dateblock Header geschriwwe steet: passt / passt net.
    Esou Aarbecht, erëm, kann net nëmmen d'Datenveraarbechtung verzögeren, an deementspriechend de Parameter an de Mechanismus, deen dëse Parameter feststellt, ass bedeitend.
    Dofir bitt de Verkeefer, an der Dokumentatioun fir dëse Parameter, verschidde Wäerter a bemierkt datt jo, et gëtt en Impakt, awer Dir kënnt verschidde Wäerter wielen, och "Off" a verschidden Auswierkungen.

Gutt, eng global Conclusioun.

D'Approche, am Allgemengen, stellt sech eraus als zimmlech funktionnéiert.

Hien erlaabt sech ganz, an de fréie Stadien vun der Laaschtprüfung vun engem bestëmmte Servicesystem, fir seng (System) optimal Konfiguratioun fir d'Laascht ze wielen, net ze vill an d'Spezifizitéiten vum Opbau vum System fir d'Laascht ze verdéiwen.

Awer et schléisst et net komplett aus - op d'mannst um Niveau vum Verständnis: de System muss iwwer d'"Upassungsknäppchen" an déi zulässlech Rotatiounsberäicher vun dëse Knäpper bekannt sinn.

D'Approche kann dann relativ séier déi optimal Systemkonfiguratioun fannen.
A baséiert op d'Resultater vum Test ass et méiglech Informatiounen iwwer d'Natur vun der Bezéiung tëscht de Systemleistungsmetriken an de Wäerter vun de Systemastellungsparameter ze kréien.

Wat natierlech zu der Entstoe vun dësem ganz déiwe Verständnis vum System, senger Operatioun, op d'mannst ënner enger bestëmmter Laascht bäidroe soll.

An der Praxis ass dëst en Austausch vun de Käschte fir de personaliséierte System ze verstoen fir d'Käschte fir sou Tester vum System ze preparéieren.

Ech wëll getrennt notéieren: an dëser Approche ass de Grad vun der Adäquatitéit vum Systemprüfung fir d'Betribsbedingungen, déi et am kommerziellen Operatioun wäert hunn, kritesch wichteg.

Merci fir Är Opmierksamkeet an Zäit.

Source: will.com

Setzt e Commentaire