Hello
Nagpasya akong ibahagi ang aking nahanap - ang bunga ng pag-iisip, pagsubok at pagkakamali.
Sa pangkalahatan: hindi ito isang paghahanap, siyempre - ang lahat ng ito ay dapat na kilala sa mahabang panahon, sa mga taong kasangkot sa inilapat na pagpoproseso ng data ng istatistika at pag-optimize ng anumang mga sistema, hindi partikular na ang DBMS.
At: oo, alam nila, nagsusulat sila ng mga kawili-wiling artikulo sa kanilang pananaliksik, (UPD.: sa mga komento ay itinuro nila ang isang napaka-kagiliw-giliw na proyekto: )
Sa kabilang banda: wala akong nakikitang malawakang pagbanggit o pagpapakalat ng diskarteng ito sa Internet sa mga IT specialist, DBA.
So, to the point.
Ipagpalagay natin na mayroon tayong gawain: mag-set up ng isang partikular na sistema ng serbisyo upang magserbisyo ng ilang uri ng trabaho.
Ito ay kilala tungkol sa gawaing ito: kung ano ito, kung paano sinusukat ang kalidad ng gawaing ito, at ano ang pamantayan para sa pagsukat ng kalidad na ito.
Ipagpalagay din natin na ito ay higit pa o hindi gaanong kilala at nauunawaan: eksakto kung paano ginagawa ang trabaho sa (o sa) sistema ng serbisyong ito.
"Higit pa o mas kaunti" - nangangahulugan ito na posible na maghanda (o makuha ito mula sa isang lugar) ng isang tiyak na tool, utility, serbisyo na maaaring ma-synthesize at mailapat sa system na may test load na sapat na sapat sa kung ano ang gagawin, sa mga kondisyong sapat na sapat para sa paggawa sa produksyon.
Kaya, ipagpalagay natin na ang isang hanay ng mga parameter ng pagsasaayos para sa sistema ng serbisyong ito ay kilala, na maaaring magamit upang i-configure ang system na ito sa mga tuntunin ng pagiging produktibo ng trabaho nito.
At ano ang problema - walang sapat na kumpletong pag-unawa sa sistema ng serbisyong ito, isa na nagbibigay-daan sa iyong dalubhasang i-configure ang mga setting ng system na ito para sa pag-load sa hinaharap sa isang naibigay na platform at makuha ang kinakailangang produktibidad ng system.
Well. Ito ay halos palaging ang kaso.
Ano ang maaari mong gawin dito?
Buweno, ang unang bagay na nasa isip ay tingnan ang dokumentasyon para sa sistemang ito. Unawain kung ano ang mga katanggap-tanggap na hanay para sa mga halaga ng mga parameter ng pagsasaayos. At, halimbawa, gamit ang coordinate descent method, pumili ng mga value para sa mga parameter ng system sa mga pagsubok.
Yung. bigyan ang system ng ilang uri ng pagsasaayos, sa anyo ng isang tiyak na hanay ng mga halaga para sa mga parameter ng pagsasaayos nito.
Mag-apply ng test load dito, gamit ang mismong tool-utility, load generator.
At tingnan ang halaga - ang tugon, o isang sukatan ng kalidad ng system.
Ang pangalawang pag-iisip ay maaaring ang konklusyon na ito ay napakahabang panahon.
Well, iyon ay: kung mayroong maraming mga setting ng mga parameter, kung ang mga saklaw ng kanilang mga halaga na pinapatakbo ay malaki, kung ang bawat indibidwal na pagsubok sa pag-load ay tumatagal ng maraming oras upang makumpleto, kung gayon: oo, ang lahat ng ito ay maaaring tumagal ng hindi katanggap-tanggap matagal na panahon.
Well, narito ang maaari mong maunawaan at matandaan.
Maaari mong malaman na sa hanay ng mga halaga ng mga parameter ng mga setting ng system ng serbisyo mayroong isang vector, bilang isang pagkakasunud-sunod ng ilang mga halaga.
Ang bawat naturang vector, ang iba pang mga bagay ay pantay-pantay (sapagkat hindi ito apektado ng vector na ito), ay tumutugma sa isang ganap na tiyak na halaga ng sukatan - isang tagapagpahiwatig ng kalidad ng operasyon ng system sa ilalim ng isang pagsubok na pagkarga.
Ie
Tukuyin natin ang vector configuration ng system bilang 
Saan ; saan — bilang ng mga parameter ng pagsasaayos ng system, kung gaano karami ang mga parameter na ito.
At ang halaga ng sukatan na naaayon dito tukuyin natin ito bilang
, pagkatapos ay makakakuha tayo ng isang function:
Kaya, kung gayon: ang lahat ay agad na nauuwi sa, sa aking kaso: halos nakalimutan mula sa aking mga araw ng pag-aaral, mga algorithm para sa paghahanap para sa sukdulan ng isang function.
Okay, ngunit narito ang isang pang-organisasyon at inilapat na tanong na lumitaw: aling algorithm ang gagamitin.
- Sa kahulugan - upang mas mababa ang iyong code sa pamamagitan ng kamay.
- At para gumana ito, i.e. natagpuan ang extremum (kung mayroon man), mabuti, hindi bababa sa mas mabilis kaysa sa coordinate descent.
Ang unang punto ay nagpapahiwatig na kailangan nating tumingin sa ilang mga kapaligiran kung saan ang mga naturang algorithm ay naipatupad na, at, sa ilang anyo, handa nang gamitin sa code.
Well, alam ko python и cran-r
Ang pangalawang punto ay nangangahulugan na kailangan mong basahin ang tungkol sa mga algorithm mismo, kung ano ang mga ito, kung ano ang kanilang mga kinakailangan, at ang mga tampok ng kanilang trabaho.
At ang ibinibigay nila ay maaaring maging kapaki-pakinabang na mga side effect - mga resulta, o direkta mula sa algorithm mismo.
O maaari silang makuha mula sa mga resulta ng algorithm.
Marami ang nakasalalay sa mga kondisyon ng pag-input.
Halimbawa, kung, sa ilang kadahilanan, kailangan mong makakuha ng isang resulta nang mas mabilis, mabuti, kailangan mong tumingin sa mga algorithm ng gradient descent at pumili ng isa sa mga ito.
O, kung ang oras ay hindi gaanong mahalaga, maaari mong, halimbawa, gumamit ng stochastic optimization method, gaya ng genetic algorithm.
Iminumungkahi kong isaalang-alang ang gawain ng diskarteng ito, ang pagpili ng pagsasaayos ng system, gamit ang isang genetic algorithm, sa susunod, kaya na magsalita: gawain sa laboratoryo.
Orihinal:
- Magkaroon, bilang isang sistema ng serbisyo:
oracle xe 18c - Hayaan itong maghatid ng aktibidad sa transaksyon at ang layunin: upang makuha ang pinakamataas na posibleng throughput ng subdatabase, sa mga transaksyon/seg.
- Maaaring ibang-iba ang mga transaksyon sa likas na katangian ng pagtatrabaho sa data at sa konteksto ng trabaho.
Sumang-ayon tayo na ito ay mga transaksyon na hindi nagpoproseso ng malaking halaga ng data ng tabular.
Sa diwa na hindi sila nakakabuo ng mas maraming undo data kaysa sa gawing muli at hindi nagpoproseso ng malalaking porsyento ng mga row at malalaking talahanayan.
Ito ay mga transaksyon na nagbabago ng isang row sa isang mas marami o mas kaunting malaking talahanayan, na may maliit na bilang ng mga index sa talahanayang ito.
Sa sitwasyong ito: ang pagiging produktibo ng subdatabase para sa pagproseso ng mga transaksyon ay, na may reserbasyon, ay matutukoy ng kalidad ng pagproseso ng redox database.
Disclaimer - kung pag-uusapan natin ang tungkol sa mga setting ng subdb.
Dahil, sa pangkalahatang kaso, maaaring mayroong, halimbawa, mga transactional lock sa pagitan ng mga sesyon ng SQL, dahil sa disenyo ng trabaho ng user na may tabular na data at/o ang tabular na modelo.
Kung saan, siyempre, ay magkakaroon ng isang mapagpahirap na epekto sa sukatan ng TPS at ito ay magiging isang exogenous na kadahilanan, na nauugnay sa subdatabase: mabuti, ito ay kung paano ang tabular na modelo ay dinisenyo at ang trabaho na may data sa loob nito na nangyayari ang mga pagbara.
Samakatuwid, para sa kadalisayan ng eksperimento, ibubukod namin ang salik na ito, at sa ibaba ay linawin ko nang eksakto kung paano.
- Ipagpalagay natin, para sa katiyakan, na 100% ng mga SQL command na isinumite sa database ay mga DML command.
Hayaang magkapareho ang mga katangian ng user sa subdatabase sa mga pagsubok.
Namely: ang bilang ng skl sessions, tabular data, how skl sessions work with them. - Gumagana ang subd
FORCE LOGGING,ARCHIVELOGmga mod. Naka-off ang flashback-database mode, sa subd level. - Redo logs: matatagpuan sa isang hiwalay na file system, sa isang hiwalay na "disk";
Ang natitirang bahagi ng pisikal na bahagi ng database: sa isa pa, hiwalay na file system, sa isang hiwalay na "disk":
Higit pang mga detalye tungkol sa pisikal na device. mga bahagi ng database ng laboratoryo
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 0Sa una, sa ilalim ng mga kondisyon ng pag-load na ito, gusto kong gumamit ng transaction subd
Mayroon itong napakagandang tampok, sipiin ko ang may-akda:
Sa gitna ng SLOB ay ang “SLOB method.” Ang Paraang SLOB ay naglalayong subukan ang mga platform
nang walang pagtatalo sa aplikasyon. Hindi maaaring magmaneho ng pinakamataas na pagganap ng hardware
gamit ang application code na, halimbawa, nakatali sa pag-lock ng application o kahit na
pagbabahagi ng mga bloke ng Oracle Database. Tama iyon—may overhead kapag nagbabahagi ng data
sa mga bloke ng data! Ngunit ang SLOB—sa default na pag-deploy nito—ay immune sa naturang pagtatalo.
Ang deklarasyon na ito: tumutugma, ito ay.
Ito ay maginhawa upang ayusin ang antas ng paralelismo ng mga sesyon ng cl, ito ang susi -t ilunsad ang utility runit.sh mula sa SLOB
Ang porsyento ng mga DML command ay kinokontrol, sa bilang ng mga text message na ipinadala sa subd, bawat text session, parameter UPDATE_PCT
Hiwalay at napaka maginhawa: SLOB mismo, bago at pagkatapos ng session ng pag-load - naghahanda ng statspack, o awr-snapshots (kung ano ang nakatakdang ihanda).
Gayunpaman, ito pala SLOB ay hindi sumusuporta sa mga SQL session na may tagal na mas mababa sa 30 segundo.
Samakatuwid, una kong na-code ang aking sariling, manggagawa-magsasaka na bersyon ng loader, at pagkatapos ay nanatili itong gumagana.
Hayaan akong linawin kung ano ang ginagawa ng loader at kung paano ito ginagawa, para sa kalinawan.
Talagang ganito ang hitsura ng loader:
Code ng manggagawa
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 dotxInilunsad ang mga manggagawa sa ganitong paraan:
Tumatakbong manggagawa
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"
waitAt ang mga talahanayan para sa mga manggagawa ay inihanda tulad nito:
Paglikha ng mga talahanayan
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"Yung. Para sa bawat manggagawa (sa praktikal: isang hiwalay na sesyon ng SQL sa DB) isang hiwalay na talahanayan ang nilikha, kung saan gumagana ang manggagawa.
Tinitiyak nito ang kawalan ng mga transactional lock sa pagitan ng mga session ng manggagawa.
Ang bawat manggagawa: ginagawa ang parehong bagay, sa kanyang sariling mesa, ang mga mesa ay pareho.
Ang lahat ng mga manggagawa ay gumaganap ng trabaho para sa parehong dami ng oras.
Bukod dito, para sa isang mahabang panahon upang, halimbawa, isang log switch ay tiyak na magaganap, at higit sa isang beses.
Kaya, nang naaayon, lumitaw ang mga nauugnay na gastos at epekto.
Sa aking kaso, na-configure ko ang tagal ng trabaho ng mga manggagawa sa 8 minuto.
Isang piraso ng ulat ng statspack na naglalarawan sa pagpapatakbo ng subd sa ilalim ng pag-load
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.1Pagbabalik sa gawaing laboratoryo.
Kami ay, iba pang mga bagay na pantay, iba-iba ang mga halaga ng mga sumusunod na parameter ng subdatabase ng laboratoryo:
- Laki ng mga pangkat ng log ng database. hanay ng halaga: [32, 1024] MB;
- Bilang ng mga pangkat ng journal sa database. hanay ng halaga: [2,32];
log_archive_max_processessaklaw ng halaga: [1,8];commit_loggingdalawang halaga ang pinapayagan:batch|immediate;commit_waitdalawang halaga ang pinapayagan:wait|nowait;log_bufferhanay ng halaga: [2,128] MB.log_checkpoint_timeouthanay ng halaga: [60,1200] segundodb_writer_processeshanay ng halaga: [1,4]undo_retentionhanay ng halaga: [30;300] segundotransactions_per_rollback_segmenthanay ng halaga: [1,8]disk_asynch_iodalawang halaga ang pinapayagan:true|false;filesystemio_optionspinapayagan ang mga sumusunod na halaga:none|setall|directIO|asynch;db_block_checkingpinapayagan ang mga sumusunod na halaga:OFF|LOW|MEDIUM|FULL;db_block_checksumpinapayagan ang mga sumusunod na halaga:OFF|TYPICAL|FULL;
Ang isang taong may karanasan sa pagpapanatili ng mga database ng Oracle ay tiyak na masasabi na kung ano at sa anong mga halaga ang dapat itakda, mula sa tinukoy na mga parameter at ang kanilang mga katanggap-tanggap na halaga, upang makakuha ng higit na produktibo ng database para sa trabaho na may data na ipinahiwatig ng ang application code , dito sa itaas.
Ngunit.
Ang punto ng gawaing laboratoryo ay upang ipakita na ang algorithm ng pag-optimize mismo ay linawin ito para sa amin nang medyo mabilis.
Para sa amin, ang natitira na lang ay tingnan ang dokumento, sa pamamagitan ng nako-customize na sistema, sapat lang para malaman kung anong mga parameter ang babaguhin at sa anong mga saklaw.
At gayundin: i-code ang code na gagamitin para gumana sa custom na system ng napiling algorithm ng pag-optimize.
Kaya, ngayon tungkol sa code.
Napag-usapan ko sa itaas cran-r, i.e.: lahat ng manipulasyon gamit ang customized na system ay isinaayos sa anyo ng isang R script.
Ang aktwal na gawain, pagsusuri, pagpili ayon sa sukatan na halaga, mga vector ng estado ng system: ito ay isang pakete GA ()
Ang pakete, sa kasong ito, ay hindi masyadong angkop, sa diwa na inaasahan nito ang mga vectors (chromosome, kung sa mga tuntunin ng pakete) na tinukoy sa anyo ng mga string ng mga numero na may fractional na bahagi.
At ang aking vector, mula sa mga halaga ng mga parameter ng setting: ito ay 14 na dami - mga integer at mga halaga ng string.
Ang problema, siyempre, ay madaling maiiwasan sa pamamagitan ng pagtatalaga ng ilang partikular na numero sa mga halaga ng string.
Kaya, sa huli, ang pangunahing piraso ng R script ay ganito ang hitsura:
Tumawag kay 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@solutionDito, sa tulong lower и upper mga subroutine na katangian ga esensyal, ang isang lugar ng espasyo sa paghahanap ay tinukoy, kung saan isasagawa ang paghahanap para sa naturang vector (o mga vector) kung saan makukuha ang pinakamataas na halaga ng fitness function.
Ang ga subroutine ay nagsasagawa ng paghahanap sa pag-maximize ng fitness function.
Kaya, kung gayon, lumalabas na, sa kasong ito, kinakailangan na ang fitness function, na nauunawaan ang vector bilang isang hanay ng mga halaga para sa ilang mga parameter ng subd, ay tumatanggap ng isang sukatan mula sa subd.
Iyon ay: ilan, na may ibinigay na subd setup at isang naibigay na load sa subd: ang subd ay nagpoproseso ng mga transaksyon sa bawat segundo.
Iyon ay, kapag nagbubukas, ang sumusunod na multi-step ay dapat gawin sa loob ng fitness function:
- Pagproseso ng input vector ng mga numero - pag-convert nito sa mga halaga para sa mga parameter ng subdata.
- Isang pagtatangka na lumikha ng isang naibigay na bilang ng mga pangkat na gawing muli ng isang partikular na laki. Bukod dito, ang pagtatangka ay maaaring hindi matagumpay.
Mga pangkat ng magazine na umiral na sa subd, sa ilang dami at sa ilang sukat, para sa kadalisayan ng eksperimento - d.b. tinanggal. - Kung matagumpay ang nakaraang punto: pagtukoy ng mga halaga ng mga parameter ng pagsasaayos sa database (muli: maaaring may pagkabigo)
- Kung matagumpay ang nakaraang hakbang: itigil ang subd, simulan ang subd upang magkabisa ang bagong tinukoy na mga halaga ng parameter. (muli: maaaring may glitch)
- Kung matagumpay ang nakaraang hakbang: magsagawa ng pagsubok sa pagkarga. kumuha ng mga sukatan mula sa subd.
- Ibalik ang subd sa orihinal nitong estado, i.e. tanggalin ang mga karagdagang log group, ibalik ang orihinal na configuration ng subdatabase upang gumana.
Fitness function 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)
}yun. lahat ng trabaho: ginanap sa fitness function.
Ang ga-subroutine ay nagpoproseso ng mga vector, o, mas tama, mga chromosome.
Kung saan, ang pinakamahalaga sa amin ay ang pagpili ng mga chromosome na may mga gene kung saan ang fitness function ay gumagawa ng malalaking halaga.
Ito, sa esensya, ay ang proseso ng paghahanap para sa pinakamainam na hanay ng mga chromosome gamit ang isang vector sa isang N-dimensional na espasyo sa paghahanap.
Napakalinaw, detalyado , na may mga halimbawa ng R-code, ang gawain ng isang genetic algorithm.
Gusto kong hiwalay na tandaan ang dalawang teknikal na punto.
Mga auxiliary na tawag mula sa function evaluate, halimbawa, ang stop-start, ang pagtatakda ng value ng subd parameter, ay ginagawa batay sa cran-r mga function system2
Sa tulong ng kung saan: tinatawag ang ilang bash script o command.
Halimbawa:
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)
}
}Ang pangalawang punto ay ang linya, evaluate function, na may pag-save ng isang partikular na sukatan na halaga at ang kaukulang tuning vector nito sa isang log file:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Mahalaga ito, dahil mula sa array ng data na ito, posibleng makakuha ng karagdagang impormasyon tungkol sa kung alin sa mga bahagi ng tuning vector ang may mas malaki o mas maliit na epekto sa metric value.
Iyon ay: magiging posible na magsagawa ng attribute-importamce analysis.
Kaya ano ang maaaring mangyari?
Sa graph form, kung mag-order ka ng mga pagsubok sa pataas na pagkakasunud-sunod ng sukatan, ang larawan ay ang sumusunod:
Ilang data na tumutugma sa matinding halaga ng sukatan:
Dito, sa screenshot na may mga resulta, lilinawin ko: ang mga halaga ng tuning vector ay ibinibigay sa mga tuntunin ng fitness function code, hindi sa mga tuntunin ng listahan ng numero ng mga parameter/saklaw ng mga halaga ng parameter, na nabuo. sa itaas sa teksto.
Well. Marami ba o kaunti, ~8 thousand tps: isang hiwalay na tanong.
Sa loob ng balangkas ng gawaing laboratoryo, ang figure na ito ay hindi mahalaga, ang mahalaga ay ang dinamika, kung paano nagbabago ang halagang ito.
Maganda ang dynamics dito.
Malinaw na hindi bababa sa isang salik ang makabuluhang nakakaimpluwensya sa halaga ng sukatan, ang ga-algorithm, na nagbubukod-bukod sa mga chromosome vector: sakop.
Sa paghusga sa medyo masiglang dinamika ng mga halaga ng kurba, may hindi bababa sa isa pang salik na, bagama't mas maliit, ay may impluwensya.
Dito mo ito kailangan attribute-importance pagsusuri upang maunawaan kung anong mga katangian (mabuti, sa kasong ito, mga bahagi ng tuning vector) at kung gaano kalaki ang impluwensya ng mga ito sa halaga ng sukatan.
At mula sa impormasyong ito: unawain kung anong mga salik ang naapektuhan ng mga pagbabago sa mahahalagang katangian.
Magpatupad attribute-importance posible sa iba't ibang paraan.
Para sa mga layuning ito, gusto ko ang algorithm randomForest R package na may parehong pangalan ()
randomForest, dahil naiintindihan ko ang kanyang trabaho sa pangkalahatan at ang kanyang diskarte sa pagtatasa ng kahalagahan ng mga katangian sa partikular, ay bumubuo ng isang tiyak na modelo ng pag-asa ng variable ng tugon sa mga katangian.
Sa aming kaso, ang variable ng tugon ay isang sukatan na nakuha mula sa database sa mga pagsubok sa pag-load: tps;
At ang mga katangian ay mga bahagi ng tuning vector.
At iba pa randomForest sinusuri ang kahalagahan ng bawat katangian ng modelo na may dalawang numero: %IncMSE — kung paano binabago ng presensya/pagkawala ng katangiang ito sa isang modelo ang kalidad ng MSE ng modelong ito (Mean Squared Error);
At ang IncNodePurity ay isang numero na nagpapakita kung gaano kahusay, batay sa mga halaga ng katangiang ito, ang isang dataset na may mga obserbasyon ay maaaring hatiin, upang sa isang bahagi ay mayroong data na may isang halaga ng sukatan na ipinaliwanag, at sa isa pa ay may isa pang halaga ng sukatan.
Well, iyon ay: hanggang saan ito isang katangian ng pag-uuri (nakita ko ang pinakamalinaw, paliwanag sa wikang Ruso sa RandomForest ).
Worker-peasant R-code para sa pagproseso ng isang dataset na may mga resulta ng mga pagsubok sa pagkarga:
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$importanceMaaari mong direktang piliin ang mga hyperparameter ng algorithm gamit ang iyong mga kamay at, na tumutuon sa kalidad ng modelo, pumili ng modelo na mas tumpak na tumutupad sa mga hula sa dataset ng pagpapatunay.
Maaari kang magsulat ng ilang uri ng pag-andar para sa gawaing ito (sa pamamagitan ng paraan, muli, gamit ang ilang uri ng algorithm ng pag-optimize).
Maaari mong gamitin ang R package caret, hindi mahalaga ang punto.
Bilang resulta, sa kasong ito, ang sumusunod na resulta ay nakuha upang masuri ang antas ng kahalagahan ng mga katangian:
Well. Kaya, maaari nating simulan ang pandaigdigang pagmuni-muni:
- Lumalabas na ang pinakamahalaga, sa ilalim ng mga kundisyong ito ng pagsubok, ay ang parameter
commit_wait
Sa teknikal, tinutukoy nito ang execution mode ng io operation ng pagsulat ng redo data mula sa subdb log buffer hanggang sa kasalukuyang log group: synchronous o asynchronous.
Halaganowaitna nagreresulta sa halos patayo, maraming pagtaas sa halaga ng sukatan ng tps: ito ang pagsasama ng asynchronous io mode sa mga redo group.
Ang isang hiwalay na tanong ay kung dapat mong gawin ito o hindi sa isang database ng pagkain. Dito ko nililimitahan ang aking sarili sa pagsasabi lamang: ito ay isang makabuluhang kadahilanan. - Lohikal na ang laki ng log buffer ng subd: ay lumalabas na isang makabuluhang salik.
Kung mas maliit ang laki ng log buffer, mas mababa ang buffering capacity nito, mas madalas itong umaapaw at/o ang kawalan ng kakayahan na maglaan ng libreng lugar dito para sa isang bahagi ng bagong redox data.
Nangangahulugan ito: mga pagkaantala na nauugnay sa paglalaan ng espasyo sa log buffer at/o pag-dumping ng redo data mula dito sa mga redo group.
Ang mga pagkaantala, siyempre, ay dapat at makakaapekto sa throughput ng database para sa mga transaksyon. - Parametro
db_block_checksum: well, gayundin, sa pangkalahatan ito ay malinaw - ang pagpoproseso ng transaksyon ay humahantong sa pagbuo ng mga darty block sa buffer cache ng subdatabase.
Alin, kapag pinagana ang checksum ng mga datablock, kailangang iproseso ng database - kalkulahin ang mga checksum na ito mula sa katawan ng datablock, suriin ang mga ito sa kung ano ang nakasulat sa header ng datablock: tumutugma/hindi tumutugma.
Ang ganitong gawain, muli, ay hindi maaaring maantala ang pagproseso ng data, at naaayon, ang parameter at ang mekanismo na nagtatakda ng parameter na ito ay naging makabuluhan.
Iyon ang dahilan kung bakit nag-aalok ang vendor, sa dokumentasyon para sa parameter na ito, iba't ibang mga halaga para dito (ang parameter) at mga tala na oo, magkakaroon ng epekto, ngunit, mabuti, maaari kang pumili ng iba't ibang mga halaga, hanggang sa "off" at iba't ibang epekto.
Well, isang pandaigdigang konklusyon.
Ang diskarte, sa pangkalahatan, ay lumalabas na medyo gumagana.
Siya ay lubos na nagpapahintulot sa kanyang sarili, sa mga unang yugto ng pagsubok ng pagkarga ng isang tiyak na sistema ng serbisyo, upang piliin ang (sistema) na pinakamainam na pagsasaayos nito para sa pagkarga, na hindi masyadong malalim sa mga detalye ng pag-set up ng sistema para sa pagkarga.
Ngunit hindi ito ganap na ibinubukod - hindi bababa sa antas ng pag-unawa: ang sistema ay dapat malaman tungkol sa "mga adjustment knobs" at ang pinapayagang mga saklaw ng pag-ikot ng mga knobs na ito.
Ang diskarte ay maaaring medyo mabilis na mahanap ang pinakamainam na configuration ng system.
At batay sa mga resulta ng pagsubok, posible na makakuha ng impormasyon tungkol sa likas na katangian ng kaugnayan sa pagitan ng mga sukatan ng pagganap ng system at ang mga halaga ng mga parameter ng mga setting ng system.
Na, siyempre, ay dapat mag-ambag sa paglitaw ng napakalalim na pag-unawa sa sistema, ang operasyon nito, kahit sa ilalim ng isang naibigay na pagkarga.
Sa pagsasagawa, ito ay isang palitan ng mga gastos sa pag-unawa sa customized na sistema para sa mga gastos sa paghahanda ng naturang pagsubok ng system.
Gusto kong tandaan nang hiwalay: sa diskarteng ito, ang antas ng kasapatan ng pagsubok ng system sa mga kondisyon ng operating na mayroon ito sa komersyal na operasyon ay kritikal na mahalaga.
Salamat sa iyong atensyon at oras.
Pinagmulan: www.habr.com