Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау

Сәлем

Мен өз олжаммен бөлісуді жөн көрдім - ойдың жемісі, сынақ пен қателік.
Жалпы алғанда: бұл табылған нәрсе емес, әрине - мұның бәрі қолданбалы статистикалық деректерді өңдеумен және кез келген жүйені оңтайландырумен айналысатындарға, нақты МҚБЖ емес, бұрыннан белгілі болуы керек еді.
Және: иә, олар біледі, олар өздерінің зерттеулері бойынша қызықты мақалалар жазады, мысал (UPD.: түсініктемелерде олар өте қызықты жобаны атап өтті: құмырсқа )
Екінші жағынан: мен бұл тәсілдің Интернетте IT мамандары, DBA арасында кең таралғанын немесе таралуын көрмеймін.

Сонымен, нүктеге дейін.

Бізде қандай да бір жұмыс түріне қызмет көрсету үшін белгілі бір қызмет көрсету жүйесін орнату міндеті тұр деп есептейік.

Бұл жұмыс туралы белгілі: бұл не, бұл жұмыстың сапасы қалай өлшенеді және бұл сапаны өлшеудің критерийі қандай.

Сондай-ақ, бұл азды-көпті белгілі және түсінікті деп есептейік: дәл осы қызмет жүйесінде (немесе онымен) жұмыс қалай орындалады.

«Артық немесе аз» - бұл өндірісте болатын нәрсеге жеткілікті сынақ жүктемесі бар жүйеге синтезделуге және қолдануға болатын белгілі бір құралды, қызметтік бағдарламаны, қызметті дайындауға (немесе оны бір жерден алуға) болатындығын білдіреді, өндірісте жұмыс істеуге жеткілікті жағдайда.

Ал, осы қызмет көрсету жүйесі үшін реттеу параметрлерінің жиынтығы белгілі деп есептейік, оны жұмыс өнімділігі тұрғысынан осы жүйені конфигурациялау үшін пайдалануға болады.

Мәселе неде - бұл қызмет көрсету жүйесі туралы жеткілікті толық түсінік жоқ, бұл жүйенің параметрлерін берілген платформаға болашақта жүктеу үшін сарапшылықпен конфигурациялауға және жүйенің қажетті өнімділігін алуға мүмкіндік береді.

Жақсы. Бұл әрдайым дерлік болады.

Мұнда не істей аласың?

Бірінші ойға келетін нәрсе - бұл жүйенің құжаттамасын қарау. Реттеу параметрлерінің мәндері үшін қолайлы диапазондардың қандай екенін түсініңіз. Және, мысалы, координаттарды түсіру әдісін пайдаланып, сынақтардағы жүйе параметрлері үшін мәндерді таңдаңыз.

Анау. жүйеге оның конфигурация параметрлері үшін белгілі бір мәндер жиынтығы түрінде конфигурацияның қандай да бір түрін беріңіз.

Осы құрал-утилитаны, жүктеме генераторын пайдаланып, оған сынақ жүктемесін қолданыңыз.
Ал мәнді қараңыз - жауап немесе жүйе сапасының көрсеткіші.

Екінші ой, бұл өте ұзақ уақыт деген қорытынды болуы мүмкін.

Яғни, егер орнату параметрлері көп болса, олардың орындалатын мәндерінің диапазоны үлкен болса, әрбір жеке жүктеме сынағы өте көп уақытты қажет етсе, онда: иә, мұның бәрі қолайсыз болуы мүмкін. ұзақ уақыт.

Міне, сіз түсінуге және есте сақтауға болатын нәрсе.

Қызметтік жүйе параметрлерінің мәндерінің жиынында кейбір мәндердің тізбегі ретінде вектор бар екенін білуге ​​болады.

Әрбір осындай вектор, басқалары тең (бұл вектор әсер етпейтіндіктен) метриканың толық белгілі мәніне сәйкес келеді - сынақ жүктемесі кезінде жүйенің жұмыс сапасының көрсеткіші.

яғни

Жүйе конфигурациясының векторын былай деп белгілейік Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдауқайда Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау; Қайда Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау — жүйе конфигурациясының параметрлерінің саны, осы параметрлердің қаншасы бар.

