శాస్త్రీయ పోక్ పద్ధతి, లేదా బెంచ్‌మార్క్‌లు మరియు ఆప్టిమైజేషన్ అల్గారిథమ్‌ని ఉపయోగించి డేటాబేస్ కాన్ఫిగరేషన్‌ను ఎలా ఎంచుకోవాలి

హలో

నేను నా అన్వేషణను పంచుకోవాలని నిర్ణయించుకున్నాను - ఆలోచన, విచారణ మరియు లోపం యొక్క ఫలం.
పెద్దగా: ఇది అన్వేషణ కాదు, వాస్తవానికి - అనువర్తిత గణాంక డేటా ప్రాసెసింగ్ మరియు ఏదైనా సిస్టమ్‌ల ఆప్టిమైజేషన్‌లో నిమగ్నమైన వారికి, ప్రత్యేకంగా DBMS అవసరం లేని వారికి ఇది చాలా కాలంగా తెలిసి ఉండాలి.
మరియు: అవును, వారికి తెలుసు, వారు తమ పరిశోధనపై ఆసక్తికరమైన కథనాలను వ్రాస్తారు, ఒక ఉదాహరణ (UPD.: వ్యాఖ్యలలో వారు చాలా ఆసక్తికరమైన ప్రాజెక్ట్‌ను ఎత్తి చూపారు: ఒటర్ట్యూన్ )
మరోవైపు: IT నిపుణులు, DBAలో ఇంటర్నెట్‌లో ఈ విధానం గురించి విస్తృతంగా ప్రస్తావించడం లేదా వ్యాప్తి చేయడం నాకు కనిపించడం లేదు.

కాబట్టి, పాయింట్ వరకు.

మనకు ఒక పని ఉందని అనుకుందాం: ఒక రకమైన పనిని అందించడానికి నిర్దిష్ట సేవా వ్యవస్థను సెటప్ చేయడం.

ఈ పని గురించి ఇది తెలుసు: ఇది ఏమిటి, ఈ పని యొక్క నాణ్యతను ఎలా కొలుస్తారు మరియు ఈ నాణ్యతను కొలిచే ప్రమాణం ఏమిటి.

ఇది ఎక్కువ లేదా తక్కువ తెలిసినట్లు మరియు అర్థం చేసుకున్నట్లు కూడా అనుకుందాం: ఈ సేవా వ్యవస్థలో (లేదా దానితో) పని ఎలా జరుగుతుంది.

“ఎక్కువ లేదా తక్కువ” - దీనర్థం ఒక నిర్దిష్ట సాధనం, యుటిలిటీ, సేవను సిద్ధం చేయడం (లేదా ఎక్కడి నుండైనా పొందడం) సాధ్యమవుతుంది, ఇది ఉత్పత్తిలో ఉన్నదానికి తగినంత పరీక్ష లోడ్‌తో సిస్టమ్‌కు సంశ్లేషణ చేయబడుతుంది మరియు వర్తించబడుతుంది, ఉత్పత్తిలో పనిచేయడానికి తగిన పరిస్థితులలో.

బాగా, ఈ సేవా వ్యవస్థ కోసం సర్దుబాటు పారామితుల సమితి తెలిసినట్లు అనుకుందాం, దాని పని యొక్క ఉత్పాదకత పరంగా ఈ వ్యవస్థను కాన్ఫిగర్ చేయడానికి ఇది ఉపయోగించబడుతుంది.

మరియు సమస్య ఏమిటి - ఈ సేవా వ్యవస్థపై తగినంత పూర్తి అవగాహన లేదు, ఇచ్చిన ప్లాట్‌ఫారమ్‌పై భవిష్యత్తులో లోడ్ చేయడానికి మరియు సిస్టమ్ యొక్క అవసరమైన ఉత్పాదకతను పొందడానికి ఈ సిస్టమ్ యొక్క సెట్టింగ్‌లను నైపుణ్యంగా కాన్ఫిగర్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.

బాగా. ఇది దాదాపు ఎల్లప్పుడూ కేసు.

మీరు ఇక్కడ ఏమి చేయవచ్చు?

సరే, ఈ సిస్టమ్ కోసం డాక్యుమెంటేషన్‌ను చూడటం అనేది మనసులో వచ్చే మొదటి విషయం. సర్దుబాటు పారామితుల విలువలకు ఆమోదయోగ్యమైన పరిధులు ఏమిటో అర్థం చేసుకోండి. మరియు, ఉదాహరణకు, కోఆర్డినేట్ డీసెంట్ పద్ధతిని ఉపయోగించి, పరీక్షలలో సిస్టమ్ పారామితుల కోసం విలువలను ఎంచుకోండి.

ఆ. సిస్టమ్‌కు దాని కాన్ఫిగరేషన్ పారామితుల కోసం నిర్దిష్ట విలువల రూపంలో ఒక రకమైన కాన్ఫిగరేషన్ ఇవ్వండి.

ఈ టూల్-యుటిలిటీ, లోడ్ జెనరేటర్‌ని ఉపయోగించి దానికి టెస్ట్ లోడ్‌ను వర్తింపజేయండి.
మరియు విలువను చూడండి - ప్రతిస్పందన, లేదా సిస్టమ్ నాణ్యత యొక్క మెట్రిక్.

రెండవ ఆలోచన ఇది చాలా కాలం అని ముగింపు కావచ్చు.

బాగా, అంటే: చాలా సెట్టింగ్ పారామితులు ఉంటే, వాటి విలువల పరిధులు పెద్దవిగా ఉంటే, ప్రతి వ్యక్తి లోడ్ పరీక్ష పూర్తి చేయడానికి చాలా సమయం తీసుకుంటే, అప్పుడు: అవును, ఇదంతా ఆమోదయోగ్యం కాదు. చాలా కాలం.

సరే, మీరు అర్థం చేసుకోగలిగేది మరియు గుర్తుంచుకోగలిగేది ఇక్కడ ఉంది.

సేవా సిస్టమ్ సెట్టింగుల పారామితుల యొక్క విలువల సెట్‌లో కొన్ని విలువల క్రమం వలె వెక్టర్ ఉందని మీరు కనుగొనవచ్చు.

అటువంటి ప్రతి వెక్టర్, ఇతర విషయాలు సమానంగా ఉండటం (ఈ వెక్టర్ ద్వారా ఇది ప్రభావితం కాదు), మెట్రిక్ యొక్క పూర్తిగా ఖచ్చితమైన విలువకు అనుగుణంగా ఉంటుంది - ఇది టెస్ట్ లోడ్ కింద సిస్టమ్ యొక్క ఆపరేషన్ నాణ్యత యొక్క సూచిక.

అంటే

సిస్టమ్ కాన్ఫిగరేషన్ వెక్టార్‌ని ఇలా సూచిస్తాము పేరు ; ఎక్కడ — సిస్టమ్ కాన్ఫిగరేషన్ పారామితుల సంఖ్య, ఈ పారామితులు ఎన్ని ఉన్నాయి.

మరియు దీనికి సంబంధించిన మెట్రిక్ విలువ దానిని ఇలా సూచిస్తాం
, అప్పుడు మనకు ఒక ఫంక్షన్ వస్తుంది:

బాగా, అప్పుడు: నా విషయంలో ప్రతిదీ వెంటనే క్రిందికి వస్తుంది: నా విద్యార్థి రోజుల నుండి దాదాపు మర్చిపోయి, ఫంక్షన్ యొక్క అంత్య భాగాల కోసం శోధించడానికి అల్గారిథమ్‌లు.

సరే, కానీ ఇక్కడ సంస్థాగత మరియు అనువర్తిత ప్రశ్న తలెత్తుతుంది: ఏ అల్గారిథమ్ ఉపయోగించాలి.

1. అర్థంలో - మీరు చేతితో తక్కువ కోడ్ చేయవచ్చు.
2. మరియు అది పని చేయడానికి, అనగా. కోఆర్డినేట్ అవరోహణ కంటే కనీసం వేగంగా (ఒకవేళ ఉంటే) ఎక్స్‌ట్రంమ్‌ను కనుగొన్నారు.

అటువంటి అల్గారిథమ్‌లు ఇప్పటికే అమలు చేయబడి, కోడ్‌లో ఉపయోగించడానికి సిద్ధంగా ఉన్న కొన్ని వాతావరణాల వైపు మనం చూడవలసిన అవసరం ఉందని మొదటి పాయింట్ సూచిస్తుంది.
బాగా, నాకు తెలుసు python и cran-r

రెండవ అంశం ఏమిటంటే, మీరు అల్గారిథమ్‌ల గురించి, అవి ఏమిటి, వాటి అవసరాలు ఏమిటి మరియు వారి పని యొక్క లక్షణాల గురించి చదవాలి.

మరియు వారు ఇచ్చేవి ఉపయోగకరమైన దుష్ప్రభావాలు కావచ్చు - ఫలితాలు, లేదా నేరుగా అల్గోరిథం నుండి.

లేదా అల్గోరిథం ఫలితాల నుండి వాటిని పొందవచ్చు.

చాలా ఇన్పుట్ పరిస్థితులపై ఆధారపడి ఉంటుంది.

ఉదాహరణకు, కొన్ని కారణాల వల్ల, మీరు ఫలితాన్ని వేగంగా పొందాలంటే, మీరు గ్రేడియంట్ డీసెంట్ అల్గారిథమ్‌ల వైపు చూసి వాటిలో ఒకదాన్ని ఎంచుకోవాలి.

లేదా, సమయం అంత ముఖ్యమైనది కానట్లయితే, మీరు ఉదాహరణకు, జన్యు అల్గోరిథం వంటి యాదృచ్ఛిక ఆప్టిమైజేషన్ పద్ధతులను ఉపయోగించవచ్చు.

ఈ విధానం యొక్క పనిని పరిగణించాలని నేను ప్రతిపాదిస్తున్నాను, సిస్టమ్ కాన్ఫిగరేషన్‌ను ఎంచుకోవడం, జన్యు అల్గోరిథం ఉపయోగించి, తదుపరిది మాట్లాడటానికి: ప్రయోగశాల పని.

అసలు:

1. సేవా వ్యవస్థగా ఉండనివ్వండి: oracle xe 18c
2. ఇది లావాదేవీల కార్యకలాపాన్ని మరియు లక్ష్యాన్ని అందించనివ్వండి: లావాదేవీలు/సెకనులో సబ్‌డేటాబేస్ యొక్క సాధ్యమైన అత్యధిక నిర్గమాంశను పొందడం.
3. డేటాతో పని చేసే స్వభావం మరియు పని సందర్భంలో లావాదేవీలు చాలా భిన్నంగా ఉంటాయి.
   ఇవి పెద్ద మొత్తంలో పట్టిక డేటాను ప్రాసెస్ చేయని లావాదేవీలు అని అంగీకరిస్తాం.
   అవి మళ్లీ చేయడం కంటే ఎక్కువ అన్‌డు డేటాను ఉత్పత్తి చేయవు మరియు ఎక్కువ శాతం అడ్డు వరుసలు మరియు పెద్ద పట్టికలను ప్రాసెస్ చేయవు.

ఇవి ఈ పట్టికలో తక్కువ సంఖ్యలో సూచికలతో ఎక్కువ లేదా తక్కువ పెద్ద పట్టికలో ఒక అడ్డు వరుసను మార్చే లావాదేవీలు.

ఈ పరిస్థితిలో: ప్రాసెసింగ్ లావాదేవీల కోసం సబ్‌డేటాబేస్ యొక్క ఉత్పాదకత, రిజర్వేషన్‌తో, రెడాక్స్ డేటాబేస్ ద్వారా ప్రాసెసింగ్ నాణ్యత ద్వారా నిర్ణయించబడుతుంది.

నిరాకరణ - మేము సబ్‌డిబి సెట్టింగ్‌ల గురించి ప్రత్యేకంగా మాట్లాడినట్లయితే.

ఎందుకంటే, సాధారణ సందర్భంలో, ఉదాహరణకు, పట్టిక డేటా మరియు/లేదా పట్టిక మోడల్‌తో వినియోగదారు పని రూపకల్పన కారణంగా SQL సెషన్‌ల మధ్య లావాదేవీ తాళాలు ఉండవచ్చు.

