Научни поке метод, или како одабрати конфигурацију базе података користећи бенчмаркове и алгоритам оптимизације

Здраво

Одлучио сам да поделим своје откриће - плод размишљања, покушаја и грешака.
Углавном: ово, наравно, није откриће – све је то требало одавно да буде познато онима који се баве примењеном статистичком обрадом података и оптимизацијом било ког система, не нужно конкретно ДБМС-а.
И: да, знају, пишу занимљиве чланке о свом истраживању, пример (УПД.: у коментарима су истакли веома занимљив пројекат: оттертуне )
С друге стране: напросто не видим никакво широко помињање или ширење овог приступа на Интернету међу ИТ стручњацима, ДБА.

Дакле, до тачке.

Претпоставимо да имамо задатак: да поставимо одређени услужни систем да сервисира неку врсту посла.

О овом делу се зна: шта је, како се мери квалитет овог дела и који је критеријум за мерење овог квалитета.

Претпоставимо и да је мање-више познато и схваћено: тачно како се рад обавља у (или са) овом услужном систему.

„Мање или више“ – то значи да је могуће припремити (или набавити однекуд) одређени алат, услужни програм, услугу који се може синтетизовати и применити на систем са тестним оптерећењем које је довољно адекватно ономе што ће бити у производњи, у условима довољно адекватним за рад у производњи .

Па, претпоставимо да је познат скуп параметара подешавања за овај сервисни систем који се може користити за конфигурисање овог система у смислу продуктивности његовог рада.

И у чему је проблем – не постоји довољно потпуно разумевање овог сервисног система, које вам омогућава да стручно конфигуришете подешавања овог система за будуће оптерећење на датој платформи и добијете потребну продуктивност система.

Добро. То је скоро увек случај.

Шта можеш да урадиш овде?

Па, прво што вам пада на памет је да погледате документацију за овај систем. Схватите који су прихватљиви опсези за вредности параметара подешавања. И, на пример, користећи метод координатног спуштања, изаберите вредности за системске параметре у тестовима.

Оне. дати систему неку врсту конфигурације, у облику одређеног скупа вредности за његове конфигурационе параметре.

Примените пробно оптерећење на њега, користећи овај алат, генератор оптерећења.
И погледајте вредност - одзив, или метрику квалитета система.

Друга помисао може бити закључак да је ово веома дуго.

Па, то јест: ако постоји много параметара подешавања, ако су распони њихових вредности које се покрећу велики, ако је сваком појединачном тесту оптерећења потребно много времена да се заврши, онда: да, све ово може трајати неприхватљиво Дуго времена.

Па, ево шта можете разумети и запамтити.

Можете сазнати да у скупу вредности параметара подешавања система услуга постоји вектор, као низ неких вредности.

Сваки такав вектор, уз остале једнаке ствари (по томе што овај вектор не утиче на њега), одговара потпуно одређеној вредности метрике - индикатора квалитета рада система под тестним оптерећењем.

Ие

Означимо вектор конфигурације система као Где ; Где — број параметара конфигурације система, колико ових параметара има.

И вредност метрике која одговара овоме означимо као
, онда добијамо функцију:

Е, онда: све се одмах своди на, у мом случају: скоро заборављене из студентских дана, алгоритме за тражење екстремума функције.

Добро, али овде се поставља организационо и примењено питање: који алгоритам користити.

1. У смислу – тако да можете мање кодирати ручно.
2. И да би то радило, тј. пронашао екстрем (ако га има), па, барем брже од координатног спуштања.

Прва тачка наговештава да треба да се осврнемо на нека окружења у којима су такви алгоритми већ имплементирани, и у неком облику су спремни за употребу у коду.
Па знам python и cran-r

Друга тачка значи да треба да прочитате о самим алгоритмима, шта су они, који су њихови захтеви, карактеристике њиховог рада.

А оно што дају могу бити корисни нежељени ефекти – резултати, или директно из самог алгоритма.

Или се могу добити из резултата алгоритма.

Много зависи од улазних услова.

На пример, ако из неког разлога морате брже да добијете резултат, онда морате да погледате алгоритме спуштања градијента и изаберете један од њих.

Или, ако време није толико важно, можете, на пример, користити методе стохастичке оптимизације, као што је генетски алгоритам.

Предлажем да се рад овог приступа, одабиром конфигурације система, коришћењем генетског алгоритма, размотри у следећем, да тако кажем: лабораторијском раду.

Почетно:

1. Нека буде, као услужни систем: oracle xe 18c
2. Нека служи трансакцијској активности и циљу: да се добије највећи могући проток подбазе података, у трансакцијама/сек.
3. Трансакције могу бити веома различите по природи рада са подацима и контексту рада.
   Сложимо се да су то трансакције које не обрађују велику количину табеларних података.
   У смислу да они не генеришу више података за поништавање него понављање и не обрађују велике проценте редова и великих табела.