Және осыған сәйкес метриканың мәні Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау деп белгілейік
Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау, онда біз функцияны аламыз: Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау

Ал, сонда: бәрі бірден келеді, менің жағдайымда: студенттік кезімнен ұмытып кете жаздады, функцияның экстремумын іздеу алгоритмдері.

Жарайды, бірақ бұл жерде ұйымдастырушылық және қолданбалы сұрақ туындайды: қандай алгоритмді пайдалану керек.

  1. Бұл мағынада - қолмен азырақ кодтау үшін.
  2. Және оның жұмыс істеуі үшін, яғни. экстремумды тапты (егер бар болса), кем дегенде координаталық түсуден жылдамырақ.

Бірінші тармақ мұндай алгоритмдер қазірдің өзінде іске асырылған және қандай да бір түрде кодта пайдалануға дайын кейбір орталарды іздеу керек екенін көрсетеді.
Мен білемін python и cran-r

Екінші тармақ алгоритмдердің өздері туралы, олар қандай, олардың талаптары қандай және олардың жұмыс ерекшеліктері туралы оқу керек екенін білдіреді.

Және олардың беретіні пайдалы жанама әсерлер болуы мүмкін - нәтижелер немесе тікелей алгоритмнің өзінен.

Немесе оларды алгоритм нәтижелерінен алуға болады.

Көп нәрсе енгізу шарттарына байланысты.

Мысалы, қандай да бір себептермен нәтижені тезірек алу қажет болса, градиентті түсіру алгоритмдерін қарап, олардың біреуін таңдау керек.

Немесе уақыт соншалықты маңызды болмаса, мысалы, генетикалық алгоритм сияқты стохастикалық оңтайландыру әдістерін қолдануға болады.

Мен генетикалық алгоритмді қолдана отырып, жүйе конфигурациясын таңдай отырып, келесі әдіспен жұмысты қарастыруды ұсынамын: зертханалық жұмыс.

Түпнұсқа:

  1. Қызмет көрсету жүйесі ретінде бар болсын: oracle xe 18c
  2. Ол транзакциялық әрекетке қызмет етсін және мақсат: транзакциялар/сек бойынша ішкі дерекқордың мүмкін болатын ең жоғары өткізу қабілетін алу.
  3. Мәліметтермен жұмыс істеу сипаты мен жұмыс контекстінде транзакциялар өте әртүрлі болуы мүмкін.
    Келісейік, бұл кестелік деректердің үлкен көлемін өңдемейтін транзакциялар.
    Қайталаудан гөрі кері қайтару деректерін жасамайды және жолдар мен үлкен кестелердің үлкен пайызын өңдемейді деген мағынада.

Бұл азды-көпті үлкен кестедегі бір жолды өзгертетін транзакциялар, осы кестеде индекстер саны аз.

Бұл жағдайда: транзакцияларды өңдеуге арналған ішкі дерекқордың өнімділігі резервті сақтай отырып, тотықсыздану дерекқорының өңдеу сапасымен анықталады.

Жауапкершіліктен бас тарту - егер біз subdb параметрлері туралы арнайы айтатын болсақ.

Өйткені, жалпы жағдайда, мысалы, кестелік деректермен және/немесе кестелік модельмен пайдаланушы жұмысының дизайнына байланысты SQL сеанстары арасында транзакциялық құлыптар болуы мүмкін.

Бұл, әрине, TPS метрикасына депрессиялық әсер етеді және бұл ішкі дерекқорға қатысты экзогендік фактор болады: кестелік модель осылай құрастырылған және ондағы деректермен жұмыс бітеліп қалады.

Сондықтан, эксперименттің тазалығы үшін біз бұл факторды алып тастаймыз, ал төменде мен дәл қалай түсіндіремін.

  1. Дерекқорға жіберілген SQL пәрмендерінің 100%-ы DML пәрмендері деп нақтылық үшін қарастырайық.
    Тесттерде пайдаланушының ішкі деректер қорымен жұмысының сипаттамалары бірдей болсын.
    Атап айтқанда: skl сеанстарының саны, кестелік деректер, skl сеанстары олармен қалай жұмыс істейтіні.
  2. Subd жұмыс істейді FORCE LOGGING, ARCHIVELOG мод. Flashback-деректер базасы режимі қосалқы деңгейде өшірілген.
  3. Журналдарды қайталау: бөлек файлдық жүйеде, бөлек «дискіде» орналасқан;
    Дерекқордың физикалық құрамдас бөлігінің қалған бөлігі: басқа, бөлек файлдық жүйеде, бөлек «дискіде»:

