Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης

Γεια σας

Αποφάσισα να μοιραστώ το εύρημα μου - τον καρπό της σκέψης, της δοκιμής και του λάθους.
Σε γενικές γραμμές: αυτό δεν είναι εύρημα, φυσικά - όλα αυτά θα έπρεπε να ήταν γνωστά εδώ και πολύ καιρό, σε όσους ασχολούνται με την εφαρμοσμένη στατιστική επεξεργασία δεδομένων και τη βελτιστοποίηση οποιωνδήποτε συστημάτων, όχι απαραίτητα συγκεκριμένα του DBMS.
Και: ναι, ξέρουν, γράφουν ενδιαφέροντα άρθρα για την έρευνά τους, παράδειγμα (UPD.: στα σχόλια επεσήμαναν ένα πολύ ενδιαφέρον έργο: αλλόκοτος )
Από την άλλη πλευρά: εκ των πραγμάτων δεν βλέπω καμία ευρεία αναφορά ή διάδοση αυτής της προσέγγισης στο Διαδίκτυο μεταξύ των ειδικών πληροφορικής, DBA.

Έτσι, στο σημείο.

Ας υποθέσουμε ότι έχουμε ένα καθήκον: να δημιουργήσουμε ένα συγκεκριμένο σύστημα υπηρεσιών για την εξυπηρέτηση κάποιου είδους εργασίας.

Είναι γνωστό για αυτό το έργο: τι είναι, πώς μετράται η ποιότητα αυτού του έργου και ποιο είναι το κριτήριο για τη μέτρηση αυτής της ποιότητας.

Ας υποθέσουμε επίσης ότι είναι λίγο πολύ γνωστό και κατανοητό: πώς ακριβώς εκτελείται η εργασία σε (ή με) αυτό το σύστημα υπηρεσιών.

"Περισσότερο ή λιγότερο" - αυτό σημαίνει ότι είναι δυνατό να προετοιμαστεί (ή να το πάρει από κάπου) ένα συγκεκριμένο εργαλείο, βοηθητικό πρόγραμμα, υπηρεσία που μπορεί να συντεθεί και να εφαρμοστεί στο σύστημα με δοκιμαστικό φορτίο επαρκώς κατάλληλο για αυτό που θα είναι στην παραγωγή, σε συνθήκες επαρκώς κατάλληλες για εργασία στην παραγωγή .

Λοιπόν, ας υποθέσουμε ότι είναι γνωστό ένα σύνολο παραμέτρων προσαρμογής για αυτό το σύστημα υπηρεσιών, οι οποίες μπορούν να χρησιμοποιηθούν για τη διαμόρφωση αυτού του συστήματος όσον αφορά την παραγωγικότητα της εργασίας του.

Και ποιο είναι το πρόβλημα - δεν υπάρχει επαρκώς πλήρης κατανόηση αυτού του συστήματος υπηρεσιών, κάτι που σας επιτρέπει να διαμορφώσετε με έμπειρο τρόπο τις ρυθμίσεις αυτού του συστήματος για μελλοντική φόρτωση σε μια δεδομένη πλατφόρμα και να αποκτήσετε την απαιτούμενη παραγωγικότητα του συστήματος.

Καλά. Αυτό συμβαίνει σχεδόν πάντα.

Τι μπορείτε να κάνετε εδώ;

Λοιπόν, το πρώτο πράγμα που σας έρχεται στο μυαλό είναι να εξετάσετε την τεκμηρίωση για αυτό το σύστημα. Κατανοήστε ποια είναι τα αποδεκτά εύρη για τις τιμές των παραμέτρων προσαρμογής. Και, για παράδειγμα, χρησιμοποιώντας τη μέθοδο καθόδου συντεταγμένων, επιλέξτε τιμές για τις παραμέτρους του συστήματος σε δοκιμές.

Εκείνοι. δώστε στο σύστημα κάποιο είδος διαμόρφωσης, με τη μορφή ενός συγκεκριμένου συνόλου τιμών για τις παραμέτρους διαμόρφωσής του.

Εφαρμόστε ένα δοκιμαστικό φορτίο σε αυτό, χρησιμοποιώντας αυτό ακριβώς το εργαλείο-βοηθητικό, γεννήτρια φορτίου.
Και κοιτάξτε την τιμή - την απόκριση ή μια μέτρηση της ποιότητας του συστήματος.

Η δεύτερη σκέψη μπορεί να είναι το συμπέρασμα ότι πρόκειται για πολύ μεγάλο χρονικό διάστημα.

Λοιπόν, δηλαδή: εάν υπάρχουν πολλές παραμέτρους ρύθμισης, εάν τα εύρη των τιμών τους που εκτελούνται είναι μεγάλα, εάν κάθε μεμονωμένη δοκιμή φορτίου χρειάζεται πολύ χρόνο για να ολοκληρωθεί, τότε: ναι, όλα αυτά μπορεί να διαρκέσουν απαράδεκτα πολύς καιρός.

Λοιπόν, εδώ είναι τι μπορείτε να καταλάβετε και να θυμάστε.

Μπορείτε να μάθετε ότι στο σύνολο τιμών των παραμέτρων των ρυθμίσεων του συστήματος υπηρεσιών υπάρχει ένα διάνυσμα, ως ακολουθία ορισμένων τιμών.

Κάθε τέτοιο διάνυσμα, τα άλλα πράγματα είναι ίσα (στο ότι δεν επηρεάζεται από αυτό το διάνυσμα), αντιστοιχεί σε μια εντελώς καθορισμένη τιμή της μέτρησης - ένας δείκτης της ποιότητας της λειτουργίας του συστήματος υπό δοκιμαστικό φορτίο.

Δηλαδή

Ας υποδηλώσουμε το διάνυσμα διαμόρφωσης συστήματος ως Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησηςΌπου Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης; Οπου Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης — αριθμός παραμέτρων διαμόρφωσης συστήματος, πόσες από αυτές τις παραμέτρους υπάρχουν.

Και η τιμή της μέτρησης που αντιστοιχεί σε αυτό Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης ας το χαρακτηρίσουμε ως
Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης, τότε παίρνουμε τη συνάρτηση: Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης

Λοιπόν, όλα καταλήγουν αμέσως, στην περίπτωσή μου: σχεδόν ξεχασμένοι από τα φοιτητικά μου χρόνια, αλγόριθμοι αναζήτησης για το άκρο μιας συνάρτησης.

Εντάξει, αλλά εδώ τίθεται ένα οργανωτικό και εφαρμοσμένο ερώτημα: ποιον αλγόριθμο να χρησιμοποιήσω.

  1. Με την έννοια - έτσι ώστε να μπορείτε να κωδικοποιήσετε λιγότερο με το χέρι.
  2. Και για να λειτουργήσει, δηλ. βρήκε το άκρο (αν υπάρχει), καλά, τουλάχιστον γρηγορότερα από τη συντεταγμένη κάθοδο.

Το πρώτο σημείο υποδηλώνει ότι πρέπει να κοιτάξουμε προς ορισμένα περιβάλλοντα στα οποία τέτοιοι αλγόριθμοι έχουν ήδη εφαρμοστεί και είναι, σε κάποια μορφή, έτοιμοι για χρήση σε κώδικα.
Λοιπόν, ξέρω python и cran-r

Το δεύτερο σημείο σημαίνει ότι πρέπει να διαβάσετε για τους ίδιους τους αλγόριθμους, τι είναι, ποιες είναι οι απαιτήσεις τους και τα χαρακτηριστικά της δουλειάς τους.

Και αυτό που δίνουν μπορεί να είναι χρήσιμες παρενέργειες - αποτελέσματα, ή απευθείας από τον ίδιο τον αλγόριθμο.

Ή μπορούν να ληφθούν από τα αποτελέσματα του αλγορίθμου.

Πολλά εξαρτώνται από τις συνθήκες εισαγωγής.

Για παράδειγμα, εάν, για κάποιο λόγο, πρέπει να λάβετε ένα αποτέλεσμα πιο γρήγορα, πρέπει να κοιτάξετε προς τους αλγόριθμους gradient descent και να επιλέξετε έναν από αυτούς.

Ή, εάν ο χρόνος δεν είναι τόσο σημαντικός, μπορείτε, για παράδειγμα, να χρησιμοποιήσετε μεθόδους στοχαστικής βελτιστοποίησης, όπως έναν γενετικό αλγόριθμο.

Προτείνω να εξετάσουμε το έργο αυτής της προσέγγισης, επιλέγοντας τη διαμόρφωση του συστήματος, χρησιμοποιώντας έναν γενετικό αλγόριθμο, στην επόμενη, θα λέγαμε: εργαστηριακή εργασία.

Αρχικός:

  1. Ας υπάρχει, ως σύστημα εξυπηρέτησης: oracle xe 18c
  2. Αφήστε το να εξυπηρετήσει τη συναλλακτική δραστηριότητα και τον στόχο: να αποκτήσετε τη μεγαλύτερη δυνατή απόδοση της υποβάσης δεδομένων, σε συναλλαγές/δευτ.
  3. Οι συναλλαγές μπορεί να είναι πολύ διαφορετικές ως προς τη φύση της εργασίας με δεδομένα και το πλαίσιο της εργασίας.
    Ας συμφωνήσουμε ότι πρόκειται για συναλλαγές που δεν επεξεργάζονται μεγάλο όγκο δεδομένων σε πίνακα.
    Με την έννοια ότι δεν δημιουργούν περισσότερα δεδομένα αναίρεσης από την επανάληψη και δεν επεξεργάζονται μεγάλα ποσοστά σειρών και μεγάλων πινάκων.

Πρόκειται για συναλλαγές που αλλάζουν μία σειρά σε έναν περισσότερο ή λιγότερο μεγάλο πίνακα, με μικρό αριθμό ευρετηρίων σε αυτόν τον πίνακα.

Σε αυτήν την περίπτωση: η παραγωγικότητα της υποβάσης δεδομένων για την επεξεργασία των συναλλαγών θα καθοριστεί, με επιφύλαξη, από την ποιότητα της επεξεργασίας από τη βάση δεδομένων οξειδοαναγωγής.

Αποποίηση ευθυνών - αν μιλάμε συγκεκριμένα για τις ρυθμίσεις subdb.

Επειδή, στη γενική περίπτωση, μπορεί να υπάρχουν, για παράδειγμα, κλειδώματα συναλλαγών μεταξύ των περιόδων σύνδεσης SQL, λόγω του σχεδιασμού της εργασίας του χρήστη με δεδομένα πίνακα ή/και το μοντέλο πίνακα.

Κάτι που, φυσικά, θα έχει μια καταθλιπτική επίδραση στη μέτρηση TPS και αυτός θα είναι ένας εξωγενής παράγοντας, σε σχέση με την υποβάση δεδομένων: Λοιπόν, έτσι σχεδιάστηκε το πινακοποιητικό μοντέλο και η εργασία με δεδομένα σε αυτό που εμφανίζονται μπλοκαρίσματα.

Επομένως, για την καθαρότητα του πειράματος, θα αποκλείσουμε αυτόν τον παράγοντα και παρακάτω θα διευκρινίσω ακριβώς πώς.

  1. Ας υποθέσουμε, για βεβαιότητα, ότι το 100% των εντολών SQL που υποβάλλονται στη βάση δεδομένων είναι εντολές DML.
    Αφήστε τα χαρακτηριστικά της εργασίας του χρήστη με την υποβάση δεδομένων να είναι ίδια στις δοκιμές.
    Δηλαδή: ο αριθμός των περιόδων σύνδεσης skl, τα δεδομένα πίνακα, ο τρόπος με τον οποίο λειτουργούν οι συνεδρίες skl με αυτές.
  2. Το Subd λειτουργεί σε FORCE LOGGING, ARCHIVELOG mods. Η λειτουργία βάσεων δεδομένων αναδρομής είναι απενεργοποιημένη, στο επίπεδο υποδ.
  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

Αρχικά, υπό αυτές τις συνθήκες φόρτωσης, ήθελα να χρησιμοποιήσω συναλλαγή subd SLOB-uility
Έχει ένα τόσο υπέροχο χαρακτηριστικό, θα παραθέσω τον συγγραφέα:

Στην καρδιά του SLOB βρίσκεται η «μέθοδος SLOB». Η μέθοδος SLOB στοχεύει στη δοκιμή πλατφορμών
χωρίς αμφισβήτηση αιτήσεων. Δεν μπορεί κανείς να οδηγήσει τη μέγιστη απόδοση υλικού
χρησιμοποιώντας κωδικό εφαρμογής που, για παράδειγμα, δεσμεύεται από κλείδωμα εφαρμογής ή ακόμα και
κοινή χρήση μπλοκ βάσης δεδομένων Oracle. Αυτό είναι σωστό — υπάρχει επιβάρυνση κατά την κοινή χρήση δεδομένων
σε μπλοκ δεδομένων! Αλλά το SLOB —στην προεπιλεγμένη του ανάπτυξη— είναι απρόσβλητο σε τέτοιους ισχυρισμούς.

Αυτή η δήλωση: αντιστοιχεί, είναι.
Είναι βολικό να ρυθμίζετε τον βαθμό παραλληλισμού των συνεδριών cl, αυτό είναι το κλειδί -t εκκινήστε το βοηθητικό πρόγραμμα runit.sh από το SLOB
Το ποσοστό των εντολών DML ρυθμίζεται, στον αριθμό των μηνυμάτων κειμένου που αποστέλλονται στο subd, κάθε περίοδος κειμένου, παράμετρος UPDATE_PCT
Ξεχωριστά και πολύ βολικά: SLOB η ίδια, πριν και μετά τη συνεδρία φόρτωσης - προετοιμάζει ένα statspack ή στιγμιότυπα awr (τι έχει ρυθμιστεί να προετοιμαστεί).

Ωστόσο, αποδείχθηκε ότι SLOB δεν υποστηρίζει περιόδους λειτουργίας SQL με διάρκεια μικρότερη από 30 δευτερόλεπτα.
Επομένως, πρώτα κωδικοποίησα τη δική μου, εργατοαγροτική έκδοση του φορτωτή και μετά παρέμεινε σε λειτουργία.

Επιτρέψτε μου να διευκρινίσω τι κάνει ο φορτωτής και πώς το κάνει, για λόγους σαφήνειας.
Ουσιαστικά ο φορτωτής μοιάζει με αυτό:

Κωδικός εργάτη

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

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

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

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

exit
__EOF__
}
export -f dotx

Οι εργαζόμενοι εκτοξεύονται ως εξής:

Εργάτες που τρέχουν

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

Και οι πίνακες για τους εργαζόμενους προετοιμάζονται ως εξής:

Δημιουργία πινάκων

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

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

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

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

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

Εκείνοι. Για κάθε εργαζόμενο (πρακτικά: μια ξεχωριστή συνεδρία SQL στο DB) δημιουργείται ένας ξεχωριστός πίνακας, με τον οποίο συνεργάζεται ο εργαζόμενος.

Αυτό διασφαλίζει την απουσία κλειδώματος συναλλαγών μεταξύ των συνεδριών εργασίας.
Κάθε εργάτης: κάνει το ίδιο πράγμα, με το δικό του τραπέζι, τα τραπέζια είναι όλα ίδια.
Όλοι οι εργαζόμενοι εκτελούν εργασία για το ίδιο χρονικό διάστημα.
Επιπλέον, για αρκετά μεγάλο χρονικό διάστημα, ώστε, για παράδειγμα, να συμβεί σίγουρα ένας διακόπτης καταγραφής, και περισσότερες από μία φορές.
Λοιπόν, κατά συνέπεια, προέκυψαν σχετικό κόστος και επιπτώσεις.
Στην περίπτωσή μου, ρύθμισα τη διάρκεια της εργασίας των εργαζομένων στα 8 λεπτά.

Ένα κομμάτι μιας αναφοράς statspack που περιγράφει τη λειτουργία του υποδ υπό φορτίο

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

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

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

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

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

Επιστροφή στις εργαστηριακές εργασίες.
Αν και άλλα πράγματα είναι ίσα, θα αλλάξουμε τις τιμές των ακόλουθων παραμέτρων της εργαστηριακής υποβάσης δεδομένων:

  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;

Ένα άτομο με εμπειρία στη συντήρηση βάσεων δεδομένων 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 επεξεργάζεται συναλλαγές ανά δευτερόλεπτο.

Δηλαδή, κατά το ξεδίπλωμα, πρέπει να εκτελεστεί το ακόλουθο πολλαπλό βήμα μέσα στη λειτουργία φυσικής κατάστασης:

  1. Επεξεργασία του διανύσματος εισαγωγής αριθμών - μετατροπή του σε τιμές για τις παραμέτρους υποδεδομένων.
  2. Μια προσπάθεια δημιουργίας ενός δεδομένου αριθμού ομάδων επανάληψης ενός δεδομένου μεγέθους. Επιπλέον, η προσπάθεια μπορεί να είναι ανεπιτυχής.
    Ομάδες περιοδικών που υπήρχαν ήδη στο υποδ, σε κάποια ποσότητα και σε κάποιο μέγεθος, για την καθαρότητα του πειράματος - δ.β. διαγράφηκε.
  3. Εάν το προηγούμενο σημείο είναι επιτυχές: καθορίζοντας τις τιμές των παραμέτρων διαμόρφωσης στη βάση δεδομένων (και πάλι: μπορεί να υπάρχει αποτυχία)
  4. Εάν το προηγούμενο βήμα είναι επιτυχές: διακοπή του subd, εκκίνηση του subd έτσι ώστε να τεθούν σε ισχύ οι πρόσφατα καθορισμένες τιμές παραμέτρων. (πάλι: μπορεί να υπάρχει πρόβλημα)
  5. Εάν το προηγούμενο βήμα είναι επιτυχές: εκτελέστε μια δοκιμή φόρτωσης. λάβετε μετρήσεις από υποδ.
  6. Επιστρέψτε το 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-υπορουτίνα επεξεργάζεται φορείς, ή, πιο σωστά, χρωμοσώματα.
Στην οποία, το πιο σημαντικό για εμάς είναι η επιλογή χρωμοσωμάτων με γονίδια για τα οποία η συνάρτηση καταλληλότητας παράγει μεγάλες τιμές.

Αυτή, στην ουσία, είναι η διαδικασία αναζήτησης του βέλτιστου συνόλου χρωμοσωμάτων χρησιμοποιώντας ένα διάνυσμα σε έναν χώρο αναζήτησης Ν-διάστατων.

Πολύ σαφής, λεπτομερής εξήγηση, με παραδείγματα 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)

Αυτό είναι σημαντικό, επειδή από αυτόν τον πίνακα δεδομένων, θα είναι δυνατό να ληφθούν πρόσθετες πληροφορίες σχετικά με το ποια από τα στοιχεία του διανύσματος συντονισμού έχει μεγαλύτερη ή μικρότερη επίδραση στη μετρική τιμή.

Δηλαδή: θα είναι δυνατή η διεξαγωγή ανάλυσης χαρακτηριστικών-σημασίας.

Τι μπορεί λοιπόν να συμβεί;

Σε μορφή γραφήματος, εάν παραγγείλετε τις δοκιμές σε αύξουσα μετρική σειρά, η εικόνα είναι η εξής:

Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης

Ορισμένα δεδομένα που αντιστοιχούν στις ακραίες τιμές της μέτρησης:
Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης
Εδώ, στο στιγμιότυπο οθόνης με τα αποτελέσματα, θα διευκρινίσω: οι τιμές του διανύσματος συντονισμού δίνονται ως προς τον κωδικό συνάρτησης καταλληλότητας, όχι ως προς την αριθμητική λίστα παραμέτρων/εύρη τιμών παραμέτρων, η οποία διατυπώθηκε παραπάνω στο κείμενο.

Καλά. Είναι πολύ ή λίγο, ~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, δεν είναι σημαντικό το θέμα.

Ως αποτέλεσμα, σε αυτήν την περίπτωση, προκύπτει το ακόλουθο αποτέλεσμα για να εκτιμηθεί ο βαθμός σημασίας των χαρακτηριστικών:

Η επιστημονική μέθοδος poke ή πώς να επιλέξετε μια διαμόρφωση βάσης δεδομένων χρησιμοποιώντας σημεία αναφοράς και έναν αλγόριθμο βελτιστοποίησης

Καλά. Έτσι, μπορούμε να ξεκινήσουμε τον παγκόσμιο προβληματισμό:

  1. Αποδεικνύεται ότι το πιο σημαντικό, υπό αυτές τις συνθήκες δοκιμής, ήταν η παράμετρος commit_wait
    Τεχνικά, καθορίζει τον τρόπο εκτέλεσης της λειτουργίας io για την εγγραφή δεδομένων επανάληψης από το buffer καταγραφής subdb στην τρέχουσα ομάδα καταγραφής: σύγχρονη ή ασύγχρονη.
    Αξία nowait που οδηγεί σε μια σχεδόν κατακόρυφη, πολλαπλή αύξηση της τιμής της μέτρησης tps: αυτή είναι η συμπερίληψη της λειτουργίας ασύγχρονου io σε ομάδες επανάληψης.
    Μια ξεχωριστή ερώτηση είναι εάν πρέπει ή όχι να το κάνετε αυτό σε μια βάση δεδομένων τροφίμων. Εδώ περιορίζομαι στο να αναφέρω απλώς: αυτός είναι ένας σημαντικός παράγοντας.
  2. Είναι λογικό ότι το μέγεθος του buffer καταγραφής του subd: αποδεικνύεται σημαντικός παράγοντας.
    Όσο μικρότερο είναι το μέγεθος της προσωρινής μνήμης καταγραφής, τόσο μικρότερη είναι η χωρητικότητα της προσωρινής μνήμης, τόσο πιο συχνά υπερχειλίζει ή/και η αδυναμία εκχώρησης μιας ελεύθερης περιοχής σε αυτήν για ένα τμήμα νέων δεδομένων οξειδοαναγωγής.
    Αυτό σημαίνει: καθυστερήσεις που σχετίζονται με την κατανομή χώρου στην προσωρινή μνήμη καταγραφής και/ή την απόρριψη δεδομένων επανάληψης από αυτό σε ομάδες επανάληψης.
    Αυτές οι καθυστερήσεις, φυσικά, θα πρέπει και επηρεάζουν την απόδοση της βάσης δεδομένων για τις συναλλαγές.
  3. Παράμετρος db_block_checksum: Λοιπόν, επίσης, γενικά είναι σαφές - η επεξεργασία συναλλαγών οδηγεί στον σχηματισμό μπλοκ darty στην προσωρινή μνήμη προσωρινής αποθήκευσης της υποβάσης δεδομένων.
    Τα οποία, όταν είναι ενεργοποιημένος ο έλεγχος των αθροισμάτων ελέγχου μπλοκ δεδομένων, η βάση δεδομένων πρέπει να επεξεργαστεί - να υπολογίσει αυτά τα αθροίσματα ελέγχου από το σώμα του μπλοκ δεδομένων, να τα ελέγξει με αυτό που είναι γραμμένο στην κεφαλίδα του μπλοκ δεδομένων: ταιριάζει/δεν ταιριάζει.
    Τέτοιες εργασίες, πάλι, δεν μπορούν παρά να καθυστερήσουν την επεξεργασία δεδομένων και, κατά συνέπεια, η παράμετρος και ο μηχανισμός που ορίζει αυτήν την παράμετρο αποδεικνύονται σημαντικές.
    Γι' αυτό ο προμηθευτής προσφέρει, στην τεκμηρίωση για αυτήν την παράμετρο, διαφορετικές τιμές και σημειώνει ότι ναι, θα υπάρξει αντίκτυπος, αλλά μπορείτε να επιλέξετε διαφορετικές τιμές, ακόμη και "off" και διαφορετικές επιπτώσεις.

Λοιπόν, ένα παγκόσμιο συμπέρασμα.

Η προσέγγιση, γενικά, αποδεικνύεται αρκετά λειτουργική.

Επιτρέπει αρκετά στον εαυτό του, στα πρώτα στάδια της δοκιμής φορτίου ενός συγκεκριμένου συστήματος εξυπηρέτησης, προκειμένου να επιλέξει τη βέλτιστη διαμόρφωση του (συστήματος) για το φορτίο, να μην εμβαθύνει πολύ στις ιδιαιτερότητες της ρύθμισης του συστήματος για το φορτίο.

Αλλά δεν το αποκλείει εντελώς - τουλάχιστον σε επίπεδο κατανόησης: το σύστημα πρέπει να είναι γνωστό για τα "κουμπιά ρύθμισης" και τα επιτρεπτά εύρη περιστροφής αυτών των κουμπιών.

Η προσέγγιση μπορεί στη συνέχεια να βρει σχετικά γρήγορα τη βέλτιστη διαμόρφωση συστήματος.
Και με βάση τα αποτελέσματα των δοκιμών, είναι δυνατό να ληφθούν πληροφορίες σχετικά με τη φύση της σχέσης μεταξύ των μετρήσεων απόδοσης του συστήματος και των τιμών των παραμέτρων των ρυθμίσεων του συστήματος.

Κάτι που, φυσικά, θα πρέπει να συμβάλει στην ανάδυση αυτής της πολύ βαθιάς κατανόησης του συστήματος, της λειτουργίας του, τουλάχιστον κάτω από ένα δεδομένο φορτίο.

Στην πράξη, πρόκειται για ανταλλαγή του κόστους κατανόησης του προσαρμοσμένου συστήματος με το κόστος προετοιμασίας μιας τέτοιας δοκιμής του συστήματος.

Θα ήθελα να σημειώσω ξεχωριστά: σε αυτήν την προσέγγιση, ο βαθμός επάρκειας του ελέγχου του συστήματος στις συνθήκες λειτουργίας που θα έχει στην εμπορική λειτουργία είναι εξαιρετικά σημαντικός.

Σας ευχαριστώ για την προσοχή και τον χρόνο σας.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο