Hello
Ég ákvað að deila uppgötvuninni minni - ávöxtum hugsunar, reynslu og villu.
Í stórum dráttum: þetta er auðvitað ekki uppgötvun - allt þetta ætti að hafa verið vitað í langan tíma, fyrir þá sem taka þátt í hagnýtri tölfræðilegri gagnavinnslu og hagræðingu hvers kyns kerfa, ekki endilega DBMS sérstaklega.
Og: já, þeir vita, þeir skrifa áhugaverðar greinar um rannsóknir sínar, (UPD.: í athugasemdum bentu þeir á mjög áhugavert verkefni: )
Á hinn bóginn: í ósköpunum sé ég ekki að minnst sé á eða dreift þessari nálgun á Netinu meðal upplýsingatæknisérfræðinga, DBA.
Svo, að efninu.
Gefum okkur að við höfum verkefni: að setja upp ákveðið þjónustukerfi til að þjónusta einhvers konar vinnu.
Það er vitað um þetta verk: hvað það er, hvernig gæði þessarar vinnu eru mæld og hver er viðmiðunin til að mæla þessi gæði.
Við skulum líka gera ráð fyrir að það sé meira og minna vitað og skilið: nákvæmlega hvernig vinna fer fram í (eða með) þessu þjónustukerfi.
„Meira eða minna“ - þetta þýðir að það er hægt að undirbúa (eða fá það einhvers staðar frá) tiltekið tól, tól, þjónustu sem hægt er að búa til og nota á kerfið með prófunarálagi sem nægir til þess sem verður í framleiðslu, við aðstæður sem nægja til að vinna í framleiðslu.
Jæja, við skulum gera ráð fyrir að sett af aðlögunarbreytum fyrir þetta þjónustukerfi sé þekkt, sem hægt er að nota til að stilla þetta kerfi með tilliti til framleiðni vinnu þess.
Og hvað er vandamálið - það er ekki nægilega fullkominn skilningur á þessu þjónustukerfi, sá sem gerir þér kleift að stilla stillingar þessa kerfis með faglegum hætti fyrir framtíðarálag á tilteknum vettvangi og fá nauðsynlega framleiðni kerfisins.
Jæja. Þetta er nánast alltaf raunin.
Hvað getur þú gert hér?
Jæja, það fyrsta sem kemur upp í hugann er að skoða skjölin fyrir þetta kerfi. Skildu hver ásættanleg svið eru fyrir gildi aðlögunarbreytanna. Og, til dæmis, með því að nota hnitmiðunaraðferðina, veldu gildi fyrir kerfisfæribreytur í prófunum.
Þeir. gefðu kerfinu einhvers konar uppsetningu, í formi tiltekins setts af gildum fyrir stillingarbreytur þess.
Settu prufuálag á það með því að nota þetta mjög tól-tól, hleðslurafall.
Og líttu á gildið - viðbrögðin, eða mælikvarða á gæði kerfisins.
Seinni hugsunin gæti verið niðurstaðan að þetta sé mjög langur tími.
Jæja, það er: ef það eru margar stillingarfæribreytur, ef gildissvið þeirra sem fjallað er um er stórt, ef hvert einstakt álagspróf tekur mikinn tíma að klára, þá: já, allt þetta gæti tekið óviðunandi magn tímans.
Jæja, hér er það sem þú getur skilið og munað.
Þú getur komist að því að í gildum færibreytum þjónustukerfisstillinga er vektor, sem röð nokkurra gilda.
Hver slíkur vigur, að öðru óbreyttu (að því leyti að hann hefur ekki áhrif á þennan vektor), samsvarar algjörlega ákveðnu gildi mæligildisins - vísbending um gæði reksturs kerfisins undir prófunarálagi.
Þ.e.
Við skulum tákna kerfisstillingarvigur sem 
hvar ; Hvar — fjöldi kerfisstillingarfæribreyta, hversu margar af þessum færibreytum eru til.
Og gildi mæligildisins sem samsvarar þessu við skulum tákna það sem
, þá fáum við fall:
Jæja, þá: allt kemur strax niður á, í mínu tilfelli: næstum gleymt frá námstíma mínum, reiknirit til að leita að ysta hluta falls.
Allt í lagi, en hér vaknar skipulagsleg og beitt spurning: hvaða reiknirit á að nota.
- Í skilningi - þannig að þú getur kóðað minna með höndunum.
- Og til að það virki, þ.e. fann öfga (ef það er einhver), ja, að minnsta kosti hraðar en hnit.
Fyrsti punkturinn gefur til kynna að við þurfum að horfa í átt að sumum umhverfi þar sem slík reiknirit hafa þegar verið innleidd og eru í einhverri mynd tilbúin til notkunar í kóða.
Jæja, ég veit python и cran-r
Annað atriðið þýðir að þú þarft að lesa um reikniritin sjálf, hver þau eru, hverjar kröfur þeirra eru og eiginleika vinnu þeirra.
Og það sem þeir gefa geta verið gagnlegar aukaverkanir - niðurstöður, eða beint frá reikniritinu sjálfu.
Eða þeir geta verið fengnir úr niðurstöðum reikniritsins.
Mikið veltur á inntaksskilyrðum.
Til dæmis, ef þú þarft af einhverjum ástæðum að fá niðurstöðu hraðar, jæja, þú þarft að horfa í átt að halla reikniritum og velja einn af þeim.
Eða ef tíminn er ekki svo mikilvægur geturðu til dæmis notað stochastic hagræðingaraðferðir, eins og erfðafræðilegt reiknirit.
Ég legg til að íhuga vinnu þessarar nálgunar, val á kerfisstillingu, með því að nota erfðafræðilegt reiknirit, í næstu, ef svo má segja: rannsóknarstofuvinnu.
Upprunalegt:
- Látum það vera, sem þjónustukerfi:
oracle xe 18c - Láttu það þjóna viðskiptavirkni og markmiðinu: að fá sem mesta afköst undirgagnagrunnsins, í færslum/sek.
- Viðskipti geta verið mjög mismunandi í eðli vinnu með gögn og samhengi vinnunnar.
Við skulum vera sammála um að þetta séu viðskipti sem vinna ekki mikið magn af töflugögnum.
Í þeim skilningi að þeir búa ekki til fleiri afturköllunargögn en endurtaka og vinna ekki úr stórum hlutfalli af línum og stórum töflum.
Þetta eru færslur sem breyta einni línu í meira eða minna stórri töflu, með fáum vísitölum á þessari töflu.
Í þessum aðstæðum: framleiðni undirgagnagrunnsins fyrir vinnslu viðskipta mun, með fyrirvara, ráðast af gæðum vinnslu enduroxunargagnagrunnsins.
Fyrirvari - ef við tölum sérstaklega um subdb stillingarnar.
Vegna þess að í almennu tilvikinu geta til dæmis verið viðskiptalæsingar á milli SQL lota, vegna hönnunar notendavinnu með töflugögn og/eða töflulíkanið.
Sem að sjálfsögðu mun hafa niðurdrepandi áhrif á TPS mæligildið og þetta mun vera utanaðkomandi þáttur, miðað við undirgagnagrunninn: jæja, svona var töflulíkanið hannað og vinnan með gögnin í því að stíflur eiga sér stað.
Þess vegna, fyrir hreinleika tilraunarinnar, munum við útiloka þennan þátt og hér að neðan mun ég skýra nákvæmlega hvernig.
- Gefum okkur, til að vera viss, að 100% af SQL skipunum sem sendar eru í gagnagrunninn séu DML skipanir.
Látið eiginleika notendavinnu með undirgagnagrunninum vera þau sömu í prófunum.
Nefnilega: fjöldi skl fundur, töflugögn, hvernig skl fundur vinna með þeim. - Subd virkar í
FORCE LOGGING,ARCHIVELOGmods. Slökkt er á Flashback-gagnagrunnsham á subd stigi. - Endurtaka logs: staðsett í sérstöku skráarkerfi, á sérstökum „diski“;
Afgangurinn af efnishluta gagnagrunnsins: í öðru, aðskildu skráarkerfi, á sérstökum „diski“:
Nánari upplýsingar um líkamlega tækið. gagnagrunnshlutar rannsóknarstofu
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 0Upphaflega, við þessar hleðsluaðstæður, vildi ég nota viðskipta undird
Það hefur svo dásamlegan eiginleika, ég ætla að vitna í höfundinn:
Kjarninn í SLOB er „SLOB aðferðin“. SLOB aðferðin miðar að því að prófa vettvang
án umsóknardeilu. Maður getur ekki keyrt hámarksafköst vélbúnaðar
með því að nota forritakóða sem er til dæmis bundinn af forritalæsingu eða jafnvel
að deila Oracle gagnagrunnsblokkum. Það er rétt - það er kostnaður þegar deilt er gögnum
í gagnablokkum! En SLOB - í sjálfgefna uppsetningu sinni - er ónæmur fyrir slíkum deilum.
Þessi yfirlýsing: samsvarar, það er.
Það er þægilegt að stjórna hversu samhliða cl fundur er, þetta er lykillinn -t ræsa tólið runit.sh frá SLOB
Hlutfall DML skipana er stjórnað, í fjölda textaskilaboða sem eru send til undird, hver textalota, breytu UPDATE_PCT
Sér og mjög þægilegt: SLOB sjálft, fyrir og eftir hleðslulotuna - útbýr statspakka, eða awr-snapshots (það sem er stillt á að vera undirbúið).
Hins vegar kom í ljós að SLOB styður ekki SQL lotur sem eru styttri en 30 sekúndur.
Þess vegna kóðaði ég fyrst mína eigin, verkamanna-bóndaútgáfu af hleðslutækinu, og síðan hélt hún áfram.
Leyfðu mér að skýra hvað hleðslutækið gerir og hvernig það gerir það, til glöggvunar.
Í meginatriðum lítur hleðslutækið svona út:
Starfsmannakóði
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 dotxStarfsmenn eru settir af stað á þennan hátt:
Starfsmenn í gangi
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"
waitOg borð fyrir starfsmenn eru útbúin svona:
Að búa til töflur
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"Þeir. Fyrir hvern starfsmann (nánast: sérstök SQL lota í DB) er sérstök tafla sem starfsmaðurinn vinnur með.
Þetta tryggir fjarveru viðskiptalása á milli starfsmannalota.
Hver starfsmaður: gerir það sama, með sínu eigin borði eru borðin öll eins.
Allir starfsmenn vinna jafnlangan tíma.
Þar að auki, í nægilega langan tíma þannig að til dæmis logrofi myndi örugglega eiga sér stað, og oftar en einu sinni.
Jæja, í samræmi við það kom tilheyrandi kostnaður og áhrif.
Í mínu tilfelli stillti ég lengd vinnu starfsmanna á 8 mínútur.
Hluti af statspack skýrslu sem lýsir starfsemi subd undir álagi
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.1Aftur í rannsóknarstofuvinnuna.
Við munum, að öðru óbreyttu, breyta gildum eftirfarandi stika í undirgagnagrunni rannsóknarstofu:
- Stærð gagnagrunnsskrárhópa. gildissvið: [32, 1024] MB;
- Fjöldi tímaritahópa í gagnagrunninum. gildissvið: [2,32];
log_archive_max_processesgildissvið: [1,8];commit_loggingtvö gildi eru leyfð:batch|immediate;commit_waittvö gildi eru leyfð:wait|nowait;log_buffergildissvið: [2,128] MB.log_checkpoint_timeoutgildissvið: [60,1200] sekúndurdb_writer_processesgildissvið: [1,4]undo_retentiongildissvið: [30;300] sekúndurtransactions_per_rollback_segmentgildissvið: [1,8]disk_asynch_iotvö gildi eru leyfð:true|false;filesystemio_optionseftirfarandi gildi eru leyfð:none|setall|directIO|asynch;db_block_checkingeftirfarandi gildi eru leyfð:OFF|LOW|MEDIUM|FULL;db_block_checksumeftirfarandi gildi eru leyfð:OFF|TYPICAL|FULL;
Einstaklingur sem hefur reynslu af viðhaldi Oracle gagnagrunna getur vissulega þegar sagt til hvers og hvaða gildi ætti að setja, út frá tilgreindum breytum og ásættanlegum gildum þeirra, til að fá meiri framleiðni gagnagrunnsins fyrir vinnu með gögnum sem tilgreind eru af umsóknarkóðann, hér að ofan.
En.
Tilgangurinn með rannsóknarstofuvinnunni er að sýna fram á að hagræðingaralgrímið sjálft skýrir þetta tiltölulega fljótt fyrir okkur.
Fyrir okkur er allt sem eftir er að skoða skjalið, í gegnum sérhannaðar kerfið, bara nóg til að finna út hvaða breytur á að breyta og á hvaða sviðum.
Og einnig: kóðaðu kóðann sem verður notaður til að vinna með sérsniðnu kerfi valins hagræðingaralgríms.
Svo, nú um kóðann.
Ég talaði hér að ofan um cran-r, þ.e.: allar meðhöndlun með sérsniðna kerfinu er skipulögð í formi R-handrits.
Raunverulegt verkefni, greining, val eftir mæligildi, kerfisástandsvigrar: þetta er pakki GA ()
Pakkinn, í þessu tilfelli, er ekki mjög hentugur, í þeim skilningi að hann býst við að vektorar (litningar, ef miðað við pakkann) séu tilgreindir í formi talnastrengja með brotahluta.
Og vektorinn minn, frá gildum stillingarbreytanna: þetta eru 14 stærðir - heiltölur og strengjagildi.
Vandamálið er auðvitað auðvelt að forðast með því að tengja ákveðnar tölur við strengjagildi.
Þannig að lokum lítur aðalhlutinn af R handritinu svona út:
Hringdu í 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@solutionHér með hjálp lower и upper undirrútínueiginleika ga Í meginatriðum er svæði leitarrýmisins tilgreint, þar sem leitað verður að slíkum vektor (eða vektorum) sem hámarksgildi líkamsræktaraðgerðarinnar verður fengin fyrir.
Ga undirrútínan framkvæmir leit sem hámarkar líkamsræktaraðgerðina.
Jæja, þá kemur í ljós að í þessu tilfelli er nauðsynlegt að líkamsræktarfallið, sem skilur vigurinn sem gildismengi fyrir ákveðnar færibreytur subd, fái mæligildi frá subd.
Það er: hversu margir, með tiltekinni subd uppsetningu og tilteknu álagi á subd: subd vinnur viðskipti á sekúndu.
Það er að segja að þegar það er að þróast verður að framkvæma eftirfarandi fjölþrepa í líkamsræktaraðgerðinni:
- Vinnsla inntaksvektors talna - umbreytir honum í gildi fyrir undirgagnabreyturnar.
- Tilraun til að búa til tiltekinn fjölda endurgerða hópa af ákveðinni stærð. Þar að auki gæti tilraunin verið árangurslaus.
Tímarithópar sem þegar voru til í subd, í einhverju magni og af einhverri stærð, fyrir hreinleika tilraunarinnar - d.b. eytt. - Ef fyrri liður heppnast: að tilgreina gildi stillingarfæribreyta í gagnagrunninn (aftur: það gæti verið bilun)
- Ef fyrra skrefið heppnast: stöðva subd, byrja subd þannig að nýtilgreind færibreytugildi taki gildi. (aftur: það gæti verið galli)
- Ef fyrra skrefið heppnast: framkvæma álagspróf. fáðu mælikvarða frá subd.
- Færa subd aftur í upprunalegt horf, þ.e. eyða viðbótarskrárhópum, skilaðu upprunalegu undirgagnagrunnsstillingunni til að virka.
Kóði fyrir líkamsræktaraðgerðir
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)
}Það. öll vinna: framkvæmt í líkamsræktaraðgerðinni.
Ga-undirrútínan vinnur vigra, eða réttara sagt, litninga.
Þar sem það sem er mikilvægast fyrir okkur er val á litningum með genum sem líkamsræktarvirknin framleiðir stór gildi fyrir.
Þetta er í raun ferlið við að leita að ákjósanlegu mengi litninga með því að nota vektor í N-víddar leitarrými.
Mjög skýrt, ítarlegt , með dæmum um R-kóða, verk erfðafræðilegs reiknirits.
Ég vil sérstaklega nefna tvö tæknileg atriði.
Hjálparsímtöl frá aðgerðinni evaluate, til dæmis, stöðva-byrja, stilla gildi subd færibreytunnar, eru framkvæmdar á grundvelli cran-r aðgerðir system2
Með hjálp sem: einhver bash skrift eða skipun er kölluð.
Til dæmis:
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)
}
}Annar punkturinn er línan, evaluate aðgerðir, með því að vista tiltekið mæligildi og samsvarandi stillingarvektor þess í annálaskrá:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Þetta er mikilvægt vegna þess að úr þessari gagnafylki verður hægt að fá viðbótarupplýsingar um hver af íhlutum stillivigtarins hefur meiri eða minni áhrif á mæligildið.
Það er: það verður hægt að framkvæma eiginda-mikilvægisgreiningu.
Svo hvað getur gerst?
Á myndriti, ef þú pantar prófin í hækkandi mæliröð, er myndin sem hér segir:
Sum gögn sem samsvara öfgagildum mæligildisins:
Hér, í skjáskotinu með niðurstöðunum, mun ég skýra: gildi stillingarvigursins eru gefin út með tilliti til hæfniaðgerðakóðans, ekki með tilliti til fjöldalistans yfir færibreytur/svið færibreytugilda, sem var mótaður ofar í textanum.
Jæja. Er það mikið eða lítið, ~8 þúsund tps: sérstök spurning.
Innan ramma rannsóknarstofu er þessi tala ekki mikilvæg, það sem skiptir máli er gangverkið, hvernig þetta gildi breytist.
Dýnamíkin hér er góð.
Það er augljóst að að minnsta kosti einn þáttur hefur veruleg áhrif á gildi mæligildisins, ga-reikniritið, sem flokkar litningaferana: hulið.
Miðað við nokkuð öflugt gangverk ferilgildanna er að minnsta kosti einn þáttur í viðbót sem hefur áhrif, þótt hann sé umtalsvert minni.
Þetta er þar sem þú þarft á því að halda attribute-importance greiningu til að skilja hvaða eiginleikar (jæja, í þessu tilfelli, þættir stillivigursins) og hversu mikil áhrif þeir hafa á mæligildið.
Og út frá þessum upplýsingum: skilja hvaða þættir voru fyrir áhrifum af breytingum á mikilvægum eiginleikum.
Framkvæma attribute-importance mögulegt á mismunandi vegu.
Í þessum tilgangi líkar mér við reikniritið randomForest R pakki með sama nafni ()
randomForest, eins og ég skil verk hans almennt og nálgun hans við mat á mikilvægi eiginda sérstaklega, byggir upp ákveðið líkan af því hversu háð svörunarbreytan er háð eigindunum.
Í okkar tilviki er svarbreytan mælikvarði sem fæst úr gagnagrunninum í álagsprófum: tps;
Og eiginleikar eru hluti af stillingarvektornum.
Svo hér randomForest metur mikilvægi hvers líkanseiginleika með tveimur tölum: %IncMSE — hvernig tilvist/fjarvera þessa eiginleika í líkani breytir MSE gæðum þessa líkans (Mean Squared Error);
Og IncNodePurity er tala sem endurspeglar hversu vel, byggt á gildum þessa eiginleika, er hægt að skipta gagnasafni með athugunum, þannig að í öðrum hlutanum eru gögn með einu gildi mæligildisins sem verið er að útskýra, og í hinum með annað gildi mæligildisins.
Jæja, það er: að hve miklu leyti er þetta flokkunareiginleiki (ég sá skýrustu skýringar á rússnesku á RandomForest ).
R-kóði verkamanna-bónda til að vinna úr gagnasafni með niðurstöðum álagsprófa:
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Þú getur beint valið ofurfæribreytur reikniritsins með höndum þínum og, með áherslu á gæði líkansins, valið líkan sem uppfyllir nákvæmari spár um staðfestingargagnagrunninn.
Þú getur skrifað einhvers konar aðgerð fyrir þessa vinnu (við the vegur, aftur, með því að nota einhvers konar hagræðingaralgrím).
Þú getur notað R pakkann caret, ekki málið er mikilvægt.
Fyrir vikið, í þessu tilfelli, fæst eftirfarandi niðurstaða til að meta hversu mikilvægi eiginleikarnir eru:
Jæja. Þannig getum við byrjað alþjóðlega íhugun:
- Það kemur í ljós að mikilvægasta, við þessar prófunaraðstæður, var breytan
commit_wait
Tæknilega tilgreinir það framkvæmdarham io aðgerðarinnar að skrifa endurgerð gögn úr subdb log biðminni yfir í núverandi log hóp: samstilltur eða ósamstilltur.
Gildinowaitsem leiðir til næstum lóðréttrar, margfaldrar hækkunar á gildi tps mæligildisins: þetta er innlimun ósamstillta io hamsins í endurgerða hópum.
Sérstök spurning er hvort þú ættir að gera þetta í matvælagagnagrunni eða ekki. Hér takmarka ég mig við að fullyrða: þetta er mikilvægur þáttur. - Það er rökrétt að stærð log buffer subd: reynist vera mikilvægur þáttur.
Því minni sem stærðarminnið er, því minni stuðpúðargeta hans, því oftar flæðir hann yfir og/eða vanhæfni til að úthluta lausu svæði í honum fyrir hluta nýrra redoxgagna.
Þetta þýðir: tafir í tengslum við úthlutun pláss í biðminni og/eða að endurtaka gögnum er hent úr því í endurgerða hópa.
Þessar tafir ættu auðvitað að hafa áhrif á afköst gagnagrunnsins fyrir viðskipti og gera það. - Viðfang
db_block_checksum: jæja, líka, almennt er það ljóst - færsluvinnsla leiðir til myndunar darty blokka í biðminni skyndiminni undirgagnagrunnsins.
Sem, þegar kveikt er á eftirlitstölum gagnablokka, þarf gagnagrunnurinn að vinna úr - reiknaðu þessar eftirlitssummur úr meginmáli gagnablokkarinnar, athugaðu þær með því sem er skrifað í gagnablokkahausnum: passar/passar ekki.
Slík vinna, aftur, getur ekki annað en tafið gagnavinnslu, og í samræmi við það reynist færibreytan og vélbúnaðurinn sem setur þessa færibreytu vera mikilvægur.
Þess vegna býður söluaðilinn, í skjölunum fyrir þessa færibreytu, mismunandi gildi fyrir hana (breytu) og tekur fram að já, það mun hafa áhrif, en, jæja, þú getur valið mismunandi gildi, allt að „off“ og mismunandi áhrif.
Jæja, alþjóðleg niðurstaða.
Aðferðin, almennt séð, reynist nokkuð vel.
Hann leyfir sér alveg, á fyrstu stigum álagsprófunar á tilteknu þjónustukerfi, til að velja (kerfis) bestu uppsetningu þess fyrir álagið, að kafa ekki of mikið í sérkenni þess að setja upp kerfið fyrir álagið.
En það útilokar það ekki alveg - að minnsta kosti á skilningsstigi: kerfið verður að vera þekkt um „stillingarhnappana“ og leyfilegt snúningssvið þessara hnappa.
Aðferðin getur þá tiltölulega fljótt fundið bestu kerfisuppsetninguna.
Og byggt á niðurstöðum prófana er hægt að fá upplýsingar um eðli sambandsins milli kerfisframmistöðumælinga og gilda breytu kerfisstillinga.
Sem auðvitað ætti að stuðla að því að þessi mjög djúpi skilningur á kerfinu, rekstri þess, að minnsta kosti undir ákveðnu álagi, myndist.
Í reynd er um að ræða skipti á kostnaði við að skilja sérsniðna kerfið fyrir kostnað við undirbúning slíkrar prófunar á kerfinu.
Ég vil taka sérstaklega fram: Í þessari nálgun skiptir miklu máli hversu fullnægjandi kerfisprófanir eru fyrir þær rekstrarskilyrði sem það mun hafa í atvinnurekstri.
Þakka þér fyrir athygli þína og tíma.
Heimild: www.habr.com