안녕 고 면접관 : GMP 모델, 왜 P가 있나요?

오늘의 주인공은 바둑 인터뷰에서 나온 만능 GMP 모델 질문의 확장 질문(질문)입니다. 바로 "GMP 모델, 왜 P이 필요한가요?"

더 자세히 알아보겠습니다. 사실 이 인터뷰에서 질문의 본질은 "GMP 모델에서는 왜 G와 M을 직접 묶을 수 없는 걸까요? 너무 번거롭습니다. 왜 그렇게 번거롭습니까? 무슨 문제입니까?"라고 묻는 것입니다. 문제를 해결하려고 하시나요?"

GM 모델

Go1.0 소스 코드 복호화

static void
schedule(G *gp)
{
 ...
 schedlock();
 if(gp != nil) {
  ...
  switch(gp->status){
  case Grunnable:
  case Gdead:
   // Shouldn't have been running!
   runtime·throw("bad gp->status in sched");
  case Grunning:
   gp->status = Grunnable;
   gput(gp);
   break;
  }

 gp = nextgandunlock();
 gp->readyonstop = 0;
 gp->status = Grunning;
 m->curg = gp;
 gp->m = m;
 ...
 runtime·gogo(&gp->sched, 0);
}

• Callschedlock 가져오기 방법 글로벌 잠금. schedlock 方法来获取全局锁。
• 获取全局锁成功后，将当前 Goroutine 状态从 Running（正在被调度） 状态修改为 Runnable（可以被调度）状态。
• 调用 gput 方法来保存当前 Goroutine 的运行状态等信息，以便于后续的使用。
• 调用 nextgandunlock 方法来寻找下一个可运行 Goroutine，并且释放全局锁给其他调度使用。
• 获取到下一个待运行的 Goroutine 后，将其运行状态修改为 Running。
• 调用 runtime·gogo

전화 gput 저장 방법 현재 고루틴 실행 상태 및 후속 사용을 위한 기타 정보입니다.

실행할 다음 고루틴을 얻은 후 실행 상태를 Running으로 변경하세요.

전화 런타임·gogo 메소드 , 방금 얻은 다음 실행할 고루틴을 실행하고 다음 스케줄링 라운드에 들어갑니다.

GM 모델에 대한 생각

Go1.0.1의 스케줄러 소스코드를 분석해보면 흥미로운 점을 발견할 수 있습니다. 이는 스케줄러 자체(스케줄 방식)입니다. 일반 프로세스에서는 반환되지 않습니다. 즉, 기본 프로세스가 종료되지 않습니다.

현재 Goroutine 스케줄러(Go 1.0의 GM 모델 참조)는 Go로 작성된 동시 프로그램, 특히 처리량이 높은 서버 및 병렬 컴퓨팅 프로그램의 확장성을 제한합니다.

구현에는 다음과 같은 문제가 있습니다.

• 단일 전역 뮤텍스(Sched.Lock)와 중앙 집중식 상태 관리가 있습니다.
• 뮤텍스는 모든 고루틴 관련 작업(생성, 완료, 재정렬, 등), 심각한 잠금 경쟁으로 이어집니다.
• 고루틴 전달 문제:
• 고루틴(G) 핸드오버(G.nextg): 실행 가능한 고루틴은 종종 작업자 스레드(M's) 간에 전달됩니다.
• 위로 인해 지연 시간이 늘어나고 추가 오버헤드가 발생할 수 있습니다. 모든 M은 실행 가능한 G, 특히 방금 G를 생성한 M을 실행할 수 있어야 합니다.
• 각 M은 메모리(M.mcache)에 캐시되어야 합니다.
• 과도한 리소스 소비(각 mcache는 2M의 메모리 캐시 및 기타 캐시를 흡수할 수 있음)와 열악한 데이터 지역성을 초래합니다.
• 잦은 스레드 차단/차단 해제:
• 스레드는 syscall이 있는 경우 자주 차단되고 차단 해제됩니다. 이는 추가 성능 오버헤드를 많이 추가합니다.

GMP 모델

위의 GM 모델의 많은 문제를 해결하기 위해 Go1.1에서 Dmitry Vyukov는 GM 모델을 기반으로 하는 새로운 P(Processor) 구성 요소를 추가했습니다. 그리고 새롭게 발생한 일부 문제를 해결하기 위해 Work Stealing 알고리즘을 구현했습니다.

GMP 모델은 이전 기사 "Go 그룹 친구들이 물었습니다: 제어할 적절한 고루틴 수는 얼마입니까? 이것이 GC와 스케줄링에 영향을 미칠까요?" "에 설명되어 있습니다.

좋다고 생각하는 친구들은 주목해도 좋고 여기서는 반복하지 않겠습니다.

어떤 변화를 가져올까요

P를 추가하면 어떤 변화가 생길까요? 좀 더 명확하게 얘기해보자.

• 각 P에는 자체 로컬 큐가 있어 글로벌 큐에 대한 직접적인 의존도가 크게 줄어듭니다. 결과적으로 잠금 경쟁이 줄어듭니다. GM 모델의 성능 오버헤드의 대부분은 잠금 경쟁입니다.

• 각 P의 상대적 균형에 따라 GMP 모델에도 작업 스틸링 알고리즘이 구현되어 있습니다. P의 로컬 큐가 비어 있으면 실행 가능한 G가 글로벌 큐 또는 로컬 큐에서 도난당합니다. 다른 P를 실행하여 유휴 상태를 줄이고 리소스 활용도를 향상시킵니다.

왜 P

이때 헷갈려하는 친구들도 있을텐데, 로컬 큐와 Work Stealing 알고리즘을 구현하고 싶다면 직접 M에 추가하면 되지 않을까요? M의 경우 유사한 기능을 얻을 수 있습니다 .

다른 P 구성 요소를 추가하는 이유는 무엇입니까?

M(시스템 스레드)의 위치 지정과 결합하여 이렇게 하면 다음과 같은 문제가 발생합니다.

• 일반적으로 M의 수가 P보다 많을 것입니다. Go와 마찬가지로 M 개수의 최대 제한은 10000이고, P의 기본 개수는 CPU 코어 개수입니다. 또한 M의 속성으로 인해, 즉 M을 차단하는 시스템 차단 호출이 있어 충분하지 않은 경우에도 M은 계속 증가하게 됩니다.

• M이 계속 증가하면 로컬 큐가 M에 마운트되면 로컬 큐도 증가한다는 의미입니다. 로컬 큐 관리가 복잡해지고 Work Stealing 성능이 크게 저하되므로 이는 명백히 불합리합니다.

• M 시스템 호출에 의해 차단된 후, 차단되자마자 모든 것을 중지시키는 것이 아니라 실행되지 않은 작업을 다른 사람에게 할당하여 계속 실행되기를 바랍니다.

그러므로 M을 사용하는 것은 무리입니다. 그러면 새로운 컴포넌트 P를 도입하고 로컬 큐를 P에 연결하면 이 문제를 아주 잘 해결할 수 있습니다.

요약

오늘의 글은 Go 언어 스케줄러 전체에 대한 몇 가지 역사적 상황, 원인 분석 및 해결 방법 설명을 결합한 것입니다.

"GMP 모델, 왜 P가 있지?" 이 질문은 시스템 설계 이해와도 같습니다. 이제 많은 사람들이 인터뷰에 응하기 위해 GMP 모델을 외우거나 즉석에서 통과하게 될 것이기 때문입니다. 그리고 그 이면의 실제 이유를 이해하는 것이 우리가 배우고 이해해야 할 것입니다.

무슨 일이 일어나고 있고 왜 일어나는지 알아야만 상황을 깨뜨릴 수 있습니다.