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

다음은 저의 이전 댓글https://blog.dbi-services.com/aurora-serverless-v2-ram/입니다.‎그 전에 너는 마땅히 먼저 읽어야 한다.나는 램의 자동 확장을 연구하고 있는데, 지금은 CPU 이용률을 연구할 때가 되었다.
Aurora Serverless v2 데이터베이스를 만들었습니다. (테스트 버전 미리 보기 버전이라는 것을 잊지 마십시오.) 4 ACU에서 32 ACU로 자동으로 확장할 수 있습니다.버퍼가 어떻게 자동으로 크기를 조절하는지 보여주기 위해 시계 스캔을 보고 있습니다.여기에서, 나는 하나, 그리고 두 개, 그리고 트리에서 같은 cpu () 과정을 실행할 것이다.자동 배율 조정 및 관련 지표의 동시 세션을 표시합니다.
다음은 초당 조회 수로 표시된 글로벌 워크로드(AWS에 PMMprevious post이 설치되어 있으므로 사용하도록 함)입니다.

운영 요약 및 용량 자동 축소 및 측정된 CPU 활용도:

10:38 1 session  running,  6 ACU , 14% CPU usage
10:54 2 sessions running, 11 ACUs, 26% CPU usage
11:09 3 sessions running, 16 ACUs, 39% CPU usage
11:25 4 sessions running, 21 ACUs, 50% CPU usage
11:40 5 sessions running, 26 ACUs, 63% CPU usage
11:56 6 sessions running, 31 ACUs, 75% CPU usage
12:12 7 sessions running, 32 ACUs, 89% CPU usage
12:27 8 sessions running, 32 ACUs, 97% CPU usage
타임스탬프는 CPU에서 실행되는 세션을 추가하기 시작한 시간을 보여 줍니다. 그러면 클라우드 워치의 지표와 일치할 수 있습니다.여기서 볼 때 아우라 데이터베이스 엔진은 8VCPU 기기에서 작동하는 것 같지만 ACU의 증가는'CPU 이용률'지표가 바탕으로 하는 운영체제의 라인을 동태적으로 바꾸지 않았다.
CloudWatch에 대한 자세한 내용은 다음과 같습니다.

