سلام
تصمیم گرفتم یافته خود را به اشتراک بگذارم - ثمره فکر، آزمون و خطا.
به طور کلی: این یک یافته نیست، البته - همه اینها باید برای مدت طولانی برای کسانی که درگیر پردازش داده های آماری کاربردی و بهینه سازی هر سیستم هستند، نه به طور خاص DBMS، شناخته شده باشد.
و: بله، آنها می دانند، آنها مقالات جالبی در مورد تحقیقات خود می نویسند، (UPD.: در نظرات آنها به یک پروژه بسیار جالب اشاره کردند: )
از سوی دیگر: من هیچ اشاره یا انتشار گسترده ای از این رویکرد در اینترنت در میان متخصصان فناوری اطلاعات، DBA نمی بینم.
بنابراین، به نقطه.
بیایید فرض کنیم که ما یک وظیفه داریم: راه اندازی یک سیستم خدمات خاص برای خدمات رسانی به نوعی کار.
در مورد این اثر معلوم است: چیست، کیفیت این کار چگونه سنجیده می شود و معیار سنجش این کیفیت چیست.
بیایید همچنین فرض کنیم که کم و بیش شناخته شده و درک شده است: دقیقاً چگونه کار در (یا با) این سیستم خدماتی انجام می شود.
"کم و بیش" - این بدان معنی است که می توان ابزار، ابزار، سرویس خاصی را تهیه کرد (یا از جایی دریافت کرد) که می تواند سنتز شود و با یک بار آزمایشی به اندازه کافی برای آنچه در تولید خواهد بود، ترکیب شود و به سیستم اعمال شود. در شرایط به اندازه کافی برای کار در تولید.
خوب، بیایید فرض کنیم که مجموعه ای از پارامترهای تنظیم برای این سیستم خدماتی شناخته شده است که می توان از آنها برای پیکربندی این سیستم از نظر بهره وری کار استفاده کرد.
و مشکل چیست - درک کافی کامل از این سیستم خدماتی وجود ندارد، چیزی که به شما امکان می دهد تنظیمات این سیستم را برای بارگذاری آینده در یک پلت فرم مشخص پیکربندی کنید و بهره وری مورد نیاز سیستم را به دست آورید.
خوب. تقریبا همیشه اینطور است.
تو اینجا چکاری میتوانی انجام دهی؟
خوب، اولین چیزی که به ذهن می رسد این است که به مستندات این سیستم نگاه کنید. درک کنید که محدوده های قابل قبول برای مقادیر پارامترهای تنظیم چیست. و به عنوان مثال، با استفاده از روش نزول مختصات، مقادیر پارامترهای سیستم را در تست ها انتخاب کنید.
آن ها به سیستم نوعی پیکربندی را در قالب مجموعه ای خاص از مقادیر برای پارامترهای پیکربندی آن ارائه دهید.
با استفاده از این ابزار ابزار، ژنراتور بار، یک بار آزمایشی روی آن اعمال کنید.
و به ارزش - پاسخ یا معیاری از کیفیت سیستم نگاه کنید.
فکر دوم ممکن است نتیجه گیری باشد که این زمان بسیار طولانی است.
خوب، یعنی: اگر پارامترهای تنظیم زیادی وجود داشته باشد، اگر محدوده مقادیر در حال اجرا آنها بزرگ باشد، اگر هر آزمایش بار جداگانه زمان زیادی برای تکمیل نیاز دارد، پس: بله، همه اینها ممکن است غیرقابل قبول باشد. مدت زمان طولانی.
خوب، این چیزی است که می توانید بفهمید و به خاطر بسپارید.
می توانید دریابید که در مجموعه مقادیر پارامترهای تنظیمات سیستم خدمات، یک بردار به عنوان دنباله ای از مقادیر وجود دارد.
هر یک از این بردارها، سایر موارد برابر هستند (از این نظر که تحت تأثیر این بردار قرار نمی گیرند)، با یک مقدار کاملاً مشخص از متریک مطابقت دارد - نشانگر کیفیت عملکرد سیستم تحت یک بار آزمایشی.
مثلا
اجازه دهید بردار پیکربندی سیستم را به صورت مشخص نشان دهیم 
جایی که ; جایی که - تعداد پارامترهای پیکربندی سیستم، چند مورد از این پارامترها وجود دارد.
و مقدار متریک مربوط به این بیایید آن را به عنوان نشان دهیم
، سپس یک تابع دریافت می کنیم:
خب، پس: در مورد من، همه چیز بلافاصله به این می رسد: تقریباً از دوران دانشجویی من فراموش شده، الگوریتم هایی برای جستجوی حداکثر یک تابع.
بسیار خوب، اما در اینجا یک سوال سازمانی و کاربردی مطرح می شود: از کدام الگوریتم استفاده کنیم.
- به این معنا - به طوری که می توانید کمتر با دست کدنویسی کنید.
- و برای اینکه کار کند، یعنی. اکسترموم را پیدا کرد (اگر وجود داشته باشد)، خوب، حداقل سریعتر از نزول مختصات.
اولین نکته اشاره می کند که ما باید به محیط هایی نگاه کنیم که چنین الگوریتم هایی قبلاً در آنها پیاده سازی شده اند و به نوعی برای استفاده در کد آماده هستند.
خوب، من می دانم python и cran-r
نکته دوم به این معنی است که شما باید در مورد خود الگوریتم ها، چیستی آنها، نیازهای آنها و ویژگی های کار آنها مطالعه کنید.
و آنچه آنها می دهند می تواند عوارض جانبی مفیدی باشد - نتایج یا مستقیماً از خود الگوریتم.
یا می توان آنها را از نتایج الگوریتم به دست آورد.
خیلی به شرایط ورودی بستگی دارد.
به عنوان مثال، اگر به دلایلی نیاز دارید سریعتر به نتیجه برسید، خوب، باید به الگوریتم های نزولی گرادیان نگاه کنید و یکی از آنها را انتخاب کنید.
یا اگر زمان چندان مهم نیست، می‌توانید مثلاً از روش‌های بهینه‌سازی تصادفی مانند الگوریتم ژنتیک استفاده کنید.
من پیشنهاد می کنم کار این رویکرد را با انتخاب پیکربندی سیستم با استفاده از یک الگوریتم ژنتیک در مرحله بعدی در نظر بگیریم: کار آزمایشگاهی.
اولیه:
- اجازه دهید وجود داشته باشد، به عنوان یک سیستم خدمات:
oracle xe 18c - اجازه دهید در خدمت فعالیت تراکنش و هدف باشد: به دست آوردن بالاترین توان عملیاتی ممکن از پایگاه داده، در تراکنش در ثانیه.
- تراکنش ها می توانند از نظر ماهیت کار با داده ها و زمینه کار بسیار متفاوت باشند.
بیایید قبول کنیم که این تراکنش‌هایی هستند که حجم زیادی از داده‌های جدولی را پردازش نمی‌کنند.
به این معنا که داده‌های واگرد بیشتری نسبت به انجام مجدد تولید نمی‌کنند و درصد زیادی از ردیف‌ها و جداول بزرگ را پردازش نمی‌کنند.
اینها تراکنش هایی هستند که یک ردیف را در یک جدول کم و بیش بزرگ با تعداد اندکی از شاخص ها در این جدول تغییر می دهند.
در این شرایط: بهره‌وری پایگاه داده‌های فرعی برای پردازش تراکنش‌ها، با یک رزرو، با کیفیت پردازش توسط پایگاه‌داده ردوکس تعیین می‌شود.
سلب مسئولیت - اگر به طور خاص در مورد تنظیمات subdb صحبت کنیم.
زیرا، در حالت کلی، ممکن است، برای مثال، قفل های تراکنش بین جلسات SQL، به دلیل طراحی کار کاربر با داده های جدولی و/یا مدل جدولی وجود داشته باشد.
که البته تأثیری ناامیدکننده بر متریک TPS خواهد داشت و این یک عامل برونزا نسبت به پایگاه داده فرعی خواهد بود: خوب، این نحوه طراحی مدل جدولی و کار با داده های موجود در آن است که انسداد رخ می دهد.
بنابراین، برای خلوص آزمایش، این عامل را حذف می کنیم و در زیر دقیقاً چگونگی آن را روشن می کنم.
- اجازه دهید برای قطعیت فرض کنیم که 100٪ از دستورات SQL ارسال شده به پایگاه داده دستورات DML هستند.
بگذارید ویژگی های کار کاربر با پایگاه داده در آزمایش ها یکسان باشد.
یعنی: تعداد جلسات 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 - در استقرار پیش‌فرض خود - از چنین بحث‌هایی مصون است.
این اعلامیه: مطابقت دارد، آن است.
تنظیم میزان موازی جلسات cl راحت است، این کلید است -t ابزار را راه اندازی کنید runit.sh از SLOB
درصد دستورات DML تنظیم می شود، در تعداد پیام های متنی ارسال شده به subd، هر جلسه متن، پارامتر UPDATE_PCT
به طور جداگانه و بسیار راحت: SLOB خودش، قبل و بعد از جلسه بارگذاری - یک statspack یا عکس های فوری (چیزی که قرار است آماده شود) آماده می کند.
با این حال، معلوم شد که SLOB از جلسات SQL با مدت زمان کمتر از 30 ثانیه پشتیبانی نمی کند.
بنابراین، من ابتدا نسخه کارگری-دهقانی لودر خود را کدنویسی کردم و سپس به کار خود ادامه دادم.
اجازه دهید برای وضوح بیشتر توضیح دهم که لودر چه کاری انجام می دهد و چگونه آن را انجام می دهد.
اساساً لودر به شکل زیر است:
کد کارگر
function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off
define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum
declare
v_upto number;
v_key number;
v_tots number;
v_cts number;
begin
select max(col1) into v_upto from system.testtab_&&wnum;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
v_tots := &&period + v_cts;
while v_cts <= v_tots
loop
v_key:=abs(mod(dbms_random.random,v_upto));
if v_key=0 then
v_key:=1;
end if;
update system.testtab_&&wnum t
set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
where t.col1=v_key
;
commit;
SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
end loop;
end;
/
exit
__EOF__
}
export -f dotxکارگران از این طریق راه اندازی می شوند:
کارگران در حال دویدن
echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
echo "sql-session: ${i}" >> "$v_logfile"
dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
waitو جداول برای کارگران به شرح زیر تهیه می شود:
ایجاد جداول
function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off
define wnum="$1"
define ts_name="slob"
begin
execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/
create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable
seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"آن ها برای هر کارگر (عملا: یک جلسه SQL جداگانه در DB) یک جدول جداگانه ایجاد می شود که کارگر با آن کار می کند.
این عدم وجود قفل معاملاتی بین جلسات کارگر را تضمین می کند.
هر کارگر: همین کار را می کند، با جدول خودش، میزها همه یکسان است.
همه کارگران کار را برای مدت یکسان انجام می دهند.
علاوه بر این، برای مدت زمان کافی به طوری که، به عنوان مثال، یک سوئیچ ورود به سیستم قطعا رخ می دهد، و بیش از یک بار.
خوب، بر این اساس، هزینه ها و اثرات مرتبط به وجود آمد.
در مورد من، مدت زمان کار کارگران را 8 دقیقه تنظیم کردم.
بخشی از گزارش statspack که عملکرد subd تحت بار را توصیف می کند
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
2929910313 XE 1 07-Sep-20 23:12 18.0.0.0.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
billing.izhevsk1 Linux x86 64-bit 2 2 1 15.6
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 1630 07-Sep-20 23:12:27 55 .7
End Snap: 1631 07-Sep-20 23:20:29 62 .6
Elapsed: 8.03 (mins) Av Act Sess: 8.4
DB time: 67.31 (mins) DB CPU: 15.01 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 1,392M Std Block Size: 8K
Shared Pool: 288M Log Buffer: 103,424K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 8.4 0.0 0.00 0.20
DB CPU(s): 1.9 0.0 0.00 0.04
Redo size: 7,685,765.6 978.4
Logical reads: 60,447.0 7.7
Block changes: 47,167.3 6.0
Physical reads: 8.3 0.0
Physical writes: 253.4 0.0
User calls: 42.6 0.0
Parses: 23.2 0.0
Hard parses: 1.2 0.0
W/A MB processed: 1.0 0.0
Logons: 0.5 0.0
Executes: 15,756.5 2.0
Rollbacks: 0.0 0.0
Transactions: 7,855.1بازگشت به کار آزمایشگاهی.
در صورت مساوی بودن سایر موارد، مقادیر پارامترهای زیر پایگاه داده آزمایشگاهی را تغییر خواهیم داد:
- اندازه گروه های گزارش پایگاه داده محدوده مقدار: [32, 1024] مگابایت;
- تعداد گروه های مجلات در پایگاه داده. محدوده مقدار: [2,32];
log_archive_max_processesمحدوده مقدار: [1,8];commit_loggingدو مقدار مجاز است:batch|immediate;commit_waitدو مقدار مجاز است:wait|nowait;log_bufferمحدوده مقدار: [2,128] مگابایت.log_checkpoint_timeoutمحدوده مقدار: [60,1200] ثانیهdb_writer_processesمحدوده مقدار: [1,4،XNUMX]undo_retentionمحدوده مقدار: [30;300] ثانیهtransactions_per_rollback_segmentمحدوده مقدار: [1,8،XNUMX]disk_asynch_ioدو مقدار مجاز است:true|false;filesystemio_optionsمقادیر زیر مجاز است:none|setall|directIO|asynch;db_block_checkingمقادیر زیر مجاز است:OFF|LOW|MEDIUM|FULL;db_block_checksumمقادیر زیر مجاز است:OFF|TYPICAL|FULL;
یک فرد با تجربه در نگهداری پایگاه داده های Oracle مطمئناً می تواند بگوید که چه و به چه مقادیری باید از روی پارامترهای مشخص شده و مقادیر قابل قبول آنها تنظیم شود تا بهره وری بیشتری از پایگاه داده برای کار با داده های نشان داده شده به دست آورد. کد برنامه، در اینجا بالا.
اما.
هدف کار آزمایشگاهی نشان دادن این است که خود الگوریتم بهینه سازی این موضوع را نسبتاً سریع برای ما روشن می کند.
برای ما، تنها چیزی که باقی می‌ماند این است که از طریق سیستم قابل تنظیم، به سند نگاه کنیم، فقط کافی است بفهمیم چه پارامترهایی را باید تغییر دهیم و در چه محدوده‌هایی.
و همچنین: کدی را که برای کار با سیستم سفارشی الگوریتم بهینه سازی انتخاب شده استفاده می شود، کد کنید.
خب حالا در مورد کد.
در بالا در موردش صحبت کردم cran-r، یعنی: تمام دستکاری ها با سیستم سفارشی شده در قالب یک اسکریپت R تنظیم می شوند.
وظیفه واقعی، تجزیه و تحلیل، انتخاب بر اساس مقدار متریک، بردارهای وضعیت سیستم: این یک بسته است GA ()
بسته، در این مورد، چندان مناسب نیست، به این معنا که انتظار دارد بردارها (کروموزوم ها، اگر از نظر بسته) به صورت رشته های اعداد با یک قسمت کسری مشخص شوند.
و بردار من، از مقادیر پارامترهای تنظیم: اینها 14 کمیت هستند - اعداد صحیح و مقادیر رشته.
البته با اختصاص اعداد خاص به مقادیر رشته به راحتی از این مشکل جلوگیری می شود.
بنابراین، در پایان، قطعه اصلی اسکریپت R به شکل زیر است:
با GA::ga تماس بگیرید
cat( "", file=v_logfile, sep="n", append=F)
pSize = 10
elitism_value=1
pmutation_coef=0.8
pcrossover_coef=0.1
iterations=50
gam=GA::ga(type="real-valued", fitness=evaluate,
lower=c(32,2, 1,1,1,2,60,1,30,1,0,0, 0,0), upper=c(1024,32, 8,10,10,128,800,4,300,8,10,40, 40,30),
popSize=pSize,
pcrossover = pcrossover_coef,
pmutation = pmutation_coef,
maxiter=iterations,
run=4,
keepBest=T)
cat( "GA-session is done" , file=v_logfile, sep="n", append=T)
gam@solutionاینجا، با کمک lower и upper ویژگی های زیر روال ga اساساً منطقه ای از فضای جستجو مشخص می شود که در آن جستجو برای چنین بردار (یا بردارهایی) انجام می شود که حداکثر مقدار تابع تناسب برای آن به دست می آید.
زیربرنامه ga جستجویی را انجام می دهد که عملکرد تناسب اندام را به حداکثر می رساند.
خوب، پس معلوم می شود که در این مورد، لازم است که تابع تناسب، با درک بردار به عنوان مجموعه ای از مقادیر برای پارامترهای خاصی از subd، یک متریک از subd دریافت کند.
یعنی: تعداد، با تنظیم subd معین و بار معین در subd: subd تراکنش ها را در هر ثانیه پردازش می کند.
یعنی هنگام باز کردن، چند مرحله زیر باید در داخل تابع تناسب اندام انجام شود:
- پردازش بردار ورودی اعداد - تبدیل آن به مقادیر پارامترهای زیرداده.
- تلاشی برای ایجاد تعداد معینی از گروه‌های تکراری با اندازه معین. علاوه بر این، تلاش ممکن است ناموفق باشد.
گروه‌های مجله‌ای که قبلاً برای خلوص آزمایش در بخش فرعی، در مقداری و اندازه‌ای وجود داشتند - d.b. حذف شده. - در صورت موفقیت آمیز بودن نقطه قبلی: تعیین مقادیر پارامترهای پیکربندی در پایگاه داده (دوباره: ممکن است خرابی وجود داشته باشد)
- اگر مرحله قبل موفقیت آمیز بود: توقف subd، شروع subd به طوری که مقادیر پارامتر جدید مشخص شده اعمال شوند. (باز هم: ممکن است اشکالی وجود داشته باشد)
- اگر مرحله قبل موفقیت آمیز بود: آزمایش بار را انجام دهید. معیارها را از subd دریافت کنید.
- subd را به حالت اولیه خود برگردانید، i.e. گروه‌های گزارش اضافی را حذف کنید، پیکربندی اصلی پایگاه داده را به کار بازگردانید.
کد عملکرد تناسب اندام
evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")
opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")
opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
opn$disk_asynch_io="false"
}
opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
opn$filesystemio_options="asynch"
}
opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
opn$db_block_checking="FULL"
}
opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
opn$db_block_checksum="FULL"
}
v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)
rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
return (0)
}
v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) { v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) { v_rc=1 }
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
rc=stop_db("abort")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
return (0)
}
rc=run_test()
v_metric=getmetric()
rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)
cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}که همه کارها: در عملکرد تناسب اندام انجام می شود.
زیرروال ga بردارها یا به عبارت صحیح تر کروموزوم ها را پردازش می کند.
که در آن، آنچه برای ما مهم است، انتخاب کروموزوم هایی با ژن هایی است که تابع تناسب مقادیر زیادی برای آنها تولید می کند.
این، در اصل، فرآیند جستجوی مجموعه بهینه کروموزوم ها با استفاده از یک بردار در فضای جستجوی N بعدی است.
بسیار واضح، با جزئیات ، با مثال هایی از R-code، کار یک الگوریتم ژنتیک.
من می خواهم به طور جداگانه به دو نکته فنی اشاره کنم.
تماس های کمکی از تابع evaluateبه عنوان مثال، stop-start، تنظیم مقدار پارامتر subd، بر اساس انجام می شود 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)این مهم است، زیرا از این آرایه داده، می توان اطلاعات اضافی در مورد اینکه کدام یک از اجزای بردار تنظیم تأثیر کمتر یا بیشتر بر مقدار متریک دارد، به دست آورد.
یعنی: امکان انجام تجزیه و تحلیل ویژگی-importamce وجود خواهد داشت.
پس چه اتفاقی می تواند بیفتد؟
در فرم نمودار، اگر تست ها را به ترتیب متریک صعودی مرتب کنید، تصویر به شرح زیر است:
برخی از داده های مربوط به مقادیر شدید متریک:
در اینجا، در اسکرین شات با نتایج، توضیح خواهم داد: مقادیر بردار تنظیم برحسب کد تابع تناسب داده می شود، نه از نظر تعداد لیست پارامترها / محدوده مقادیر پارامتر که فرموله شده است. بالا در متن
خوب. زیاد است یا کم، ~8 TPS: یک سوال جداگانه.
در چارچوب کارهای آزمایشگاهی، این رقم مهم نیست، آنچه مهم است دینامیک است، چگونه این مقدار تغییر می کند.
پویایی اینجا خوب است.
بدیهی است که حداقل یک عامل به طور قابل توجهی بر مقدار متریک تأثیر می گذارد، الگوریتم ga، مرتب سازی از طریق بردارهای کروموزوم: پوشش داده شده.
با قضاوت بر اساس دینامیک نسبتاً شدید مقادیر منحنی، حداقل یک عامل دیگر وجود دارد که اگرچه بسیار کوچکتر است، اما تأثیر دارد.
این جایی است که شما به آن نیاز دارید 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 را برای نوشتن داده‌های انجام مجدد از بافر گزارش subdb به گروه گزارش فعلی مشخص می‌کند: همزمان یا ناهمزمان.
ارزشnowaitکه منجر به افزایش تقریباً عمودی و چندگانه در مقدار متریک tps می‌شود: این شامل حالت io ناهمزمان در گروه‌های redo است.
یک سوال جداگانه این است که آیا باید این کار را در پایگاه داده مواد غذایی انجام دهید یا خیر. در اینجا من فقط به بیان این نکته اکتفا می کنم: این یک عامل مهم است. - منطقی است که اندازه بافر log subd: عامل مهمی باشد.
هرچه اندازه بافر گزارش کوچکتر باشد، ظرفیت بافر آن کمتر است، بیشتر اوقات سرریز می شود و/یا ناتوانی در تخصیص یک منطقه آزاد در آن برای بخشی از داده های ردوکس جدید.
این به این معنی است: تاخیرهای مرتبط با تخصیص فضا در بافر گزارش و/یا ریختن داده‌های انجام مجدد از آن به گروه‌های مجدد.
البته این تأخیرها باید بر توان عملیاتی پایگاه داده برای تراکنش‌ها تأثیر بگذارد. - پارامتر
db_block_checksum: خوب، همچنین، به طور کلی واضح است - پردازش تراکنش منجر به تشکیل بلوک‌های دارتی در حافظه پنهان بافر پایگاه داده می‌شود.
هنگامی که بررسی جمع‌های چک بلوک‌های داده فعال است، پایگاه داده باید آن را پردازش کند - این جمع‌های چک را از بدنه بلوک داده محاسبه کند، آنها را با آنچه در هدر بلوک داده نوشته شده است بررسی کند: مطابقت دارد / مطابقت ندارد.
چنین کاری، باز هم نمی تواند پردازش داده ها را به تاخیر بیندازد، و بر این اساس، پارامتر و مکانیسمی که این پارامتر را تنظیم می کند، قابل توجه است.
به همین دلیل است که فروشنده، در مستندات این پارامتر، مقادیر متفاوتی را برای آن (پارامتر) ارائه می دهد و توجه می کند که بله، تأثیر خواهد داشت، اما، خوب، می توانید مقادیر مختلفی را انتخاب کنید، تا «خاموش» و تاثیرات مختلف
خوب، یک نتیجه گیری جهانی.
به طور کلی، رویکرد کاملاً کارآمد است.
او کاملاً به خود اجازه می دهد در مراحل اولیه آزمایش بار یک سیستم خدمات خاص، به منظور انتخاب پیکربندی بهینه (سیستم) آن برای بار، بیش از حد به جزئیات راه اندازی سیستم برای بار نپردازد.
اما آن را به طور کامل حذف نمی کند - حداقل در سطح درک: سیستم باید در مورد "شستی های تنظیم" و محدوده های مجاز چرخش این دستگیره ها شناخته شود.
سپس این رویکرد می تواند نسبتاً سریع پیکربندی سیستم بهینه را پیدا کند.
و بر اساس نتایج آزمایش، می توان اطلاعاتی در مورد ماهیت رابطه بین معیارهای عملکرد سیستم و مقادیر پارامترهای تنظیمات سیستم به دست آورد.
که البته باید به ظهور این درک بسیار عمیق از سیستم، عملکرد آن، حداقل تحت یک بار معین کمک کند.
در عمل، این مبادله هزینه های درک سیستم سفارشی شده با هزینه های آماده سازی چنین آزمایشی از سیستم است.
من می خواهم به طور جداگانه یادآوری کنم: در این رویکرد، میزان کفایت تست سیستم با شرایط عملیاتی که در عملیات تجاری خواهد داشت بسیار مهم است.
ممنون از توجه و وقت شما.
منبع: www.habr.com