🥇 বৈজ্ঞানিক পোকিং পদ্ধতি, বা বেঞ্চমার্ক এবং একটি অপ্টিমাইজেশান অ্যালগরিদম ব্যবহার করে কীভাবে একটি সাবডেটাবেস কনফিগারেশন নির্বাচন করবেন

হ্যালো

আমি আমার সন্ধান ভাগ করার সিদ্ধান্ত নিয়েছি - চিন্তা, বিচার এবং ত্রুটির ফল।
সর্বোপরি: এটি অবশ্যই একটি সন্ধান নয় - এই সমস্ত কিছু দীর্ঘ সময়ের জন্য জানা উচিত ছিল, যারা প্রয়োগকৃত পরিসংখ্যানগত ডেটা প্রক্রিয়াকরণ এবং যে কোনও সিস্টেমের অপ্টিমাইজেশানের সাথে জড়িত, অগত্যা বিশেষভাবে ডিবিএমএস নয়।
এবং: হ্যাঁ, তারা জানে, তারা তাদের গবেষণায় আকর্ষণীয় নিবন্ধ লেখে, উদাহরণ (UPD.: মন্তব্যে তারা একটি খুব আকর্ষণীয় প্রকল্প নির্দেশ করেছে: ottertune )
অন্যদিকে: অফহ্যান্ড আমি আইটি বিশেষজ্ঞ, ডিবিএ-র মধ্যে ইন্টারনেটে এই পদ্ধতির কোনও ব্যাপক উল্লেখ বা প্রচার দেখতে পাচ্ছি না।

সুতরাং, বিন্দু.

আসুন ধরে নিই যে আমাদের একটি কাজ আছে: কোনও ধরণের কাজ করার জন্য একটি নির্দিষ্ট পরিষেবা সিস্টেম সেট আপ করা।

এই কাজটি সম্পর্কে জানা যায়: এটি কী, এই কাজের গুণমান কীভাবে পরিমাপ করা হয় এবং এই গুণটি পরিমাপের মাপকাঠি কী।

আসুন এটিও অনুমান করি যে এটি কমবেশি পরিচিত এবং বোঝা যায়: এই পরিষেবা সিস্টেমে (বা এর সাথে) ঠিক কীভাবে কাজ করা হয়।

"কম বা কম" - এর অর্থ হল একটি নির্দিষ্ট টুল, ইউটিলিটি, পরিষেবা প্রস্তুত করা সম্ভব (বা এটি কোথাও থেকে পাওয়া যায়) যা উৎপাদনে যা হবে তার জন্য পর্যাপ্ত পরিমাণে পরীক্ষার লোড সহ সিস্টেমে সংশ্লেষিত এবং প্রয়োগ করা যেতে পারে, উৎপাদনে কাজ করার জন্য যথেষ্ট পর্যাপ্ত পরিস্থিতিতে।

ঠিক আছে, আসুন ধরে নিই যে এই পরিষেবা সিস্টেমের জন্য সামঞ্জস্য পরামিতিগুলির একটি সেট পরিচিত, যা এই সিস্টেমটিকে এর কাজের উত্পাদনশীলতার পরিপ্রেক্ষিতে কনফিগার করতে ব্যবহার করা যেতে পারে।

এবং সমস্যাটি কী - এই পরিষেবা সিস্টেমের পর্যাপ্তভাবে সম্পূর্ণ বোধগম্যতা নেই, যা আপনাকে একটি প্রদত্ত প্ল্যাটফর্মে ভবিষ্যতের লোডের জন্য এই সিস্টেমের সেটিংস দক্ষতার সাথে কনফিগার করতে এবং সিস্টেমের প্রয়োজনীয় উত্পাদনশীলতা পেতে দেয়।

আমরা হব. এটি প্রায় সবসময়ই হয়।

আপনি এখানে কি করতে পারেন?

ওয়েল, মনে আসে যে প্রথম জিনিস এই সিস্টেমের জন্য ডকুমেন্টেশন তাকান হয়. সামঞ্জস্য পরামিতিগুলির মানগুলির জন্য গ্রহণযোগ্য ব্যাপ্তিগুলি কী তা বুঝুন। এবং, উদাহরণস্বরূপ, স্থানাঙ্ক ডিসেন্ট পদ্ধতি ব্যবহার করে, পরীক্ষায় সিস্টেম প্যারামিটারের জন্য মান নির্বাচন করুন।

