🥇 វិធីសាស្ត្រ poking បែបវិទ្យាសាស្ត្រ ឬរបៀបជ្រើសរើសការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យរងដោយប្រើគោល និងក្បួនដោះស្រាយបង្កើនប្រសិទ្ធភាព

Здравствуйте។

ខ្ញុំបានសម្រេចចិត្តចែករំលែកការស្វែងរករបស់ខ្ញុំ - ផ្លែផ្កានៃការគិត ការសាកល្បង និងកំហុស។
ជាទូទៅ៖ នេះមិនមែនជាការស្វែងរកទេ ពិតណាស់ ទាំងអស់នេះគួរតែត្រូវបានគេស្គាល់ជាយូរមកហើយ សម្រាប់អ្នកដែលចូលរួមក្នុងដំណើរការទិន្នន័យស្ថិតិដែលបានអនុវត្ត និងការបង្កើនប្រសិទ្ធភាពនៃប្រព័ន្ធណាមួយ មិនចាំបាច់ជាពិសេស DBMS នោះទេ។
ហើយ៖ បាទ ពួកគេដឹង ពួកគេសរសេរអត្ថបទគួរឱ្យចាប់អារម្មណ៍លើការស្រាវជ្រាវរបស់ពួកគេ ឧទាហរណ៍ (UPD.: នៅក្នុងសេចក្តីអធិប្បាយ ពួកគេបានចង្អុលបង្ហាញអំពីគម្រោងដ៏គួរឱ្យចាប់អារម្មណ៍មួយ៖ ottertune )
ម៉្យាងវិញទៀត៖ ខ្ញុំមិនបានឃើញការលើកឡើងឬការផ្សព្វផ្សាយយ៉ាងទូលំទូលាយនៃវិធីសាស្រ្តនេះនៅលើអ៊ីនធឺណិតក្នុងចំណោមអ្នកជំនាញផ្នែកព័ត៌មានវិទ្យា DBA ទេ។

ដូច្នេះ, ដល់ចំណុច។

ចូរសន្មតថាយើងមានភារកិច្ចមួយ: រៀបចំប្រព័ន្ធសេវាកម្មជាក់លាក់មួយដើម្បីបម្រើការងារមួយចំនួន។

វាត្រូវបានគេដឹងអំពីការងារនេះ៖ តើវាជាអ្វី របៀបដែលគុណភាពនៃការងារនេះត្រូវបានវាស់វែង និងអ្វីដែលជាលក្ខណៈវិនិច្ឆ័យសម្រាប់វាស់គុណភាពនេះ។

ចូរសន្មតថាវាត្រូវបានគេស្គាល់ និងយល់តិចឬច្រើន៖ ច្បាស់អំពីរបៀបដែលការងារត្រូវបានអនុវត្តនៅក្នុង (ឬជាមួយ) ប្រព័ន្ធសេវាកម្មនេះ។

"តិចឬច្រើន" - នេះមានន័យថាវាអាចធ្វើទៅបានដើម្បីរៀបចំ (ឬទទួលបានវាពីកន្លែងណាមួយ) ឧបករណ៍ជាក់លាក់មួយ ឧបករណ៍ប្រើប្រាស់ សេវាកម្មដែលអាចសំយោគនិងអនុវត្តទៅប្រព័ន្ធជាមួយនឹងបន្ទុកសាកល្បងគ្រប់គ្រាន់សម្រាប់អ្វីដែលនឹងមាននៅក្នុងផលិតកម្ម។ ក្នុងលក្ខខណ្ឌគ្រប់គ្រាន់សម្រាប់ធ្វើការក្នុងផលិតកម្ម។

ជាការប្រសើរណាស់ ចូរសន្មតថាសំណុំនៃប៉ារ៉ាម៉ែត្រកែតម្រូវសម្រាប់ប្រព័ន្ធសេវាកម្មនេះត្រូវបានគេស្គាល់ ដែលអាចត្រូវបានប្រើដើម្បីកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធនេះទាក់ទងនឹងផលិតភាពនៃការងាររបស់វា។