Физикалық құрылғы туралы толығырақ. зертханалық мәліметтер базасының құрамдас бөліктері

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

Бастапқыда, осы жүктеме жағдайында мен транзакция subd пайдаланғым келді SLOB утилитасы
Оның керемет қасиеті бар, мен автордың сөзін келтірейін:

SLOB негізінде «SLOB әдісі» жатыр. SLOB әдісі платформаларды сынауға бағытталған
қолданбалы даусыз. Аппараттық құралдың максималды өнімділігін басқару мүмкін емес
қолданбалы кодты пайдалану, мысалы, қолданбаны құлыптау арқылы немесе тіпті
Oracle Database блоктарын ортақ пайдалану. Бұл дұрыс — деректерді ортақ пайдалану кезінде қосымша шығындар болады
деректер блоктарында! Бірақ SLOB — әдепкі қолдануда — мұндай дауларға қарсы иммунитет.

Бұл декларация: сәйкес келеді, ол.
Кл сеанстарының параллельділік дәрежесін реттеу ыңғайлы, бұл кілт -t қызметтік бағдарламаны іске қосыңыз runit.sh SLOB сайтынан
DML пәрмендерінің пайызы ішкі бөлімге жіберілетін мәтіндік хабарламалар санында, әрбір мәтіндік сессияда, параметрде реттеледі. UPDATE_PCT
Бөлек және өте ыңғайлы: SLOB өзі, жүктеу сеансына дейін және одан кейін - статистикалық пакетті немесе awr-суреттерді (дайындалатын нәрсе) дайындайды.

Алайда, бұл болып шықты SLOB ұзақтығы 30 секундтан аз SQL сеанстарына қолдау көрсетпейді.
Сондықтан жүк тиегішті алдымен өзімнің жұмысшы-шаруа нұсқасын кодтап алдым, содан кейін ол жұмыста қалды.

Түсінікті болу үшін жүктегіш не істейтінін және оны қалай жасайтынын түсіндіруге рұқсат етіңіз.
Негізінде жүктегіш келесідей көрінеді:

Жұмысшы коды

function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"

$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off

define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum

declare
 v_upto number;
 v_key  number;
 v_tots number;
 v_cts  number;
begin
 select max(col1) into v_upto from system.testtab_&&wnum;
 SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 v_tots := &&period + v_cts;
 while v_cts <= v_tots
 loop
  v_key:=abs(mod(dbms_random.random,v_upto));
  if v_key=0 then
   v_key:=1;
  end if;
  update system.testtab_&&wnum t
  set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
  where t.col1=v_key
  ;
  commit;
  SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 end loop;
end;
/

exit
__EOF__
}
export -f dotx

Жұмысшылар келесі жолмен іске қосылады:

Жұмыс істейтін жұмысшылар

echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
 echo "sql-session: ${i}" >> "$v_logfile"
 dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
wait

Ал жұмысшыларға арналған кестелер келесідей дайындалады:

Кестелерді жасау

function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off

define wnum="$1"
define ts_name="slob"

begin
 execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/

create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable

seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"

Анау. Әрбір жұмысшы үшін (тәжірибеде: МБ-да жеке SQL сеансы) жұмысшы жұмыс істейтін жеке кесте жасалады.

Бұл жұмысшы сеанстары арасында транзакциялық құлыптардың болмауын қамтамасыз етеді.
Әр жұмысшы: бірдей істейді, өз үстелімен, үстелдер бәрі бірдей.
Барлық жұмысшылар жұмысты бірдей уақытта орындайды.
Сонымен қатар, жеткілікті ұзақ уақыт бойы, мысалы, журнал қосқышы міндетті түрде пайда болады және бірнеше рет.
Сәйкесінше, ілеспе шығындар мен әсерлер пайда болды.
Менің жағдайда жұмысшылардың жұмысының ұзақтығын 8 минутқа теңшедім.

