مرحبا
قررت أن أشارك اكتشافي - ثمرة الفكر والتجربة والخطأ.
بشكل عام: هذا ليس اكتشافًا بالطبع - كل هذا كان ينبغي أن يكون معروفًا لفترة طويلة لأولئك الذين يشاركون في معالجة البيانات الإحصائية التطبيقية وتحسين أي أنظمة، وليس بالضرورة نظام إدارة قواعد البيانات على وجه التحديد.
و: نعم، إنهم يعلمون، أنهم يكتبون مقالات مثيرة للاهتمام حول أبحاثهم، (محدث: في التعليقات أشاروا إلى مشروع مثير للاهتمام للغاية: )
من ناحية أخرى: لا أرى أي ذكر أو نشر لهذا النهج على الإنترنت على نطاق واسع بين متخصصي تكنولوجيا المعلومات، DBA.
لذا ، إلى هذه النقطة.
لنفترض أن لدينا مهمة: إعداد نظام خدمة معين لخدمة نوع ما من العمل.
ومن المعروف عن هذا العمل: ما هو، وكيف يتم قياس جودة هذا العمل، وما هو معيار قياس هذه الجودة.
لنفترض أيضًا أنه معروف ومفهوم إلى حد ما: بالضبط كيف يتم تنفيذ العمل في (أو مع) نظام الخدمة هذا.
"أكثر أو أقل" - هذا يعني أنه من الممكن إعداد (أو الحصول عليها من مكان ما) أداة أو أداة مساعدة أو خدمة معينة يمكن تجميعها وتطبيقها على النظام من خلال حمل اختباري مناسب بما يكفي لما سيكون في الإنتاج، في ظروف كافية للعمل في الإنتاج.
حسنًا، لنفترض أن مجموعة من معلمات الضبط لنظام الخدمة هذا معروفة، والتي يمكن استخدامها لتكوين هذا النظام من حيث إنتاجية عمله.
وما هي المشكلة - لا يوجد فهم كامل بما فيه الكفاية لنظام الخدمة هذا، وهو ما يسمح لك بتكوين إعدادات هذا النظام بخبرة للتحميل المستقبلي على منصة معينة والحصول على الإنتاجية المطلوبة للنظام.
حسنًا. وهذا هو الحال دائمًا تقريبًا.
ماذا يمكنك ان تفعل هنا؟
حسنًا، أول ما يتبادر إلى ذهنك هو إلقاء نظرة على الوثائق الخاصة بهذا النظام. افهم ما هي النطاقات المقبولة لقيم معلمات التعديل. وعلى سبيل المثال، باستخدام طريقة النسب الإحداثي، حدد قيم معلمات النظام في الاختبارات.
أولئك. إعطاء النظام نوعًا من التكوين، في شكل مجموعة محددة من القيم لمعلمات التكوين الخاصة به.
قم بتطبيق حمل اختباري عليه باستخدام أداة التحميل هذه.
وانظر إلى القيمة - الاستجابة، أو مقياس جودة النظام.
قد تكون الفكرة الثانية هي الاستنتاج بأن هذا وقت طويل جدًا.
حسنًا، هذا يعني: إذا كان هناك الكثير من معلمات الإعداد، وإذا كانت نطاقات قيمها التي يتم تشغيلها كبيرة، وإذا استغرق كل اختبار تحميل فردي وقتًا طويلاً لإكماله، فحينئذٍ: نعم، كل هذا قد يستغرق وقتًا غير مقبول منذ وقت طويل.
حسنًا، إليك ما يمكنك فهمه وتذكره.
يمكنك معرفة أنه في مجموعة قيم معلمات إعدادات نظام الخدمة يوجد متجه كتسلسل لبعض القيم.
كل متجه من هذا القبيل، مع تساوي الأشياء الأخرى (من حيث أنه لا يتأثر بهذا المتجه)، يتوافق مع قيمة محددة تمامًا للمقياس - وهو مؤشر لجودة تشغيل النظام تحت حمل الاختبار.
أي
دعونا نشير إلى ناقل تكوين النظام كـ 
حيث ; أين — عدد معلمات تكوين النظام، وكم عدد هذه المعلمات الموجودة.
وقيمة المقياس المقابل لذلك دعونا نشير إليها كما
، ثم نحصل على وظيفة:
حسنًا، إذًا: كل شيء يتلخص على الفور، في حالتي: لقد نسيت تقريبًا منذ أيام دراستي، خوارزميات البحث عن الحد الأقصى للدالة.
حسنًا، ولكن هنا يطرح سؤال تنظيمي وتطبيقي: ما هي الخوارزمية التي يجب استخدامها؟
- بمعنى - حتى تتمكن من ترميز أقل يدويًا.
- ولكي يعمل، أي. وجدت الحد الأقصى (إذا كان هناك واحد)، حسنًا، على الأقل أسرع من النسب الإحداثي.
تشير النقطة الأولى إلى أننا بحاجة إلى النظر إلى بعض البيئات التي تم فيها تنفيذ مثل هذه الخوارزميات بالفعل، وتكون جاهزة للاستخدام في التعليمات البرمجية بشكل ما.
حسنا انا اعلم python и cran-r
النقطة الثانية تعني أنك بحاجة إلى القراءة عن الخوارزميات نفسها، وما هي، وما هي متطلباتها، وميزات عملها.
وما يقدمونه يمكن أن يكون آثارًا جانبية مفيدة - نتائج، أو مباشرة من الخوارزمية نفسها.
أو يمكن الحصول عليها من نتائج الخوارزمية.
يعتمد الكثير على ظروف الإدخال.
على سبيل المثال، إذا كنت بحاجة، لسبب ما، إلى الحصول على نتيجة بشكل أسرع، حسنًا، فأنت بحاجة إلى النظر إلى خوارزميات النسب التدرجي واختيار واحدة منها.
أو، إذا لم يكن الوقت مهمًا جدًا، فيمكنك، على سبيل المثال، استخدام أساليب التحسين العشوائية، مثل الخوارزمية الجينية.
أقترح النظر في عمل هذا النهج، واختيار تكوين النظام، باستخدام الخوارزمية الجينية، في العمل التالي، إذا جاز التعبير: العمل المختبري.
مبدئي:
- فليكن، كنظام خدمة:
oracle xe 18c - دعها تخدم نشاط المعاملات والهدف: الحصول على أعلى إنتاجية ممكنة لقاعدة البيانات الفرعية، في المعاملات/ثانية.
- يمكن أن تكون المعاملات مختلفة تمامًا في طبيعة العمل مع البيانات وسياق العمل.
دعنا نتفق على أن هذه معاملات لا تعالج كمية كبيرة من البيانات الجدولية.
بمعنى أنها لا تولد بيانات تراجع أكثر من الإعادة ولا تعالج نسبًا كبيرة من الصفوف والجداول الكبيرة.
هذه هي المعاملات التي تغير صفًا واحدًا في جدول كبير إلى حد ما، مع وجود عدد صغير من الفهارس في هذا الجدول.
في هذه الحالة: سيتم تحديد إنتاجية قاعدة البيانات الفرعية لمعالجة المعاملات، مع الحجز، من خلال جودة المعالجة بواسطة قاعدة بيانات الأكسدة والاختزال.
إخلاء المسؤولية - إذا تحدثنا تحديدًا عن إعدادات قاعدة البيانات الفرعية.
لأنه، في الحالة العامة، قد يكون هناك، على سبيل المثال، أقفال معاملات بين جلسات SQL، وذلك بسبب تصميم عمل المستخدم مع البيانات الجدولية و/أو النموذج الجدولي.
والذي، بالطبع، سيكون له تأثير محبط على مقياس TPS وسيكون هذا عاملاً خارجيًا، بالنسبة لقاعدة البيانات الفرعية: حسنًا، هذه هي الطريقة التي تم بها تصميم النموذج الجدولي والعمل مع البيانات الموجودة فيه والتي تحدث انسدادات.
لذلك، من أجل نقاء التجربة، سوف نستبعد هذا العامل، وفيما يلي سأوضح بالضبط كيف.
- لنفترض، على سبيل اليقين، أن 100% من أوامر SQL المقدمة إلى قاعدة البيانات هي أوامر 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في البداية، في ظل ظروف التحميل هذه، كنت أرغب في استخدام المعاملة الفرعية
لديها ميزة رائعة، سأقتبس من المؤلف:
في قلب SLOB توجد "طريقة SLOB". تهدف طريقة SLOB إلى اختبار المنصات
دون منافسة التطبيق. لا يمكن للمرء أن يقود أقصى أداء للأجهزة
باستخدام رمز التطبيق المرتبط، على سبيل المثال، بقفل التطبيق أو حتى
مشاركة كتل قاعدة بيانات أوراكل. هذا صحيح، هناك حمل إضافي عند مشاركة البيانات
في كتل البيانات! لكن SLOB – في نشره الافتراضي – محصن ضد مثل هذا الخلاف.
وهذا التصريح: يقابل، فهو كذلك.
من الملائم تنظيم درجة التوازي بين جلسات cl، وهذا هو المفتاح -t إطلاق الأداة المساعدة runit.sh من سلوب
يتم تنظيم نسبة أوامر DML، في عدد الرسائل النصية التي يتم إرسالها إلى الفرع الفرعي، كل جلسة نصية، المعلمة UPDATE_PCT
بشكل منفصل ومريح للغاية: SLOB نفسه، قبل جلسة التحميل وبعدها - يقوم بإعداد حزمة إحصائيات، أو لقطات awr (ما تم إعداده للتحضير).
ومع ذلك، اتضح ذلك 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 منفصلة في قاعدة البيانات) يتم إنشاء جدول منفصل يعمل به العامل.
وهذا يضمن عدم وجود أقفال المعاملات بين جلسات العمل.
كل عامل: يفعل نفس الشيء، بطاولته الخاصة، الطاولات كلها متشابهة.
جميع العمال يؤدون العمل لنفس القدر من الوقت.
علاوة على ذلك، لفترة طويلة بما فيه الكفاية بحيث، على سبيل المثال، سيحدث تبديل السجل بالتأكيد، وأكثر من مرة.
حسنًا، وفقًا لذلك، نشأت التكاليف والآثار المرتبطة بها.
في حالتي، قمت بضبط مدة عمل العمال على 8 دقائق.
جزء من تقرير statspack يصف تشغيل القسم الفرعي تحت التحميل
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2929910313 XE 1 07-Sep-20 23:12 18.0.0.0.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
billing.izhevsk1 Linux x86 64-bit 2 2 1 15.6
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 1630 07-Sep-20 23:12:27 55 .7
End Snap: 1631 07-Sep-20 23:20:29 62 .6
Elapsed: 8.03 (mins) Av Act Sess: 8.4
DB time: 67.31 (mins) DB CPU: 15.01 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 1,392M Std Block Size: 8K
Shared Pool: 288M Log Buffer: 103,424K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 8.4 0.0 0.00 0.20
DB CPU(s): 1.9 0.0 0.00 0.04
Redo size: 7,685,765.6 978.4
Logical reads: 60,447.0 7.7
Block changes: 47,167.3 6.0
Physical reads: 8.3 0.0
Physical writes: 253.4 0.0
User calls: 42.6 0.0
Parses: 23.2 0.0
Hard parses: 1.2 0.0
W/A MB processed: 1.0 0.0
Logons: 0.5 0.0
Executes: 15,756.5 2.0
Rollbacks: 0.0 0.0
Transactions: 7,855.1العودة إلى العمل المختبري.
سنقوم، مع تساوي الأمور الأخرى، بتغيير قيم المعلمات التالية لقاعدة البيانات الفرعية للمختبر:
- حجم مجموعات سجل قاعدة البيانات. نطاق القيمة: [32، 1024] ميجابايت؛
- عدد مجموعات المجلات في قاعدة البيانات. نطاق القيمة: [2,32]؛
log_archive_max_processesنطاق القيمة: [1,8،XNUMX]؛commit_loggingيُسمح بقيمتين:batch|immediate;commit_waitيُسمح بقيمتين:wait|nowait;log_bufferنطاق القيمة: [2,128] ميجابايت.log_checkpoint_timeoutنطاق القيمة: [60,1200] ثانيةdb_writer_processesنطاق القيمة: [1,4]undo_retentionنطاق القيمة: [30;300] ثانيةtransactions_per_rollback_segmentنطاق القيمة: [1,8]disk_asynch_ioيُسمح بقيمتين:true|false;filesystemio_optionsالقيم التالية مسموح بها:none|setall|directIO|asynch;db_block_checkingالقيم التالية مسموح بها:OFF|LOW|MEDIUM|FULL;db_block_checksumالقيم التالية مسموح بها:OFF|TYPICAL|FULL;
من المؤكد أن الشخص الذي لديه خبرة في صيانة قواعد بيانات أوراكل يمكنه بالفعل أن يقول ما هي القيم التي يجب تعيينها، من المعلمات المحددة وقيمها المقبولة، من أجل الحصول على إنتاجية أكبر لقاعدة البيانات للعمل مع البيانات المشار إليها بواسطة رمز التطبيق هنا أعلاه.
لكن.
الهدف من العمل المختبري هو إظهار أن خوارزمية التحسين نفسها ستوضح لنا ذلك بسرعة نسبية.
بالنسبة لنا، كل ما تبقى هو النظر في المستند، من خلال النظام القابل للتخصيص، وهو ما يكفي فقط لمعرفة المعلمات التي يجب تغييرها وفي أي نطاقات.
وأيضًا: قم بترميز الكود الذي سيتم استخدامه للعمل مع النظام المخصص لخوارزمية التحسين المحددة.
والآن عن الكود.
لقد تحدثت أعلاه عن 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.
وهذا يعني: كم عدد، مع إعداد فرعي معين وتحميل معين على الفرعي: يقوم الفرعي بمعالجة المعاملات في الثانية.
أي أنه عند الفتح، يجب تنفيذ الخطوات المتعددة التالية داخل وظيفة اللياقة البدنية:
- معالجة متجه الإدخال للأرقام - تحويله إلى قيم لمعلمات البيانات الفرعية.
- محاولة لإنشاء عدد معين من مجموعات الإعادة ذات حجم معين. علاوة على ذلك، قد تكون المحاولة غير ناجحة.
مجموعات المجلات الموجودة بالفعل في القسم الفرعي، في بعض الكمية وبعض الحجم، لنقاء التجربة - d.b. تم الحذف. - إذا نجحت النقطة السابقة: تحديد قيم معلمات التكوين لقاعدة البيانات (مرة أخرى: قد يكون هناك فشل)
- إذا نجحت الخطوة السابقة: قم بإيقاف القسم الفرعي، وبدء تشغيل القسم الفرعي حتى تصبح قيم المعلمات المحددة حديثًا نافذة المفعول. (مرة أخرى: قد يكون هناك خلل)
- إذا نجحت الخطوة السابقة: قم بإجراء اختبار التحميل. الحصول على المقاييس من 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 بمعالجة النواقل، أو بشكل صحيح، الكروموسومات.
والأهم بالنسبة لنا هو اختيار الكروموسومات ذات الجينات التي تنتج لها وظيفة اللياقة قيمًا كبيرة.
هذه، في جوهرها، هي عملية البحث عن المجموعة المثالية من الكروموسومات باستخدام ناقل في مساحة بحث ذات أبعاد N.
واضحة جدا ومفصلة ، مع أمثلة على كود R، عمل الخوارزمية الجينية.
أود أن أشير بشكل منفصل إلى نقطتين فنيتين.
المكالمات المساعدة من الوظيفة evaluate، على سبيل المثال، يتم تنفيذ Stop-Start، وتحديد قيمة المعلمة الفرعية، بناءً على ذلك cran-r المهام system2
بمساعدة ما يلي: يتم استدعاء بعض البرامج النصية أو الأوامر bash.
على سبيل المثال:
set_db_parameter
set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")
x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (attributes(x)$status)
}
else {
cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
return (0)
}
}النقطة الثانية هي السطر evaluate وظائف، مع حفظ قيمة مترية محددة وناقل الضبط المقابل لها في ملف السجل:
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)هذا أمر مهم، لأنه من خلال مجموعة البيانات هذه، سيكون من الممكن الحصول على معلومات إضافية حول أي من مكونات متجه الضبط له تأثير أكبر أو أقل على القيمة المترية.
أي: سيكون من الممكن إجراء تحليل أهمية السمات.
إذن ماذا يمكن أن يحدث؟
وفي شكل رسم بياني، إذا قمت بترتيب الاختبارات بترتيب متري تصاعدي، فستكون الصورة كما يلي:
بعض البيانات المقابلة للقيم المتطرفة للمقياس:
هنا، في لقطة الشاشة مع النتائج، سأوضح: يتم إعطاء قيم متجه الضبط من حيث رمز وظيفة اللياقة البدنية، وليس من حيث قائمة أرقام المعلمات/نطاقات قيم المعلمات، التي تمت صياغتها أعلاه في النص.
حسنًا. هل هو كثير أم قليل، ~ 8 آلاف نقطة: سؤال منفصل.
في إطار العمل المختبري، هذا الرقم ليس مهما، المهم هو الديناميكيات، وكيف تتغير هذه القيمة.
الديناميكيات هنا جيدة.
من الواضح أن هناك عامل واحد على الأقل يؤثر بشكل كبير على قيمة المقياس، وهو خوارزمية الجا، التي تقوم بالفرز عبر ناقلات الكروموسوم: المغطاة.
إذا حكمنا من خلال الديناميكيات القوية إلى حد ما لقيم المنحنى، هناك عامل واحد آخر على الأقل له تأثير، على الرغم من أنه أصغر بكثير.
هذا هو المكان الذي تحتاجه attribute-importance تحليل لفهم ما هي السمات (حسنًا، في هذه الحالة، مكونات متجه الضبط) ومدى تأثيرها على القيمة المترية.
ومن هذه المعلومات: فهم العوامل التي تأثرت بالتغيرات في السمات المهمة.
جولة attribute-importance ممكن بطرق مختلفة.
لهذه الأغراض، أنا أحب الخوارزمية randomForest حزمة R بنفس الاسم ()
randomForestكما أفهم عمله بشكل عام ومنهجه في تقييم أهمية السمات بشكل خاص، فإنه يبني نموذجًا معينًا لاعتماد متغير الاستجابة على السمات.
في حالتنا، متغير الاستجابة هو مقياس تم الحصول عليه من قاعدة البيانات في اختبارات التحميل: tps;
والسمات هي مكونات ناقل الضبط.
حتى هنا randomForest يقيم أهمية كل سمة نموذج برقمين: %IncMSE - كيف يؤدي وجود/غياب هذه السمة في النموذج إلى تغيير جودة MSE لهذا النموذج (متوسط الخطأ المربع)؛
و IncNodePurity هو رقم يعكس مدى جودة تقسيم مجموعة البيانات مع الملاحظات، بناءً على قيم هذه السمة، بحيث توجد في جزء واحد بيانات ذات قيمة واحدة من المقياس الذي يتم شرحه، وفي الجزء الآخر مع قيمة أخرى للمقياس.
حسنًا، هذا يعني: إلى أي مدى تعد هذه سمة تصنيفية (رأيت التفسير الأكثر وضوحًا باللغة الروسية على RandomForest ).
رمز R للعمال والفلاحين لمعالجة مجموعة البيانات مع نتائج اختبارات التحميل:
x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')
idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]
library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importanceيمكنك تحديد المعلمات الفائقة للخوارزمية مباشرة بيديك، مع التركيز على جودة النموذج، وتحديد نموذج يلبي التوقعات في مجموعة بيانات التحقق من الصحة بشكل أكثر دقة.
يمكنك كتابة نوع من الوظائف لهذا العمل (بالمناسبة، مرة أخرى، باستخدام نوع من خوارزمية التحسين).
يمكنك استخدام حزمة R caret، ليست النقطة مهمة.
ونتيجة لذلك يتم في هذه الحالة الحصول على النتيجة التالية لتقييم درجة أهمية السمات:
حسنًا. وهكذا، يمكننا أن نبدأ التفكير العالمي:
- وتبين أن المعلمة الأكثر أهمية، في ظل ظروف الاختبار هذه
commit_wait
من الناحية الفنية، فإنه يحدد وضع تنفيذ عملية io لكتابة بيانات الإعادة من المخزن المؤقت لسجل قاعدة البيانات الفرعية إلى مجموعة السجل الحالية: متزامن أو غير متزامن.
قيمةnowaitمما يؤدي إلى زيادة رأسية ومتعددة تقريبًا في قيمة مقياس tps: هذا هو تضمين وضع io غير المتزامن في مجموعات الإعادة.
سؤال منفصل هو ما إذا كان يجب عليك القيام بذلك في قاعدة بيانات الأغذية أم لا. هنا أقتصر على القول: هذا عامل مهم. - من المنطقي أن يكون حجم المخزن المؤقت للسجل الخاص بـ subd: عاملاً مهمًا.
كلما كان حجم المخزن المؤقت للسجل أصغر، قلت سعة التخزين المؤقت الخاصة به، وكلما زاد في كثير من الأحيان و/أو عدم القدرة على تخصيص مساحة حرة فيه لجزء من بيانات الأكسدة والاختزال الجديدة.
وهذا يعني: التأخير المرتبط بتخصيص المساحة في المخزن المؤقت للسجل و/أو تفريغ بيانات الإعادة منه في مجموعات الإعادة.
هذه التأخيرات، بالطبع، يجب أن تؤثر على إنتاجية قاعدة البيانات للمعاملات. - المعلمة
db_block_checksum: حسنًا، بشكل عام، من الواضح أن معالجة المعاملات تؤدي إلى تكوين كتل متقطعة في ذاكرة التخزين المؤقت لقاعدة البيانات الفرعية.
والتي، عند تمكين التحقق من المجاميع الاختبارية لكتل البيانات، يجب على قاعدة البيانات معالجتها - احسب هذه المجاميع الاختبارية من نص كتلة البيانات، وتحقق منها بما هو مكتوب في رأس كتلة البيانات: يطابق/لا يتطابق.
مثل هذا العمل، مرة أخرى، لا يمكن إلا أن يؤخر معالجة البيانات، وبالتالي فإن المعلمة والآلية التي تحدد هذه المعلمة تكون مهمة.
لهذا السبب يقدم البائع، في وثائق هذه المعلمة، قيمًا مختلفة ويلاحظ أنه نعم، سيكون هناك تأثير، ولكن يمكنك اختيار قيم مختلفة، حتى "إيقاف" وتأثيرات مختلفة.
حسنًا، استنتاج عالمي.
لقد تبين أن هذا النهج ناجح بشكل عام.
إنه يسمح لنفسه تمامًا، في المراحل الأولى من اختبار التحميل لنظام خدمة معين، باختيار التكوين الأمثل (النظام) للحمل، وليس الخوض كثيرًا في تفاصيل إعداد النظام للتحميل.
لكنه لا يستبعد ذلك تماما - على الأقل على مستوى الفهم: يجب أن يكون النظام على علم بـ "مقابض الضبط" ونطاقات الدوران المسموح بها لهذه المقابض.
يمكن لهذا النهج بعد ذلك العثور بسرعة نسبية على التكوين الأمثل للنظام.
وبناء على نتائج الاختبار يمكن الحصول على معلومات حول طبيعة العلاقة بين مقاييس أداء النظام وقيم معلمات إعدادات النظام.
والذي، بالطبع، يجب أن يساهم في ظهور هذا الفهم العميق للغاية للنظام، وعمله، على الأقل تحت حمل معين.
ومن الناحية العملية، يعد هذا بمثابة تبادل لتكاليف فهم النظام المخصص لتكاليف إعداد مثل هذا الاختبار للنظام.
أود أن أشير بشكل منفصل: في هذا النهج، فإن درجة كفاية اختبار النظام لظروف التشغيل التي سيكون عليها في التشغيل التجاري أمر بالغ الأهمية.
شكرا لك على اهتمامك ووقتك.
المصدر: www.habr.com