সেগুলো. সিস্টেমটিকে তার কনফিগারেশন পরামিতিগুলির জন্য নির্দিষ্ট মানগুলির সেটের আকারে কিছু ধরণের কনফিগারেশন দিন।

এই খুব টুল-ইউটিলিটি, লোড জেনারেটর ব্যবহার করে এটিতে একটি পরীক্ষা লোড প্রয়োগ করুন।
এবং মান দেখুন - প্রতিক্রিয়া, বা সিস্টেমের মানের একটি মেট্রিক।

দ্বিতীয় চিন্তা উপসংহার হতে পারে যে এটি একটি খুব দীর্ঘ সময়.

ঠিক আছে, এটি হল: যদি অনেকগুলি সেটিং প্যারামিটার থাকে, যদি তাদের মানের পরিসরগুলি বড় হয়, যদি প্রতিটি পৃথক লোড পরীক্ষা সম্পূর্ণ হতে অনেক সময় নেয়, তাহলে: হ্যাঁ, এই সমস্ত কিছু অগ্রহণযোগ্যভাবে লাগতে পারে অনেকক্ষণ.

আচ্ছা, এখানে আপনি যা বুঝতে এবং মনে রাখতে পারেন।

আপনি খুঁজে পেতে পারেন যে পরিষেবা সিস্টেম সেটিংস প্যারামিটারের মানগুলির সেটে কিছু মানগুলির ক্রম হিসাবে একটি ভেক্টর রয়েছে।

এই জাতীয় প্রতিটি ভেক্টর, অন্যান্য জিনিসগুলি সমান (যেতে এটি এই ভেক্টর দ্বারা প্রভাবিত হয় না), মেট্রিকের একটি সম্পূর্ণ নির্দিষ্ট মানের সাথে মিলে যায় - একটি পরীক্ষার লোডের অধীনে সিস্টেমের অপারেশনের মানের একটি সূচক।

অর্থাত

সিস্টেম কনফিগারেশন ভেক্টর হিসেবে চিহ্নিত করা যাক যেখানে ; কোথায় — সিস্টেম কনফিগারেশন প্যারামিটারের সংখ্যা, এই পরামিতিগুলির মধ্যে কতগুলি আছে।

এবং এর সাথে মেট্রিকের মান এর হিসাবে এটি চিহ্নিত করা যাক
, তারপর আমরা একটি ফাংশন পেতে পারি:

ঠিক আছে, তারপর: সবকিছু অবিলম্বে নিচে চলে আসে, আমার ক্ষেত্রে: আমার ছাত্রাবস্থা থেকে প্রায় ভুলে গেছি, একটি ফাংশনের চরম অংশ অনুসন্ধানের জন্য অ্যালগরিদম।

ঠিক আছে, কিন্তু এখানে একটি সাংগঠনিক এবং প্রয়োগ করা প্রশ্ন উঠেছে: কোন অ্যালগরিদম ব্যবহার করতে হবে।

অর্থে - যাতে আপনি হাতে কম কোড করতে পারেন।
এবং এটি কাজ করার জন্য, i.e. extremum পাওয়া গেছে (যদি একটি থাকে), ভাল, অন্ততপক্ষে স্থানাঙ্কের চেয়ে দ্রুত।

প্রথম পয়েন্টটি ইঙ্গিত দেয় যে আমাদের এমন কিছু পরিবেশের দিকে তাকাতে হবে যেখানে এই ধরনের অ্যালগরিদমগুলি ইতিমধ্যেই প্রয়োগ করা হয়েছে, এবং কিছু আকারে, কোডে ব্যবহারের জন্য প্রস্তুত।
আচ্ছা, আমি জানি python и cran-r

দ্বিতীয় পয়েন্টটির অর্থ হল যে আপনাকে অ্যালগরিদমগুলি সম্পর্কে পড়তে হবে, সেগুলি কী, তাদের প্রয়োজনীয়তাগুলি এবং তাদের কাজের বৈশিষ্ট্যগুলি।

এবং তারা যা দেয় তা কার্যকর পার্শ্ব প্রতিক্রিয়া হতে পারে - ফলাফল, বা সরাসরি অ্যালগরিদম থেকে।

অথবা তারা অ্যালগরিদম ফলাফল থেকে প্রাপ্ত করা যেতে পারে.