Жүктеме астында қосалқы бөлімнің жұмысын сипаттайтын статистикалық пакет есебінің бөлігі

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

Зертханалық жұмыс дегенге қайта келу.
Біз, басқалары тең болған жағдайда, зертханалық ішкі деректер қорының келесі параметрлерінің мәндерін өзгертеміз:

  1. Дерекқор журналының топтарының өлшемі. мән диапазоны: [32, 1024] МБ;
  2. Дерекқордағы журнал топтарының саны. мән диапазоны: [2,32];
  3. log_archive_max_processes мән диапазоны: [1,8];
  4. commit_logging екі мәнге рұқсат етіледі: batch|immediate;
  5. commit_wait екі мәнге рұқсат етіледі: wait|nowait;
  6. log_buffer мән диапазоны: [2,128] МБ.
  7. log_checkpoint_timeout мән диапазоны: [60,1200] секунд
  8. db_writer_processes мән диапазоны: [1,4]
  9. undo_retention мән диапазоны: [30;300] секунд
  10. transactions_per_rollback_segment мән диапазоны: [1,8]
  11. disk_asynch_io екі мәнге рұқсат етіледі: true|false;
  12. filesystemio_options келесі мәндерге рұқсат етіледі: none|setall|directIO|asynch;
  13. db_block_checking келесі мәндерге рұқсат етіледі: OFF|LOW|MEDIUM|FULL;
  14. db_block_checksum келесі мәндерге рұқсат етіледі: OFF|TYPICAL|FULL;

Oracle дерекқорларын жүргізуде тәжірибесі бар адам, көрсетілген деректермен жұмыс істеу үшін дерекқордың жоғары өнімділігін алу үшін көрсетілген параметрлерден және олардың қолайлы мәндерінен нені және қандай мәндерді орнату керектігін айта алады. қолданба коды, жоғарыда.

Бірақ.

Зертханалық жұмыстың мәні - оңтайландыру алгоритмінің өзі мұны бізге салыстырмалы түрде тез түсіндіретінін көрсету.

Біз үшін қандай параметрлерді және қандай диапазонда өзгерту керектігін білу үшін теңшелетін жүйе арқылы құжатты қарау ғана қалады.
Сондай-ақ: таңдалған оңтайландыру алгоритмінің пайдаланушы жүйесімен жұмыс істеу үшін пайдаланылатын кодты кодтаңыз.

Сонымен, енді код туралы.
туралы жоғарыда айттым cran-r, яғни: теңшелген жүйемен барлық манипуляциялар R сценарийі түрінде реттеледі.

Нақты тапсырма, талдау, метрикалық мән бойынша таңдау, жүйе күйінің векторлары: бұл пакет GA (құжаттама)
Пакет, бұл жағдайда, ол векторлардың (хромосомалар, егер пакетте болса) бөлшек бөлігі бар сандар тізбегі түрінде көрсетілуін күтетін мағынада өте қолайлы емес.

Және менің векторым, орнату параметрлерінің мәндерінен: бұл 14 шама - бүтін және жол мәндері.

Мәселе, әрине, жол мәндеріне кейбір нақты сандарды тағайындау арқылы оңай құтылуға болады.

Осылайша, соңында R сценарийінің негізгі бөлігі келесідей болады:

GA::ga қоңырау шалыңыз

cat( "", file=v_logfile, sep="n", append=F)

pSize = 10
elitism_value=1
pmutation_coef=0.8
pcrossover_coef=0.1
iterations=50

gam=GA::ga(type="real-valued", fitness=evaluate,
lower=c(32,2, 1,1,1,2,60,1,30,1,0,0, 0,0), upper=c(1024,32, 8,10,10,128,800,4,300,8,10,40, 40,30),
popSize=pSize,
pcrossover = pcrossover_coef,
pmutation = pmutation_coef,
maxiter=iterations,
run=4,
keepBest=T)
cat( "GA-session is done" , file=v_logfile, sep="n", append=T)
gam@solution

