Aurora Server v2(미리보기) 없음-RAM

오로라 서버란 무엇입니까?이것이 바로 RDS Aurora가 자동으로 확장하는 이름입니다. 실례 크기를 설정하지 않아도 됩니다. (vCPU 2개와 2GB RAM이 있는burstable db.t3.small에서 64개의 vCPU와 512GB RAM이 있는db.r5.16xlarge), ACU/Aurora 용량 단위에 따라 범위를 정의합니다.ACU는 CPU+RAM에 관한 것입니다.이 블로그 글은 램에 주목할 것이다.

오로라 서버 없음 v1

Serverless v1에서 ACU는 1(2GB RAM)에서 256(488GB RAM)으로 증가하고, 입도는 2의 멱이다. 매번 확장할 때마다 실례를 배로 늘린다.인스턴스가 사용되지 않을 때 중단(5분 이내에 접속되지 않음)된 경우 최소 용량을 0으로 선택할 수도 있지만 이후 첫 번째 접속은 정의된 최소 용량으로 재부팅하는 데 몇 분 정도 걸립니다.CPU와 같은 측정 지표에서 축소(70% 이상이면 확대, 30% 미만이면 축소)한다.접속 수(최대 접속 수의 백분율),및 사용 가능한 RAM(하지만 이것은 실제 RAM에서 최대 연결 수를 계산하는 방식입니다. RAM 한도값은 서버less v1에서 공유 버퍼의 사용을 고려했다고 생각하지 않습니다. Aurora는 한도값에 도달했을 때 확대를 시도했지만, 축소는 CPU와 연결이 한도값보다 낮고, 축소는sc 후 15분 안에 발생할 수 없습니다.)가속(냉각기).또한 Serverless v1에서 확장하는 것은 데이터베이스를 중지하고 다른 VM에서 시작하는 것을 의미하기 때문에 활성 연결 외부에서 확장을 시도하고 시간 초과나 강제(선택 사항)가 발생할 수 있습니다.
서버 1이 없어도 계속 사용할 수 있습니다.현재 일부 기능은 v2에서 사용할 수 없습니다. 예를 들어 PostgreSQL 호환성이나 데이터 API 등입니다.하지만 그들은 올 것이다. 나는 언젠가 v2가 v1을 대체할 것이라고 생각한다.

Aurora Server v2(미리보기) 없음

이 새 서비스는 더욱 정교한 자동 축소 기능을 가지고 있다.서버 가상화를 통해 재부팅 없이 VM의 vCPU 수를 늘리고, MySQL 5.7.5는 온라인으로 버퍼를 변경할 수 있습니다.이렇게 하면 0.5 ACU 이득을 선언하는 확대 및 축소 시 세분화된 세분화가 제공되므로 기다릴 필요가 없습니다.미리보기는 4ACU(8GB)에서 32(64GB)로 늘었으나 최소 0.5ACU, 최대 256ACU로 계획됐다.그런 다음 콜드 부팅 지연을 방지하기 위해 인스턴스를 중지하는 대신 0.5 ACU의 낮은 수준으로 유지하여 연결이 도착하면 데이터베이스를 즉시 사용할 수 있습니다.세분화는 인스턴스를 두 배로 늘리는 대신 0.5 ACU를 증가시킵니다.따라서 ACU가 v2에서 더 비싸더라도 소모량이 적을 수 있습니다.그리고 규모가 줄어들면 15분도 기다리지 않고 용량을 절반으로 줄일 수 있다. 인터넷에서 점차적으로 줄일 수 있기 때문이다.물론 공유 실례에 사용할 수 있는 vCPU가 없다면, 재부팅 실례는 여전히 가능하지만, 이런 상황은 자주 발생해서는 안 된다.
다음은 8GB 프레젠테이션 테이블의 예입니다.

--------------
create procedure demo(n int)
begin
 declare i int default 0;
 create table demo (id int not null primary key auto_increment, n int,x varchar(1000));
 insert into demo(n,x) values (1,lpad('x',898,'x'));
 while i < n do
  set i = i + 1;
  insert into demo(n,x) select n,x from demo;
  commit;
 end while;
end
--------------

--------------
call demo(23)
--------------

가상 머신 동작