То су трансакције које мењају један ред у мање или више великој табели, са малим бројем индекса на овој табели.

У овој ситуацији: продуктивност подбазе за обраду трансакција ће, уз резерву, бити одређена квалитетом обраде редокс базом података.

Одрицање од одговорности - ако говоримо конкретно о подешавањима субдб-а.

Јер, у општем случају, може доћи до, на пример, трансакцијских закључавања између СКЛ сесија, због дизајна корисничког рада са табеларним подацима и/или табеларног модела.

Што ће, наравно, имати депресиван ефекат на ТПС метрику и то ће бити егзогени фактор, у односу на подбазу података: па, овако је дизајниран табеларни модел и рад са подацима у њему долази до блокада.

Због тога ћемо због чистоће експеримента искључити овај фактор, а у наставку ћу појаснити како.

1. Претпоставимо, ради одређености, да су 100% СКЛ команди које се достављају бази података ДМЛ команде.
   Нека карактеристике рада корисника са подбазом података буду исте у тестовима.
   Наиме: број скл сесија, табеларни подаци, како скл сесије раде са њима.
2. Субд ради у FORCE LOGGING, ARCHIVELOG модс. Режим Фласхбацк-базе података је искључен, на нижем нивоу.
3. Редо логс: налазе се у посебном систему датотека, на посебном „диску“;
   Остатак физичке компоненте базе података: у другом, засебном систему датотека, на посебном „диску“:

Више детаља о физичком уређају. компоненте лабораторијске базе података

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

У почетку, под овим условима учитавања, желео сам да користим трансакцију субд СЛОБ-услужни програм
Има тако дивну особину, цитирам аутора:

У срцу СЛОБ-а је „СЛОБ метода“. СЛОБ метода има за циљ тестирање платформи
без спора о примени. Не може се постићи максималне перформансе хардвера
користећи код апликације који је, на пример, везан закључавањем апликације или чак
дељење блокова Орацле базе података. Тако је – постоје додатни трошкови приликом дељења података
у блоковима података! Али СЛОБ – у својој подразумеваној примени – је имун на такву свађу.

Ова изјава: одговара, јесте.
Погодно је регулисати степен паралелизма цл сесија, ово је кључ -t покрените услужни програм runit.sh од СЛОБ
Проценат ДМЛ команди је регулисан, у броју текстуалних порука које се шаљу на субд, свакој текстуалној сесији, параметру UPDATE_PCT
Одвојено и врло згодно: SLOB сама, пре и после сесије учитавања - припрема статспацк, или авр-снапсхотс (оно што је подешено да се припреми).

Међутим, показало се да SLOB не подржава СКЛ сесије које трају мање од 30 секунди.
Стога сам прво кодирао своју, радничко-сељачку верзију утоваривача, а затим је остао у функцији.

Дозволите ми да појасним шта утоваривач ради и како то ради, ради јасноће.
У суштини учитавач изгледа овако:

Шифра радника

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

Радници се лансирају на овај начин:

Радници који раде

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

А табеле за раднике припремају се овако:

Креирање табела

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"

Оне. За сваког радника (практично: засебна СКЛ сесија у ДБ) креира се посебна табела са којом радник ради.

Ово осигурава одсуство трансакцијских закључавања између сесија радника.
Сваки радник: ради исту ствар, са својим столом, столови су сви исти.
Сви радници обављају посао исто време.
Штавише, довољно дуго да би, на пример, дошло до промене дневника, и то више пута.
Па, сходно томе, настали су повезани трошкови и ефекти.
У мом случају, конфигурисао сам трајање рада радника на 8 минута.

Део извештаја о пакету података који описује рад подбазе података под оптерећењем

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

Враћајући се лабораторијском раду.
Ми ћемо, под истим условима, мењати вредности следећих параметара лабораторијске подбазе:

1. Величина група евиденције базе података. опсег вредности: [32, 1024] МБ;
2. Број група часописа у бази података. опсег вредности: [2,32];
3. log_archive_max_processes опсег вредности: [1,8];
4. commit_logging две вредности су дозвољене: batch|immediate;
5. commit_wait две вредности су дозвољене: wait|nowait;
6. log_buffer опсег вредности: [2,128] МБ.
7. log_checkpoint_timeout опсег вредности: [60,1200] секунди
8. db_writer_processes опсег вредности: [1,4]
9. undo_retention опсег вредности: [30;300] секунди
10. transactions_per_rollback_segment опсег вредности: [1,8]
11. disk_asynch_io две вредности су дозвољене: true|false;
12. filesystemio_options следеће вредности су дозвољене: none|setall|directIO|asynch;
13. db_block_checking следеће вредности су дозвољене: OFF|LOW|MEDIUM|FULL;
14. db_block_checksum следеће вредности су дозвољене: OFF|TYPICAL|FULL;