Мұнда, көмегімен lower и upper қосалқы бағдарлама атрибуттары ga шын мәнінде, іздеу кеңістігінің ауданы көрсетіледі, оның шегінде фитнес функциясының максималды мәні алынатын осындай векторға (немесе векторларға) іздеу жүргізіледі.

ga ішкі бағдарламасы фитнес функциясын барынша арттыратын іздеуді орындайды.

Сонымен, бұл жағдайда фитнес функциясы векторды ішкі бөліктің белгілі бір параметрлері үшін мәндер жиыны ретінде түсініп, ішкі бөліктен метрика алуы керек екендігі белгілі болды.

Яғни: қанша, берілген subd орнатуы және ішкі бөлімге берілген жүктеме: subd секундына транзакцияларды өңдейді.

Яғни, ашу кезінде фитнес функциясының ішінде келесі көп қадамды орындау керек:

  1. Сандардың кіріс векторын өңдеу - оны ішкі деректер параметрлері үшін мәндерге түрлендіру.
  2. Берілген өлшемдегі қайталау топтарының берілген санын құру әрекеті. Оның үстіне, әрекет сәтсіз болуы мүмкін.
    Тәжірибе тазалығы үшін субд, кейбір мөлшерде және белгілі бір мөлшерде бұрыннан бар журнал топтары - д.б. жойылды.
  3. Алдыңғы нүкте сәтті болса: дерекқорға конфигурация параметрлерінің мәндерін көрсету (қайтадан: сәтсіздік болуы мүмкін)
  4. Алдыңғы қадам сәтті болса: жаңадан көрсетілген параметр мәндері күшіне енуі үшін қосалқы файлды тоқтату, қосалқы файлды бастау. (қайтадан: қате болуы мүмкін)
  5. Алдыңғы қадам сәтті болса: жүктеме сынағын орындаңыз. subd ішінен көрсеткіштерді алыңыз.
  6. Қосымшаны бастапқы күйіне қайтарыңыз, яғни. қосымша журнал топтарын жойыңыз, бастапқы ішкі дерекқор конфигурациясын жұмысқа қайтарыңыз.

Фитнес функциясының коды

evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
 opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")

opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
 opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")

opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
 opn$disk_asynch_io="false"
} 

opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
 opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
 opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
 opn$filesystemio_options="asynch"
}

opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
 opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
 opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
 opn$db_block_checking="FULL"
}

opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
 opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
 opn$db_block_checksum="FULL"
}

v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)

rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
 cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
 return (0)
}

v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) {  v_rc=1 }

if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("immediate")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("abort")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=run_test()
v_metric=getmetric()

rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)

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

Бұл. барлық жұмыс: дене шынықтыру қызметінде орындалады.

Га-суброутин векторларды, дәлірек айтқанда хромосомаларды өңдейді.
Мұнда біз үшін ең маңыздысы фитнес функциясы үлкен мән беретін гендері бар хромосомаларды таңдау болып табылады.

Бұл, мәні бойынша, N-өлшемді іздеу кеңістігіндегі вектордың көмегімен хромосомалардың оңтайлы жиынтығын іздеу процесі.

Өте анық, егжей-тегжейлі түсініктеме, R-код мысалдарымен, генетикалық алгоритм жұмысы.

Мен екі техникалық тармақты бөлек атап өткім келеді.

Функциядан көмекші шақырулар evaluate, мысалы, тоқтату-бастау, subd параметрінің мәнін орнату негізінде орындалады cran-r функциялары system2

Оның көмегімен: кейбір bash сценарийі немесе пәрмені шақырылады.

Мысалы:

set_db_параметрі

set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")

x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
 cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (attributes(x)$status)
}
else {
 cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (0)
}
}

Екінші нүкте - сызық, evaluate арнайы метрикалық мәнді және оның сәйкес реттеу векторын журнал файлына сақтай отырып, функциялар:

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

Бұл маңызды, өйткені осы деректер массивінен баптау векторының құрамдастарының қайсысы метрикалық мәнге үлкен немесе аз әсер ететіні туралы қосымша ақпаратты алуға болады.