వాస్తవానికి, ఇది TPS మెట్రిక్‌పై నిరుత్సాహపరిచే ప్రభావాన్ని కలిగి ఉంటుంది మరియు ఇది సబ్‌డేటాబేస్‌కు సంబంధించి ఒక బాహ్య కారకంగా ఉంటుంది: అలాగే, పట్టిక మోడల్‌ను ఈ విధంగా రూపొందించారు మరియు దానిలోని డేటాతో పని చేయడం వల్ల అడ్డంకులు ఏర్పడతాయి.

అందువలన, ప్రయోగం యొక్క స్వచ్ఛత కోసం, మేము ఈ కారకాన్ని మినహాయిస్తాము మరియు క్రింద నేను ఖచ్చితంగా ఎలా స్పష్టం చేస్తాను.

1. డేటాబేస్‌కు సమర్పించిన SQL కమాండ్‌లలో 100% 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 స్వయంగా, లోడ్ సెషన్‌కు ముందు మరియు తర్వాత - స్టాట్‌స్పాక్ లేదా 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"

ఆ. ప్రతి కార్మికునికి (ఆచరణాత్మకంగా: DBలో ప్రత్యేక 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 పరిమాణాలు - పూర్ణాంకాలు మరియు స్ట్రింగ్ విలువలు.

స్ట్రింగ్ విలువలకు కొన్ని నిర్దిష్ట సంఖ్యలను కేటాయించడం ద్వారా సమస్య సులభంగా నివారించబడుతుంది.

అందువలన, చివరికి, 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 subroutine లక్షణాలు ga ముఖ్యంగా, శోధన స్థలం యొక్క ప్రాంతం పేర్కొనబడింది, దానిలో ఫిట్‌నెస్ ఫంక్షన్ యొక్క గరిష్ట విలువ పొందబడే అటువంటి వెక్టర్ (లేదా వెక్టర్స్) కోసం శోధన జరుగుతుంది.

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)
}

ఆ. అన్ని పని: ఫిట్‌నెస్ ఫంక్షన్‌లో ప్రదర్శించబడింది.

ga-సబ్రౌటిన్ వెక్టర్స్ లేదా, మరింత సరిగ్గా, క్రోమోజోమ్‌లను ప్రాసెస్ చేస్తుంది.
దీనిలో, ఫిట్‌నెస్ ఫంక్షన్ పెద్ద విలువలను ఉత్పత్తి చేసే జన్యువులతో కూడిన క్రోమోజోమ్‌ల ఎంపిక మనకు చాలా ముఖ్యమైనది.

ఇది సారాంశంలో, N-డైమెన్షనల్ సెర్చ్ స్పేస్‌లో వెక్టర్‌ని ఉపయోగించి క్రోమోజోమ్‌ల యొక్క సరైన సెట్ కోసం శోధించే ప్రక్రియ.

చాలా స్పష్టంగా, వివరంగా వివరణ, R- కోడ్ యొక్క ఉదాహరణలతో, జన్యు అల్గోరిథం యొక్క పని.

నేను రెండు సాంకేతిక అంశాలను విడిగా గమనించాలనుకుంటున్నాను.

ఫంక్షన్ నుండి సహాయక కాల్స్ evaluate, ఉదాహరణకు, స్టాప్-స్టార్ట్, సబ్‌డి పరామితి యొక్క విలువను సెట్ చేయడం ఆధారంగా నిర్వహిస్తారు cran-r విధులు system2

దీని సహాయంతో: కొన్ని బాష్ స్క్రిప్ట్ లేదా కమాండ్ అంటారు.

ఉదాహరణకు:

set_db_parameter

set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")

x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
 cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (attributes(x)$status)
}
else {
 cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (0)
}
}

రెండవ పాయింట్ లైన్, evaluate విధులు, నిర్దిష్ట మెట్రిక్ విలువను మరియు దాని సంబంధిత ట్యూనింగ్ వెక్టార్‌ను లాగ్ ఫైల్‌కు సేవ్ చేయడంతో:

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

ఇది ముఖ్యమైనది, ఎందుకంటే ఈ డేటా శ్రేణి నుండి, ట్యూనింగ్ వెక్టర్ యొక్క ఏ భాగాలు మెట్రిక్ విలువపై ఎక్కువ లేదా తక్కువ ప్రభావాన్ని కలిగి ఉంటాయనే దాని గురించి అదనపు సమాచారాన్ని పొందడం సాధ్యమవుతుంది.

అంటే: లక్షణం-ప్రాముఖ్యత విశ్లేషణ నిర్వహించడం సాధ్యమవుతుంది.

కాబట్టి ఏమి జరగవచ్చు?

గ్రాఫ్ రూపంలో, మీరు పరీక్షలను ఆరోహణ మెట్రిక్ క్రమంలో ఆర్డర్ చేస్తే, చిత్రం క్రింది విధంగా ఉంటుంది:

మెట్రిక్ యొక్క విపరీతమైన విలువలకు సంబంధించిన కొన్ని డేటా:

ఇక్కడ, ఫలితాలతో స్క్రీన్‌షాట్‌లో, నేను స్పష్టం చేస్తాను: ట్యూనింగ్ వెక్టర్ యొక్క విలువలు ఫిట్‌నెస్ ఫంక్షన్ కోడ్ పరంగా ఇవ్వబడ్డాయి, పారామితులు / పారామీటర్ విలువల శ్రేణుల సంఖ్య జాబితా పరంగా కాదు, ఇది రూపొందించబడింది వచనంలో పైన.

బాగా. ఇది చాలా లేదా కొంచెం, ~ 8 వేల tps: ఒక ప్రత్యేక ప్రశ్న.
ప్రయోగశాల పని యొక్క చట్రంలో, ఈ సంఖ్య ముఖ్యమైనది కాదు, ముఖ్యమైనది డైనమిక్స్, ఈ విలువ ఎలా మారుతుంది.

ఇక్కడ డైనమిక్స్ బాగున్నాయి.
క్రోమోజోమ్ వెక్టర్స్ ద్వారా క్రమబద్ధీకరించబడిన మెట్రిక్, గా-అల్గోరిథం యొక్క విలువను కనీసం ఒక అంశం గణనీయంగా ప్రభావితం చేస్తుందని స్పష్టంగా తెలుస్తుంది: కవర్.
వక్రత విలువల యొక్క చాలా శక్తివంతమైన డైనమిక్స్ ద్వారా నిర్ణయించడం, గణనీయంగా చిన్నది అయినప్పటికీ, ప్రభావం చూపే మరో అంశం కూడా ఉంది.

ఇది మీకు అవసరం attribute-importance ఏ లక్షణాలను (అలాగే, ఈ సందర్భంలో, ట్యూనింగ్ వెక్టర్ యొక్క భాగాలు) మరియు అవి మెట్రిక్ విలువను ఎంత ప్రభావితం చేస్తాయో అర్థం చేసుకోవడానికి విశ్లేషణ.
మరియు ఈ సమాచారం నుండి: ముఖ్యమైన లక్షణాలలో మార్పుల ద్వారా ఏ కారకాలు ప్రభావితమయ్యాయో అర్థం చేసుకోండి.

రన్ attribute-importance వివిధ మార్గాల్లో సాధ్యం.

ఈ ప్రయోజనాల కోసం, నేను అల్గోరిథంను ఇష్టపడుతున్నాను randomForest అదే పేరుతో R ప్యాకేజీ (డాక్యుమెంటేషన్)
randomForest, నేను అతని పనిని సాధారణంగా అర్థం చేసుకున్నాను మరియు ప్రత్యేకించి లక్షణాల ప్రాముఖ్యతను అంచనా వేయడానికి అతని విధానం, లక్షణాలపై ప్రతిస్పందన వేరియబుల్ యొక్క ఆధారపడటం యొక్క నిర్దిష్ట నమూనాను రూపొందిస్తుంది.

మా విషయంలో, ప్రతిస్పందన వేరియబుల్ అనేది లోడ్ పరీక్షలలో డేటాబేస్ నుండి పొందిన మెట్రిక్: tps;
మరియు గుణాలు ట్యూనింగ్ వెక్టర్ యొక్క భాగాలు.

