4 코어 8 스레드 프로세서에서 시스템로드를 해석하는 올바른 방법

우리 모두 알다시피, 단일 프로세서 에서 1.00의로드는 100 % 의로드가 있음을 의미합니다 . 쿼드 코어의 유사하게 4.00 부하는 100 % 입니다.

4 코어 8 스레드 프로세서의로드를 어떻게 해석해야합니까? CPU의 최대 용량에 언제 도달합니까? 에서 4.00 또는 8.00 ?

확실하지 않지만 대부분에 1.00*n_cpu있습니다.

로드는 다음을 의미합니다. 단일 CPU 시스템에 여러 프로세스가있는 경우 프로세스가 병렬로 실행됩니다. 그러나 사실이 아닙니다. 실제로 발생하는 일 : 커널은 프로세스에 1/100 초를주고 인터럽트로 실행을 중단합니다. 그리고 다른 프로세스에 다음 1/100 초를 제공합니다.

실제로 "어떤 프로세스가 다음 1/100 초 간격을 가져야합니까?"라는 질문은 복잡한 휴리스틱에 의해 결정됩니다. 그것은으로 명명 작업 스케줄링 .

물론 차단 된 프로세스 (예 : 디스크에서 읽고있는 데이터를 기다리는 중)는이 작업 예약에서 제외됩니다.

로드 내용 : 현재 1/100 번째 두 번째 시간 프레임을 기다리는 프로세스 수 물론 평균값입니다. 에서 여러 개의 숫자를 볼 수 있기 때문 cat /proc/loadavg입니다.

멀티 CPU 시스템의 상황은 조금 더 복잡합니다. 여러 프로세스에 시간 프레임을 제공 할 수있는 여러 CPU가 있습니다. 따라서 작업 예약이 약간 복잡해 지지만 너무 복잡하지는 않습니다. 그러나 상황은 동일합니다.

커널은 지능적이며 최적의 효율성을 위해 시스템 리소스를 공유하려고 시도하며 그 근처에 있습니다 (예를 들어 작은 최적화 작업이 있습니다. 캐싱 고려 사항으로 인해 CPU가 있지만 문제가되지는 않습니다). 로드가 8 인 경우 다음 시간 슬라이스를 기다리는 프로세스가 실제로 8 개 있기 때문입니다. CPU가 8 개인 경우 이러한 시간 조각을 CPU에 일대일로 제공 할 수 있으므로 시스템이 최적으로 사용됩니다.

이 표시 top되면 실제 실행중인 프로세스 수가 놀랍게도 낮다는 것을 알 수 있습니다. 프로세스가 표시된 프로세스 R입니다. 하드 코어가 아닌 시스템에서도 종종 5 미만입니다. 디스크 나 네트워크에서 데이터를 기다리는 프로세스도 일시 중단되기 때문 S입니다 (맨 위에 표시 ). 로드에는 CPU 사용량 만 표시됩니다.

디스크 부하를 측정하는 도구도 있지만 CPU 사용량 모니터링만큼 중요하지는 않지만 전문적인 sysadmin 세계에서는 잘 알려져 있지 않습니다.

Windows 도구는 종종 실제 CPU 수로 부하를 나눕니다. 이로 인해 일부 전문 Windows 시스템 관리자가 CPU별로 나누어 진 시스템로드를 사용하게됩니다. 당신이 그들에게 이것을 설명하고 나면 그들은 옳지 않으며 아마도 더 행복 할 것입니다.

멀티 코어 CPU는 실제로 동일한 실리콘 칩에있는 여러 개의 CPU입니다. 다른 점이 없다.

하이퍼 스레딩 CPU의 경우 흥미로운 부작용이 있습니다. CPU를로드하면 하이퍼 스레드 쌍이 느려집니다. 그러나 이것은 일반적인 작업 스케줄링이 처리하는 더 깊은 계층에서 발생하지만 스케줄러의 프로세스 이동 결정에 영향을 줄 수 있으며 영향을 미쳐야합니다.

그러나 현재의 관점에서-시스템 부하를 결정하는 것은 중요하지 않습니다.

