🥇שיטת חיטוט מדעית, או כיצד לבחור תצורת תת מסד נתונים באמצעות מדדים ואלגוריתם אופטימיזציה

שלום

החלטתי לשתף בממצא שלי - פרי מחשבה, ניסוי וטעייה.
בגדול: זה לא ממצא כמובן - כל זה היה צריך להיות ידוע מזמן, למי שעוסק בעיבוד נתונים סטטיסטיים יישומי ואופטימיזציה של מערכות כלשהן, לאו דווקא ה-DBMS.
וכן: כן, הם יודעים, הם כותבים מאמרים מעניינים על המחקר שלהם, דוגמה (UPD.: בהערות הם הצביעו על פרויקט מאוד מעניין: ottertune )
מצד שני: ישר אני לא רואה איזכור או הפצה נרחבת של גישה זו באינטרנט בקרב מומחי IT, DBA.

אז, לעניין.

בוא נניח שיש לנו משימה: להקים מערכת שירות מסוימת שתשרת סוג של עבודה.

ידוע על עבודה זו: מהי, איך נמדדת איכות העבודה הזו ומהו הקריטריון למדידת איכות זו.

בואו גם נניח שזה פחות או יותר ידוע ומובן: איך בדיוק מתבצעת העבודה במערכת השירות הזו (או עם).

"פחות או יותר" - זה אומר שאפשר להכין (או להשיג אותו מאיפשהו) כלי מסוים, שירות, שירות שניתן לסנתז ולהחיל על המערכת עם עומס בדיקה מספיק מתאים למה שיהיה בייצור, בתנאים מספיקים לעבודה בייצור.

ובכן, נניח שידוע קבוצה של פרמטרי התאמה עבור מערכת שירות זו, אשר ניתן להשתמש בהם כדי להגדיר מערכת זו מבחינת הפרודוקטיביות של עבודתה.

ומה הבעיה - אין הבנה מלאה מספיק של מערכת השירות הזו, כזו שמאפשרת לך להגדיר במומחיות את ההגדרות של מערכת זו לעומס עתידי על פלטפורמה נתונה ולקבל את הפרודוקטיביות הנדרשת של המערכת.

נו. זה כמעט תמיד המצב.

מה אתה יכול לעשות כאן?

ובכן, הדבר הראשון שעולה בראש הוא להסתכל על התיעוד של המערכת הזו. הבן מהם הטווחים המקובלים עבור הערכים של פרמטרי ההתאמה. ולדוגמה, באמצעות שיטת הירידה בקואורדינטות, בחר ערכים עבור פרמטרי מערכת בבדיקות.

הָהֵן. תן למערכת איזושהי תצורה, בצורה של סט ספציפי של ערכים עבור פרמטרי התצורה שלה.

הפעל עליו עומס בדיקה, באמצעות מחולל עומסים זה ממש כלי-עזר.
ותראה את הערך - התגובה, או מדד של איכות המערכת.

המחשבה השנייה עשויה להיות המסקנה שמדובר בזמן ארוך מאוד.

ובכן, כלומר: אם יש הרבה פרמטרי הגדרה, אם טווחי הערכים שלהם המופעלים גדולים, אם כל בדיקת עומס בודדת לוקחת הרבה זמן להשלים, אז: כן, כל זה עשוי לקחת זמן בלתי מתקבל על הדעת הרבה זמן.

ובכן, הנה מה שאתה יכול להבין ולזכור.

אתה יכול לגלות שבקבוצת הערכים של פרמטרי הגדרות מערכת השירות יש וקטור, כרצף של כמה ערכים.

כל וקטור כזה, בהיותו דברים שווים (בכך שהוא אינו מושפע מווקטור זה), מתאים לערך מטרי מוגדר לחלוטין - אינדיקטור לאיכות פעולת המערכת בעומס בדיקה.

כלומר

הבה נסמן את וקטור תצורת המערכת בתור איפה ; איפה - מספר פרמטרים של תצורת המערכת, כמה מהפרמטרים הללו יש.

וערך המדד המקביל לכך בואו נסמן את זה בתור
, אז נקבל פונקציה:

ובכן, אם כן: הכל מסתכם מיד, במקרה שלי: כמעט נשכח מימי הסטודנטים שלי, אלגוריתמים לחיפוש הקיצון של פונקציה.

אוקיי, אבל כאן עולה שאלה ארגונית ויישומית: באיזה אלגוריתם להשתמש.

במובן - כדי שתוכלו לקודד פחות ביד.
וכדי שזה יעבוד, כלומר. מצא את הקיצון (אם יש כזה), ובכן, לפחות מהר יותר מירידה בקואורדינטות.

