Hello.
Min biryar da ku dîtina xwe parve bikim - fêkiya raman, ceribandin û xeletiyê.
Bi gelemperî: ev ne vedîtinek e, bê guman - ev hemî pêdivî ye ku ji demek dirêj ve were zanîn, ji wan ên ku di pêvajoyek daneya statîstîkî ya sepandî û xweşbînkirina her pergalê de têkildar in, ne bi taybetî DBMS.
Û: erê, ew dizanin, ew li ser lêkolîna xwe gotarên balkêş dinivîsin, (UPD.: Di şîroveyan de wan projeyek pir balkêş destnîşan kirin: )
Ji aliyek din ve: nerast ez di nav pisporên IT-ê, DBA-ê de, behs an belavkirina vê nêzîkatiyê li ser Înternetê nabînim.
Ji ber vê yekê, ji bo xala.
Werin em texmîn bikin ku peywirek me heye: em pergalek karûbarek diyarkirî saz bikin da ku karûbarê cûrbecûr bixebite.
Di derbarê vê xebatê de tê zanîn: ew çi ye, kalîteya vî karî çawa tê pîvandin, û pîvana pîvandina vê sifatê çi ye.
Werin em her weha bifikirin ku ew kêm-zêde tê zanîn û têgihîştin: tam çawa di vê pergala karûbarê (an bi) re kar tê kirin.
"Kêmtir an kêm" - ev tê vê wateyê ku meriv dikare amûrek, karûbar, karûbarek diyarkirî amade bike (an jî ji deverekê bistîne) ku dikare were sentezkirin û li pergalê bi barek ceribandinê têra xwe têra tiştê ku dê di hilberînê de be, were sepandin, di şert û mercên têra xwe ji bo xebatê di hilberînê de têra xwe.
Welê, em bihesibînin ku komek pîvanên verastkirinê ji bo vê pergala karûbarê tê zanîn, ku dikare were bikar anîn da ku vê pergalê di warê hilberîna xebata wê de mîheng bike.
Û pirsgirêk çi ye - têgihîştinek têra xwe ya bêkêmasî ya vê pergala karûbarê tune ye, ya ku dihêle hûn bi pisporî mîhengên vê pergalê ji bo barkirina pêşerojê li ser platformek diyarkirî mîheng bikin û hilberîna pêdivî ya pergalê bistînin.
Baş. Ev hema hema her tim wisa ye.
Hûn dikarin li vir çi bikin?
Welê, yekem tiştê ku tê hişê xwe ev e ku meriv li belgeya vê pergalê binêre. Fêm bikin ku rêzikên pejirandî ji bo nirxên pîvanên verastkirinê çi ne. Û, mînakî, bi karanîna rêbaza dakêşana hevrêziyê, di ceribandinan de ji bo pîvanên pergalê nirxan hilbijêrin.
Ewan. ji bo pîvanên veavakirina wê, di forma komek nirxan de, cûreyek veavakirinê bide pergalê.
Bi karanîna vê amûr-kêrhatî, jeneratorê barkirinê, barek ceribandinê li wê bicîh bikin.
Û li nirxê binêrin - bersiv, an pîvanek kalîteya pergalê.
Ramana duyemîn dibe ku encamek be ku ev demek pir dirêj e.
Welê, ev e: heke gelek pîvanên guheztinê hebin, ger rêzikên nirxên wan ên ku hatine pêçan mezin in, heke her ceribandinek barkirinê ya kesane ji bo temamkirina gelek dem digire, wê hingê: erê, ev hemî dibe ku rêjeyek nayê qebûl kirin ya demê.
Welê, li vir tiştê ku hûn dikarin fêm bikin û bîr bînin ev e.
Hûn dikarin fêr bibin ku di komek nirxên mîhengên pergala karûbarê de vektorek wekî rêzek hin nirxan heye.
Her vektorek wusa, ku tiştên din wekhev in (ku ew ji hêla vê vektorê ve nayê bandor kirin), bi nirxek bi tevahî diyar a metrikê re têkildar e - nîşanek kalîteya xebata pergalê di bin barek ceribandinê de.
E.E.
Ka em vektora veavakirina pergalê wekî destnîşan bikin 
ko ; Ko - hejmara parametreyên veavakirina pergalê, çend ji van parameteran hene.
Û nirxa metrîka ku bi vê re têkildar e em wê wekî destnîşan bikin
, wê hingê em fonksiyonek digirin:
Welê, wê gavê: her tişt tavilê tê, di doza min de: hema ji rojên xwendekariya min hatine ji bîr kirin, algorîtmayên ji bo lêgerîna ekstrama fonksiyonek.
Baş e, lê li vir pirsek rêxistinî û sepandî derdikeve holê: kîjan algorîtma bikar bîne.
- Di wateyê de - da ku hûn bi destan kêmtir kod bikin.
- Û ji bo ku ew bixebite, i.e. extremum dît (eger yek hebe), baş e, bi kêmanî ji daketina koordînat zûtir zûtir.
Xala yekem destnîşan dike ku pêdivî ye ku em li hin hawîrdorên ku tê de algorîtmayên weha hatine bicîh kirin, bigerin û, bi rengekî, ji bo karanîna kodê amade ne.
Belê, ez dizanim python и cran-r
Xala duyemîn tê vê wateyê ku hûn hewce ne ku li ser algorîtmayan bixwe bixwînin, ew çi ne, hewcedariyên wan çi ne, û taybetmendiyên xebata wan.
Û ya ku ew didin dikare bandorên alîgir ên kêrhatî be - encam, an rasterast ji algorîtmayê bixwe.
An jî ew dikarin ji encamên algorîtmayê werin wergirtin.
Pir tişt bi şert û mercên têketinê ve girêdayî ye.
Mînakî, heke, ji ber hin sedeman, hûn hewce ne ku encamek zûtir bi dest bixin, baş e, hûn hewce ne ku li algorîtmayên daketina gradientê bigerin û yek ji wan hilbijêrin.
An jî, heke dem ne ew qas girîng be, hûn dikarin, mînakî, rêbazên optimîzasyona stokastîk, wekî algorîtmayek genetîkî, bikar bînin.
Ez pêşniyar dikim ku xebata vê nêzîkatiyê, hilbijartina veavakirina pergalê, bi karanîna algorîtmayek genetîkî, di ya din de, bi vî rengî: xebata laboratîfê binirxînim.
Eslî:
- Bila wekî pergala karûbarê hebe:
oracle xe 18c - Bila ew ji çalakiya danûstendinê û armancê re xizmet bike: di danûstendinan / saniyeyê de gihandina herî zêde ya gengaz a bindatabasê bigire.
- Danûstandin dikare di cewherê xebata bi daneyan û çarçoveya xebatê de pir cûda be.
Werin em bipejirînin ku ev danûstendin in ku hejmareke mezin ji daneyên tabloyê napejirînin.
Di vê wateyê de ku ew ji nûvekirinê bêtir daneya betalkirinê naafirînin û rêjeyên mezin ên rêz û tabloyên mezin pêvajoyê nakin.
Vana danûstendinan in ku di tabloyek kêm-zêde mezin de yek rêzek diguhezînin, bi hejmarek piçûk li ser vê tabloyê.
Di vê rewşê de: hilberandina bindaneya ji bo danûstendinên pêvajoyê, bi veqetandinê, dê ji hêla kalîteya pêvajoyê ve ji hêla databasa redox ve were destnîşankirin.
Daxuyanî - heke em bi taybetî li ser mîhengên subdb-ê biaxivin.
Ji ber ku, di rewşa gelemperî de, dibe ku, ji ber sêwirana xebata bikarhêner bi daneyên tabloyî û/an modela tabloyê, ji bo nimûne, di navbera danişînên SQL de qefleyên danûstendinê hebin.
Ya ku, bê guman, dê bandorek depresyonê li ser metrika TPS-ê hebe û ev ê bibe faktorek biyanî, li gorî bindatabasê: Belê, bi vî rengî modela tabloyê hate sêwirandin û xebata bi daneya tê de ku blokan çêdibe.
Ji ber vê yekê, ji bo paqijiya ceribandinê, em ê vê faktorê derxînin, û li jêr ez ê tam çawa zelal bikim.
- Werin em bihesibînin, ji bo teqezbûnê, ku 100% ji emrên SQL yên ku ji databasê re têne şandin fermanên DML ne.
Bila taybetmendiyên bikarhênerê ku bi bindatabasê re dixebitin di ceribandinan de yek bin.
Ango: hejmara danişînên skl, daneyên tabloyê, danişînên skl çawa bi wan re dixebitin. - Subd di nav de dixebite
FORCE LOGGING,ARCHIVELOGmods. Moda Flashback-danûstandinê, di asta subd de tê girtin. - Têketinên dubare: di pergalek pelê ya cihê de, li ser "dîskek" veqetandî;
Beşa fizîkî ya mayî ya databasê: di pergala pelê ya din de, veqetandî, li ser "dîskek" veqetandî:
Agahiyên bêtir di derbarê cîhaza fîzîkî de. pêkhateyên databasa laboratîfê
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 0Di destpêkê de, di bin van şert û mercên barkirinê de, min xwest ku subd-ya danûstendinê bikar bînim
Taybetmendiyek wusa ecêb heye, ez ê ji nivîskarê vebêjim:
Di dilê SLOB de "rêbaza SLOB" heye. Rêbaza SLOB armanc dike ku platforman ceribandin
bêyî nakokiya serîlêdanê. Kes nikare performansa hardware ya herî zêde ajot bike
bikaranîna koda serîlêdanê ya ku, wek nimûne, bi girtina serîlêdanê ve girêdayî ye an jî heta
parvekirina blokên Oracle Database. Rast e - dema parvekirina daneyan serek heye
di blokên daneyan de! Lê SLOB-di danasîna xweya xwerû de- ji nakokiyên weha bêpar e.
Ev danezan: bihevre ye, ew e.
Birêkûpêkkirina asta paralelîzma danişînên cl rehet e, ev kilît e -t karûbar dest pê bike runit.sh ji SLOB
Rêjeya fermanên DML-ê têne rêve kirin, di hejmara peyamên nivîsê yên ku ji subd re têne şandin, her danişîna nivîsê, parametre UPDATE_PCT
Ji hev cuda û pir bi hêsanî: SLOB bi xwe, berî û piştî danişîna barkirinê - statspack, an wêneyên awr-ê amade dike (ya ku tête amadekirin).
Lêbelê, derket holê ku SLOB danişînên SQL yên bi dirêjahiya ji 30 çirkeyan kêmtir piştgirî nake.
Ji ber vê yekê, min pêşî guhertoya barkerê ya xweya, karker-gundî kod kir, û dûv re ew di xebitandinê de ma.
Bila ez zelal bikim ka barker çi dike û çawa dike, ji bo zelaliyê.
Di bingeh de barker bi vî rengî xuya dike:
Koda karker
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 dotxKarker bi vî rengî têne destpêkirin:
Karkerên diherikin
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Û tabloyên ji bo karkeran bi vî awayî têne amadekirin:
Çêkirina tabloyan
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"Ewan. Ji bo her karkerek (bi pratîkî: danişînek SQL-ya cihê ya di DB-ê de) tabloyek cihê tê çêkirin, ku karker pê re dixebite.
Ev nebûna qefleyên danûstendinê di navbera danişînên karker de misoger dike.
Her karker: eynî tiştî dike, bi maseya xwe, mase tev wek hev in.
Hemî karker di heman demê de kar dikin.
Wekî din, ji bo demek têra xwe dirêj da ku, mînakî, guhezek têketinê bê guman çêbibe, û ji carekê zêdetir.
Welê, li gorî vê yekê, lêçûn û bandorên têkildar derketin.
Di doza min de, min dema xebata karkeran di 8 hûrdeman de mîheng kir.
Parçeyek raporek statspack ku operasyona subd-ê di bin barkirinê de vedibêje
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.1Vegere ser karê laboratuarê.
Em ê, ku tiştên din wekhev bin, nirxên pîvanên jêrîn ên bin-danûstandina laboratîfê biguhezînin:
- Mezinahiya komên têketinên databasê. range nirx: [32, 1024] MB;
- Hejmara komên kovarê di databasê de. range nirx: [2,32];
log_archive_max_processesrange nirx: [1,8];commit_loggingdu nirx têne destûr kirin:batch|immediate;commit_waitdu nirx têne destûr kirin:wait|nowait;log_bufferrange nirxê: [2,128] MB.log_checkpoint_timeoutrange nirx: [60,1200] secondsdb_writer_processesrêjeya nirxê: [1,4]undo_retentionrange nirx: [30;300] secondstransactions_per_rollback_segmentrêjeya nirxê: [1,8]disk_asynch_iodu nirx têne destûr kirin:true|false;filesystemio_optionsnirxên jêrîn têne destûr kirin:none|setall|directIO|asynch;db_block_checkingnirxên jêrîn têne destûr kirin:OFF|LOW|MEDIUM|FULL;db_block_checksumnirxên jêrîn têne destûr kirin:OFF|TYPICAL|FULL;
Kesek xwedî ezmûn di domandina databasên Oracle de bê guman jixwe dikare bêje ka çi û ji kîjan nirxan divê were danîn, ji pîvanên diyarkirî û nirxên wan ên pejirandî, da ku ji bo xebata bi daneya ku ji hêla ve hatî destnîşan kirin hilberîneriyek mezin a databasê bigire. koda serîlêdanê, li vir li jor.
Lebê.
Mebesta xebata laboratîf ew e ku nîşan bide ku algorîtmaya xweşbîniyê bixwe dê vê yekê ji me re bi lez zelal bike.
Ji bo me, ya ku dimîne ev e ku em li belgeyê binihêrin, bi navgîniya pergala xwerû, tenê bes e ku em fêr bibin ka kîjan pîvan û di kîjan rêzan de biguhezînin.
Û her weha: koda kodê ku dê were bikar anîn da ku bi pergala xwerû ya algorîtmaya xweşbîniya bijartî re bixebite.
Ji ber vê yekê, niha li ser kodê.
Min li jor behsa wê kir cran-r, ango: Hemî manîpulasyonên bi pergala xwerû re di şeklê tîpek R de têne rêve kirin.
Karê rastîn, analîzkirin, hilbijartina ji hêla nirxa metrikê, vektorên rewşa pergalê: ev pakêtek e GA ()
Pakêt, di vê rewşê de, ne pir guncaw e, di vê wateyê de ku ew li bendê ye ku vektor (kromozom, heke di nav pakêtê de be) di şiklê rêzikên jimaran de bi parçeyek perçekirî bêne diyar kirin.
Û vektora min, ji nirxên pîvanên mîhengê: ev 14 hejmar in - hejmar û nirxên rêzê.
Pirsgirêk, bê guman, bi danasîna hin hejmarên taybetî li nirxên rêzikê bi hêsanî ji holê radibe.
Bi vî rengî, di dawiyê de, beşa sereke ya nivîsara R bi vî rengî xuya dike:
Gazî GA::ga bikin
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@solutionLi vir, bi alîkariyê lower и upper taybetmendiyên subroutine ga di bingeh de, deverek cîhê lêgerînê tê destnîşan kirin, ku di hundurê wê de dê lêgerînek ji bo vektorek (an vektorên) wusa were kirin ku ji bo wê nirxa herî zêde ya fonksiyona fitnessê were bidestxistin.
Binrûtina ga lêgerînek dike ku fonksiyona fitnessê zêde dike.
Welê, wê hingê, derdikeve holê ku, di vê rewşê de, pêdivî ye ku fonksiyona fitnessê, ku vektorê wekî komek nirxan ji bo hin parametreyên subd-ê fam dike, metrikek ji subd-ê werdigire.
Ango: çend, bi sazûmanek subd-ya diyarkirî û barek diyarkirî li ser subd-ê: subd her çirkeyê danûstendinan dike.
Ango, dema ku vedibe, divê pir-gavên jêrîn di hundurê fonksiyona fitnessê de bêne kirin:
- Pêvajoya vektora têketina jimareyan - veguheztina wê di nirxan de ji bo parametreyên jêrdane.
- Hewldanek ji bo afirandina hejmarek diyarkirî ya komên ji nû ve bi pîvanek diyarkirî. Wekî din, hewldan dibe ku neserketî be.
Komên kovarê yên ku ji berê ve di bindê de hebûn, di hin hejmar û hin mezinahî de, ji bo paqijiya ceribandinê - d.b. jêbirin. - Ger xala berê serketî be: diyarkirina nirxên pîvanên mîhengê li databasê (dîsa: dibe ku têkçûnek hebe)
- Ger gava berê serketî be: rawestandina subd-ê, destpêkirina subd-ê da ku nirxên parameterê yên ku nû hatine destnîşan kirin bandor bibin. (dîsa: dibe ku xeletiyek hebe)
- Ger gava berê serketî be: ceribandinek barkirinê bikin. metrîkan ji subd bistînin.
- Subd vegerîne rewşa wê ya bingehîn, ango. komên têketinê yên din jêbirin, veavakirina bindatabasê ya orîjînal vegerînin xebatê.
Koda fonksiyona fitnessê
evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")
opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")
opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
opn$disk_asynch_io="false"
}
opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
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)
}Va. hemî kar: di fonksiyona fitnessê de têne kirin.
Ga-subrûtîn vektoran, an jî, rasttir, kromozoman pêvajoyê dike.
Di vê yekê de, ya ku ji bo me ya herî girîng e, hilbijartina kromozomên bi genan e ku fonksiyona fitnessê ji bo wan nirxên mezin çêdike.
Ev, di eslê xwe de, pêvajoya lêgerîna li komek kromozoman a çêtirîn e ku vektorek di cîhek lêgerîna N-dimensîyonî de bikar tîne.
Pir zelal, berfireh , bi mînakên R-kodê, karê algorîtmayek genetîkî.
Ez dixwazim du xalên teknîkî ji hev veqetînim.
Bangên Alîkarî ji fonksiyonê evaluate, mînakî, rawestan-destpêk, danîna nirxa parameterê subd, li ser bingehê têne kirin cran-r fonksiyonên system2
Bi arîkariya ku: hin tîpên bash an ferman tê gotin.
Bo nimûne:
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)
}
}Xala duyemîn xet e, evaluate fonksiyonên, bi tomarkirina nirxek metrîkek taybetî û vektora wê ya guncandî ya têkildar li pelek têketinê:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Ev girîng e, ji ber ku ji vê berhevoka daneyê, dê mimkun be ku meriv agahdariya zêde li ser kîjan ji hêmanên vektora tunekirinê bandorek mezin an kêmtir li ser nirxa metrîkê heye bigire.
Ango: dê gengaz be ku analîza taybetmendî-importamce were kirin.
Îcar çi dibe bila bibe?
Di forma grafîkê de, heke hûn ceribandinan bi rêza metrîka hilkişînê ferman bikin, wêne wiha ye:
Hin daneyên ku bi nirxên giran ên metrikê re têkildar in:
Li vir, di dîmendera bi encaman re, ez ê zelal bikim: nirxên vektora tunekirinê di warê koda fonksiyonê ya fitnessê de têne dayîn, ne di warê navnîşa hejmarê ya pîvanan / rêzikên nirxên parametreyê de, ku hatî formule kirin. jorîn di nivîsê de.
Baş. Pir an hindik e, ~ 8 hezar tps: pirsek cuda.
Di çarçoveya xebatên laboratîfê de ev jimar ne girîng e, ya girîng dînamîk e, ev nirx çawa diguhere.
Dînamîkên li vir baş in.
Eşkere ye ku bi kêmanî yek faktor bi girîngî bandorê li nirxa metrikê, ga-algorîtmayê dike, ku di nav vektorên kromozomê de dabeş dibe: nixumandî.
Li gorî dînamîkên berbiçav ên nirxên kemerê dadbar bikin, bi kêmanî faktorek din heye ku her çend pir piçûktir be jî, lê bandorek wê heye.
Ev cihê ku hûn hewce ne attribute-importance analîz kirin ku fêm bikin ka kîjan taybetmendî (baş, di vê rewşê de, hêmanên vektora guheztinê) û ew çiqas bandorê li nirxa metrikê dikin.
Û ji vê agahiyê: fêm bikin ka kîjan faktor ji guhertinên di taybetmendiyên girîng de bandor bûne.
Dardekirin attribute-importance bi awayên cuda mimkun e.
Ji bo van armancan, ez ji algorîtmayê hez dikim randomForest pakêta R ya bi heman navî ()
randomForest, wekî ku ez xebata wî bi gelemperî û nêzîkatiya wî ya ji bo nirxandina girîngiya taybetmendiyan bi taybetî fam dikim, modelek diyar a girêdayîbûna guhêrbara bersivê bi taybetmendiyan ava dike.
Di rewşa me de, guhêrbar bersivê metrîkek e ku di ceribandinên barkirinê de ji databasê hatî wergirtin: tps;
Û taybetmendî hêmanên vektora tunekirinê ne.
Ji ber vê yekê li vir randomForest girîngiya her taybetmendiya modelê bi du hejmaran dinirxîne: %IncMSE - çawa hebûn/nebûna vê taybetmendiyê di modelekê de qalîteya MSE ya vê modelê diguhezîne (Çewtiya Mean Squared);
In IncNodePurity jimareyek e ku li ser bingeha nirxên vê taybetmendiyê çiqas baş nîşan dide, danûstendinek bi çavdêriyan dikare were dabeş kirin, da ku di beşek de daneyên bi yek nirxa metrîkê ku tê ravekirin heye, û li ya din jî bi nirxek din a metrikê.
Welê, ew e: ev ta çi astê taybetmendiyek dabeşker e (min li ser RandomForest ravekirina herî zelal, bi zimanê rûsî dît ).
Koda R-ya karker-gundî ji bo hilberandina danûstendinek bi encamên ceribandinên barkirinê:
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$importanceHûn dikarin rasterast bi destên xwe hîperparametreyên algorîtmayê hilbijêrin û, balkişandina li ser kalîteya modelê, modelek hilbijêrin ku pêşbîniyên li ser daneya pejirandinê rasttir pêk tîne.
Hûn dikarin ji bo vê xebatê cûreyek fonksiyonê binivîsin (bi awayê, dîsa, bi karanîna cûreyek algorîtmaya xweşbîniyê bikar tînin).
Hûn dikarin pakêta R bikar bînin caret, ne xal girîng e.
Wekî encamek, di vê rewşê de, encama jêrîn tête wergirtin ku asta girîngiya taybetmendiyan binirxînin:
Baş. Bi vî rengî, em dikarin refleksa gerdûnî dest pê bikin:
- Derket holê ku ya herî girîng, di bin van şert û mercên ceribandinê de, pîvan bû
commit_wait
Ji hêla teknîkî ve, ew moda darvekirinê ya operasyona io ya nivîsandina daneya ji nû ve ji tampona têketinê ya subdb-ê heya koma têketinê ya heyî diyar dike: hevdem an asynkron.
nirxênowaitku di encamê de hema hema vertîkal, zêdebûnek pirjimar di nirxa metrika tps de çêdibe: ev tevlêbûna moda io ya asînkron di komên ji nûve de ye.
Pirsek cûda ev e ku gelo divê hûn vê yekê di databasek xwarinê de bikin an na. Li vir ez bi tenê dibêjim: ev faktorek girîng e. - Mantiqî ye ku mezinahiya tampona têketinê ya subd-ê: dibe faktorek girîng.
Mezinahiya tampona têketinê her ku piçûktir be, kapasîteya wê ya tampon kêm dibe, ew qas pir caran ew diherike û/an nekaribûna veqetandina deverek belaş tê de ji bo beşek daneyên redoxê yên nû.
Ev tê vê wateyê: dereng bi veqetandina cîhê di tampona têketinê de û/an girtina daneya ji nûvekirinê ji wê ve di nav komên ji nû ve ve girêdayî ye.
Ev dereng, bê guman, divê û bandorê li ser karûbarê databasê ji bo danûstandinan bikin. - Parîsê
db_block_checksum: Baş e, di heman demê de, bi gelemperî ew eşkere ye - pêvajoyek danûstendinê dibe sedema avakirina blokên darty di cache tamponê ya bindatabasê de.
Kîjan, dema ku kontrolkirina danûstendinên blokên daneyê çalak e, pêdivî ye ku databas pêvajo bike - van jimareyên kontrolê ji laşê bloka daneyê bihesibîne, wan bi tiştê ku di sernavê bloka daneyê de hatî nivîsandin ve kontrol bike: lihevhatî / li hev nayê.
Xebatek wusa, dîsa, nikare pêvajoya daneyê dereng bixe, û li gorî vê yekê, pîvan û mekanîzmaya ku vê parameterê destnîşan dike girîng dibe.
Ji ber vê yekê firoşkar, di belgeya vê parameterê de, ji bo wê (parametre) nirxên cihêreng pêşkêşî dike û destnîşan dike ku erê, dê bandorek hebe, lê baş e, hûn dikarin nirxên cihêreng hilbijêrin, heya "off" û bandorên cuda.
Belê, encamek gerdûnî.
Nêzîkatî, bi gelemperî, pir bikêr derdikeve holê.
Ew bi xwe rê dide, di qonaxên destpêkê yên ceribandina barkirinê ya pergalek karûbarek diyarkirî de, ji bo ku veavakirina wê ya (pergalê) çêtirîn ji bo barkirinê hilbijêrin, ne ku pir di nav taybetmendiyên sazkirina pergalê de ji bo barkirinê hûr bibin.
Lê ew bi tevahî jê dernaxe - bi kêmanî di asta têgihiştinê de: pêdivî ye ku pergal li ser "pêlên eyarkirinê" û rêzikên destûr ên zivirandina van girêkan were zanîn.
Dûv re nêzîkatî dikare bi rengek zû veavakirina pergalê ya çêtirîn bibîne.
Û li ser bingeha encamên ceribandinê, gengaz e ku meriv di derheqê xwezaya têkiliya di navbera pîvanên performansa pergalê û nirxên pîvanên mîhengên pergalê de agahdarî werbigire.
Ya ku, bê guman, divê di derketina holê ya vê têgihiştina pir kûr a pergalê, xebata wê de, bi kêmanî di bin barek diyar de, bibe alîkar.
Di pratîkê de, ev danûstendina lêçûnên têgihîştina pergala xwerû ya ji bo lêçûnên amadekirina ceribandinek wusa ya pergalê ye.
Ez dixwazim ji hev veqetînim: Di vê nêzîkatiyê de, asta têrbûna ceribandina pergalê ji şert û mercên xebitandinê yên ku ew ê di xebata bazirganî de hebe pir girîng e.
Spas ji bo baldarî û dema we.
Source: www.habr.com