కాబట్టి ఇక్కడ randomForest రెండు సంఖ్యలతో ప్రతి మోడల్ లక్షణం యొక్క ప్రాముఖ్యతను అంచనా వేస్తుంది: %IncMSE — మోడల్‌లో ఈ లక్షణం యొక్క ఉనికి/లేకపోవడం ఈ మోడల్ యొక్క MSE నాణ్యతను ఎలా మారుస్తుంది (మీన్ స్క్వేర్డ్ ఎర్రర్);

మరియు IncNodePurity అనేది ఈ లక్షణం యొక్క విలువల ఆధారంగా, పరిశీలనలతో కూడిన డేటాసెట్‌ను ఎంత బాగా విభజించవచ్చో ప్రతిబింబించే సంఖ్య, తద్వారా ఒక భాగంలో మెట్రిక్ యొక్క ఒక విలువతో డేటా ఉంటుంది మరియు మరొక దానితో ఉంటుంది మెట్రిక్ యొక్క మరొక విలువ.
సరే, అంటే: ఇది ఏ మేరకు వర్గీకరించే లక్షణం (నేను రాండమ్‌ఫారెస్ట్‌లో అత్యంత స్పష్టమైన, రష్యన్ భాషలో వివరణను చూశాను. ఇక్కడ).

లోడ్ పరీక్షల ఫలితాలతో డేటాసెట్‌ను ప్రాసెస్ చేయడానికి కార్మికుడు-రైతు 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, పాయింట్ కాదు ముఖ్యం.

ఫలితంగా, ఈ సందర్భంలో, లక్షణాల యొక్క ప్రాముఖ్యత స్థాయిని అంచనా వేయడానికి క్రింది ఫలితం పొందబడుతుంది:

బాగా. అందువలన, మేము ప్రపంచ ప్రతిబింబం ప్రారంభించవచ్చు:

1. ఈ పరీక్ష పరిస్థితులలో అత్యంత ముఖ్యమైనది పరామితి అని తేలింది commit_wait
   సాంకేతికంగా, ఇది సబ్‌డిబి లాగ్ బఫర్ నుండి ప్రస్తుత లాగ్ గ్రూప్‌కు రిడో డేటాను వ్రాయడం యొక్క io ఆపరేషన్ యొక్క ఎగ్జిక్యూషన్ మోడ్‌ను నిర్దేశిస్తుంది: సింక్రోనస్ లేదా ఎసిన్క్రోనస్.
   విలువ nowait ఇది దాదాపుగా నిలువుగా, tps మెట్రిక్ విలువలో బహుళ పెరుగుదలకు దారి తీస్తుంది: ఇది పునరావృత సమూహాలలో అసమకాలిక io మోడ్‌ని చేర్చడం.
   మీరు దీన్ని ఆహార డేటాబేస్‌లో చేయాలా వద్దా అనేది ప్రత్యేక ప్రశ్న. ఇక్కడ నేను కేవలం పేర్కొనడానికి పరిమితం చేస్తున్నాను: ఇది ఒక ముఖ్యమైన అంశం.
2. సబ్‌డి యొక్క లాగ్ బఫర్ పరిమాణం: ఒక ముఖ్యమైన అంశంగా మారడం తార్కికం.
   లాగ్ బఫర్ యొక్క పరిమాణం చిన్నది, దాని బఫరింగ్ సామర్థ్యం తక్కువగా ఉంటుంది, తరచుగా అది పొంగిపొర్లుతుంది మరియు/లేదా కొత్త రెడాక్స్ డేటాలో కొంత భాగానికి దానిలో ఉచిత ప్రాంతాన్ని కేటాయించలేకపోవడం.
   దీనర్థం: లాగ్ బఫర్‌లో స్థలాన్ని కేటాయించడం మరియు/లేదా దాని నుండి పునరావృతం చేసే డేటాను పునరావృత సమూహాలలోకి డంప్ చేయడంతో సంబంధించిన ఆలస్యం.
   ఈ జాప్యాలు, వాస్తవానికి, లావాదేవీల కోసం డేటాబేస్ యొక్క నిర్గమాంశను ప్రభావితం చేయాలి.
