Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman

Hello

Saya memutuskan untuk berkongsi penemuan saya - buah fikiran, percubaan dan kesilapan.
Secara keseluruhannya: ini bukan satu penemuan, sudah tentu - semua ini sepatutnya diketahui sejak sekian lama, kepada mereka yang terlibat dalam pemprosesan data statistik gunaan dan pengoptimuman mana-mana sistem, tidak semestinya DBMS secara khusus.
Dan: ya, mereka tahu, mereka menulis artikel menarik mengenai penyelidikan mereka, contoh (UPD.: dalam komen mereka menunjukkan projek yang sangat menarik: ottertune )
Sebaliknya: secara langsung saya tidak melihat sebarang sebutan atau penyebaran meluas mengenai pendekatan ini di Internet dalam kalangan pakar IT, DBA.

So, to the point.

Mari kita anggap bahawa kita mempunyai tugas: untuk menyediakan sistem perkhidmatan tertentu untuk perkhidmatan sesuatu jenis kerja.

Kerja ini diketahui: apakah itu, bagaimana kualiti kerja ini diukur, dan apakah kriteria untuk mengukur kualiti ini.

Mari kita anggap juga bahawa ia lebih kurang diketahui dan difahami: dengan tepat cara kerja dilakukan dalam (atau dengan) sistem perkhidmatan ini.

"Lebih kurang" - ini bermakna bahawa adalah mungkin untuk menyediakan (atau mendapatkannya dari suatu tempat) alat, utiliti, perkhidmatan tertentu yang boleh disintesis dan digunakan pada sistem dengan beban ujian yang mencukupi untuk apa yang akan dikeluarkan, dalam keadaan yang cukup memadai untuk bekerja dalam pengeluaran.

Baiklah, mari kita anggap bahawa satu set parameter pelarasan untuk sistem perkhidmatan ini diketahui, yang boleh digunakan untuk mengkonfigurasi sistem ini dari segi produktiviti kerjanya.

Dan apakah masalahnya - tidak ada pemahaman yang cukup lengkap tentang sistem perkhidmatan ini, yang membolehkan anda mengkonfigurasi tetapan sistem ini dengan mahir untuk beban masa depan pada platform tertentu dan mendapatkan produktiviti sistem yang diperlukan.

Nah. Ini hampir selalu berlaku.

Apa yang boleh anda lakukan di sini?

Nah, perkara pertama yang terlintas di fikiran ialah melihat dokumentasi untuk sistem ini. Fahami apakah julat yang boleh diterima untuk nilai parameter pelarasan. Dan, sebagai contoh, menggunakan kaedah keturunan koordinat, pilih nilai untuk parameter sistem dalam ujian.

Itu. berikan sistem beberapa jenis konfigurasi, dalam bentuk set nilai tertentu untuk parameter konfigurasinya.

Sapukan beban ujian padanya, menggunakan penjana beban utiliti utiliti ini.
Dan lihat pada nilai - tindak balas, atau metrik kualiti sistem.

Pemikiran kedua mungkin kesimpulan bahawa ini adalah masa yang sangat lama.

Baiklah, iaitu: jika terdapat banyak parameter tetapan, jika julat nilainya yang dijalankan adalah besar, jika setiap ujian beban individu mengambil banyak masa untuk diselesaikan, maka: ya, semua ini mungkin mengambil masa yang tidak boleh diterima. masa yang lama.

Nah, inilah yang anda boleh faham dan ingat.

Anda boleh mengetahui bahawa dalam set nilai parameter tetapan sistem perkhidmatan terdapat vektor, sebagai urutan beberapa nilai.

Setiap vektor tersebut, perkara lain adalah sama (dalam hal ia tidak dipengaruhi oleh vektor ini), sepadan dengan nilai metrik yang pasti sepenuhnya - penunjuk kualiti operasi sistem di bawah beban ujian.

Ie

Mari kita nyatakan vektor konfigurasi sistem sebagai Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimumanJika Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman; di mana Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman — bilangan parameter konfigurasi sistem, berapa banyak parameter ini terdapat.

Dan nilai metrik yang sepadan dengan ini Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman mari kita nyatakan sebagai
Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman, maka kita mendapat fungsi: Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman

Nah, kemudian: segala-galanya serta-merta datang ke, dalam kes saya: hampir terlupa dari zaman pelajar saya, algoritma untuk mencari ekstrem fungsi.

Baiklah, tetapi di sini timbul persoalan organisasi dan gunaan: algoritma yang manakah hendak digunakan.

  1. Dalam erti kata - supaya anda boleh mengekod kurang dengan tangan.
  2. Dan agar ia berfungsi, i.e. mendapati ekstrem (jika ada), baik, sekurang-kurangnya lebih cepat daripada keturunan koordinat.

Perkara pertama membayangkan bahawa kita perlu melihat ke arah beberapa persekitaran di mana algoritma sedemikian telah dilaksanakan, dan, dalam beberapa bentuk, sedia untuk digunakan dalam kod.
Nah, saya tahu python и cran-r

Perkara kedua bermakna anda perlu membaca tentang algoritma itu sendiri, apakah ia, apakah keperluannya, dan ciri kerjanya.

Dan apa yang mereka berikan boleh menjadi kesan sampingan yang berguna - hasil, atau terus daripada algoritma itu sendiri.

Atau mereka boleh didapati daripada hasil algoritma.

Banyak bergantung pada keadaan input.

Sebagai contoh, jika, atas sebab tertentu, anda perlu mendapatkan hasil dengan lebih cepat, anda perlu melihat ke arah algoritma keturunan kecerunan dan memilih salah satu daripadanya.

Atau, jika masa tidak begitu penting, anda boleh, contohnya, menggunakan kaedah pengoptimuman stokastik, seperti algoritma genetik.

Saya bercadang untuk mempertimbangkan kerja pendekatan ini, memilih konfigurasi sistem, menggunakan algoritma genetik, dalam seterusnya, boleh dikatakan: kerja makmal.

Asal:

  1. Biar ada, sebagai sistem perkhidmatan: oracle xe 18c
  2. Biarkan ia melaksanakan aktiviti transaksi dan matlamat: untuk mendapatkan daya pemprosesan tertinggi yang mungkin bagi subdatabase, dalam transaksi/saat.
  3. Transaksi boleh menjadi sangat berbeza dalam sifat bekerja dengan data dan konteks kerja.
    Mari kita bersetuju bahawa ini adalah urus niaga yang tidak memproses sejumlah besar data jadual.
    Dalam erti kata bahawa mereka tidak menjana lebih banyak data buat asal daripada buat semula dan tidak memproses peratusan besar baris dan jadual besar.

Ini ialah urus niaga yang menukar satu baris dalam jadual yang lebih kurang besar, dengan bilangan indeks yang kecil pada jadual ini.

Dalam keadaan ini: produktiviti subdatabase untuk memproses transaksi akan, dengan tempahan, ditentukan oleh kualiti pemprosesan oleh pangkalan data redoks.

Penafian - jika kita bercakap secara khusus tentang tetapan subdb.

Kerana, dalam kes umum, mungkin terdapat, sebagai contoh, kunci transaksi antara sesi SQL, disebabkan oleh reka bentuk kerja pengguna dengan data jadual dan/atau model jadual.

Yang, sudah tentu, akan memberi kesan yang menyedihkan pada metrik TPS dan ini akan menjadi faktor eksogen, berbanding dengan subdatabase: nah, ini adalah cara model jadual direka bentuk dan kerja dengan data di dalamnya yang tersumbat berlaku.

Oleh itu, untuk kesucian eksperimen, kami akan mengecualikan faktor ini, dan di bawah saya akan menjelaskan dengan tepat bagaimana.

  1. Mari kita anggap, untuk kepastian, bahawa 100% daripada arahan SQL yang diserahkan kepada pangkalan data adalah arahan DML.
    Biarkan ciri pengguna berfungsi dengan subdatabase adalah sama dalam ujian.
    Iaitu: bilangan sesi skl, data jadual, cara sesi skl berfungsi dengan mereka.
  2. Subd berfungsi di FORCE LOGGING, ARCHIVELOG mod. Mod pangkalan data flashback dimatikan, pada tahap subd.
  3. Buat semula log: terletak dalam sistem fail berasingan, pada "cakera" yang berasingan;
    Selebihnya komponen fizikal pangkalan data: dalam sistem fail berasingan yang lain, pada "cakera" yang berasingan:

Butiran lanjut tentang peranti fizikal. komponen pangkalan data makmal

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

Pada mulanya, di bawah keadaan pemuatan ini, saya ingin menggunakan subd transaksi SLOB-utiliti
Ia mempunyai ciri yang begitu indah, saya akan memetik pengarang:

Di tengah-tengah SLOB ialah "kaedah SLOB." Kaedah SLOB bertujuan untuk menguji platform
tanpa pertikaian permohonan. Seseorang tidak boleh memacu prestasi perkakasan maksimum
menggunakan kod aplikasi yang, sebagai contoh, terikat dengan penguncian aplikasi atau pun
berkongsi blok Pangkalan Data Oracle. Betul—ada overhed apabila berkongsi data
dalam blok data! Tetapi SLOB—dalam penggunaan lalainya—kebal terhadap perbalahan sedemikian.

Perisytiharan ini: sepadan, ia adalah.
Adalah mudah untuk mengawal tahap keselarian sesi cl, ini adalah kuncinya -t melancarkan utiliti runit.sh daripada SLOB
Peratusan arahan DML dikawal, dalam bilangan mesej teks yang dihantar ke subd, setiap sesi teks, parameter UPDATE_PCT
Secara berasingan dan sangat mudah: SLOB sendiri, sebelum dan selepas sesi pemuatan - menyediakan pek statistik, atau tangkapan awr (apa yang ditetapkan untuk disediakan).

Namun, ternyata begitu SLOB tidak menyokong sesi SQL dengan tempoh kurang daripada 30 saat.
Oleh itu, saya mula-mula mengekodkan versi pemuat saya sendiri, pekerja-petani, dan kemudian ia kekal beroperasi.

Biar saya jelaskan perkara yang dilakukan oleh pemuat dan cara ia melakukannya, untuk kejelasan.
Pada asasnya pemuat kelihatan seperti ini:

Kod pekerja

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

Pekerja dilancarkan dengan cara ini:

Pekerja berlari

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

Dan meja untuk pekerja disediakan seperti ini:

Mencipta jadual

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"

Itu. Untuk setiap pekerja (secara praktikal: sesi SQL yang berasingan dalam DB) jadual berasingan dicipta, yang digunakan oleh pekerja itu.

Ini memastikan ketiadaan kunci transaksi antara sesi pekerja.
Setiap pekerja: melakukan perkara yang sama, dengan meja sendiri, meja semuanya sama.
Semua pekerja melakukan kerja untuk jumlah masa yang sama.
Selain itu, untuk masa yang cukup lama supaya, sebagai contoh, suis log pasti akan berlaku, dan lebih daripada sekali.
Oleh itu, kos dan kesan yang berkaitan timbul.
Dalam kes saya, saya mengkonfigurasi tempoh kerja pekerja pada 8 minit.

Sekeping laporan pek statistik yang menerangkan operasi subd di bawah beban

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

Berbalik kepada kerja makmal.
Kami akan, perkara lain yang sama, mengubah nilai parameter berikut subdatabase makmal:

  1. Saiz kumpulan log pangkalan data. julat nilai: [32, 1024] MB;
  2. Bilangan kumpulan jurnal dalam pangkalan data. julat nilai: [2,32];
  3. log_archive_max_processes julat nilai: [1,8];
  4. commit_logging dua nilai dibenarkan: batch|immediate;
  5. commit_wait dua nilai dibenarkan: wait|nowait;
  6. log_buffer julat nilai: [2,128] MB.
  7. log_checkpoint_timeout julat nilai: [60,1200] saat
  8. db_writer_processes julat nilai: [1,4]
  9. undo_retention julat nilai: [30;300] saat
  10. transactions_per_rollback_segment julat nilai: [1,8]
  11. disk_asynch_io dua nilai dibenarkan: true|false;
  12. filesystemio_options nilai berikut dibenarkan: none|setall|directIO|asynch;
  13. db_block_checking nilai berikut dibenarkan: OFF|LOW|MEDIUM|FULL;
  14. db_block_checksum nilai berikut dibenarkan: OFF|TYPICAL|FULL;