הנקודה הראשונה מרמזת שאנחנו צריכים להסתכל לעבר כמה סביבות שבהן אלגוריתמים כאלה כבר יושמו, והם, בצורה כלשהי, מוכנות לשימוש בקוד.
ובכן אני יודע python и cran-r

הנקודה השנייה פירושה שעליך לקרוא על האלגוריתמים עצמם, מה הם, מה הדרישות שלהם, תכונות העבודה שלהם.

ומה שהם נותנים יכול להיות תופעות לוואי שימושיות - תוצאות, או ישירות מהאלגוריתם עצמו.

או שניתן לקבל אותם מתוצאות האלגוריתם.

הרבה תלוי בתנאי הקלט.

לדוגמה, אם, מסיבה כלשהי, אתה צריך לקבל תוצאה מהר יותר, ובכן, אתה צריך להסתכל לעבר אלגוריתמים של ירידה בשיפוע ולבחור אחד מהם.

או, אם הזמן לא כל כך חשוב, אתה יכול, למשל, להשתמש בשיטות אופטימיזציה סטוכסטיות, כמו אלגוריתם גנטי.

אני מציע לשקול את העבודה של גישה זו, בחירת תצורת המערכת, באמצעות אלגוריתם גנטי, בעבודה הבאה, כביכול: עבודת מעבדה.

התחלתי:

שיהיה, כמערכת שירות: oracle xe 18c
תן לזה לשרת את הפעילות העסקית והמטרה: להשיג את התפוקה הגבוהה ביותר האפשרית של תת מסד הנתונים, בעסקאות/שניות.
עסקאות יכולות להיות שונות מאוד באופי העבודה עם נתונים ובהקשר העבודה.
בואו נסכים שמדובר בעסקאות שאינן מעבדות כמות גדולה של נתונים טבלאיים.
במובן זה שהם לא מייצרים יותר נתוני ביטול מאשר לעשות מחדש ולא מעבדים אחוזים גדולים של שורות וטבלאות גדולות.

מדובר בעסקאות שמשנות שורה אחת בטבלה גדולה פחות או יותר, עם מספר קטן של אינדקסים בטבלה זו.

במצב זה: הפרודוקטיביות של תת מסד הנתונים לעיבוד עסקאות תיקבע, בהסתייגות, לפי איכות העיבוד של מסד הנתונים החיזור.

כתב ויתור - אם נדבר ספציפית על הגדרות subdb.

מכיוון שבמקרה הכללי ייתכנו, למשל, נעילות טרנזקציות בין הפעלות של SQL, עקב עיצוב עבודת המשתמש עם נתונים טבלאיים ו/או המודל הטבלאי.

מה שכמובן ישפיע מדכא על מדד ה-TPS וזה יהיה גורם אקסוגני, יחסית לבסיס הנתונים המשנה: ובכן, כך תוכנן המודל הטבלאי והעבודה עם נתונים בו שמתרחשות חסימות.

לכן, למען טוהר הניסוי, נשלל גורם זה, ולהלן אבהיר כיצד בדיוק.

הבה נניח, ליתר ביטחון, ש-100% מפקודות ה-SQL הנשלחות למסד הנתונים הן פקודות DML.
תן למאפייני העבודה של המשתמש עם תת-בסיס הנתונים להיות זהים בבדיקות.
כלומר: מספר מפגשי SKL, נתונים טבלאיים, כיצד מפגשי SKL עובדים איתם.
Subd עובד ב FORCE LOGGING, ARCHIVELOG אופנים. מצב Flashback-Datebank כבוי, ברמת subd.
בצע שוב יומני: ממוקם במערכת קבצים נפרדת, על "דיסק" נפרד;
שאר הרכיב הפיזי של מסד הנתונים: במערכת קבצים אחרת, נפרדת, ב"דיסק" נפרד:

פרטים נוספים על המכשיר הפיזי. רכיבי מסד נתונים במעבדה

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 שואפת לבחון פלטפורמות
ללא טענה ליישום. אי אפשר לנהוג בביצועי חומרה מקסימליים
באמצעות קוד יישום המחובר, למשל, לנעילת יישום או אפילו
שיתוף בלוקים של Oracle Database. זה נכון - יש תקורה בעת שיתוף נתונים
בבלוק נתונים! אבל SLOB - בפריסת ברירת המחדל שלו - חסין בפני טענה כזו.

ההכרזה הזו: תואמת, זה כן.
זה נוח לווסת את מידת ההקבלה של מפגשי cl, זה המפתח -t להפעיל את כלי השירות runit.sh מ-SLOB
אחוז פקודות DML מוסדר, במספר הודעות הטקסט הנשלחות ל-subd, כל סשן טקסט, פרמטר UPDATE_PCT
בנפרד ומאוד נוח: SLOB עצמו, לפני ואחרי סשן הטעינה - מכין סטטיסטיקה, או awr-snapshots (מה מוגדר להיות מוכן).

עם זאת, התברר כי 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] MB;
מספר קבוצות היומן במאגר. טווח ערכים: [2,32];
log_archive_max_processes טווח ערכים: [1,8];
commit_logging שני ערכים מותרים: batch|immediate;
commit_wait שני ערכים מותרים: wait|nowait;
log_buffer טווח ערכים: [2,128] MB.
log_checkpoint_timeout טווח ערכים: [60,1200] שניות
db_writer_processes טווח ערכים: [1,4]
undo_retention טווח ערכים: [30;300] שניות
transactions_per_rollback_segment טווח ערכים: [1,8]
disk_asynch_io שני ערכים מותרים: true|false;
filesystemio_options הערכים הבאים מותרים: none|setall|directIO|asynch;
db_block_checking הערכים הבאים מותרים: OFF|LOW|MEDIUM|FULL;
db_block_checksum הערכים הבאים מותרים: OFF|TYPICAL|FULL;

בעל ניסיון בתחזוקת מסדי נתונים של אורקל בהחלט יכול כבר לומר מה ולאילו ערכים יש להגדיר, מהפרמטרים שצוינו והערכים המקובלים שלהם, על מנת להשיג פרודוקטיביות רבה יותר של מסד הנתונים לעבודה עם נתונים המצוינים על ידי קוד היישום, כאן למעלה.

אבל.

מטרת עבודת המעבדה היא להראות שאלגוריתם האופטימיזציה עצמו יבהיר לנו זאת מהר יחסית.

מבחינתנו, כל מה שנותר הוא להסתכל לתוך המסמך, דרך המערכת הניתנת להתאמה אישית, מספיק כדי לגלות אילו פרמטרים לשנות ובאילו טווחים.
וגם: קוד את הקוד שישמש לעבודה עם המערכת המותאמת אישית של אלגוריתם האופטימיזציה שנבחר.

אז, עכשיו לגבי הקוד.
דיברתי למעלה על cran-r, כלומר: כל המניפולציות עם המערכת המותאמת מתוזמרת בצורה של תסריט 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 מעבד טרנזקציות בשנייה.

כלומר, בעת הפתיחה, יש לבצע את השלב הרב הבא בתוך פונקציית הכושר:

עיבוד וקטור הקלט של מספרים - המרתו לערכים עבור פרמטרי המשנה.
ניסיון ליצור מספר נתון של קבוצות חוזרות בגודל נתון. יתרה מכך, הניסיון עלול להיכשל.
קבוצות מגזינים שכבר היו קיימות בסב"ד, בכמות מסוימת ובגודל מסוים, על טהרת הניסוי - ד.ב. נמחק.
אם הנקודה הקודמת הצליחה: ציון הערכים של פרמטרי תצורה למסד הנתונים (שוב: ייתכן שיש כשל)
אם השלב הקודם הצליח: עצירת ה-subd, התחלת ה-subd כך שערכי הפרמטרים החדשים שצוינו ייכנסו לתוקף. (שוב: ייתכן שיש תקלה)
אם השלב הקודם הצליח: בצע בדיקת עומס. קבל מדדים מ-subd.
החזר את ה-subd למצבו המקורי, כלומר. מחק קבוצות יומן נוספות, החזר את תצורת המשנה המקורית לעבודה.

קוד פונקציית כושר

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

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

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

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

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

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

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

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

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

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

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

rc=run_test()
v_metric=getmetric()

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

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

זֶה. כל העבודה: מבוצעת בפונקציית הכושר.

ה-ga-subroutine מעבדת וקטורים, או יותר נכון, כרומוזומים.
שבהם, מה שהכי חשוב לנו הוא בחירת הכרומוזומים עם גנים שפונקציית הכושר מייצרת עבורם ערכים גדולים.

זהו, במהותו, תהליך החיפוש אחר קבוצת הכרומוזומים האופטימלית באמצעות וקטור במרחב חיפוש N-ממדי.

מאוד ברור, מפורט הסבר, עם דוגמאות של 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)

זה חשוב, מכיוון שממערך נתונים זה, ניתן יהיה לקבל מידע נוסף לגבי מי מהמרכיבים של וקטור הכוונון משפיע יותר או פחות על הערך המטרי.

