ProHoster > Blogs > Administrācija > Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu

Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu

Sveiki

Nolēmu padalÄ«ties ar savu atradumu ā€“ pārdomu, izmēģinājumu un kļūdu augli.
Kopumā: tas, protams, nav atradums - tam visam jau sen vajadzēja zināt tiem, kas nodarbojas ar lietiŔķo statistisko datu apstrādi un jebkuras sistēmas optimizāciju, ne vienmēr tieÅ”i DBVS.
Un: jā, viņi zina, viņi raksta interesantus rakstus par saviem pētījumiem, piemērs (UPD.: komentāros viņi norādīja uz ļoti interesantu projektu: ottertune )
No otras puses: es neredzu, ka Ŕī pieeja bÅ«tu plaÅ”i pieminēta vai izplatÄ«ta internetā IT speciālistu, DBA, vidÅ«.

Tātad, pie lietas.

Pieņemsim, ka mums ir uzdevums: izveidot noteiktu pakalpojumu sistēmu, lai apkalpotu kādu darbu.

Par Å”o darbu ir zināms: kas tas ir, kā tiek mērÄ«ta Ŕī darba kvalitāte un kāds ir Ŕīs kvalitātes mērÄ«Å”anas kritērijs.

Pieņemsim arÄ«, ka tas ir vairāk vai mazāk zināms un saprotams: kā tieÅ”i tiek veikts darbs Å”ajā pakalpojumu sistēmā (vai ar to).

ā€œVairāk vai mazākā€ - tas nozÄ«mē, ka ir iespējams sagatavot (vai kaut kur iegÅ«t) noteiktu rÄ«ku, utilÄ«tu, servisu, ko var sintezēt un pielietot sistēmā ar testa slodzi, kas ir pietiekami adekvāta tam, kas bÅ«s ražoÅ”anā, apstākļos, kas ir pietiekami piemēroti darbam ražoÅ”anā.

Nu, pieņemsim, ka ir zināms Ŕīs pakalpojumu sistēmas regulÄ“Å”anas parametru kopums, ar kuru palÄ«dzÄ«bu var konfigurēt Å”o sistēmu tās darba produktivitātes ziņā.

Un kāda ir problēma - nav pietiekami pilnÄ«ga izpratne par Å”o pakalpojumu sistēmu, kas ļauj prasmÄ«gi konfigurēt Ŕīs sistēmas iestatÄ«jumus turpmākai slodzei uz dotās platformas un iegÅ«t nepiecieÅ”amo sistēmas produktivitāti.

Nu. Tā tas ir gandrīz vienmēr.

Ko jūs varat darīt Ŕeit?

Nu, pirmais, kas nāk prātā, ir apskatÄ«t Ŕīs sistēmas dokumentāciju. Saprotiet, kādi ir regulÄ“Å”anas parametru vērtÄ«bu pieļaujamie diapazoni. Un, piemēram, izmantojot koordinātu nolaiÅ”anās metodi, testos atlasiet sistēmas parametru vērtÄ«bas.

Tie. pieŔķiriet sistēmai sava veida konfigurāciju Ä«paÅ”as vērtÄ«bu kopas veidā tās konfigurācijas parametriem.

Pielietojiet tai testa slodzi, izmantojot Ŕo paŔu rīku-utilītu, slodzes ģeneratoru.
Un paskatieties uz vērtÄ«bu ā€“ atbildi vai sistēmas kvalitātes metriku.

Otra doma var būt secinājums, ka tas ir ļoti ilgs laiks.

Nu, tas ir: ja ir daudz regulÄ“Å”anas parametru, ja to vērtÄ«bu diapazoni ir lieli, ja katra atseviŔķa slodzes pārbaude aizņem daudz laika, tad: jā, tas viss var aizņemt nepieņemami daudz no laika.

Lūk, ko jūs varat saprast un atcerēties.

Jūs varat uzzināt, ka pakalpojumu sistēmas iestatījumu parametru vērtību kopā ir vektors kā dažu vērtību secība.

Katrs Ŕāds vektors, ja citas lietas ir vienādas (jo Å”is vektors to neietekmē), atbilst pilnÄ«gi noteiktai metrikas vērtÄ«bai - sistēmas darbÄ«bas kvalitātes rādÄ«tājam testa slodzes apstākļos.

Ti

ApzÄ«mēsim sistēmas konfigurācijas vektoru kā Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmuKur Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu; Kur Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu ā€” sistēmas konfigurācijas parametru skaits, cik no Å”iem parametriem ir.

Un tam atbilstoŔā metrikas vērtÄ«ba Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu apzÄ«mēsim to kā
Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu, tad mēs iegūstam funkciju: Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu

Nu tad: manā gadÄ«jumā viss uzreiz sanāk: gandrÄ«z aizmirsts no studentu laikiem, algoritmi funkcijas galējÄ«bas meklÄ“Å”anai.

Labi, bet Ŕeit rodas organizatorisks un lietiŔķs jautājums: kuru algoritmu izmantot.

  1. Tādā ziņā - lai ar roku mazāk varētu kodēt.
  2. Un lai tas darbotos, t.i. atrada ekstrēmu (ja tāds ir), nu, vismaz ātrāk par koordinātu nolaiÅ”anos.

Pirmais punkts norāda, ka mums ir jāskatās uz dažām vidēm, kurās Ŕādi algoritmi jau ir ieviesti un kaut kādā veidā ir gatavi lietoÅ”anai kodā.
Nu es zinu python Šø cran-r

Otrais punkts nozÄ«mē, ka jums ir jāizlasa par paÅ”iem algoritmiem, kas tie ir, kādas ir to prasÄ«bas un to darba iezÄ«mes.

Un tas, ko tie dod, var bÅ«t noderÄ«gi blakusefekti ā€“ rezultāti vai tieÅ”i no paÅ”a algoritma.

Vai arī tos var iegūt no algoritma rezultātiem.

Daudz kas ir atkarīgs no ievades apstākļiem.

Piemēram, ja kāda iemesla dēļ jums ir nepiecieÅ”ams ātrāk iegÅ«t rezultātu, jums ir jāmeklē gradienta nolaiÅ”anās algoritmi un jāizvēlas viens no tiem.

Vai arī, ja laiks nav tik svarīgs, varat, piemēram, izmantot stohastiskās optimizācijas metodes, piemēram, ģenētisko algoritmu.

Es ierosinu Ŕīs pieejas darbu, izvēloties sistēmas konfigurāciju, izmantojot Ä£enētisko algoritmu, izskatÄ«t nākamajā, tā sakot, laboratorijas darbā.

Oriģināls:

  1. Lai pastāv kā pakalpojumu sistēma: oracle xe 18c
  2. Lai tas kalpo transakciju darbÄ«bai un mērÄ·im: iegÅ«t pēc iespējas lielāku apakÅ”datubāzes caurlaidspēju, darÄ«jumos/sek.
  3. DarÄ«jumi var bÅ«t ļoti atŔķirÄ«gi pēc darba ar datiem un darba konteksta.
    Vienosimies, ka tie ir darījumi, kuros netiek apstrādāts liels tabulas datu apjoms.
    Tādā ziņā, ka tie neÄ£enerē vairāk atsaukÅ”anas datu nekā pārtaisÄ«Å”ana un neapstrādā lielu rindu un lielu tabulu procentuālo daļu.

Tie ir darījumi, kas maina vienu rindu vairāk vai mazāk lielā tabulā ar nelielu skaitu indeksu Ŕajā tabulā.

Šādā situācijā: darījumu apstrādes apakŔdatu bāzes produktivitāti ar atrunu noteiks redox datu bāzes apstrādes kvalitāte.

Atruna - ja mēs runājam tieÅ”i par subdb iestatÄ«jumiem.

Jo vispārÄ«gā gadÄ«jumā starp SQL sesijām var bÅ«t, piemēram, transakciju bloÄ·Ä“Å”anas, kas izriet no lietotāja darba dizaina ar tabulas datiem un/vai tabulas modeļa.

Kas, protams, nomācoÅ”i ietekmēs TPS metriku, un tas bÅ«s eksogēns faktors attiecÄ«bā pret apakÅ”datu bāzi: lÅ«k, Ŕādi tika izveidots tabulas modelis un darbs ar tajā esoÅ”ajiem datiem, kas rada aizsprostojumus.

Tāpēc eksperimenta tÄ«rÄ«bas labad mēs izslēgsim Å”o faktoru, un tālāk es paskaidroÅ”u, kā tieÅ”i.

  1. Precīzāk pieņemsim, ka 100% datu bāzei iesniegto SQL komandu ir DML komandas.
    Lai testos lietotāja darba ar apakŔdatu bāzi raksturojums ir vienāds.
    Proti: skl sesiju skaits, tabulas dati, kā skl sesijas ar tām darbojas.
  2. Subd darbojas FORCE LOGGING, ARCHIVELOG modifikācijas. Atmiņas datu bāzes režīms ir izslēgts apakÅ”lÄ«menÄ«.
  3. PārtaisÄ«t žurnālus: atrodas atseviŔķā failu sistēmā, atseviŔķā ā€œdiskāā€;
    Pārējā datu bāzes fiziskā sastāvdaļa: citā, atseviŔķā failu sistēmā, atseviŔķā ā€œdiskāā€:

Sīkāka informācija par fizisko ierīci. laboratorijas datu bāzes komponenti

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

Sākotnēji Å”ajos slodzes apstākļos es gribēju izmantot transakciju subd SLOB-lietderÄ«ba
Tam ir tik brÄ«niŔķīga iezÄ«me, es citÄ“Å”u autoru:

SLOB pamatā ir ā€œSLOB metodeā€. SLOB metodes mērÄ·is ir pārbaudÄ«t platformas
bez strÄ«da par pieteikumu. Nevar nodroÅ”ināt maksimālu aparatÅ«ras veiktspēju
izmantojot lietojumprogrammas kodu, kas, piemēram, ir saistÄ«ts ar lietojumprogrammas bloÄ·Ä“Å”anu vai pat
Oracle datu bāzes bloku koplietoÅ”ana. TieÅ”i tā ā€” datu koplietoÅ”ana rada papildu izmaksas
datu blokos! Taču SLOB savā noklusējuma izvietoÅ”anā ir imÅ«na pret Ŕādu strÄ«du.

Šī deklarācija: atbilst, tā ir.
Ir ērti regulēt cl sesiju paralēlisma pakāpi, tas ir galvenais -t palaidiet utilītu runit.sh no SLOB
DML komandu procentuālais daudzums tiek regulēts apakÅ”grupai nosÅ«tÄ«to Ä«sziņu skaitā, katrā teksta sesijā, parametrā UPDATE_PCT
AtseviŔķi un ļoti ērti: SLOB pati pirms un pēc ielādes sesijas - sagatavo statspack vai awr-snapshots (kas ir iestatÄ«ts sagatavoÅ”anā).

Tomēr izrādījās, ka SLOB neatbalsta SQL sesijas, kuru ilgums ir mazāks par 30 sekundēm.
Tāpēc es vispirms iekodēju savu, strādnieku-zemnieku iekrāvēja versiju, un tad tā palika ekspluatācijā.

Skaidrības labad ļaujiet man paskaidrot, ko dara iekrāvējs un kā tas to dara.
BÅ«tÄ«bā iekrāvējs izskatās Ŕādi:

Strādnieka kods

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

Darbinieki tiek palaisti Ŕādā veidā:

SkriejoŔi strādnieki

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

Un galdi strādniekiem tiek sagatavoti Ŕādi:

Tabulu veidoŔana

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"

Tie. Katram darbiniekam (praktiski: atseviŔķa SQL sesija DB) tiek izveidota atseviŔķa tabula, ar kuru darbinieks strādā.

Tas nodroÅ”ina, ka starp darbinieku sesijām nav darÄ«jumu bloÄ·Ä“Å”anas.
Katrs strādnieks: dara vienu un to paŔu, ar savu galdu, visi galdi ir vienādi.
Visi darbinieki veic darbu vienādu laiku.
Turklāt pietiekami ilgu laiku, lai, piemēram, baļķu pārslēgÅ”ana noteikti notiktu, un vairāk nekā vienu reizi.
Attiecīgi radās saistītās izmaksas un sekas.
Manā gadījumā strādnieku darba ilgumu konfigurēju uz 8 minūtēm.

