科学的なポーク手法、またはベンチマークと最適化アルゴリズムを使用してデータベース構成を選択する方法

もしもし

私は、思考と試行錯誤の成果である私の発見を共有することにしました。
概して、もちろんこれは発見ではありません。このことはすべて、応用統計データ処理やシステム (必ずしも DBMS に限ったものではない) の最適化に携わる人々には、長い間知られていたはずです。
そして：はい、彼らは知っています、彼らは自分たちの研究について興味深い記事を書いています、 例 (UPD.: コメントの中で、彼らは非常に興味深いプロジェクトを指摘しました: オッテルチューン )
その一方で、率直に言って、IT スペシャリストである DBA の間で、インターネット上でこのアプローチが広く言及されたり普及したりしているのは見当たりません。

ということで、本題です。

ある種の作業を処理するために特定のサービス システムをセットアップするというタスクがあると仮定しましょう。

この作品については、それが何であるか、この作品の品質がどのように測定されるか、そしてこの品質を測定するための基準が何であるかがわかっています。

また、このサービス システム内で (またはこのサービス システムで) 作業がどのように実行されるかについては、多かれ少なかれ理解されていると仮定しましょう。

「多かれ少なかれ」 - これは、運用環境に十分に適したテスト負荷で合成してシステムに適用できる特定のツール、ユーティリティ、サービスを準備できる (またはどこかから入手できる) ことを意味します。本番環境での作業に十分な条件が整っていること。

さて、このサービス システムの一連の調整パラメータが既知であり、その作業の生産性の観点からこのシステムを構成するために使用できると仮定しましょう。

そして問題は何ですか。このサービス システムについては、特定のプラットフォームでの将来の負荷に合わせてこのシステムの設定を専門的に構成し、システムに必要な生産性を得ることができる、十分に完全な理解がありません。

良い。 これはほとんど常に当てはまります。

ここで何ができるでしょうか？

まず最初に思い浮かぶのは、このシステムのドキュメントを見ることです。 調整パラメータの値の許容範囲を理解します。 そして、たとえば、座標降下法を使用して、テストでシステム パラメーターの値を選択します。

それらの。 構成パラメータの特定の値のセットの形式で、システムに何らかの構成を与えます。

このツールユーティリティである負荷ジェネレータを使用して、テスト負荷を適用します。
そして、その値、つまり応答、つまりシステムの品質の指標に注目してください。

次に考えられるのは、これは非常に長い時間であるという結論かもしれません。

つまり、設定パラメーターが多数ある場合、実行される値の範囲が大きい場合、個々の負荷テストの完了に時間がかかる場合、はい、これには許容できないほど時間がかかる可能性があります。長い間。

さて、ここであなたが理解し、覚えておくことができることを説明します。

サービスシステム設定パラメータの値のセットには、いくつかの値のシーケンスとしてベクトルがあることがわかります。

このような各ベクトルは、その他の条件が等しい場合 (このベクトルの影響を受けないという点で)、メトリックの完全に明確な値、つまりテスト負荷下でのシステムの動作品質の指標に対応します。

すなわち

システム構成ベクトルを次のように表すことにします。 どこ ; どこ — システム構成パラメータの数、これらのパラメータがいくつあるか。

そして、これに対応するメトリクスの値 それを次のように表しましょう
そうすると、次の関数が得られます。

さて、私の場合、すべてはすぐに、学生時代からほとんど忘れられていた、関数の極値を検索するためのアルゴリズムに帰着します。

さて、しかしここで、どのアルゴリズムを使用するかという、組織的かつ応用的な問題が生じます。

1. ある意味では、手作業でコーディングする手間が減ります。
2. そしてそれが機能するためには、つまり(極値があれば) 少なくとも座標降下よりも速く見つかりました。

最初の点は、そのようなアルゴリズムがすでに実装されており、何らかの形でコードで使用できる環境に目を向ける必要があることを示唆しています。
まあ、知っています python и cran-r

XNUMX 番目のポイントは、アルゴリズム自体、アルゴリズムの内容、要件、動作の特徴について読む必要があることを意味します。

そして、それらが与えるものは、有益な副作用、つまり結果、またはアルゴリズム自体から直接得られる可能性があります。

または、アルゴリズムの結果から取得することもできます。

入力条件に大きく依存します。

たとえば、何らかの理由で結果をより速く取得する必要がある場合は、勾配降下法アルゴリズムに注目し、そのいずれかを選択する必要があります。

または、時間がそれほど重要ではない場合は、たとえば、遺伝的アルゴリズムなどの確率的最適化手法を使用できます。

私は、遺伝的アルゴリズムを使用してシステム構成を選択するこのアプローチの作業を、いわば実験室での作業として検討することを提案します。

ソース：

1. サービス システムとして次のようなものがあるとします。 oracle xe 18c
2. これをトランザクション アクティビティに使用し、サブデータベースの可能な限り最高のスループット (トランザクション/秒) を取得するという目標を達成します。
3. トランザクションは、データの操作の性質や作業のコンテキストが大きく異なる場合があります。
   これらは大量の表形式データを処理しないトランザクションであることに同意しましょう。
   これは、REDO よりも多くの UNDO データを生成せず、大部分の行や大きなテーブルを処理しないという意味です。

これらは、テーブル上の少数のインデックスを使用して、多かれ少なかれ大きなテーブル内の XNUMX 行を変更するトランザクションです。

この状況では、トランザクションを処理するためのサブデータベースの生産性は、予約があれば、REDOX データベースによる処理の品質によって決まります。

免責事項 - 特に subdb 設定について話す場合。

一般に、表形式データや表形式モデルを使用したユーザー作業の設計により、たとえば SQL セッション間にトランザクション ロックが発生する可能性があるためです。

もちろん、これは tps メトリクスにマイナスの影響を及ぼし、これはサブデータベースに関連した外因的要因になります。これが、表形式モデルの設計方法と、ブロックが発生するその中のデータの処理方法です。

したがって、実験の純度を高めるために、この要素を除外し、以下でその方法を正確に説明します。

1. 明確にするために、データベースに送信される SQL コマンドの 100% が DML コマンドであると仮定します。
   テストでは、サブデータベースを操作するユーザーの特性が同じになるようにします。
   つまり、skl セッションの数、表形式のデータ、skl セッションがそれらとどのように連携するか。
2. サブドはで動作します FORCE LOGGING, ARCHIVELOG 改造品。 フラッシュバック データベース モードは、subd レベルでオフになります。
3. REDO ログ: 別のファイル システムの別の「ディスク」にあります。
   データベースの物理コンポーネントの残りの部分: 別の別のファイル システム、別の「ディスク」上:

物理デバイスの詳細。 研究室データベースのコンポーネント

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 スナップショット (準備されるように設定されているもの) を準備します。

しかし、判明したのは、 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 XNUMX つの値が許可されます。 batch|immediate;
5. commit_wait XNUMX つの値が許可されます。 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 XNUMX つの値が許可されます。 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 セットアップと subd 上の指定された負荷で、subd が XNUMX 秒あたりにトランザクションを処理する数です。

つまり、展開するときに、フィットネス関数内で次の複数のステップを実行する必要があります。

1. 数値の入力ベクトルを処理し、サブデータ パラメーターの値に変換します。
2. 指定されたサイズの指定された数の REDO グループを作成しようとします。 さらに、その試みは失敗する可能性があります。
   実験の純粋さのために、ある程度の量とある程度のサイズで、サブッドにすでに存在していた雑誌グループ - d.b. 削除されました。
3. 前のポイントが成功した場合: 構成パラメータの値をデータベースに指定します (繰り返しになりますが、失敗する可能性があります)
4. 前のステップが成功した場合: subd を停止し、新しく指定したパラメーター値が有効になるように subd を開始します。 (繰り返しますが、不具合がある可能性があります)
5. 前の手順が成功した場合: 負荷テストを実行します。 subdからメトリクスを取得します。
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 サブルーチンはベクトル、より正確には染色体を処理します。
その中で、私たちにとって最も重要なことは、適応度関数が大きな値を生み出す遺伝子を持つ染色体を選択することです。

これは本質的に、N 次元の検索空間でベクトルを使用して最適な染色体のセットを検索するプロセスです。

非常に明確で詳細な 説明、遺伝的アルゴリズムの働きである R コードの例を示します。

技術的な点を XNUMX つ個別に指摘したいと思います。

関数からの補助呼び出し evaluateたとえば、停止/開始、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)
}
}

XNUMX番目のポイントはラインです。 evaluate 特定のメトリック値とそれに対応する調整ベクトルをログ ファイルに保存する機能:

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

これは重要です。なぜなら、このデータ配列から、調整ベクトルのどの成分がメトリック値に多かれ少なかれ影響を与えるかについての追加情報を取得できるからです。

つまり、属性重要度分析が可能になります。

それで何が起こるでしょうか？

グラフ形式で、テストをメトリックの昇順に並べると、図は次のようになります。

メトリクスの極値に対応するいくつかのデータ:

ここで、結果を含むスクリーンショットで明確にします。調整ベクトルの値は、定式化されたパラメーターの番号リスト/パラメーター値の範囲の観点ではなく、適応度関数のコードの観点から与えられます。本文中の上にあります。

良い。 約 8 tps は多いのか少ないのか、別の質問です。
実験室での研究の枠組みでは、この数値は重要ではありません。重要なのはダイナミクス、つまりこの値がどのように変化するかです。

ここのダイナミクスは良いです。
少なくとも XNUMX つの要素が、染色体ベクトルを並べ替えるメトリクス、ga アルゴリズムの値に大きく影響することは明らかです。
曲線値のかなり激しいダイナミクスから判断すると、かなり小さいとはいえ、影響を与える要因が少なくとも XNUMX つあります。

ここが必要です attribute-importance 分析により、どのような属性 (この場合は調整ベクトルのコンポーネント) がメトリック値にどの程度影響するかを理解できます。
そして、この情報から、重要な属性の変化によってどのような要因が影響を受けたかを理解します。

ラン attribute-importance さまざまな方法で可能です。

これらの目的のために、私はこのアルゴリズムが好きです randomForest 同名の R パッケージ (ドキュメント)
randomForest私が理解しているように、彼の研究全般、特に属性の重要性を評価するアプローチは、属性に対する応答変数の依存性についての特定のモデルを構築しています。

この場合、応答変数は負荷テストでデータベースから取得されたメトリックです。 tps;
また、属性は調整ベクトルのコンポーネントです。

そしてそう randomForest 各モデル属性の重要性を XNUMX つの数値で評価します。 %IncMSE — モデル内のこの属性の有無によって、このモデルの MSE 品質 (平均二乗誤差) がどのように変化するか。

そして、IncNodePurity は、この属性の値に基づいて、観測値を含むデータセットをどの程度うまく分割できるかを反映する数値です。つまり、ある部分には説明されているメトリクスの XNUMX つの値を持つデータがあり、もう XNUMX つは説明されているメトリクスの値を持つデータが存在します。メトリックの別の値。
つまり、これはどの程度分類属性なのかということです (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、重要なのはポイントではありません。

その結果、この場合、属性の重要度を評価すると以下のような結果が得られます。

良い。 したがって、グローバル リフレクションを開始できます。

1. これらのテスト条件下で最も重要なのはパラメータであることが判明しました。 commit_wait
   技術的には、REDO データを subdb ログ バッファから現在のログ グループに書き込む io 操作の実行モード (同期または非同期) を指定します。
   値 nowait その結果、tps メトリックの値がほぼ垂直に複数回増加します。これは、REDO グループに非同期 IO モードが含まれていることです。
   別の問題は、これを食品データベースで行うべきかどうかです。 ここでは、これは重要な要素であるとだけ述べておきます。
2. subd: のログ バッファーのサイズが重要な要素であることが判明するのは論理的です。
   ログ バッファのサイズが小さいほど、バッファリング容量が少なくなり、オーバーフローが発生したり、新しい酸化還元データの一部に空き領域を割り当てることができなくなることが多くなります。
   これは、ログ・バッファ内の領域の割り当てや、ログ・バッファからREDOグループへのREDOデータのダンプに関連する遅延を意味します。
   これらの遅延は、当然のことながら、トランザクションのデータベースのスループットに影響を与えるはずです。
3. パラメーター db_block_checksum: そうですね、一般的に、トランザクション処理によりサブデータベースのバッファ キャッシュ内にダーティ ブロックが形成されることは明らかです。
   データブロックのチェックサムのチェックが有効になっている場合、データベースはデータブロックの本体からこれらのチェックサムを計算し、データブロックのヘッダーに書かれているものと照合して、一致/不一致をチェックする必要があります。
   このような作業もまた、データ処理を遅らせるほかなく、したがって、パラメータと、このパラメータを設定するメカニズムが重要であることが判明します。
   そのため、ベンダーはこのパラメータのドキュメントでこのパラメータ (パラメータ) に異なる値を提供し、確かに影響はありますが、「オフ」や「オフ」までの異なる値を選択できると述べています。さまざまな影響。

まあ、世界的な結論です。

一般に、このアプローチは非常にうまく機能していることがわかります。

彼は、特定のサービス システムの負荷テストの初期段階では、負荷に合わせてその (システム) 最適な構成を選択するため、負荷に合わせてシステムをセットアップする詳細についてはあまり深く掘り下げないことにしています。

しかし、それを完全に排除するわけではありません - 少なくとも理解のレベルでは、システムは「調整ノブ」とこれらのノブの回転の許容範囲について知っておく必要があります。

このアプローチにより、最適なシステム構成を比較的迅速に見つけることができます。
そして、テストの結果に基づいて、システムパフォーマンスメトリックとシステム設定パラメーターの値の間の関係の性質に関する情報を取得することができます。

もちろん、これは、少なくとも所定の負荷の下でのシステムとその動作についての非常に深い理解の出現に貢献するはずです。

実際には、これは、カスタマイズされたシステムを理解するためのコストと、そのようなシステムのテストを準備するためのコストとを交換することになります。

個別に指摘しておきたいのは、このアプローチでは、商業運用における運用条件に対するシステム テストの適切性の程度が非常に重要であるということです。

ご清聴いただきありがとうございました。

出所： habr.com