이 창설 과정에서 나는 여러 차례 축소 (실례 창설 후) 와 증대 (표 줄 촬영 기간) 를 겪었다. 이 경우 가상 컴퓨터가 다른 서버로 이동되었을 수도 있고 다시 시작해야 한다는 것을 알 수 있다.CloudWatch의 "엔진 가동 시간"은 재부팅과 ACU의 "서버 없는 데이터베이스 용량"을 통해 (용량 단위)됩니다.

가상 머신을 이동하는 동안 다음과 같은 오류가 발생했습니다.

ERROR 2013 (HY000) at line 29: Lost connection to MySQL server during query

이 경우 다시 시도하기만 하면 됩니다.만약 그렇지 않다면, 최소/최대 ACU를 설정하거나, 설정된 데이터베이스로 이동할 수 있습니다.

--------------
analyze table demo
--------------
Table           Op       Msg_type   Msg_text
-----------     -------  --------   --------
franck.demo     analyze  status     OK

--------------
select round(data_length/1024/1024) TABLE_MB,round(index_length/1024/1024) INDEX_MB,table_rows,table_name,table_type,engine from information_s
chema.tables where table_schema='franck'
--------------

TABLE_MB  INDEX_MB        table_rows      table_name      table_type      engine
--------  --------        ----------      ----------      ----------      ------
    8200         0           7831566            demo      BASE TABLE      InnoDB

여기서 나는 내 책상의 크기를 검사했다. 약 8GB.

버퍼 탱크

vCPU를 언급했는데 램은요?가상 머신 메모리도 온라인으로 크기를 조절할 수 있지만 차이가 있다.CPU가 있어 너무 빨리 축소하면 바로 확장하여 이전 성능으로 복구할 수 있다.그러나 RAM을 사용할 때 캐시에서 데이터를 꺼냈습니다. 이 데이터는 첫 번째 세션이 다시 뜨거워지기 전에 바로 돌아오지 않습니다.따라서 서버 v2가 없으면 InnoDB LRU(최근에 가장 적게 사용된) 버퍼를 보고 버퍼를 버릴 위험을 추정해야 합니다.내가 InnoDB를 언급한 것은 현재Aurora Serverless v2가MySQL 호환성만 지원하기 때문이다.
프레젠테이션에서 다음 프로그램을 실행하고 있습니다.

use franck;
set profiling = 1;
select count(*) from demo where x='$(date) $RANDOM';
show profiles;

나는 이미 순환에서 그것을 실행했기 때문에 세션이 8GB를 계속 읽는다. (술어는 어떤 내용도 필터하지 않고, 매번 다른 검색만 실행한다. 왜냐하면 나는 캐시가 아닌 버퍼에 대한 영향을 표시하고 싶기 때문이다.)
그리고 약 18:00부터 18:23까지 다른 세션을 실행했습니다.

use franck;
delimiter $$
drop procedure if exists cpu;
create procedure cpu()
begin
 declare i int default 0;
 while 1  do
  set i = i + 1;
 end while;
end$$
delimiter ;
call cpu();

내 MySQL 프로그램 코드로 나를 평가하지 마세요.)저는 그냥 CPU 순환하는 거예요.
20분 후:

MySQL [(none)]> show full processlist;

--------------
show full processlist
--------------

+-----+----------+--------------------+--------+---------+------+--------------+------------------------------------------------------------------------+
| Id  | User     | Host               | db     | Command | Time | State        | Info                                                                   |
+-----+----------+--------------------+--------+---------+------+--------------+------------------------------------------------------------------------+
|  42 | admin    | 192.169.29.1:22749 | franck | Query   |    0 | NULL         | call cpu()                                                             |
| 302 | rdsadmin | localhost          | NULL   | Sleep   |    1 | NULL         | NULL                                                                   |
| 303 | rdsadmin | localhost          | NULL   | Sleep   |    0 | NULL         | NULL                                                                   |
| 304 | rdsadmin | localhost          | NULL   | Sleep   |    0 | NULL         | NULL                                                                   |
| 305 | rdsadmin | localhost          | NULL   | Sleep   |    0 | NULL         | NULL                                                                   |
| 339 | admin    | 192.169.29.1:30495 | NULL   | Query   |    0 | starting     | show full processlist                                                  |
| 342 | admin    | 192.169.29.1:42711 | franck | Query   |    3 | Sending data | select count(*) from demo where x='Sun Dec  6 18:23:25 CET 2020 28911' |
+-----+----------+--------------------+--------+---------+------+--------------+------------------------------------------------------------------------+
7 rows in set (0.00 sec)

MySQL [(none)]> kill 42;
--------------
kill 42
--------------

나는 이미 달리기 순환을 멈추었다.
다음은 CloudWatch에서 본 내용입니다.

DB 연결: 저는 항상 바쁜 연결을 가지고 있는데 대부분 프레젠테이션의 중복 검색에 사용됩니다.20분 안에 두 번째 (내 CPU 프로그램).마지막 세 번째는 내가 세션을 종료할 때

서버 데이터베이스 용량이 없음: ACU 수량입니다.스캔만 실행 중인 경우 이 값은 6이고 CPU 세션이 실행 중인 경우

는 11로 확대됩니다.

CPU 사용률(백분율): 운영 체제 스레드의 백분율입니다.스캔 세션만 실행할 때는 13.6%였고 추가 CPU가 실행되는 동안에는 23%에 달했다.ACU가 6에서 11로 확장되면 운영 체제 스레드의 수가 증가하지 않습니다.이따가 다시 돌아올게요

엔진 정상 가동 시간: 분당 1분씩 증가한다. 이는 모든 확대/축소가 엔진을 다시 가동하지 않은 상태에서 이루어진다는 것을 의미한다

현재, CloudWatch metrics에서 보지 못한 것은 제 프레젠테이션 테이블 스캔의 응답 시간입니다.

Dec 06 17:52:37 1       79.03579950     select count(*) from demo where x='Sun Dec  6 17:51:17 CET 2020 13275'
Dec 06 17:53:59 1       79.83154300     select count(*) from demo where x='Sun Dec  6 17:52:37 CET 2020 4418'
Dec 06 17:55:20 1       79.81895825     select count(*) from demo where x='Sun Dec  6 17:53:59 CET 2020 11596'
Dec 06 17:56:40 1       78.29040100     select count(*) from demo where x='Sun Dec  6 17:55:20 CET 2020 25484'
Dec 06 17:58:02 1       80.15728125     select count(*) from demo where x='Sun Dec  6 17:56:40 CET 2020 15321'
Dec 06 17:59:42 1       98.29309550     select count(*) from demo where x='Sun Dec  6 17:58:02 CET 2020 31126'
Dec 06 18:01:09 1       85.07732725     select count(*) from demo where x='Sun Dec  6 17:59:42 CET 2020 29792'
Dec 06 18:02:30 1       79.16154650     select count(*) from demo where x='Sun Dec  6 18:01:09 CET 2020 21930'
Dec 06 18:02:34 1       2.81377450      select count(*) from demo where x='Sun Dec  6 18:02:30 CET 2020 12269'
Dec 06 18:02:38 1       2.77996150      select count(*) from demo where x='Sun Dec  6 18:02:34 CET 2020 30306'
Dec 06 18:02:42 1       2.73756325      select count(*) from demo where x='Sun Dec  6 18:02:38 CET 2020 22678'
Dec 06 18:02:47 1       2.77504400      select count(*) from demo where x='Sun Dec  6 18:02:42 CET 2020 933'
Dec 06 18:02:51 1       2.73966275      select count(*) from demo where x='Sun Dec  6 18:02:47 CET 2020 21922'
Dec 06 18:02:56 1       2.87023975      select count(*) from demo where x='Sun Dec  6 18:02:51 CET 2020 9158'
Dec 06 18:03:00 1       2.75959675      select count(*) from demo where x='Sun Dec  6 18:02:56 CET 2020 31710'
Dec 06 18:03:04 1       2.72658975      select count(*) from demo where x='Sun Dec  6 18:03:00 CET 2020 27248'
Dec 06 18:03:09 1       2.71731325      select count(*) from demo where x='Sun Dec  6 18:03:04 CET 2020 18965'

8GB를 스캔하는 데 1분 이상, 즉 100MB/s가 소요됩니다. 이것은 우리가 물리적으로 읽을 수 있는 것입니다.6 ACU 인스턴스에는 8GB를 사용할 수 없습니다.그리고 다른 세션을 시작하고 11 ACU로 자동 배율을 트리거할 때 메모리가 충분해졌습니다. 이것이 바로 검색 응답 시간이 3초도 안 되는 이유입니다.나는 운영체제를 보지 않으면 계산하기가 쉽지 않기 때문에 CPU 사용률로 돌아갈 것이라고 말했다.나는 이것이 박문을 한 편 더 보낼 가치가 있다고 생각한다.계수가 CPU에서 단독으로 실행될 때, 나는 13.6%의 CPU 이용률을 보았다.여기에는 I/O가 포함되지만 6개의 ACU에서 13.6%는 CPU에서 세션을 실행하는 것과 같은 것으로 알고 있습니다.따라서 검색에 입출력 제한이 없을 수 있습니다.그리고 나는 다른 세션을 추가했다. 나는 그것이 완전히 CPU에서 실행되고, 연결 시간 사이에, 스캔도 완전히 CPU에서 실행된다는 것을 안다. (모두 버퍼에서 나온 것)CPU 활용도 23%는 11 ACU 규모에서 CPU를 완전히 사용하는 2개 세션이 26%를 차지한다고 생각합니다.나는 다른 테스트를 해서 이 점을 확인할 것이다.나는 이곳의 Performance Insight가 실제 상황을 이해하기 위해 그립다...
그리고 보시다시피 동시 세션을 중지하면 크기가 줄어들고 응답 시간을 상상할 수 있습니다.

Dec 06 18:24:23 1       3.03963650      select count(*) from demo where x='Sun Dec  6 18:24:17 CET 2020 2815'
Dec 06 18:24:27 1       2.80417800      select count(*) from demo where x='Sun Dec  6 18:24:23 CET 2020 16763'
Dec 06 18:24:31 1       2.77208025      select count(*) from demo where x='Sun Dec  6 18:24:27 CET 2020 29473'
Dec 06 18:24:36 1       3.13085700      select count(*) from demo where x='Sun Dec  6 18:24:31 CET 2020 712'
Dec 06 18:24:41 1       2.77904025      select count(*) from demo where x='Sun Dec  6 18:24:36 CET 2020 17967'
Dec 06 18:24:45 1       2.76111900      select count(*) from demo where x='Sun Dec  6 18:24:41 CET 2020 20407'
Dec 06 18:24:49 1       2.79092475      select count(*) from demo where x='Sun Dec  6 18:24:45 CET 2020 7644'
Dec 06 18:26:17 1       85.68287300     select count(*) from demo where x='Sun Dec  6 18:24:49 CET 2020 691'
Dec 06 18:27:40 1       81.58135400     select count(*) from demo where x='Sun Dec  6 18:26:17 CET 2020 14101'
Dec 06 18:29:02 1       80.00523900     select count(*) from demo where x='Sun Dec  6 18:27:40 CET 2020 31646'
Dec 06 18:30:22 1       78.79213700     select count(*) from demo where x='Sun Dec  6 18:29:02 CET 2020 811'
Dec 06 18:31:42 1       78.37765950     select count(*) from demo where x='Sun Dec  6 18:30:22 CET 2020 24539'
Dec 06 18:33:02 1       78.64492525     select count(*) from demo where x='Sun Dec  6 18:31:42 CET 2020 789'
Dec 06 18:34:22 1       78.36776750     select count(*) from demo where x='Sun Dec  6 18:33:02 CET 2020 2321'
Dec 06 18:35:42 1       78.38105625     select count(*) from demo where x='Sun Dec  6 18:34:22 CET 2020 27716'
Dec 06 18:37:04 1       79.74060525     select count(*) from demo where x='Sun Dec  6 18:35:42 CET 2020 487'

예, 6 ACU로 낮추고 버퍼를 줄여 물리적 I/O로 돌아갑니다...
CPU와 RAM이 비례적으로 축소될 때, 이것은 위험이다. 한 라인이 CPU를 절약하기 위해 충분한 RAM이 없을 수도 있다.그리고 모순되는 것은 더 많은 합병 활동이 있을 때 더 많은 것을 얻을 수 있다는 것이다.다음은 내가 만나고 싶지 않은 상황이다.

프랭크 파초트

그래.그런 다음 VM을 이동하고 엔진을 재부팅해야 할 경우 예비 캐시 비용을 계산합니다.테스트는 하지 않았지만, 더 높은 부하 -> 확대 -> 이동 가상 기기 -> 더 많은 I/O -> 더 적은 CPU% (캐시가 예열될 때까지) -> 여기서 규모를 줄이는 것은 나쁜 생각입니다.
2020년 12월 6일 오후 20:32

ACU 및 버퍼 크기

"창설 과정에서만 0 ACU를 보았지만 이 미리 보기에는""일시 중지""옵션이 없으며 4~32 ACU 사이만 가능합니다."

나는 관련 설정을 검사하기 위해 이 모든 설비를 테스트했다.ACU와 max 연결, VM 크기, 버퍼 크기 및 쿼리 캐시 크기를 x축에서 확인할 수 있습니다.

여기서, 당신은 나의 8GB 프레젠테이션 테이블에 무슨 일이 일어났는지 볼 수 있습니다. 이것은 6 ACU 모양에 적합하지 않고, 버퍼는 6GB이지만, 메모리에는 13.5GB의 11 ACU 모양을 보존하고 있습니다.
Serverless의 다양한 재미있는 버퍼 설정에서 다음을 수행합니다.

--------------
show global variables like '%innodb%buffer_pool%'
--------------

Variable_name   Value
innodb_buffer_pool_chunk_size   157286400
innodb_buffer_pool_dump_at_shutdown     OFF
innodb_buffer_pool_dump_now     OFF
innodb_buffer_pool_dump_pct     25
innodb_buffer_pool_filename     ib_buffer_pool
innodb_buffer_pool_instances    8
innodb_buffer_pool_load_abort   OFF
innodb_buffer_pool_load_at_startup      OFF
innodb_buffer_pool_load_now     OFF
innodb_buffer_pool_size 3774873600
innodb_shared_buffer_pool_uses_huge_pages       OFF
--------------

커다란 페이지가 서버가 없는 환경에서 닫힙니다.이 innodb 공유 버퍼 풀 사용 거대한 페이지는 MySQL이 아니라 Aurora에 특정한 페이지로 제공된 Aurora와 스타일이 같지만 서버가 없는 환경에서 닫힙니다.서버가 없으면 메모리를 어떻게 분배하고 취소할 수 있는지를 고려하면 일리가 있다.

ACU 및 CPU

내가 언급한 바와 같이 이것은 새로운 박문할 가치가 있다.아마존은 ACU-vCPU 등가물을 제시하지 않았다.그리고 내가 본 CPU 사용률 비율을 감안하면 가상 컴퓨터는 크기를 조절하지 않았다고 생각한다.엔진이 다시 작동하는 것을 보지 않으면

대가

가격에 관해서 제리미 데리의 분석을 읽어 드릴게요. https://www.jeremydaly.com/aurora-serverless-v2-preview/
내 의견...서버가 없는 것은 클라우드 공급자가 수입을 낮추기 위해 제공하는 기능이다.그럼 더 비싸죠.클라우드 공급자는 VM을 이동하지 않고 확장할 수 있도록 유휴 CPU의 여유를 유지해야 한다(가용성에 영향을 줄 수 있으므로 더 많은 시간과 메모리를 새로 고쳐야 한다).바쁠 때는 돈을 더 많이 내지만, 러시아워에 포화될 위험을 무릅쓰지 않고 여가 시간을 절약할 수 있다.
어쨌든 서버가 없는 것이 선택이라는 것을 잊지 마세요.그것은 너의 요구에 적합할 수도 있고, 적합하지 않을 수도 있다.위에서 설명한 버퍼 효과를 원하지 않는다면, 이 실례에서 자신이 얼마나 많은 RAM을 가지고 있는지 정확히 알 수 있는 실례를 제공할 수 있습니다.그리고이것은 미리 보기 버전이라는 것을 잊지 마라. 베타 버전처럼 무엇이든 바꿀 수 있다.다음 기사에서는 CPU 사용률https://blog.dbi-services.com/aurora-serverless-v2-cpu/에 대해 자세히 설명합니다.