🥇სამეცნიერო პოკერის მეთოდი, ან როგორ ავირჩიოთ ქვემონაცემთა ბაზის კონფიგურაცია საორიენტაციო ნიშნებისა და ოპტიმიზაციის ალგორითმის გამოყენებით

გამარჯობა

გადავწყვიტე გამეზიარებინა ჩემი აღმოჩენა - ფიქრის, ცდისა და შეცდომის ნაყოფი.
ზოგადად: ეს არ არის აღმოჩენა, რა თქმა უნდა - ეს ყველაფერი დიდი ხნის განმავლობაში უნდა ყოფილიყო ცნობილი მათთვის, ვინც ჩართულია სტატისტიკური მონაცემების გამოყენებით დამუშავებასა და ნებისმიერი სისტემის ოპტიმიზაციაში, და არა კონკრეტულად DBMS.
და: დიახ, მათ იციან, ისინი წერენ საინტერესო სტატიებს თავიანთ კვლევებზე, მაგალითად (UPD.: კომენტარებში მათ აღნიშნეს ძალიან საინტერესო პროექტი: სხვათაშორისი )
მეორე მხრივ, მე ვერ ვხედავ ამ მიდგომის ფართოდ ხსენებას ან გავრცელებას ინტერნეტში IT სპეციალისტებს შორის, DBA.

ასე რომ, წერტილი.

დავუშვათ, რომ ჩვენ გვაქვს დავალება: დავაყენოთ გარკვეული სერვისის სისტემა რაიმე სახის სამუშაოს შესასრულებლად.

ცნობილია ამ ნაწარმოების შესახებ: რა არის ის, როგორ იზომება ამ სამუშაოს ხარისხი და რა კრიტერიუმით ხდება ამ ხარისხის გაზომვა.

მოდით ასევე ვივარაუდოთ, რომ მეტ-ნაკლებად ცნობილია და გასაგები: ზუსტად როგორ ხდება სამუშაოები (ან) ამ სერვისის სისტემაში.

"მეტ-ნაკლებად" - ეს ნიშნავს, რომ შესაძლებელია მოამზადოთ (ან მიიღოთ იგი სადმე) გარკვეული ხელსაწყოს, უტილიტას, სერვისის, რომლის სინთეზირება და სისტემაში გამოყენება შესაძლებელია საკმარისად ადეკვატური სატესტო დატვირთვით, რაც იქნება წარმოებაში. წარმოებაში მუშაობისთვის საკმარისად ადეკვატურ პირობებში.

კარგი, დავუშვათ, რომ ცნობილია ამ სერვისის სისტემის კორექტირების პარამეტრების ნაკრები, რომელიც შეიძლება გამოყენებულ იქნას ამ სისტემის კონფიგურაციისთვის მისი მუშაობის პროდუქტიულობის თვალსაზრისით.

და რა არის პრობლემა - არ არის საკმარისად სრულყოფილი გაგება ამ სერვისის სისტემის შესახებ, რომელიც საშუალებას გაძლევთ პროფესიონალურად დააკონფიგურიროთ ამ სისტემის პარამეტრები მოცემულ პლატფორმაზე მომავალი დატვირთვისთვის და მიიღოთ სისტემის საჭირო პროდუქტიულობა.

კარგად. ეს თითქმის ყოველთვის ასეა.

რისი გაკეთება შეგიძლია აქ?

პირველი, რაც მახსენდება, არის ამ სისტემის დოკუმენტაციის გადახედვა. გაიგეთ რა არის მისაღები დიაპაზონი კორექტირების პარამეტრების მნიშვნელობებისთვის. და, მაგალითად, კოორდინატთა წარმოშობის მეთოდის გამოყენებით, ტესტებში აირჩიეთ სისტემის პარამეტრების მნიშვნელობები.

იმათ. მიეცით სისტემას რაიმე სახის კონფიგურაცია, მისი კონფიგურაციის პარამეტრების მნიშვნელობების კონკრეტული ნაკრების სახით.

გამოიყენეთ მასზე სატესტო დატვირთვა, ამ ინსტრუმენტ-უტილიტის, დატვირთვის გენერატორის გამოყენებით.
და შეხედეთ მნიშვნელობას - პასუხს, ან სისტემის ხარისხის მეტრიკას.

მეორე აზრი შეიძლება იყოს დასკვნა, რომ ეს ძალიან დიდი დროა.

