Linux CPU Load Averages 이해하기
linux 운영체제를 운영 해보신 경험이 있으신 분들은 Load Averages 라는 것이 중요하다는 것은 알고 있지만,
이 수치가 정확하게 뭘 의미하는지.. 얼마까지 괜찮은건지 모르는 경우들이 있었습니다.
이 수치에 대한 설명을 쉽게 해놓은 블로그가 있어 공유하고자 합니다.
결론만 말씀 드리자면, CPU의 Core당 처리 할 수 있는 양은 1로 표현 한 것이고, 이를 넘어서기 시작하면 대기열이 발생하는 것입니다.
대기열이 발생한다는 것은 현재 가지고 있는 처리량을 넘어섰기 때문에 지연이 발생하는 것이죠.
2 Core 기준 = Load Averages 2가 넘게 되면 지연 발생
16 Core 기준 = Load Averages 16이 넘으면 지연 발생
코어 기준으로 수치를 다르게 보고 판단을 해야 한다는 것입니다.
=========================================================================================
Linux로드 평균에 이미 익숙 할 것입니다. 부하 평균은 uptime및 top명령으로 표시되는 세 숫자입니다. 다음과 같습니다.
Load averages : 0.09, 0.05, 0.01
대부분의 사람들은 부하 평균이 무엇을 의미하는지 알 수 있습니다. 세 숫자는 점진적으로 더 긴 기간 (1, 5, 15 분 평균)에 대한 평균을 나타내며 숫자가 낮을수록 좋습니다. 숫자가 클수록 문제 또는 과부하 된 기계를 나타냅니다. 그러나 임계 값은 무엇입니까? "양호"및 "불량"부하 평균 값은 무엇입니까? 부하 평균 값에 대해 언제 염려해야하며 최대한 빨리 수정해야합니까?
첫째, 부하 평균 값이 의미하는 바에 대한 약간의 배경 지식입니다. 가장 간단한 경우로 시작하겠습니다. 하나의 단일 코어 프로세서가있는 머신입니다.
교통 비유
단일 코어 CPU는 단일 트래픽 레인과 같습니다. 당신이 다리 운영자라고 상상 해보세요 ... 때로는 다리가 너무 바빠서 차가 줄을 섭니다. 다리에서 교통이 어떻게 움직이는 지 사람들에게 알리고 싶습니다. 적절한 메트릭은 특정 시간에 얼마나 많은 자동차가 기다리고 있는지 입니다. 대기중인 차가 없으면 들어오는 운전자는 즉시 운전할 수 있다는 것을 알고 있습니다. 차량이 백업되면 운전자는 지연이 있다는 것을 알게됩니다.
그럼, Bridge Operator, 어떤 번호 체계를 사용할 건가요? 어때 :
- 0.00은 다리에 교통량이 전혀 없음을 의미합니다 . 실제로 0.00에서 1.00 사이는 백업이 없음을 의미하며 도착하는 차는 바로 계속됩니다.
- 1.00은 브리지가 정확히 용량에 있음을 의미합니다 . 모든 것이 여전히 양호하지만 교통 체증이 조금 더 심해지면 상황이 느려질 것입니다.
- 1.00 이상은 백업이 있음을 의미합니다. 얼마예요? 음, 2.00은 총 두 차선에 해당하는 차가 있음을 의미합니다. 한 차선은 다리에, 한 차선은 기다릴 가치가 있습니다. 3.00은 총 가치가있는 3 개의 차선이 있음을 의미합니다. 다리에 1 개 차선이 있고 대기 할 가치가있는 2 개 차선이 있습니다. 기타.
이것이 기본적으로 CPU 부하입니다. "자동차"는 CPU 시간 ( "브리지 교차")을 사용하거나 CPU를 사용하기 위해 대기하는 프로세스입니다. Unix는이를 실행 대기열 길이라고합니다 . 현재 실행중인 프로세스 수와 실행 대기중인 (대기중인) 수의 합계입니다.
다리 운영자와 마찬가지로 자동차 / 프로세스가 기다리지 않기를 바랍니다. 따라서 CPU로드는 이상적으로 1.00 미만으로 유지되어야합니다. 또한 브리지 운영자와 마찬가지로 1.00 이상의 일시적인 스파이크가 발생해도 괜찮습니다.하지만 지속적으로 1.00을 초과하면 걱정할 필요가 있습니다.
그래서 이상적인 부하는 1.00이라고 말하는 건가요?
음, 정확히는 아닙니다. 부하가 1.00 인 문제는 헤드 룸이 없다는 것입니다. 실제로 많은 시스템 관리자는 0.70에 선을 그립니다.
-
"필요는 그것으로 찾을 것이다" 엄지 손가락의 규칙 : 0.70 당신의 평균 부하는 상황이 더 악화되기 전에 조사> 위의 0.70, 그것의 시간을 머물 경우.
-
"지금 수정" 엄지 손가락의 규칙 : 1.00 . 부하 평균이 1.00 이상이면 문제를 찾아 지금 수정하세요. 그렇지 않으면 한밤중에 깨어나 재미 있지 않을 것입니다.
-
"Arrgh, 그것은 오전 3 WTF입니까?" 경험 법칙 : 5.0 . 부하 평균이 5.00 이상이면 심각한 문제에 처할 수 있고, 상자가 걸려 있거나 느려지고 있으며, 이는 한밤중이나 발표 할 때와 같이 가능한 최악의 시간에 (설명 할 수 없을 정도로) 발생합니다. 회의에서. 거기에 가지 마십시오.
다중 프로세서는 어떻습니까? 내 부하에 3.00이 표시되지만 문제가 없습니다.
쿼드 프로세서 시스템이 있습니까? 3.00의 부하로 여전히 건강합니다.
다중 프로세서 시스템에서로드는 사용 가능한 프로세서 코어 수에 상대적입니다. "100 % 사용률"표시는 단일 코어 시스템에서 1.00, 듀얼 코어에서 2.00, 쿼드 코어에서 4.00 등입니다.
다리 비유로 돌아 가면 "1.00"은 실제로 "1 차선의 교통량"을 의미합니다. 1 차선 다리에서는 채워 졌다는 의미입니다. 2 차선 교량에서 부하가 1.00이면 용량이 50 %라는 것을 의미합니다. 차선 하나만 가득 차서 채울 수있는 또 다른 전체 차선이 있습니다.
CPU와 동일 : 1.00의로드는 단일 코어 박스에서 100 % CPU 사용률입니다. 듀얼 코어 박스에서 2.00의로드는 100 % CPU 사용률입니다.
멀티 코어 대 멀티 프로세서
주제를 다루는 동안 멀티 코어 대 멀티 프로세서에 대해 이야기 해 보겠습니다. 성능상의 이유로 단일 듀얼 코어 프로세서가있는 시스템은 기본적으로 각각 하나의 코어가있는 두 개의 프로세서가있는 시스템과 동일합니까? 예. 대충. 여기에는 캐시 양, 프로세서 간 프로세스 핸드 오프 빈도 등과 관련하여 많은 미묘한 점이 있습니다. 이러한 세부 사항에도 불구하고 CPU로드 값 크기를 조정하기 위해서는 총 코어 수가 중요합니다. 이러한 코어가 분산되어있는 많은 물리적 프로세서.
이는 두 가지 새로운 경험 규칙으로 이어집니다.
-
"코어 수 = 최대로드"경험 규칙 : 멀티 코어 시스템에서로드는 사용 가능한 코어 수를 초과하지 않아야합니다.
-
"코어는 코어가" 코어가 CPU에 걸쳐 분산되어 얼마나 중요하지 않습니다 : 엄지 손가락의 규칙. 2 개의 쿼드 코어 == 4 개의 듀얼 코어 == 8 개의 단일 코어. 이러한 목적을 위해 모두 8 개의 코어입니다.
집으로 가져 오기
다음의 부하 평균 출력을 살펴 보겠습니다 uptime.
~ $ 가동 시간
23:05 14 일, 6:08, 사용자 7 명, 부하 평균 : 0.65 0.42 0.36
이것은 듀얼 코어 CPU에 있으므로 많은 헤드 룸이 있습니다. 로드가 1.7 정도 이상으로 유지 될 때까지 생각조차하지 않을 것입니다.
자,이 세 숫자는 어떻습니까? 0.65는 지난 1 분 동안의 평균, 0.42는 지난 5 분 동안의 평균, 0.36은 지난 15 분 동안의 평균입니다. 이것은 우리에게 질문을 던집니다.
어느 평균을 관찰해야합니까? 1 분, 5 분, 15 분?
우리가 이야기 한 수치 (1.00 = 지금 수정 등)의 경우 5 분 또는 15 분 평균을보고 있어야합니다. 솔직히, 박스가 1 분 평균 1.0 이상으로 급증해도 괜찮습니다. 15 분 평균이 1.0에서 북쪽으로 이동하여 스냅해야하는 지점에 머무르는 경우입니다. (분명히 우리가 배운 것처럼이 숫자를 시스템의 프로세서 코어 수로 조정하십시오).
따라서로드 평균을 해석하려면 코어 수가 중요합니다. 시스템에있는 코어 수를 어떻게 알 수 있습니까?
cat /proc/cpuinfo시스템의 각 프로세서에 대한 정보를 얻으려면 참고 : OSX에서는 사용할 수 없으며 Google에서 대체 할 수 있습니다. 카운트를 얻으려면 다음을 실행 grep하고 단어 수를 계산합니다.grep 'model name' /proc/cpuinfo | wc -l
더 많은 서버? 아니면 더 빠른 코드?
서버 추가는 느린 코드에 대한 반창고가 될 수 있습니다. Scout APM 은 비효율적이고 비용이 많이 드는 코드를 찾아 수정하는 데 도움이됩니다. N + 1 SQL 호출, 메모리 팽창 및 기타 코드 관련 문제를 자동으로 식별하므로 디버깅 시간을 줄이고 프로그래밍에 더 많은 시간을 할애 할 수 있습니다.