Statspack pārskata daļa, kurā aprakstīta apakŔgrupas darbība slodzes laikā

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

Atgriežoties pie laboratorijas darbiem.
Ja citas lietas bÅ«s vienādas, mēs mainÄ«sim Ŕādu laboratorijas apakÅ”datu bāzes parametru vērtÄ«bas:

  1. Datu bāzes žurnālu grupu lielums. vērtību diapazons: [32, 1024] MB;
  2. Žurnālu grupu skaits datu bāzē. vērtību diapazons: [2,32];
  3. log_archive_max_processes vērtību diapazons: [1,8];
  4. commit_logging ir atļautas divas vērtības: batch|immediate;
  5. commit_wait ir atļautas divas vērtības: wait|nowait;
  6. log_buffer vērtību diapazons: [2,128] MB.
  7. log_checkpoint_timeout vērtību diapazons: [60,1200 XNUMX] sekundes
  8. db_writer_processes vērtību diapazons: [1,4]
  9. undo_retention vērtību diapazons: [30;300] sekundes
  10. transactions_per_rollback_segment vērtību diapazons: [1,8]
  11. disk_asynch_io ir atļautas divas vērtības: true|false;
  12. filesystemio_options ir atļautas Ŕādas vērtÄ«bas: none|setall|directIO|asynch;
  13. db_block_checking ir atļautas Ŕādas vērtÄ«bas: OFF|LOW|MEDIUM|FULL;
  14. db_block_checksum ir atļautas Ŕādas vērtÄ«bas: OFF|TYPICAL|FULL;

Cilvēks ar pieredzi Oracle datu bāzu uzturÄ“Å”anā noteikti jau var pateikt, kādas un uz kādām vērtÄ«bām ir jāiestata, no norādÄ«tajiem parametriem un to pieļaujamām vērtÄ«bām, lai iegÅ«tu lielāku datu bāzes produktivitāti darbam ar datiem, ko norāda pieteikuma kods Å”eit iepriekÅ”.

Bet

Laboratorijas darba jēga ir parādÄ«t, ka pats optimizācijas algoritms to mums noskaidros salÄ«dzinoÅ”i ātri.

Mums atliek tikai ieskatīties dokumentā, izmantojot pielāgojamo sistēmu, lai uzzinātu, kādus parametrus un kādos diapazonos mainīt.
Un arī: iekodējiet kodu, kas tiks izmantots darbam ar izvēlētā optimizācijas algoritma pielāgoto sistēmu.

Tātad, tagad par kodu.
Es runāju iepriekÅ” par cran-r, t.i.: visas manipulācijas ar pielāgoto sistēmu tiek organizētas R skripta formā.

Faktiskais uzdevums, analÄ«ze, atlase pēc metriskās vērtÄ«bas, sistēmas stāvokļa vektori: Ŕī ir pakete GA (dokumentāciju)
Pakete Å”ajā gadÄ«jumā nav Ä«paÅ”i piemērota tādā ziņā, ka tā sagaida, ka vektori (hromosomas, ja paketes izteiksmē) tiks norādÄ«ti skaitļu virkņu veidā ar daļēju daļu.

Un mans vektors no iestatÄ«Å”anas parametru vērtÄ«bām: tie ir 14 daudzumi - veseli skaitļi un virkņu vērtÄ«bas.

Protams, no problēmas var viegli izvairÄ«ties, virkņu vērtÄ«bām pieŔķirot dažus konkrētus skaitļus.

Tādējādi galu galā R skripta galvenais gabals izskatās Ŕādi:

Zvaniet uz 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

LÅ«k, ar palÄ«dzÄ«bu lower Šø upper apakÅ”programmas atribÅ«ti ga bÅ«tÄ«bā ir norādÄ«ts meklÄ“Å”anas telpas apgabals, kurā tiks veikta tāda vektora (vai vektoru) meklÄ“Å”ana, kuram tiks iegÅ«ta atbilstÄ«bas funkcijas maksimālā vērtÄ«ba.

ApakÅ”programma ga veic meklÄ“Å”anu, maksimāli palielinot fitnesa funkciju.

Nu, tad izrādās, ka Å”ajā gadÄ«jumā fitnesa funkcijai, saprotot vektoru kā vērtÄ«bu kopu noteiktiem subd parametriem, jāsaņem metrika no apakÅ”daļas.

Tas ir: cik daudz ar noteiktu apakÅ”grupas iestatÄ«jumu un noteiktu apakÅ”grupas slodzi: apakÅ”grupa apstrādā darÄ«jumus sekundē.

Tas nozÄ«mē, ka, atlokot, fitnesa funkcijā ir jāveic Ŕādas vairākas darbÄ«bas:

  1. Apstrādājiet skaitļu ievades vektoru - pārveidojiet to apakÅ”datu parametru vērtÄ«bās.
  2. Mēģinājums izveidot noteiktu skaitu noteikta izmēra pārtaisÄ«Å”anas grupu. Turklāt mēģinājums var bÅ«t neveiksmÄ«gs.
    Žurnālu grupas, kas jau eksistēja apakŔā, kaut kādā daudzumā un kāda izmēra, eksperimenta tÄ«rÄ«bas labad - d.b. dzēsts.
  3. Ja iepriekŔējais punkts ir veiksmÄ«gs: konfigurācijas parametru vērtÄ«bu norādÄ«Å”ana datu bāzē (atkal: var bÅ«t kļūme)
  4. Ja iepriekŔējā darbÄ«ba ir veiksmÄ«ga: apakÅ”grupas apturÄ“Å”ana, apakÅ”grupas palaiÅ”ana, lai stātos spēkā tikko norādÄ«tās parametru vērtÄ«bas. (atkal: var bÅ«t kļūme)
  5. Ja iepriekŔējā darbÄ«ba ir veiksmÄ«ga: veiciet slodzes pārbaudi. iegÅ«t metriku no apakÅ”d.
  6. Atgrieziet subd sākotnējā stāvoklÄ«, t.i. dzēst papildu žurnālu grupas, atgriezt sākotnējo apakÅ”datubāzes konfigurāciju darbam.

Fitnesa funkcijas kods

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

Tas. viss darbs: veikts fitnesa funkcijā.

Ga-apakŔprogramma apstrādā vektorus vai, pareizāk sakot, hromosomas.
Kurā mums vissvarīgākā ir hromosomu atlase ar gēniem, kuriem fitnesa funkcija rada lielas vērtības.

Tas bÅ«tÄ«bā ir process, kurā tiek meklēts optimālais hromosomu komplekts, izmantojot vektoru N-dimensijas meklÄ“Å”anas telpā.

Ļoti skaidri, detalizēti skaidrojums, ar R-koda piemēriem, ģenētiskā algoritma darbs.

Es vēlos atseviŔķi atzÄ«mēt divus tehniskos punktus.

Papildzvani no funkcijas evaluate, piemēram, stop-start, iestatot subd parametra vērtību, tiek veiktas, pamatojoties uz cran-r funkcijas system2

Ar kuras palīdzību: tiek izsaukts kāds bash skripts vai komanda.

Piemēram:

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

Otrais punkts ir lÄ«nija, evaluate funkcijas, saglabājot noteiktu metrikas vērtÄ«bu un tai atbilstoÅ”o regulÄ“Å”anas vektoru žurnāla failā:

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

Tas ir svarÄ«gi, jo no Ŕī datu masÄ«va bÅ«s iespējams iegÅ«t papildu informāciju par to, kura no skaņoÅ”anas vektora sastāvdaļām vairāk vai mazāk ietekmē metrikas vērtÄ«bu.

Tas ir: būs iespējams veikt atribūtu-importamce analīzi.

Tātad, kas var notikt?

Diagrammas formā, ja pasÅ«tāt testus augoŔā metrikas secÄ«bā, attēls ir Ŕāds:

Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu

Daži dati, kas atbilst metrikas galējām vērtībām:
Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu
Å eit, ekrānuzņēmumā ar rezultātiem, es precizÄ“Å”u: regulÄ“Å”anas vektora vērtÄ«bas ir norādÄ«tas fitnesa funkcijas koda izteiksmē, nevis parametru skaitļu saraksta / parametru vērtÄ«bu diapazona izteiksmē, kas tika formulēts. augstāk tekstā.

