평균 실행 큐 길이는 1인데 로드 평균은 거의 0인 이유는 무엇입니까?

평균 실행 큐 길이는 1인데 로드 평균은 거의 0인 이유는 무엇입니까?

(원래 Stack Overflow에 이 글을 게시했습니다. 여기로 옮기자고 제안했습니다.)

Fedora 17에서 로드 평균 활동을 확인하기 위해 sar 명령을 실행하면 시스템이 유휴 상태이고 로드 평균이 거의 0임에도 불구하고 거의 항상 실행 대기열 길이가 1로 표시됩니다. 실행 대기열 길이와 Linux 로드 평균과의 관계에 대해 제가 이해한 바에 따르면 시간이 지남에 따라 실행 대기열 길이가 평균 1이라면 쿼드 코어 시스템의 로드 평균은 로드 평균의 ~25%여야 합니다. 제 경우에는 다음과 같습니다. 약 1.00입니다:

$ sar -q 30 60
Linux 3.9.10-100.fc17.i686 (blah)   22/05/14    _i686_  (4 CPU)

16:29:10      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
16:29:40            1       547      0.02      0.07      0.57         0
16:30:10            1       548      0.09      0.08      0.56         0
16:30:40            1       547      0.05      0.07      0.54         0
16:31:10            1       547      0.03      0.06      0.52         0
16:31:40            0       547      0.02      0.06      0.51         0
16:32:10            1       547      0.01      0.05      0.49         0
16:32:40            1       547      0.13      0.08      0.49         0
16:33:10            1       547      0.08      0.07      0.47         0
16:33:40            1       547      0.05      0.07      0.46         0

실행 가능한 작업을 자주 폴링하면 가끔 이상한 프로세스가 나타나는 것을 볼 수 있습니다(이 작업을 수행하려면 ps r -A | grep -v 'ps r -A'를 사용합니다). 나는 sar 출력과 일관성을 유지하기 위해 주기적으로 프로세스 팝업이 나타나는 것을 보고 싶었습니다.

그런 다음 가능한 한 많은 CPU를 소비하는 단일 스레드 프로세스를 시작하면 실행 큐 크기가 즉시 2로 점프하지만(이 경우 예상됨) 이상하게도 잠시 후 실행 큐가 다시 1로 떨어집니다.

Linux 3.9.10-100.fc17.i686 (blah)   22/05/14    _i686_  (4 CPU)

16:32:40      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
16:33:10            1       547      0.08      0.07      0.47         0
16:33:40            1       547      0.05      0.07      0.46         0

START SCRIPT

16:34:10            2       548      0.11      0.08      0.45         0
16:34:40            2       548      0.51      0.18      0.47         0
16:35:10            2       548      0.70      0.26      0.49         0
16:35:40            2       548      0.82      0.33      0.50         0
16:36:10            2       548      0.89      0.39      0.52         0
16:36:40            2       548      0.93      0.45      0.53         0
16:37:10            2       548      0.96      0.50      0.55         0
16:37:40            2       548      1.04      0.57      0.57         0
16:38:10            2       548      1.02      0.61      0.58         0
16:38:40            2       548      1.01      0.64      0.60         0
16:39:10            2       548      1.09      0.70      0.61         0
16:39:40            2       548      1.05      0.72      0.63         0
16:40:10            3       550      1.11      0.77      0.64         0
16:40:40            3       549      1.06      0.79      0.65         0
16:41:10            3       549      1.04      0.81      0.67         0
16:41:40            3       549      1.02      0.83      0.68         0
16:42:10            2       549      1.01      0.84      0.69         0
16:42:40            2       549      1.01      0.86      0.70         0
16:43:10            1       549      1.07      0.89      0.71         0
16:43:40            1       549      1.04      0.90      0.72         0
16:44:10            1       549      1.03      0.91      0.73         0
16:44:40            1       549      1.02      0.92      0.74         0
16:45:10            1       548      1.01      0.93      0.75         0
16:45:40            1       548      1.01      0.93      0.75         0
16:46:10            1       548      1.00      0.94      0.76         0
16:46:40            1       548      1.00      0.94      0.77         0
16:47:10            1       548      1.00      0.95      0.78         0
16:47:40            1       548      1.00      0.96      0.78         0
16:48:10            1       548      1.00      0.96      0.79         0

무슨 일인지 설명해 줄 수 있는 사람 있나요? 내가 생각할 수 있는 유일한 설명은 다른 이유가 없다면 CPU를 활용하는 몇 가지 특별한 시스템 작업이 있다는 것입니다.

  1. 부하 평균 계산에는 포함되지 않으며
  2. 이를 필요로 하는 프로세스가 발생하면 CPU 시간이 포기됩니다.

또는

sar 명령이 실행 큐를 샘플링할 때 자체적으로 볼 수 있지만, CPU 로드 스크립트가 실행되는 동안 실행 큐가 1로 유지되는 이유는 설명되지 않습니다.

또는

로드 평균화/실행 대기열의 개념을 오해했습니다.

어떤 제안이라도 대단히 감사하겠습니다!

업데이트: 그래서 동일한 버전의 fedora 및 sar 등을 사용하는 다른 컴퓨터에서 다시 시도했습니다. 이번에는 시스템이 유휴 상태일 때 일관된 실행 대기열 길이가 0인 것을 볼 수 있습니다. 또한 centos 5.7 시스템에서도 시도했지만 유휴 상태에서는 실행 대기열 길이가 항상 0입니다.

따라서 아마도 sar는 실행 대기열에서 즉시 자신을 볼 수 없을 것입니다. 이 시스템이 약 0의 로드 평균을 보고하지만 실행 큐 길이는 항상 1로 측정되는 이유를 여전히 설명할 수 없습니다.

답변1

이것은 단지 추측일 뿐이지만, 실행 큐 길이가 평균이 아닌(이미 3개의 평균이 있는데 왜 평균이어야 합니까?) 특정 시점이라면 그 효과는 쉽게 설명됩니다. sar실행 대기열에 표시되는 항목은 항상 sar그 자체입니다. 프로세스를 추가하지 않으면 프로세스가 두 개가 됩니다.

답변2

저는 SAR runq_sz가 평균이 아니라 순간적인 스냅샷이라는 결론에 도달했습니다.

a) 저부하 서버에서 로드 평균이 가장 높은 초당 sar와 top을 비교했는데, 1분 동안 초당 평균 60 sar 값을 얻었을 때 top의 로드 평균보다 훨씬 높지만 더 간단했습니다. .

b) 항상 정수입니다. 평균(또는 초당)인 경우 로드 평균이나 CPU와 같은 소수점이 됩니다.

관련 정보