ហើយអ្វីដែលជាបញ្ហា - មិនមានការយល់ដឹងពេញលេញគ្រប់គ្រាន់អំពីប្រព័ន្ធសេវាកម្មនេះ ដែលអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធការកំណត់នៃប្រព័ន្ធនេះយ៉ាងជំនាញសម្រាប់ការផ្ទុកនាពេលអនាគតនៅលើវេទិកាដែលបានផ្តល់ឱ្យ និងទទួលបានផលិតភាពដែលត្រូវការនៃប្រព័ន្ធ។

អញ្ចឹង។ នេះគឺស្ទើរតែគ្រប់ពេលវេលា។

តើអ្នកអាចធ្វើអ្វីនៅទីនេះ?

ជាការប្រសើរណាស់, រឿងដំបូងដែលចូលមកក្នុងគំនិតគឺដើម្បីមើលឯកសារសម្រាប់ប្រព័ន្ធនេះ។ យល់ពីអ្វីដែលជួរដែលអាចទទួលយកបានសម្រាប់តម្លៃនៃប៉ារ៉ាម៉ែត្រកែតម្រូវ។ ហើយជាឧទាហរណ៍ ដោយប្រើវិធីសំរបសំរួលចុះក្រោម ជ្រើសរើសតម្លៃសម្រាប់ប៉ារ៉ាម៉ែត្រប្រព័ន្ធក្នុងការធ្វើតេស្ត។

ទាំងនោះ។ ផ្តល់ឱ្យប្រព័ន្ធនូវប្រភេទនៃការកំណត់រចនាសម្ព័ន្ធមួយចំនួនក្នុងទម្រង់នៃសំណុំតម្លៃជាក់លាក់សម្រាប់ប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធរបស់វា។

អនុវត្តការសាកល្បងលើវាដោយប្រើឧបករណ៍នេះជាឧបករណ៍ប្រើប្រាស់ខ្លាំងណាស់ ផ្ទុកម៉ាស៊ីនភ្លើង។
ហើយមើលតម្លៃ - ការឆ្លើយតបឬម៉ែត្រនៃគុណភាពនៃប្រព័ន្ធ។

គំនិតទីពីរអាចជាការសន្និដ្ឋានថានេះគឺជាពេលវេលាដ៏យូរ។

ជាការប្រសើរណាស់ នោះគឺ៖ ប្រសិនបើមានប៉ារ៉ាម៉ែត្រកំណត់ច្រើន ប្រសិនបើជួរនៃតម្លៃរបស់ពួកគេដែលកំពុងដំណើរការមានទំហំធំ ប្រសិនបើការធ្វើតេស្តផ្ទុកនីមួយៗត្រូវចំណាយពេលច្រើនដើម្បីបញ្ចប់ នោះ៖ បាទ អ្វីៗទាំងអស់នេះអាចទទួលយកបានដែលមិនអាចទទួលយកបាន។ យូរ។

មែនហើយ នេះជាអ្វីដែលអ្នកអាចយល់ និងចងចាំបាន។

អ្នកអាចរកឃើញថានៅក្នុងសំណុំតម្លៃនៃប៉ារ៉ាម៉ែត្រការកំណត់ប្រព័ន្ធសេវាកម្មមានវ៉ិចទ័រដែលជាលំដាប់នៃតម្លៃមួយចំនួន។

វ៉ិចទ័របែបនេះ វត្ថុផ្សេងទៀតស្មើគ្នា (ដែលវាមិនត្រូវបានប៉ះពាល់ដោយវ៉ិចទ័រនេះ) ត្រូវគ្នាទៅនឹងតម្លៃកំណត់ទាំងស្រុងនៃម៉ែត្រ - សូចនាករនៃគុណភាពនៃប្រតិបត្តិការរបស់ប្រព័ន្ធក្រោមបន្ទុកសាកល្បង។

I.e.

អនុញ្ញាតឱ្យយើងសម្គាល់វ៉ិចទ័រកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធជា ដែលជាកន្លែង ; កន្លែងណា - ចំនួនប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធ តើចំនួនប៉ារ៉ាម៉ែត្រទាំងនេះមានប៉ុន្មាន។

និងតម្លៃនៃម៉ែត្រដែលត្រូវគ្នានឹងនេះ។ ចូរយើងសម្គាល់វាជា
បន្ទាប់មកយើងទទួលបានមុខងារមួយ៖

មែនហើយ៖ អ្វីគ្រប់យ៉ាងកើតឡើងភ្លាមៗក្នុងករណីរបស់ខ្ញុំ៖ ស្ទើរតែភ្លេចពីថ្ងៃសិស្សរបស់ខ្ញុំ ក្បួនដោះស្រាយសម្រាប់ស្វែងរកមុខងារខ្លាំងបំផុត។

មិនអីទេ ប៉ុន្តែនៅទីនេះ សំណួររៀបចំ និងអនុវត្តមួយកើតឡើង៖ ក្បួនដោះស្រាយដែលត្រូវប្រើ។

នៅក្នុងន័យ - ដូច្នេះអ្នកអាចសរសេរកូដតិចដោយដៃ។
ហើយសម្រាប់វាដំណើរការ, i.e. បានរកឃើញភាពជ្រុលនិយម (ប្រសិនបើមានមួយ) ជាការប្រសើរណាស់ យ៉ាងហោចណាស់ក៏លឿនជាងសំរបសំរួលតំណពូជ។

ចំណុចដំបូងណែនាំថាយើងត្រូវរកមើលបរិស្ថានមួយចំនួនដែលក្បួនដោះស្រាយបែបនេះត្រូវបានអនុវត្តរួចហើយ ហើយក្នុងទម្រង់ខ្លះត្រៀមសម្រាប់ប្រើក្នុងកូដ។
អញ្ចឹងខ្ញុំដឹង python и cran-r

ចំណុចទីពីរមានន័យថាអ្នកត្រូវអានអំពី algorithms ខ្លួនឯងថាតើពួកគេជាអ្វី តម្រូវការរបស់ពួកគេជាអ្វី លក្ខណៈពិសេសនៃការងាររបស់ពួកគេ។

ហើយអ្វីដែលពួកគេផ្តល់ឱ្យអាចជាផលប៉ះពាល់ដែលមានប្រយោជន៍ - លទ្ធផលឬដោយផ្ទាល់ពីក្បួនដោះស្រាយខ្លួនឯង។

ឬពួកគេអាចទទួលបានពីលទ្ធផលនៃក្បួនដោះស្រាយ។

ភាគច្រើនអាស្រ័យលើលក្ខខណ្ឌនៃការបញ្ចូល។

ឧទាហរណ៍ ប្រសិនបើហេតុផលខ្លះ អ្នកត្រូវទទួលបានលទ្ធផលលឿនជាង នោះអ្នកត្រូវរកមើលក្បួនដោះស្រាយការចុះជម្រាលជម្រាល ហើយជ្រើសរើសមួយក្នុងចំណោមពួកគេ។

ឬប្រសិនបើពេលវេលាមិនសំខាន់ទេ អ្នកអាចឧទាហរណ៍ ប្រើវិធីសាស្ត្របង្កើនប្រសិទ្ធភាព stochastic ដូចជាក្បួនដោះស្រាយហ្សែន។

ខ្ញុំស្នើឱ្យពិចារណាការងារនៃវិធីសាស្រ្តនេះ ជ្រើសរើសការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធ ដោយប្រើក្បួនដោះស្រាយហ្សែន នៅបន្ទាប់ដើម្បីនិយាយ៖ ការងារមន្ទីរពិសោធន៍។

ដើម៖

