Wapendwa
Niliamua kushiriki nilichopata - matunda ya mawazo, majaribio na makosa.
Kwa ujumla: hii sio kupatikana, bila shaka - yote haya yanapaswa kujulikana kwa muda mrefu, kwa wale wanaohusika katika usindikaji wa data ya takwimu na uboreshaji wa mifumo yoyote, si lazima hasa DBMS.
Na: ndio, wanajua, wanaandika nakala za kupendeza kwenye utafiti wao, (UPD.: katika maoni walionyesha mradi wa kupendeza sana: )
Kwa upande mwingine: offhand sioni kutajwa au usambazaji wowote wa njia hii kwenye Mtandao kati ya wataalamu wa IT, DBA.
Hivyo, kwa uhakika.
Hebu tufikiri kwamba tuna kazi: kuanzisha mfumo fulani wa huduma ili kutumikia aina fulani ya kazi.
Inajulikana kuhusu kazi hii: ni nini, jinsi ubora wa kazi hii unavyopimwa, na ni kigezo gani cha kupima ubora huu.
Hebu pia tufikirie kuwa inajulikana zaidi au chini na inaeleweka: hasa jinsi kazi inafanywa katika (au kwa) mfumo huu wa huduma.
"Zaidi au kidogo" - hii inamaanisha kuwa inawezekana kuandaa (au kuipata kutoka mahali fulani) chombo fulani, matumizi, huduma ambayo inaweza kuunganishwa na kutumika kwa mfumo na mzigo wa mtihani wa kutosha kwa kile kitakachokuwa katika uzalishaji, katika hali ya kutosha kwa ajili ya kufanya kazi katika uzalishaji.
Naam, hebu tufikiri kwamba seti ya vigezo vya marekebisho ya mfumo huu wa huduma inajulikana, ambayo inaweza kutumika kusanidi mfumo huu kwa suala la tija ya kazi yake.
Na ni shida gani - hakuna ufahamu kamili wa kutosha wa mfumo huu wa huduma, ambayo hukuruhusu kusanidi kwa utaalam mipangilio ya mfumo huu kwa mzigo wa baadaye kwenye jukwaa fulani na kupata tija inayohitajika ya mfumo.
Vizuri. Hii ni karibu kila wakati.
Unaweza kufanya nini hapa?
Naam, jambo la kwanza linalokuja akilini ni kuangalia nyaraka za mfumo huu. Elewa ni safu zipi zinazokubalika kwa maadili ya vigezo vya marekebisho. Na, kwa mfano, kwa kutumia njia ya asili ya kuratibu, chagua maadili ya vigezo vya mfumo katika vipimo.
Wale. toa mfumo aina fulani ya usanidi, kwa namna ya seti maalum ya maadili kwa vigezo vyake vya usanidi.
Tumia mzigo wa majaribio kwake, kwa kutumia chombo hiki, jenereta ya kupakia.
Na angalia thamani - majibu, au metriki ya ubora wa mfumo.
Wazo la pili linaweza kuwa hitimisho kwamba hii ni muda mrefu sana.
Kweli, hiyo ni: ikiwa kuna vigezo vingi vya kuweka, ikiwa safu za maadili zinazoendeshwa ni kubwa, ikiwa kila mtihani wa mzigo wa mtu binafsi unachukua muda mwingi kukamilisha, basi: ndio, yote haya yanaweza kuchukua bila kukubalika. muda mrefu.
Kweli, hapa ndio unaweza kuelewa na kukumbuka.
Unaweza kujua kuwa katika seti ya maadili ya vigezo vya mipangilio ya mfumo wa huduma kuna vekta, kama mlolongo wa maadili fulani.
Kila vekta kama hiyo, vitu vingine kuwa sawa (kwa kuwa haiathiriwa na vekta hii), inalingana na dhamana ya uhakika kabisa ya metri - kiashiria cha ubora wa uendeshaji wa mfumo chini ya mzigo wa majaribio.
Mimi
Wacha tuonyeshe vekta ya usanidi wa mfumo kama 
Ambapo ; Wapi - idadi ya vigezo vya usanidi wa mfumo, ni ngapi kati ya vigezo hivi kuna.
Na thamani ya kipimo kinacholingana na hii hebu tuashirie kama
, kisha tunapata kazi:
Kweli, basi: kila kitu kinakuja chini, kwa upande wangu: karibu kusahaulika kutoka kwa siku za mwanafunzi wangu, algorithms ya kutafuta upeo wa kazi.
Sawa, lakini hapa swali la shirika na linalotumika linatokea: ni algorithm gani ya kutumia.
- Kwa maana - ili uweze kuandika chini kwa mkono.
- Na ili ifanye kazi, i.e. ilipata uliokithiri (ikiwa kuna moja), vizuri, angalau haraka kuliko asili ya kuratibu.
Hoja ya kwanza inadokeza kwamba tunahitaji kuangalia mazingira fulani ambayo kanuni hizo tayari zimetekelezwa, na ziko, kwa namna fulani, tayari kutumika katika msimbo.
Naam, najua python ΠΈ cran-r
Hoja ya pili inamaanisha kuwa unahitaji kusoma juu ya algorithms yenyewe, ni nini, mahitaji yao ni nini, na sifa za kazi zao.
Na kile wanachotoa kinaweza kuwa madhara muhimu - matokeo, au moja kwa moja kutoka kwa algorithm yenyewe.
Au wanaweza kupatikana kutoka kwa matokeo ya algorithm.
Mengi inategemea hali ya uingizaji.
Kwa mfano, ikiwa, kwa sababu fulani, unahitaji kupata matokeo haraka, vizuri, unahitaji kutazama algorithms ya asili ya gradient na uchague moja yao.
Au, ikiwa wakati sio muhimu sana, unaweza, kwa mfano, kutumia njia za uboreshaji wa stochastic, kama vile algorithm ya maumbile.
Ninapendekeza kuzingatia kazi ya mbinu hii, kuchagua usanidi wa mfumo, kwa kutumia algorithm ya maumbile, kwa ijayo, kwa kusema: kazi ya maabara.
Asili:
- Wacha iwe, kama mfumo wa huduma:
oracle xe 18c - Iruhusu itumike shughuli za muamala na lengo: kupata upitishaji wa juu zaidi wa hifadhidata ndogo, katika shughuli/sekunde.
- Miamala inaweza kuwa tofauti sana katika hali ya kufanya kazi na data na muktadha wa kazi.
Wacha tukubaliane kwamba hizi ni shughuli ambazo hazichakati idadi kubwa ya data ya jedwali.
Kwa maana kwamba hazitoi data zaidi ya kutendua kuliko kufanya upya na hazichakati asilimia kubwa ya safu mlalo na jedwali kubwa.
Hizi ni shughuli zinazobadilisha safu mlalo moja katika jedwali kubwa zaidi au kidogo, na idadi ndogo ya faharasa kwenye jedwali hili.
Katika hali hii: tija ya hifadhidata ndogo ya shughuli za usindikaji, kwa uhifadhi, itaamuliwa na ubora wa usindikaji na hifadhidata ya redox.
Kanusho - ikiwa tunazungumza haswa juu ya mipangilio ya subdb.
Kwa sababu, katika hali ya jumla, kunaweza kuwa, kwa mfano, kufuli za shughuli kati ya vikao vya SQL, kutokana na muundo wa kazi ya mtumiaji na data ya jedwali na / au mfano wa tabular.
Ambayo, kwa kweli, itakuwa na athari ya kufadhaisha kwenye metri ya TPS na hii itakuwa sababu ya nje, inayohusiana na hifadhidata ndogo: vizuri, hivi ndivyo muundo wa tabular ulivyoundwa na kazi iliyo na data ndani yake ambayo vizuizi vinatokea.
Kwa hiyo, kwa ajili ya usafi wa jaribio, tutaondoa jambo hili, na hapa chini nitafafanua jinsi gani.
- Hebu tuchukulie, kwa uhakika, kwamba 100% ya amri za SQL zilizowasilishwa kwenye hifadhidata ni amri za DML.
Acha sifa za mtumiaji kufanya kazi na hifadhidata ndogo ziwe sawa katika majaribio.
Yaani: idadi ya vikao vya skl, data ya jedwali, jinsi vikao vya skl vinavyofanya kazi nao. - Subd inafanya kazi ndani
FORCE LOGGING,ARCHIVELOGmods. Hali ya hifadhidata ya Flashback imezimwa, katika kiwango kidogo. - Rudia kumbukumbu: iko katika mfumo tofauti wa faili, kwenye "diski" tofauti;
Sehemu iliyobaki ya hifadhidata: katika mfumo mwingine, tofauti wa faili, kwenye "diski" tofauti:
Maelezo zaidi kuhusu kifaa halisi. vipengele vya hifadhidata vya maabara
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 0Hapo awali, chini ya hali hizi za mzigo, nilitaka kutumia subd ya ununuzi
Ina sifa nzuri sana, nitamnukuu mwandishi:
Kiini cha SLOB ni "mbinu ya SLOB." Mbinu ya SLOB inalenga kupima majukwaa
bila ubishi wa maombi. Mtu hawezi kuendesha utendaji wa juu wa maunzi
kutumia msimbo wa programu ambayo, kwa mfano, imefungwa na kufunga programu au hata
kushiriki vizuizi vya Hifadhidata ya Oracle. Hiyo ni kweli - kuna ziada wakati wa kushiriki data
katika vitalu vya data! Lakini SLOB - katika uwekaji wake chaguo-msingi - haina kinga dhidi ya ubishi kama huo.
Tamko hili: linalingana, ni.
Ni rahisi kudhibiti kiwango cha usawa wa vikao vya madarasa, hii ndio ufunguo -t kuzindua shirika runit.sh kutoka SLOB
Asilimia ya amri za DML inadhibitiwa, katika idadi ya ujumbe wa maandishi unaotumwa kwa subd, kila kipindi cha maandishi, parameta. UPDATE_PCT
Tofauti na kwa urahisi sana: SLOB yenyewe, kabla na baada ya kikao cha mzigo - huandaa statspack, au awr-snapshots (nini kilichowekwa kutayarishwa).
Hata hivyo, ikawa hivyo SLOB haiauni vipindi vya SQL vilivyo na muda wa chini ya sekunde 30.
Kwa hivyo, kwanza niliandika toleo langu mwenyewe, la wafanyikazi-wakulima wa kipakiaji, na kisha ikabaki kufanya kazi.
Acha nifafanue kile kipakiaji hufanya na jinsi inavyofanya, kwa uwazi.
Kimsingi kipakiaji kinaonekana kama hii:
Kanuni ya mfanyakazi
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 dotxWafanyakazi wanazinduliwa kwa njia hii:
Wafanyakazi wanaoendesha
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"
waitNa meza za wafanyikazi zimeandaliwa kama hii:
Kujenga meza
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"Wale. Kwa kila mfanyakazi (kivitendo: kikao tofauti cha SQL katika DB) meza tofauti imeundwa, ambayo mfanyakazi hufanya kazi nayo.
Hii inahakikisha kutokuwepo kwa kufuli za shughuli kati ya vikao vya wafanyikazi.
Kila mfanyakazi: hufanya kitu kimoja, na meza yake mwenyewe, meza zote ni sawa.
Wafanyakazi wote hufanya kazi kwa muda sawa.
Zaidi ya hayo, kwa muda mrefu wa kutosha ili, kwa mfano, kubadili kwa logi bila shaka kutokea, na zaidi ya mara moja.
Kweli, ipasavyo, gharama na athari zinazohusiana ziliibuka.
Kwa upande wangu, nilisanidi muda wa kazi ya wafanyikazi kwa dakika 8.
Kipande cha ripoti ya statspack inayoelezea utendakazi wa subd chini ya mzigo
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.1Kurudi kwa kazi ya maabara.
Sisi, vitu vingine kuwa sawa, tutabadilisha maadili ya vigezo vifuatavyo vya hifadhidata ndogo ya maabara:
- Ukubwa wa vikundi vya kumbukumbu za hifadhidata. anuwai ya thamani: [32, 1024] MB;
- Idadi ya vikundi vya majarida kwenye hifadhidata. anuwai ya thamani: [2,32];
log_archive_max_processesthamani mbalimbali: [1,8];commit_loggingmaadili mawili yanaruhusiwa:batch|immediate;commit_waitmaadili mawili yanaruhusiwa:wait|nowait;log_bufferanuwai ya thamani: [2,128] MB.log_checkpoint_timeoutanuwai ya thamani: sekunde [60,1200]db_writer_processesanuwai ya thamani: [1,4]undo_retentionanuwai ya thamani: [30;300] sekundetransactions_per_rollback_segmentanuwai ya thamani: [1,8]disk_asynch_iomaadili mawili yanaruhusiwa:true|false;filesystemio_optionsmaadili yafuatayo yanaruhusiwa:none|setall|directIO|asynch;db_block_checkingmaadili yafuatayo yanaruhusiwa:OFF|LOW|MEDIUM|FULL;db_block_checksummaadili yafuatayo yanaruhusiwa:OFF|TYPICAL|FULL;
Mtu aliye na uzoefu wa kutunza hifadhidata za Oracle anaweza kusema tayari ni nini na kwa maadili gani yanapaswa kuwekwa, kutoka kwa vigezo maalum na maadili yao yanayokubalika, ili kupata tija kubwa ya hifadhidata kwa kazi iliyo na data iliyoonyeshwa na. nambari ya maombi, hapa juu.
Lakini.
Hatua ya kazi ya maabara ni kuonyesha kwamba algorithm ya utoshelezaji yenyewe itatufafanulia hili kwa haraka.
Kwetu sisi, kilichobaki ni kuangalia hati, kupitia mfumo unaoweza kubinafsishwa, ya kutosha tu kujua ni vigezo gani vya kubadilisha na katika safu gani.
Na pia: weka nambari ambayo itatumika kufanya kazi na mfumo maalum wa algorithm iliyochaguliwa ya uboreshaji.
Kwa hiyo, sasa kuhusu kanuni.
Nilizungumza hapo juu cran-r, yaani: ghiliba zote zilizo na mfumo uliobinafsishwa zimepangwa kwa njia ya hati ya R.
Kazi halisi, uchambuzi, uteuzi kwa thamani ya metri, vekta za hali ya mfumo: hii ni kifurushi GA ()
Kifurushi, katika kesi hii, haifai sana, kwa maana kwamba inatarajia vectors (chromosomes, ikiwa ni kwa mujibu wa mfuko) kuwa maalum kwa namna ya masharti ya namba na sehemu ya sehemu.
Na vekta yangu, kutoka kwa maadili ya vigezo vya kuweka: hizi ni idadi 14 - nambari na maadili ya kamba.
Shida, kwa kweli, inaepukwa kwa urahisi kwa kugawa nambari maalum kwa maadili ya kamba.
Kwa hivyo, mwishowe, sehemu kuu ya hati ya R inaonekana kama hii:
Piga simu 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@solutionHapa, kwa msaada lower ΠΈ upper sifa za subroutine ga kimsingi, eneo la nafasi ya utaftaji limebainishwa, ambalo utaftaji utafanywa kwa vekta kama hiyo (au vekta) ambayo dhamana ya juu ya kazi ya usawa itapatikana.
Subroutine ya ga hufanya utafutaji ili kuongeza utendaji wa siha.
Kweli, basi, inabadilika kuwa, katika kesi hii, ni muhimu kwamba kazi ya usawa, kuelewa vekta kama seti ya maadili ya vigezo fulani vya subd, inapokea metric kutoka kwa subd.
Hiyo ni: ni ngapi, na usanidi uliopeanwa wa subd na mzigo uliopewa kwenye subd: shughuli ndogo huchakata kwa sekunde.
Hiyo ni, wakati wa kufunua, hatua nyingi zifuatazo lazima zifanyike ndani ya kazi ya usawa:
- Inasindika vekta ya pembejeo ya nambari - kuibadilisha kuwa maadili ya vigezo vya data ndogo.
- Jaribio la kuunda idadi fulani ya vikundi vya kufanya upya vya saizi fulani. Aidha, jaribio hilo linaweza kutofanikiwa.
Makundi ya majarida ambayo tayari yalikuwepo katika subd, kwa kiasi fulani na ya ukubwa fulani, kwa usafi wa majaribio - d.b. imefutwa. - Ikiwa hatua ya awali imefanikiwa: kubainisha maadili ya vigezo vya usanidi kwenye hifadhidata (tena: kunaweza kuwa na kutofaulu)
- Ikiwa hatua ya awali imefanikiwa: kusimamisha subd, kuanzia subd ili maadili mapya ya parameta yaanze kutumika. (tena: kunaweza kuwa na hitilafu)
- Ikiwa hatua ya awali imefanikiwa: fanya mtihani wa mzigo. pata vipimo kutoka kwa subd.
- Rudisha subd kwa hali yake ya awali, i.e. futa vikundi vya ziada vya kumbukumbu, rudisha usanidi wa hifadhidata asilia kufanya kazi.
Msimbo wa utendaji wa siha
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)
}Hiyo. kazi zote: zilizofanywa katika utendaji wa usawa.
Ga-subroutine huchakata vekta, au, kwa usahihi zaidi, kromosomu.
Ambayo, kilicho muhimu zaidi kwetu ni uteuzi wa chromosomes zilizo na jeni ambazo utendaji wa usawa hutoa maadili makubwa.
Huu, kimsingi, ni mchakato wa kutafuta seti mojawapo ya kromosomu kwa kutumia vekta katika nafasi ya utafutaji ya N-dimensional.
Wazi sana, kina , pamoja na mifano ya R-code, kazi ya algorithm ya maumbile.
Ningependa kutambua pointi mbili za kiufundi tofauti.
Simu za msaidizi kutoka kwa kitendakazi evaluate, kwa mfano, kuacha-kuanza, kuweka thamani ya parameter ndogo, hufanywa kwa kuzingatia cran-r kazi system2
Kwa msaada wa ambayo: hati fulani ya bash au amri inaitwa.
Kwa mfano:
set_db_parameta
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)
}
}Jambo la pili ni mstari, evaluate kazi, na kuhifadhi thamani maalum ya metri na vekta yake ya kurekebisha kwa faili ya kumbukumbu:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Hii ni muhimu, kwa sababu kutoka kwa safu hii ya data, itawezekana kupata maelezo ya ziada kuhusu ni sehemu gani ya vector ya kurekebisha ina athari kubwa au ndogo kwa thamani ya metri.
Hiyo ni: itawezekana kufanya uchambuzi wa umuhimu wa sifa.
Kwa hiyo nini kinaweza kutokea?
Katika fomu ya grafu, ikiwa utaagiza majaribio katika mpangilio wa metri ya kupanda, picha ni kama ifuatavyo.
Baadhi ya data inayolingana na maadili yaliyokithiri ya kipimo:
Hapa, kwenye picha ya skrini na matokeo, nitafafanua: maadili ya vekta ya kurekebisha hupewa kulingana na nambari ya kazi ya usawa, sio kwa suala la orodha ya nambari ya vigezo / safu za maadili ya parameta, ambayo iliundwa. hapo juu kwenye maandishi.
Vizuri. Ni nyingi au kidogo, ~tps elfu 8: swali tofauti.
Ndani ya mfumo wa kazi ya maabara, takwimu hii si muhimu, ni nini muhimu ni mienendo, jinsi thamani hii inavyobadilika.
Mienendo hapa ni nzuri.
Ni dhahiri kwamba angalau sababu moja huathiri kwa kiasi kikubwa thamani ya kipimo, ga-algorithm, kupanga kupitia vekta za kromosomu: zilizofunikwa.
Kwa kuzingatia mienendo yenye nguvu ya thamani za curve, kuna angalau sababu moja zaidi ambayo, ingawa ni ndogo sana, ina ushawishi.
Hapa ndipo unapoihitaji attribute-importance uchambuzi ili kuelewa ni sifa gani (vizuri, katika kesi hii, sehemu za vekta ya kurekebisha) na ni kiasi gani zinaathiri thamani ya metri.
Na kutoka kwa habari hii: kuelewa ni mambo gani yaliyoathiriwa na mabadiliko katika sifa muhimu.
Run attribute-importance iwezekanavyo kwa njia tofauti.
Kwa madhumuni haya, napenda algorithm randomForest R kifurushi cha jina moja ()
randomForest, ninavyoelewa kazi yake kwa ujumla na mbinu yake ya kutathmini umuhimu wa sifa hasa, hujenga kielelezo fulani cha utegemezi wa kutofautisha kwa majibu kwenye sifa.
Kwa upande wetu, tofauti ya majibu ni kipimo kilichopatikana kutoka kwa hifadhidata katika majaribio ya mzigo: tps;
Na sifa ni vipengele vya vector ya kurekebisha.
Hivyo hapa randomForest inatathmini umuhimu wa kila sifa ya mfano na nambari mbili: %IncMSE β jinsi uwepo/kutokuwepo kwa sifa hii katika modeli kunabadilisha ubora wa MSE wa modeli hii (Maana ya Hitilafu ya Mraba);
Na IncNodePurity ni nambari inayoonyesha jinsi vizuri, kulingana na maadili ya sifa hii, seti ya data iliyo na uchunguzi inaweza kugawanywa, ili katika sehemu moja kuna data iliyo na thamani moja ya metriki iliyoelezewa, na kwa nyingine na. thamani nyingine ya kipimo.
Kweli, hiyo ni: ni kwa kiwango gani hii ni sifa ya uainishaji (niliona maelezo ya wazi zaidi ya lugha ya Kirusi kwenye RandomForest ).
Msimbo wa R wa wafanyikazi-wakulima kwa usindikaji wa seti ya data na matokeo ya majaribio ya mzigo:
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$importanceUnaweza kuchagua moja kwa moja hyperparameters ya algorithm kwa mikono yako na, kwa kuzingatia ubora wa mfano, chagua mfano ambao unatimiza kwa usahihi utabiri kwenye hifadhidata ya uthibitisho.
Unaweza kuandika aina fulani ya kazi kwa kazi hii (kwa njia, tena, kwa kutumia aina fulani ya algorithm ya uboreshaji).
Unaweza kutumia kifurushi cha R caret, sio hatua ni muhimu.
Kama matokeo, katika kesi hii, matokeo yafuatayo yanapatikana ili kutathmini kiwango cha umuhimu wa sifa:
Vizuri. Kwa hivyo, tunaweza kuanza tafakari ya ulimwengu:
- Inabadilika kuwa muhimu zaidi, chini ya hali hizi za kupima, ilikuwa parameter
commit_wait
Kitaalam, inabainisha hali ya utekelezaji ya utendakazi wa io wa kuandika fanya upya data kutoka kwa bafa ya kumbukumbu ya subdb hadi kikundi cha kumbukumbu cha sasa: synchronous au asynchronous.
Thamaninowaitambayo husababisha ongezeko la karibu wima, nyingi katika thamani ya metriki ya tps: huu ni ujumuishaji wa modi ya io isiyolingana katika vikundi vya kufanya upya.
Swali tofauti ni ikiwa unapaswa kufanya hivi au la katika hifadhidata ya chakula. Hapa ninajiwekea kikomo kwa kusema tu: hii ni sababu muhimu. - Ni sawa kwamba saizi ya bafa ya logi ya subd: inageuka kuwa sababu muhimu.
Kadiri ukubwa wa bafa wa logi unavyopungua, uwezo wake wa kuakibisha mdogo, ndivyo inavyofurika mara nyingi zaidi na/au kutoweza kutenga eneo lisilolipishwa ndani yake kwa sehemu ya data mpya ya redox.
Hii inamaanisha: ucheleweshaji unaohusishwa na kutenga nafasi katika bafa ya kumbukumbu na/au kutupa data ya kufanya upya kutoka kwayo katika vikundi vya kufanya upya.
Ucheleweshaji huu, bila shaka, unapaswa kuathiri upitishaji wa hifadhidata kwa miamala. - Parameter
db_block_checksum: vizuri, pia, kwa ujumla ni wazi - usindikaji wa muamala husababisha uundaji wa vizuizi vya giza kwenye kashe ya hifadhidata ndogo.
Ambayo, wakati ukaguzi wa hesabu za vizuizi vya data umewezeshwa, hifadhidata lazima ichakata - kuhesabu hesabu hizi kutoka kwa sehemu ya hifadhidata, ziangalie na kile kilichoandikwa kwenye kichwa cha hifadhidata: mechi/hailingani.
Kazi kama hiyo, tena, haiwezi lakini kuchelewesha usindikaji wa data, na ipasavyo, parameta na utaratibu unaoweka parameta hii inageuka kuwa muhimu.
Ndio sababu muuzaji hutoa, katika nyaraka za paramu hii, maadili tofauti yake (parameta) na anabainisha kuwa ndio, kutakuwa na athari, lakini, vizuri, unaweza kuchagua maadili tofauti, hadi "kuzima" na. athari tofauti.
Naam, hitimisho la kimataifa.
Mbinu, kwa ujumla, inageuka kuwa inafanya kazi kabisa.
Anajiruhusu kabisa, katika hatua za mwanzo za upimaji wa mzigo wa mfumo fulani wa huduma, ili kuchagua (mfumo) usanidi wake bora kwa mzigo, sio kujipenyeza sana katika maalum ya kuanzisha mfumo wa mzigo.
Lakini haiizuii kabisa - angalau katika kiwango cha uelewa: mfumo lazima ujulikane juu ya "visu vya marekebisho" na safu zinazoruhusiwa za kuzunguka kwa visu hivi.
Mbinu basi inaweza kupata usanidi bora wa mfumo kwa haraka.
Na kwa kuzingatia matokeo ya upimaji, inawezekana kupata habari juu ya asili ya uhusiano kati ya metrics ya utendaji wa mfumo na maadili ya vigezo vya mipangilio ya mfumo.
Ambayo, bila shaka, inapaswa kuchangia kuibuka kwa ufahamu huu wa kina sana wa mfumo, uendeshaji wake, angalau chini ya mzigo fulani.
Kwa mazoezi, hii ni kubadilishana kwa gharama za kuelewa mfumo ulioboreshwa kwa gharama za kuandaa upimaji kama huo wa mfumo.
Ningependa kutambua tofauti: kwa njia hii, kiwango cha kutosha cha kupima mfumo kwa hali ya uendeshaji ambayo itakuwa nayo katika uendeshaji wa kibiashara ni muhimu sana.
Asante kwa umakini wako na wakati.
Chanzo: mapenzi.com