კარგად, ეს არის: თუ არსებობს მრავალი პარამეტრის პარამეტრი, თუ მათი მნიშვნელობების დიაპაზონი დიდია, თუ თითოეული ინდივიდუალური დატვირთვის ტესტის შესრულებას დიდი დრო სჭირდება, მაშინ: დიახ, ამ ყველაფერს შეიძლება მიუღებელი დასჭირდეს. დიდი დრო.

აბა, აი, რა შეგიძლიათ გაიგოთ და გახსოვდეთ.

შეგიძლიათ გაიგოთ, რომ სერვისის სისტემის პარამეტრების პარამეტრების მნიშვნელობების სიმრავლეში არის ვექტორი, როგორც ზოგიერთი მნიშვნელობის თანმიმდევრობა.

ყოველი ასეთი ვექტორი, სხვა თანაბარი მდგომარეობით (იმით, რომ მასზე ეს ვექტორი გავლენას არ ახდენს), შეესაბამება მეტრიკის სრულიად განსაზღვრულ მნიშვნელობას - ტესტის დატვირთვის ქვეშ სისტემის მუშაობის ხარისხის მაჩვენებელი.

ანუ

მოდით აღვნიშნოთ სისტემის კონფიგურაციის ვექტორი როგორც სად ; სად — სისტემის კონფიგურაციის პარამეტრების რაოდენობა, რამდენია ეს პარამეტრი.

და ამის შესაბამისი მეტრიკის მნიშვნელობა აღვნიშნოთ როგორც
, მაშინ ვიღებთ ფუნქციას:

კარგად, მაშინ: ყველაფერი მაშინვე მოდის, ჩემს შემთხვევაში: თითქმის დავიწყებული სტუდენტობის დროიდან, ფუნქციის ექსტრემის ძიების ალგორითმები.

კარგი, მაგრამ აქ ჩნდება ორგანიზაციული და გამოყენებითი კითხვა: რომელი ალგორითმი გამოვიყენოთ.

გაგებით - ისე, რომ ხელით ნაკლები კოდირება შეძლოთ.
და რომ იმუშაოს, ე.ი. იპოვა ექსტრემუმი (თუ არსებობს), კარგად, კოორდინატზე უფრო სწრაფად მაინც.

პირველი პუნქტი მიუთითებს იმაზე, რომ ჩვენ უნდა შევხედოთ ზოგიერთ გარემოს, რომლებშიც ასეთი ალგორითმები უკვე დანერგილია და, გარკვეული ფორმით, მზად არიან გამოსაყენებლად კოდში.
ისე, მე ვიცი python и cran-r

მეორე პუნქტი ნიშნავს, რომ თქვენ უნდა წაიკითხოთ თავად ალგორითმების შესახებ, რა არის ისინი, რა მოთხოვნები აქვთ და მათი მუშაობის მახასიათებლები.

და რასაც ისინი აძლევენ, შეიძლება იყოს სასარგებლო გვერდითი მოვლენები - შედეგები, ან უშუალოდ თავად ალგორითმიდან.

ან მათი მიღება შესაძლებელია ალგორითმის შედეგებიდან.

ბევრი რამ არის დამოკიდებული შეყვანის პირობებზე.

მაგალითად, თუ რაიმე მიზეზით თქვენ გჭირდებათ შედეგის უფრო სწრაფად მიღება, კარგად, თქვენ უნდა მიხედოთ გრადიენტული დაღმართის ალგორითმებს და აირჩიოთ ერთი მათგანი.

ან, თუ დრო არც ისე მნიშვნელოვანია, შეგიძლიათ, მაგალითად, გამოიყენოთ სტოქასტური ოპტიმიზაციის მეთოდები, როგორიცაა გენეტიკური ალგორითმი.

მე ვთავაზობ ამ მიდგომის მუშაობის განხილვას, სისტემის კონფიგურაციის არჩევით, გენეტიკური ალგორითმის გამოყენებით, შემდეგ, ასე ვთქვათ: ლაბორატორიულ სამუშაოში.

Ორიგინალური:

იყოს, როგორც მომსახურების სისტემა: oracle xe 18c
დაე, ის ემსახურებოდეს ტრანზაქციულ აქტივობას და მიზანს: ქვემონაცემთა ბაზის მაქსიმალური გამტარუნარიანობის მიღება ტრანზაქციებში/წმ.
ტრანზაქციები შეიძლება ძალიან განსხვავებული იყოს მონაცემებთან მუშაობის ბუნებით და მუშაობის კონტექსტით.
შევთანხმდეთ, რომ ეს არის ტრანზაქციები, რომლებიც არ ამუშავებენ დიდი რაოდენობით ცხრილის მონაცემებს.
იმ გაგებით, რომ ისინი არ ქმნიან გაუქმების უფრო მეტ მონაცემს, ვიდრე გადაკეთებას და არ ამუშავებენ მწკრივების და დიდი ცხრილების დიდ პროცენტებს.