អនុញ្ញាតឱ្យមានជាប្រព័ន្ធសេវាកម្ម៖ oracle xe 18c
អនុញ្ញាតឱ្យវាបម្រើសកម្មភាពប្រតិបតិ្តការ និងគោលដៅ៖ ដើម្បីទទួលបានទិន្នផលខ្ពស់បំផុតនៃមូលដ្ឋានទិន្នន័យរងក្នុងប្រតិបត្តិការ/វិនាទី។
ប្រតិបត្តិការអាចមានភាពខុសគ្នាខ្លាំងនៅក្នុងលក្ខណៈនៃការធ្វើការជាមួយទិន្នន័យ និងបរិបទនៃការងារ។
ចូរយើងយល់ស្របថាទាំងនេះគឺជាប្រតិបត្តិការដែលមិនដំណើរការទិន្នន័យតារាងចំនួនច្រើន។
ក្នុងន័យថាពួកគេមិនបង្កើតទិន្នន័យមិនធ្វើវិញច្រើនជាងការធ្វើឡើងវិញ ហើយមិនដំណើរការភាគរយធំនៃជួរដេក និងតារាងធំ។

ទាំងនេះគឺជាប្រតិបត្តិការដែលផ្លាស់ប្តូរជួរមួយក្នុងតារាងធំជាង ឬតិចជាង ជាមួយនឹងសន្ទស្សន៍មួយចំនួនតូចនៅលើតារាងនេះ។

ក្នុងស្ថានភាពនេះ៖ ផលិតភាពនៃមូលដ្ឋានទិន្នន័យរងសម្រាប់ដំណើរការប្រតិបត្តិការនឹងត្រូវបានកំណត់ដោយការកក់ទុកដោយគុណភាពនៃដំណើរការដោយមូលដ្ឋានទិន្នន័យ redox ។

ការបដិសេធ - ប្រសិនបើយើងនិយាយជាពិសេសអំពីការកំណត់ subdb ។

ពីព្រោះក្នុងករណីទូទៅ វាអាចមានការចាក់សោរប្រតិបត្តិការរវាងវគ្គ SQL ដោយសារតែការរចនានៃការងាររបស់អ្នកប្រើជាមួយទិន្នន័យតារាង និង/ឬគំរូតារាង។

ជាការពិត ដែលនឹងមានផលប៉ះពាល់យ៉ាងខ្លាំងទៅលើម៉ែត្រ TPS ហើយនេះនឹងក្លាយជាកត្តាខាងក្រៅ ដែលទាក់ទងទៅនឹងមូលដ្ឋានទិន្នន័យរង៖ ជាការប្រសើរណាស់ នេះជារបៀបដែលគំរូតារាងត្រូវបានរចនា និងធ្វើការជាមួយទិន្នន័យនៅក្នុងវាដែលការស្ទះកើតឡើង។

ដូច្នេះ ដើម្បីភាពបរិសុទ្ធនៃការពិសោធន៍ យើងនឹងដកកត្តានេះចេញ ហើយខាងក្រោមខ្ញុំនឹងបញ្ជាក់ឱ្យច្បាស់អំពីរបៀប។

អនុញ្ញាតឱ្យយើងសន្មត់ថា 100% នៃពាក្យបញ្ជា SQL ដែលបានបញ្ជូនទៅកាន់មូលដ្ឋានទិន្នន័យគឺជាពាក្យបញ្ជា DML ។
អនុញ្ញាតឱ្យលក្ខណៈរបស់អ្នកប្រើធ្វើការជាមួយមូលដ្ឋានទិន្នន័យរងគឺដូចគ្នានៅក្នុងការធ្វើតេស្ត។
ឧទាហរណ៍៖ ចំនួនវគ្គ skl ទិន្នន័យតារាង របៀបដែលវគ្គ skl ដំណើរការជាមួយពួកគេ។
Subd ធ្វើការនៅ FORCE LOGGING, ARCHIVELOG ម៉ូដ។ របៀប Flashback-database ត្រូវបានបិទ នៅកម្រិតរង។
ធ្វើកំណត់ហេតុឡើងវិញ៖ មានទីតាំងនៅក្នុងប្រព័ន្ធឯកសារដាច់ដោយឡែកមួយនៅលើ "ថាស" ដាច់ដោយឡែក។
នៅសល់នៃសមាសធាតុរូបវន្តនៃមូលដ្ឋានទិន្នន័យ៖ នៅក្នុងប្រព័ន្ធឯកសារដាច់ដោយឡែកមួយទៀត នៅលើ "ថាស" ដាច់ដោយឡែកមួយ៖