Seseorang yang berpengalaman dalam menyelenggara pangkalan data Oracle sudah tentu sudah boleh mengatakan apa dan nilai apa yang perlu ditetapkan, dari parameter yang ditentukan dan nilai yang boleh diterimanya, untuk mendapatkan produktiviti pangkalan data yang lebih besar untuk kerja dengan data yang ditunjukkan oleh kod aplikasi , di sini di atas.

Tetapi.

Tujuan kerja makmal adalah untuk menunjukkan bahawa algoritma pengoptimuman itu sendiri akan menjelaskan perkara ini untuk kita dengan cepat.

Bagi kami, yang tinggal hanyalah melihat ke dalam dokumen, melalui sistem yang boleh disesuaikan, cukup untuk mengetahui parameter yang perlu diubah dan dalam julat apa.
Dan juga: kodkan kod yang akan digunakan untuk berfungsi dengan sistem tersuai bagi algoritma pengoptimuman yang dipilih.

Jadi, sekarang mengenai kod.
Saya bercakap di atas cran-r, iaitu: semua manipulasi dengan sistem tersuai diatur dalam bentuk skrip R.

Tugas sebenar, analisis, pemilihan mengikut nilai metrik, vektor keadaan sistem: ini adalah pakej GA (dokumentasi)
Pakej, dalam kes ini, tidak begitu sesuai, dalam erti kata ia menjangkakan vektor (kromosom, jika dari segi pakej) ditentukan dalam bentuk rentetan nombor dengan bahagian pecahan.

Dan vektor saya, dari nilai parameter tetapan: ini adalah 14 kuantiti - integer dan nilai rentetan.

Masalahnya, sudah tentu, mudah dielakkan dengan memberikan beberapa nombor tertentu kepada nilai rentetan.

Oleh itu, pada akhirnya, bahagian utama skrip R kelihatan seperti ini:

Hubungi 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

Di sini, dengan bantuan lower и upper atribut subrutin ga pada asasnya, kawasan ruang carian ditentukan, di mana carian akan dilakukan untuk vektor (atau vektor) sedemikian yang mana nilai maksimum fungsi kecergasan akan diperolehi.

Subrutin ga melakukan carian memaksimumkan fungsi kecergasan.

Jadi, ternyata, dalam kes ini, fungsi kecergasan perlu, memahami vektor sebagai satu set nilai untuk parameter tertentu subd, menerima metrik daripada subd.

Iaitu: berapa banyak, dengan persediaan subd yang diberikan dan beban yang diberikan pada subd: subd memproses urus niaga sesaat.

Iaitu, apabila berlaku, pelbagai langkah berikut mesti dilakukan di dalam fungsi kecergasan:

  1. Memproses vektor input nombor - menukarnya kepada nilai untuk parameter subdata.
  2. Percubaan untuk mencipta bilangan kumpulan buat semula tertentu dengan saiz tertentu. Lebih-lebih lagi, percubaan itu mungkin tidak berjaya.
    Kumpulan majalah yang telah wujud dalam subd, dalam kuantiti tertentu dan saiz tertentu, untuk ketulenan eksperimen - d.b. dipadamkan.
  3. Jika titik sebelumnya berjaya: tentukan nilai parameter konfigurasi ke pangkalan data (sekali lagi: mungkin terdapat kegagalan)
  4. Jika langkah sebelumnya berjaya: hentikan subd, mulakan subd supaya nilai parameter yang baru ditentukan berkuat kuasa. (sekali lagi: mungkin ada masalah)
  5. Jika langkah sebelumnya berjaya: lakukan ujian beban. dapatkan metrik daripada subd.
  6. Kembalikan subd kepada keadaan asalnya, i.e. padam kumpulan log tambahan, kembalikan konfigurasi subdatabase asal untuk berfungsi.

Kod fungsi kecergasan

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)
}

Itu. semua kerja: dilakukan dalam fungsi kecergasan.

Subrutin ga memproses vektor, atau, lebih tepat lagi, kromosom.
Di mana, apa yang paling penting bagi kami ialah pemilihan kromosom dengan gen yang mana fungsi kecergasan menghasilkan nilai yang besar.

Ini, pada dasarnya, adalah proses mencari set kromosom yang optimum menggunakan vektor dalam ruang carian N-dimensi.

Sangat jelas, terperinci penjelasan, dengan contoh kod R, kerja algoritma genetik.

Saya ingin ambil perhatian secara berasingan dua perkara teknikal.

Panggilan tambahan daripada fungsi evaluate, sebagai contoh, berhenti-mula, menetapkan nilai parameter subd, dilakukan berdasarkan cran-r fungsi system2

Dengan bantuannya: beberapa skrip atau arahan bash dipanggil.

Sebagai contoh:

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)
}
}

Titik kedua ialah garis, evaluate fungsi, dengan menyimpan nilai metrik tertentu dan vektor penalaan yang sepadan dengan fail log:

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)

Ini penting, kerana daripada tatasusunan data ini, adalah mungkin untuk mendapatkan maklumat tambahan tentang komponen vektor penalaan yang mana mempunyai kesan yang lebih besar atau lebih kecil pada nilai metrik.

Iaitu: adalah mungkin untuk menjalankan analisis atribut-importamce.

Jadi apa yang boleh berlaku?

Dalam bentuk graf, jika anda memesan ujian dalam tertib metrik menaik, gambar adalah seperti berikut:

Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman

Beberapa data yang sepadan dengan nilai ekstrem metrik:
Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman
Di sini, dalam tangkapan skrin dengan hasilnya, saya akan menjelaskan: nilai vektor penalaan diberikan dari segi kod fungsi kecergasan, bukan dari segi senarai nombor parameter/julat nilai parameter, yang dirumuskan di atas dalam teks.

Nah. Adakah banyak atau sedikit, ~8 ribu tps: soalan berasingan.
Dalam rangka kerja makmal, angka ini tidak penting, yang penting ialah dinamik, bagaimana nilai ini berubah.

Dinamik di sini bagus.
Jelas sekali bahawa sekurang-kurangnya satu faktor mempengaruhi nilai metrik, algoritma ga, menyusun vektor kromosom: dilindungi.
Berdasarkan dinamik nilai lengkung yang agak kuat, terdapat sekurang-kurangnya satu lagi faktor yang, walaupun jauh lebih kecil, mempunyai pengaruh.

Di sinilah anda memerlukannya attribute-importance analisis untuk memahami atribut apa (baik, dalam kes ini, komponen vektor penalaan) dan sejauh mana ia mempengaruhi nilai metrik.
Dan daripada maklumat ini: fahami faktor yang dipengaruhi oleh perubahan dalam atribut penting.

Run attribute-importance mungkin dengan cara yang berbeza.

Untuk tujuan ini, saya suka algoritma randomForest Pakej R dengan nama yang sama (dokumentasi)
randomForest, kerana saya memahami kerjanya secara umum dan pendekatannya untuk menilai kepentingan atribut khususnya, membina model tertentu pergantungan pembolehubah tindak balas pada atribut.

Dalam kes kami, pembolehubah tindak balas ialah metrik yang diperoleh daripada pangkalan data dalam ujian beban: tps;
Dan atribut ialah komponen vektor penalaan.

Jadi disini randomForest menilai kepentingan setiap atribut model dengan dua nombor: %IncMSE — bagaimana kehadiran/ketiadaan atribut ini dalam model mengubah kualiti MSE model ini (Mean Squared Error);

Dan IncNodePurity ialah nombor yang mencerminkan seberapa baik, berdasarkan nilai atribut ini, set data dengan pemerhatian boleh dibahagikan, supaya di satu bahagian terdapat data dengan satu nilai metrik yang dijelaskan, dan di bahagian lain dengan satu lagi nilai metrik.
Baiklah, iaitu: sejauh mana sifat pengelasan ini (saya melihat penjelasan bahasa Rusia yang paling jelas di RandomForest di sini).

Kod R pekerja-petani untuk memproses set data dengan hasil ujian beban:

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

Anda boleh terus memilih hiperparameter algoritma dengan tangan anda dan, menumpukan pada kualiti model, pilih model yang lebih tepat memenuhi ramalan pada set data pengesahan.
Anda boleh menulis beberapa jenis fungsi untuk kerja ini (sekali lagi, menggunakan beberapa jenis algoritma pengoptimuman).

Anda boleh menggunakan pakej R caret, bukan intinya yang penting.