ეს არის ტრანზაქციები, რომლებიც ცვლის ერთ რიგს მეტ-ნაკლებად დიდ ცხრილში, ამ ცხრილში ინდექსების მცირე რაოდენობით.

ამ სიტუაციაში: ტრანზაქციების დამუშავების ქვე-ბაზის პროდუქტიულობა, დათქმით, განისაზღვრება რედოქსის მონაცემთა ბაზის მიერ დამუშავების ხარისხით.

პასუხისმგებლობის შეზღუდვა - თუ კონკრეტულად ვსაუბრობთ subdb პარამეტრებზე.

იმის გამო, რომ, ზოგად შემთხვევაში, შეიძლება იყოს, მაგალითად, ტრანზაქციის ჩაკეტვა SQL სესიებს შორის, მომხმარებლის მუშაობის დიზაინის გამო, ტაბულურ მონაცემებთან და/ან ტაბულურ მოდელთან.

რაც, რა თქმა უნდა, დამთრგუნველ გავლენას მოახდენს TPS მეტრიკაზე და ეს იქნება ეგზოგენური ფაქტორი, ქვემონაცემთა ბაზასთან მიმართებაში: კარგად, ასე შეიქმნა ტაბულური მოდელი და მასში არსებული მონაცემებით მუშაობა, რომ მოხდეს ბლოკირება.

ამიტომ, ექსპერიმენტის სიწმინდისთვის, ჩვენ გამოვრიცხავთ ამ ფაქტორს და ქვემოთ განვმარტავ ზუსტად როგორ.

დავუშვათ, დაზუსტებისთვის, რომ მონაცემთა ბაზაში გაგზავნილი SQL ბრძანებების 100% არის DML ბრძანებები.
დაე, მომხმარებლის ქვემონაცემებთან მუშაობის მახასიათებლები ტესტებში იგივე იყოს.
კერძოდ: skl სესიების რაოდენობა, ტაბულური მონაცემები, როგორ მუშაობს skl სესიები მათთან.
Subd მუშაობს FORCE LOGGING, ARCHIVELOG მოდიფიკაციები. Flashback-მონაცემთა ბაზის რეჟიმი გამორთულია, subd დონეზე.
ჩანაწერების გამეორება: განლაგებულია ცალკე ფაილურ სისტემაში, ცალკე „დისკზე“;
ბაზის დანარჩენი ფიზიკური კომპონენტი: სხვა, ცალკე ფაილურ სისტემაში, ცალკე „დისკზე“:

მეტი ინფორმაცია ფიზიკური მოწყობილობის შესახებ. ლაბორატორიული მონაცემთა ბაზის კომპონენტები

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 მონაცემთა ბაზის ბლოკების გაზიარება. ეს ასეა — არის ზედმეტი ხარჯები მონაცემთა გაზიარებისას
მონაცემთა ბლოკებში! მაგრამ SLOB - მისი ნაგულისხმევი განლაგებით - იმუნურია ასეთი კამათის მიმართ.

ეს განცხადება: შეესაბამება, ეს არის.
მოსახერხებელია cl სესიების პარალელურობის ხარისხის რეგულირება, ეს არის გასაღები -t გაუშვით კომუნალური პროგრამა runit.sh SLOB-დან
DML ბრძანებების პროცენტი რეგულირდება, ტექსტური შეტყობინებების რაოდენობაში, რომლებიც იგზავნება subd-ზე, თითოეულ ტექსტურ სესიაზე, პარამეტრზე. UPDATE_PCT
ცალკე და ძალიან მოხერხებულად: SLOB თავად, დატვირთვის სესიის დაწყებამდე და შემდეგ - ამზადებს statspack-ს, ან awr-snapshot-ებს (რაც არის დაყენებული მოსამზადებლად).

თუმცა აღმოჩნდა, რომ SLOB არ აქვს SQL სესიების მხარდაჭერა 30 წამზე ნაკლები ხანგრძლივობით.
ამიტომ, ჯერ ჩამტვირთველის საკუთარი, მუშა-გლეხური ვერსია დავაკოდირე, შემდეგ კი ფუნქციონირებაში დარჩა.

