Сайн байна уу.
Бодлын үр дүн, сорилт, алдааны үр дүнг би олж хуваалцахаар шийдлээ.
Товчхондоо: энэ нь мэдээжийн хэрэг олдвор биш юм - энэ бүхэн нь DBMS биш, харин статистикийн өгөгдөл боловсруулах, аливаа системийг оновчтой болгоход оролцдог хүмүүст удаан хугацааны туршид мэдэгдэж байх ёстой.
Тэгээд: тийм ээ, тэд мэднэ, тэд судалгааныхаа талаар сонирхолтой нийтлэл бичдэг, (UPD .: тайлбар дээр тэд маш сонирхолтой төслийг онцолсон: )
Нөгөө талаар: Би мэдээллийн технологийн мэргэжилтнүүд болох DBA-ийн дунд энэ хандлагыг интернетэд өргөнөөр дурдаж, түгээсэн байхыг би олж харахгүй байна.
Тиймээс, цэг рүү.
Бидэнд ямар нэг төрлийн ажилд үйлчлэхийн тулд тодорхой үйлчилгээний системийг бий болгох даалгавар байна гэж бодъё.
Энэ ажлын талаар мэддэг: энэ нь юу вэ, энэ ажлын чанарыг хэрхэн хэмждэг, энэ чанарыг хэмжих шалгуур нь юу вэ.
Энэ үйлчилгээний системд (эсвэл үүнтэй хамт) ажил яг хэрхэн хийгдэж байгаа талаар илүү их эсвэл бага мэддэг, ойлгогддог гэж бодъё.
"Их эсвэл бага" - энэ нь үйлдвэрлэлд байгаатай тэнцэх хэмжээний туршилтын ачаалал бүхий системд нэгтгэж, хэрэглэх боломжтой тодорхой хэрэгсэл, хэрэгсэл, үйлчилгээг бэлтгэх (эсвэл хаанаас ч авах) боломжтой гэсэн үг юм. үйлдвэрлэлд ажиллахад хангалттай нөхцөлд .
За, энэ үйлчилгээний системийн тохируулгын параметрүүдийн багц нь мэдэгдэж байгаа бөгөөд энэ системийг ажлын бүтээмжийн хувьд тохируулахад ашиглаж болно гэж бодъё.
Асуудал нь юу вэ - энэ үйлчилгээний системийн талаар хангалттай бүрэн ойлголт байхгүй бөгөөд энэ нь тухайн платформ дээр ирээдүйд ачаалах системийн тохиргоог чадварлаг тохируулах, системийн шаардлагатай бүтээмжийг авах боломжийг олгодог.
За. Энэ нь бараг үргэлж тохиолддог.
Та энд юу хийж чадах вэ?
За, хамгийн түрүүнд энэ системийн баримт бичгийг харах хэрэгтэй. Тохируулах параметрийн утгуудын хувьд хүлээн зөвшөөрөгдөх хязгаар гэж юу болохыг ойлгох. Жишээлбэл, координатыг бууруулах аргыг ашиглан туршилтын системийн параметрүүдийн утгыг сонгоно уу.
Тэдгээр. системд тохиргооны параметрүүдийн тодорхой багц утгын хэлбэрээр зарим төрлийн тохиргоог өгөх.
Ачаалал үүсгэгч энэ хэрэгсэл-хэрэгслийг ашиглан түүнд туршилтын ачааллыг ашиглана уу.
Мөн үнэ цэнийг харна уу - хариу үйлдэл эсвэл системийн чанарын хэмжүүр.
Хоёр дахь бодол нь энэ бол маш урт хугацаа гэсэн дүгнэлт байж болох юм.
За, өөрөөр хэлбэл: хэрэв олон тохиргоотой параметрүүд байгаа бол тэдгээрийн утгын хэмжээ их байвал, ачааллын туршилт бүрийг дуусгахад маш их цаг зарцуулдаг бол: тийм ээ, энэ бүхэн хүлээн зөвшөөрөгдөхгүй хугацаа шаардагдана. урт хугацаа.
Эндээс та ойлгож, санаж чадах зүйл байна.
Үйлчилгээний системийн тохиргооны параметрүүдийн утгуудын багцад зарим утгын дараалал хэлбэрээр вектор байгааг олж мэдэх боломжтой.
Ийм вектор бүр, бусад зүйлс нь тэнцүү (энэ векторын нөлөөнд автдаггүй) хэмжүүрийн бүрэн тодорхой утгатай тохирч байгаа нь туршилтын ачааллын дор системийн ажиллагааны чанарын үзүүлэлт юм.
Ий
Системийн тохиргооны векторыг гэж тэмдэглэе 
хаана ; Хаана — системийн тохиргооны параметрүүдийн тоо, эдгээр параметрүүдийн хэд нь байна.
Үүнд харгалзах хэмжүүрийн утга гэж тэмдэглэе
, дараа нь бид функцийг авна:
За, тэгвэл: бүх зүйл тэр дороо бууж ирдэг, миний хувьд: оюутан ахуй үеэсээ бараг мартагдсан, функцийн экстремумыг хайх алгоритмууд.
За, гэхдээ энд зохион байгуулалтын болон хэрэглээний асуулт гарч ирнэ: аль алгоритмыг ашиглах вэ.
- Энэ утгаараа - ингэснээр та гараар бага кодлох боломжтой.
- Мөн энэ нь ажиллахын тулд, өөрөөр хэлбэл. экстремумыг (хэрэв байгаа бол), ядаж координатаас хурдан олсон.
Эхний цэг нь бид ийм алгоритмуудыг аль хэдийн хэрэгжүүлсэн, ямар нэг хэлбэрээр кодонд ашиглахад бэлэн байгаа зарим орчныг хайх хэрэгтэйг сануулж байна.
За, би мэднэ python и cran-r
Хоёрдахь зүйл бол алгоритмууд өөрсдөө, тэдгээр нь юу вэ, ямар шаардлага тавьдаг, ажлын онцлог шинж чанаруудын талаар унших хэрэгтэй гэсэн үг юм.
Мөн тэдний өгч байгаа зүйл нь үр дүн, эсвэл алгоритм өөрөө шууд хамааралтай гаж нөлөө байж болно.
Эсвэл тэдгээрийг алгоритмын үр дүнгээс олж авч болно.
Оролтын нөхцлөөс их зүйл шалтгаална.
Жишээлбэл, хэрэв та ямар нэг шалтгааны улмаас үр дүнг хурдан авах шаардлагатай бол градиент буурах алгоритмуудыг хайж, тэдгээрийн аль нэгийг нь сонгох хэрэгтэй.
Эсвэл, хэрэв цаг хугацаа тийм ч чухал биш бол та жишээлбэл, генетикийн алгоритм гэх мэт стохастик оновчлолын аргыг ашиглаж болно.
Би энэ аргын ажлыг, системийн тохиргоог сонгох, генетикийн алгоритмыг ашиглан дараагийн, өөрөөр хэлбэл лабораторийн ажлыг авч үзэхийг санал болгож байна.
Жинхэнэ:
- Үйлчилгээний системийн хувьд дараах байдалтай байг.
oracle xe 18c - Энэ нь гүйлгээний үйл ажиллагаанд үйлчлэх ба зорилго нь: гүйлгээ/сек-ээр дэд мэдээллийн сангаас хамгийн их дамжуулах чадварыг олж авах.
- Гүйлгээ нь өгөгдөлтэй ажиллах шинж чанар, ажлын нөхцөл байдлаас ихээхэн ялгаатай байж болно.
Эдгээр нь их хэмжээний хүснэгтийн өгөгдлийг боловсруулдаггүй гүйлгээнүүд гэдгийг хүлээн зөвшөөрье.
Тэд дахин хийхээс илүү буцаах өгөгдлийг үүсгэдэггүй, мөр болон том хүснэгтүүдийн их хувийг боловсруулдаггүй гэсэн утгаараа.
Эдгээр нь том эсвэл бага хэмжээний хүснэгтийн нэг мөрийг өөрчилдөг гүйлгээнүүд бөгөөд энэ хүснэгтэд цөөн тооны индексүүд байдаг.
Энэ нөхцөлд: гүйлгээг боловсруулах дэд мэдээллийн сангийн бүтээмжийг урьдчилан сэргийлэх зорилгоор редокс мэдээллийн баазын боловсруулалтын чанараар тодорхойлно.
Disclaimer - хэрэв бид subdb тохиргооны талаар тусгайлан ярих юм бол.
Учир нь ерөнхий тохиолдолд, жишээлбэл, SQL сешнүүдийн хооронд гүйлгээний түгжээ, хэрэглэгчийн хүснэгтийн өгөгдөл болон/эсвэл хүснэгтэн загвартай ажиллах загвараас шалтгаалж болно.
Энэ нь мэдээжийн хэрэг TPS хэмжигдэхүүнд дарангуйлах нөлөө үзүүлэх бөгөөд энэ нь дэд мэдээллийн сантай харьцуулахад экзоген хүчин зүйл байх болно: хүснэгтэн загварыг ингэж зохион бүтээсэн бөгөөд түүн дэх өгөгдөлтэй ажиллахад бөглөрөл үүсдэг.
Тиймээс, туршилтын цэвэр байдлын үүднээс бид энэ хүчин зүйлийг хасч, доор нь би яг яаж хийхийг тодруулах болно.
- Өгөгдлийн санд илгээсэн SQL командуудын 100% нь DML командууд байна гэж тодорхой бодъё.
Туршилтын хувьд хэрэглэгчийн дэд мэдээллийн сантай ажиллах шинж чанарууд ижил байна.
Тухайлбал: skl сессийн тоо, хүснэгтэн өгөгдөл, skl сессүүд тэдэнтэй хэрхэн ажилладаг талаар. - Subd ажилладаг
FORCE LOGGING,ARCHIVELOGмод. Flashback-өгөгдлийн сангийн горимыг дэд түвшинд унтраасан. - Бүртгэлийг дахин хийх: тусдаа файлын системд, тусдаа "диск" дээр байрладаг;
Өгөгдлийн сангийн физик бүрэлдэхүүн хэсгийн үлдсэн хэсэг: өөр, тусдаа файлын системд, тусдаа "диск" дээр:
Физик төхөөрөмжийн талаарх дэлгэрэнгүй мэдээлэл. лабораторийн мэдээллийн сангийн бүрэлдэхүүн хэсгүүд
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Эхэндээ эдгээр ачааллын нөхцөлд би гүйлгээний дэд хэсгийг ашиглахыг хүссэн
Энэ нь гайхалтай шинж чанартай тул би зохиогчоос иш татъя:
SLOB-ийн гол цөм нь "SLOB арга" юм. SLOB арга нь платформуудыг турших зорилготой
өргөдлийн маргаангүйгээр. Хүн хамгийн их техник хангамжийн гүйцэтгэлийг жолоодож чадахгүй
програмын кодыг ашиглан, жишээлбэл, аппликешн түгжих эсвэл бүр хүртэл
Oracle мэдээллийн сангийн блокуудыг хуваалцах. Энэ нь зөв - өгөгдөл хуваалцахад нэмэлт зардал гардаг
өгөгдлийн блокуудад! Гэхдээ SLOB нь анхдагч байдлаараа ийм маргаанаас хамгаалагдсан байдаг.
Энэ тунхаглал: тохирч байна, энэ нь.
Энэ нь cl сессийн параллелизмын түвшинг зохицуулахад тохиромжтой, энэ бол түлхүүр юм -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"Тэдгээр. Ажилчин бүрийн хувьд (бараг нь: subdb-д тусдаа skl сесс) тусдаа хүснэгт үүсгэсэн бөгөөд үүнтэй ажилтан ажилладаг.
Энэ нь ажилчдын сесс хооронд гүйлгээний түгжээ байхгүйг баталгаажуулдаг.
Ажилчин бүр: ижил зүйлийг хийдэг, өөрийн гэсэн ширээтэй, хүснэгтүүд бүгд адилхан.
Бүх ажилчид ижил хугацаанд ажлаа гүйцэтгэдэг.
Түүгээр ч зогсохгүй хангалттай удаан хугацаанд, жишээлбэл, бүртгэлийн шилжүүлэгч нь нэгээс олон удаа тохиолдох болно.
Үүний дагуу холбогдох зардал, үр дагавар бий болсон.
Миний хувьд ажилчдын ажлын үргэлжлэх хугацааг 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] MB.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 дэд програм нь фитнессийн функцийг нэмэгдүүлэхийн тулд хайлт хийдэг.
Тэгэхээр энэ тохиолдолд фитнессийн функц нь векторыг дэд хэсгийн тодорхой параметрүүдийн утгын багц гэж ойлгож, дэд хэсгээс хэмжүүр авах шаардлагатай болж байна.
Энэ нь: өгөгдсөн дэд тохиргоо болон дэд хэсэг дээр өгөгдсөн ачаалалтай хэр олон: дэд хэсэг нь секундэд гүйлгээг боловсруулдаг.
Өөрөөр хэлбэл, задлахдаа фитнессийн функц дотор дараах олон үе шатыг хийх ёстой.
- Тоонуудын оролтын векторыг боловсруулах - үүнийг дэд өгөгдлийн параметрүүдийн утга болгон хувиргах.
- Өгөгдсөн хэмжээтэй өгөгдсөн тооны дахин хийх бүлгүүдийг үүсгэх оролдлого. Түүнээс гадна оролдлого амжилтгүй болж магадгүй юм.
Туршилтын цэвэр байдлын хувьд дэд хэсэгт аль хэдийн байсан сэтгүүлийн бүлгүүд, зарим тоо хэмжээ, хэмжээгээрээ - d.b. устгасан. - Хэрэв өмнөх цэг амжилттай бол: мэдээллийн санд тохиргооны параметрүүдийн утгыг зааж өгөх (дахин: алдаа гарсан байж магадгүй)
- Хэрэв өмнөх алхам амжилттай бол: дэд хэсгийг зогсоож, дэд хэсгийг эхлүүлснээр шинээр заасан параметрийн утгууд хүчин төгөлдөр болно. (дахин: алдаа гарсан байж магадгүй)
- Хэрэв өмнөх алхам амжилттай бол: ачааллын туршилтыг хийнэ. 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, жишээ нь, stop-start, subd параметрийн утгыг тохируулах, дээр үндэслэн гүйцэтгэнэ cran-r функцууд system2
Үүний тусламжтайгаар: зарим bash скрипт эсвэл командыг дууддаг.
Жишээ нь:
set_db_параметр
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 мянган халбага уу: тусдаа асуулт.
Лабораторийн ажлын хүрээнд энэ үзүүлэлт чухал биш, чухал зүйл бол динамик, энэ үнэ цэнэ хэрхэн өөрчлөгдөх явдал юм.
Энд динамик сайн байна.
Хромосомын векторуудыг ялгах га-алгоритм хэмжигдэхүүнд дор хаяж нэг хүчин зүйл ихээхэн нөлөөлдөг нь ойлгомжтой.
Муруй утгуудын нэлээн эрчимтэй динамикаас харахад хамаагүй бага ч гэсэн өөр нэг хүчин зүйл нөлөөлж байна.
Энэ нь танд хэрэгтэй газар юм 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 горимыг оруулах явдал юм.
Хүнсний мэдээллийн санд үүнийг хийх ёстой эсэх нь тусдаа асуулт юм. Энд би зөвхөн хэлэхээр хязгаарлагдаж байна: энэ бол чухал хүчин зүйл юм. - Дэд хэсгийн бүртгэлийн буферийн хэмжээ нь чухал хүчин зүйл болж хувирах нь логик юм.
Бүртгэлийн буферийн хэмжээ бага байх тусам буферийн багтаамж бага байх тусам халих нь элбэг ба/эсвэл шинэ исэлдэлтийн өгөгдлийн хэсэгт чөлөөт талбайг хуваарилах боломжгүй болно.
Энэ нь: бүртгэлийн буферт зай хуваарилах болон түүнээс дахин хийх өгөгдлийг дахин хийх бүлгүүдэд шилжүүлэхтэй холбоотой саатал гэсэн үг.
Эдгээр саатал нь мэдээжийн хэрэг гүйлгээний мэдээллийн баазын нэвтрүүлэх чадварт нөлөөлөх ёстой бөгөөд нөлөөлнө. - Үзүүлэлт
db_block_checksum: сайн, бас ерөнхийдөө ойлгомжтой - гүйлгээний боловсруулалт нь дэд мэдээллийн сангийн буфер кэшэд дарти блокууд үүсэхэд хүргэдэг.
Өгөгдлийн блокуудын хяналтын нийлбэрийг шалгах үед өгөгдлийн сан боловсруулах ёстой - өгөгдлийн блокийн үндсэн хэсгээс эдгээр хяналтын нийлбэрийг тооцоолж, мэдээллийн блокийн толгой хэсэгт бичсэн зүйлээс шалгана уу: таарч байна / таарахгүй байна.
Ийм ажил нь дахин өгөгдөл боловсруулалтыг удаашруулж чадахгүй бөгөөд үүний дагуу энэ параметрийг тохируулах параметр ба механизм нь чухал ач холбогдолтой болж хувирдаг.
Тийм ч учраас худалдагч нь энэ параметрийн баримт бичигт өөр өөр утгыг (параметр) санал болгодог бөгөөд тийм ээ, нөлөөлөл байх болно, гэхдээ та "унтраах" хүртэл өөр утгыг сонгох боломжтой. янз бүрийн нөлөө.
За, дэлхийн хэмжээний дүгнэлт.
Ерөнхийдөө арга нь нэлээд үр дүнтэй болж хувирдаг.
Тэрээр тодорхой үйлчилгээний системийн ачааллын туршилтын эхний үе шатанд ачааллын хувьд түүний (системийн) оновчтой тохиргоог сонгохын тулд ачааллын системийг тохируулах онцлогийг хэт их судлахгүй байх боломжийг олгодог.
Гэхдээ энэ нь үүнийг бүрэн үгүйсгэхгүй - наад зах нь ойлголтын түвшинд: систем нь "тохируулгын бариулууд" болон эдгээр бариулыг эргүүлэх зөвшөөрөгдөх хүрээний талаар мэддэг байх ёстой.
Энэ арга нь системийн оновчтой тохиргоог харьцангуй хурдан олох боломжтой.
Туршилтын үр дүнд үндэслэн системийн гүйцэтгэлийн хэмжигдэхүүн ба системийн тохиргооны параметрүүдийн утгуудын хоорондын хамаарлын шинж чанарын талаар мэдээлэл авах боломжтой.
Мэдээжийн хэрэг, энэ нь систем, түүний үйл ажиллагааны талаар маш гүн гүнзгий ойлголттой болоход хувь нэмэр оруулах ёстой.
Практикт энэ нь системийн ийм туршилтыг бэлтгэх зардалд тохируулсан системийг ойлгох зардлыг солилцох явдал юм.
Би тусад нь тэмдэглэхийг хүсч байна: энэ аргын хувьд системийн туршилтыг арилжааны нөхцөлд ашиглах нөхцөл байдалд нийцүүлэх зэрэг нь маш чухал юм.
Анхаарал, цаг гаргасанд баярлалаа.
Эх сурвалж: www.habr.com