과학적인 찌르기 방법 또는 벤치마크와 최적화 알고리즘을 사용하여 데이터베이스 구성을 선택하는 방법

안녕하세요.

나는 생각과 시행착오의 결과인 내 발견을 공유하기로 결정했습니다.
물론 이것은 발견된 것이 아닙니다. 이 모든 것은 응용 통계 데이터 처리 및 모든 시스템의 최적화에 관여하는 사람들(꼭 DBMS일 필요는 없음)에게 오랫동안 알려져 있었어야 합니다.
그리고: 그렇습니다. 그들은 자신의 연구에 대해 흥미로운 기사를 쓴다는 것을 알고 있습니다. 예 (UPD.: 댓글에서 그들은 매우 흥미로운 프로젝트를 지적했습니다. 수달 )
반면에, IT 전문가인 DBA 사이에서 인터넷에서 이 접근 방식이 널리 언급되거나 전파되는 것을 본 적이 없습니다.

그래서 요점까지.

어떤 종류의 작업을 서비스하기 위해 특정 서비스 시스템을 설정하는 작업이 있다고 가정해 보겠습니다.

이 작업에 대해서는 그것이 무엇인지, 이 작업의 품질을 어떻게 측정하는지, 이 품질을 측정하는 기준은 무엇인지가 알려져 있습니다.

또한 이 서비스 시스템에서 작업이 수행되는 방식이 어느 정도 알려져 있고 이해되어 있다고 가정해 보겠습니다.

"다소" - 이는 생산 단계에 충분히 적합한 테스트 로드를 사용하여 시스템에 합성하고 적용할 수 있는 특정 도구, 유틸리티, 서비스를 준비(또는 어딘가에서 가져오는)하는 것이 가능함을 의미합니다. 생산 작업에 충분히 적합한 조건에서.

글쎄, 작업 생산성 측면에서 이 시스템을 구성하는 데 사용할 수 있는 이 서비스 시스템에 대한 일련의 조정 매개변수가 알려져 있다고 가정해 보겠습니다.

그리고 문제는 무엇입니까? 이 서비스 시스템에 대한 완전한 이해가 충분하지 않아 특정 플랫폼의 향후 로드에 대해 이 시스템의 설정을 전문적으로 구성하고 시스템에 필요한 생산성을 얻을 수 있습니다.

잘. 이것은 거의 항상 그렇습니다.

여기서 무엇을 할 수 있나요?

글쎄, 가장 먼저 떠오르는 것은 이 시스템에 대한 문서를 보는 것입니다. 조정 매개변수 값에 허용되는 범위가 무엇인지 이해합니다. 예를 들어 좌표 하강 방법을 사용하여 테스트에서 시스템 매개 변수 값을 선택합니다.

저것들. 구성 매개변수에 대한 특정 값 세트의 형태로 시스템에 일종의 구성을 제공합니다.

이 도구 유틸리티 로드 생성기를 사용하여 테스트 로드를 적용합니다.
그리고 값(응답 또는 시스템 품질 측정 기준)을 살펴보세요.

두 번째 생각은 이것이 매우 오랜 시간이라는 결론일 수도 있다.

즉, 설정 매개변수가 많고, 실행되는 값의 범위가 크고, 각 개별 부하 테스트를 완료하는 데 많은 시간이 걸리는 경우, 예, 이 모든 작업에 허용할 수 없을 정도로 많은 시간이 걸릴 수 있습니다. 장기.

글쎄요, 여러분이 이해하고 기억할 수 있는 것은 다음과 같습니다.

서비스 시스템 설정 매개변수의 값 세트에는 일부 값의 시퀀스로 벡터가 있음을 알 수 있습니다.

이러한 각 벡터는 (이 벡터의 영향을 받지 않는다는 점에서) 다른 것들이 동일하다는 점에서 완전히 명확한 메트릭 값, 즉 테스트 로드 하에서 시스템 작동 품질을 나타내는 지표에 해당합니다.

즉,

시스템 구성 벡터를 다음과 같이 표시하겠습니다. 어디에서 ; 어디 — 시스템 구성 매개변수의 수, 이러한 매개변수가 몇 개 있는지.

그리고 이에 대응하는 메트릭의 값은 그것을 다음과 같이 표시하자
, 그러면 우리는 함수를 얻습니다:

그렇다면 모든 것이 즉각적으로 귀결됩니다. 제 경우에는 학생 시절에는 거의 잊어버렸던 함수의 극값을 검색하는 알고리즘이 나왔습니다.

좋습니다. 그러나 여기서는 어떤 알고리즘을 사용할 것인지에 대한 조직적이고 적용 가능한 질문이 발생합니다.

1. 어떤 의미에서는 손으로 코딩하는 일이 줄어듭니다.
2. 그리고 그것이 작동하려면, 즉 극값(있는 경우)을 찾았습니다. 음, 적어도 좌표 하강보다 빠릅니다.

첫 번째 요점은 그러한 알고리즘이 이미 구현되어 있고 어떤 형태로든 코드에서 사용할 준비가 된 일부 환경을 살펴볼 필요가 있음을 암시합니다.
글쎄, 나도 알아 python и cran-r

두 번째 요점은 알고리즘 자체, 그것이 무엇인지, 요구 사항이 무엇인지, 작업의 특징에 대해 읽어야 한다는 것을 의미합니다.

그리고 그들이 제공하는 것은 결과 또는 알고리즘 자체에서 직접적으로 유용한 부작용이 될 수 있습니다.

또는 알고리즘의 결과로부터 얻을 수도 있습니다.

입력 조건에 따라 많은 것이 달라집니다.

예를 들어, 어떤 이유로든 결과를 더 빨리 얻어야 한다면 경사하강법 알고리즘을 살펴보고 그 중 하나를 선택해야 합니다.

또는 시간이 그다지 중요하지 않다면 예를 들어 유전 알고리즘과 같은 확률론적 최적화 방법을 사용할 수 있습니다.

나는 유전 알고리즘을 사용하여 시스템 구성을 선택하는 이 접근 방식의 작업을 다음으로 말하자면 실험실 작업으로 고려할 것을 제안합니다.

출처:

1. 서비스 시스템으로서 다음을 수행하십시오. oracle xe 18c
2. 트랜잭션 활동과 목표(트랜잭션/초 단위)에서 하위 데이터베이스의 가능한 최고 처리량을 얻는 것을 목표로 하십시오.
3. 트랜잭션은 데이터 작업의 성격과 작업 컨텍스트에 따라 매우 다를 수 있습니다.
   이는 대량의 표 형식 데이터를 처리하지 않는 트랜잭션이라는 점에 동의합시다.
   다시 실행보다 더 많은 실행 취소 데이터를 생성하지 않으며 많은 비율의 행과 큰 테이블을 처리하지 않는다는 의미입니다.

이는 이 테이블에 소수의 인덱스가 있는 다소 큰 테이블의 한 행을 변경하는 트랜잭션입니다.

이 상황에서 트랜잭션 처리를 위한 하위 데이터베이스의 생산성은 예약에 따라 산화환원 데이터베이스의 처리 품질에 따라 결정됩니다.

면책 조항 - subdb 설정에 대해 구체적으로 이야기하는 경우.

왜냐하면 일반적인 경우 테이블 형식 데이터 및/또는 테이블 형식 모델을 사용한 사용자 작업 설계로 인해 SQL 세션 간에 트랜잭션 잠금이 있을 수 있기 때문입니다.

물론 이는 TPS 지표에 우울한 영향을 미칠 것이며 이는 하위 데이터베이스와 관련하여 외생적 요인이 될 것입니다. 음, 이것이 표 형식 모델이 설계된 방식과 막힘이 발생하는 내부 데이터 작업 방식입니다.

따라서 실험의 순수성을 위해 이 요소는 제외하고, 아래에서는 그 방법을 구체적으로 설명하겠습니다.

1. 명확성을 위해 데이터베이스에 제출된 SQL 명령의 100%가 DML 명령이라고 가정하겠습니다.
   테스트에서는 하위 데이터베이스를 사용하는 사용자의 특성이 동일하도록 하십시오.
   즉, skl 세션 수, 표 형식 데이터, skl 세션이 이들과 작동하는 방식입니다.
2. Subd는 다음에서 작동합니다. FORCE LOGGING, ARCHIVELOG 개조. 플래시백 데이터베이스 모드는 하위 레벨에서 꺼집니다.
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

처음에는 이러한 로드 조건에서 transaction subd를 사용하고 싶었습니다. SLOB 유틸리티
정말 놀라운 기능이 있습니다. 저자의 말을 인용하겠습니다.

SLOB의 핵심은 'SLOB 방식'이다. SLOB 방법은 플랫폼 테스트를 목표로 합니다.
애플리케이션 경합 없이. 하드웨어 성능을 최대화할 수는 없습니다.
예를 들어 애플리케이션 잠금 또는 심지어는 바인딩된 애플리케이션 코드를 사용합니다.
Oracle 데이터베이스 블록을 공유합니다. 맞습니다. 데이터를 공유하면 오버헤드가 발생합니다.
데이터 블록에서! 그러나 기본 배포의 SLOB는 이러한 경합에 영향을 받지 않습니다.

이 선언은 다음과 같습니다.
cl 세션의 병렬성 정도를 조절하는 것이 편리합니다. 이것이 핵심입니다. -t 유틸리티를 실행하다 runit.sh SLOB에서
DML 명령의 비율은 하위 항목, 각 텍스트 세션, 매개변수로 전송되는 텍스트 메시지 수로 규제됩니다. UPDATE_PCT
별도로 매우 편리하게: SLOB 로드 세션 전후에 자체적으로 - statspack 또는 awr-snapshots(준비하도록 설정된 것)을 준비합니다.

그러나 그것은 밝혀졌다 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분으로 구성했습니다.

로드 중인 서브의 작동을 설명하는 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 설정과 subd에 대한 주어진 로드를 사용하여 얼마나 많은 트랜잭션을 처리합니까? subd는 초당 트랜잭션을 처리합니다.

즉, 펼칠 때 피트니스 함수 내에서 다음과 같은 여러 단계를 수행해야 합니다.

1. 숫자의 입력 벡터 처리 - 이를 하위 데이터 매개변수의 값으로 변환합니다.
2. 주어진 크기의 주어진 수의 리두 그룹을 생성하려는 시도입니다. 게다가 그 시도가 실패할 수도 있다.
   실험의 순수성을 위해 이미 하위 그룹에 어느 정도 수량과 규모로 존재했던 잡지 그룹 - d.b. 삭제되었습니다.
3. 이전 지점이 성공한 경우: 구성 매개변수의 값을 데이터베이스에 지정(역시: 실패할 수 있음)
4. 이전 단계가 성공한 경우: subd를 중지하고 새로 지정된 매개변수 값이 적용되도록 subd를 시작합니다. (다시 말하지만, 오류가 있을 수 있습니다)
5. 이전 단계가 성공한 경우: 부하 테스트를 수행합니다. subd에서 측정항목을 가져옵니다.
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예를 들어, subd 매개변수의 값을 설정하는 stop-start는 다음을 기반으로 수행됩니다. cran-r 기능 system2

도움을 받아 일부 bash 스크립트 또는 명령이 호출됩니다.

예를 들면 다음과 같습니다

set_db_매개변수

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: 별도의 질문입니다.
실험실 작업의 틀 내에서 이 수치는 중요하지 않습니다. 중요한 것은 역학, 이 값이 어떻게 변하는가입니다.

여기의 역학은 좋습니다.
적어도 하나의 요소가 염색체 벡터를 정렬하는 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, 요점은 중요하지 않습니다.

결과적으로, 이 경우 속성의 중요도를 평가하기 위해 다음과 같은 결과가 얻어졌다.

잘. 따라서 우리는 전역 반영을 시작할 수 있습니다.

1. 이러한 테스트 조건에서 가장 중요한 것은 매개변수였습니다. commit_wait
   기술적으로 이는 subdb 로그 버퍼의 리두 데이터를 현재 로그 그룹에 쓰기 위한 io 작업의 실행 모드(동기 또는 비동기)를 지정합니다.
   가치 nowait 이는 tps 메트릭 값이 거의 수직으로 여러 번 증가하는 결과를 가져옵니다. 이는 다시 실행 그룹에 비동기 io 모드를 포함시키는 것입니다.
   별도의 질문은 식품 데이터베이스에서 이 작업을 수행해야 하는지 여부입니다. 여기서는 이것이 중요한 요소라는 점만 언급하겠습니다.
2. subd:의 로그 버퍼 크기가 중요한 요소인 것은 논리적입니다.
   로그 버퍼의 크기가 작을수록 버퍼링 용량이 작아지고 오버플로가 더 자주 발생하며/또는 새로운 산화환원 데이터의 일부를 위해 여유 공간을 할당할 수 없게 됩니다.
   이는 로그 버퍼의 공간 할당 및/또는 로그 버퍼의 리두 데이터를 리두 그룹으로 덤프하는 것과 관련된 지연을 의미합니다.
   물론 이러한 지연은 트랜잭션에 대한 데이터베이스 처리량에 영향을 미칩니다.
3. 매개 변수 db_block_checksum: 글쎄요, 일반적으로 트랜잭션 처리로 인해 하위 데이터베이스의 버퍼 캐시에 다티 블록이 형성된다는 점은 분명합니다.
   데이터 블록의 체크섬 확인이 활성화되면 데이터베이스는 데이터 블록 본문에서 이러한 체크섬을 계산하고 데이터 블록 헤더에 기록된 내용(일치/일치하지 않음)으로 확인해야 합니다.
   이러한 작업은 역시 데이터 처리를 지연시킬 수 없으며 따라서 이 매개변수를 설정하는 매개변수와 메커니즘이 중요한 것으로 나타납니다.
   그렇기 때문에 공급업체는 이 매개변수에 대한 문서에서 해당 매개변수에 대해 다른 값을 제공하고 영향이 있을 것이라고 언급합니다. 하지만 "off" 및 "off"까지 다른 값을 선택할 수 있습니다. 다른 영향.

글쎄요, 세계적인 결론입니다.

일반적으로 이 접근 방식은 꽤 효과적인 것으로 나타났습니다.

그는 특정 서비스 시스템의 로드 테스트 초기 단계에서 로드에 대한 시스템 설정의 세부 사항을 너무 많이 탐구하지 않고 로드에 대한 최적의 구성(시스템)을 선택하기 위해 스스로를 허용합니다.

그러나 최소한 이해 수준에서는 이를 완전히 배제하지는 않습니다. 시스템은 "조정 손잡이"와 이러한 손잡이의 허용 회전 범위에 대해 알아야 합니다.

그러면 이 접근 방식을 통해 최적의 시스템 구성을 상대적으로 빠르게 찾을 수 있습니다.
그리고 테스트 결과를 바탕으로 시스템 성능 지표와 시스템 설정 매개변수 값 간의 관계 특성에 대한 정보를 얻을 수 있습니다.

물론 이는 적어도 주어진 부하 하에서 시스템과 작동에 대한 매우 깊은 이해의 출현에 기여해야 합니다.

실제로 이는 맞춤형 시스템을 이해하는 데 드는 비용을 시스템 테스트를 준비하는 데 드는 비용으로 교환하는 것입니다.

저는 별도로 언급하고 싶습니다. 이 접근 방식에서는 상업적 운영에서 갖게 될 운영 조건에 대한 시스템 테스트의 적절성 정도가 매우 중요합니다.

귀하의 관심과 시간에 감사드립니다.

출처 : habr.com