Salom.
Men o'z topilmalarimni baham ko'rishga qaror qildim - fikrlash, sinov va xatolik samarasi.
Umuman olganda: bu topilma emas, albatta - bularning barchasi statistik ma'lumotlarni amaliy qayta ishlash va har qanday tizimni optimallashtirish bilan shug'ullanadiganlarga uzoq vaqtdan beri ma'lum bo'lishi kerak edi, ayniqsa ma'lumotlar bazasi ma'lumotlar bazasi.
Va: ha, ular bilishadi, ular o'zlarining tadqiqotlari bo'yicha qiziqarli maqolalar yozadilar, (UPD: sharhlarda ular juda qiziqarli loyihani ta'kidlashdi: )
Boshqa tomondan: o'z-o'zidan men IT-mutaxassislari, DBA o'rtasida Internetda ushbu yondashuv haqida keng tarqalgan eslatma yoki tarqatishni ko'rmayapman.
Shunday qilib, nuqtaga.
Faraz qilaylik, bizda vazifa bor: qandaydir ishlarga xizmat ko'rsatish uchun ma'lum bir xizmat tizimini o'rnatish.
Bu ish haqida ma'lum: bu nima, bu ishning sifati qanday o'lchanadi va bu sifatni o'lchash mezoni qanday.
Keling, ko'p yoki kamroq ma'lum va tushunilgan deb faraz qilaylik: ushbu xizmat tizimida (yoki u bilan) ish qanday amalga oshirilganligi aniq.
"Ko'proq yoki kamroq" - bu ishlab chiqarishda bo'ladigan narsaga etarlicha mos keladigan sinov yuki bilan sintez qilinishi va tizimga qo'llanilishi mumkin bo'lgan ma'lum bir vositani, yordamchi dasturni, xizmatni tayyorlash (yoki uni biron bir joydan olish) mumkinligini anglatadi. ishlab chiqarishda ishlash uchun etarli sharoitlarda.
Keling, ushbu xizmat ko'rsatish tizimi uchun sozlash parametrlari to'plami ma'lum deb faraz qilaylik, bu tizimni ish samaradorligi nuqtai nazaridan sozlash uchun ishlatilishi mumkin.
Va muammo nimada - ushbu xizmat tizimi haqida etarlicha to'liq tushuncha yo'q, bu sizga ushbu platformada kelajakda yuklash uchun ushbu tizim sozlamalarini malakali tarzda sozlash va tizimning kerakli unumdorligini olish imkonini beradi.
Xo'sh. Bu deyarli har doim shunday bo'ladi.
Bu yerda nima qila olasiz?
Xo'sh, aqlga kelgan birinchi narsa - bu tizim uchun hujjatlarni ko'rib chiqish. Sozlash parametrlarining qiymatlari uchun maqbul diapazonlar nima ekanligini tushunib oling. Va, masalan, koordinatalarni tushirish usulidan foydalanib, testlarda tizim parametrlari uchun qiymatlarni tanlang.
Bular. tizimga konfiguratsiya parametrlari uchun ma'lum qiymatlar to'plami shaklida qandaydir konfiguratsiyani bering.
Ushbu asbob-uskunalar, yuk generatoridan foydalanib, unga sinov yukini qo'llang.
Va qiymatga qarang - javob yoki tizim sifati ko'rsatkichi.
Ikkinchi fikr, bu juda uzoq vaqt degan xulosa bo'lishi mumkin.
Xo'sh, ya'ni: agar sozlash parametrlari juda ko'p bo'lsa, ularning qiymatlari diapazonlari katta bo'lsa, har bir alohida yuk testini bajarish uchun ko'p vaqt kerak bo'lsa, unda: ha, bularning barchasi qabul qilinishi mumkin bo'lmagan vaqt talab qilishi mumkin. uzoq vaqt.
Xo'sh, bu erda nimani tushunishingiz va eslashingiz mumkin.
Xizmat tizimi sozlamalari parametrlari qiymatlari to'plamida ba'zi qiymatlar ketma-ketligi sifatida vektor mavjudligini bilib olishingiz mumkin.
Har bir bunday vektor, boshqa narsalar teng bo'lsa (bu vektor unga ta'sir qilmaydi) metrikaning to'liq aniq qiymatiga mos keladi - sinov yuki ostida tizimning ishlash sifati ko'rsatkichi.
ya'ni
Tizim konfiguratsiya vektorini quyidagicha belgilaymiz 
qayerda ; Qayerda β tizim konfiguratsiyasi parametrlari soni, bu parametrlarning qanchasi borligi.
Va bunga mos keladigan metrikaning qiymati deb belgilaymiz
, keyin biz funktsiyani olamiz:
Xo'sh, unda hamma narsa darhol tushadi, mening holimda: talabalik davrimdan deyarli unutilgan, funktsiyaning ekstremumini qidirish algoritmlari.
Yaxshi, lekin bu erda tashkiliy va amaliy savol tug'iladi: qaysi algoritmdan foydalanish kerak.
- Bu ma'noda - qo'lda kamroq kodlash uchun.
- Va ishlashi uchun, ya'ni. ekstremumni topdi (agar mavjud bo'lsa), yaxshi, hech bo'lmaganda koordinatali tushishdan tezroq.
Birinchi nuqta, biz bunday algoritmlar allaqachon amalga oshirilgan va qaysidir shaklda kodda foydalanishga tayyor bo'lgan ba'zi muhitlarga qarashimiz kerakligini ko'rsatadi.
Xo'sh, bilaman python ΠΈ cran-r
Ikkinchi nuqta, algoritmlarning o'zlari, ular nima, ularning talablari va ishlarining xususiyatlari haqida o'qishingiz kerakligini anglatadi.
Va ular beradigan narsa foydali yon ta'sirlar bo'lishi mumkin - natijalar yoki to'g'ridan-to'g'ri algoritmning o'zidan.
Yoki ularni algoritm natijalaridan olish mumkin.
Ko'p narsa kirish shartlariga bog'liq.
Misol uchun, agar biron sababga ko'ra natijani tezroq olishingiz kerak bo'lsa, unda siz gradient tushish algoritmlariga qarashingiz va ulardan birini tanlashingiz kerak.
Yoki, agar vaqt unchalik muhim bo'lmasa, siz, masalan, genetik algoritm kabi stokastik optimallashtirish usullaridan foydalanishingiz mumkin.
Men ushbu yondashuvning ishini, tizim konfiguratsiyasini tanlashni, genetik algoritmdan foydalangan holda, keyingi, aytganda: laboratoriya ishini ko'rib chiqishni taklif qilaman.
Asl:
- Xizmat tizimi sifatida bo'lsin:
oracle xe 18c - U tranzaktsion faoliyatga xizmat qilsin va maqsad: tranzaksiyalar/sekundlarda quyi ma'lumotlar bazasining mumkin bo'lgan eng yuqori o'tkazuvchanligini olish.
- Tranzaksiyalar ma'lumotlar bilan ishlash tabiati va ish kontekstida juda farq qilishi mumkin.
Keling, bu katta hajmdagi jadval ma'lumotlarini qayta ishlamaydigan operatsiyalar ekanligiga rozi bo'laylik.
Ular takrorlashdan ko'ra ko'proq bekor qilish ma'lumotlarini yaratmaydilar va qatorlar va katta jadvallarning katta foizini qayta ishlamaydilar.
Bular ko'p yoki kamroq katta jadvaldagi bir qatorni o'zgartiradigan operatsiyalar bo'lib, bu jadvalda oz sonli indekslar mavjud.
Bunday vaziyatda: tranzaktsiyalarni qayta ishlash uchun subma'lumotlar bazasining unumdorligi, rezerv bilan, redoks ma'lumotlar bazasi tomonidan qayta ishlash sifati bilan belgilanadi.
Rad etish - agar biz subdb sozlamalari haqida gapiradigan bo'lsak.
Chunki, umumiy holatda, masalan, SQL seanslari o'rtasida, foydalanuvchining jadval ma'lumotlari va/yoki jadval modeli bilan ishlash dizayni tufayli tranzaksiya blokirovkalari bo'lishi mumkin.
Bu, albatta, TPS metrikasiga tushkunlikka tushadigan ta'sir qiladi va bu subma'lumotlar bazasiga nisbatan ekzogen omil bo'ladi: jadvalli model shunday yaratilgan va undagi ma'lumotlar bilan ishlash blokirovkalar sodir bo'ladi.
Shuning uchun, eksperimentning tozaligi uchun biz ushbu omilni istisno qilamiz va quyida men qanday qilib aniq tushuntiraman.
- Aniqlik uchun ma'lumotlar bazasiga yuborilgan SQL buyruqlarining 100% DML buyruqlari ekanligini faraz qilaylik.
Testlarda foydalanuvchining subma'lumotlar bazasi bilan ishlash xususiyatlari bir xil bo'lsin.
Ya'ni: skl seanslari soni, jadval ma'lumotlari, skl seanslari ular bilan qanday ishlaydi. - Subd ishlaydi
FORCE LOGGING,ARCHIVELOGmods. Flashback-ma'lumotlar bazasi rejimi subd darajasida o'chirilgan. - Jurnallarni qayta tiklash: alohida fayl tizimida, alohida "diskda" joylashgan;
Ma'lumotlar bazasining jismoniy komponentining qolgan qismi: boshqa, alohida fayl tizimida, alohida "diskda":
Jismoniy qurilma haqida batafsil ma'lumot. laboratoriya ma'lumotlar bazasi komponentlari
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 0Dastlab, ushbu yuklash sharoitida men tranzaksiya subd dan foydalanmoqchi edim
Uning shunday ajoyib xususiyati borki, men muallifdan iqtibos keltiraman:
SLOBning markazida "SLOB usuli" mavjud. SLOB usuli platformalarni sinab ko'rishga qaratilgan
ariza bahsisiz. Uskunaning maksimal ishlashini boshqarish mumkin emas
ilova kodini ishlatish, masalan, ilovani blokirovka qilish yoki hatto bog'lash
Oracle ma'lumotlar bazasi bloklarini almashish. To'g'ri - ma'lumotlarni almashishda ortiqcha yuk bor
ma'lumotlar bloklarida! Ammo SLOB - sukut bo'yicha - bunday tortishuvlarga qarshi immunitetga ega.
Bu deklaratsiya: mos keladi, shunday.
Kl seanslarining parallellik darajasini tartibga solish qulay, bu kalit -t yordamchi dasturni ishga tushiring runit.sh SLOB dan
DML buyruqlarining ulushi subd-ga yuboriladigan matnli xabarlar sonida, har bir matn seansida, parametrda tartibga solinadi. UPDATE_PCT
Alohida va juda qulay: SLOB o'zi, yuklash seansidan oldin va keyin - statspack yoki awr-snapshotlarni (tayyorlash uchun o'rnatilgan) tayyorlaydi.
Biroq, bu ma'lum bo'ldi SLOB davomiyligi 30 soniyadan kam bo'lgan SQL seanslarini qo'llab-quvvatlamaydi.
Shuning uchun men birinchi navbatda yuk ko'taruvchining o'zimning ishchi-dehqon versiyasini kodladim, keyin esa u ishlay boshladi.
Aniqlik uchun yuklovchi nima qilishini va buni qanday qilishini aniqlab beraman.
Asosan loader quyidagicha ko'rinadi:
Ishchi kodi
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 dotxIshchilar quyidagi tarzda ishga tushiriladi:
Ishlayotgan ishchilar
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"
waitVa ishchilar uchun jadvallar quyidagicha tayyorlanadi:
Jadvallar yaratish
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"Bular. Har bir ishchi uchun (amalda: JBda alohida SQL seansi) alohida jadval tuziladi, u bilan ishchi ishlaydi.
Bu ishchi seanslar o'rtasida tranzaksiya blokirovkalari yo'qligini ta'minlaydi.
Har bir ishchi: xuddi shu narsani qiladi, o'z stoli bilan, jadvallar hammasi bir xil.
Barcha ishchilar bir xil vaqt davomida ishni bajaradilar.
Bundan tashqari, etarlicha uzoq vaqt davomida, masalan, log kaliti albatta sodir bo'ladi va bir necha marta.
Shunga ko'ra, tegishli xarajatlar va ta'sirlar paydo bo'ldi.
Mening holimda men ishchilar ishining davomiyligini 8 daqiqaga sozladim.
Subdning yuk ostida ishlashini tavsiflovchi statspack hisobotining bir qismi
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.1Laboratoriya ishiga qaytish.
Boshqa narsalar teng bo'lsa, biz laboratoriya subma'lumotlar bazasining quyidagi parametrlarining qiymatlarini o'zgartiramiz:
- Ma'lumotlar bazasi jurnali guruhlari hajmi. qiymat diapazoni: [32, 1024] MB;
- Ma'lumotlar bazasidagi jurnal guruhlari soni. qiymat diapazoni: [2,32];
log_archive_max_processesqiymat diapazoni: [1,8];commit_loggingikkita qiymatga ruxsat beriladi:batch|immediate;commit_waitikkita qiymatga ruxsat beriladi:wait|nowait;log_bufferqiymat diapazoni: [2,128] MB.log_checkpoint_timeoutqiymat diapazoni: [60,1200] soniyadb_writer_processesqiymat diapazoni: [1,4]undo_retentionqiymat diapazoni: [30;300] soniyatransactions_per_rollback_segmentqiymat diapazoni: [1,8]disk_asynch_ioikkita qiymatga ruxsat beriladi:true|false;filesystemio_optionsquyidagi qiymatlarga ruxsat beriladi:none|setall|directIO|asynch;db_block_checkingquyidagi qiymatlarga ruxsat beriladi:OFF|LOW|MEDIUM|FULL;db_block_checksumquyidagi qiymatlarga ruxsat beriladi:OFF|TYPICAL|FULL;
Oracle ma'lumotlar bazalarini yuritishda tajribaga ega bo'lgan shaxs, ma'lumotlar bazasida ko'rsatilgan ma'lumotlar bilan ishlash uchun ma'lumotlar bazasining ko'proq unumdorligini olish uchun ko'rsatilgan parametrlar va ularning maqbul qiymatlaridan nimani va qanday qiymatlarni belgilash kerakligini aniq aytishi mumkin. ilova kodi, bu erda yuqorida.
Lekin.
Laboratoriya ishining maqsadi optimallashtirish algoritmining o'zi buni biz uchun nisbatan tez aniqlab berishini ko'rsatishdir.
Biz uchun faqat sozlanishi mumkin bo'lgan tizim orqali hujjatni ko'rib chiqish qoladi, faqat qaysi parametrlarni va qaysi diapazonlarda o'zgartirish kerakligini bilish kifoya.
Va shuningdek: tanlangan optimallashtirish algoritmining maxsus tizimi bilan ishlash uchun ishlatiladigan kodni kodlang.
Shunday qilib, endi kod haqida.
Men yuqorida haqida gapirdim cran-r, ya'ni: moslashtirilgan tizim bilan barcha manipulyatsiyalar R skripti shaklida tartibga solinadi.
Haqiqiy vazifa, tahlil, metrik qiymat bo'yicha tanlash, tizim holati vektorlari: bu paket GA ()
Paket, bu holda, juda mos emas, chunki u vektorlarni (xromosomalar, agar paket bo'lsa) kasr qismi bilan raqamlar qatorlari shaklida ko'rsatilishini kutadi.
Va mening vektorim, sozlash parametrlarining qiymatlaridan: bu 14 ta miqdor - butun sonlar va satr qiymatlari.
Muammo, albatta, satr qiymatlariga ba'zi bir aniq raqamlarni belgilash orqali osonlikcha oldini olish mumkin.
Shunday qilib, oxir-oqibat, R skriptining asosiy qismi quyidagicha ko'rinadi:
GA::ga ga qo'ng'iroq qiling
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@solutionMana, yordam bilan lower ΠΈ upper pastki dastur atributlari ga Mohiyatan, qidiruv maydonining maydoni belgilanadi, uning ichida fitnes funktsiyasining maksimal qiymati olinadigan bunday vektor (yoki vektorlar) uchun qidiruv amalga oshiriladi.
Ga subprogrammasi fitnes funksiyasini maksimal darajada oshiruvchi qidiruvni amalga oshiradi.
Xo'sh, ma'lum bo'lishicha, bu holda, vektorni subdning ma'lum parametrlari uchun qiymatlar to'plami sifatida tushunadigan fitnes funktsiyasi subddan metrikani olishi kerak.
Ya'ni: ma'lum subd sozlamalari va subdda berilgan yuk bilan qancha: subd soniyada tranzaktsiyalarni qayta ishlaydi.
Ya'ni, ochilganda, fitnes funktsiyasi ichida quyidagi ko'p bosqichlarni bajarish kerak:
- Raqamlarning kirish vektorini qayta ishlash - uni subma'lumotlar parametrlari uchun qiymatlarga aylantirish.
- Berilgan o'lchamdagi ma'lum miqdordagi takroriy guruhlarni yaratishga urinish. Bundan tashqari, urinish muvaffaqiyatsiz bo'lishi mumkin.
Tajribaning tozaligi uchun subdda allaqachon mavjud bo'lgan jurnal guruhlari, ba'zi miqdorda va ba'zi o'lchamlarda - d.b. o'chirildi. - Agar oldingi nuqta muvaffaqiyatli bo'lsa: ma'lumotlar bazasiga konfiguratsiya parametrlarining qiymatlarini ko'rsatish (yana: xato bo'lishi mumkin)
- Agar oldingi qadam muvaffaqiyatli bo'lsa: yangi belgilangan parametr qiymatlari kuchga kirishi uchun subdni to'xtatib, subdni ishga tushiring. (yana: xatolik bo'lishi mumkin)
- Agar oldingi qadam muvaffaqiyatli bo'lsa: yuk sinovini o'tkazing. subd dan ko'rsatkichlarni oling.
- Subdni asl holatiga qaytaring, ya'ni. qo'shimcha jurnal guruhlarini o'chirish, asl subma'lumotlar bazasi konfiguratsiyasini ishlashga qaytarish.
Fitness funktsiyasi kodi
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)
}Bu. barcha ish: fitnes funktsiyasida bajarilgan.
Ga-subroutin vektorlarni, to'g'rirog'i, xromosomalarni qayta ishlaydi.
Bunda biz uchun eng muhimi, fitnes funktsiyasi katta qiymatlarni keltirib chiqaradigan genlarga ega xromosomalarni tanlashdir.
Bu, mohiyatiga ko'ra, N o'lchovli qidiruv maydonida vektor yordamida xromosomalarning optimal to'plamini izlash jarayonidir.
Juda aniq, batafsil , R-kod misollari bilan, genetik algoritmning ishi.
Men ikkita texnik jihatni alohida ta'kidlamoqchiman.
Funktsiyadan yordamchi chaqiruvlar evaluate, masalan, to'xtatish-start, subd parametrining qiymatini belgilash, asosida amalga oshiriladi cran-r funktsiyalari system2
Buning yordamida: bash skripti yoki buyrug'i chaqiriladi.
Masalan:
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)
}
}Ikkinchi nuqta - chiziq, evaluate Muayyan metrik qiymatni va uning mos sozlash vektorini jurnal fayliga saqlash bilan funksiyalar:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Bu juda muhim, chunki ushbu ma'lumotlar massividan sozlash vektorining tarkibiy qismlaridan qaysi biri metrik qiymatga ko'proq yoki kamroq ta'sir ko'rsatishi haqida qo'shimcha ma'lumot olish mumkin bo'ladi.
Ya'ni: atribut-muhimlik tahlilini o'tkazish mumkin bo'ladi.
Xo'sh, nima bo'lishi mumkin?
Grafik shaklida, agar siz testlarni o'sib boruvchi metrik tartibda buyurtma qilsangiz, rasm quyidagicha bo'ladi:
Ko'rsatkichning ekstremal qiymatlariga mos keladigan ba'zi ma'lumotlar:
Bu erda, natijalar bilan skrinshotda men aniqlab beraman: sozlash vektorining qiymatlari tuzilgan parametrlar / parametr qiymatlari diapazonlarining raqamlar ro'yxati bo'yicha emas, balki fitnes funktsiyasi kodi bo'yicha berilgan. matnda yuqorida.
Xo'sh. Ko'pmi yoki ozmi, ~8 ming tsp: alohida savol.
Laboratoriya ishi doirasida bu ko'rsatkich muhim emas, eng muhimi, dinamika, bu qiymat qanday o'zgarishi.
Bu erda dinamika yaxshi.
Ko'rinib turibdiki, hech bo'lmaganda bitta omil metrikaning qiymatiga, ga-algoritmning xromosoma vektorlari orqali saralanishiga sezilarli ta'sir qiladi: qoplangan.
Egri chiziq qiymatlarining etarlicha kuchli dinamikasiga qaraganda, sezilarli darajada kichikroq bo'lsa-da, ta'sir ko'rsatadigan kamida yana bitta omil mavjud.
Bu sizga kerak bo'lgan joy attribute-importance qanday atributlarni (yaxshi, bu holda sozlash vektorining tarkibiy qismlari) va ular metrik qiymatga qanchalik ta'sir qilishini tushunish uchun tahlil qilish.
Va bu ma'lumotlardan: muhim atributlarning o'zgarishi qanday omillarga ta'sir qilganini tushuning.
yugurish attribute-importance turli yo'llar bilan mumkin.
Ushbu maqsadlar uchun menga algoritm yoqadi randomForest Xuddi shu nomdagi R paketi ()
randomForest, men uning umumiy ishini va xususan atributlarning ahamiyatini baholashga yondashuvini tushunganimdek, javob o'zgaruvchisining atributlarga bog'liqligining ma'lum bir modelini quradi.
Bizning holatda, javob o'zgaruvchisi yuk testlarida ma'lumotlar bazasidan olingan ko'rsatkichdir: tps;
Va atributlar sozlash vektorining tarkibiy qismlaridir.
Va shunday randomForest Har bir model atributining ahamiyatini ikkita raqam bilan baholaydi: %IncMSE β modelda ushbu atributning mavjudligi/yoβqligi ushbu modelning MSE sifatini qanday oβzgartiradi (Mean Squared Error);
Va IncNodePurity - bu ushbu atributning qiymatlariga asoslanib, kuzatuvlar bilan ma'lumotlar to'plamini qanchalik to'g'ri bo'lish mumkinligini aks ettiruvchi raqam, shunda bir qismida metrikaning bir qiymati tushuntirilgan, ikkinchisida esa ma'lumotlar mavjud. metrikaning boshqa qiymati.
Xo'sh, ya'ni: bu qanchalik tasniflovchi atribut (men RandomForest-da eng aniq, rus tilidagi tushuntirishni ko'rdim. ).
Yuk sinovlari natijalari bilan ma'lumotlar to'plamini qayta ishlash uchun ishchi-dehqon R-kodi:
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$importanceSiz o'zingizning qo'lingiz bilan algoritmning giperparametrlarini to'g'ridan-to'g'ri tanlashingiz va model sifatiga e'tibor qaratib, tekshirish ma'lumotlar to'plamidagi bashoratlarni aniqroq bajaradigan modelni tanlashingiz mumkin.
Siz ushbu ish uchun qandaydir funktsiyani yozishingiz mumkin (aytmoqchi, yana qandaydir optimallashtirish algoritmidan foydalangan holda).
R paketidan foydalanishingiz mumkin caret, nuqta muhim emas.
Natijada, bu holda, atributlarning muhimlik darajasini baholash uchun quyidagi natija olinadi:
Xo'sh. Shunday qilib, biz global fikrlashni boshlashimiz mumkin:
- Ma'lum bo'lishicha, ushbu sinov sharoitida eng muhimi parametr bo'lgan
commit_wait
Texnik jihatdan u subdb jurnali buferidan joriy jurnallar guruhiga takrorlash ma'lumotlarini yozish uchun io operatsiyasining bajarish rejimini belgilaydi: sinxron yoki asinxron.
ma'nonowaitbu tps metrikasi qiymatining deyarli vertikal, bir necha marta oshishiga olib keladi: bu asinxron io rejimini takrorlash guruhlariga kiritish.
Alohida savol - oziq-ovqat ma'lumotlar bazasida buni qilish kerakmi yoki yo'qmi. Bu erda men faqat aytish bilan cheklanaman: bu muhim omil. - Subd: log buferining o'lchami muhim omil bo'lib chiqishi mantiqan.
Jurnal buferining o'lchami qanchalik kichik bo'lsa, uning buferlash qobiliyati shunchalik kam bo'lsa, u tez-tez toshib ketadi va/yoki yangi redoks ma'lumotlarining bir qismi uchun undagi bo'sh maydonni ajrata olmaydi.
Buning ma'nosi: jurnal buferida bo'sh joy ajratish va/yoki undan qayta ishlash ma'lumotlarini takrorlash guruhlariga tushirish bilan bog'liq kechikishlar.
Ushbu kechikishlar, albatta, tranzaktsiyalar uchun ma'lumotlar bazasini o'tkazish qobiliyatiga ta'sir qilishi kerak va ta'sir qiladi. - Parametr
db_block_checksum: shuningdek, umuman olganda, bu aniq - tranzaktsiyalarni qayta ishlash subma'lumotlar bazasi bufer keshida darty bloklari shakllanishiga olib keladi.
Ma'lumotlar bloklarining nazorat summalarini tekshirish yoqilgan bo'lsa, ma'lumotlar bazasi qayta ishlashi kerak - ma'lumotlar blokining asosiy qismidan ushbu nazorat summalarini hisoblang, ularni ma'lumotlar bloki sarlavhasida yozilgan narsalar bilan tekshiring: mos keladi / mos kelmaydi.
Bunday ish, yana, ma'lumotlarni qayta ishlashni kechiktirishi mumkin emas va shunga ko'ra, ushbu parametrni o'rnatadigan parametr va mexanizm muhim bo'lib chiqadi.
Shuning uchun sotuvchi ushbu parametr uchun hujjatlarda uning (parametr) turli qiymatlarini taklif qiladi va ha, ta'sir bo'lishini ta'kidlaydi, lekin siz "o'chirilgan" va "o'chirilgan" ga qadar turli xil qiymatlarni tanlashingiz mumkin. turli ta'sirlar.
Xo'sh, global xulosa.
Yondashuv, umuman olganda, juda samarali bo'lib chiqadi.
U ma'lum bir xizmat ko'rsatish tizimini yukni sinovdan o'tkazishning dastlabki bosqichlarida uning (tizimning) yuk uchun optimal konfiguratsiyasini tanlash uchun, yuk uchun tizimni o'rnatishning o'ziga xos xususiyatlarini juda ko'p o'rganmaslikka imkon beradi.
Ammo bu buni butunlay inkor etmaydi - hech bo'lmaganda tushunish darajasida: tizim "sozlash tugmalari" va ushbu tugmalarning ruxsat etilgan aylanish diapazonlari haqida ma'lum bo'lishi kerak.
Keyin yondashuv nisbatan tez optimal tizim konfiguratsiyasini topishi mumkin.
Va sinov natijalariga ko'ra, tizimning ishlash ko'rsatkichlari va tizim sozlamalari parametrlarining qiymatlari o'rtasidagi munosabatlarning tabiati haqida ma'lumot olish mumkin.
Bu, albatta, tizimni, hech bo'lmaganda ma'lum bir yuk ostida ishlashini juda chuqur tushunishning paydo bo'lishiga hissa qo'shishi kerak.
Amalda, bu moslashtirilgan tizimni tushunish xarajatlarini tizimning bunday sinovini tayyorlash xarajatlari bilan almashishdir.
Alohida ta'kidlashni istardim: ushbu yondashuvda tizimni sinovdan o'tkazishning tijorat maqsadlarida foydalanish shartlariga muvofiqligi juda muhimdir.
E'tibor va vaqtingiz uchun rahmat.
Manba: www.habr.com