ইনপুট অবস্থার উপর অনেক কিছু নির্ভর করে।

উদাহরণস্বরূপ, যদি কোনো কারণে, আপনার দ্রুত ফলাফল পেতে হয়, ভাল, আপনাকে গ্রেডিয়েন্ট ডিসেন্ট অ্যালগরিদমের দিকে তাকাতে হবে এবং সেগুলির মধ্যে একটি বেছে নিতে হবে।

অথবা, যদি সময় এত গুরুত্বপূর্ণ না হয়, আপনি উদাহরণস্বরূপ, স্টকাস্টিক অপ্টিমাইজেশান পদ্ধতি ব্যবহার করতে পারেন, যেমন একটি জেনেটিক অ্যালগরিদম।

আমি এই পদ্ধতির কাজ বিবেচনা করার প্রস্তাব করছি, সিস্টেম কনফিগারেশন নির্বাচন করে, একটি জেনেটিক অ্যালগরিদম ব্যবহার করে, পরবর্তীতে, তাই কথা বলতে: পরীক্ষাগারের কাজ।

প্রাথমিক:

একটি পরিষেবা ব্যবস্থা হিসাবে থাকতে দিন: oracle xe 18c
এটিকে লেনদেন সংক্রান্ত কার্যকলাপ এবং লক্ষ্য পরিবেশন করতে দিন: লেনদেন/সেকেন্ডে সাবডেটাবেসের সর্বোচ্চ সম্ভাব্য থ্রুপুট পেতে।
ডেটা নিয়ে কাজ করার প্রকৃতি এবং কাজের প্রসঙ্গে লেনদেনগুলি খুব আলাদা হতে পারে।
আসুন সম্মত হই যে এইগুলি এমন লেনদেন যা প্রচুর পরিমাণে ট্যাবুলার ডেটা প্রক্রিয়া করে না।
এই অর্থে যে তারা পুনরায় করার চেয়ে বেশি পূর্বাবস্থায় ডেটা তৈরি করে না এবং সারি এবং বড় টেবিলের বড় শতাংশ প্রক্রিয়া করে না।

এগুলি এমন লেনদেন যা এই টেবিলে অল্প সংখ্যক সূচী সহ কম বা বেশি বড় টেবিলে একটি সারি পরিবর্তন করে।

এই পরিস্থিতিতে: লেনদেন প্রক্রিয়াকরণের জন্য সাবডেটাবেসের উত্পাদনশীলতা, একটি সংরক্ষণ সহ, রেডক্স ডাটাবেস দ্বারা প্রক্রিয়াকরণের গুণমান দ্বারা নির্ধারিত হবে।

দাবিত্যাগ - যদি আমরা সাবডিবি সেটিংস সম্পর্কে বিশেষভাবে কথা বলি।

কারণ, সাধারণ ক্ষেত্রে, উদাহরণস্বরূপ, ট্যাবুলার ডেটা এবং/অথবা ট্যাবুলার মডেলের সাথে ব্যবহারকারীর কাজের ডিজাইনের কারণে SQL সেশনের মধ্যে লেনদেনমূলক লক থাকতে পারে।

যা, অবশ্যই, টিপিএস মেট্রিকের উপর একটি হতাশাজনক প্রভাব ফেলবে এবং এটি সাবডেটাবেসের সাথে সম্পর্কিত একটি বহিরাগত ফ্যাক্টর হবে: ভাল, এইভাবে ট্যাবুলার মডেলটি ডিজাইন করা হয়েছিল এবং এতে ডেটা নিয়ে কাজ যা ব্লকেজগুলি ঘটে।

অতএব, পরীক্ষার বিশুদ্ধতার জন্য, আমরা এই ফ্যাক্টরটি বাদ দেব এবং নীচে আমি ঠিক কীভাবে ব্যাখ্যা করব।

আসুন আমরা অনুমান করি, নিশ্চিততার জন্য, ডাটাবেসে জমা দেওয়া এসকিউএল কমান্ডের 100% হল ডিএমএল কমান্ড।
সাবডেটাবেসের সাথে ব্যবহারকারীর কাজের বৈশিষ্ট্য পরীক্ষায় একই হতে দিন।
যথা: skl সেশনের সংখ্যা, ট্যাবুলার ডেটা, কীভাবে skl সেশনগুলি তাদের সাথে কাজ করে।
Subd কাজ করে FORCE LOGGING, ARCHIVELOG মোড ফ্ল্যাশব্যাক-ডাটাবেস মোড বন্ধ, সাবডি স্তরে।
লগ পুনরায় করুন: একটি পৃথক ফাইল সিস্টেমে অবস্থিত, একটি পৃথক "ডিস্ক" এ;
ডাটাবেসের অবশিষ্ট ভৌত উপাদান: অন্যটিতে, পৃথক ফাইল সিস্টেম, একটি পৃথক "ডিস্ক" এ:

শারীরিক ডিভাইস সম্পর্কে আরো বিশদ বিবরণ. পরীক্ষাগার ডাটাবেস উপাদান

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 পদ্ধতির লক্ষ্য প্ল্যাটফর্ম পরীক্ষা করা
আবেদন বিবাদ ছাড়া। একজন সর্বোচ্চ হার্ডওয়্যার কর্মক্ষমতা চালাতে পারে না
অ্যাপ্লিকেশন কোড ব্যবহার করে যা, উদাহরণস্বরূপ, অ্যাপ্লিকেশন লকিং বা এমনকি দ্বারা আবদ্ধ
ওরাকল ডাটাবেস ব্লক শেয়ার করা। এটা ঠিক—ডেটা শেয়ার করার সময় ওভারহেড থাকে
ডেটা ব্লকে! কিন্তু SLOB - এটির ডিফল্ট স্থাপনায় - এই ধরনের বিতর্ক থেকে অনাক্রম্য।

এই ঘোষণা: অনুরূপ, এটা.
cl সেশনের সমান্তরালতার ডিগ্রী নিয়ন্ত্রণ করা সুবিধাজনক, এটি হল মূল -t ইউটিলিটি চালু করুন runit.sh SLOB থেকে
ডিএমএল কমান্ডের শতাংশ নিয়ন্ত্রিত হয়, সাবডিতে পাঠানো পাঠ্য বার্তার সংখ্যা, প্রতিটি পাঠ্য অধিবেশন, পরামিতি 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

ল্যাবরেটরির কাজে ফিরে আসা।
আমরা, অন্যান্য জিনিস সমান হওয়ায়, পরীক্ষাগার সাবডেটাবেসের নিম্নলিখিত পরামিতিগুলির মানগুলি পরিবর্তিত করব:

ডাটাবেস লগ গ্রুপের আকার। মান পরিসীমা: [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;

ওরাকল ডাটাবেস রক্ষণাবেক্ষণের অভিজ্ঞতাসম্পন্ন একজন ব্যক্তি অবশ্যই ইতিমধ্যেই বলতে পারেন যে নির্দিষ্ট প্যারামিটার এবং তাদের গ্রহণযোগ্য মানগুলি থেকে কী এবং কী মানগুলি সেট করা উচিত, যাতে নির্দেশিত ডেটা সহ কাজের জন্য ডাটাবেসের আরও বেশি উত্পাদনশীলতা পেতে অ্যাপ্লিকেশন কোড, এখানে উপরে.

কিন্তু।

ল্যাবরেটরির কাজের পয়েন্টটি হল দেখানো যে অপ্টিমাইজেশান অ্যালগরিদম নিজেই আমাদের জন্য এটি তুলনামূলকভাবে দ্রুত পরিষ্কার করবে।

আমাদের জন্য, যা অবশিষ্ট থাকে তা হল কাস্টমাইজযোগ্য সিস্টেমের মাধ্যমে নথির দিকে নজর দেওয়া, কোন প্যারামিটারগুলি পরিবর্তন করতে হবে এবং কোন পরিসরে তা খুঁজে বের করার জন্য যথেষ্ট।
এবং এছাড়াও: কোডটি কোড করুন যা নির্বাচিত অপ্টিমাইজেশান অ্যালগরিদমের কাস্টম সিস্টেমের সাথে কাজ করতে ব্যবহৃত হবে।

সুতরাং, এখন কোড সম্পর্কে.
আমি উপরে কথা বলেছি 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 সাবরুটিন ফিটনেস ফাংশন সর্বাধিক করে একটি অনুসন্ধান সম্পাদন করে।

ঠিক আছে, তাহলে, দেখা যাচ্ছে যে, এই ক্ষেত্রে, ফিটনেস ফাংশনটি, সাবডি-এর নির্দিষ্ট পরামিতিগুলির জন্য মানগুলির একটি সেট হিসাবে ভেক্টরকে বোঝার জন্য, সাবডি থেকে একটি মেট্রিক গ্রহণ করা প্রয়োজন।

অর্থাৎ: কতগুলি, একটি প্রদত্ত সাবডি সেটআপ এবং সাবডিতে একটি প্রদত্ত লোড সহ: সাবডি প্রতি সেকেন্ডে লেনদেন প্রক্রিয়া করে৷

অর্থাৎ, উন্মোচন করার সময়, ফিটনেস ফাংশনের অভ্যন্তরে নিম্নলিখিত বহু-পদক্ষেপগুলি সম্পাদন করতে হবে:

সংখ্যার ইনপুট ভেক্টর প্রক্রিয়াকরণ - সাবডেটা প্যারামিটারের জন্য এটিকে মানগুলিতে রূপান্তর করা।
একটি প্রদত্ত আকারের একটি প্রদত্ত সংখ্যক রিডো গ্রুপ তৈরি করার একটি প্রচেষ্টা৷ তদুপরি, প্রচেষ্টা ব্যর্থ হতে পারে।
ম্যাগাজিন গ্রুপগুলি যা ইতিমধ্যেই সাবডিতে, কিছু পরিমাণে এবং কিছু আকারের, পরীক্ষার বিশুদ্ধতার জন্য বিদ্যমান ছিল - d.b. মুছে ফেলা হয়েছে
যদি পূর্ববর্তী পয়েন্টটি সফল হয়: ডাটাবেসে কনফিগারেশন প্যারামিটারের মান উল্লেখ করা (আবার: একটি ব্যর্থতা হতে পারে)
যদি পূর্ববর্তী ধাপটি সফল হয়: সাবডি বন্ধ করা, সাবডি শুরু করা যাতে নতুন নির্দিষ্ট করা প্যারামিটার মান কার্যকর হয়। (আবার: একটি ত্রুটি হতে পারে)
পূর্ববর্তী ধাপ সফল হলে: একটি লোড পরীক্ষা সঞ্চালন. সাবডি থেকে মেট্রিক্স পান।
সাবডিটিকে তার আসল অবস্থায় ফিরিয়ে দিন, যেমন অতিরিক্ত লগ গ্রুপ মুছে দিন, মূল সাবডেটাবেস কনফিগারেশন কাজ করতে ফিরিয়ে দিন।

ফিটনেস ফাংশন কোড

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-মাত্রিক অনুসন্ধান স্থানে একটি ভেক্টর ব্যবহার করে ক্রোমোজোমের সর্বোত্তম সেট অনুসন্ধান করার প্রক্রিয়া।

খুব পরিষ্কার, বিস্তারিত ব্যাখ্যা, আর-কোডের উদাহরণ সহ, একটি জেনেটিক অ্যালগরিদমের কাজ।

আমি আলাদাভাবে দুটি প্রযুক্তিগত পয়েন্ট নোট করতে চাই।

ফাংশন থেকে সহায়ক কল evaluate, উদাহরণস্বরূপ, স্টপ-স্টার্ট, সাবডি প্যারামিটারের মান সেট করা, এর উপর ভিত্তি করে সঞ্চালিত হয় cran-r ফাংশন system2

যার সাহায্যে: কিছু ব্যাশ স্ক্রিপ্ট বা কমান্ড বলা হয়।

উদাহরণস্বরূপ:

সেট_ডিবি_প্যারামিটার

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 হাজার টিপিএস: একটি পৃথক প্রশ্ন।
পরীক্ষাগার কাজের কাঠামোর মধ্যে, এই চিত্রটি গুরুত্বপূর্ণ নয়, কী গুরুত্বপূর্ণ তা হল গতিবিদ্যা, কীভাবে এই মানটি পরিবর্তিত হয়।

এখানে গতিশীলতা ভাল.
এটা স্পষ্ট যে অন্তত একটি ফ্যাক্টর উল্লেখযোগ্যভাবে মেট্রিকের মানকে প্রভাবিত করে, ga-অ্যালগরিদম, ক্রোমোজোম ভেক্টরের মাধ্যমে সাজানো: আচ্ছাদিত।
বক্র মানগুলির মোটামুটি জোরালো গতিবিদ্যা দ্বারা বিচার করলে, অন্তত আরও একটি ফ্যাক্টর রয়েছে যা উল্লেখযোগ্যভাবে ছোট হলেও প্রভাব ফেলে।

এই যেখানে আপনি এটি প্রয়োজন attribute-importance কোন বৈশিষ্ট্যগুলি (ভালভাবে, এই ক্ষেত্রে, টিউনিং ভেক্টরের উপাদানগুলি) এবং তারা মেট্রিক মানকে কতটা প্রভাবিত করে তা বোঝার জন্য বিশ্লেষণ।
এবং এই তথ্য থেকে: গুরুত্বপূর্ণ বৈশিষ্ট্যের পরিবর্তনের দ্বারা কোন কারণগুলি প্রভাবিত হয়েছিল তা বুঝুন।

চালান attribute-importance বিভিন্ন উপায়ে করা যেতে পারে।

এই উদ্দেশ্যে, আমি অ্যালগরিদম পছন্দ করি randomForest একই নামের R প্যাকেজ (ডকুমেন্টেশন)
randomForest, যেমন আমি সাধারণভাবে তার কাজ বুঝতে পারি এবং বিশেষ করে গুণাবলীর গুরুত্ব মূল্যায়ন করার জন্য তার দৃষ্টিভঙ্গি, বৈশিষ্ট্যগুলির উপর প্রতিক্রিয়া ভেরিয়েবলের নির্ভরতার একটি নির্দিষ্ট মডেল তৈরি করে।

আমাদের ক্ষেত্রে, রেসপন্স ভেরিয়েবল হল লোড টেস্টে ডাটাবেস থেকে প্রাপ্ত একটি মেট্রিক: tps;
এবং গুণাবলী হল টিউনিং ভেক্টরের উপাদান।

এবং তাই randomForest দুটি সংখ্যার সাথে প্রতিটি মডেল বৈশিষ্ট্যের গুরুত্ব মূল্যায়ন করে: %IncMSE — কিভাবে একটি মডেলে এই বৈশিষ্ট্যের উপস্থিতি/অনুপস্থিতি এই মডেলের MSE গুণমানকে পরিবর্তন করে (মান বর্গীয় ত্রুটি);

এবং IncNodePurity হল এমন একটি সংখ্যা যা প্রতিফলিত করে কতটা ভালভাবে, এই বৈশিষ্ট্যের মানগুলির উপর ভিত্তি করে, পর্যবেক্ষণ সহ একটি ডেটাসেটকে ভাগ করা যায়, যাতে একটি অংশে মেট্রিকের একটি মান সহ ডেটা থাকে এবং অন্যটিতে ব্যাখ্যা করা হয় মেট্রিকের আরেকটি মান।
ঠিক আছে, এটি হল: এটি কতটা শ্রেণীবদ্ধ বৈশিষ্ট্য (আমি র্যান্ডমফরেস্টের সবচেয়ে স্পষ্ট, রাশিয়ান-ভাষার ব্যাখ্যা দেখেছি এখানে).

লোড পরীক্ষার ফলাফল সহ একটি ডেটাসেট প্রক্রিয়াকরণের জন্য শ্রমিক-কৃষক 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 অপারেশনের এক্সিকিউশন মোড নির্দিষ্ট করে: সিঙ্ক্রোনাস বা অ্যাসিঙ্ক্রোনাস।
মান nowait যার ফলে tps মেট্রিকের মান প্রায় উল্লম্ব, একাধিক বৃদ্ধি পায়: এটি হল রিডো গ্রুপে অ্যাসিঙ্ক্রোনাস আইও মোডের অন্তর্ভুক্তি।
একটি পৃথক প্রশ্ন হল আপনার খাদ্য ডাটাবেসে এটি করা উচিত কিনা। এখানে আমি নিজেকে শুধু বলার মধ্যেই সীমাবদ্ধ রাখি: এটি একটি উল্লেখযোগ্য ফ্যাক্টর।
এটা যৌক্তিক যে subd এর লগ বাফারের আকার: একটি উল্লেখযোগ্য ফ্যাক্টর হতে সক্রিয় আউট.
লগ বাফারের আকার যত ছোট হবে, এর বাফারিং ক্ষমতা তত কম হবে, প্রায়ই এটি উপচে পড়বে এবং/অথবা নতুন রেডক্স ডেটার একটি অংশের জন্য এটিতে একটি মুক্ত এলাকা বরাদ্দ করতে অক্ষমতা।
এর অর্থ হল: লগ বাফারে স্থান বরাদ্দ করা এবং/অথবা এটি থেকে রিডো গ্রুপে ডাম্পিং রিডো ডেটার সাথে যুক্ত বিলম্ব।
এই বিলম্বগুলি অবশ্যই লেনদেনের জন্য ডাটাবেসের থ্রুপুটকে প্রভাবিত করবে এবং করবে৷
স্থিতিমাপ db_block_checksum: ভাল, এছাড়াও, সাধারণভাবে এটি পরিষ্কার - লেনদেন প্রক্রিয়াকরণ সাবডেটাবেসের বাফার ক্যাশে ডার্টি ব্লক গঠনের দিকে নিয়ে যায়।
যেটি, যখন ডেটাব্লকগুলির চেকসামগুলি পরীক্ষা করা সক্রিয় করা হয়, তখন ডাটাবেসকে প্রক্রিয়া করতে হয় - ডেটাব্লকের মূল অংশ থেকে এই চেকসামগুলি গণনা করে, ডেটাব্লক শিরোলেখের মধ্যে যা লেখা আছে তা দিয়ে সেগুলি পরীক্ষা করুন: মেলে/মেলে না।
এই ধরনের কাজ, আবার, ডেটা প্রসেসিংকে বিলম্বিত করতে পারে না এবং সেই অনুযায়ী, প্যারামিটার এবং মেকানিজম যা এই প্যারামিটার সেট করে তা তাৎপর্যপূর্ণ হতে পারে।
এই কারণেই বিক্রেতা এই প্যারামিটারের জন্য ডকুমেন্টেশনে বিভিন্ন মান এবং নোট দেয় যে হ্যাঁ, একটি প্রভাব থাকবে, তবে আপনি বিভিন্ন মান, এমনকি "বন্ধ" এবং বিভিন্ন প্রভাব চয়ন করতে পারেন।

ওয়েল, একটি বিশ্বব্যাপী উপসংহার.

পদ্ধতি, সাধারণভাবে, বেশ কার্যকরী হতে দেখা যাচ্ছে।

তিনি একটি নির্দিষ্ট পরিষেবা সিস্টেমের লোড পরীক্ষার প্রাথমিক পর্যায়ে, লোডের জন্য এটির (সিস্টেম) সর্বোত্তম কনফিগারেশন নির্বাচন করার জন্য, লোডের জন্য সিস্টেম সেট আপ করার সুনির্দিষ্ট বিষয়ে খুব বেশি অনুসন্ধান না করার জন্য নিজেকে অনুমতি দেন।

তবে এটি সম্পূর্ণরূপে বাদ দেয় না - অন্তত বোঝার স্তরে: সিস্টেমটিকে অবশ্যই "সামঞ্জস্য নব" এবং এই নবগুলির ঘূর্ণনের অনুমতিযোগ্য পরিসীমা সম্পর্কে জানা উচিত।

পদ্ধতিটি তারপর অপেক্ষাকৃত দ্রুত সর্বোত্তম সিস্টেম কনফিগারেশন খুঁজে পেতে পারে।
এবং পরীক্ষার ফলাফলের উপর ভিত্তি করে, সিস্টেমের কর্মক্ষমতা মেট্রিক্স এবং সিস্টেম সেটিংস পরামিতিগুলির মানগুলির মধ্যে সম্পর্কের প্রকৃতি সম্পর্কে তথ্য পাওয়া সম্ভব।

যা, অবশ্যই, অন্তত একটি প্রদত্ত লোড অধীনে সিস্টেম, তার অপারেশন এই খুব গভীর বোঝার উত্থানে অবদান রাখা উচিত।

অনুশীলনে, এটি সিস্টেমের এই ধরনের পরীক্ষার প্রস্তুতির খরচের জন্য কাস্টমাইজড সিস্টেম বোঝার খরচের বিনিময়।

আমি আলাদাভাবে নোট করতে চাই: এই পদ্ধতিতে, বাণিজ্যিক ক্রিয়াকলাপে এটির অপারেটিং অবস্থার জন্য সিস্টেম পরীক্ষার পর্যাপ্ততার ডিগ্রি সমালোচনামূলকভাবে গুরুত্বপূর্ণ।

আপনার মনোযোগ এবং সময় জন্য আপনাকে ধন্যবাদ.

উত্স: www.habr.com

একটি মন্তব্য জুড়ুন উত্তর বাতিল