Особа са искуством у одржавању Орацле база података сигурно већ може рећи шта и на које вредности треба подесити, од наведених параметара и њихових прихватљивих вредности, како би се постигла већа продуктивност базе података за рад са подацима на које указује код апликације, овде изнад.

Али.

Смисао лабораторијског рада је да покаже да ће нам сам алгоритам оптимизације то релативно брзо разјаснити.

За нас остаје само да погледамо документ, кроз прилагодљиви систем, тек толико да сазнамо које параметре да променимо иу којим распонима.
И такође: кодирајте код који ће се користити за рад са прилагођеним системом изабраног алгоритма оптимизације.

Дакле, сада о коду.
Горе сам говорио о cran-r, односно: све манипулације са прилагођеним системом су оркестриране у облику Р скрипте.

Стварни задатак, анализа, избор по метричкој вредности, вектори стања система: ово је пакет GA (документацију)
Пакет, у овом случају, није баш погодан, у смислу да очекује да се вектори (хромозоми, ако се ради о пакету) специфицирају у облику низова бројева са разломком.

И мој вектор, од вредности параметара подешавања: ово су 14 величина - цели бројеви и вредности низа.

Проблем се, наравно, лако може избећи додељивањем одређених бројева вредностима низа.

Дакле, на крају, главни део Р скрипте изгледа овако:

Позовите ГА::га

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

Ево, уз помоћ lower и upper атрибути потпрограма ga у суштини, специфицира се област простора за претрагу у оквиру које ће се извршити претрага таквог вектора (или вектора) за које ће се добити максимална вредност функције фитнеса.

Га потпрограм врши претрагу максимизирајући функцију фитнеса.

Па, онда се испоставља да је у овом случају неопходно да функција фитнеса, схватајући вектор као скуп вредности за одређене параметре субд, добије метрику од субд.

То је: колико, са датим подешавањем субд и датим оптерећењем на субд: субд обрађује трансакције у секунди.

Односно, приликом отварања, унутар функције фитнеса мора се извршити следећи више корака:

1. Обрада улазног вектора бројева - претварање у вредности за параметре подподатака.
2. Покушај креирања датог броја редо група дате величине. Штавише, покушај може бити неуспешан.
   Групе часописа које су већ постојале у подд, у некој количини и неке величине, ради чистоће експеримента – д.б. избрисан.
3. Ако је претходна тачка успешна: навођење вредности конфигурационих параметара у бази података (опет: може доћи до неуспеха)
4. Ако је претходни корак успешан: заустављање субд-а, покретање субд-а како би ново специфициране вредности параметара ступиле на снагу. (опет: можда постоји грешка)
5. Ако је претходни корак успешан: извршите тест оптерећења. добити метрику од подд.
6. Вратите субд у првобитно стање, тј. избришите додатне групе дневника, вратите оригиналну конфигурацију базе података да ради.

Код функције фитнеса

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

То. сав рад: обавља се у фитнес функцији.

Га-подпрограм обрађује векторе, или, тачније, хромозоме.
У чему нам је најважнији одабир хромозома са генима за које фитнес функција производи велике вредности.

Ово је, у суштини, процес тражења оптималног скупа хромозома помоћу вектора у Н-димензионалном простору претраге.

Врло јасно, детаљно објашњење, са примерима Р-кода, рад генетског алгоритма.

Желео бих посебно да напоменем две техничке тачке.

Помоћни позиви из функције evaluate, на пример, стоп-старт, подешавање вредности параметра субд, се изводе на основу cran-r функције system2

Уз помоћ којих се: позива нека басх скрипта или команда.

На пример:

сет_дб_параметер

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

Друга тачка је линија, evaluate функције, са чувањем одређене метричке вредности и њеног одговарајућег вектора подешавања у датотеку евиденције:

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

Ово је важно, јер ће из овог низа података бити могуће добити додатне информације о томе која од компоненти вектора подешавања има већи или мањи утицај на метричку вредност.

То јест: биће могуће спровести анализу атрибута-важности.

Па шта се може догодити?

У облику графикона, ако наручите тестове узлазним метричким редоследом, слика је следећа:

Неки подаци који одговарају екстремним вредностима метрике:

Овде, на снимку екрана са резултатима, разјаснићу: вредности вектора подешавања су дате у смислу кода функције фитнеса, а не у смислу листе бројева параметара/опсега вредности параметара, која је формулисана горе у тексту.

Добро. Да ли је то много или мало, ~8 хиљада тпс: посебно питање.
У оквиру лабораторијског рада ова цифра није битна, битна је динамика, како се та вредност мења.

Овде је динамика добра.
Очигледно је да бар један фактор значајно утиче на вредност метрике, га-алгоритам, сортирање кроз векторе хромозома: покривено.
Судећи по прилично снажној динамици вредности криве, постоји бар још један фактор који, иако знатно мањи, има утицај.

