سلام
مون پنهنجي ڳولا کي حصيداري ڪرڻ جو فيصلو ڪيو - فڪر، آزمائش ۽ غلطي جو ميوو.
عام طور تي: هي هڪ ڳولها ناهي، يقينا - اهو سڀ ڪجهه ڊگهي عرصي کان ڄاڻڻ گهرجي، انهن لاء جيڪي لاڳو ٿيل شمارياتي ڊيٽا پروسيسنگ ۽ ڪنهن به سسٽم جي اصلاح ۾ ملوث آهن، خاص طور تي خاص طور تي ڊي بي ايم ايس.
۽: ها، اهي ڄاڻن ٿا، اهي پنهنجي تحقيق تي دلچسپ مضمون لکندا آهن، (UPD.: تبصرن ۾ انهن هڪ تمام دلچسپ منصوبي جي نشاندهي ڪئي: )
ٻئي طرف: مون کي انٽرنيٽ تي آئي ٽي ماهرن، ڊي بي اي جي وچ ۾ انٽرنيٽ تي هن طريقي جو ڪو به وسيع ذڪر يا ورهائڻ نظر نٿو اچي.
تنهن ڪري، نقطي تائين.
اچو ته فرض ڪريو ته اسان وٽ ھڪڙو ڪم آھي: ھڪڙي قسم جي ڪم جي خدمت لاء ھڪڙي خاص سروس سسٽم قائم ڪرڻ لاء.
هن ڪم جي باري ۾ معلوم ٿئي ٿو: اهو ڇا آهي، هن ڪم جي معيار کي ڪيئن ماپي ويندي آهي، ۽ هن معيار کي ماپڻ لاء معيار ڇا آهي.
اچو ته اهو پڻ فرض ڪريون ته اهو گهٽ يا گهٽ ڄاڻايل ۽ سمجھيو ويو آهي: بلڪل ڪيئن ڪم ڪيو ويندو آهي (يا سان) هن سروس سسٽم ۾.
"وڌيڪ يا گهٽ" - ان جو مطلب اهو آهي ته اهو ممڪن آهي تيار ڪرڻ (يا ڪنهن هنڌ کان حاصل ڪريو) هڪ خاص اوزار، افاديت، خدمت جيڪا ترتيب ڏئي سگهجي ٿي ۽ سسٽم تي لاڳو ٿي سگهي ٿي ٽيسٽ لوڊ سان ڪافي ڪافي آهي جيڪا پيداوار ۾ هوندي، پيداوار ۾ ڪم ڪرڻ لاء ڪافي حالتن ۾.
خير، اچو ته فرض ڪريون ته هن سروس سسٽم لاءِ ايڊجسٽمينٽ پيٽرولر جو هڪ سيٽ معلوم ٿئي ٿو، جيڪو هن سسٽم کي ترتيب ڏيڻ لاءِ استعمال ڪري سگهجي ٿو ان جي ڪم جي پيداوار جي لحاظ کان.
۽ مسئلو ڇا آهي - هن سروس سسٽم جي ڪافي مڪمل ڄاڻ نه آهي، جيڪو توهان کي ڏنل پليٽ فارم تي مستقبل جي لوڊ لاء هن سسٽم جي سيٽنگن کي ماهر طور تي ترتيب ڏيڻ ۽ سسٽم جي گهربل پيداوار حاصل ڪرڻ جي اجازت ڏئي ٿو.
خير. اهو لڳ ڀڳ هميشه ڪيس آهي.
توهان هتي ڇا ڪري سگهو ٿا؟
خير، پهرين شيء جيڪا ذهن ۾ اچي ٿي هن سسٽم لاء دستاويزن کي ڏسڻ لاء. سمجھو ته ڇا قابل قبول حدون آھن تنصيب جي ماپن جي قدرن لاءِ. ۽، مثال طور، coordinate descent طريقو استعمال ڪندي، ٽيسٽ ۾ سسٽم پيٽرولر لاءِ قدر چونڊيو.
اهي. سسٽم کي ڪجهه قسم جي ترتيب ڏيو، ان جي ترتيب جي پيٽرولن لاء قدر جي مخصوص سيٽ جي صورت ۾.
ان تي ٽيسٽ لوڊ لاڳو ڪريو، ھي تمام اوزار استعمال ڪندي، لوڊ جنريٽر.
۽ قدر کي ڏسو - جواب، يا سسٽم جي معيار جو هڪ ميٽرڪ.
ٻيو خيال اهو نتيجو ٿي سگهي ٿو ته اهو هڪ تمام ڊگهو وقت آهي.
چڱو، اهو آهي: جيڪڏهن اتي ڪيترائي سيٽنگ پيٽرولر آهن، جيڪڏهن انهن جي قيمتن جي حدن جو سلسلو تمام وڏو آهي، جيڪڏهن هر فرد جي لوڊ ٽيسٽ مڪمل ٿيڻ ۾ تمام گهڻو وقت وٺندو آهي، پوء: ها، اهو سڀ ڪجهه ناقابل قبول ٿي سگهي ٿو. وڏو وقت.
خير، هتي آهي جيڪو توهان سمجهي ۽ ياد ڪري سگهو ٿا.
توهان اهو ڳولي سگهو ٿا ته خدمت سسٽم جي سيٽنگن جي قيمتن جي سيٽنگن ۾ هڪ ویکٹر آهي، ڪجهه قدرن جي ترتيب جي طور تي.
هر هڪ اهڙي ویکٹر، ٻيون شيون برابر هجڻ (ان ۾ هن ویکٹر کان متاثر نه ٿيو آهي)، ميٽرڪ جي مڪمل طور تي مقرر قدر سان ملندڙ جلندڙ آهي - هڪ امتحان واري لوڊ هيٺ سسٽم جي آپريشن جي معيار جو هڪ اشارو.
I.
اچو ته سسٽم جي ترتيب واري ویکٹر کي بيان ڪريون جيئن 
ڪٿي ؛ ڪٿي - سسٽم جي ٺاھ جوڙ جي پيٽرولن جو تعداد، انھن مان ڪيترا آھن.
۽ انهي سان لاڳاپيل ميٽرڪ جو قدر اچو ته ان کي بيان ڪريون
، پوء اسان هڪ فنڪشن حاصل ڪندا آهيون:
خير، پوءِ: سڀ ڪجهه فوري طور تي اچي ٿو، منهنجي صورت ۾: تقريبن منهنجي شاگردن جي ڏينهن کان وساريو ويو، هڪ فنڪشن جي انتها کي ڳولڻ لاء الگورتھم.
ٺيڪ آهي، پر هتي هڪ تنظيمي ۽ لاڳو سوال پيدا ٿئي ٿو: ڪهڙو الورورٿم استعمال ڪجي.
- معنيٰ ۾ - انهي ڪري ته توهان هٿ سان گهٽ ڪوڊ ڪري سگهو ٿا.
- ۽ ان کي ڪم ڪرڻ لاء، يعني. انتها مليا (جيڪڏهن ڪو آهي)، چڱو، گهٽ ۾ گهٽ تيزيء سان همراه نزول کان.
پهريون نقطو اشارو ڏئي ٿو ته اسان کي ڪجهه ماحول ڏانهن ڏسڻ جي ضرورت آهي جنهن ۾ اهڙا الگورتھم اڳ ۾ ئي لاڳو ڪيا ويا آهن، ۽ آهن، ڪجهه شڪل ۾، ڪوڊ ۾ استعمال لاء تيار آهن.
خير، مون کي خبر آهي python и cran-r
ٻئي نقطي جو مطلب اهو آهي ته توهان کي خود الگورتھم بابت پڙهڻ جي ضرورت آهي، اهي ڇا آهن، انهن جون گهرجون ڪهڙيون آهن، ۽ انهن جي ڪم جون خاصيتون.
۽ جيڪي ڏيندا آھن سو ٿي سگھي ٿو مفيد ضمني اثرات - نتيجا، يا سڌو سنئون الگورتھم مان.
يا اهي الگورتھم جي نتيجن مان حاصل ڪري سگھجن ٿيون.
گهڻو ڪجهه ان پٽ جي حالتن تي منحصر آهي.
مثال طور، جيڪڏهن، ڪنهن سبب جي ڪري، توهان کي تڪڙو نتيجو حاصل ڪرڻ جي ضرورت آهي، سٺو، توهان کي ڏسڻ جي ضرورت آهي گريجوئيٽ نزول الگورتھم ڏانهن ۽ انهن مان هڪ چونڊيو.
يا، جيڪڏهن وقت ايترو اهم نه آهي، توهان ڪري سگهو ٿا، مثال طور، اسٽوچسٽڪ اصلاحي طريقا استعمال ڪريو، جهڙوڪ جينياتي الگورتھم.
مان هن طريقي جي ڪم تي غور ڪرڻ جي صلاح ڏيان ٿو، سسٽم جي ترتيب کي چونڊڻ، جينياتي الگورتھم استعمال ڪندي، پوء ڳالهائڻ لاء: ليبارٽري ڪم.
اصل:
- اچو ته، هڪ سروس سسٽم جي طور تي:
oracle xe 18c - ان کي ٽرانزيڪشن جي سرگرمي ۽ مقصد جي خدمت ڪرڻ ڏيو: ذيلي ڊيٽابيس جي اعلي ترين ممڪن ذريعي حاصل ڪرڻ لاء، ٽرانزيڪشن / سيڪنڊ ۾.
- ٽرانزيڪشن ڊيٽا سان ڪم ڪرڻ جي نوعيت ۾ ۽ ڪم جي حوالي سان تمام مختلف ٿي سگهن ٿا.
اچو ته متفق آهيون ته اهي ٽرانزيڪشن آهن جيڪي پروسيس نه ڪندا آهن وڏي مقدار ۾ ٽيبلر ڊيٽا.
انهي معنى ۾ ته اهي ٻيهر ٺاهڻ کان وڌيڪ اڻڄاتل ڊيٽا پيدا نه ڪندا آهن ۽ قطار ۽ وڏي ٽيبل جي وڏي سيڪڙو تي عمل نه ڪندا آهن.
اهي ٽرانزيڪشن آهن جيڪي هڪ قطار کي گهٽ يا گهٽ وڏي ٽيبل ۾ تبديل ڪندا آهن، هن ميز تي انڊيڪس جي ننڍڙي تعداد سان.
هن صورتحال ۾: پروسيسنگ ٽرانزيڪشن لاء ذيلي ڊيٽابيس جي پيداوار، هڪ رزرويشن سان، ريڊڪس ڊيٽابيس پاران پروسيسنگ جي معيار طرفان طئي ڪيو ويندو.
ڊسڪليمر - جيڪڏهن اسان خاص طور تي ذيلي ڊي بي سيٽنگون بابت ڳالهايون ٿا.
ڇاڪاڻ ته، عام صورت ۾، ٿي سگهي ٿو، مثال طور، SQL سيشن جي وچ ۾ ٽرانزيڪشنل لاڪ، صارف جي ڪم جي ڊيزائن جي ڪري ٽيبلر ڊيٽا ۽/يا ٽيبل ماڊل سان.
جنهن جو، يقيناً، TPS ميٽرڪ تي هڪ مايوس ڪندڙ اثر پوندو ۽ اهو هڪ خارجي عنصر هوندو، جيڪو ذيلي ڊيٽابيس جي نسبت سان آهي: خير، هي ڪيئن ٺهيل ماڊل ماڊل ٺاهيو ويو ۽ ان ۾ ڊيٽا سان ڪم ڪيو ويو جنهن ۾ رڪاوٽون ٿينديون آهن.
تنهن ڪري، تجربي جي پاڪائي لاء، اسان هن عنصر کي خارج ڪنداسين، ۽ هيٺ آئون واضح ڪندس ته ڪيئن.
- اچو ته فرض ڪريون، يقيني طور تي، ته ڊيٽابيس ۾ جمع ڪيل SQL حڪمن جو 100٪ DML ڪمانڊ آهن.
اچو ته صارف جي ڪم جي خاصيتن کي ذيلي ڊيٽابيس سان گڏ ٽيسٽ ۾ ساڳيو هجي.
يعني: skl سيشن جو تعداد، ٽيبلر ڊيٽا، ڪيئن skl سيشن انهن سان ڪم ڪن ٿا. - Subd ۾ ڪم ڪري ٿو
FORCE LOGGING,ARCHIVELOGموڊ Flashback-ڊيٽابيس موڊ بند ڪيو ويو آهي، ذيلي سطح تي. - ريڊ لاگز: هڪ الڳ فائل سسٽم ۾ واقع، هڪ الڳ "ڊسڪ" تي؛
ڊيٽابيس جو باقي جسماني حصو: ٻئي ۾، الڳ فائل سسٽم، هڪ الڳ "ڊسڪ" تي:
جسماني ڊوائيس بابت وڌيڪ تفصيل. ليبارٽري ڊيٽابيس اجزاء
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 طريقو پليٽ فارمن کي جانچڻ جو مقصد آهي
بغير درخواست جي تڪرار کان سواء. هڪ هارڊويئر جي وڌ ۾ وڌ ڪارڪردگي کي ڊرائيو نٿو ڪري سگهي
ايپليڪيشن ڪوڊ استعمال ڪندي، مثال طور، ايپليڪيشن لاڪنگ يا ايستائين جو پابند
شيئرنگ Oracle ڊيٽابيس بلاڪ. اھو صحيح آھي- ڊيٽا شيئر ڪرڻ وقت مٿي آھي
ڊيٽا بلاڪ ۾! پر SLOB- ان جي ڊفالٽ ڊيپلائيشن ۾- اهڙي تڪرار کان محفوظ آهي.
هي اعلان: ملندڙ آهي، اهو آهي.
اهو cl سيشن جي برابري جي درجي کي منظم ڪرڻ لاء آسان آهي، هي اهم آهي -t يوٽيلٽي شروع ڪريو runit.sh SLOB کان
ڊي ايم ايل حڪمن جو سيڪڙو منظم ڪيو ويو آهي، ٽيڪسٽ پيغامن جي تعداد ۾ جيڪي سب ڊي ڏانهن موڪليا ويا آهن، هر ٽيڪسٽ سيشن، پيٽرولر UPDATE_PCT
الڳ الڳ ۽ بلڪل آساني سان: SLOB پاڻ، لوڊ سيشن کان اڳ ۽ بعد ۾ - هڪ statspack تيار ڪري ٿو، يا awr-snapshots (جيڪو تيار ڪيو وڃي ٿو).
بهرحال، اهو ظاهر ٿيو ته 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;
هڪ شخص جيڪو Oracle ڊيٽابيس کي برقرار رکڻ ۾ تجربو رکي ٿو اهو اڳ ۾ ئي چئي سگهي ٿو ته ڇا ۽ ڪهڙا قدر مقرر ڪيا وڃن، مخصوص پيٽرولر ۽ انهن جي قابل قبول قدرن مان، ڊيٽا سان گڏ ڪم ڪرڻ لاءِ ڊيٽابيس جي وڌيڪ پيداوار حاصل ڪرڻ لاءِ. اپليڪيشن ڪوڊ، هتي مٿي.
پر.
ليبارٽري جي ڪم جو نقطو اهو ڏيکارڻ آهي ته اصلاح الورورٿم پاڻ اسان لاء نسبتا جلدي واضح ڪندو.
اسان لاءِ، باقي اهو آهي ته دستاويز کي ڏسڻ لاءِ، حسب ضرورت سسٽم ذريعي، بس اهو معلوم ڪرڻ لاءِ ڪافي آهي ته ڪهڙن پيٽرولن کي تبديل ڪرڻو آهي ۽ ڪهڙين حدن ۾.
۽ پڻ: ڪوڊ ڪوڊ جيڪو ڪم ڪرڻ لاء استعمال ڪيو ويندو ڪسٽم سسٽم جي چونڊيل اصلاح الورورٿم سان.
پوء، هاڻي ڪوڊ جي باري ۾.
مون مٿي ذڪر ڪيو آهي cran-r، يعني: ڪسٽمائيز سسٽم سان گڏ سڀ ڌانڌليون آر اسڪرپٽ جي صورت ۾ ترتيب ڏنل آهن.
اصل ڪم، تجزيو، چونڊ ميٽرڪ ويليو، سسٽم اسٽيٽ ویکٹر: هي هڪ پيڪيج آهي GA ()
پيڪيج، هن معاملي ۾، بلڪل مناسب نه آهي، ان لحاظ کان ته اهو ویکٹر (ڪروموزوم، جيڪڏهن پيڪيج جي لحاظ کان) جي توقع رکي ٿو ته انگن جي تارن جي شڪل ۾ هڪ جزوي حصو سان.
۽ منهنجو ویکٹر، سيٽنگ جي قيمتن جي قيمتن مان: اهي 14 مقدار آهن - انٽيجرز ۽ اسٽرنگ ويلز.
مسئلو، يقينا، آساني سان ڪجهه مخصوص نمبرن کي اسٽرنگ جي قيمتن کي تفويض ڪرڻ کان بچي وڃي ٿو.
اهڙيء طرح، آخر ۾، آر اسڪرپٽ جو مکيه ٽڪرو هن طرح ڏسڻ ۾ اچي ٿو:
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 subroutine خاصيتون ga بنيادي طور تي، ڳولا جي جڳهه جو هڪ علائقو بيان ڪيو ويو آهي، جنهن جي اندر هڪ اهڙي ویکٹر (يا ویکٹرز) جي ڳولا ڪئي ويندي جنهن لاء فٽنيس فنڪشن جي وڌ ۾ وڌ قيمت حاصل ڪئي ويندي.
ga subroutine فٽنيس فنڪشن کي وڌائڻ لاءِ ڳولا ڪري ٿو.
خير، پوء، اهو ظاهر ٿئي ٿو ته، هن صورت ۾، ضروري آهي ته فٽنيس فنڪشن، ویکٹر کي سمجھڻ جي قيمت جي هڪ سيٽ جي طور تي subd جي ڪجهه پيٽرولن لاء، subd مان هڪ ميٽرڪ حاصل ڪري.
اهو آهي: ڪيترا، ڏنل ذيلي سيٽ اپ سان ۽ سب ڊي تي ڏنل لوڊ: ذيلي پروسيس ٽرانزيڪشن في سيڪنڊ.
اھو آھي، جڏھن پڌرو ڪيو وڃي، ھيٺ ڏنل گھڻن قدمن کي فٽنيس فنڪشن اندر انجام ڏيڻ گھرجي:
- انگن جي ان پٽ ویکٹر کي پروسيس ڪري رهيو آهي - ان کي ذيلي ڊيٽا پيٽرولر جي قدرن ۾ تبديل ڪرڻ.
- هڪ ڏنل سائيز جي ٻيهر گروپن جو هڪ ڏنل تعداد ٺاهڻ جي ڪوشش. ان کان سواء، ڪوشش ناڪام ٿي سگهي ٿي.
ميگزين جا گروپ جيڪي اڳ ۾ ئي موجود هئا ذيلي ذيلي، ڪجهه مقدار ۾ ۽ ڪجهه سائيز ۾، تجربي جي پاڪائي لاءِ - d.b. حذف ٿيل - جيڪڏهن پوئين نقطو ڪامياب آهي: ڊيٽابيس کي ترتيب ڏيڻ جي پيٽرولن جي قيمتن کي بيان ڪرڻ (ٻيهر: اتي هڪ ناڪامي ٿي سگهي ٿي)
- جيڪڏهن اڳوڻو قدم ڪامياب آهي: سب ڊي کي روڪيو، ذيلي کي شروع ڪيو وڃي ته جيئن نئين بيان ڪيل پيٽرولر قدر اثر انداز ٿئي. (ٻيهر: اتي هڪ خرابي ٿي سگهي ٿي)
- جيڪڏهن پوئين قدم ڪامياب آهي: لوڊ ٽيسٽ انجام ڏيو. 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)
}اهو. سڀ ڪم: فٽنيس فنڪشن ۾ ڪيو ويو.
ga-subroutine عمل ویکٹر، يا، وڌيڪ صحيح طور تي، ڪروموزوم.
جنهن ۾، اسان لاءِ سڀ کان اهم شيءِ آهي جينز سان ڪروموزوم جو انتخاب جنهن لاءِ فٽنيس فنڪشن وڏي قدر پيدا ڪري ٿو.
اهو، جوهر ۾، هڪ N-dimensional ڳولا واري جاءِ ۾ ویکٹر استعمال ڪندي ڪروموزوم جي بهترين سيٽ کي ڳولڻ جو عمل آهي.
بلڪل واضح، تفصيلي , R-code جي مثالن سان، جينياتي الگورتھم جو ڪم.
مان ٻه ٽيڪنيڪل نقطا الڳ الڳ نوٽ ڪرڻ چاهيندس.
فنڪشن مان معاون ڪالون evaluate، مثال طور، اسٽاپ-شروع، سيٽنگ قيمت جي ذيلي پيٽرولر، جي بنياد تي انجام ڏنو ويو آهي cran-r افعال system2
جنهن جي مدد سان: ڪي بيش اسڪرپٽ يا ڪمانڊ سڏجي ٿو.
مثال طور
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 تجزيو سمجھڻ لاءِ ته ڪھڙا خاصيتون (چڱو، ھن صورت ۾، ٽيوننگ ویکٹر جا جزا) ۽ اھي ميٽرڪ قدر کي ڪيترو متاثر ڪن ٿا.
۽ هن معلومات مان: سمجھو ته ڪهڙا عنصر متاثر ٿيا اھم خاصيتن ۾ تبديليون.
هلائي attribute-importance مختلف طريقن سان ممڪن آهي.
انهن مقصدن لاء، مون کي الورورٿم پسند آهي randomForest ساڳئي نالي جو آر پيڪيج ()
randomForest، جيئن مان سمجهان ٿو هن جي ڪم کي عام طور تي ۽ خاص طور تي خاصيتن جي اهميت کي جانچڻ لاءِ هن جو انداز، خاصيتن تي ردعمل متغير جي انحصار جو هڪ خاص نمونو ٺاهي ٿو.
اسان جي صورت ۾، جوابي متغير هڪ ميٽرڪ آهي جيڪو ڊيٽابيس مان لوڊ ٽيسٽ ۾ حاصل ڪيو ويو آهي: tps;
۽ خاصيتون ٽيوننگ ویکٹر جا حصا آھن.
سو هتي randomForest ٻن نمبرن سان هر ماڊل جي خاصيت جي اهميت جو اندازو لڳائي ٿو: %IncMSE - ڪيئن هڪ ماڊل ۾ هن خاصيت جي موجودگي/غير موجودگي هن ماڊل جي MSE معيار کي تبديل ڪري ٿي (ميان اسڪوائرڊ ايرر)؛
۽ IncNodePurity هڪ عدد آهي جيڪو ظاهر ڪري ٿو ته ڪيتري چڱيءَ طرح، هن وصف جي قدرن جي بنياد تي، مشاهدن سان گڏ هڪ ڊيٽا سيٽ کي ورهائي سگهجي ٿو، ته جيئن هڪ حصي ۾ ڊيٽا آهي جنهن جي هڪ قدر جي وضاحت ڪئي پئي وڃي، ۽ ٻئي ۾ ميٽرڪ جو ٻيو قدر.
خير، اهو آهي: ڪهڙي حد تائين اها درجه بندي خاصيت آهي (مون ڏٺو ته RandomForest تي سڀ کان وڌيڪ واضح، روسي-ٻولي جي وضاحت ).
لوڊ ٽيسٽ جي نتيجن سان گڏ ڊيٽا سيٽ جي پروسيسنگ لاءِ مزدور هاري آر ڪوڊ:
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توھان سڌو سنئون پنھنجي ھٿن سان الورورٿم جي هائپرپراميٽرز کي منتخب ڪري سگھو ٿا، ۽ ماڊل جي معيار تي ڌيان ڏئي، ھڪڙو نمونو چونڊيو جيڪو صحيح ڊيٽا سيٽ تي اڳڪٿيون وڌيڪ صحيح طور تي پورو ڪري.
توھان ھن ڪم لاءِ ڪجھ قسم جو فنڪشن لکي سگھو ٿا (رستي سان، وري، ڪنھن قسم جي اصلاح الورورٿم استعمال ڪندي).
توھان استعمال ڪري سگھو ٿا آر پيڪيج caret، نقطو اهم ناهي.
نتيجي طور، هن صورت ۾، هيٺ ڏنل نتيجو حاصل ڪيو ويو آهي خاصيتن جي اهميت جي درجي جو اندازو لڳائڻ لاء:
خير. اهڙيء طرح، اسان عالمي عڪاسي شروع ڪري سگهون ٿا:
- اهو ظاهر ٿئي ٿو ته سڀ کان اهم، انهن جانچ جي حالتن هيٺ، پيٽرولر هو
commit_wait
تخنيقي طور تي، اهو بيان ڪري ٿو io آپريشن جي عمل واري موڊ کي لکڻ جي ريڊو ڊيٽا کي subdb لاگ بفر کان موجوده لاگ گروپ ڏانهن: هم وقت سازي يا هم وقت ساز.
قدرnowaitجنهن جي نتيجي ۾ لڳ ڀڳ عمودي، ٽي پي ايس ميٽرڪ جي قيمت ۾ گھڻا واڌارو آهي: هي شامل آهي asynchronous io موڊ کي ريڊو گروپن ۾.
هڪ الڳ سوال اهو آهي ته ڇا توهان کي اهو ڪرڻ گهرجي فوڊ ڊيٽابيس ۾. هتي آئون پاڻ کي صرف بيان ڪرڻ تائين محدود ڪري ٿو: هي هڪ اهم عنصر آهي. - اهو منطقي آهي ته ذيلي ذيلي جي لاگ بفر جي سائيز: هڪ اهم عنصر ٿي سگهي ٿو.
لاگ بفر جي سائيز جيتري ننڍي هوندي، ان جي بفرنگ جي گنجائش گهٽ هوندي، اوترو ئي اهو اوور فلو ٿيندو ۽/يا ان ۾ نئين ريڊڪس ڊيٽا جي هڪ حصي لاءِ مفت ايريا مختص ڪرڻ جي ناڪامي.
هن جو مطلب آهي: دير سان لاڳاپيل جڳهه مختص ڪرڻ سان لاگ بفر ۾ ۽/يا ڊمپنگ ريڊو ڊيٽا ان مان ريڊو گروپن ۾.
اهي تاخير، يقينا، ٽرانزيڪشن لاءِ ڊيٽابيس جي ذريعي تي اثر انداز ٿيڻ گهرجن. - نيم
db_block_checksum: سٺو، پڻ، عام طور تي اهو واضح آهي - ٽرانزيڪشن پروسيسنگ ذيلي ڊيٽابيس جي بفر ڪيش ۾ ڊارٽي بلاڪ جي ٺهڻ جي ڪري ٿي.
جنهن ۾، جڏهن ڊيٽا بلاڪ جي چيڪسمس کي چيڪ ڪرڻ چالو ڪيو ويندو آهي، ڊيٽابيس کي پروسيس ڪرڻو پوندو آهي - انهن چيڪسمس کي ڊيٽابيس جي جسم مان ڳڻيو، انهن کي چيڪ ڪريو ته ڇا لکيو ويو آهي ڊيٽابيس جي هيڊر ۾: ميچز/ڏس نه ٿو ملي.
اهو ڪم، ٻيهر، ڊيٽا پروسيسنگ کي دير نه ٿو ڪري سگهي، ۽ ان جي مطابق، پيٽرولر ۽ ميکانيزم جيڪو هن پيٽرول کي سيٽ ڪري ٿو اهو اهم ٿي سگهي ٿو.
اهو ئي سبب آهي ته وينڊر پيش ڪري ٿو، هن پيراميٽر جي دستاويزن ۾، ان لاءِ مختلف قدر (پيراميٽر) ۽ نوٽ ڪري ٿو ته ها، اتي هڪ اثر ٿيندو، پر، چڱو، توهان مختلف قدر چونڊي سگهو ٿا، "آف" تائين ۽ مختلف اثرات.
خير، هڪ عالمي نتيجو.
اهو طريقو، عام طور تي، ڪافي ڪم ڪري رهيو آهي.
هو پاڻ کي اجازت ڏئي ٿو، هڪ خاص سروس سسٽم جي لوڊ ٽيسٽ جي شروعاتي مرحلن ۾، لوڊ لاء ان (سسٽم) کي بهتر ترتيب ڏيڻ لاء، لوڊ لاء سسٽم قائم ڪرڻ جي خاصيتن ۾ تمام گهڻو ڌيان نه ڏيڻ لاء.
پر اهو ان کي مڪمل طور تي خارج نٿو ڪري - گهٽ ۾ گهٽ سمجهه جي سطح تي: سسٽم کي لازمي طور تي ڄاڻڻ گهرجي "ايڊجسٽ ڪنبس" ۽ انهن knobs جي گردش جي جائز حدن بابت.
انهي طريقي سان نسبتا جلدي ڳولي سگهي ٿو بهتر سسٽم جي جوڙجڪ.
۽ جاچ جي نتيجن جي بنياد تي، اهو ممڪن آهي ته سسٽم جي ڪارڪردگي جي ماپ ۽ سسٽم جي سيٽنگن جي قيمتن جي قيمت جي وچ ۾ تعلق جي فطرت بابت معلومات حاصل ڪرڻ.
جيڪو، يقينا، سسٽم جي هن تمام گهڻي ڄاڻ جي ظاهر ٿيڻ ۾ مدد ڏيڻ گهرجي، ان جي آپريشن، گهٽ ۾ گهٽ هڪ ڏنل لوڊ هيٺ.
عملي طور تي، هي سسٽم جي اهڙي جاچ تيار ڪرڻ جي خرچن لاء ڪسٽمائيز سسٽم کي سمجهڻ جي قيمتن جي بدلي آهي.
مان الڳ الڳ نوٽ ڪرڻ چاهيان ٿو: هن طريقي ۾، آپريٽنگ حالتن ۾ سسٽم جي جانچ جي ڪافي حد تائين جيڪا تجارتي آپريشن ۾ هوندي، انتهائي اهم آهي.
توهان جي توجه ۽ وقت جي مهرباني.
جو ذريعو: www.habr.com