이러한 지표는 다음과 같습니다.
  • 왼쪽 상단의 서버 없음 용량 유닛: ACU를 4에서 32(미리보기)로 자동 확장, 0.5
  • 세분화
  • 오른쪽 상단의 CPU 사용률: 사용 가능한 스레드의 집합으로 CPU에서 실행되는 세션
  • 왼쪽 하단의 엔진 정상 운행 시간: 이 운행 기간에 다시 가동되지 않음
  • botton의 DB 연결 오른쪽: 시작하기 전에 4개의 빈 세션이 있습니다. 그리고 4를 빼면 세션을 실행할 수 있습니다
  • CPU에는 8개의 세션이 있는데, 나는 이미 CPU를 포화시켰다. 우리가 100%에 도달했을 때, 나는 이것이 8개의 핵이지, 하이퍼스레딩이 아니라고 추측했다.이것은 32개의 ACU이기 때문에 이것은 하나의 ACU가 하나의 핵심의 4분의 1이라는 것을 의미한다. 그러나...
    다음은 내가 PMM에서 보여준 것과 같은 지표이지만 클라우드워치에서 작업 부하의 규모를 다시 한 번 살펴보자.

    ACU가 운영 체제 커널에 비례하면 선형 성능을 기대하지만 그렇지 않습니다.세션은 6개의 ACU에서 초당 125만 회의 쿼리 속도로 실행됩니다.11대의 ACU에서 두 세션의 조회 속도는 초당 180만 건이다.16개의 ACU에서 초당 250만 개의 조회 속도로 트리 세션을 수행합니다.그래서 수학은 그리 간단하지 않다.이것은 16 ACU의 처리량이 8 ACU의 두 배가 아니라는 뜻입니까?저희가 소형 ACU의 버스터블 실례를 사용하고 있죠?8개의 vCPU와 64GB는 최대 32ACU의 서버가 없는 데이터베이스를 시작할 때 데이터베이스에서 실행된다는 뜻입니까?r5.실제 ACU가 얼마든지 상관없이 2xlarge가상 머신은 최대 ACU와 CPU에만 cgroup 또는 유사한 제한을 받습니까?
    나는 또 다른 테스트를 했는데 이번에는 최소와 최대 ACU를 16으로 설정했다.그래서 이것은 데이터베이스를 설정하는 것과 유사할 수 있다.r5.덩치 큰 사람.
    1000만 번 순환한 후에 멈추는 cpu () 프로세스를 수정했습니다.
    
    delimiter $$
    drop procedure if exists cpu;
    create procedure cpu()
    begin
     declare i int default 0;
     while i < 1e7  do
      set i = i + 1;
     end while;
    end$$
    delimiter ;
    
    100만 개의 순환dbfiddle에서 50초가 걸린다. 다른 플랫폼에서 테스트할 수 있다. 이 플랫폼에서 CPU의 속도를 알 수 있다.
    연결 루프를 실행했습니다. 이 함수를 실행하고 시간과 루프를 다시 표시합니다.
    
    Dec 07 18:41:45 real    0m24.271s
    Dec 07 18:42:10 real    0m25.031s
    Dec 07 18:42:35 real    0m25.146s
    Dec 07 18:43:00 real    0m24.817s
    Dec 07 18:43:24 real    0m23.868s
    Dec 07 18:43:48 real    0m24.180s
    Dec 07 18:44:12 real    0m23.758s
    Dec 07 18:44:36 real    0m24.532s
    Dec 07 18:45:00 real    0m23.651s
    Dec 07 18:45:23 real    0m23.540s
    Dec 07 18:45:47 real    0m23.813s
    Dec 07 18:46:11 real    0m24.295s
    Dec 07 18:46:35 real    0m23.525s
    
    이것은 세션으로 CPU 사용률이 26%입니다. (이것이 바로 제가 생각하는 16 ACU의 서버 데이터베이스가 4vCPU 서버에서 실행되지 않는 이유입니다.)
    
    Dec 07 18:46:59 real    0m24.013s
    Dec 07 18:47:23 real    0m24.318s
    Dec 07 18:47:47 real    0m23.845s
    Dec 07 18:48:11 real    0m24.066s
    Dec 07 18:48:35 real    0m23.903s
    Dec 07 18:49:00 real    0m24.842s
    Dec 07 18:49:24 real    0m24.173s
    Dec 07 18:49:49 real    0m24.557s
    Dec 07 18:50:13 real    0m24.684s
    Dec 07 18:50:38 real    0m24.860s
    Dec 07 18:51:03 real    0m24.988s
    
    이것은 두 개의 세션(나는 한 세션만 표시하는 시간)이다. CPU 사용률은 50%이다. 이것은 나의 추측을 증명한다. 나는 CPU 자원의 절반을 사용했다.각 세션의 응답 시간은 한 세션만 실행할 때와 같습니다.
    
    Dec 07 18:51:28 real    0m24.714s
    Dec 07 18:51:53 real    0m24.802s
    Dec 07 18:52:18 real    0m24.936s
    Dec 07 18:52:42 real    0m24.371s
    Dec 07 18:53:06 real    0m24.161s
    Dec 07 18:53:31 real    0m24.543s
    Dec 07 18:53:55 real    0m24.316s
    Dec 07 18:54:20 real    0m25.183s
    
    나는 지금 그곳에서 세 개의 세션을 실행하고 있는데 응답 시간이 여전히 비슷하다. (나의 CPU 사용률은 75%이기 때문에 분명히 나는 여기에 두 개 이상의 핵이 있다. 하이퍼스레딩이 없거나, 실행하는 스레드 수가 핵수를 초과할 때, 나는 성능 손실을 보아야 한다.)
    
    Dec 07 18:54:46 real    0m25.937s
    Dec 07 18:55:11 real    0m25.063s
    Dec 07 18:55:36 real    0m24.400s
    Dec 07 18:56:01 real    0m25.223s
    Dec 07 18:56:27 real    0m25.791s
    Dec 07 18:57:17 real    0m24.798s
    Dec 07 18:57:42 real    0m25.385s
    Dec 07 18:58:07 real    0m24.561s
    
    이것은 모두 네 과목이 있다.CPU가 거의 100% 사용 중이고 응답 시간이 정상적이며 이는 4개의 코어를 실행할 수 있음을 증명합니다.
    
    Dec 07 18:58:36 real    0m28.562s
    Dec 07 18:59:06 real    0m30.618s
    Dec 07 18:59:36 real    0m30.002s
    Dec 07 19:00:07 real    0m30.921s
    Dec 07 19:00:39 real    0m31.931s
    Dec 07 19:01:11 real    0m32.233s
    Dec 07 19:01:43 real    0m32.138s
    Dec 07 19:02:13 real    0m29.676s
    Dec 07 19:02:44 real    0m30.483s
    
    한번 더.현재 CPU는 100%입니다. 프로세스는 4개의 스레드만 사용할 수 있기 때문에 런queue에서 5분의 1을 기다려야 합니다.우리는 응답 시간에 20퍼센트의 추가 시간을 볼 수 있다.
    더 이상 프로세스를 시작하지 않지만 용량을 늘리고 최대 ACU를 24로 설정한 다음 자동 배율을 설정합니다.
    
    ...
    Dec 07 19:08:02 real    0m33.176s
    Dec 07 19:08:34 real    0m32.346s
    Dec 07 19:09:01 real    0m26.912s
    Dec 07 19:09:25 real    0m24.319s
    Dec 07 19:09:35 real    0m10.174s
    Dec 07 19:09:37 real    0m1.704s
    Dec 07 19:09:39 real    0m1.952s
    Dec 07 19:09:41 real    0m1.600s
    Dec 07 19:09:42 real    0m1.487s
    Dec 07 19:10:07 real    0m24.453s
    Dec 07 19:10:32 real    0m25.794s
    Dec 07 19:10:57 real    0m24.917s
    ...
    Dec 07 19:19:48 real    0m25.939s
    Dec 07 19:20:13 real    0m25.716s
    Dec 07 19:20:40 real    0m26.589s
    Dec 07 19:21:06 real    0m26.341s
    Dec 07 19:21:34 real    0m27.255s
    
    
    19:00에 최대 ACU를 24로 늘리고 자동으로 배율을 조정합니다.엔진이 19:09:30에 다시 가동되었는데, 나는 약간의 오류가 발생했다. 19:21까지, 나는 다시 최상의 응답 시간에 도달했다.나는 24개의 ACU 크기의 기기에서 5개의 세션을 실행했다. 나는 이것이 6개의 OS 라인이라고 생각한다. 만약 나의 모든 가설이 정확하다면, 나는 5/6=83%의 CPU 이용률을 예상한다.다음은 CloudWatch의 지표입니다.

    네, 약간의 파동을 거친 후에 우리는 83퍼센트에 달하는 것 같습니다.이 이상들은 아마도 나의 스크립트가 긴 프로그램을 실행한 결과일 것이다.엔진을 재부팅할 때(엔진 가동 시간에 표시됨) 일정 시간 동안 연결을 끊었다가 로드를 줄였다가 CPU 사용률에서 표시됨) 가용 자원을 줄였다가 (서버 용량 단위 없음에서 표시됨)
    ACU와 RAM 간의 대응 관계가 기록되어 있다(최소/최대치를 정의할 때 볼 수 있고 내previous post에 보고된다) 극광을 설정하는 실례 유형은 RAM과 vCPU 간의 대응 관계를 나타낸다(여기서 본 16ACU 32GB 4vCPU는db.r5.xlarge이다): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html#aurora-db-instance-classes
    내부 작업 원리에 대한 정보가 거의 공개되지 않기 때문에 이 모든 것은 추측이라는 것을 명심하세요.이것은 미리 보기 테스트 버전으로 GA가 발표될 때 많은 것들이 달라질 수 있다. 본 블로그의 목적은 서버가 설정될지 없는지를 결정하고 부작용을 고려하며 클라우드 워치 지표를 해석할 때 그 작업 원리에 대한 이해가 매우 유용하다는 것을 보여주기 위한 것이다.우리는 이 조사를 위해 커다란 업무량을 부담할 필요가 없다. 그것은 소형 실험실에서 공부하고, 진실한 것을 검증하는 것이다.

    좋은 웹페이지 즐겨찾기