저는 R을 사용하여 많은 통계 분석을 수행하고 AWS에서 대규모 멀티코어 인스턴스를 많이 활용합니다. 주로 하이퍼파라미터 검색, 교차 검증, 부트스트래핑에 사용됩니다.
코어 가 있는 인스턴스 c와 한 번에 코어 r >= c로 파밍되는 복제 작업이 있다고 가정해 보겠습니다. c이제 시스템 프로세스(예: 내 ssh 클라이언트 실행)로 인해 실행 중인 복제 htop외에 작업이 있습니다 .c
이는 내가 운영 체제의 작동을 이해하는 한 htop프로세서에 액세스할 수 있도록 내 작업을 종료하는 일부 프로세스가 있음을 의미합니다. 이러한 다양한 프로세스를 햇볕 아래서 어느 정도 시간을 보낸 후 작업이 재개됩니다.
를 보면 htop녹색에 빨간색이 많이 섞여 있는 것을 볼 수 있습니다. 녹색은 내 작업이고 빨간색은 내 작업을 가능하게 하기 위해 수행된 배경 작업이라고 말하는 것이 정확합니까?
직관적으로 이러한 종류의 셔플링은 차선책인 것 같습니다. 그래서 제가 직접적으로 묻는 질문은 다음과 같습니다. 코어에 액세스할 수 있는 경우 c복제 작업을 모든 c코어 에 할당해야 합니까 c-1?
또한 내가 이해하지 못하고 얼버무리는 작업에 컴퓨팅 리소스를 할당하는 방법에 대한 세부 정보가 많이 있다고 생각합니다. 모든 작업이 c-1코어로 이동하고 모든 시스템 프로세스가 코어로 이동 하려면 어떻게 해야 합니까 cth? 하나의 막대를 제외하고 내 htop이 모두 녹색으로 변합니까? 그리고 이것이 어떤 의미가 있을까요?
벤치마킹 실험을 할 수 있을 것 같지만 거대한 인스턴스와 데이터 세트에는 어려울 것이며 응용 프로그램에 따라 달라지는 것들이 얼마나 많은지 잘 모르겠습니다. 그래서 저는 일이 어떻게 진행되는지 더 잘 이해하고 싶습니다.
답변1
실험 없이는 특정 애플리케이션에 대한 정확한 효과를 알기가 어렵지만, 일반적인 경험 법칙은 코어 수를 약간 초과하는 것이 유익하다는 것입니다(예를 들어 대부분의 컴파일 가이드에서는 코어/스레드 수 + 1) 그러나 이를 너무 많이 초과하면 추가 오버헤드로 인해 역효과를 낳을 가능성이 높습니다. 그 이유는 작업 중 하나(또는 두 개)가 I/O나 타이머 등을 기다리며 잠자고 있는 경우 다른 스레드가 계속 진행될 수 있기 때문입니다.
작업 셔플링(OS 스케줄링)은 모든 최신 운영 체제에서 발생하며 이에 맞서기보다는 함께 협력해야 합니다. 관련되지 않은 경쟁이 있는 것 같으면 프로세스의 좋은 수준을 낮출 수 있지만 전용 AWS 인스턴스에서는... 그것이 필요하다고 상상하기 어렵습니다.