Akibatnya, dalam kes ini, keputusan berikut diperoleh untuk menilai tahap kepentingan atribut:

Kaedah cucuk saintifik, atau cara memilih konfigurasi pangkalan data menggunakan penanda aras dan algoritma pengoptimuman

Nah. Oleh itu, kita boleh memulakan refleksi global:

  1. Ternyata yang paling penting, di bawah keadaan ujian ini, adalah parameter commit_wait
    Secara teknikal, ia menentukan mod pelaksanaan operasi io untuk menulis semula data daripada penimbal log subdb kepada kumpulan log semasa: segerak atau tak segerak.
    Nilai nowait yang menghasilkan peningkatan yang hampir menegak, berbilang dalam nilai metrik tps: ini ialah kemasukan mod io tak segerak dalam kumpulan buat semula.
    Soalan berasingan ialah sama ada anda perlu melakukan ini dalam pangkalan data makanan atau tidak. Di sini saya mengehadkan diri saya hanya untuk menyatakan: ini adalah faktor penting.
  2. Adalah logik bahawa saiz penimbal log subd: ternyata menjadi faktor penting.
    Lebih kecil saiz penimbal log, lebih kecil kapasiti penimbalannya, lebih kerap ia melimpah dan/atau ketidakupayaan untuk memperuntukkan kawasan bebas di dalamnya untuk sebahagian daripada data redoks baharu.
    Ini bermakna: kelewatan yang dikaitkan dengan memperuntukkan ruang dalam penimbal log dan/atau membuang data buat semula daripadanya ke dalam kumpulan buat semula.
    Kelewatan ini, sudah tentu, harus dan menjejaskan daya pemprosesan pangkalan data untuk transaksi.
  3. Parameter db_block_checksum: baik, juga, secara amnya jelas - pemprosesan transaksi membawa kepada pembentukan blok darty dalam cache penimbal subdatabase.
    Yang mana, apabila menyemak jumlah semak bagi sekatan data didayakan, pangkalan data perlu memproses - mengira jumlah semakan ini daripada badan sekatan data, semaknya dengan apa yang tertulis dalam pengepala sekatan data: sepadan/tidak sepadan.
    Kerja sedemikian, sekali lagi, tidak boleh tidak menangguhkan pemprosesan data, dan oleh itu, parameter dan mekanisme yang menetapkan parameter ini ternyata penting.
    Itulah sebabnya vendor menawarkan, dalam dokumentasi untuk parameter ini, nilai yang berbeza untuknya (parameter) dan ambil perhatian bahawa ya, akan ada kesan, tetapi, anda boleh memilih nilai yang berbeza, sehingga "mati" dan impak yang berbeza.

Nah, kesimpulan global.

Pendekatan itu, secara umum, ternyata cukup berkesan.

Dia benar-benar membenarkan dirinya, pada peringkat awal ujian beban sistem perkhidmatan tertentu, untuk memilih konfigurasi optimumnya (sistem) untuk beban, bukan untuk menyelidiki terlalu banyak kekhususan untuk menyediakan sistem untuk beban.

Tetapi ia tidak mengecualikan sepenuhnya - sekurang-kurangnya pada tahap pemahaman: sistem mesti diketahui tentang "tombol pelarasan" dan julat putaran yang dibenarkan bagi tombol ini.

Pendekatan ini kemudiannya boleh mencari konfigurasi sistem yang optimum dengan cepat.
Dan berdasarkan hasil ujian, adalah mungkin untuk mendapatkan maklumat tentang sifat hubungan antara metrik prestasi sistem dan nilai parameter tetapan sistem.

Yang, sudah tentu, harus menyumbang kepada kemunculan pemahaman yang sangat mendalam tentang sistem ini, operasinya, sekurang-kurangnya di bawah beban tertentu.

Dalam amalan, ini adalah pertukaran kos memahami sistem tersuai untuk kos penyediaan ujian sistem tersebut.

Saya ingin ambil perhatian secara berasingan: dalam pendekatan ini, tahap kecukupan ujian sistem kepada keadaan operasi yang akan ada dalam operasi komersial adalah amat penting.

Terima kasih atas perhatian dan masa anda.

Sumber: www.habr.com

Tambah komen