સાયન્ટિફિક પોક મેથડ, અથવા બેન્ચમાર્ક અને ઓપ્ટિમાઇઝેશન અલ્ગોરિધમનો ઉપયોગ કરીને ડેટાબેઝ કન્ફિગરેશન કેવી રીતે પસંદ કરવું

હેલો

મેં મારી શોધ શેર કરવાનું નક્કી કર્યું - વિચાર, અજમાયશ અને ભૂલનું ફળ.
મોટાભાગે: આ કોઈ શોધ નથી, અલબત્ત - આ બધું લાંબા સમયથી જાણવું જોઈએ, જેઓ લાગુ આંકડાકીય ડેટા પ્રોસેસિંગ અને કોઈપણ સિસ્ટમના ઑપ્ટિમાઇઝેશન સાથે સંકળાયેલા છે, ખાસ કરીને ડીબીએમએસ જરૂરી નથી.
અને: હા, તેઓ જાણે છે, તેઓ તેમના સંશોધન પર રસપ્રદ લેખો લખે છે, ઉદાહરણ (UPD.: ટિપ્પણીઓમાં તેઓએ એક ખૂબ જ રસપ્રદ પ્રોજેક્ટ દર્શાવ્યો: ઓટરટ્યુન )
બીજી બાજુ: IT નિષ્ણાતો, DBA વચ્ચે ઇન્ટરનેટ પર આ અભિગમનો કોઈ વ્યાપક ઉલ્લેખ અથવા પ્રસાર મને દેખાતો નથી.

તેથી, બિંદુ સુધી.

ચાલો ધારીએ કે અમારી પાસે એક કાર્ય છે: અમુક પ્રકારના કાર્યની સેવા માટે ચોક્કસ સેવા સિસ્ટમ સેટ કરવી.

તે આ કાર્ય વિશે જાણીતું છે: તે શું છે, આ કાર્યની ગુણવત્તા કેવી રીતે માપવામાં આવે છે અને આ ગુણવત્તાને માપવા માટે માપદંડ શું છે.

ચાલો એ પણ માની લઈએ કે તે વધુ કે ઓછું જાણીતું અને સમજાયું છે: આ સેવા સિસ્ટમમાં (અથવા સાથે) કાર્ય કેવી રીતે કરવામાં આવે છે.

"વધુ કે ઓછું" - આનો અર્થ એ છે કે ચોક્કસ સાધન, ઉપયોગિતા, સેવા તૈયાર કરવી શક્ય છે (અથવા તેને ક્યાંકથી મેળવવી) જે ઉત્પાદનમાં હશે તે માટે પૂરતા પ્રમાણમાં પરીક્ષણ લોડ સાથે સિસ્ટમ પર સંશ્લેષણ અને લાગુ કરી શકાય છે, ઉત્પાદનમાં કામ કરવા માટે પૂરતી પર્યાપ્ત પરિસ્થિતિઓમાં.

સારું, ચાલો ધારીએ કે આ સેવા સિસ્ટમ માટે ગોઠવણ પરિમાણોનો સમૂહ જાણીતો છે, જેનો ઉપયોગ આ સિસ્ટમને તેના કાર્યની ઉત્પાદકતાના સંદર્ભમાં ગોઠવવા માટે કરી શકાય છે.

અને સમસ્યા શું છે - આ સેવા સિસ્ટમની પૂરતી સંપૂર્ણ સમજ નથી, જે તમને આપેલ પ્લેટફોર્મ પર ભાવિ લોડ માટે આ સિસ્ટમની સેટિંગ્સને કુશળતાપૂર્વક ગોઠવવાની અને સિસ્ટમની આવશ્યક ઉત્પાદકતા મેળવવા માટે પરવાનગી આપે છે.

વેલ. આ લગભગ હંમેશા કેસ છે.

તમે અહીં શું કરી શકો?

ઠીક છે, પ્રથમ વસ્તુ જે ધ્યાનમાં આવે છે તે આ સિસ્ટમ માટેના દસ્તાવેજીકરણને જોવાનું છે. એડજસ્ટમેન્ટ પેરામીટર્સના મૂલ્યો માટે સ્વીકાર્ય રેન્જ શું છે તે સમજો. અને, ઉદાહરણ તરીકે, સંકલન વંશ પદ્ધતિનો ઉપયોગ કરીને, પરીક્ષણોમાં સિસ્ટમ પરિમાણો માટે મૂલ્યો પસંદ કરો.

તે. સિસ્ટમને તેના રૂપરેખાંકન પરિમાણો માટે મૂલ્યોના ચોક્કસ સેટના સ્વરૂપમાં અમુક પ્રકારનું રૂપરેખાંકન આપો.

આ ખૂબ જ ટૂલ-યુટિલિટી, લોડ જનરેટરનો ઉપયોગ કરીને તેના પર ટેસ્ટ લોડ લાગુ કરો.
અને મૂલ્ય જુઓ - પ્રતિભાવ, અથવા સિસ્ટમની ગુણવત્તાનું મેટ્રિક.