כלומר: ניתן יהיה לבצע ניתוח תכונות-חשיבות.

אז מה יכול לקרות?

בצורת גרף, אם אתה מזמין את המבחנים בסדר מטרי עולה, התמונה היא כדלקמן:

כמה נתונים התואמים את הערכים הקיצוניים של המדד:

כאן, בצילום המסך עם התוצאות, אבהיר: הערכים של וקטור הכוונון ניתנים במונחים של קוד פונקציית הכושר, לא במונחים של רשימת מספר הפרמטרים/טווחי ערכי הפרמטרים, שנוסחה. למעלה בטקסט.

נו. האם זה הרבה או מעט, ~8 אלף טפס: שאלה נפרדת.
במסגרת עבודת מעבדה הנתון הזה לא חשוב, מה שחשוב זה הדינמיקה, איך הערך הזה משתנה.

הדינמיקה כאן טובה.
ברור שלפחות גורם אחד משפיע באופן משמעותי על ערכו של המדד, האלגוריתם ה-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.
שאלה נפרדת היא האם כדאי לעשות זאת במאגר מזון או לא. כאן אני מגביל את עצמי רק להצהיר: זה גורם משמעותי.
זה הגיוני שגודל מאגר הלוג של ה-subd: מתברר כגורם משמעותי.
ככל שגודל מאגר היומן קטן יותר, קיבולת החציצה שלו קטנה יותר, כך הוא עולה על גדותיו לעתים קרובות יותר ו/או חוסר היכולת להקצות בו שטח פנוי לחלק מנתוני חיזור חדשים.
משמעות הדבר היא: עיכובים הקשורים להקצאת שטח במאגר היומן ו/או השלכת נתוני ביצוע מחדש ממנו לקבוצות ביצוע מחדש.
עיכובים אלו, כמובן, צריכים ומשפיעים על התפוקה של מסד הנתונים לעסקאות.
פרמטר db_block_checksum: ובכן, גם, באופן כללי זה ברור - עיבוד עסקאות מוביל להיווצרות של בלוקים דרטיים במטמון המאגר של תת מסד הנתונים.
אשר, כאשר בדיקת סכמי בדיקה של בלוקים של נתונים מופעלת, על מסד הנתונים לעבד - חשב את סכומי הבדיקה הללו מגוף ה-Datablock, בדוק אותם עם מה שכתוב ב-datablock header: matches/לא תואם.
עבודה כזו, שוב, אינה יכולה שלא לעכב את עיבוד הנתונים, ובהתאם, הפרמטר והמנגנון שקובע פרמטר זה מתגלים כמשמעותיים.
זו הסיבה שהספק מציע בתיעוד של פרמטר זה ערכים שונים ומציין כי כן, תהיה השפעה, אבל אתה יכול לבחור ערכים שונים, אפילו "כבוי" והשפעות שונות.

ובכן, מסקנה גלובלית.

הגישה, באופן כללי, מתבררת כעובדת למדי.

הוא די מרשה לעצמו, בשלבים הראשונים של בדיקת עומס של מערכת שירות מסוימת, כדי לבחור את התצורה האופטימלית שלה (מערכת) לעומס, לא להתעמק יותר מדי בפרטים הספציפיים של הקמת המערכת לעומס.

אבל זה לא שולל את זה לחלוטין - לפחות ברמת ההבנה: המערכת חייבת להיות ידועה על "כפתורי ההתאמה" ועל טווחי הסיבוב המותרים של הכפתורים הללו.

לאחר מכן, הגישה יכולה למצוא במהירות יחסית את תצורת המערכת האופטימלית.
ובהתבסס על תוצאות הבדיקות, ניתן לקבל מידע על אופי הקשר בין מדדי ביצועי המערכת לבין ערכי פרמטרי הגדרות המערכת.

מה שכמובן אמור לתרום להופעתה של ההבנה המאוד עמוקה הזו של המערכת, פעולתה, לפחות תחת עומס נתון.

בפועל מדובר בהחלפה של עלויות הבנת המערכת המותאמת לעלויות הכנת בדיקה כזו של המערכת.

ברצוני לציין בנפרד: בגישה זו ישנה חשיבות קריטית למידת ההתאמה של בדיקת המערכת לתנאי ההפעלה שיהיו לה בפעילות מסחרית.

תודה על תשומת הלב והזמן.

מקור: www.habr.com

שיטת ה-poke המדעית, או כיצד לבחור תצורת מסד נתונים באמצעות מדדים ואלגוריתם אופטימיזציה

הוספת תגובה ביטול תגובה