ព័ត៌មានលម្អិតបន្ថែមអំពីឧបករណ៍រាងកាយ។ សមាសធាតុមូលដ្ឋានទិន្នន័យមន្ទីរពិសោធន៍

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-snapshots (អ្វីដែលត្រូវរៀបចំ)។

ទោះយ៉ាងណាក៏ដោយវាបានប្រែក្លាយ 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] MB;
ចំនួនក្រុមសារព័ត៌មានក្នុងមូលដ្ឋានទិន្នន័យ។ ជួរតម្លៃ៖ [2,32];
log_archive_max_processes ជួរតម្លៃ៖ [1,8];
commit_logging តម្លៃពីរត្រូវបានអនុញ្ញាត៖ batch|immediate;
commit_wait តម្លៃពីរត្រូវបានអនុញ្ញាត៖ wait|nowait;
log_buffer ជួរតម្លៃ៖ [2,128] MB ។
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 ក្នុងបរិមាណខ្លះនិងទំហំខ្លះសម្រាប់ភាពបរិសុទ្ធនៃការពិសោធន៍ - d.b. បានលុប។
ប្រសិនបើចំណុចមុនទទួលបានជោគជ័យ៖ ការបញ្ជាក់តម្លៃនៃប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធទៅកាន់មូលដ្ឋានទិន្នន័យ (ម្តងទៀត៖ អាចមានការបរាជ័យ)
ប្រសិនបើជំហានមុនទទួលបានជោគជ័យ៖ ការបញ្ឈប់ subd ចាប់ផ្តើម subd ដូច្នេះតម្លៃប៉ារ៉ាម៉ែត្រដែលបានបញ្ជាក់ថ្មីមានប្រសិទ្ធភាព។ (ម្តងទៀត៖ អាចមានកំហុស)
ប្រសិនបើជំហានមុនបានជោគជ័យ៖ ធ្វើតេស្តផ្ទុក។ ទទួលបានម៉ែត្រពី subd ។
ត្រឡប់ subd ទៅសភាពដើមរបស់វា i.e. លុបក្រុមកំណត់ហេតុបន្ថែម ត្រឡប់ការកំណត់មូលដ្ឋានទិន្នន័យរងដើមដើម្បីដំណើរការ។

លេខកូដមុខងារលំហាត់ប្រាណ

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

នោះ។ ការងារទាំងអស់៖ អនុវត្តក្នុងមុខងារសម្បទា។

ga-subroutine ដំណើរការវ៉ិចទ័រ ឬកាន់តែត្រឹមត្រូវ ក្រូម៉ូសូម។
ដែលក្នុងនោះ អ្វីដែលសំខាន់បំផុតសម្រាប់យើងគឺការជ្រើសរើសក្រូម៉ូសូមដែលមានហ្សែន ដែលមុខងារសម្បទាបង្កើតតម្លៃដ៏ធំ។

នេះជាការពិត គឺជាដំណើរការនៃការស្វែងរកសំណុំក្រូម៉ូសូមដ៏ល្អប្រសើរដោយប្រើវ៉ិចទ័រនៅក្នុងទំហំស្វែងរក N-dimensional ។

ច្បាស់ណាស់ លម្អិត ការពន្យល់ជាមួយនឹងឧទាហរណ៍នៃ R-code ការងារនៃក្បួនដោះស្រាយហ្សែន។

ខ្ញុំចង់កត់សម្គាល់ដោយឡែកពីគ្នានូវចំណុចបច្ចេកទេសពីរ។