બીજો વિચાર એ નિષ્કર્ષ હોઈ શકે છે કે આ ખૂબ લાંબો સમય છે.

ઠીક છે, તે છે: જો ત્યાં ઘણા બધા ટ્યુનિંગ પરિમાણો છે, જો તેમના આવરી લેવાયેલા મૂલ્યોની શ્રેણી મોટી છે, જો દરેક વ્યક્તિગત લોડ પરીક્ષણ પૂર્ણ થવામાં ઘણો સમય લે છે, તો: હા, આ બધું અસ્વીકાર્ય રકમ લઈ શકે છે ના સમયે.

સારું, તમે જે સમજી શકો છો અને યાદ રાખી શકો છો તે અહીં છે.

તમે શોધી શકો છો કે સેવા સિસ્ટમ સેટિંગ્સ પરિમાણોના મૂલ્યોના સમૂહમાં કેટલાક મૂલ્યોના ક્રમ તરીકે વેક્ટર છે.

આવા દરેક વેક્ટર, અન્ય વસ્તુઓ સમાન હોય છે (જેમાં તે આ વેક્ટરથી પ્રભાવિત નથી), મેટ્રિકના સંપૂર્ણ ચોક્કસ મૂલ્યને અનુરૂપ છે - પરીક્ષણ લોડ હેઠળ સિસ્ટમની કામગીરીની ગુણવત્તાનું સૂચક.

એટલે

ચાલો સિસ્ટમ રૂપરેખાંકન વેક્ટર તરીકે દર્શાવીએ જ્યાં ; જ્યાં — સિસ્ટમ રૂપરેખાંકન પરિમાણોની સંખ્યા, આમાંના કેટલા પરિમાણો છે.

અને આને અનુરૂપ મેટ્રિકનું મૂલ્ય ચાલો તેને તરીકે દર્શાવીએ
, પછી આપણને એક કાર્ય મળે છે:

સારું, પછી: મારા કિસ્સામાં, બધું તરત જ નીચે આવે છે: મારા વિદ્યાર્થી દિવસોથી લગભગ ભૂલી ગયેલું, ફંક્શનના અંતિમ ભાગને શોધવા માટેના અલ્ગોરિધમ્સ.

ઠીક છે, પરંતુ અહીં એક સંસ્થાકીય અને લાગુ પ્રશ્ન ઊભો થાય છે: કયા અલ્ગોરિધમનો ઉપયોગ કરવો.

1. અર્થમાં - જેથી તમે હાથથી ઓછા કોડ કરી શકો.
2. અને તે કામ કરવા માટે, એટલે કે. એક્સ્ટ્રીમમ (જો ત્યાં હોય તો), સારું, ઓછામાં ઓછું સંકલન વંશ કરતાં વધુ ઝડપી.

પ્રથમ બિંદુ સંકેત આપે છે કે આપણે કેટલાક પર્યાવરણો તરફ ધ્યાન આપવાની જરૂર છે જેમાં આવા અલ્ગોરિધમ્સ પહેલાથી જ અમલમાં મૂકવામાં આવ્યા છે, અને અમુક સ્વરૂપે, કોડમાં ઉપયોગ માટે તૈયાર છે.
સારું, હું જાણું છું python и cran-r

બીજા મુદ્દાનો અર્થ એ છે કે તમારે પોતાને એલ્ગોરિધમ્સ વિશે વાંચવાની જરૂર છે, તેઓ શું છે, તેમની જરૂરિયાતો શું છે, તેમના કાર્યની સુવિધાઓ.

અને તેઓ જે આપે છે તે ઉપયોગી આડઅસરો હોઈ શકે છે - પરિણામો, અથવા સીધા અલ્ગોરિધમથી જ.

અથવા તેઓ અલ્ગોરિધમના પરિણામોમાંથી મેળવી શકાય છે.

ઘણું ઇનપુટ શરતો પર આધાર રાખે છે.

ઉદાહરણ તરીકે, જો, કોઈ કારણસર, તમારે ઝડપથી પરિણામ મેળવવાની જરૂર છે, સારું, તમારે ગ્રેડિયન્ટ ડિસેન્ટ એલ્ગોરિધમ્સ તરફ જોવાની અને તેમાંથી એક પસંદ કરવાની જરૂર છે.

અથવા, જો સમય એટલો મહત્વપૂર્ણ નથી, તો તમે, ઉદાહરણ તરીકે, સ્ટોકેસ્ટિક ઑપ્ટિમાઇઝેશન પદ્ધતિઓનો ઉપયોગ કરી શકો છો, જેમ કે આનુવંશિક અલ્ગોરિધમ.

હું આ અભિગમના કાર્યને ધ્યાનમાં લેવાનો પ્રસ્તાવ મૂકું છું, સિસ્ટમ રૂપરેખાંકન પસંદ કરીને, આનુવંશિક અલ્ગોરિધમનો ઉપયોગ કરીને, આગળ, તેથી બોલવા માટે: પ્રયોગશાળા કાર્ય.

મૂળ:

1. સેવા સિસ્ટમ તરીકે રહેવા દો: oracle xe 18c
2. તેને ટ્રાન્ઝેક્શનલ એક્ટિવિટી અને ધ્યેય પૂરો કરવા દો: સબડેટાબેઝનું સૌથી વધુ શક્ય થ્રુપુટ, વ્યવહારો/સેકંડમાં મેળવવા માટે.
3. ડેટા સાથે કામ કરવાની પ્રકૃતિ અને કામના સંદર્ભમાં વ્યવહારો ખૂબ જ અલગ હોઈ શકે છે.
   ચાલો સંમત થઈએ કે આ એવા વ્યવહારો છે જે મોટા પ્રમાણમાં ટેબ્યુલર ડેટા પર પ્રક્રિયા કરતા નથી.
   આ અર્થમાં કે તેઓ ફરીથી કરવા કરતાં વધુ પૂર્વવત્ ડેટા જનરેટ કરતા નથી અને પંક્તિઓ અને મોટા કોષ્ટકોની મોટી ટકાવારી પર પ્રક્રિયા કરતા નથી.

આ એવા વ્યવહારો છે જે વધુ કે ઓછા મોટા કોષ્ટકમાં એક પંક્તિને બદલે છે, આ ટેબલ પર ઓછી સંખ્યામાં અનુક્રમણિકાઓ છે.

આ પરિસ્થિતિમાં: પ્રક્રિયા વ્યવહારો માટે સબડેટાબેઝની ઉત્પાદકતા, આરક્ષણ સાથે, રેડોક્સ ડેટાબેઝ દ્વારા પ્રક્રિયાની ગુણવત્તા દ્વારા નક્કી કરવામાં આવશે.

અસ્વીકરણ - જો આપણે સબડીબી સેટિંગ્સ વિશે ખાસ વાત કરીએ.

કારણ કે, સામાન્ય કિસ્સામાં, ઉદાહરણ તરીકે, ટેબ્યુલર ડેટા અને/અથવા ટેબ્યુલર મોડલ સાથે વપરાશકર્તાના કાર્યની ડિઝાઇનને કારણે, SQL સત્રો વચ્ચે વ્યવહારિક તાળાઓ હોઈ શકે છે.

જે, અલબત્ત, TPS મેટ્રિક પર નિરાશાજનક અસર કરશે અને સબડેટાબેઝની તુલનામાં આ એક બાહ્ય પરિબળ હશે: સારું, આ રીતે ટેબ્યુલર મોડેલ ડિઝાઇન કરવામાં આવ્યું હતું અને તેમાં ડેટા સાથેનું કાર્ય જે અવરોધો થાય છે.

તેથી, પ્રયોગની શુદ્ધતા માટે, અમે આ પરિબળને બાકાત રાખીશું, અને નીચે હું બરાબર કેવી રીતે સ્પષ્ટ કરીશ.

1. ચાલો, નિશ્ચિતતા માટે, માની લઈએ કે ડેટાબેઝમાં સબમિટ કરાયેલ 100% SQL આદેશો DML આદેશો છે.
   સબડેટાબેઝ સાથે વપરાશકર્તાના કામની લાક્ષણિકતાઓને પરીક્ષણોમાં સમાન રહેવા દો.
   જેમ કે: skl સત્રોની સંખ્યા, ટેબ્યુલર ડેટા, skl સત્રો તેમની સાથે કેવી રીતે કાર્ય કરે છે.
2. સબડી માં કામ કરે છે FORCE LOGGING, ARCHIVELOG મોડ્સ ફ્લેશબેક-ડેટાબેઝ મોડ સબડી સ્તરે બંધ છે.
3. લૉગ્સ ફરીથી કરો: અલગ ફાઇલ સિસ્ટમમાં સ્થિત છે, એક અલગ "ડિસ્ક" પર;
   ડેટાબેઝનો બાકીનો ભૌતિક ઘટક: બીજામાં, અલગ ફાઇલ સિસ્ટમ, અલગ "ડિસ્ક" પર:

ભૌતિક ઉપકરણ વિશે વધુ વિગતો. લેબોરેટરી ડેટાબેઝ ઘટકો

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 પદ્ધતિનો હેતુ પ્લેટફોર્મનું પરીક્ષણ કરવાનો છે
અરજી વિવાદ વિના. એક મહત્તમ હાર્ડવેર પ્રદર્શન ચલાવી શકતું નથી
એપ્લિકેશન કોડનો ઉપયોગ કરીને જે, ઉદાહરણ તરીકે, એપ્લિકેશન લોકીંગ દ્વારા અથવા તો બંધાયેલ છે
ઓરેકલ ડેટાબેઝ બ્લોક્સ શેર કરી રહ્યા છે. તે સાચું છે - ડેટા શેર કરતી વખતે ઓવરહેડ હોય છે
ડેટા બ્લોક્સમાં! પરંતુ SLOB-તેના ડિફોલ્ટ જમાવટમાં-આવા વિવાદથી પ્રતિરક્ષા છે.

આ ઘોષણા: અનુરૂપ છે, તે છે.
cl સત્રોની સમાનતાની ડિગ્રીનું નિયમન કરવું અનુકૂળ છે, આ ચાવી છે -t ઉપયોગિતા શરૂ કરો runit.sh SLOB થી
DML આદેશોની ટકાવારી, સબડી પર મોકલવામાં આવતા ટેક્સ્ટ સંદેશાઓની સંખ્યામાં, દરેક ટેક્સ્ટ સત્ર, પરિમાણમાં નિયમન કરવામાં આવે છે UPDATE_PCT
અલગ અને ખૂબ જ અનુકૂળ: SLOB પોતે, લોડ સત્ર પહેલા અને પછી - એક statspack, અથવા awr-સ્નેપશોટ (જે તૈયાર કરવા માટે સેટ છે) તૈયાર કરે છે.

જો કે, તે બહાર આવ્યું છે SLOB 30 સેકન્ડ કરતાં ઓછા સમયગાળા સાથે SQL સત્રોને સમર્થન આપતું નથી.
તેથી, મેં પહેલા લોડરનું મારું પોતાનું, કામદાર-ખેડૂત સંસ્કરણ કોડ કર્યું, અને પછી તે કાર્યરત રહ્યું.

મને સ્પષ્ટતા માટે લોડર શું કરે છે અને તે કેવી રીતે કરે છે તેની સ્પષ્ટતા કરવા દો.
આવશ્યકપણે લોડર આના જેવો દેખાય છે:

વર્કર કોડ

function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"

$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off

define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum

declare
 v_upto number;
 v_key  number;
 v_tots number;
 v_cts  number;
begin
 select max(col1) into v_upto from system.testtab_&&wnum;
 SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 v_tots := &&period + v_cts;
 while v_cts <= v_tots
 loop
  v_key:=abs(mod(dbms_random.random,v_upto));
  if v_key=0 then
   v_key:=1;
  end if;
  update system.testtab_&&wnum t
  set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
  where t.col1=v_key
  ;
  commit;
  SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 end loop;
end;
/

exit
__EOF__
}
export -f dotx

કામદારોને આ રીતે શરૂ કરવામાં આવે છે:

કામદારો ચલાવી રહ્યા છે

echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
 echo "sql-session: ${i}" >> "$v_logfile"
 dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
wait

અને કામદારો માટે કોષ્ટકો આ રીતે તૈયાર કરવામાં આવે છે:

કોષ્ટકો બનાવી રહ્યા છીએ

function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off

define wnum="$1"
define ts_name="slob"

begin
 execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/

create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable

seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"

તે. દરેક કાર્યકર માટે (વ્યવહારિક રીતે: ડીબીમાં એક અલગ SQL સત્ર) એક અલગ ટેબલ બનાવવામાં આવે છે, જેની સાથે કાર્યકર કામ કરે છે.

આ કાર્યકર સત્રો વચ્ચે વ્યવહારિક તાળાઓની ગેરહાજરીની ખાતરી કરે છે.
દરેક કાર્યકર: તે જ વસ્તુ કરે છે, તેના પોતાના ટેબલ સાથે, કોષ્ટકો બધા સમાન છે.
બધા કામદારો સમાન સમય માટે કામ કરે છે.
તદુપરાંત, પર્યાપ્ત લાંબા સમય માટે જેથી, ઉદાહરણ તરીકે, લોગ સ્વીચ ચોક્કસપણે થશે, અને એક કરતા વધુ વખત.
ઠીક છે, તે મુજબ, સંકળાયેલ ખર્ચ અને અસરો ઊભી થઈ.
મારા કિસ્સામાં, મેં કામદારોના કામનો સમયગાળો 8 મિનિટમાં ગોઠવ્યો છે.

લોડ હેઠળ સબડીની કામગીરીનું વર્ણન કરતા સ્ટેટસ્પેક રિપોર્ટનો એક ભાગ

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          2929910313 XE                  1 07-Sep-20 23:12 18.0.0.0.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     billing.izhevsk1 Linux x86 64-bit           2     2       1         15.6

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:       1630 07-Sep-20 23:12:27       55        .7
  End Snap:       1631 07-Sep-20 23:20:29       62        .6
   Elapsed:       8.03 (mins) Av Act Sess:       8.4
   DB time:      67.31 (mins)      DB CPU:      15.01 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:     1,392M              Std Block Size:         8K
     Shared Pool:       288M                  Log Buffer:   103,424K

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                8.4                0.0        0.00        0.20
       DB CPU(s):                1.9                0.0        0.00        0.04
       Redo size:        7,685,765.6              978.4
   Logical reads:           60,447.0                7.7
   Block changes:           47,167.3                6.0
  Physical reads:                8.3                0.0
 Physical writes:              253.4                0.0
      User calls:               42.6                0.0
          Parses:               23.2                0.0
     Hard parses:                1.2                0.0
W/A MB processed:                1.0                0.0
          Logons:                0.5                0.0
        Executes:           15,756.5                2.0
       Rollbacks:                0.0                0.0
    Transactions:            7,855.1

લેબોરેટરી કામ પર પાછા ફરો.
અમે, અન્ય વસ્તુઓ સમાન હોવાને કારણે, પ્રયોગશાળા સબડેટાબેઝના નીચેના પરિમાણોના મૂલ્યોમાં ફેરફાર કરીશું:

1. ડેટાબેઝ લોગ જૂથોનું કદ. મૂલ્ય શ્રેણી: [32, 1024] MB;
2. ડેટાબેઝમાં જર્નલ જૂથોની સંખ્યા. મૂલ્ય શ્રેણી: [2,32];
3. log_archive_max_processes મૂલ્ય શ્રેણી: [1,8];
4. commit_logging બે મૂલ્યોને મંજૂરી છે: batch|immediate;
5. commit_wait બે મૂલ્યોને મંજૂરી છે: wait|nowait;
6. log_buffer મૂલ્ય શ્રેણી: [2,128] MB.
7. log_checkpoint_timeout મૂલ્ય શ્રેણી: [60,1200] સેકન્ડ
8. db_writer_processes મૂલ્ય શ્રેણી: [1,4]
9. undo_retention મૂલ્ય શ્રેણી: [30;300] સેકન્ડ
10. transactions_per_rollback_segment મૂલ્ય શ્રેણી: [1,8]
11. disk_asynch_io બે મૂલ્યોને મંજૂરી છે: true|false;
12. filesystemio_options નીચેના મૂલ્યોને મંજૂરી છે: none|setall|directIO|asynch;
13. db_block_checking નીચેના મૂલ્યોને મંજૂરી છે: OFF|LOW|MEDIUM|FULL;
14. db_block_checksum નીચેના મૂલ્યોને મંજૂરી છે: OFF|TYPICAL|FULL;

ઓરેકલ ડેટાબેઝને જાળવવાનો અનુભવ ધરાવતી વ્યક્તિ ચોક્કસપણે પહેલેથી જ કહી શકે છે કે શું અને કયા મૂલ્યો સેટ કરવા જોઈએ, ઉલ્લેખિત પરિમાણો અને તેમના સ્વીકાર્ય મૂલ્યોમાંથી, ડેટા સાથેના કાર્ય માટે ડેટાબેઝની વધુ ઉત્પાદકતા મેળવવા માટે એપ્લિકેશન કોડ, અહીં ઉપર.

પણ.

પ્રયોગશાળાના કાર્યનો મુદ્દો એ બતાવવાનો છે કે ઑપ્ટિમાઇઝેશન અલ્ગોરિધમ પોતે જ આપણા માટે પ્રમાણમાં ઝડપથી આ સ્પષ્ટ કરશે.

અમારા માટે, કસ્ટમાઇઝ કરી શકાય તેવી સિસ્ટમ દ્વારા દસ્તાવેજમાં જોવાનું બાકી છે, ફક્ત તે શોધવા માટે પૂરતું છે કે કયા પરિમાણો બદલવા અને કઈ શ્રેણીમાં છે.
અને એ પણ: કોડને કોડ કરો જેનો ઉપયોગ પસંદ કરેલ ઑપ્ટિમાઇઝેશન અલ્ગોરિધમની કસ્ટમ સિસ્ટમ સાથે કામ કરવા માટે કરવામાં આવશે.

તેથી, હવે કોડ વિશે.
મેં ઉપર વાત કરી cran-r, એટલે કે: કસ્ટમાઇઝ્ડ સિસ્ટમ સાથેની તમામ મેનીપ્યુલેશન્સ 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 સબરૂટિન લક્ષણો ga અનિવાર્યપણે, સર્ચ સ્પેસનો વિસ્તાર નિર્દિષ્ટ કરેલ છે, જેની અંદર આવા વેક્ટર (અથવા વેક્ટર) માટે શોધ કરવામાં આવશે જેના માટે ફિટનેસ ફંક્શનનું મહત્તમ મૂલ્ય પ્રાપ્ત થશે.

ગા સબરૂટિન ફિટનેસ ફંક્શનને મહત્તમ કરવા માટે શોધ કરે છે.

સારું, તે પછી, તે તારણ આપે છે કે, આ કિસ્સામાં, તે જરૂરી છે કે ફિટનેસ ફંક્શન, સબડીના ચોક્કસ પરિમાણો માટેના મૂલ્યોના સમૂહ તરીકે વેક્ટરને સમજવું, સબડીમાંથી મેટ્રિક પ્રાપ્ત કરે છે.

એટલે કે: કેટલા, આપેલ સબડી સેટઅપ અને સબડી પર આપેલ લોડ સાથે: સબડી પ્રતિ સેકન્ડ વ્યવહારો પ્રક્રિયા કરે છે.

એટલે કે, જ્યારે પ્રગટ થાય છે, ત્યારે ફિટનેસ ફંક્શનની અંદર નીચેના મલ્ટિ-સ્ટેપ કરવું આવશ્યક છે:

1. સંખ્યાઓના ઇનપુટ વેક્ટર પર પ્રક્રિયા કરવી - તેને સબડેટા પરિમાણો માટે મૂલ્યોમાં રૂપાંતરિત કરવું.
2. આપેલ કદના રીડો જૂથોની આપેલ સંખ્યા બનાવવાનો પ્રયાસ. તદુપરાંત, પ્રયાસ નિષ્ફળ થઈ શકે છે.
   મેગેઝિન જૂથો જે પહેલાથી સબડીમાં અસ્તિત્વમાં છે, અમુક માત્રામાં અને અમુક કદમાં, પ્રયોગની શુદ્ધતા માટે - d.b. કાઢી નાખ્યું
3. જો પાછલો મુદ્દો સફળ છે: ડેટાબેઝમાં રૂપરેખાંકન પરિમાણોના મૂલ્યોનો ઉલ્લેખ કરવો (ફરીથી: ત્યાં નિષ્ફળતા હોઈ શકે છે)
4. જો પાછલું પગલું સફળ થાય છે: સબડીને રોકવું, સબડી શરૂ કરવું જેથી નવા ઉલ્લેખિત પેરામીટર મૂલ્યો પ્રભાવી થાય. (ફરીથી: ત્યાં કોઈ ખામી હોઈ શકે છે)
5. જો પાછલું પગલું સફળ છે: લોડ ટેસ્ટ કરો. સબડીમાંથી મેટ્રિક્સ મેળવો.
6. સબડીને તેની મૂળ સ્થિતિમાં પરત કરો, એટલે કે. વધારાના લોગ જૂથોને કાઢી નાખો, મૂળ સબડેટાબેઝ રૂપરેખાંકનને કાર્ય કરવા માટે પરત કરો.

ફિટનેસ ફંક્શન કોડ

evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
 opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")

opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
 opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")

opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
 opn$disk_asynch_io="false"
} 

opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
 opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
 opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
 opn$filesystemio_options="asynch"
}

opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
 opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
 opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
 opn$db_block_checking="FULL"
}

opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
 opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
 opn$db_block_checksum="FULL"
}

v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)

rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
 cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
 return (0)
}

v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) {  v_rc=1 }

if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("immediate")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("abort")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=run_test()
v_metric=getmetric()

rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}

તે. બધા કામ: ફિટનેસ ફંક્શનમાં કરવામાં આવે છે.

ગા-સબરૂટિન વેક્ટર અથવા, વધુ યોગ્ય રીતે, રંગસૂત્રોની પ્રક્રિયા કરે છે.
જેમાં, આપણા માટે જે સૌથી અગત્યનું છે તે જનીન સાથેના રંગસૂત્રોની પસંદગી છે જેના માટે ફિટનેસ ફંક્શન મોટા મૂલ્યો ઉત્પન્ન કરે છે.

આ, સારમાં, N-પરિમાણીય શોધ જગ્યામાં વેક્ટરનો ઉપયોગ કરીને રંગસૂત્રોના શ્રેષ્ઠ સમૂહને શોધવાની પ્રક્રિયા છે.

ખૂબ જ સ્પષ્ટ, વિગતવાર સમજૂતી, આર-કોડના ઉદાહરણો સાથે, આનુવંશિક અલ્ગોરિધમનું કાર્ય.

હું બે તકનીકી મુદ્દાઓને અલગથી નોંધવા માંગુ છું.

કાર્યમાંથી સહાયક કૉલ્સ evaluate, ઉદાહરણ તરીકે, સ્ટોપ-સ્ટાર્ટ, સબડી પેરામીટરનું મૂલ્ય સેટ કરવું, તેના આધારે કરવામાં આવે છે cran-r કાર્યો system2

જેની મદદથી: અમુક 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 હજાર ટીપીએસ: એક અલગ પ્રશ્ન.
પ્રયોગશાળાના કાર્યના માળખામાં, આ આંકડો મહત્વપૂર્ણ નથી, ગતિશીલતા શું છે, આ મૂલ્ય કેવી રીતે બદલાય છે તે મહત્વનું છે.

અહીંની ગતિશીલતા સારી છે.
તે સ્પષ્ટ છે કે ઓછામાં ઓછું એક પરિબળ મેટ્રિકના મૂલ્યને નોંધપાત્ર રીતે પ્રભાવિત કરે છે, ગા-એલ્ગોરિધમ, રંગસૂત્ર વેક્ટર દ્વારા વર્ગીકરણ: આવરી લેવામાં આવ્યું છે.
વળાંક મૂલ્યોની એકદમ ઉત્સાહી ગતિશીલતા દ્વારા અભિપ્રાય આપતા, ઓછામાં ઓછું એક વધુ પરિબળ છે, જે નોંધપાત્ર રીતે નાનું હોવા છતાં, પ્રભાવ ધરાવે છે.

આ તે છે જ્યાં તમને તેની જરૂર છે attribute-importance કયા લક્ષણો (સારી રીતે, આ કિસ્સામાં, ટ્યુનિંગ વેક્ટરના ઘટકો) અને તેઓ મેટ્રિક મૂલ્યને કેટલી અસર કરે છે તે સમજવા માટે વિશ્લેષણ.
અને આ માહિતીમાંથી: સમજો કે નોંધપાત્ર લક્ષણોમાં ફેરફારો દ્વારા કયા પરિબળો પ્રભાવિત થયા હતા.

ચલાવો attribute-importance વિવિધ રીતે શક્ય છે.

આ હેતુઓ માટે, મને અલ્ગોરિધમ ગમે છે randomForest સમાન નામનું R પેકેજ (દસ્તાવેજીકરણ)
randomForest, જેમ કે હું સામાન્ય રીતે તેમના કાર્યને સમજું છું અને ખાસ કરીને વિશેષતાઓના મહત્વનું મૂલ્યાંકન કરવા માટેનો તેમનો અભિગમ, વિશેષતાઓ પર પ્રતિભાવ ચલની અવલંબનનું ચોક્કસ મોડેલ બનાવે છે.

અમારા કિસ્સામાં, પ્રતિભાવ ચલ એ લોડ પરીક્ષણોમાં ડેટાબેઝમાંથી મેળવેલ મેટ્રિક છે: tps;
અને લક્ષણો ટ્યુનિંગ વેક્ટરના ઘટકો છે.

તેથી અહીં randomForest બે સંખ્યાઓ સાથે દરેક મોડેલ વિશેષતાના મહત્વનું મૂલ્યાંકન કરે છે: %IncMSE — મોડેલમાં આ લક્ષણની હાજરી/ગેરહાજરી આ મોડેલની MSE ગુણવત્તાને કેવી રીતે બદલે છે (મીન સ્ક્વેર્ડ એરર);

અને IncNodePurity એ એક સંખ્યા છે જે પ્રતિબિંબિત કરે છે કે આ વિશેષતાના મૂલ્યોના આધારે, અવલોકનો સાથેના ડેટાસેટને વિભાજિત કરી શકાય છે, જેથી એક ભાગમાં મેટ્રિકના એક મૂલ્ય સાથેનો ડેટા છે અને બીજા ભાગમાં મેટ્રિકનું બીજું મૂલ્ય.
સારું, તે છે: આ કેટલી હદ સુધી વર્ગીકૃત વિશેષતા છે (મેં રેન્ડમફોરેસ્ટ પર સૌથી સ્પષ્ટ, રશિયન-ભાષાની સમજૂતી જોઈ અહીં).

લોડ પરીક્ષણોના પરિણામો સાથે ડેટાસેટની પ્રક્રિયા કરવા માટે કામદાર-ખેડૂત આર-કોડ:

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, મુદ્દો મહત્વપૂર્ણ નથી.

પરિણામે, આ કિસ્સામાં, લક્ષણોના મહત્વની ડિગ્રીનું મૂલ્યાંકન કરવા માટે નીચેના પરિણામ પ્રાપ્ત થાય છે:

વેલ. આમ, આપણે વૈશ્વિક પ્રતિબિંબ શરૂ કરી શકીએ છીએ:

1. તે તારણ આપે છે કે આ પરીક્ષણ શરતો હેઠળ, સૌથી મહત્વપૂર્ણ પરિમાણ હતું commit_wait
   તકનીકી રીતે, તે સબડીબી લોગ બફરમાંથી વર્તમાન લોગ જૂથમાં રીડો ડેટા લખવાના io ઓપરેશનના એક્ઝેક્યુશન મોડને સ્પષ્ટ કરે છે: સિંક્રનસ અથવા અસુમેળ.
   કિંમત nowait જે tps મેટ્રિકના મૂલ્યમાં લગભગ ઊભી, બહુવિધ વધારામાં પરિણમે છે: આ રીડો જૂથોમાં અસુમેળ io મોડનો સમાવેશ છે.
   એક અલગ પ્રશ્ન એ છે કે તમારે ફૂડ ડેટાબેઝમાં આ કરવું જોઈએ કે નહીં. અહીં હું મારી જાતને ફક્ત કહેવા માટે મર્યાદિત કરું છું: આ એક મહત્વપૂર્ણ પરિબળ છે.
2. તે તાર્કિક છે કે સબડીના લોગ બફરનું કદ નોંધપાત્ર પરિબળ છે.
   લોગ બફરનું કદ જેટલું નાનું છે, તેની બફરિંગ ક્ષમતા જેટલી ઓછી છે, તેટલી વાર તે ઓવરફ્લો થાય છે અને/અથવા નવા રેડોક્સ ડેટાના ભાગ માટે તેમાં મુક્ત વિસ્તાર ફાળવવામાં અસમર્થતા.
   આનો અર્થ છે: લોગ બફરમાં જગ્યા ફાળવવામાં અને/અથવા તેમાંથી રીડો ડેટાને ફરીથી કરો જૂથોમાં ડમ્પ કરવા સાથે સંકળાયેલ વિલંબ.
   આ વિલંબ, અલબત્ત, વ્યવહારો માટે ડેટાબેઝના થ્રુપુટને અસર કરે છે અને કરે છે.
3. પેરામીટર db_block_checksum: સારું, પણ, સામાન્ય રીતે તે સ્પષ્ટ છે - ટ્રાન્ઝેક્શન પ્રોસેસિંગ સબડેટાબેઝના બફર કેશમાં ડાર્ટી બ્લોક્સની રચના તરફ દોરી જાય છે.
   જે, જ્યારે ડેટાબ્લોકના ચેકસમ્સની ચકાસણી સક્ષમ હોય, ત્યારે ડેટાબેસે પ્રક્રિયા કરવાની હોય છે - ડેટાબ્લોકના મુખ્ય ભાગમાંથી આ ચેકસમ્સની ગણતરી કરવી, ડેટાબ્લોક હેડરમાં શું લખ્યું છે તેની સાથે તેમને તપાસો: મેચ/મેળ નથી.
   આવા કાર્ય, ફરીથી, ડેટા પ્રોસેસિંગમાં વિલંબ કરી શકતા નથી, અને તે મુજબ, પેરામીટર અને મિકેનિઝમ જે આ પરિમાણને સેટ કરે છે તે નોંધપાત્ર હોવાનું બહાર આવ્યું છે.
   તેથી જ વિક્રેતા ઓફર કરે છે, આ પરિમાણ માટેના દસ્તાવેજીકરણમાં, વિવિધ મૂલ્યો અને નોંધો કે હા, ત્યાં અસર થશે, પરંતુ તમે વિવિધ મૂલ્યો, "બંધ" અને વિવિધ અસરો પણ પસંદ કરી શકો છો.

સારું, વૈશ્વિક નિષ્કર્ષ.

અભિગમ, સામાન્ય રીતે, તદ્દન કાર્યકારી હોવાનું બહાર આવ્યું છે.

તે ચોક્કસ સેવા સિસ્ટમના લોડ પરીક્ષણના પ્રારંભિક તબક્કામાં, લોડ માટે તેની (સિસ્ટમ) શ્રેષ્ઠ રૂપરેખાંકન પસંદ કરવા માટે, લોડ માટે સિસ્ટમ સેટ કરવાની વિશિષ્ટતાઓમાં વધુ પડતી તપાસ ન કરવા માટે, પોતાને તદ્દન પરવાનગી આપે છે.

પરંતુ તે તેને સંપૂર્ણપણે બાકાત કરતું નથી - ઓછામાં ઓછું સમજણના સ્તરે: સિસ્ટમ "એડજસ્ટમેન્ટ નોબ્સ" અને આ નોબ્સના પરિભ્રમણની અનુમતિપાત્ર શ્રેણીઓ વિશે જાણતી હોવી જોઈએ.

અભિગમ પછી પ્રમાણમાં ઝડપથી શ્રેષ્ઠ સિસ્ટમ રૂપરેખાંકન શોધી શકે છે.
અને પરીક્ષણના પરિણામોના આધારે, સિસ્ટમ પ્રદર્શન મેટ્રિક્સ અને સિસ્ટમ સેટિંગ્સ પરિમાણોના મૂલ્યો વચ્ચેના સંબંધની પ્રકૃતિ વિશેની માહિતી મેળવવાનું શક્ય છે.

જે, અલબત્ત, સિસ્ટમની આ ખૂબ જ ઊંડી સમજણના ઉદભવમાં ફાળો આપવો જોઈએ, તેની કામગીરી, ઓછામાં ઓછા આપેલ ભાર હેઠળ.

વ્યવહારમાં, આ સિસ્ટમના આવા પરીક્ષણ તૈયાર કરવાના ખર્ચ માટે કસ્ટમાઇઝ્ડ સિસ્ટમને સમજવાના ખર્ચનું વિનિમય છે.

હું અલગથી નોંધવા માંગુ છું: આ અભિગમમાં, તે વ્યવસાયિક કામગીરીમાં હશે તે ઓપરેટિંગ પરિસ્થિતિઓ માટે સિસ્ટમ પરીક્ષણની પર્યાપ્તતાની ડિગ્રી વિવેચનાત્મક રીતે મહત્વપૂર્ણ છે.

તમારા ધ્યાન અને સમય બદલ આભાર.

સોર્સ: www.habr.com