خوش
میں نے اپنی تلاش کا اشتراک کرنے کا فیصلہ کیا - سوچ، آزمائش اور غلطی کا پھل۔
مجموعی طور پر: یہ کوئی تلاش نہیں ہے، یقیناً - یہ سب کچھ ان لوگوں کو ایک طویل عرصے سے معلوم ہونا چاہیے تھا جو لاگو شماریاتی ڈیٹا پروسیسنگ اور کسی بھی سسٹم کی اصلاح میں ملوث ہیں، ضروری نہیں کہ خاص طور پر ڈی بی ایم ایس۔
اور: ہاں، وہ جانتے ہیں، وہ اپنی تحقیق پر دلچسپ مضامین لکھتے ہیں، (UPD.: تبصروں میں انہوں نے ایک بہت ہی دلچسپ منصوبے کی نشاندہی کی: )
دوسری طرف: مجھے انٹرنیٹ پر آئی ٹی ماہرین، ڈی بی اے کے درمیان اس نقطہ نظر کا وسیع پیمانے پر ذکر یا پھیلاؤ نظر نہیں آتا۔
تو، نقطہ پر.
آئیے فرض کریں کہ ہمارے پاس ایک کام ہے: کسی قسم کے کام کی خدمت کے لیے ایک مخصوص سروس سسٹم قائم کرنا۔
اس کام کے بارے میں معلوم ہے کہ یہ کیا ہے، اس کام کے معیار کو کیسے ماپا جاتا ہے، اور اس معیار کی پیمائش کا معیار کیا ہے۔
آئیے یہ بھی مان لیں کہ یہ کم و بیش جانا جاتا ہے اور سمجھا جاتا ہے: بالکل اس سروس سسٹم میں (یا اس کے ساتھ) کام کیسے ہوتا ہے۔
"زیادہ یا کم" - اس کا مطلب یہ ہے کہ ایک مخصوص ٹول، افادیت، سروس تیار کرنا (یا اسے کہیں سے حاصل کرنا) ممکن ہے جس کی ترکیب سازی کی جا سکتی ہے اور اس سسٹم پر لاگو کیا جا سکتا ہے جس کے ٹیسٹ لوڈ کے ساتھ کافی حد تک پیداوار میں کیا جائے گا، پیداوار میں کام کرنے کے لیے کافی حالات میں۔
ٹھیک ہے، آئیے فرض کریں کہ اس سروس سسٹم کے لیے ایڈجسٹمنٹ پیرامیٹرز کا ایک سیٹ معلوم ہے، جو اس سسٹم کو اس کے کام کی پیداواری صلاحیت کے لحاظ سے ترتیب دینے کے لیے استعمال کیا جا سکتا ہے۔
اور مسئلہ کیا ہے - اس سروس سسٹم کے بارے میں کافی حد تک مکمل فہم نہیں ہے، جو کہ آپ کو کسی مخصوص پلیٹ فارم پر مستقبل کے بوجھ کے لیے اس سسٹم کی سیٹنگز کو مہارت کے ساتھ ترتیب دینے اور سسٹم کی مطلوبہ پیداواری صلاحیت حاصل کرنے کی اجازت دیتا ہے۔
ٹھیک ہے. تقریباً ہمیشہ ایسا ہی ہوتا ہے۔
آپ یہاں کیا کر سکتے ہیں؟
ٹھیک ہے، ذہن میں آنے والی پہلی چیز اس سسٹم کے لیے دستاویزات کو دیکھنا ہے۔ سمجھیں کہ ایڈجسٹمنٹ پیرامیٹرز کی قدروں کے لیے قابل قبول رینجز کیا ہیں۔ اور، مثال کے طور پر، کوآرڈینیٹ ڈیسنٹ طریقہ کا استعمال کرتے ہوئے، ٹیسٹ میں سسٹم کے پیرامیٹرز کے لیے قدریں منتخب کریں۔
وہ. نظام کو اس کے کنفیگریشن پیرامیٹرز کے لیے قدروں کے مخصوص سیٹ کی شکل میں کسی قسم کی ترتیب دیں۔
اس ٹول یوٹیلیٹی، لوڈ جنریٹر کا استعمال کرتے ہوئے اس پر ایک ٹیسٹ لوڈ لگائیں۔
اور قدر کو دیکھیں - ردعمل، یا نظام کے معیار کا ایک میٹرک۔
دوسری سوچ کا نتیجہ یہ نکل سکتا ہے کہ یہ بہت طویل وقت ہے۔
ٹھیک ہے، وہ یہ ہے کہ: اگر سیٹنگ کے بہت سارے پیرامیٹرز ہیں، اگر ان کی اقدار کی حدیں بڑی ہیں، اگر ہر انفرادی لوڈ ٹیسٹ کو مکمل ہونے میں کافی وقت لگتا ہے، تو: ہاں، یہ سب کچھ ناقابل قبول حد تک لگ سکتا ہے۔ طویل وقت
ٹھیک ہے، یہ ہے جو آپ سمجھ سکتے ہیں اور یاد کر سکتے ہیں۔
آپ یہ جان سکتے ہیں کہ سروس سسٹم سیٹنگ پیرامیٹرز کی اقدار کے سیٹ میں کچھ اقدار کی ترتیب کے طور پر ایک ویکٹر ہوتا ہے۔
ہر اس طرح کا ویکٹر، دوسری چیزیں برابر ہونے کی وجہ سے (اس وجہ سے کہ یہ اس ویکٹر سے متاثر نہیں ہوتا ہے)، میٹرک کی مکمل طور پر متعین قدر سے مساوی ہے - ایک ٹیسٹ بوجھ کے تحت سسٹم کے آپریشن کے معیار کا اشارہ۔
یعنی۔
آئیے ہم سسٹم کنفیگریشن ویکٹر کو بطور اشارہ کرتے ہیں۔ 
جہاں ; کہاں - سسٹم کنفیگریشن پیرامیٹرز کی تعداد، ان میں سے کتنے پیرامیٹرز ہیں۔
اور اس سے متعلقہ میٹرک کی قدر کے طور پر اس کی نشاندہی کرتے ہیں
، پھر ہمیں ایک فنکشن ملتا ہے:
ٹھیک ہے، پھر: میرے معاملے میں، سب کچھ فوری طور پر نیچے آتا ہے: میرے طالب علمی کے زمانے سے تقریباً بھول گیا، فنکشن کی انتہا کو تلاش کرنے کے الگورتھم۔
ٹھیک ہے، لیکن یہاں ایک تنظیمی اور لاگو سوال پیدا ہوتا ہے: کون سا الگورتھم استعمال کرنا ہے۔
- معنوں میں - تاکہ آپ ہاتھ سے کم کوڈ کرسکیں۔
- اور اس کے کام کرنے کے لیے، یعنی extremum ملا (اگر کوئی ہے)، ٹھیک ہے، کم از کم کوآرڈینیٹ ڈیسنٹ سے زیادہ تیز۔
پہلا نکتہ اشارہ کرتا ہے کہ ہمیں کچھ ایسے ماحول کی طرف دیکھنے کی ضرورت ہے جن میں اس طرح کے الگورتھم پہلے ہی لاگو کیے جا چکے ہیں، اور کسی نہ کسی شکل میں، کوڈ میں استعمال کے لیے تیار ہیں۔
ٹھیک ہے، میں جانتا ہوں python и cran-r
دوسرے نکتے کا مطلب یہ ہے کہ آپ کو الگورتھم کے بارے میں خود پڑھنا ہوگا، وہ کیا ہیں، ان کی ضروریات کیا ہیں، اور ان کے کام کی خصوصیات۔
اور جو کچھ وہ دیتے ہیں وہ مفید ضمنی اثرات ہوسکتے ہیں - نتائج، یا براہ راست الگورتھم سے۔
یا وہ الگورتھم کے نتائج سے حاصل کیے جا سکتے ہیں۔
بہت کچھ ان پٹ کی شرائط پر منحصر ہے۔
مثال کے طور پر، اگر، کسی وجہ سے، آپ کو تیزی سے نتیجہ حاصل کرنے کی ضرورت ہے، ٹھیک ہے، آپ کو گریڈینٹ ڈیسنٹ الگورتھم کی طرف دیکھنا ہوگا اور ان میں سے ایک کا انتخاب کرنا ہوگا۔
یا، اگر وقت اتنا اہم نہیں ہے، تو آپ، مثال کے طور پر، سٹاکسٹک آپٹیمائزیشن کے طریقے استعمال کر سکتے ہیں، جیسے کہ جینیاتی الگورتھم۔
میں اس نقطہ نظر کے کام پر غور کرنے کی تجویز کرتا ہوں، نظام کی ترتیب کو منتخب کرتے ہوئے، جینیاتی الگورتھم کا استعمال کرتے ہوئے، اگلے میں، تو بات کریں: لیبارٹری کا کام۔
اصل:
- ایک سروس سسٹم کے طور پر ہونے دو:
oracle xe 18c - اسے لین دین کی سرگرمی اور مقصد کو پورا کرنے دیں: لین دین/سیکنڈ میں سب ڈیٹا بیس کا سب سے زیادہ ممکنہ تھرو پٹ حاصل کرنا۔
- ڈیٹا کے ساتھ کام کرنے کی نوعیت اور کام کے تناظر میں لین دین بہت مختلف ہو سکتے ہیں۔
آئیے اس بات سے اتفاق کرتے ہیں کہ یہ وہ لین دین ہیں جو ٹیبلر ڈیٹا کی ایک بڑی مقدار پر کارروائی نہیں کرتے ہیں۔
اس معنی میں کہ وہ دوبارہ کرنے سے زیادہ انڈو ڈیٹا تیار نہیں کرتے ہیں اور قطاروں اور بڑی میزوں کے بڑے فیصد پر کارروائی نہیں کرتے ہیں۔
یہ وہ لین دین ہیں جو کم و بیش بڑے ٹیبل میں ایک قطار کو تبدیل کرتے ہیں، اس ٹیبل پر انڈیکس کی ایک چھوٹی تعداد کے ساتھ۔
اس صورت حال میں: لین دین کی پروسیسنگ کے لیے ذیلی ڈیٹا بیس کی پیداواری صلاحیت، ریزرویشن کے ساتھ، ریڈوکس ڈیٹا بیس کے ذریعے پروسیسنگ کے معیار سے طے کی جائے گی۔
ڈس کلیمر - اگر ہم خاص طور پر سب ڈی بی سیٹنگز کے بارے میں بات کرتے ہیں۔
کیونکہ، عام صورت میں، مثال کے طور پر، SQL سیشنز کے درمیان ٹرانزیکشنل لاک ہو سکتے ہیں، ٹیبلر ڈیٹا اور/یا ٹیبلر ماڈل کے ساتھ صارف کے کام کے ڈیزائن کی وجہ سے۔
جس کا، یقیناً، TPS میٹرک پر افسردہ کرنے والا اثر پڑے گا اور یہ سب ڈیٹا بیس کی نسبت ایک خارجی عنصر ہو گا: ٹھیک ہے، ٹیبلر ماڈل کو اس طرح ڈیزائن کیا گیا تھا اور اس میں ڈیٹا کے ساتھ کام جو کہ رکاوٹیں واقع ہوتی ہیں۔
لہذا، تجربے کی پاکیزگی کے لئے، ہم اس عنصر کو خارج کردیں گے، اور ذیل میں میں واضح کروں گا کہ کس طرح.
- آئیے، یقینی طور پر، فرض کریں کہ ڈیٹا بیس میں جمع کردہ ایس کیو ایل کمانڈز میں سے 100٪ ڈی ایم ایل کمانڈز ہیں۔
سب ڈیٹا بیس کے ساتھ صارف کے کام کرنے کی خصوصیات کو ٹیسٹوں میں ایک جیسا رہنے دیں۔
یعنی: skl سیشنز کی تعداد، ٹیبلولر ڈیٹا، skl سیشن ان کے ساتھ کیسے کام کرتے ہیں۔ - سب ڈی میں کام کرتا ہے۔
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 - اپنی ڈیفالٹ تعیناتی میں - اس طرح کے تنازعات سے محفوظ ہے۔
یہ اعلان: مماثل ہے، یہ ہے۔
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"وہ. ہر کارکن کے لیے (عملی طور پر: ڈی بی میں ایک الگ ایس کیو ایل سیشن) ایک علیحدہ ٹیبل بنایا جاتا ہے، جس کے ساتھ کارکن کام کرتا ہے۔
یہ ورکر سیشنز کے درمیان لین دین کے تالے کی عدم موجودگی کو یقینی بناتا ہے۔
ہر کارکن: ایک ہی کام کرتا ہے، اپنی میز کے ساتھ، میزیں سب ایک جیسی ہیں۔
تمام کارکن ایک ہی وقت کے لیے کام کرتے ہیں۔
مزید یہ کہ، کافی لمبے عرصے کے لیے تاکہ، مثال کے طور پر، ایک لاگ سوئچ یقینی طور پر واقع ہو، اور ایک سے زیادہ بار۔
ٹھیک ہے، اس کے مطابق، متعلقہ اخراجات اور اثرات پیدا ہوئے.
میرے معاملے میں، میں نے کارکنوں کے کام کا دورانیہ 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، یعنی: اپنی مرضی کے مطابق نظام کے ساتھ تمام ہیرا پھیری کو آر اسکرپٹ کی شکل میں ترتیب دیا گیا ہے۔
اصل کام، تجزیہ، میٹرک ویلیو کے لحاظ سے انتخاب، سسٹم اسٹیٹ ویکٹر: یہ ایک پیکیج ہے۔ 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 subroutine فٹنس فنکشن کو زیادہ سے زیادہ تلاش کرتا ہے۔
ٹھیک ہے، پھر، یہ پتہ چلتا ہے کہ، اس صورت میں، یہ ضروری ہے کہ فٹنس فنکشن، subd کے مخصوص پیرامیٹرز کے لیے ویکٹر کو اقدار کے ایک سیٹ کے طور پر سمجھے، subd سے ایک میٹرک حاصل کرے۔
یعنی: کتنے، دیئے گئے ذیلی سیٹ اپ کے ساتھ اور ذیلی پر دیئے گئے بوجھ کے ساتھ: subd فی سیکنڈ لین دین پر عمل کرتا ہے۔
یعنی، کھولتے وقت، فٹنس فنکشن کے اندر درج ذیل ملٹی سٹیپ کو انجام دینا ضروری ہے:
- نمبروں کے ان پٹ ویکٹر پر کارروائی کرنا - اسے ذیلی ڈیٹا پیرامیٹرز کی قدروں میں تبدیل کرنا۔
- دیے گئے سائز کے ریڈو گروپس کی ایک دی گئی تعداد کو بنانے کی کوشش۔ مزید یہ کہ کوشش ناکام ہو سکتی ہے۔
میگزین گروپس جو پہلے سے ہی ذیل میں موجود تھے، کچھ مقدار میں اور کچھ سائز کے، تجربے کی پاکیزگی کے لیے - d.b. حذف کر دیا گیا - اگر پچھلا نقطہ کامیاب ہے: ڈیٹا بیس میں کنفیگریشن پیرامیٹرز کی قدروں کی وضاحت کرنا (دوبارہ: ناکامی ہو سکتی ہے)
- اگر پچھلا مرحلہ کامیاب ہے: 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)
}وہ. تمام کام: فٹنس فنکشن میں انجام دیا گیا۔
ga-subroutine ویکٹر، یا، زیادہ درست طریقے سے، کروموسوم پر عمل کرتا ہے۔
جس میں، ہمارے لیے جو چیز سب سے اہم ہے وہ ہے جینز کے ساتھ کروموسوم کا انتخاب جس کے لیے فٹنس فنکشن بڑی قدریں پیدا کرتا ہے۔
یہ، جوہر میں، N-dimensional تلاش کی جگہ میں ویکٹر کا استعمال کرتے ہوئے کروموسوم کے بہترین سیٹ کو تلاش کرنے کا عمل ہے۔
بہت واضح، مفصل R-code کی مثالوں کے ساتھ، ایک جینیاتی الگورتھم کا کام۔
میں الگ سے دو تکنیکی نکات نوٹ کرنا چاہوں گا۔
فنکشن سے معاون کالز evaluate، مثال کے طور پر، سٹاپ اسٹارٹ، ذیلی پیرامیٹر کی قدر کو ترتیب دینا، کی بنیاد پر انجام دیا جاتا ہے۔ cran-r افعال system2
جس کی مدد سے: کچھ bash اسکرپٹ یا کمانڈ کہا جاتا ہے۔
مثال کے طور پر:
سیٹ_ڈی بی_پیرامیٹر
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-algorithm، کروموسوم ویکٹرز کے ذریعے چھانٹنا: covered۔
منحنی اقدار کی کافی زور دار حرکیات کو دیکھتے ہوئے، کم از کم ایک اور عنصر ہے جو کہ نمایاں طور پر چھوٹا ہونے کے باوجود اثر رکھتا ہے۔
یہ وہ جگہ ہے جہاں آپ کو اس کی ضرورت ہے۔ attribute-importance تجزیہ یہ سمجھنے کے لیے کہ کون سی صفات (اچھی طرح سے، اس معاملے میں، ٹیوننگ ویکٹر کے اجزاء) اور وہ میٹرک ویلیو کو کتنا متاثر کرتے ہیں۔
اور اس معلومات سے: سمجھیں کہ اہم صفات میں تبدیلیوں سے کن عوامل متاثر ہوئے۔
چلائیں attribute-importance مختلف طریقوں سے ممکن ہے.
ان مقاصد کے لیے، مجھے الگورتھم پسند ہے۔ randomForest اسی نام کا R پیکیج ()
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آپ اپنے ہاتھوں سے الگورتھم کے ہائپر پیرامیٹرز کو براہ راست منتخب کر سکتے ہیں اور ماڈل کے معیار پر توجہ مرکوز کرتے ہوئے ایک ایسا ماڈل منتخب کر سکتے ہیں جو توثیق کے ڈیٹاسیٹ کی پیشین گوئیوں کو زیادہ درست طریقے سے پورا کرتا ہو۔
آپ اس کام کے لیے کسی قسم کا فنکشن لکھ سکتے ہیں (ویسے، دوبارہ، کسی قسم کی اصلاحی الگورتھم کا استعمال کرتے ہوئے)۔
آپ R پیکج استعمال کر سکتے ہیں۔ caret، نکتہ اہم نہیں ہے۔
نتیجے کے طور پر، اس صورت میں، صفات کی اہمیت کا اندازہ لگانے کے لیے درج ذیل نتیجہ حاصل کیا جاتا ہے:
ٹھیک ہے. اس طرح، ہم عالمی عکاسی شروع کر سکتے ہیں:
- یہ پتہ چلتا ہے کہ سب سے اہم، ان جانچ کے حالات کے تحت، پیرامیٹر تھا
commit_wait
تکنیکی طور پر، یہ سب ڈی بی لاگ بفر سے موجودہ لاگ گروپ میں ریڈو ڈیٹا لکھنے کے io آپریشن کے ایگزیکیوشن موڈ کی وضاحت کرتا ہے: ہم وقت ساز یا غیر مطابقت پذیر۔
ویلیوnowaitجس کا نتیجہ تقریباً عمودی، tps میٹرک کی قدر میں متعدد اضافہ کی صورت میں نکلتا ہے: یہ ریڈو گروپس میں غیر مطابقت پذیر io موڈ کی شمولیت ہے۔
ایک الگ سوال یہ ہے کہ آیا آپ کو یہ کام فوڈ ڈیٹا بیس میں کرنا چاہیے یا نہیں۔ یہاں میں اپنے آپ کو صرف یہ بتانے تک محدود رکھتا ہوں: یہ ایک اہم عنصر ہے۔ - یہ منطقی ہے کہ subd: کے لاگ بفر کا سائز ایک اہم عنصر ثابت ہوتا ہے۔
لاگ بفر کا سائز جتنا چھوٹا ہوگا، اس کی بفرنگ کی گنجائش اتنی ہی کم ہوگی، یہ اتنا ہی زیادہ بہہ جائے گا اور/یا نئے ریڈوکس ڈیٹا کے ایک حصے کے لیے اس میں خالی جگہ مختص کرنے میں ناکامی ہوگی۔
اس کا مطلب ہے: لاگ بفر میں جگہ مختص کرنے اور/یا اس سے ریڈو ڈیٹا کو دوبارہ گروپوں میں ڈمپ کرنے سے وابستہ تاخیر۔
یہ تاخیر، یقیناً، لین دین کے لیے ڈیٹا بیس کے تھرو پٹ کو متاثر کرتی ہے اور کرتی ہے۔ - پیرامیٹر
db_block_checksum: ٹھیک ہے، عام طور پر یہ بھی واضح ہے - ٹرانزیکشن پروسیسنگ سب ڈیٹا بیس کے بفر کیشے میں ڈارٹی بلاکس کی تشکیل کا باعث بنتی ہے۔
جس میں، جب ڈیٹا بلاکس کے چیک سمز کی جانچ پڑتال کو فعال کیا جاتا ہے، ڈیٹا بیس کو پروسیس کرنا پڑتا ہے - ڈیٹا بلاک کے جسم سے ان چیکسم کا حساب لگائیں، ان کو چیک کریں کہ ڈیٹا بلاک ہیڈر میں کیا لکھا ہے: میچز/مماثل نہیں ہیں۔
اس طرح کا کام، دوبارہ، ڈیٹا پروسیسنگ میں تاخیر نہیں کر سکتا، اور اس کے مطابق، پیرامیٹر اور طریقہ کار جو اس پیرامیٹر کو متعین کرتا ہے، اہم ثابت ہوتا ہے۔
اس لیے وینڈر اس پیرامیٹر کے لیے دستاویزات میں، مختلف اقدار اور نوٹ پیش کرتا ہے کہ ہاں، ایک اثر پڑے گا، لیکن آپ مختلف قدروں کا انتخاب کر سکتے ہیں، یہاں تک کہ "آف" اور مختلف اثرات۔
ٹھیک ہے، ایک عالمی نتیجہ.
نقطہ نظر، عام طور پر، کافی کام کر رہا ہے.
وہ خود کو کسی خاص سروس سسٹم کی لوڈ ٹیسٹنگ کے ابتدائی مراحل میں، اس کی (سسٹم) کو لوڈ کے لیے بہترین کنفیگریشن کا انتخاب کرنے کی اجازت دیتا ہے، نہ کہ بوجھ کے لیے سسٹم کو ترتیب دینے کی تفصیلات میں بہت زیادہ غور و فکر کرنے کے لیے۔
لیکن یہ اسے مکمل طور پر خارج نہیں کرتا ہے - کم از کم فہم کی سطح پر: سسٹم کو "ایڈجسٹمنٹ نوبز" اور ان نوبس کی گردش کی قابل اجازت حدود کے بارے میں معلوم ہونا چاہیے۔
نقطہ نظر اس کے بعد نسبتا تیزی سے زیادہ سے زیادہ نظام کی ترتیب کو تلاش کر سکتا ہے.
اور جانچ کے نتائج کی بنیاد پر، سسٹم کی کارکردگی کے میٹرکس اور سسٹم سیٹنگ کے پیرامیٹرز کی اقدار کے درمیان تعلق کی نوعیت کے بارے میں معلومات حاصل کرنا ممکن ہے۔
جو، یقیناً، کم از کم ایک دیے گئے بوجھ کے تحت، اس نظام، اس کے آپریشن کے بارے میں اس بہت گہری تفہیم کے ابھرنے میں حصہ ڈالنا چاہیے۔
عملی طور پر، یہ نظام کی اس طرح کی جانچ کی تیاری کے اخراجات کے لیے حسب ضرورت نظام کو سمجھنے کے اخراجات کا تبادلہ ہے۔
میں الگ سے نوٹ کرنا چاہوں گا: اس نقطہ نظر میں، آپریٹنگ حالات کے لیے سسٹم ٹیسٹنگ کی کافی حد تک جو اس کے تجارتی آپریشن میں ہوں گے، انتہائی اہم ہے۔
آپ کی توجہ اور وقت کا شکریہ۔
ماخذ: www.habr.com