ნება მომეცით განვმარტო რას აკეთებს ჩამტვირთავი და როგორ აკეთებს ამას, სიცხადისთვის.
არსებითად, ჩამტვირთავი ასე გამოიყურება:

მუშა კოდი

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 სესია DB-ში) იქმნება ცალკე ცხრილი, რომლითაც მუშაობს მუშაკი.

ეს უზრუნველყოფს ოპერაციული ჩაკეტვის არარსებობას მუშაკთა სესიებს შორის.
თითოეული მუშა: აკეთებს იგივეს, თავისი მაგიდით, მაგიდები ყველა ერთნაირია.
ყველა თანამშრომელი ასრულებს სამუშაოს იმავე დროის განმავლობაში.
უფრო მეტიც, საკმარისად დიდი ხნის განმავლობაში ისე, რომ, მაგალითად, ჟურნალის შეცვლა აუცილებლად მოხდეს და არაერთხელ.
შესაბამისად, წარმოიშვა დაკავშირებული ხარჯები და ეფექტები.
ჩემს შემთხვევაში, მე დავაყენე მუშების მუშაობის ხანგრძლივობა 8 წუთში.

statspack ანგარიშის ნაწილი, რომელიც აღწერს subd-ის მუშაობას დატვირთვის ქვეშ

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          2929910313 XE                  1 07-Sep-20 23:12 18.0.0.0.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     billing.izhevsk1 Linux x86 64-bit           2     2       1         15.6

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:       1630 07-Sep-20 23:12:27       55        .7
  End Snap:       1631 07-Sep-20 23:20:29       62        .6
   Elapsed:       8.03 (mins) Av Act Sess:       8.4
   DB time:      67.31 (mins)      DB CPU:      15.01 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:     1,392M              Std Block Size:         8K
     Shared Pool:       288M                  Log Buffer:   103,424K

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                8.4                0.0        0.00        0.20
       DB CPU(s):                1.9                0.0        0.00        0.04
       Redo size:        7,685,765.6              978.4
   Logical reads:           60,447.0                7.7
   Block changes:           47,167.3                6.0
  Physical reads:                8.3                0.0
 Physical writes:              253.4                0.0
      User calls:               42.6                0.0
          Parses:               23.2                0.0
     Hard parses:                1.2                0.0
W/A MB processed:                1.0                0.0
          Logons:                0.5                0.0
        Executes:           15,756.5                2.0
       Rollbacks:                0.0                0.0
    Transactions:            7,855.1

ვუბრუნდებით ლაბორატორიულ სამუშაოს.
ჩვენ, სხვა თანაბარ პირობებში, შევცვლით ლაბორატორიული ქვემონაცემთა ბაზის შემდეგი პარამეტრების მნიშვნელობებს:

მონაცემთა ბაზის ჟურნალის ჯგუფების ზომა. მნიშვნელობის დიაპაზონი: [32, 1024] მბ;
ჟურნალის ჯგუფების რაოდენობა მონაცემთა ბაზაში. მნიშვნელობების დიაპაზონი: [2,32];
log_archive_max_processes მნიშვნელობების დიაპაზონი: [1,8];
commit_logging დასაშვებია ორი მნიშვნელობა: batch|immediate;
commit_wait დასაშვებია ორი მნიშვნელობა: wait|nowait;
log_buffer მნიშვნელობის დიაპაზონი: [2,128] მბ.
log_checkpoint_timeout მნიშვნელობის დიაპაზონი: [60,1200] წამი
db_writer_processes მნიშვნელობის დიაპაზონი: [1,4]
undo_retention მნიშვნელობის დიაპაზონი: [30;300] წამი
transactions_per_rollback_segment მნიშვნელობის დიაპაზონი: [1,8]
disk_asynch_io დასაშვებია ორი მნიშვნელობა: true|false;
filesystemio_options ნებადართულია შემდეგი მნიშვნელობები: none|setall|directIO|asynch;
db_block_checking ნებადართულია შემდეგი მნიშვნელობები: OFF|LOW|MEDIUM|FULL;
db_block_checksum ნებადართულია შემდეგი მნიშვნელობები: OFF|TYPICAL|FULL;