ការហៅជំនួយពីមុខងារ evaluateឧទាហរណ៍ បញ្ឈប់ការចាប់ផ្តើម ការកំណត់តម្លៃនៃប៉ារ៉ាម៉ែត្ររងត្រូវបានអនុវត្តដោយផ្អែកលើ 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 ពាន់ tps: សំណួរដាច់ដោយឡែក។
នៅក្នុងក្របខ័ណ្ឌនៃការងារមន្ទីរពិសោធន៍តួលេខនេះមិនសំខាន់ទេអ្វីដែលសំខាន់គឺថាមវន្តតើតម្លៃនេះផ្លាស់ប្តូរយ៉ាងដូចម្តេច។

ថាមវន្តនៅទីនេះគឺល្អ។
វាច្បាស់ណាស់ថាយ៉ាងហោចណាស់កត្តាមួយមានឥទ្ធិពលយ៉ាងសំខាន់ទៅលើតម្លៃនៃម៉ែត្រគឺ ga-algorithm តម្រៀបតាមវ៉ិចទ័រក្រូម៉ូសូម៖ គ្របដណ្តប់។
ដោយវិនិច្ឆ័យដោយសក្ដានុពលដ៏ខ្លាំងក្លានៃតម្លៃខ្សែកោង យ៉ាងហោចណាស់មានកត្តាមួយបន្ថែមទៀតដែលទោះបីជាតូចជាងខ្លាំងក៏ដោយ ក៏មានឥទ្ធិពល។

នេះជាកន្លែងដែលអ្នកត្រូវការ attribute-importance ការវិភាគដើម្បីយល់ពីគុណលក្ខណៈអ្វី (ល្អក្នុងករណីនេះ សមាសធាតុនៃវ៉ិចទ័រលៃតម្រូវ) និងថាតើពួកវាមានឥទ្ធិពលលើតម្លៃម៉ែត្រប៉ុន្មាន។
ហើយពីព័ត៌មាននេះ៖ ស្វែងយល់ថាតើកត្តាអ្វីខ្លះត្រូវបានប៉ះពាល់ដោយការផ្លាស់ប្តូរលក្ខណៈសំខាន់ៗ។

ប្រតិបត្តិ attribute-importance អាចធ្វើទៅបានតាមវិធីផ្សេងៗគ្នា។

សម្រាប់គោលបំណងទាំងនេះខ្ញុំចូលចិត្តក្បួនដោះស្រាយ randomForest កញ្ចប់ R នៃឈ្មោះដូចគ្នា (ឯកសារ)
randomForestដូចដែលខ្ញុំយល់ពីការងាររបស់គាត់ជាទូទៅ និងវិធីសាស្រ្តរបស់គាត់ក្នុងការវាយតម្លៃសារៈសំខាន់នៃគុណលក្ខណៈជាពិសេស បង្កើតគំរូជាក់លាក់នៃការពឹងផ្អែកនៃអថេរឆ្លើយតបលើគុណលក្ខណៈ។

ក្នុងករណីរបស់យើង អថេរឆ្លើយតបគឺជាម៉ែត្រដែលទទួលបានពីមូលដ្ឋានទិន្នន័យក្នុងការធ្វើតេស្តផ្ទុក៖ tps;
ហើយគុណលក្ខណៈគឺជាធាតុផ្សំនៃវ៉ិចទ័រលៃតម្រូវ។

ដូច្នេះនៅទីនេះ randomForest វាយតម្លៃសារៈសំខាន់នៃគុណលក្ខណៈគំរូនីមួយៗដោយលេខពីរ៖ %IncMSE — របៀបដែលវត្តមាន/អវត្តមាននៃគុណលក្ខណៈនេះនៅក្នុងគំរូមួយផ្លាស់ប្តូរគុណភាព MSE នៃគំរូនេះ (កំហុសមធ្យមការ៉េ);

ហើយ IncNodePurity គឺជាលេខដែលឆ្លុះបញ្ចាំងពីរបៀបដែលល្អ ដោយផ្អែកលើតម្លៃនៃគុណលក្ខណៈនេះ សំណុំទិន្នន័យដែលមានការសង្កេតអាចត្រូវបានបែងចែក ដូច្នេះនៅក្នុងផ្នែកមួយមានទិន្នន័យជាមួយនឹងតម្លៃមួយនៃម៉ែត្រដែលត្រូវបានពន្យល់ និងនៅក្នុងផ្នែកផ្សេងទៀតជាមួយ តម្លៃមួយទៀតនៃម៉ែត្រ។
មែនហើយ នោះហើយជា៖ តើនេះជាលក្ខណៈចាត់ថ្នាក់កម្រិតណា (ខ្ញុំបានឃើញការពន្យល់ជាភាសារុស្សីច្បាស់លាស់បំផុតនៅលើ RandomForest នៅទីនេះ).

Worker-peasant R-code សម្រាប់ដំណើរការសំណុំទិន្នន័យជាមួយនឹងលទ្ធផលនៃការធ្វើតេស្តផ្ទុក៖

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 នៃការសរសេរទិន្នន័យ redo ពី subdb log buffer ទៅកាន់ក្រុម log បច្ចុប្បន្ន៖ synchronous ឬ asynchronous។
តម្លៃ nowait ដែលជាលទ្ធផលស្ទើរតែបញ្ឈរ ការកើនឡើងច្រើននៅក្នុងតម្លៃនៃម៉ែត្រ tps៖ នេះគឺជាការរួមបញ្ចូលនៃរបៀប io អសមកាលនៅក្នុងក្រុមធ្វើឡើងវិញ។
សំណួរដាច់ដោយឡែកមួយគឺថាតើអ្នកគួរធ្វើបែបនេះនៅក្នុងមូលដ្ឋានទិន្នន័យអាហារឬអត់។ នៅទីនេះខ្ញុំដាក់កម្រិតខ្លួនឯងថាគ្រាន់តែនិយាយថា: នេះគឺជាកត្តាសំខាន់មួយ។
វាជាឡូជីខលដែលទំហំនៃ log buffer នៃ subd: ប្រែទៅជាកត្តាសំខាន់។
ទំហំសតិបណ្ដោះអាសន្ននៃកំណត់ហេតុកាន់តែតូច សមត្ថភាពផ្ទុករបស់វាកាន់តែតិច នោះវាកាន់តែហូរហៀរ និង/ឬអសមត្ថភាពក្នុងការបែងចែកតំបន់ទំនេរនៅក្នុងវាសម្រាប់ផ្នែកនៃទិន្នន័យ redox ថ្មី។
នេះមានន័យថា៖ ការពន្យាពេលដែលទាក់ទងនឹងការបែងចែកទំហំនៅក្នុងសតិបណ្ដោះអាសន្នកំណត់ហេតុ និង/ឬការចាក់ទិន្នន័យឡើងវិញពីវាទៅក្នុងក្រុមឡើងវិញ។
ជាការពិតណាស់ការពន្យារពេលទាំងនេះគួរតែ និងប៉ះពាល់ដល់ដំណើរការនៃមូលដ្ឋានទិន្នន័យសម្រាប់ប្រតិបត្តិការ។
ប៉ារ៉ាម៉ែត្រ db_block_checksum៖ ផងដែរ ជាទូទៅវាច្បាស់ណាស់ - ដំណើរការប្រតិបត្តិការនាំទៅរកការបង្កើតប្លុក darty នៅក្នុងឃ្លាំងផ្ទុកទិន្នន័យរងរបស់មូលដ្ឋានទិន្នន័យ។
ដែលនៅពេលពិនិត្យមើល checksums នៃ datablock ត្រូវបានបើក មូលដ្ឋានទិន្នន័យត្រូវដំណើរការ - គណនា checksums ទាំងនេះពីតួនៃ datablock ពិនិត្យមើលវាជាមួយនឹងអ្វីដែលបានសរសេរនៅក្នុង datablock header៖ ផ្គូផ្គង/មិនត្រូវគ្នា។
ការងារបែបនេះម្តងទៀតមិនអាចពន្យារពេលដំណើរការទិន្នន័យបានទេ ហើយតាមនោះ ប៉ារ៉ាម៉ែត្រ និងយន្តការដែលកំណត់ប៉ារ៉ាម៉ែត្រនេះប្រែជាសំខាន់។
នោះហើយជាមូលហេតុដែលអ្នកលក់ផ្តល់ជូននៅក្នុងឯកសារសម្រាប់ប៉ារ៉ាម៉ែត្រនេះ តម្លៃផ្សេងគ្នាសម្រាប់វា (ប៉ារ៉ាម៉ែត្រ) ហើយចំណាំថាបាទ/ចាស វានឹងមានផលប៉ះពាល់ ប៉ុន្តែអ្នកអាចជ្រើសរើសតម្លៃផ្សេងគ្នារហូតដល់ "បិទ" និង ផលប៉ះពាល់ផ្សេងៗគ្នា។

ជាការប្រសើរណាស់, ការសន្និដ្ឋានជាសកល។

ជាទូទៅ វិធីសាស្រ្តនេះប្រែជាដំណើរការល្អ។

គាត់ពិតជាអនុញ្ញាតឱ្យខ្លួនគាត់ផ្ទាល់នៅក្នុងដំណាក់កាលដំបូងនៃការធ្វើតេស្តផ្ទុកនៃប្រព័ន្ធសេវាកម្មជាក់លាក់មួយដើម្បីជ្រើសរើស (ប្រព័ន្ធ) ការកំណត់រចនាសម្ព័ន្ធដ៏ល្អប្រសើររបស់វាសម្រាប់បន្ទុក មិនមែនដើម្បីស្វែងយល់ច្រើនពេកអំពីជាក់លាក់នៃការដំឡើងប្រព័ន្ធសម្រាប់បន្ទុកនោះទេ។

ប៉ុន្តែវាមិនរាប់បញ្ចូលវាទាំងស្រុងនោះទេ - យ៉ាងហោចណាស់នៅកម្រិតនៃការយល់ដឹង: ប្រព័ន្ធត្រូវតែដឹងអំពី "ឧបករណ៍លៃតម្រូវ" និងជួរដែលអាចអនុញ្ញាតបាននៃការបង្វិលនៃ knobs ទាំងនេះ។

វិធីសាស្រ្តនេះអាចរកឃើញការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធដ៏ល្អប្រសើរបានយ៉ាងឆាប់រហ័ស។
ហើយផ្អែកលើលទ្ធផលនៃការធ្វើតេស្ត វាអាចទទួលបានព័ត៌មានអំពីលក្ខណៈនៃទំនាក់ទំនងរវាងរង្វាស់នៃដំណើរការប្រព័ន្ធ និងតម្លៃនៃប៉ារ៉ាម៉ែត្រនៃការកំណត់ប្រព័ន្ធ។

ដែលជាការពិតណាស់គួរតែរួមចំណែកដល់ការលេចឡើងនៃការយល់ដឹងយ៉ាងជ្រាលជ្រៅនៃប្រព័ន្ធនេះប្រតិបត្តិការរបស់វាយ៉ាងហោចណាស់នៅក្រោមបន្ទុកដែលបានផ្តល់ឱ្យ។

នៅក្នុងការអនុវត្ត នេះគឺជាការដោះដូរនៃការចំណាយលើការយល់ដឹងអំពីប្រព័ន្ធតាមតម្រូវការសម្រាប់ការចំណាយក្នុងការរៀបចំការធ្វើតេស្តប្រព័ន្ធបែបនេះ។

ខ្ញុំចង់កត់សម្គាល់ដោយឡែកពីគ្នា៖ នៅក្នុងវិធីសាស្រ្តនេះ កម្រិតនៃភាពគ្រប់គ្រាន់នៃការធ្វើតេស្តប្រព័ន្ធទៅនឹងលក្ខខណ្ឌប្រតិបត្តិការដែលវានឹងមាននៅក្នុងប្រតិបត្តិការពាណិជ្ជកម្មគឺមានសារៈសំខាន់ណាស់។

សូមអរគុណចំពោះការយកចិត្តទុកដាក់ និងពេលវេលារបស់អ្នក។

ប្រភព: www.habr.com

បន្ថែមមតិយោបល់ ответОтменить