Nu. Vai tas ir daudz vai maz, ~8 tūkstoŔi tps: atseviŔķs jautājums.
Laboratorijas darbu ietvaros Å”is skaitlis nav svarÄ«gs, svarÄ«ga ir dinamika, kā Ŕī vērtÄ«ba mainās.

Dinamika Ŕeit ir laba.
Ir acÄ«mredzams, ka vismaz viens faktors bÅ«tiski ietekmē metrikas vērtÄ«bu, ga-algoritms, Ŕķirojot pa hromosomu vektoriem: aptverts.
Spriežot pēc diezgan spēcīgās līkņu vērtību dinamikas, ir vēl vismaz viens faktors, kas, lai arī ievērojami mazāks, tomēr ietekmē.

Å eit jums tas ir nepiecieÅ”ams attribute-importance analÄ«ze, lai saprastu, kādi atribÅ«ti (Å”ajā gadÄ«jumā skaņoÅ”anas vektora komponenti) un cik lielā mērā tie ietekmē metrikas vērtÄ«bu.
Un no Ŕīs informācijas: izprotiet, kādus faktorus ietekmēja nozÄ«mÄ«gu atribÅ«tu izmaiņas.

skrējiens attribute-importance iespējams dažādos veidos.

Šiem nolūkiem man patīk algoritms randomForest R pakotne ar tādu paŔu nosaukumu (dokumentāciju)
randomForest, kā es saprotu viņa darbu kopumā un viņa pieeju, lai novērtētu atribÅ«tu svarÄ«gumu, jo Ä«paÅ”i, veido noteiktu modeli atbildes mainÄ«gā atkarÄ«bai no atribÅ«tiem.

Mūsu gadījumā atbildes mainīgais ir metrika, kas iegūta no datu bāzes slodzes testos: tps;
Un atribÅ«ti ir regulÄ“Å”anas vektora sastāvdaļas.

Un tā randomForest novērtē katra modeļa atribÅ«ta nozÄ«mi ar diviem skaitļiem: %IncMSE ā€” kā Ŕī atribÅ«ta esamÄ«ba/neesamÄ«ba modelÄ« maina Ŕī modeļa MSE kvalitāti (Mean Squared Error);

Un IncNodePurity ir skaitlis, kas atspoguļo to, cik labi, pamatojoties uz Ŕī atribÅ«ta vērtÄ«bām, var sadalÄ«t datu kopu ar novērojumiem tā, lai vienā daļā bÅ«tu dati ar vienu izskaidrotās metrikas vērtÄ«bu, bet otrā ar cita metrikas vērtÄ«ba.
Nu, tas ir: cik lielā mērā tas ir klasificējoÅ”s atribÅ«ts (visskaidrāko skaidrojumu krievu valodā redzēju RandomForest Å”eit).

Strādnieka-zemnieka R-kods datu kopas apstrādei ar slodzes testu rezultātiem:

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

JÅ«s varat tieÅ”i ar savām rokām atlasÄ«t algoritma hiperparametrus un, koncentrējoties uz modeļa kvalitāti, atlasÄ«t modeli, kas precÄ«zāk atbilst validācijas datu kopas prognozēm.
Šim darbam var uzrakstīt kaut kādu funkciju (starp citu, atkal izmantojot kaut kādu optimizācijas algoritmu).

Varat izmantot R pakotni caret, ne jau būtība ir svarīga.

Rezultātā Å”ajā gadÄ«jumā tiek iegÅ«ts Ŕāds rezultāts, lai novērtētu atribÅ«tu svarÄ«guma pakāpi:

Zinātniskā poke metode jeb kā izvēlēties datu bāzes konfigurāciju, izmantojot etalonus un optimizācijas algoritmu

Nu. Tādējādi mēs varam sākt globālas pārdomas:

  1. Izrādās, ka visnozÄ«mÄ«gākais Å”ajos testÄ“Å”anas apstākļos bija parametrs commit_wait
    Tehniski tas norāda izpildes režīmu io operācijai, rakstot redo datus no subdb žurnāla bufera uz paÅ”reizējo žurnālu grupu: sinhrona vai asinhrona.
    VērtÄ«ba nowait kas rada gandrÄ«z vertikālu, vairākkārtēju tps metrikas vērtÄ«bas pieaugumu: tas ir asinhronā io režīma iekļauÅ”ana pārtaisÄ«Å”anas grupās.
    AtseviŔķs jautājums ir par to, vai jums tas jādara pārtikas datubāzē. Å eit es aprobežojos tikai ar apgalvojumu: tas ir nozÄ«mÄ«gs faktors.
  2. Loģiski, ka subd: žurnāla bufera lielums izrādās būtisks faktors.
    Jo mazāks ir žurnāla bufera izmērs, jo mazāka ir tā buferizācijas jauda, ā€‹ā€‹jo biežāk tas pārplÅ«st un/vai nespēj tajā pieŔķirt brÄ«vu apgabalu daļai jaunu redoksdatu.
    Tas nozÄ«mē: aizkaves, kas saistÄ«tas ar vietas pieŔķirÅ”anu žurnāla buferÄ« un/vai pārtaisÄ«Å”anas datu izmeÅ”anu no tā pārtaisÄ«Å”anas grupās.
    Å Ä«s kavÄ“Å”anās, protams, ietekmē un ietekmē darÄ«jumu datu bāzes caurlaidspēju.
  3. Parametrs db_block_checksum: labi, arÄ« kopumā ir skaidrs - darÄ«jumu apstrādes rezultātā apakÅ”datu bāzes bufera keÅ”atmiņā veidojas darty bloki.
    Kura, pārbaudot datu bloku kontrolsummas ir iespējota, datu bāzei ir jāapstrādā - jāaprēķina Ŕīs kontrolsummas no datu bloka pamatteksta, jāpārbauda ar to, kas rakstÄ«ts datu bloka galvenē: atbilst/nesakrÄ«t.
    Šāds darbs atkal nevar neaizkavēt datu apstrādi, un attiecÄ«gi parametrs un mehānisms, kas nosaka Å”o parametru, izrādās bÅ«tisks.
    Tāpēc pārdevējs Ŕī parametra dokumentācijā piedāvā dažādas tā (parametra) vērtÄ«bas un atzÄ«mē, ka jā, ietekme bÅ«s, bet, labi, jÅ«s varat izvēlēties dažādas vērtÄ«bas, lÄ«dz ā€œizslēgtsā€ un dažādas ietekmes.

Nu, globāls secinājums.

Kopumā pieeja izrādās diezgan efektīva.

ViņŔ diezgan atļaujas noteiktas servisa sistēmas slodzes testÄ“Å”anas sākumposmā, lai izvēlētos tās (sistēmas) optimālo slodzei konfigurāciju, pārāk neiedziļināties sistēmas slodzei uzstādÄ«Å”anas specifikā.

Bet tas to pilnÄ«bā neizslēdz - vismaz izpratnes lÄ«menÄ«: sistēmai ir jāzina par ā€œregulÄ“Å”anas pogāmā€ un Å”o kloÄ·u pieļaujamajiem grieÅ”anās diapazoniem.

Pēc tam Ŕī pieeja var salÄ«dzinoÅ”i ātri atrast optimālo sistēmas konfigurāciju.
Un, pamatojoties uz testÄ“Å”anas rezultātiem, ir iespējams iegÅ«t informāciju par sakarÄ«bu starp sistēmas veiktspējas rādÄ«tājiem un sistēmas iestatÄ«jumu parametru vērtÄ«bām.

Kam, protams, vajadzētu veicināt Ŕīs ļoti dziļās izpratnes raÅ”anos par sistēmu, tās darbÄ«bu, vismaz pie noteiktas slodzes.

Praksē tā ir pielāgotās sistēmas izpratnes izmaksu apmaiņa pret Ŕādas sistēmas testÄ“Å”anas sagatavoÅ”anas izmaksām.

Es vēlos atseviŔķi atzÄ«mēt: Å”ajā pieejā ļoti svarÄ«ga ir sistēmas testÄ“Å”anas atbilstÄ«bas pakāpe ekspluatācijas apstākļiem, kas tai bÅ«s komerciālā darbÄ«bā.

Paldies par uzmanību un laiku.

Avots: www.habr.com

Pievieno komentāru