Овде вам треба attribute-importance анализу да бисмо разумели који атрибути (па, у овом случају, компоненте вектора подешавања) и колико утичу на метричку вредност.
И из ових информација: схватите на које факторе су утицале промене значајних атрибута.

Извршити attribute-importance могуће на различите начине.

За ове сврхе ми се свиђа алгоритам randomForest Р пакет истог имена (документацију)
randomForest, како разумем његов рад уопште и његов приступ процени важности атрибута посебно, гради одређени модел зависности варијабле одговора од атрибута.

У нашем случају, променљива одговора је метрика добијена из базе података у тестовима оптерећења: tps;
А атрибути су компоненте вектора подешавања.

Дакле овде randomForest процењује важност сваког атрибута модела са два броја: %IncMSE — како присуство/одсуство овог атрибута у моделу мења МСЕ квалитет овог модела (средња квадратна грешка);

А ИнцНодеПурити је број који одражава колико добро, на основу вредности овог атрибута, скуп података са запажањима може да се подели, тако да се у једном делу налазе подаци са једном вредношћу метрике која се објашњава, а у другом са другу вредност метрике.
Па, то јест: у којој мери је ово класификациони атрибут (видео сам најјасније објашњење на руском језику на РандомФорест-у овде).

Радник-сељак Р-код за обраду скупа података са резултатима тестова оптерећења:

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

Можете директно да изаберете хиперпараметре алгоритма својим рукама и, фокусирајући се на квалитет модела, изаберете модел који тачније испуњава предвиђања у скупу података за валидацију.
Можете написати неку врсту функције за овај рад (успут, опет, користећи неку врсту оптимизацијског алгоритма).

Можете користити Р пакет caret, није битна поента.

Као резултат тога, у овом случају се добија следећи резултат за процену степена важности атрибута:

Добро. Дакле, можемо започети глобалну рефлексију:

1. Испоставило се да је најзначајнији, у овим условима тестирања, био параметар commit_wait
   Технички, он специфицира начин извршавања ио операције писања редо података из субдб бафера дневника у тренутну групу дневника: синхрони или асинхрони.
   Вредност nowait што резултира скоро вертикалним, вишеструким повећањем вредности тпс метрике: ово је укључивање асинхроног ио режима у редо групе.
   Посебно питање је да ли то треба да урадите у бази података о храни. Овде се ограничавам само на констатацију: ово је значајан фактор.
2. Логично је да се величина бафера дневника субд: покаже као значајан фактор.
   Што је мања величина бафера дневника, мањи је његов капацитет баферовања, чешће се он прелива и/или немогућност да се у њему додели слободна област за део нових редокс података.
   То значи: кашњења повезана са додељивањем простора у баферу дневника и/или одлагањем података о понављању из њега у групе за понављање.
   Ова кашњења би, наравно, требало да утичу и утичу на пропусност базе података за трансакције.
3. Параметар db_block_checksum: па, такође, генерално је јасно - обрада трансакција доводи до формирања блокова дарти у кешу бафера подбазе.
   Које, када је омогућена провера контролних сума блокова података, база података мора да обради - израчуна ове контролне суме из тела блока података, провери их са оним што је написано у заглављу блока података: одговара/не поклапа се.
   Такав рад, опет, не може а да не одложи обраду података, па се сходно томе и параметар и механизам који поставља овај параметар испоставља значајним.
   Због тога продавац нуди у документацији за овај параметар различите вредности за њега (параметар) и напомиње да да, биће утицаја, али, добро, можете изабрати различите вредности, до „искључено“ и различити утицаји.

Па, глобални закључак.

Приступ се, генерално гледано, показао прилично радним.

Он сасвим дозвољава себи да у раним фазама тестирања оптерећења одређеног сервисног система, да би одабрао његову (системску) оптималну конфигурацију за оптерећење, не улази превише у специфичности подешавања система за оптерећење.

Али то не искључује то у потпуности - барем на нивоу разумевања: систем мора бити познат о "дугмадима за подешавање" и дозвољеним дометима ротације ових дугмића.

Приступ тада може релативно брзо пронаћи оптималну конфигурацију система.
А на основу резултата тестирања, могуће је добити информације о природи односа између метрике перформанси система и вредности параметара системских подешавања.

Што би, наравно, требало да допринесе настанку овог веома дубоког разумевања система, његовог функционисања, бар под датим оптерећењем.

У пракси, ово је замена трошкова разумевања прилагођеног система за трошкове припреме таквог тестирања система.

Напомињем посебно: у овом приступу је критично важан степен адекватности тестирања система условима рада које ће имати у комерцијалном раду.

Хвала вам на пажњи и времену.

Извор: ввв.хабр.цом