Salam
Tapıntımı bölüşmək qərarına gəldim - düşüncənin, sınaq və səhvin bəhrəsi.
Ümumiyyətlə: bu, əlbəttə ki, tapıntı deyil - bütün bunlar uzun müddətdir tətbiq olunan statistik məlumatların emalı və hər hansı bir sistemin optimallaşdırılması ilə məşğul olanlara məlum olmalı idi, xüsusən də DBMS deyil.
Və: bəli, bilirlər, araşdırmaları ilə bağlı maraqlı məqalələr yazırlar, (UPD.: şərhlərdə çox maraqlı bir layihəyə diqqət çəkdilər: )
Digər tərəfdən: mən bu yanaşmanın İnternetdə İT mütəxəssisləri, DBA arasında geniş yayılmış qeydini və ya yayılmasını görmürəm.
Beləliklə, nöqtəyə.
Fərz edək ki, bir vəzifəmiz var: bir növ işə xidmət etmək üçün müəyyən bir xidmət sistemi qurmaq.
Bu iş haqqında məlumdur: bu nədir, bu işin keyfiyyəti necə ölçülür və bu keyfiyyətin ölçülməsi üçün meyar nədir.
Gəlin, onun az və ya çox bilindiyini və başa düşüldüyünü fərz edək: bu xidmət sistemində (və ya onunla) iş tam olaraq necə həyata keçirilir.
"Daha çox və ya daha az" - bu o deməkdir ki, istehsalda olacaqlara kifayət qədər adekvat sınaq yükü ilə sintez edilə bilən və sistemə tətbiq oluna bilən müəyyən bir alət, yardım proqramı, xidmət hazırlamaq (və ya onu haradan almaq) mümkündür; istehsalatda işləmək üçün kifayət qədər münasib şəraitdə.
Tutaq ki, bu xidmət sistemi üçün bir sıra tənzimləmə parametrləri məlumdur, bu sistemin işinin məhsuldarlığı baxımından bu sistemi konfiqurasiya etmək üçün istifadə edilə bilər.
Və problem nədir - bu xidmət sistemi haqqında kifayət qədər tam bir anlayış yoxdur, bu sistemin parametrlərini müəyyən bir platformada gələcək yükləmə üçün mütəxəssis şəkildə konfiqurasiya etməyə və sistemin tələb olunan məhsuldarlığını əldə etməyə imkan verir.
Yaxşı. Bu, demək olar ki, həmişə belədir.
Burada nə edə bilərsən?
Yaxşı, ağla gələn ilk şey bu sistemin sənədlərinə baxmaqdır. Tənzimləmə parametrlərinin dəyərləri üçün məqbul diapazonların nə olduğunu anlayın. Və, məsələn, koordinat eniş metodundan istifadə edərək, testlərdə sistem parametrləri üçün dəyərlər seçin.
Bunlar. sistemə konfiqurasiya parametrləri üçün müəyyən bir dəyər dəsti şəklində bir növ konfiqurasiya verin.
Bu çox alət-kommunal, yük generatorundan istifadə edərək, ona sınaq yükü tətbiq edin.
Və dəyərə baxın - cavab və ya sistemin keyfiyyətinin metrikası.
İkinci fikir, bunun çox uzun müddət olduğu qənaəti ola bilər.
Yaxşı, yəni: bir çox parametr parametrləri varsa, onların icra edilən dəyərlərinin diapazonları böyükdürsə, hər bir fərdi yük testini tamamlamaq üçün çox vaxt lazımdırsa, onda: bəli, bütün bunlar qəbuledilməz ola bilər. uzun müddət.
Yaxşı, başa düşə və xatırlaya biləcəyiniz şey budur.
Xidmət sisteminin parametrləri parametrlərinin dəyərlər dəstində bəzi dəyərlərin ardıcıllığı kimi bir vektor olduğunu öyrənə bilərsiniz.
Hər bir belə vektor, digər şeylər bərabərdir (bu vektorun təsirinə məruz qalmamaq şərti ilə) tamamilə müəyyən bir metrik dəyərə uyğun gəlir - sınaq yükü altında sistemin iş keyfiyyətinin göstəricisi.
Yəni
Sistem konfiqurasiya vektorunu kimi işarə edək 
Hara ; Harada — sistem konfiqurasiya parametrlərinin sayı, bu parametrlərin neçəsi var.
Və buna uyğun metrikanın dəyəri kimi işarə edək
, onda bir funksiya alırıq:
Yaxşı, onda: mənim vəziyyətimdə hər şey dərhal aşağı düşür: tələbə günlərimdən demək olar ki, unudulmuşam, funksiyanın ekstremumunu axtarmaq üçün alqoritmlər.
Yaxşı, amma burada təşkilati və tətbiqi sual yaranır: hansı alqoritmdən istifadə etmək.
- Mənasında - əl ilə daha az kodlaya biləsiniz.
- Və işləməsi üçün, yəni. ekstremumu (əgər varsa), yaxşı, ən azı koordinat enişindən daha sürətli tapdı.
Birinci nöqtə, bu cür alqoritmlərin artıq tətbiq olunduğu və müəyyən formada kodda istifadəyə hazır olduğu bəzi mühitlərə baxmaq lazım olduğuna işarə edir.
Yaxşı, bilirəm python и cran-r
İkinci məqam o deməkdir ki, alqoritmlərin özləri, onların nə olduğu, tələblərinin nədən ibarət olduğu və işinin xüsusiyyətləri haqqında oxumaq lazımdır.
Verdikləri faydalı yan təsirlər ola bilər - nəticələr və ya birbaşa alqoritmin özündən.
Yaxud onlar alqoritmin nəticələrindən əldə edilə bilər.
Çox şey giriş şərtlərindən asılıdır.
Məsələn, əgər nədənsə daha tez nəticə əldə etmək lazımdırsa, onda siz gradient eniş alqoritmlərinə baxmaq və onlardan birini seçmək lazımdır.
Və ya vaxt o qədər də vacib deyilsə, məsələn, genetik alqoritm kimi stoxastik optimallaşdırma üsullarından istifadə edə bilərsiniz.
Bu yanaşmanın işini, sistem konfiqurasiyasını seçərək, genetik alqoritmdən istifadə edərək, növbəti, belə deyək: laboratoriya işində nəzərdən keçirməyi təklif edirəm.
Orijinal:
- Bir xidmət sistemi olaraq olsun:
oracle xe 18c - O, əməliyyat fəaliyyətinə və məqsədə xidmət etsin: alt verilənlər bazasının ən yüksək ötürücülük qabiliyyətini tranzaksiyalar/san ilə əldə etmək.
- Əməliyyatlar verilənlərlə işləmək xarakterinə və iş kontekstinə görə çox fərqli ola bilər.
Razılaşaq ki, bunlar böyük miqdarda cədvəl məlumatlarını emal etməyən əməliyyatlardır.
O mənada ki, onlar təkrar etməkdən daha çox geri qaytarma məlumatı yaratmırlar və sətirlərin və böyük cədvəllərin böyük faizini emal etmirlər.
Bunlar az və ya çox böyük cədvəldə bir sıra dəyişən, bu cədvəldə az sayda indekslə işləyən əməliyyatlardır.
Bu vəziyyətdə: əməliyyatların işlənməsi üçün alt verilənlər bazasının məhsuldarlığı, qeyd-şərtlə redoks verilənlər bazası tərəfindən emal keyfiyyəti ilə müəyyən ediləcəkdir.
İmtina - subdb parametrləri haqqında xüsusi olaraq danışsaq.
Çünki, ümumi halda, məsələn, cədvəl verilənləri və/və ya cədvəl modeli ilə istifadəçi işinin dizaynına görə SQL seansları arasında əməliyyat kilidləri ola bilər.
Hansı ki, bu, əlbəttə ki, TPS metrikasına depressiv təsir göstərəcək və bu, alt verilənlər bazasına nisbətən ekzogen amil olacaq: yaxşı, cədvəl modeli belə tərtib edilib və oradakı məlumatlarla işləmək tıxanmaların baş verməsidir.
Buna görə də, eksperimentin təmizliyi üçün bu amili istisna edəcəyik və aşağıda dəqiq necə olduğunu aydınlaşdıracağam.
- Dəqiqlik üçün fərz edək ki, verilənlər bazasına təqdim edilən SQL əmrlərinin 100%-i DML əmrləridir.
Testlərdə istifadəçinin alt verilənlər bazası ilə işləməsinin xüsusiyyətləri eyni olsun.
Məhz: skl seanslarının sayı, cədvəl məlumatları, skl seanslarının onlarla necə işlədiyi. - Subd işləyir
FORCE LOGGING,ARCHIVELOGmods. Flashback-verilənlər bazası rejimi subd səviyyəsində söndürülür. - Qeydləri təkrarlayın: ayrıca fayl sistemində, ayrıca "diskdə" yerləşir;
Verilənlər bazasının fiziki komponentinin qalan hissəsi: başqa, ayrıca fayl sistemində, ayrıca "diskdə":
Fiziki cihaz haqqında ətraflı məlumat. laboratoriya verilənlər bazası komponentləri
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 0Başlanğıcda, bu yükləmə şərtləri altında, əməliyyat subd istifadə etmək istədim
Onun elə gözəl xüsusiyyəti var ki, müəllifdən sitat gətirirəm:
SLOB-un mərkəzində “SLOB metodu” dayanır. SLOB Metodunun məqsədi platformaları sınaqdan keçirməkdir
ərizə mübahisəsi olmadan. Maksimum hardware performansını idarə edə bilməzsiniz
məsələn, proqramın kilidlənməsi və ya hətta bağlanması ilə bağlı olan proqram kodundan istifadə etməklə
Oracle Database bloklarının paylaşılması. Düzdür, məlumat mübadiləsi zamanı əlavə yük var
məlumat bloklarında! Ancaq SLOB - standart yerləşdirmədə - bu cür mübahisələrə qarşı immunitetlidir.
Bu bəyannamə: uyğun gəlir, belədir.
Cl seanslarının paralellik dərəcəsini tənzimləmək rahatdır, əsas budur -t yardım proqramını işə salın runit.sh SLOB-dan
DML əmrlərinin faizi subd-yə göndərilən mətn mesajlarının sayında, hər mətn sessiyasında, parametrdə tənzimlənir. UPDATE_PCT
Ayrı-ayrılıqda və çox rahat: SLOB özü, yükləmə seansından əvvəl və sonra - statspack və ya awr-snapshots (hazırlanmaq üçün təyin olunan) hazırlayır.
Lakin məlum oldu ki SLOB 30 saniyədən az davam edən SQL seanslarını dəstəkləmir.
Ona görə də mən əvvəlcə yükləyicinin öz fəhlə-kəndli variantını kodladım, sonra isə işlək vəziyyətdə qaldı.
Yükləyicinin nə etdiyini və bunu necə etdiyini aydınlaşdırmaq üçün icazə verin.
Əsasən yükləyici belə görünür:
İşçi kodu
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İşçilər bu şəkildə işə salınır:
Çalışan işçilər
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"
waitVə işçilər üçün masalar belə hazırlanır:
Cədvəllərin yaradılması
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"Bunlar. Hər bir işçi üçün (praktiki olaraq: DB-də ayrıca SQL sessiyası) işçinin işlədiyi ayrıca cədvəl yaradılır.
Bu, işçi seansları arasında əməliyyat kilidlərinin olmamasını təmin edir.
Hər bir işçi: eyni şeyi edir, öz masası ilə, masalar hamısı eynidir.
Bütün işçilər eyni vaxtda işi yerinə yetirirlər.
Üstəlik, kifayət qədər uzun müddətdir ki, məsələn, bir günlük keçid mütləq baş versin və bir dəfədən çox.
Yaxşı, müvafiq olaraq, əlaqəli xərclər və təsirlər yarandı.
Mənim vəziyyətimdə işçilərin iş müddətini 8 dəqiqəyə konfiqurasiya etdim.
Yük altında alt bölmənin işini təsvir edən statspack hesabatının bir hissəsi
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 işinə qayıdırıq.
Digər şeylər bərabər olduqda, laboratoriya alt verilənlər bazasının aşağıdakı parametrlərinin dəyərlərini dəyişdirəcəyik:
- Verilənlər bazası jurnalının qruplarının ölçüsü. dəyər diapazonu: [32, 1024] MB;
- Verilənlər bazasındakı jurnal qruplarının sayı. qiymət diapazonu: [2,32];
log_archive_max_processesqiymət diapazonu: [1,8];commit_loggingiki dəyərə icazə verilir:batch|immediate;commit_waitiki dəyərə icazə verilir:wait|nowait;log_bufferdəyər diapazonu: [2,128] MB.log_checkpoint_timeoutdəyər diapazonu: [60,1200] saniyədb_writer_processesdəyər diapazonu: [1,4]undo_retentiondəyər diapazonu: [30;300] saniyətransactions_per_rollback_segmentdəyər diapazonu: [1,8]disk_asynch_ioiki dəyərə icazə verilir:true|false;filesystemio_optionsaşağıdakı dəyərlərə icazə verilir:none|setall|directIO|asynch;db_block_checkingaşağıdakı dəyərlərə icazə verilir:OFF|LOW|MEDIUM|FULL;db_block_checksumaşağıdakı dəyərlərə icazə verilir:OFF|TYPICAL|FULL;
Oracle verilənlər bazalarının saxlanmasında təcrübəsi olan bir şəxs, göstərilən məlumatlarla işləmək üçün verilənlər bazasının daha çox məhsuldarlığını əldə etmək üçün göstərilən parametrlərdən və onların məqbul dəyərlərindən nə və hansı dəyərlərin təyin edilməli olduğunu, şübhəsiz ki, artıq deyə bilər. tətbiq kodu, yuxarıda.
Amma.
Laboratoriya işinin məqsədi, optimallaşdırma alqoritminin özünün bizim üçün nisbətən tez bir zamanda aydınlaşdıracağını göstərməkdir.
Bizim üçün geriyə sadəcə olaraq, hansı parametrləri və hansı diapazonlarda dəyişdiriləcəyini öyrənmək kifayətdir ki, sənədə fərdiləşdirilə bilən sistem vasitəsilə baxmaq kifayətdir.
Həm də: seçilmiş optimallaşdırma alqoritminin xüsusi sistemi ilə işləmək üçün istifadə ediləcək kodu kodlayın.
Beləliklə, indi kod haqqında.
haqqında yuxarıda danışdım cran-r, yəni: fərdiləşdirilmiş sistemlə bütün manipulyasiyalar R skripti şəklində təşkil edilir.
Faktiki tapşırıq, təhlil, metrik dəyərlə seçim, sistem vəziyyəti vektorları: bu paketdir GA ()
Paket, bu halda, vektorların (paket baxımından xromosomların) kəsr hissəsi olan nömrələr sətirləri şəklində göstərilməsini gözlədiyi mənada çox uyğun deyil.
Və mənim vektorum, parametr parametrlərinin dəyərlərindən: bunlar 14 kəmiyyətdir - tam ədədlər və sətir dəyərləri.
Əlbəttə ki, sətir dəyərlərinə bəzi xüsusi nömrələr təyin etməklə problemin qarşısını almaq olar.
Beləliklə, sonda R skriptinin əsas hissəsi belə görünür:
GA::ga-ya zəng edin
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@solutionBudur, köməyi ilə lower и upper alt proqram atributları ga mahiyyətcə, axtarış sahəsinin sahəsi müəyyən edilir, onun daxilində uyğunluq funksiyasının maksimum dəyərinin alınacağı belə bir vektor (və ya vektorlar) üçün axtarış aparılacaqdır.
ga alt proqramı fitness funksiyasını maksimuma çatdıran axtarışı həyata keçirir.
Yaxşı, onda belə çıxır ki, bu vəziyyətdə vektoru subd-nin müəyyən parametrləri üçün dəyərlər dəsti kimi başa düşən fitnes funksiyası subd-dən bir metrik almalıdır.
Yəni: verilmiş subd quraşdırması və subd-də verilən yüklə nə qədər: subd saniyədə əməliyyatları emal edir.
Yəni, açılarkən fitnes funksiyası daxilində aşağıdakı çox addımlar yerinə yetirilməlidir:
- Rəqəmlərin giriş vektorunun işlənməsi - onu subdata parametrləri üçün dəyərlərə çevirmək.
- Verilmiş ölçüdə verilmiş sayda təkrar qruplar yaratmaq cəhdi. Üstəlik, cəhd uğursuz ola bilər.
Təcrübənin saflığı üçün subd-də artıq mövcud olan jurnal qrupları, müəyyən miqdarda və müəyyən ölçüdə - d.b. silindi. - Əvvəlki nöqtə uğurlu olarsa: verilənlər bazasına konfiqurasiya parametrlərinin dəyərlərinin təyin edilməsi (yenidən: uğursuzluq ola bilər)
- Əvvəlki addım uğurlu olarsa: yeni təyin olunmuş parametr dəyərlərinin qüvvəyə minməsi üçün subd-nin dayandırılması, subd-nin işə salınması. (yenə: xəta ola bilər)
- Əvvəlki addım uğurlu olarsa: yükləmə testini həyata keçirin. subd-dən ölçüləri əldə edin.
- Subd-ni orijinal vəziyyətinə qaytarın, yəni. əlavə log qruplarını silin, orijinal alt verilənlər bazası konfiqurasiyasını işə qaytarın.
Fitness funksiyası kodu
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. bütün işlər: fitnes funksiyasında yerinə yetirilir.
Ga-alt proqram vektorları, daha doğrusu, xromosomları emal edir.
Hansı ki, bizim üçün ən vacib olan, fitnes funksiyasının böyük dəyər verdiyi genlərə malik xromosomların seçilməsidir.
Bu, mahiyyət etibarilə, N ölçülü axtarış fəzasında vektordan istifadə edərək optimal xromosom dəstinin axtarışı prosesidir.
Çox aydın, ətraflı , R-kod nümunələri ilə, bir genetik alqoritmin işi.
İki texniki məqamı ayrıca qeyd etmək istərdim.
Funksiyadan köməkçi çağırışlar evaluate, məsələn, stop-start, subd parametrinin dəyərinin təyin edilməsi əsasında həyata keçirilir cran-r funksiyaları system2
Onun köməyi ilə: bəzi bash skripti və ya əmri çağırılır.
Misal üçün:
set_db_parametri
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)
}
}İkinci nöqtə xəttdir, evaluate xüsusi metrik dəyəri və onun müvafiq tənzimləmə vektorunu log faylına saxlamaqla funksiyalar:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)Bu vacibdir, çünki bu verilənlər massivindən tənzimləmə vektorunun komponentlərindən hansının metrik qiymətə daha çox və ya az təsir göstərdiyi barədə əlavə məlumat əldə etmək mümkün olacaq.
Yəni: atribut-əhəmiyyət təhlili aparmaq mümkün olacaq.
Bəs nə baş verə bilər?
Qrafik şəklində, testləri artan metrik qaydada sifariş etsəniz, şəkil aşağıdakı kimidir:
Metrikin həddindən artıq dəyərlərinə uyğun gələn bəzi məlumatlar:
Burada, nəticələrlə ekran görüntüsündə aydınlaşdıracağam: tənzimləmə vektorunun dəyərləri tərtib edilmiş parametrlərin/parametr dəyərlərinin diapazonlarının nömrə siyahısı baxımından deyil, fitnes funksiyası kodu baxımından verilir. mətndə yuxarıda.
Yaxşı. Çox yoxsa az, ~8 min tps: ayrıca sual.
Laboratoriya işləri çərçivəsində bu rəqəm önəmli deyil, vacib olan dinamikadır, bu qiymətin necə dəyişməsidir.
Burada dinamika yaxşıdır.
Aydındır ki, ən azı bir amil metrikanın, ga-alqoritmin dəyərinə əhəmiyyətli dərəcədə təsir göstərir, xromosom vektorları ilə çeşidlənir: əhatə olunur.
Əyri dəyərlərinin kifayət qədər güclü dinamikasına əsasən, əhəmiyyətli dərəcədə kiçik olsa da, təsir göstərən ən azı bir başqa amil var.
Bu sizə lazım olan yerdir attribute-importance hansı atributları (yaxşı, bu halda tənzimləmə vektorunun komponentləri) və metrik dəyərə nə dərəcədə təsir etdiyini başa düşmək üçün təhlil.
Və bu məlumatdan: əhəmiyyətli atributlardakı dəyişikliklərin hansı amillərə təsir etdiyini anlayın.
İcra etmək attribute-importance bir çox yolla ola bilər.
Bu məqsədlər üçün alqoritmi bəyənirəm randomForest Eyni adlı R paketi ()
randomForest, mən onun ümumi işini və xüsusilə atributların əhəmiyyətini qiymətləndirməyə yanaşmasını başa düşdüyümə görə, cavab dəyişəninin atributlardan asılılığının müəyyən modelini qurur.
Bizim vəziyyətimizdə cavab dəyişəni yük testlərində verilənlər bazasından əldə edilən bir metrikdir: tps;
Və atributlar tənzimləmə vektorunun komponentləridir.
Və belədir randomForest hər bir model atributunun əhəmiyyətini iki rəqəmlə qiymətləndirir: %IncMSE — modeldə bu atributun olması/yoxluğu bu modelin MSE keyfiyyətini necə dəyişir (Orta kvadrat xəta);
Və IncNodePurity, bu atributun dəyərlərinə əsaslanaraq, müşahidələri olan bir məlumat dəstinin nə qədər yaxşı bölünə biləcəyini əks etdirən bir rəqəmdir ki, bir hissədə metrikanın bir dəyəri ilə, digərində isə izah edilən məlumat var. metrikanın başqa bir dəyəri.
Yaxşı, yəni: bu nə dərəcədə təsnifat atributudur (RandomForest-də ən aydın, rus dilində izahat gördüm ).
Yük testlərinin nəticələri ilə məlumat dəstinin işlənməsi üçün işçi-kəndli R kodu:
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 alqoritmin hiperparametrlərini birbaşa əllərinizlə seçə və modelin keyfiyyətinə diqqət yetirərək, doğrulama verilənlər bazası üzrə proqnozları daha dəqiq yerinə yetirən modeli seçə bilərsiniz.
Bu iş üçün bir növ funksiya yaza bilərsiniz (yeri gəlmişkən, bir növ optimallaşdırma alqoritmindən istifadə etməklə).
R paketindən istifadə edə bilərsiniz caret, məqam önəmli deyil.
Nəticədə, bu halda, atributların əhəmiyyət dərəcəsini qiymətləndirmək üçün aşağıdakı nəticə əldə edilir:
Yaxşı. Beləliklə, qlobal düşüncəyə başlaya bilərik:
- Belə çıxır ki, bu sınaq şəraitində ən əhəmiyyətlisi parametrdir
commit_wait
Texniki cəhətdən o, subdb log buferindən cari jurnal qrupuna redo məlumatlarının yazılması io əməliyyatının icra rejimini təyin edir: sinxron və ya asinxron.
DəyərnowaitBu, tps metrikasının dəyərinin demək olar ki, şaquli, dəfələrlə artması ilə nəticələnir: bu, asinxron io rejiminin təkrarlama qruplarına daxil edilməsidir.
Ayrı bir sual, bunu qida bazasında etməli olub-olmamağınızdır. Burada yalnız qeyd etməklə kifayətlənirəm: bu mühüm amildir. - Subd: log buferinin ölçüsünün əhəmiyyətli bir amil olması məntiqlidir.
Jurnal buferinin ölçüsü nə qədər kiçik olarsa, onun tamponlama qabiliyyəti bir o qədər az olarsa, bir o qədər tez-tez daşır və/və ya yeni redoks məlumatlarının bir hissəsi üçün orada boş sahəni ayıra bilmir.
Bu o deməkdir: log buferində yerin ayrılması və/yaxud ondan redo məlumatlarının təkrar qruplara atılması ilə bağlı gecikmələr.
Bu gecikmələr, əlbəttə ki, əməliyyatlar üçün verilənlər bazasının ötürmə qabiliyyətinə təsir etməlidir və təsir göstərir. - Parametr
db_block_checksum: yaxşı, həmçinin, ümumiyyətlə, aydındır - əməliyyatın işlənməsi alt verilənlər bazasının bufer keşində darty bloklarının meydana gəlməsinə səbəb olur.
Hansı ki, verilənlər bloklarının yoxlama məbləğlərinin yoxlanılması aktiv olduqda, verilənlər bazası emal etməlidir - verilənlər blokunun gövdəsindən bu yoxlama məbləğlərini hesablayın, verilənlər blokunun başlığında yazılanlarla yoxlayın: uyğun gəlir/uyğun gəlmir.
Bu cür iş, yenə də məlumatların işlənməsini gecikdirə bilməz və buna görə də bu parametri təyin edən parametr və mexanizm əhəmiyyətli olur.
Buna görə də satıcı bu parametr üçün sənədlərdə onun (parametr) fərqli dəyərləri təklif edir və qeyd edir ki, bəli, təsir olacaq, amma yaxşı, siz “söndürülmüş” və müxtəlif təsirlər.
Yaxşı, qlobal bir nəticə.
Ümumiyyətlə, yanaşma olduqca işlək görünür.
O, müəyyən bir xidmət sisteminin yük sınağının ilkin mərhələlərində onun (sistemin) yük üçün optimal konfiqurasiyasını seçmək, sistemin yük üçün qurulmasının xüsusiyyətlərini çox araşdırmamaq üçün özünə tamamilə imkan verir.
Ancaq bu, bunu tamamilə istisna etmir - ən azı anlayış səviyyəsində: sistem "tənzimləmə düymələri" və bu düymələrin icazə verilən fırlanma diapazonları haqqında bilinməlidir.
Bundan sonra yanaşma nisbətən tez optimal sistem konfiqurasiyasını tapa bilər.
Və sınaq nəticələrinə əsasən, sistemin keyfiyyət göstəriciləri ilə sistemin konfiqurasiya parametrlərinin dəyərləri arasındakı əlaqənin xarakteri haqqında məlumat əldə etmək mümkündür.
Hansı ki, əlbəttə ki, sistemin bu çox dərin anlayışının yaranmasına, onun ən azı müəyyən bir yük altında işləməsinə kömək etməlidir.
Praktikada bu, sistemin belə sınaqdan keçirilməsinin hazırlanması xərcləri üçün fərdiləşdirilmiş sistemin başa düşülməsi xərclərinin mübadiləsidir.
Ayrı-ayrılıqda qeyd etmək istərdim: bu yanaşmada sistem testinin kommersiya istismarında olacağı iş şəraitinə adekvatlıq dərəcəsi çox vacibdir.
Diqqətinizə və vaxtınıza görə təşəkkür edirik.
Mənbə: www.habr.com