Здраво
Решив да го споделам моето откритие - плод на мисла, обиди и грешки.
Во голема мера: ова не е откритие, се разбира - сето ова требаше да им биде познато долго време, на оние кои се вклучени во применетата статистичка обработка на податоци и оптимизација на кој било систем, а не нужно конкретно на DBMS.
И: да, знаат, пишуваат интересни написи за нивното истражување, (УПД.: во коментарите истакнаа еден многу интересен проект: )
Од друга страна: ненамерно, не гледам широко распространето спомнување или ширење на овој пристап на Интернет меѓу ИТ специјалистите, DBA.
Значи, до точка.
Да претпоставиме дека имаме задача: да поставиме одреден сервисен систем за сервисирање на некаква работа.
За ова дело се знае: што е тоа, како се мери квалитетот на оваа работа и кој е критериумот за мерење на овој квалитет.
Ајде, исто така, да претпоставиме дека е повеќе или помалку познато и разбрано: точно како се изведува работата во (или со) овој сервисен систем.
„Повеќе или помалку“ - тоа значи дека е можно да се подготви (или да се добие од некаде) одредена алатка, алатка, услуга што може да се синтетизира и примени на системот со тест оптоварување доволно соодветно на она што ќе биде во производство, во услови доволно адекватни за работа во производство .
Па, да претпоставиме дека е познат збир на параметри за прилагодување за овој сервисен систем, што може да се користи за конфигурирање на овој систем во однос на продуктивноста на неговата работа.
И што е проблемот - нема доволно целосно разбирање за овој сервисен систем, такво што ви овозможува стручно да ги конфигурирате поставките на овој систем за идно оптоварување на дадена платформа и да ја добиете потребната продуктивност на системот.
Па. Ова е речиси секогаш случај.
Што можете да направите овде?
Па, првото нешто што ви паѓа на ум е да ја погледнете документацијата за овој систем. Разберете кои се прифатливите опсези за вредностите на параметрите за прилагодување. И, на пример, користејќи го методот на координатно спуштање, изберете вредности за системските параметри во тестовите.
Оние. дајте му на системот некаква конфигурација, во форма на специфичен сет на вредности за неговите конфигурациски параметри.
Нанесете тест оптоварување на него, користејќи ја оваа алатка-услужна алатка, генератор на оптоварување.
И погледнете ја вредноста - одговорот или метриката на квалитетот на системот.
Втората мисла може да биде заклучокот дека ова е многу долго време.
Па, тоа е: ако има многу параметри за поставување, ако опсегот на нивните вредности што се извршуваат се големи, ако секој поединечен тест за оптоварување бара многу време за да се заврши, тогаш: да, сето ова може да потрае неприфатливо долго време.
Па, еве што можете да разберете и запомните.
Можете да дознаете дека во множеството вредности на параметрите на поставките на системот за услуги има вектор, како низа од некои вредности.
Секој таков вектор, додека другите работи се еднакви (со тоа што не е засегнат од овој вектор), одговара на сосема дефинитивна вредност на метриката - индикатор за квалитетот на работата на системот под тест оптоварување.
Односно
Дозволете ни да го означиме векторот за конфигурација на системот како 
каде ; Каде — број на параметри за конфигурација на системот, колку од овие параметри има.
И вредноста на метриката што одговара на ова да го означиме како
, тогаш ја добиваме функцијата:
Па, тогаш: сè веднаш се сведува на, во мојот случај: речиси заборавен од моите студентски денови, алгоритми за пребарување на екстремот на функцијата.
Во ред, но тука се поставува организациско и применето прашање: кој алгоритам да се користи.
- Во смисла - за да можете да кодирате помалку рачно.
- А за да функционира т.е. го најде екстремумот (ако го има), добро, барем побрзо од координатното спуштање.
Првата точка навестува дека треба да погледнеме кон некои средини во кои таквите алгоритми се веќе имплементирани и, во некоја форма, се подготвени за употреба во код.
Па, знам python и cran-r
Втората точка значи дека треба да прочитате за самите алгоритми, кои се тие, кои се нивните барања и карактеристиките на нивната работа.
А тоа што го даваат може да биде корисни нуспојави - резултати, или директно од самиот алгоритам.
Или тие можат да се добијат од резултатите од алгоритмот.
Многу зависи од условите за внесување.
На пример, ако, поради некоја причина, треба да постигнете резултат побрзо, добро, треба да погледнете кон алгоритмите за спуштање на градиент и да изберете еден од нив.
Или, ако времето не е толку важно, можете, на пример, да користите стохастички методи за оптимизација, како што е генетскиот алгоритам.
Предлагам да се разгледа работата на овој пристап, избирајќи ја конфигурацијата на системот, користејќи генетски алгоритам, во следната, така да се каже: лабораториска работа.
Оригинал:
- Нека има, како систем на услуги:
oracle xe 18c - Нека служи за трансакциска активност и цел: да се добие најголема можна пропусност на подбазата на податоци, во трансакции/сек.
- Трансакциите можат да бидат многу различни по природата на работата со податоци и контекстот на работата.
Да се согласиме дека се работи за трансакции кои не обработуваат голема количина табеларни податоци.
Во смисла дека тие не генерираат повеќе податоци за поништување отколку повторно и не обработуваат големи проценти од редови и големи табели.
Тоа се трансакции кои менуваат еден ред во повеќе или помалку голема табела, со мал број на индекси на оваа табела.
Во оваа ситуација: продуктивноста на подбазата на податоци за обработка на трансакции, со резерва, ќе биде одредена од квалитетот на обработката од страна на редокс базата на податоци.
Одрекување - ако зборуваме конкретно за поставките за subdb.
Бидејќи, во општиот случај, може да има, на пример, трансакциски заклучувања помеѓу сесиите на SQL, поради дизајнот на работата на корисникот со табеларни податоци и/или табеларниот модел.
Што, се разбира, ќе има депресивно влијание врз метриката на TPS и ова ќе биде егзоген фактор, во однос на подбазата на податоци: па, вака е дизајниран табеларниот модел и работата со податоците во него што се случуваат блокади.
Затоа, за чистотата на експериментот, ќе го исклучиме овој фактор, а подолу ќе објаснам точно како.
- Да претпоставиме, за дефинитивно, дека 100% од SQL командите доставени до базата на податоци се DML команди.
Карактеристиките на корисничката работа со подбазата на податоци нека бидат исти во тестовите.
Имено: бројот на skl сесии, табеларни податоци, како функционираат skl сесиите со нив. - Subd работи во
FORCE LOGGING,ARCHIVELOGмодови. Режимот за ретроспектива-база на податоци е исклучен, на ниво на подд. - Повтори дневници: лоцирани во посебен датотечен систем, на посебен „диск“;
Остатокот од физичката компонента на базата на податоци: во друг, посебен датотечен систем, на посебен „диск“:
Повеќе детали за физичкиот уред. лабораториски компоненти на базата на податоци
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Првично, под овие услови на оптоварување, сакав да користам трансакција subd
Има толку прекрасна карактеристика, ќе го цитирам авторот:
Во срцето на SLOB е „методот SLOB“. Методот SLOB има за цел да тестира платформи
без расправа за апликацијата. Не може да се вози максимални хардверски перформанси
користење на кодот на апликацијата кој е, на пример, врзан со заклучување на апликацијата или дури
споделување на блокови на Oracle Database. Тоа е точно - има над глава при споделување податоци
во податочни блокови! Но, SLOB - во неговото стандардно распоредување - е имун на таквите расправии.
Оваа декларација: одговара, тоа е.
Удобно е да се регулира степенот на паралелизам на cl сесиите, ова е клучот -t стартувајте ја алатката runit.sh од СЛОБ
Процентот на DML команди е регулиран, во бројот на текстуални пораки што се испраќаат до подд, секоја текстуална сесија, параметар UPDATE_PCT
Одделно и многу погодно: SLOB самиот, пред и по сесијата за вчитување - подготвува statspack, или awr-snapshots (што е поставено да се подготви).
Сепак, се покажа дека SLOB не поддржува SQL сесии со времетраење помало од 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"Оние. За секој работник (практично: посебна SQL сесија во DB) се креира посебна табела, со која работи работникот.
Ова осигурува отсуство на трансакциски заклучувања помеѓу сесиите на работниците.
Секој работник: го прави истото, со своја маса, масите се сите исти.
Сите работници работат исто време.
Покрај тоа, доволно долго, така што, на пример, дефинитивно ќе се случи прекинувач на дневникот, и тоа повеќе од еднаш.
Па, соодветно, се појавија придружните трошоци и ефекти.
Во мојот случај, го конфигурирав времетраењето на работата на работниците на 8 минути.
Дел од извештајот на statspack кој ја опишува работата на subd под оптоварување
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Враќање на лабораториската работа.
Ние ќе ги менуваме вредностите на следните параметри на лабораториската подбаза на податоци, ако се подеднакви работи:
- Големина на групи за дневници на базата на податоци. опсег на вредности: [32, 1024] MB;
- Број на групи на списанија во базата на податоци. опсег на вредности: [2,32];
log_archive_max_processesопсег на вредности: [1,8];commit_loggingДозволени се две вредности:batch|immediate;commit_waitДозволени се две вредности:wait|nowait;log_bufferопсег на вредности: [2,128] MB.log_checkpoint_timeoutопсег на вредности: [60,1200] секундиdb_writer_processesопсег на вредности: [1,4]undo_retentionопсег на вредности: [30;300] секундиtransactions_per_rollback_segmentопсег на вредности: [1,8]disk_asynch_ioДозволени се две вредности:true|false;filesystemio_optionsДозволени се следните вредности:none|setall|directIO|asynch;db_block_checkingДозволени се следните вредности:OFF|LOW|MEDIUM|FULL;db_block_checksumДозволени се следните вредности:OFF|TYPICAL|FULL;
Лице со искуство во одржување на бази на податоци на Oracle сигурно веќе може да каже што и до кои вредности треба да се постават, од наведените параметри и нивните прифатливи вредности, за да се добие поголема продуктивност на базата на податоци за работа со податоци што се означени со кодот на апликацијата, овде погоре.
Но.
Поентата на лабораториската работа е да покаже дека самиот алгоритам за оптимизација ќе ни го разјасни ова релативно брзо.
За нас останува само да погледнеме во документот, преку приспособливиот систем, доволно само за да дознаеме кои параметри да ги смениме и во кои опсези.
И, исто така: кодирајте го кодот што ќе се користи за работа со сопствениот систем на избраниот алгоритам за оптимизација.
Значи, сега за кодот.
Зборував погоре за cran-r, т.е.: сите манипулации со приспособениот систем се оркестрирани во форма на скрипта R.
Вистинската задача, анализа, избор по метричка вредност, вектори на системска состојба: ова е пакет GA ()
Пакетот, во овој случај, не е многу погоден, во смисла дека очекува векторите (хромозомите, ако во однос на пакетот) да бидат специфицирани во форма на низи од броеви со фракционо дел.
И мојот вектор, од вредностите на параметрите за поставување: ова се 14 количини - цели броеви и вредности на низа.
Проблемот, се разбира, лесно се избегнува со доделување на некои специфични броеви на вредностите на низата.
Така, на крајот, главниот дел од скриптата R изгледа вака:
Јавете се на ГА::га
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 во суштина, се одредува област на просторот за пребарување, во која ќе се изврши пребарување за таков вектор (или вектори) за кои ќе се добие максималната вредност на функцијата за фитнес.
Потпрограмата ga врши пребарување максимизирајќи ја фитнес функцијата.
Па, тогаш, излегува дека, во овој случај, неопходно е фитнес функцијата, разбирајќи го векторот како збир на вредности за одредени параметри на подд, да добие метрика од подд.
Односно: колку, со дадена поставка за subd и дадено оптоварување на subd: subd обработува трансакции во секунда.
Односно, кога се расплетува, мора да се изврши следниов повеќе чекор во внатрешноста на фитнес функцијата:
- Обработка на влезниот вектор на броеви - претворање во вредности за параметрите на подподатоци.
- Обид да се создаде даден број на повторно групи со дадена големина. Покрај тоа, обидот може да биде неуспешен.
Групи на списанија кои веќе постоеле во подд, во одредена количина и во одредена големина, за чистотата на експериментот - д.б. избришани. - Ако претходната точка е успешна: наведете ги вредностите на конфигурациските параметри во базата на податоци (повторно: може да има дефект)
- Ако претходниот чекор е успешен: запирање на subd, стартување на subd за да стапат на сила новонаведените вредности на параметарот. (повторно: може да има дефект)
- Ако претходниот чекор е успешен: направете тест за оптоварување. добијте метрика од подд.
- Вратете го subd во првобитната состојба, т.е. избришете ги дополнителните групи на дневници, вратете ја оригиналната конфигурација на базата на податоци на работа.
Код за фитнес функција
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)
}Тоа. целата работа: извршена во фитнес функција.
Га-потпрограмата обработува вектори или, поточно, хромозоми.
Во кој, најважно ни е изборот на хромозоми со гени за кои фитнес функцијата произведува големи вредности.
Ова, во суштина, е процес на пребарување на оптимален сет на хромозоми со помош на вектор во N-димензионален простор за пребарување.
Многу јасно, детално , со примери на R-код, работа на генетски алгоритам.
Би сакал посебно да забележам две технички точки.
Помошни повици од функцијата evaluate, на пример, стоп-старт, поставување на вредноста на параметарот subd, се изведуваат врз основа на cran-r функции system2
Со чија помош: се повикува некоја баш скрипта или команда.
На пример:
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)
}
}Втората точка е линијата, evaluate функции, со зачувување на одредена метричка вредност и нејзиниот соодветен вектор за подесување во датотека за евиденција:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Ова е важно, бидејќи од оваа низа на податоци ќе може да се добијат дополнителни информации за тоа која од компонентите на векторот за подесување има поголем или помал ефект врз метричката вредност.
Односно: ќе може да се спроведе анализа на атрибут-импортамце.
Значи, што може да се случи?
Во форма на графикон, ако ги подредите тестовите во растечки метрички редослед, сликата е следна:
Некои податоци што одговараат на екстремните вредности на метриката:
Овде, во скриншот со резултатите, ќе појаснам: вредностите на векторот за подесување се дадени во однос на кодот на функцијата за фитнес, а не во однос на списокот со броеви на параметри/опсези на вредности на параметрите што беше формулиран горе во текстот.
Па. Дали е многу или малку, ~8 илјади tps: посебно прашање.
Во рамките на лабораториската работа, оваа бројка не е важна, важна е динамиката, како се менува оваа вредност.
Динамиката овде е добра.
Очигледно е дека барем еден фактор значително влијае на вредноста на метриката, га-алгоритмот, сортирање низ векторите на хромозомот: покриени.
Судејќи според прилично енергичната динамика на вредностите на кривата, има барем уште еден фактор кој, иако значително помал, има влијание.
Ова е местото каде што ви треба attribute-importance анализа за да се разбере кои атрибути (добро, во овој случај, компоненти на векторот за подесување) и колку тие влијаат на метричката вредност.
И од оваа информација: разберете кои фактори биле под влијание на промените во значајните атрибути.
Изврши attribute-importance можно на различни начини.
За овие цели, ми се допаѓа алгоритмот randomForest R пакет со исто име ()
randomForest, како што ја разбирам неговата работа воопшто и неговиот пристап кон проценката на важноста на атрибутите особено, гради одреден модел на зависност на променливата одговор од атрибутите.
Во нашиот случај, променливата за одговор е метрика добиена од базата на податоци во тестовите за оптоварување: tps;
А атрибутите се компоненти на векторот за подесување.
Па еве randomForest ја оценува важноста на секој атрибут на моделот со два броја: %IncMSE — како присуството/отсуството на овој атрибут во модел го менува квалитетот на MSE на овој модел (Mean Squared Error);
И IncNodePurity е број кој одразува колку добро, врз основа на вредностите на овој атрибут, може да се подели базата на податоци со набљудувања, така што во едниот дел има податоци со едната вредност на метриката што се објаснува, а во другиот со друга вредност на метриката.
Па, тоа е: до кој степен е ова класифицирачки атрибут (го видов најјасното, објаснување на руски јазик на RandomForest ).
Работно-селанец R-код за обработка на база на податоци со резултатите од тестовите за оптоварување:
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Можете директно да ги изберете хиперпараметрите на алгоритмот со вашите раце и, фокусирајќи се на квалитетот на моделот, да изберете модел што попрецизно ги исполнува предвидувањата на базата на податоци за валидација.
Можете да напишете некаква функција за оваа работа (патем, повторно, користејќи некој вид алгоритам за оптимизација).
Можете да го користите пакетот R caret, не е важна поентата.
Како резултат на тоа, во овој случај, се добива следниов резултат за да се процени степенот на важност на атрибутите:
Па. Така, можеме да започнеме глобално размислување:
- Излегува дека најзначајниот, под овие услови на тестирање, бил параметарот
commit_wait
Технички, тој го одредува режимот на извршување на операцијата io за запишување податоци за повторување од баферот за евиденција subdb до тековната група за дневници: синхрони или асинхрони.
Вредностnowaitшто резултира со речиси вертикално, повеќекратно зголемување на вредноста на метриката tps: ова е вклучување на асинхрониот io режим во повторно групи.
Посебно прашање е дали тоа треба да го правите или не во базата на податоци за храна. Овде се ограничувам само да наведам: ова е значаен фактор. - Логично е дека големината на баферот за дневници на subd: се покажува како значаен фактор.
Колку е помала големината на баферот за евиденција, толку е помал неговиот капацитет за тампонирање, толку почесто се прелева и/или неможноста да се распредели слободна област во него за дел од нови редокс податоци.
Ова значи: доцнења поврзани со доделување простор во баферот за евиденција и/или фрлање податоци за повторување од него во групи за повторување.
Овие одложувања, се разбира, треба и влијаат на пропусната моќ на базата на податоци за трансакции. - Параметар
db_block_checksum: добро, исто така, генерално е јасно - обработката на трансакциите доведува до формирање на дарти блокови во тампон-кешот на подбазата на податоци.
Кои, кога е овозможено проверка на контролните суми на блоковите на податоци, базата треба да ги обработи - пресметајте ги овие контролни суми од телото на блокот на податоци, проверете ги со она што е напишано во заглавието на блокот на податоци: се совпаѓа/не се совпаѓа.
Таквата работа, повторно, не може, а да не ја одложи обработката на податоците, и соодветно на тоа, параметарот и механизмот што го поставува овој параметар се значајни.
Затоа продавачот нуди, во документацијата за овој параметар, различни вредности и забележува дека да, ќе има влијание, но можете да изберете различни вредности, дури и „исклучено“ и различни влијанија.
Па, глобален заклучок.
Пристапот, генерално, се покажува како доста работен.
Тој сосема си дозволува, во раните фази на тестирање на оптоварувањето на одреден сервисен систем, за да ја избере неговата (системска) оптимална конфигурација за товарот, да не навлегува премногу во спецификите на поставување на системот за оптоварување.
Но, тоа не го исклучува целосно - барем на ниво на разбирање: системот мора да биде познат за „копчињата за прилагодување“ и дозволените опсези на ротација на овие копчиња.
Пристапот потоа може релативно брзо да ја најде оптималната системска конфигурација.
И врз основа на резултатите од тестирањето, можно е да се добијат информации за природата на врската помеѓу метриката за перформансите на системот и вредностите на параметрите на системските поставки.
Што, се разбира, треба да придонесе за појавата на ова многу длабоко разбирање на системот, неговото функционирање, барем под одредено оптоварување.
Во пракса, ова е размена на трошоците за разбирање на приспособениот систем за трошоците за подготовка на такво тестирање на системот.
Посебно би сакал да забележам: во овој пристап, критично е важен степенот на соодветност на тестирањето на системот со условите за работа што ќе ги има во комерцијалната работа.
Ви благодариме за вашето внимание и време.
Извор: www.habr.com