하이퍼 스레딩은 실제로 두 번째 코어가 아니므로 200 %까지 코어를 사용하지 않지만 특정 워크로드에서는 100 %를 초과하게됩니다.

따라서 최대 하중은 약 4와 6 사이에서 알 수없는 곳입니다.

(물론 실제로 실행 가능한 프로세스, 특히 IO를 기다리는 경우를 계산하기 때문에 오버로드되면 더 높아질 수 있음)

로드 평균이 의미하는 바를 의미하지는 않습니다. 즉각적인 CPU 사용량이 아니라 실행 대기중인 프로세스 수에 관한 것입니다. 일반적으로 CPU를 원하는 것이 많지만 항상 그런 것은 아닙니다. 일반적인 원인은 IO 디스크 또는 네트워크를 기다리는 프로세스입니다.

ps -e v프로세스 상태 플래그를 실행 하고 찾아 보십시오 .

state    The state is given by a sequence of characters, for example, "RWNA". The      first character indicates the run state of the process:
D    Marks a process in disk (or other short term, uninterruptible) wait.
I    Marks a process that is idle (sleeping for longer than about 20 seconds).  
L    Marks a process that is waiting to acquire a lock.
R    Marks a runnable process.
S    Marks a process that is sleeping for less than about 20 seconds.
T    Marks a stopped process.
W    Marks an idle interrupt thread.
Z    Marks a dead process (a "zombie").

이 내용은 ps맨 페이지에서 제공되므로 자세한 내용을 찾을 수 R있으며 D프로세스가 특히 중요합니다.

모든 종류의 이유로로드 평균 '스파이크'로 끝날 수 있으므로 실제로 '이 시스템이 바쁘다'는 것 외에는 다른 방법으로는 적합하지 않습니다. 로드 평균을 CPU 코어에 매핑하는 데 어려움을 겪는다고해서 아무런 효과가 없을 것입니다.

Linux 시스템에서는 실행 가능한 큐의 프로세스뿐만 아니라로드를 계산하기 위해 카운트되는 것이 아니라 무정전 절전 상태 인 wikipedia 의 프로세스도 계산되어 디스크를 기다리는 프로세스가 많을 때로드가 급증합니다.

24 코어 Xeon 시스템 (2 소켓 x 12 코어)에서 실험을했습니다. 이 경우 Linux가 하이퍼 스레딩을 설정하는 방식으로 인해 최대로드는 48.0입니다.

그러나 48 코어 처리량에 해당하는 것은 아닙니다. 내가 관찰 한 것은 처음 24 개의 논리 프로세서에서 처리량의 약 90 %를 얻는다는 것입니다. 즉,로드가 24.0으로 실행되는 경우입니다. 그런 다음 나머지 24 개의 논리 프로세서에 대한 추가 처리량은 약 10 %입니다 (로드는 48.0으로 실행). 그것에 대해 생각하는 또 다른 방법은 24 코어에서 48 스레드를 실행하면 하이퍼 스레딩을 활성화하지 않고 활성화하면 약 10-20 % 증가한다는 것입니다. 마케팅 담당자가 암시하는 것처럼 100 % 향상되지는 않습니다.

예를 들어,이 관찰을 테스트하는 한 가지 방법은 48 개의 스레드를 실행하는 프로세스 (예 : TBB 또는 수동 롤링 스레딩 모델 사용)를 실행 한 다음 실행하는 것입니다.

time numactl --physcpubind=0-23  ./myprocess

그런 다음 실행

time numactl --physcpubind=0-47  ./myprocess

후자는 약 10-20 % 더 짧은 시간 내에 실행되어야합니다. 프로세스가 높은 I / O 차단 된 경우 결과가 다를 수 있습니다.

전자는 스레드가 각 코어의 단일 논리 프로세서에서만 실행되도록 허용하여 하이퍼 스레딩을 비활성화하고, 후자는 스레드가 각 코어의 2 개의 논리 프로세서에서 실행되도록 허용함으로써 하이퍼 스레딩을 활성화합니다.

두 경우 모두 부하는 48.0으로보고되어야합니다.