Яғни: атрибуттық-маңыздылық талдауын жүргізу мүмкін болады.

Сонымен не болуы мүмкін?

График пішімінде, егер сынақтарды өсу бойынша метрикалық ретпен тапсырыс берсеңіз, сурет келесідей болады:

Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау

Метриканың экстремалды мәндеріне сәйкес кейбір деректер:
Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау
Мұнда, нәтижелері бар скриншотта мен нақтылаймын: баптау векторының мәндері тұжырымдалған параметрлердің сандық тізімі/параметр мәндерінің диапазоны тұрғысынан емес, фитнес-функция коды бойынша берілген. мәтінде жоғарыда.

Жақсы. Бұл көп пе, әлде аз ба, ~8 мың ш/к: бөлек сұрақ.
Зертханалық жұмыс шеңберінде бұл көрсеткіш маңызды емес, маңыздысы динамика, бұл шаманың қалай өзгеретіні.

Мұндағы динамика жақсы.
Ең болмағанда бір фактордың хромосома векторлары арқылы сұрыпталатын метриканың, га-алгоритмінің мәніне айтарлықтай әсер ететіні анық: қамтылған.
Қисық мәндерінің жеткілікті қарқынды динамикасына қарағанда, айтарлықтай аз болғанымен, әсер ететін кем дегенде тағы бір фактор бар.

Бұл сізге қажет жер attribute-importance қандай атрибуттарды (жақсы, бұл жағдайда реттеу векторының құрамдастары) және олардың метрикалық мәнге қаншалықты әсер ететінін түсіну үшін талдау.
Және осы ақпараттан: маңызды атрибуттардың өзгеруіне қандай факторлар әсер еткенін түсініңіз.

жүгіру attribute-importance әртүрлі жолдармен мүмкін.

Осы мақсаттар үшін маған алгоритм ұнайды randomForest Аттас R бумасы (құжаттама)
randomForest, жалпы оның жұмысын және атап айтқанда атрибуттардың маңыздылығын бағалауға деген көзқарасын түсінгенімдей, жауап айнымалысының атрибуттарға тәуелділігінің белгілі бір моделін құрады.

Біздің жағдайда жауап айнымалысы жүктеме сынақтарында дерекқордан алынған көрсеткіш болып табылады: tps;
Ал атрибуттар баптау векторының құрамдас бөліктері болып табылады.

Солай randomForest Әрбір үлгі атрибутының маңыздылығын екі санмен бағалайды: %IncMSE — үлгіде осы атрибуттың болуы/болмауы осы үлгінің MSE сапасын қалай өзгертеді (Орташа квадраттық қате);

Және IncNodePurity - бұл атрибуттың мәндеріне сүйене отырып, бақылаулары бар деректер жиынын қаншалықты жақсы бөлуге болатындығын көрсететін сан, осылайша бір бөлігінде метриканың бір мәні түсіндірілетін деректер, ал екіншісінде метриканың басқа мәні.
Яғни, бұл қандай дәрежеде жіктеу атрибуты (мен RandomForest сайтында ең анық, орыс тіліндегі түсініктемені көрдім. осында).

Жүктеме сынақтарының нәтижелері бар деректер жиынтығын өңдеуге арналған жұмысшы-шаруа R-коды:

x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')

idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]

library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importance

Сіз өзіңіздің қолыңызбен алгоритмнің гиперпараметрлерін тікелей таңдай аласыз және үлгі сапасына назар аудара отырып, тексеру деректер жинағындағы болжамдарды дәлірек орындайтын модельді таңдай аласыз.
Сіз бұл жұмыс үшін қандай да бір функцияны жаза аласыз (айтпақшы, оңтайландыру алгоритмінің қандай да бір түрін қолдана отырып).

R бумасын пайдалануға болады caret, мәні маңызды емес.

Нәтижесінде, бұл жағдайда атрибуттардың маңыздылық дәрежесін бағалау үшін келесі нәтиже алынады:

Ғылыми соққы әдісі немесе эталондар мен оңтайландыру алгоритмі арқылы дерекқор конфигурациясын таңдау

Жақсы. Осылайша, біз жаһандық рефлексияны бастай аламыз:

  1. Бұл тестілеу жағдайында ең маңыздысы параметр болды commit_wait
    Техникалық тұрғыдан ол subdb журнал буферінен ағымдағы журналдар тобына қайталау деректерін жазу io операциясының орындалу режимін анықтайды: синхронды немесе асинхронды.
    құн nowait бұл tps метрикасының мәнінің дерлік тік, бірнеше есе жоғарылауына әкеледі: бұл қайталау топтарына асинхронды io режимін қосу.
    Бөлек сұрақ - мұны азық-түлік базасында жасау керек пе, жоқ па. Бұл жерде мен жай ғана айтумен шектелемін: бұл маңызды фактор.
  2. Subd: журналының буферінің өлшемі маңызды фактор болып шығуы қисынды.
    Журнал буферінің өлшемі неғұрлым аз болса, оның буферлеу мүмкіндігі соғұрлым аз болады, соғұрлым ол толып кетеді және/немесе жаңа тотығу-тотықсыздану деректерінің бір бөлігі үшін ондағы бос аумақты бөлу мүмкін емес.
    Бұл мынаны білдіреді: журнал буферінде кеңістікті бөлумен және/немесе одан қайта жасау топтарына қайта жасау деректерін шығарумен байланысты кешігулер.
    Бұл кешігулер, әрине, транзакциялар үшін дерекқордың өткізу қабілетіне әсер етуі керек және әсер етеді.
  3. Параметр db_block_checksum: жақсы, сондай-ақ, жалпы алғанда түсінікті - транзакцияны өңдеу ішкі дерекқордың буферлік кэшінде дарти блоктардың пайда болуына әкеледі.
    Деректер блоктарының бақылау сомасын тексеру қосылған кезде, дерекқор өңдеуі керек - деректер блогының негізгі бөлігінен осы бақылау сомасын есептеңіз, оларды деректер блогының тақырыбында жазылғанмен тексеріңіз: сәйкес келеді/сәйкес келмейді.
    Мұндай жұмыс, тағы да, деректерді өңдеуді кешіктіруге болмайды, сәйкесінше, бұл параметрді орнататын параметр мен механизм маңызды болып шығады.
    Сондықтан жеткізуші құжаттамада осы параметрге (параметрге) әртүрлі мәндерді ұсынады және иә, әсер болатынын ескертеді, бірақ «өшірулі» және «өшірулі» күйге дейін әртүрлі мәндерді таңдауға болады. әртүрлі әсерлер.

Жаһандық қорытынды.

Тәсіл, жалпы алғанда, өте тиімді болып шықты.

Ол белгілі бір қызмет көрсету жүйесін жүктемені сынаудың бастапқы кезеңдерінде оның (жүйенің) жүктеме үшін оңтайлы конфигурациясын таңдау үшін, жүктеме үшін жүйені орнату ерекшеліктеріне тым көп үңілмеуге мүмкіндік береді.

Бірақ бұл оны толығымен жоққа шығармайды - кем дегенде түсіну деңгейінде: жүйе «реттеу тұтқалары» және осы тұтқалардың рұқсат етілген айналу диапазондары туралы білуі керек.

Содан кейін тәсіл оңтайлы жүйе конфигурациясын салыстырмалы түрде тез таба алады.
Ал тестілеу нәтижелері бойынша жүйе өнімділігі көрсеткіштері мен жүйе параметрлері параметрлерінің мәндері арасындағы байланыстың сипаты туралы ақпаратты алуға болады.

Бұл, әрине, жүйе туралы өте терең түсініктің пайда болуына, оның жұмыс істеуіне, кем дегенде, берілген жүктемеде ықпал етуі керек.

Іс жүзінде бұл жүйені осындай тестілеуді дайындау шығындарына теңшелген жүйені түсіну шығындарының алмасуы.

Мен бөлек атап өткім келеді: бұл тәсілде жүйелік тестілеудің коммерциялық пайдалануда болатын жұмыс жағдайларына сәйкестік дәрежесі өте маңызды.

Назарларыңызға және уақытыңызға рахмет.

Ақпарат көзі: www.habr.com

пікір қалдыру