Oracle-ის მონაცემთა ბაზების შენარჩუნების გამოცდილების მქონე პირს, რა თქმა უნდა, უკვე შეუძლია თქვას, რა და რა მნიშვნელობები უნდა იყოს მითითებული მითითებული პარამეტრებიდან და მათი მისაღები მნიშვნელობებიდან, რათა მონაცემთა ბაზის უფრო მეტი პროდუქტიულობა მიიღოს მონაცემებთან მუშაობისთვის, რაც მითითებულია განაცხადის კოდი, აქ ზემოთ.

მაგრამ.

ლაბორატორიული სამუშაოს მიზანია აჩვენოს, რომ ოპტიმიზაციის ალგორითმი თავად გაგვიმარტავს ამას შედარებით სწრაფად.

ჩვენთვის რჩება მხოლოდ დოკუმენტის შესწავლა კონფიგურირებადი სისტემის საშუალებით, მხოლოდ იმის გასარკვევად, თუ რა პარამეტრები უნდა შეიცვალოს და რა დიაპაზონში.
და ასევე: კოდირება კოდი, რომელიც გამოყენებული იქნება არჩეული ოპტიმიზაციის ალგორითმის მორგებულ სისტემასთან მუშაობისთვის.

ასე რომ, ახლა კოდის შესახებ.
ზემოთ ვისაუბრე cran-r, ანუ: ყველა მანიპულაცია მორგებული სისტემით ორკესტრირებულია R სკრიპტის სახით.

ფაქტობრივი ამოცანა, ანალიზი, შერჩევა მეტრიკული მნიშვნელობით, სისტემის მდგომარეობის ვექტორები: ეს არის პაკეტი GA (დოკუმენტაცია)
პაკეტი, ამ შემთხვევაში, არ არის ძალიან შესაფერისი, იმ გაგებით, რომ იგი მოელის ვექტორებს (ქრომოსომებს, თუ პაკეტის თვალსაზრისით) მითითებული იქნება რიცხვების სტრიქონების სახით წილადი ნაწილით.

და ჩემი ვექტორი, პარამეტრის პარამეტრების მნიშვნელობებიდან: ეს არის 14 რაოდენობა - მთელი რიცხვები და სიმებიანი მნიშვნელობები.

პრობლემა, რა თქმა უნდა, ადვილად აიცილება სტრიქონების მნიშვნელობებზე გარკვეული კონკრეტული რიცხვების მინიჭებით.

ამრიგად, საბოლოო ჯამში, R სკრიპტის მთავარი ნაწილი ასე გამოიყურება:

დარეკეთ GA::ga

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

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

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

აი, დახმარებით lower и upper ქვეპროგრამის ატრიბუტები ga არსებითად, მითითებულია საძიებო სივრცის არე, რომლის ფარგლებშიც განხორციელდება ისეთი ვექტორის (ან ვექტორების) ძიება, რომლებისთვისაც მიიღება ფიტნეს ფუნქციის მაქსიმალური მნიშვნელობა.

ga ქვეპროგრამა ახორციელებს ძიებას, რაც მაქსიმალურად უწყობს ხელს ფიტნეს ფუნქციას.

მაშ, გამოდის, რომ ამ შემთხვევაში, აუცილებელია, რომ ფიტნესის ფუნქცია, ვექტორის, როგორც მნიშვნელობების სიმრავლის გაგებით, subd-ის გარკვეული პარამეტრებისთვის, მიიღოს მეტრიკა subd-დან.

ეს არის: რამდენი, მოცემული subd დაყენებით და მოცემული დატვირთვით subd-ზე: subd ამუშავებს ტრანზაქციებს წამში.

ანუ, გაშლისას, შემდეგი მრავალსაფეხური უნდა შესრულდეს ფიტნეს ფუნქციის შიგნით:

რიცხვების შეყვანის ვექტორის დამუშავება - მისი გადაქცევა მნიშვნელობებად ქვემონაცემების პარამეტრებისთვის.
მცდელობა შექმნას მოცემული რაოდენობის ხელახალი ჯგუფები მოცემული ზომის. უფრო მეტიც, მცდელობა შეიძლება წარუმატებელი იყოს.
ჟურნალის ჯგუფები, რომლებიც უკვე არსებობდნენ ქვედ, გარკვეული რაოდენობით და გარკვეული ზომის, ექსპერიმენტის სიწმინდისთვის - დ.ბ. წაშლილია.
თუ წინა პუნქტი წარმატებულია: მონაცემთა ბაზაში კონფიგურაციის პარამეტრების მნიშვნელობების მითითება (ისევ: შეიძლება იყოს მარცხი)
თუ წინა ნაბიჯი წარმატებულია: subd-ის შეჩერება, subd-ის დაწყება ისე, რომ ახლად მითითებული პარამეტრის მნიშვნელობები ამოქმედდეს. (კიდევ ერთხელ: შეიძლება იყოს ხარვეზი)
თუ წინა ნაბიჯი წარმატებულია: ჩაატარეთ დატვირთვის ტესტი. მიიღეთ მეტრიკა subd-დან.
დააბრუნეთ subd თავდაპირველ მდგომარეობაში, ე.ი. წაშალეთ ჟურნალის დამატებითი ჯგუფები, დააბრუნეთ თავდაპირველი ქვემონაცემთა ბაზის კონფიგურაცია.

ფიტნეს ფუნქციის კოდი

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

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

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

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

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

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

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

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

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

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

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

rc=run_test()
v_metric=getmetric()

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

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

რომ. ყველა სამუშაო: შესრულებულია ფიტნეს ფუნქციაში.

გა-სუბრუტინი ამუშავებს ვექტორებს ან, უფრო სწორად, ქრომოსომებს.
რომელშიც ჩვენთვის ყველაზე მნიშვნელოვანია ქრომოსომების შერჩევა გენებით, რომლებისთვისაც ფიტნეს ფუნქცია დიდ მნიშვნელობებს გამოიმუშავებს.

ეს, არსებითად, არის ქრომოსომების ოპტიმალური ნაკრების ძიების პროცესი ვექტორის გამოყენებით N-განზომილებიანი საძიებო სივრცეში.

ძალიან ნათელი, დეტალური ახსნა, R-კოდის მაგალითებით, გენეტიკური ალგორითმის მუშაობა.

ცალკე მინდა აღვნიშნო ორი ტექნიკური პუნქტი.

დამხმარე ზარები ფუნქციიდან evaluate, მაგალითად, stop-start, subd პარამეტრის მნიშვნელობის დაყენება, შესრულებულია საფუძველზე cran-r ფუნქციები system2

რომლის დახმარებით: რაღაც bash სკრიპტს ან ბრძანებას ეძახიან.

მაგალითად:

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

მეორე წერტილი არის ხაზი, evaluate ფუნქციები, კონკრეტული მეტრიკული მნიშვნელობის და მისი შესაბამისი დარეგულირების ვექტორის შენახვით ჟურნალის ფაილში:

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

ეს მნიშვნელოვანია, რადგან ამ მონაცემთა მასივიდან შესაძლებელი იქნება დამატებითი ინფორმაციის მიღება იმის შესახებ, თუ რომელი კომპონენტის კომპონენტს აქვს მეტი ან ნაკლები გავლენა მეტრულ მნიშვნელობაზე.

ანუ: შესაძლებელი იქნება ატრიბუტ-მნიშვნელობის ანალიზის ჩატარება.

მაშ რა შეიძლება მოხდეს?

გრაფიკის სახით, თუ ტესტებს დავალაგებთ მეტრულ ზრდად მიმდევრობით, სურათი ასეთია:

ზოგიერთი მონაცემი, რომელიც შეესაბამება მეტრიკის უკიდურეს მნიშვნელობებს:

აქ, სკრინშოტში, შედეგებთან ერთად, განვმარტავ: ტიუნინგის ვექტორის მნიშვნელობები მოცემულია ფიტნესის ფუნქციის კოდის მიხედვით და არა პარამეტრების მნიშვნელობების რიცხვითი სიის მიხედვით, რომელიც ჩამოყალიბდა. ტექსტში ზემოთ.

კარგად. ბევრია თუ ცოტა, ~8 ათასი ჩ/კ: ცალკე კითხვა.
ლაბორატორიული მუშაობის ფარგლებში ეს მაჩვენებელი არ არის მნიშვნელოვანი, მთავარია დინამიკა, როგორ იცვლება ეს მნიშვნელობა.

დინამიკა აქ კარგია.
აშკარაა, რომ მინიმუმ ერთი ფაქტორი მნიშვნელოვნად მოქმედებს მეტრიკის მნიშვნელობაზე, გა-ალგორითმი, ქრომოსომის ვექტორების მიხედვით დახარისხება: დაფარული.
მრუდის მნიშვნელობების საკმაოდ ენერგიული დინამიკის მიხედვით ვიმსჯელებთ, არის კიდევ ერთი ფაქტორი მაინც, რომელიც, თუმცა მნიშვნელოვნად მცირეა, აქვს გავლენა.

ეს არის სადაც თქვენ გჭირდებათ attribute-importance ანალიზი იმის გასაგებად, თუ რა ატრიბუტები (ამ შემთხვევაში, ტუნინგ ვექტორის კომპონენტები) და რამდენად გავლენას ახდენენ ისინი მეტრულ მნიშვნელობაზე.
და ამ ინფორმაციის მიხედვით: გაიგეთ, რა ფაქტორებზე იმოქმედა მნიშვნელოვანი ატრიბუტების ცვლილებებმა.

Run attribute-importance შესაძლებელია სხვადასხვა გზით.

ამ მიზნებისთვის მე მომწონს ალგორითმი randomForest ამავე სახელწოდების R პაკეტი (დოკუმენტაცია)
randomForestროგორც მე მესმის მისი მუშაობა ზოგადად და მისი მიდგომა კონკრეტულად ატრიბუტების მნიშვნელობის შეფასებისადმი, აყალიბებს პასუხის ცვლადის დამოკიდებულების გარკვეულ მოდელს ატრიბუტებზე.

ჩვენს შემთხვევაში, პასუხის ცვლადი არის მეტრიკა, რომელიც მიღებულია მონაცემთა ბაზიდან დატვირთვის ტესტებში: tps;
და ატრიბუტები არის tuning ვექტორის კომპონენტები.

ასე რომ აქ randomForest აფასებს თითოეული მოდელის ატრიბუტის მნიშვნელობას ორი ნომრით: %IncMSE — როგორ ცვლის მოდელში ამ ატრიბუტის არსებობა/არარსებობა ამ მოდელის MSE ხარისხს (საშუალო კვადრატული შეცდომა);

და IncNodePurity არის რიცხვი, რომელიც ასახავს რამდენად კარგად, ამ ატრიბუტის მნიშვნელობებზე დაყრდნობით, შეიძლება დაიყოს მონაცემთა ნაკრები დაკვირვებებით, ისე რომ ერთ ნაწილში არის მონაცემები ახსნილი მეტრიკის ერთი მნიშვნელობით, ხოლო მეორეში - მეტრიკის კიდევ ერთი მნიშვნელობა.
კარგად, ეს არის: რამდენად არის ეს კლასიფიკაციის ატრიბუტი (მე ვნახე ყველაზე მკაფიო, რუსულენოვანი ახსნა RandomForest-ზე აქ).

მუშა-გლეხის R-კოდი მონაცემთა ნაკრების დასამუშავებლად დატვირთვის ტესტების შედეგებით:

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

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

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

თქვენ შეგიძლიათ პირდაპირ აირჩიოთ ალგორითმის ჰიპერპარამეტრები თქვენი ხელით და, მოდელის ხარისხზე ფოკუსირებით, აირჩიოთ მოდელი, რომელიც უფრო ზუსტად შეასრულებს პროგნოზებს ვალიდაციის მონაცემთა ბაზაზე.
თქვენ შეგიძლიათ დაწეროთ რაიმე სახის ფუნქცია ამ სამუშაოსთვის (სხვათა შორის, კიდევ ერთხელ, გარკვეული სახის ოპტიმიზაციის ალგორითმის გამოყენებით).

შეგიძლიათ გამოიყენოთ R პაკეტი caret, არ არის მთავარი.

შედეგად, ამ შემთხვევაში, შემდეგი შედეგი მიიღება ატრიბუტების მნიშვნელობის შესაფასებლად:

კარგად. ამრიგად, ჩვენ შეგვიძლია დავიწყოთ გლობალური ასახვა:

გამოდის, რომ ყველაზე მნიშვნელოვანი, ამ ტესტირების პირობებში, იყო პარამეტრი commit_wait
ტექნიკურად, იგი განსაზღვრავს io ოპერაციის შესრულების რეჟიმს subdb ჟურნალის ბუფერიდან ჩაწერის ხელახალი მონაცემების მიმდინარე ჟურნალის ჯგუფში: სინქრონული ან ასინქრონული.
ღირებულება nowait რაც იწვევს tps მეტრიკის მნიშვნელობის თითქმის ვერტიკალურ, მრავალჯერადი ზრდას: ეს არის ასინქრონული io რეჟიმის ჩართვა რედო ჯგუფებში.
ცალკე კითხვაა, უნდა გააკეთო თუ არა ეს საკვების მონაცემთა ბაზაში. აქ შემოვიფარგლები მხოლოდ განცხადებით: ეს მნიშვნელოვანი ფაქტორია.
ლოგიკურია, რომ subd-ის ჟურნალის ბუფერის ზომა მნიშვნელოვანი ფაქტორი აღმოჩნდება.
რაც უფრო მცირეა ჟურნალის ბუფერის ზომა, მით ნაკლებია მისი ბუფერული სიმძლავრე, მით უფრო ხშირად აჭარბებს მას და/ან არ არის მასში თავისუფალი ზონის გამოყოფის შესაძლებლობა ახალი რედოქსული მონაცემების ნაწილისთვის.
ეს ნიშნავს: შეფერხებებს, რომლებიც დაკავშირებულია ჟურნალის ბუფერში სივრცის გამოყოფასთან და/ან მისგან ხელახალი მონაცემების ხელახალი ჯგუფებად გადაყრასთან.
ეს შეფერხებები, რა თქმა უნდა, უნდა და ახდენს გავლენას ტრანზაქციების მონაცემთა ბაზის გამტარუნარიანობაზე.
პარამეტრის db_block_checksum: ასევე, ზოგადად, გასაგებია - ტრანზაქციის დამუშავება იწვევს დარტის ბლოკების ფორმირებას ქვემონაცემთა ბაზის ბუფერულ ქეშში.
რაც, როდესაც ჩართულია მონაცემთა ბლოკების შემოწმების ჯამების შემოწმება, მონაცემთა ბაზამ უნდა დაამუშაოს - გამოთვალოს ეს შემოწმებები მონაცემთა ბლოკის კორპუსიდან, შეამოწმოს ისინი იმით, რაც წერია მონაცემთა ბლოკის სათაურში: შეესაბამება/არ ემთხვევა.
ასეთი სამუშაო, ისევ და ისევ, არ შეიძლება არ შეაფერხოს მონაცემთა დამუშავებას და, შესაბამისად, პარამეტრი და მექანიზმი, რომელიც ადგენს ამ პარამეტრს, მნიშვნელოვანი აღმოჩნდება.
ამიტომაც, გამყიდველი ამ პარამეტრის დოკუმენტაციაში სთავაზობს მას (პარამეტრს) სხვადასხვა მნიშვნელობებს და აღნიშნავს, რომ დიახ, იქნება გავლენა, მაგრამ, ასევე, შეგიძლიათ აირჩიოთ სხვადასხვა მნიშვნელობები, "გამორთვამდე" და სხვადასხვა ზემოქმედება.

ისე, გლობალური დასკვნა.

მიდგომა, ზოგადად, საკმაოდ ეფექტური გამოდის.

ის საკმაოდ საშუალებას აძლევს საკუთარ თავს, გარკვეული სერვისის სისტემის დატვირთვის ტესტირების ადრეულ ეტაპებზე, რათა შეარჩიოს მისი (სისტემის) ოპტიმალური კონფიგურაცია დატვირთვისთვის, არ ჩაუღრმავდეს დატვირთვის სისტემის დაყენების სპეციფიკას.

მაგრამ ეს მთლიანად არ გამორიცხავს - ყოველ შემთხვევაში, გაგების დონეზე: სისტემამ უნდა იცოდეს "რეგულირების ღილაკები" და ამ ღილაკების ბრუნვის დასაშვები დიაპაზონები.

შემდეგ მიდგომას შეუძლია შედარებით სწრაფად იპოვოთ სისტემის ოპტიმალური კონფიგურაცია.
და ტესტირების შედეგების საფუძველზე, შესაძლებელია მიიღოთ ინფორმაცია სისტემის მუშაობის მეტრიკასთან ურთიერთობის ბუნების შესახებ და სისტემის პარამეტრების პარამეტრების მნიშვნელობებს შორის.

რაც, რა თქმა უნდა, უნდა შეუწყოს ხელი სისტემის ამ ძალიან ღრმა გაგებას, მის ფუნქციონირებას, ყოველ შემთხვევაში, მოცემული დატვირთვის პირობებში.

პრაქტიკაში, ეს არის მორგებული სისტემის გაგების ხარჯების გაცვლა სისტემის ასეთი ტესტირების მომზადების ხარჯებთან.

ცალკე მინდა აღვნიშნო: ამ მიდგომით კრიტიკულად მნიშვნელოვანია სისტემის ტესტირების ადეკვატურობის ხარისხი იმ სამუშაო პირობებთან, რაც მას ექნება კომერციულ ექსპლუატაციაში.

გმადლობთ ყურადღებისთვის და დროისთვის.

წყარო: www.habr.com

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება