салам
Мен өзүмдүн табылгам менен бөлүшүүнү чечтим - ойдун жемиши, сыноо жана ката.
Жалпысынан алганда: бул табылга эмес, албетте - мунун баары, албетте, МБД эмес, ар кандай системаларды колдонуучу статистикалык маалыматтарды иштеп чыгуу жана оптималдаштыруу менен алектенгендерге көптөн бери белгилүү болушу керек болчу.
Жана: ооба, алар билишет, алар өздөрүнүн изилдөөлөрү боюнча кызыктуу макалаларды жазышат, (UPD.: комментарийлерде алар абдан кызыктуу долбоорду белгилешти: )
Башка жагынан алганда: мен бул ыкманы Интернетте IT адистери, DBA арасында кеңири жайылтканын же жайылтканын көргөн жокмун.
Ошентип, пунктка.
Келгиле, биздин алдыбызда милдет турат деп эсептейли: кандайдыр бир ишти тейлөө үчүн белгилүү бир тейлөө системасын түзүү.
Бул иш жөнүндө белгилүү: бул эмне, бул иштин сапаты кандайча өлчөнөт жана бул сапатты кандай критерий менен өлчөө керек.
Ал аздыр-көптүр белгилүү жана түшүнүктүү деп да коёлу: бул кызмат тутумунда (же менен) иш кандай аткарылат.
"Аздыр-көптүр" - бул өндүрүштө боло турган нерсеге адекваттуу сыноо жүктөмү менен синтезделе турган жана системага колдонула турган белгилүү бир куралды, утилитаны, кызматты даярдоого (же аны бир жерден алууга) мүмкүн экендигин билдирет. өндүрүштө иштөө үчүн жетиштүү шарттарда.
Келгиле, бул кызмат системасынын тууралоо параметрлеринин топтому белгилүү деп коёлу, алар бул системаны анын ишинин өндүрүмдүүлүгү боюнча конфигурациялоо үчүн колдонулушу мүмкүн.
Ал эми көйгөй эмнеде - бул кызмат системасы жөнүндө жетиштүү толук түшүнүк жок, бул системанын орнотууларын берилген платформада келечектеги жүктөө үчүн эксперттик конфигурациялоого жана системанын талап кылынган өндүрүмдүүлүгүн алууга мүмкүндүк берет.
жакшы. Бул дээрлик дайыма болот.
Бул жерде эмне кыла аласыз?
Ооба, акылга келген биринчи нерсе - бул системанын документтерин карап чыгуу. Жөндөө параметрлеринин маанилери үчүн алгылыктуу диапазондор кандай экенин түшүнүңүз. Жана, мисалы, координаттын түшүү ыкмасын колдонуп, тесттерде системанын параметрлери үчүн маанилерди тандаңыз.
Ошол. системага конфигурациянын кандайдыр бир түрүн, анын конфигурациясынын параметрлери үчүн маанилердин белгилүү бир топтому түрүндө бериңиз.
Бул курал-пайдалуу, жүк генераторун колдонуп, ага сыноо жүктү колдонуңуз.
Ал эми маанини караңыз - жооп же системанын сапатынын көрсөткүчү.
Экинчи ой бул абдан узак убакыт деген тыянак болушу мүмкүн.
Ооба, башкача айтканда: көп орнотуу параметрлери бар болсо, алардын аткарылып жаткан маанилеринин диапазону чоң болсо, ар бир жеке жүк сынагын аяктоо үчүн көп убакыт талап кылынса, анда: ооба, мунун баары кабыл алынгыс убакытты талап кылышы мүмкүн. узак убакыт.
Ооба, бул жерде сиз түшүнүп, эстей аласыз.
Кызмат тутумунун параметрлеринин маанилеринин топтомунда кээ бир маанилердин ырааттуулугу катары вектор бар экенин биле аласыз.
Ар бир мындай вектор, башка нерселер бирдей болгон (бул вектор ага таасир этпегендиги үчүн) метриканын толук белгилүү маанисине туура келет - сыноо жүктөмү астында системанын иштөө сапатынын көрсөткүчү.
башкача айтканда,
Системанын конфигурациясынын векторун деп белгилейли 
кайда ; Кайда — системанын конфигурациясынын параметрлеринин саны, бул параметрлердин канчасы бар.
Ал эми ушуга туура келген метриканын мааниси деп белгилейли
, анда биз функцияны алабыз:
Анда: баары дароо келип чыгат, менин учурда: студенттик күндөрүмдөн дээрлик унутулуп калган, функциянын экстремумун издөө алгоритмдери.
Макул, бирок бул жерде уюштуруучулук жана прикладдык суроо туулат: кайсы алгоритмди колдонуу керек.
- Мааниси боюнча - сиз кол менен азыраак код кыла аласыз.
- Жана анын иштеши үчүн, б.а. экстремумду (эгер бар болсо), координаттык түшүүдөн тезирээк тапты.
Биринчи пункт мындай алгоритмдер ишке ашырылган жана кандайдыр бир формада коддо колдонууга даяр болгон кээ бир чөйрөлөрдү карашыбыз керек экенин көрсөтүп турат.
Ооба, мен билем python и cran-r
Экинчи пункт, алгоритмдердин өздөрү, алар эмнелер, алардын талаптары кандай, алардын ишинин өзгөчөлүктөрү жөнүндө окуу керек дегенди билдирет.
Жана алар берген нерселер пайдалуу терс таасирлер болушу мүмкүн - натыйжалар же түздөн-түз алгоритмдин өзүнөн.
Же алар алгоритмдин натыйжаларынан алынышы мүмкүн.
Көп нерсе киргизүү шарттарынан көз каранды.
Мисалы, кандайдыр бир себептерден улам тезирээк натыйжага жетишиңиз керек болсо, анда градиенттин түшүү алгоритмдерин карап, алардын бирин тандап алышыңыз керек.
Же болбосо, убакыт анчалык деле маанилүү эмес болсо, анда, мисалы, генетикалык алгоритм сыяктуу стохастикалык оптималдаштыруу ыкмаларын колдоно аласыз.
Мен генетикалык алгоритмди колдонуп, системанын конфигурациясын тандап, кийинки, мындайча айтканда: лабораториялык ишти карап чыгууну сунуштайм.
Түпнуска:
- Кызмат системасы катары бар болсун:
oracle xe 18c - Ал транзакциялык ишмердүүлүккө кызмат кылсын жана максат: транзакциялар/сек менен поддеректер базасынын мүмкүн болгон эң жогорку өткөрүү жөндөмдүүлүгүн алуу.
- Транзакциялар маалыматтар менен иштөө мүнөзүндө жана иштин контекстинде өтө ар түрдүү болушу мүмкүн.
Келгиле, бул чоң көлөмдөгү таблицадагы маалыматтарды иштетпеген транзакциялар экенине макул бололу.
Алар кайра жасоого караганда жокко чыгаруу маалыматтарын жаратпайт жана саптардын жана чоң таблицалардын чоң пайызын иштетпейт деген мааниде.
Бул аздыр-көптүр чоң таблицада бир сапты өзгөрткөн транзакциялар, бул таблицада аз сандагы индекстер.
Мындай кырдаалда: транзакцияларды кайра иштетүү үчүн поддеректер базасынын өндүрүмдүүлүгү резерв менен редокс базасы тарабынан кайра иштетүүнүн сапаты менен аныкталат.
Disclaimer - эгерде биз subdb жөндөөлөрү жөнүндө айтсак.
Анткени, жалпы учурда, мисалы, SQL сеанстарынын ортосунда транзакциялык кулпулар болушу мүмкүн, бул колдонуучунун таблица маалыматтары жана/же таблица модели менен иштөөсүнүн дизайнына байланыштуу.
Бул, албетте, TPS метрикасына депрессиялык таасирин тийгизет жана бул суббазага салыштырмалуу экзогендик фактор болот: так, таблица модели ушундайча иштелип чыккан жана андагы маалыматтар менен иштөө бөгөттөлгөн.
Ошондуктан, эксперименттин тазалыгы үчүн биз бул факторду жокко чыгарабыз жана төмөндө кантип так түшүндүрөм.
- Келгиле, тактык үчүн, маалымат базасына берилген SQL буйруктарынын 100% DML буйруктары деп ойлойлу.
Колдонуучунун поддеректер базасы менен иштөө мүнөздөмөлөрү тесттерде бирдей болсун.
Тактап айтканда: skl сессияларынын саны, таблицадагы маалыматтар, skl сессиялары алар менен кантип иштейт. - Subd иштейт
FORCE LOGGING,ARCHIVELOGmods. Flashback-маалымат базасы режими өчүрүлгөн, subd деңгээлинде. - Журналдарды кайталоо: өзүнчө файл тутумунда, өзүнчө "дискте" жайгашкан;
Маалымат базасынын физикалык компонентинин калган бөлүгү: башка, өзүнчө файл тутумунда, өзүнчө "дискте":
Физикалык түзмөк жөнүндө көбүрөөк маалымат. лабораториялык маалыматтар базасынын компоненттери
SQL> select status||' '||name from v$controlfile;
/db/u14/oradata/XE/control01.ctl
SQL> select GROUP#||' '||MEMBER from v$logfile;
1 /db/u02/oradata/XE/redo01_01.log
2 /db/u02/oradata/XE/redo02_01.log
SQL> select FILE_ID||' '||TABLESPACE_NAME||' '||round(BYTES/1024/1024,2)||' '||FILE_NAME as col from dba_data_files;
4 UNDOTBS1 2208 /db/u14/oradata/XE/undotbs1_01.dbf
2 SLOB 128 /db/u14/oradata/XE/slob01.dbf
7 USERS 5 /db/u14/oradata/XE/users01.dbf
1 SYSTEM 860 /db/u14/oradata/XE/system01.dbf
3 SYSAUX 550 /db/u14/oradata/XE/sysaux01.dbf
5 MONITOR 128 /db/u14/oradata/XE/monitor.dbf
SQL> !cat /proc/mounts | egrep "/db/u[0-2]"
/dev/vda1 /db/u14 ext4 rw,noatime,nodiratime,data=ordered 0 0
/dev/mapper/vgsys-ora_redo /db/u02 xfs rw,noatime,nodiratime,attr2,nobarrier,inode64,logbsize=256k,noquota 0 0Башында, ушул жүктөө шарттарында мен транзакция subd колдонгум келди
Анын ушундай сонун өзгөчөлүгү бар, мен автордун сөзүн келтирейин:
SLOBдин өзөгүн "SLOB ыкмасы" түзөт. SLOB методу платформаларды сыноого багытталган
арыз талашсыз. Бири максималдуу аппараттык өндүрүмдүүлүгүн айдай албайт
Колдонмо кодун колдонуу, мисалы, колдонмо кулпусу менен байланышкан же ал тургай
Oracle Database блокторун бөлүшүү. Туура — берилиштерди бөлүшүүдө кошумча чыгымдар бар
маалымат блокторунда! Бирок SLOB - демейки жайылтууда - мындай талаш-тартыштарга каршы иммунитет.
Бул декларация: дал келет, бул.
Кл сессияларынын параллелдүүлүк даражасын жөнгө салуу ыңгайлуу, бул ачкыч -t утилитаны ишке киргизүү runit.sh SLOBден
DML буйруктарынын пайызы субдге жөнөтүлгөн тексттик билдирүүлөрдүн санында, ар бир текст сессиясында, параметрде жөнгө салынат. UPDATE_PCT
Өзүнчө жана абдан ыңгайлуу: SLOB өзү, жүктөө сессиясына чейин жана андан кийин - статистикалык пакетти же awr-снапшотторду даярдайт (эмне даярдалат).
Бирок, ошондой болуп чыкты SLOB 30 секунддан аз убакытка созулган SQL сессияларын колдобойт.
Ошондуктан, мен адегенде езумдун жумушчу-дыйкан версиясын жуктегучту коддодум, андан кийин ал иштееде калды.
Түшүнүктүү болуу үчүн жүктөгүч эмне кылат жана аны кантип аткарарын тактап берейин.
Негизи жүктөгүч төмөнкүдөй көрүнөт:
Жумушчу коду
function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off
define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum
declare
v_upto number;
v_key number;
v_tots number;
v_cts number;
begin
select max(col1) into v_upto from system.testtab_&&wnum;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
v_tots := &&period + v_cts;
while v_cts <= v_tots
loop
v_key:=abs(mod(dbms_random.random,v_upto));
if v_key=0 then
v_key:=1;
end if;
update system.testtab_&&wnum t
set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
where t.col1=v_key
;
commit;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
end loop;
end;
/
exit
__EOF__
}
export -f dotxЖумушчулар бул жол менен ишке киргизилет:
Иштеп жаткан жумушчулар
echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
echo "sql-session: ${i}" >> "$v_logfile"
dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
waitАл эми жумушчулар үчүн столдор төмөнкүдөй даярдалган:
Таблицаларды түзүү
function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off
define wnum="$1"
define ts_name="slob"
begin
execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/
create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable
seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"Ошол. Ар бир жумушчу үчүн (практикада: МБда өзүнчө SQL сессиясы) өзүнчө таблица түзүлөт, аны менен жумушчу иштейт.
Бул жумушчу сессияларынын ортосунда транзакциялык кулпулардын жоктугун камсыздайт.
Ар бир жумушчу: бир эле нерсени жасайт, өзүнүн столу менен, столдор баары бирдей.
Бардык жумушчулар бирдей убакытта жумуш аткарышат.
Анын үстүнө, мисалы, лог которгучу сөзсүз түрдө пайда болушу үчүн жана бир нече жолу жетиштүү узак убакытка.
Демек, тиешелүү чыгымдар жана таасирлери пайда болгон.
Менин учурда, мен жумушчулардын ишинин узактыгын 8 мүнөткө конфигурацияладым.
Жүктөп жаткан субддин ишин сүрөттөгөн statspack отчетунун бир бөлүгү
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2929910313 XE 1 07-Sep-20 23:12 18.0.0.0.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
billing.izhevsk1 Linux x86 64-bit 2 2 1 15.6
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 1630 07-Sep-20 23:12:27 55 .7
End Snap: 1631 07-Sep-20 23:20:29 62 .6
Elapsed: 8.03 (mins) Av Act Sess: 8.4
DB time: 67.31 (mins) DB CPU: 15.01 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 1,392M Std Block Size: 8K
Shared Pool: 288M Log Buffer: 103,424K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 8.4 0.0 0.00 0.20
DB CPU(s): 1.9 0.0 0.00 0.04
Redo size: 7,685,765.6 978.4
Logical reads: 60,447.0 7.7
Block changes: 47,167.3 6.0
Physical reads: 8.3 0.0
Physical writes: 253.4 0.0
User calls: 42.6 0.0
Parses: 23.2 0.0
Hard parses: 1.2 0.0
W/A MB processed: 1.0 0.0
Logons: 0.5 0.0
Executes: 15,756.5 2.0
Rollbacks: 0.0 0.0
Transactions: 7,855.1Лабораториялык иштерге кайтуу.
Башка нерселер бирдей болгон учурда биз лабораториялык поддеректер базасынын төмөнкү параметрлеринин маанилерин өзгөртөбүз:
- Маалыматтар базасынын журналынын топторунун өлчөмү. маани диапазону: [32, 1024] МБ;
- Базадагы журнал топторунун саны. маани диапазону: [2,32];
log_archive_max_processesмаани диапазону: [1,8];commit_loggingэки баалуулуктарга жол берилет:batch|immediate;commit_waitэки баалуулуктарга жол берилет:wait|nowait;log_bufferмаани диапазону: [2,128] МБ.log_checkpoint_timeoutмаани диапазону: [60,1200] секундdb_writer_processesмаани диапазону: [1,4]undo_retentionмаани диапазону: [30;300] секундtransactions_per_rollback_segmentмаани диапазону: [1,8]disk_asynch_ioэки баалуулуктарга жол берилет:true|false;filesystemio_optionsтөмөнкү баалуулуктарга жол берилет:none|setall|directIO|asynch;db_block_checkingтөмөнкү баалуулуктарга жол берилет:OFF|LOW|MEDIUM|FULL;db_block_checksumтөмөнкү баалуулуктарга жол берилет:OFF|TYPICAL|FULL;
Oracle маалымат базасын жүргүзүүдө тажрыйбасы бар адам, албетте, көрсөтүлгөн параметрлер менен иштөө үчүн маалымат базасынын көбүрөөк өндүрүмдүүлүгүн алуу үчүн, көрсөтүлгөн параметрлерден жана алардын алгылыктуу маанилеринен эмнени жана кандай баалуулуктарды коюу керектигин айта алат. колдонмо коду, бул жерде жогоруда.
Бирок.
Лабораториялык иштин максаты оптималдаштыруу алгоритминин өзү муну бизге салыштырмалуу тезирээк түшүндүрүп берерин көрсөтүүдө.
Биз үчүн кандай гана параметрлерди жана кайсы диапазондо өзгөртүү керектигин билүү үчүн гана документти ыңгайлаштырылган система аркылуу карап чыгуу гана калды.
Жана ошондой эле: тандалган оптималдаштыруу алгоритминин ыңгайлаштырылган системасы менен иштөө үчүн колдонула турган кодду коддоңуз.
Ошентип, азыр код жөнүндө.
Мен жогоруда айттым cran-r, б.а.: ылайыкташтырылган система менен бардык манипуляциялар R скрипти түрүндө уюштурулган.
Иш жүзүндөгү тапшырма, анализ, метрикалык маани боюнча тандоо, системанын абалынын векторлору: бул пакет GA ()
Пакет, бул учурда, ал векторлордун (хромосомалар, пакет боюнча болсо) бөлчөк бөлүгү бар сандар саптары түрүндө көрсөтүлүшүн күтөт деген мааниде анча ылайыктуу эмес.
Жана менин векторум, орнотуу параметрлеринин маанилеринен: бул 14 чоңдук - бүтүн сандар жана саптык маанилер.
Көйгөй, албетте, сап баалуулуктарына белгилүү бир сандарды ыйгаруу менен оңой эле кутулууга болот.
Ошентип, акырында, R скриптинин негизги бөлүгү төмөнкүдөй көрүнөт:
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@solutionБул жерде, жардамы менен lower и upper подпрограмманын атрибуттары ga негизи издөө мейкиндигинин аймагы көрсөтүлөт, анын ичинде фитнес-функциянын максималдуу мааниси алынуучу ушундай вектор (же векторлор) боюнча издөө жүргүзүлөт.
ga подпрограммасы фитнес-функцияны максималдаштыруучу издөөнү аткарат.
Демек, бул учурда, фитнес-функция векторду субддин айрым параметрлери үчүн маанилердин жыйындысы катары түшүнүп, субдден метрика алышы керек экен.
Башкача айтканда: канча, берилген subd орнотуу жана subd боюнча берилген жүк менен: subd секундасына транзакцияларды иштетет.
Башкача айтканда, ачып жатканда, фитнес функциясынын ичинде төмөнкү көп кадамдар аткарылышы керек:
- Сандардын кириш векторун иштетүү - аны субдата параметрлери үчүн маанилерге айландыруу.
- Берилген өлчөмдөгү кайра жасоо топторунун берилген санын түзүү аракети. Мындан тышкары, аракет ийгиликсиз болушу мүмкүн.
Эксперименттин тазалыгы үчүн субд, кандайдыр бир санда жана кандайдыр бир өлчөмдө мурунтан эле бар болгон журнал топтору - д.б. жок кылынды. - Мурунку пункт ийгиликтүү болсо: маалымат базасына конфигурация параметрлеринин маанилерин көрсөтүү (дагы: ката болушу мүмкүн)
- Мурунку кадам ийгиликтүү болсо: жаңы көрсөтүлгөн параметр маанилери күчүнө кириши үчүн subdди токтотуу, subd баштоо. (дагы: ката болушу мүмкүн)
- Мурунку кадам ийгиликтүү болсо: жүк сынагынан өтүңүз. subdден көрсөткүчтөрдү алуу.
- Субдди баштапкы абалына кайтаруу, б.а. кошумча журнал топторун жок кылуу, баштапкы суббаза конфигурациясын иштөөгө кайтаруу.
Фитнес функциянын коду
evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")
opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")
opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
opn$disk_asynch_io="false"
}
opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
opn$filesystemio_options="asynch"
}
opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
opn$db_block_checking="FULL"
}
opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
opn$db_block_checksum="FULL"
}
v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)
rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
return (0)
}
v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) { v_rc=1 }
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("abort")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=run_test()
v_metric=getmetric()
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}Ошол. бардык иш: дене тарбия милдетин аткарат.
Га-субрутин векторлорду, тагыраак айтканда хромосомаларды иштетет.
Мында биз үчүн эң негизгиси фитнес функциясы чоң маанилерди берген гендери бар хромосомаларды тандоо.
Бул, маңызы боюнча, N-өлчөмдүү издөө мейкиндигинде вектордун жардамы менен хромосомалардын оптималдуу топтомун издөө процесси.
Абдан ачык, деталдуу , R-коддун мисалдары менен, генетикалык алгоритмдин иши.
Мен эки техникалык пунктту өзүнчө белгилеп кетким келет.
Функциядан жардамчы чалуулар evaluate, мисалы, токтотуу-старт, subd параметринин маанисин коюу, негизинде жүзөгө ашырылат cran-r функциялары system2
Анын жардамы менен: кандайдыр бир bash скрипти же буйругу чакырылат.
Мисалы:
set_db_parameter
set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")
x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (attributes(x)$status)
}
else {
cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (0)
}
}Экинчи чекит - сызык, evaluate белгилүү бир метрикалык маанини жана анын тиешелүү тюнинг векторун журнал файлына сактоо менен функциялар:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Бул маанилүү, анткени бул маалыматтар массивинен тюнинг векторунун компоненттеринин кайсынысы метрикалык мааниге көбүрөөк же азыраак таасир тийгизгендиги жөнүндө кошумча маалымат алууга мүмкүн болот.
Башкача айтканда: атрибут-маанилүү анализ жүргүзүү мүмкүн болот.
Анда эмне болушу мүмкүн?
График формасында, эгер сиз тесттерди өсүүчү метрикалык тартипте заказ кылсаңыз, сүрөт төмөнкүдөй болот:
Метриканын экстремалдык маанилерине туура келген кээ бир маалыматтар:
Бул жерде, натыйжалар менен скриншотто мен тактап берем: тюнинг векторунун маанилери формулировкаланган параметрлердин/параметр маанилеринин диапазондорунун сандык тизмеси боюнча эмес, фитнес-функциянын коду боюнча берилген. текстте жогоруда.
жакшы. Бул көпбү же азбы, ~8 миң tps: өзүнчө суроо.
Лабораториялык иштердин алкагында бул көрсөткүч маанилүү эмес, маанилүүсү динамика, бул маани кандай өзгөрөт.
Бул жерде динамика жакшы.
Бул, жок эле дегенде, бир фактор хромосома векторлору аркылуу сорттоо метрика, га-алгоритмдин маанисине олуттуу таасир этээри айдан ачык: капталган.
Ийри маанилердин кыйла күчтүү динамикасына караганда, бир кыйла азыраак болсо да, таасир этүүчү дагы бир фактор бар.
Бул жерде сизге керек attribute-importance кандай атрибуттарды (ошондой эле, бул учурда, тюнинг векторунун компоненттери) жана алар метрикалык мааниге канчалык таасирин тийгизерин түшүнүү үчүн талдоо.
Жана бул маалыматтан: маанилүү атрибуттардагы өзгөрүүлөргө кандай факторлор таасир эткенин түшүнүңүз.
Run attribute-importance ар кандай жолдор менен мүмкүн.
Бул максаттар үчүн мен алгоритмди жакшы көрөм randomForest R бир эле аталыштагы пакет ()
randomForest, мен анын жалпы ишин жана өзгөчө атрибуттардын маанилүүлүгүн баалоого болгон мамилесин түшүнгөндөй, жооп өзгөрмөнүн атрибуттарга көз карандылыгынын белгилүү бир моделин курат.
Биздин учурда, жооп өзгөрмө жүк тесттер базасынан алынган метрика болуп саналат: tps;
Ал эми атрибуттар тюнинг векторунун компоненттери болуп саналат.
Мына ушундай randomForest ар бир моделдин атрибутунун маанилүүлүгүн эки сан менен баалайт: %IncMSE — моделде бул атрибуттун болушу/жоктугу бул моделдин MSE сапатын кантип өзгөртөт (Орто квадраттык ката);
Жана IncNodePurity - бул атрибуттун маанилеринин негизинде байкоолор менен берилиштер жыйындысын канчалык жакшы чагылдыра тургандыгын, бир бөлүгүндө метриканын бир мааниси түшүндүрүлгөн маалыматтар, ал эми экинчи бөлүгүндө метриканын башка мааниси.
Ооба, бул: бул канчалык деңгээлде классификациялоочу атрибут (мен RandomForestтен эң так, орусча түшүндүрмө көрдүм ).
Жумушчу-дыйкан R-коду жүктөм сыноолордун натыйжалары менен маалымат топтомун иштетүү үчүн:
x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')
idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]
library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importanceСиз өз колуңуз менен алгоритмдин гиперпараметрлерин түздөн-түз тандай аласыз жана моделдин сапатына көңүл буруп, валидация маалымат топтомундагы божомолдорду так аткарган моделди тандай аласыз.
Сиз бул иш үчүн кандайдыр бир функцияны жаза аласыз (айтмакчы, кандайдыр бир оптималдаштыруу алгоритмин колдонуу менен).
Сиз R пакетин колдоно аласыз caret, пункт маанилүү эмес.
Натыйжада, бул учурда, атрибуттардын маанилүүлүгүн баалоо үчүн төмөнкү натыйжа алынат:
жакшы. Ошентип, биз глобалдык ой жүгүртүүнү баштасак болот:
- Көрсө, бул тестирлөө шарттарында эң маанилүү параметр болгон
commit_wait
Техникалык жактан ал subdb журналынын буферинен учурдагы журнал тобуна кайталоо маалыматтарын жазуу io операциясынын аткаруу режимин аныктайт: синхрондуу же асинхрондуу.
Наркыnowaitбул tps метрикасынын маанисинин дээрлик вертикалдуу, бир нече жолу жогорулашына алып келет: бул асинхрондук io режимин кайталоо топторуна кошуу.
Өзүнчө суроо - бул тамак-аш базасында муну жасоо керекпи же жокпу. Бул жерде мен жөн гана айтуу менен чектелдим: бул маанилүү фактор. - Subd: журналынын буферинин өлчөмү олуттуу фактор болуп чыкканы логикалык.
Журнал буферинин өлчөмү канчалык кичине болсо, анын буферлөө жөндөмдүүлүгү ошончолук азыраак болсо, ошончолук көп толуп кетет жана/же жаңы редокстук маалыматтардын бир бөлүгү үчүн андагы бош аймакты бөлүүгө мүмкүн эмес.
Бул төмөнкүлөрдү билдирет: журнал буферинде мейкиндикти бөлүштүрүү жана/же андан кайталоо топторуна кайра жасоо дайындарын чыгаруу менен байланышкан кечигүү.
Бул кечигүүлөр, албетте, транзакциялар үчүн маалымат базасынын өткөрүү жөндөмдүүлүгүнө таасир этиши керек. - параметр
db_block_checksum: ошондой эле, жалпысынан бул түшүнүктүү - транзакцияны иштетүү поддеректер базасынын буфердик кэшинде дарти блоктордун пайда болушуна алып келет.
Берилиш блокторунун контролдук суммасын текшерүү иштетилгенде, маалымат базасы иштеп чыгышы керек - бул контролдук суммаларды маалымат блогунун негизги бөлүгүнөн эсептеп, аларды маалымат блогунун аталышында жазылган менен текшериңиз: дал келет/ дал келбейт.
Мындай иш, дагы эле, маалыматтарды иштеп чыгууну кечиктирбей коюуга болбойт, демек, бул параметрди орнотуучу параметр жана механизм олуттуу болуп чыгат.
Ошондуктан сатуучу документацияда бул параметр үчүн ар кандай маанилерди (параметр) сунуштайт жана ооба, таасир болорун белгилейт, бирок, сиз "өчүрүү" жана "өчүрүү" чейин ар кандай маанилерди тандай аласыз. ар кандай таасирлери.
Ооба, дүйнөлүк жыйынтык.
мамиле, жалпысынан алганда, абдан натыйжалуу болуп чыгат.
Ал белгилүү бир сервистик системаны жүктөөнү сынап көрүүнүн алгачкы этаптарында анын (системанын) жүк үчүн оптималдуу конфигурациясын тандоо үчүн, жүк үчүн системаны орнотуунун өзгөчөлүктөрүнө өтө эле тереңдеп кирбөөгө мүмкүндүк берет.
Бирок бул аны толугу менен жокко чыгарбайт - жок дегенде түшүнүү деңгээлинде: система "жөнгөлөө баскычтары" жана бул баскычтардын айлануусунун уруксат берилген диапазондору жөнүндө белгилүү болушу керек.
Бул ыкма системанын оптималдуу конфигурациясын салыштырмалуу тез таба алат.
Ал эми тестирлөөнүн жыйынтыгы боюнча, ал системанын натыйжалуулугун көрсөткүчтөрү жана система орнотуулары параметрлеринин маанилеринин ортосундагы байланыштын мүнөзү жөнүндө маалымат алууга болот.
Бул, албетте, системаны, анын иштешин, жок эле дегенде, берилген жүктүн астында абдан терең түшүнүүнүн пайда болушуна өбөлгө болушу керек.
Иш жүзүндө, бул системанын ушундай тестирлөөнү даярдоого кеткен чыгымдарга ылайыкташтырылган системаны түшүнүүгө кеткен чыгымдардын алмашуусу.
Мен өзүнчө белгилеп кетким келет: бул ыкмада системаны тестирлөөнүн коммерциялык эксплуатацияда боло турган иштөө шарттарына шайкештигинин даражасы өтө маанилүү.
Көңүл бурганыңыз жана убактыңыз үчүн рахмат.
Source: www.habr.com