3. పరామితి db_block_checksum: అలాగే, సాధారణంగా ఇది స్పష్టంగా ఉంది - లావాదేవీ ప్రాసెసింగ్ సబ్‌డేటాబేస్ యొక్క బఫర్ కాష్‌లో డార్టీ బ్లాక్‌ల ఏర్పాటుకు దారితీస్తుంది.
   ఇది, డేటాబ్లాక్‌ల చెక్‌సమ్‌లను తనిఖీ చేయడం ప్రారంభించబడినప్పుడు, డేటాబేస్ ప్రాసెస్ చేయాలి - డేటాబ్లాక్ యొక్క శరీరం నుండి ఈ చెక్‌సమ్‌లను లెక్కించండి, డేటాబ్లాక్ హెడర్‌లో వ్రాసిన వాటితో వాటిని తనిఖీ చేయండి: మ్యాచ్‌లు/ సరిపోలడం లేదు.
   అటువంటి పని, మళ్ళీ, డేటా ప్రాసెసింగ్‌ను ఆలస్యం చేయదు మరియు తదనుగుణంగా, ఈ పరామితిని సెట్ చేసే పరామితి మరియు యంత్రాంగం ముఖ్యమైనవిగా మారతాయి.
   అందుకే విక్రేత ఈ పరామితి కోసం డాక్యుమెంటేషన్‌లో విభిన్న విలువలు మరియు గమనికలను అందిస్తుంది, అవును, ప్రభావం ఉంటుంది, కానీ మీరు వేర్వేరు విలువలను ఎంచుకోవచ్చు, "ఆఫ్" మరియు విభిన్న ప్రభావాలను కూడా.

బాగా, ఒక ప్రపంచ ముగింపు.

విధానం, సాధారణంగా, చాలా పని చేస్తుంది.

అతను ఒక నిర్దిష్ట సేవా వ్యవస్థ యొక్క లోడ్ పరీక్ష యొక్క ప్రారంభ దశలలో, లోడ్ కోసం దాని (సిస్టమ్) సరైన కాన్ఫిగరేషన్‌ను ఎంచుకోవడానికి, లోడ్ కోసం సిస్టమ్‌ను సెటప్ చేసే ప్రత్యేకతలను ఎక్కువగా పరిశోధించకుండా తనను తాను అనుమతిస్తుంది.

కానీ అది పూర్తిగా మినహాయించలేదు - కనీసం అవగాహన స్థాయిలో: సిస్టమ్ తప్పనిసరిగా “సర్దుబాటు గుబ్బలు” మరియు ఈ గుబ్బల భ్రమణ యొక్క అనుమతించదగిన పరిధుల గురించి తెలుసుకోవాలి.

ఈ విధానం చాలా త్వరగా సరైన సిస్టమ్ కాన్ఫిగరేషన్‌ను కనుగొనగలదు.
మరియు పరీక్ష ఫలితాల ఆధారంగా, సిస్టమ్ పనితీరు కొలమానాలు మరియు సిస్టమ్ సెట్టింగ్‌ల పారామితుల విలువల మధ్య సంబంధం యొక్క స్వభావం గురించి సమాచారాన్ని పొందడం సాధ్యమవుతుంది.

ఇది, వాస్తవానికి, సిస్టమ్ యొక్క ఈ లోతైన అవగాహన, దాని ఆపరేషన్, కనీసం ఇచ్చిన లోడ్ కింద ఆవిర్భావానికి దోహదం చేస్తుంది.

ఆచరణలో, ఇది సిస్టమ్ యొక్క అటువంటి పరీక్షను సిద్ధం చేసే ఖర్చుల కోసం అనుకూలీకరించిన వ్యవస్థను అర్థం చేసుకునే ఖర్చుల మార్పిడి.

నేను విడిగా గమనించదలిచాను: ఈ విధానంలో, వాణిజ్య ఆపరేషన్‌లో కలిగి ఉండే ఆపరేటింగ్ పరిస్థితులకు సిస్టమ్ టెస్టింగ్ యొక్క సమర్ధత స్థాయి విమర్శనాత్మకంగా ముఖ్యమైనది.

మీ శ్రద్ధ మరియు సమయానికి ధన్యవాదాలు.

మూలం: www.habr.com