Kubernetes: CFS 할당량으로 인해 불필요한 제한이 발생할 수 있습니다.

/ sig 노드
/ 종류의 버그

# 51135의 중복인가요?

정신적으로는 비슷하지만 CFS 쿼터 기간의 일부 구성 절충보다는 커널에 실제 버그가 있다는 사실을 놓친 것 같습니다. 나는 사람들에게 더 많은 맥락을 제공하기 위해 여기 # 51135를 좋아했습니다.

내가 이해하는 한 이것이 CFS 할당량 ( --cpu-cfs-quota=false )을 비활성화하거나 구성 가능하게 만드는 또 다른 이유입니다 (# 63437).

또한이 요점 (커널 패치에서 링크 됨)이 매우 흥미 롭다는 것을 발견했습니다 (영향을 측정하기 위해) : https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1

cc @adityakali

할당량의 또 다른 문제는 kubelet이 하이퍼 스레드를 "cpus"로 계산한다는 것입니다. 클러스터가 너무로드되어 두 스레드가 동일한 코어에 예약되고 프로세스에 CPU 할당량 할당량이있는 경우 그중 하나는 사용 가능한 처리 능력의 작은 부분으로 만 수행됩니다 (다른 스레드에있는 작업이있을 때만 수행됩니다). 스톨) 그러나 자체적으로 물리적 코어가있는 것처럼 여전히 할당량을 소비합니다. 따라서 훨씬 더 많은 작업을 수행하지 않고도 할당량을 두 배로 소비합니다.
이는 하이퍼 스레딩이 활성화 된 완전히로드 된 노드 노드에서 성능이 하이퍼 스레딩 또는 할당량 비활성화 상태의 절반이되는 효과가 있습니다.

Imo the kubelet은 이러한 상황을 피하기 위해 하이퍼 스레드를 실제 CPU로 간주해서는 안됩니다.

@juliantaylor # 51135에서 언급했듯이 CPU 할당량을 끄는 것이 신뢰할 수있는 워크로드를 실행하는 대부분의 k8s 클러스터에 가장 좋은 방법 일 수 있습니다.

이것은 버그로 간주됩니까?

일부 포드가 CPU 제한을 실제로 소모하지 않는 동안 스로틀 링되면 버그처럼 들립니다.

내 클러스터에서 대부분의 할당량 초과 포드는 메트릭 (heapster, metrics-collector, node-exporter ...) 또는 연산자와 관련이 있습니다.이 연산자는 분명히 여기에서 문제가되는 종류의 워크로드를 갖고 있습니다. 매번 화해하기 위해 시간을 보내고 일어나십시오.

여기서 이상한 점은 40m 에서 100m 또는 200m 제한을 높이려고했지만 프로세스가 여전히 제한되었다는 것입니다.
이 제한을 트리거 할 수있는 워크로드를 가리키는 다른 메트릭을 볼 수 없습니다.

지금은이 포드에 대한 제한을 제거했습니다 ... 점점 좋아지고 있지만, 정말 버그처럼 들리며 Limits 비활성화하는 것보다 더 나은 솔루션을 제공해야합니다.

@ prune998 은 @vishh 의 코멘트 와이 요점을 참조하십시오 : 커널은 수학에서 그렇게해서는 안된다고하더라도 지나치게 공격적으로 제한합니다. 우리 (Zalando)는 클러스터에서 CFS 할당량 (CPU 조절)을 비활성화하기로 결정했습니다. https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload

감사합니다 @hjacobs.
Google GKE를 사용 중이며 사용 중지하는 쉬운 방법이 없지만 계속 검색합니다 ....

@ prune998 AFAIK, Google은 아직 필요한 손잡이를 노출하지 않았습니다. 우리는 업스트림에 착륙 한 CFS를 비활성화 할 가능성이있는 직후 기능 요청을 제출했으며 그 이후로 소식을 듣지 못했습니다.

Google GKE를 사용 중이며 사용 중지하는 쉬운 방법이 없지만 계속 검색합니다 ....

당분간 컨테이너에서 CPU 제한을 제거 할 수 있습니까?

CPU 관리자 문서에 따르면 CFS quota is not used to bound the CPU usage of these containers as their usage is bound by the scheduling domain itself. 하지만 CFS 스로틀 링이 발생하고 있습니다.

이는 보장 된 QoS 클래스를 달성하기 위해 CPU 제한을 설정하면 스로틀 링으로 인한 모든 이점을 무효화하므로 정적 CPU 관리자는 대부분 무의미합니다.

정적 CPU의 포드에 대해 CFS 할당량이 전혀 설정되지 않은 버그입니까?

추가 컨텍스트 (어제 배웠 음) : @hrzbrg (MyTaxi)가 Kops에 플래그를 제공하여 CPU 조절을 비활성화했습니다 : https://github.com/kubernetes/kops/issues/5826

여기에 문제 요약을 공유하십시오. 문제가 무엇인지, 어떤 시나리오에서 사용자가 영향을 받는지, 문제를 해결하기 위해 정확히 무엇이 필요한지 명확하지 않습니다.

현재 우리의 이해는 우리가 한계를 넘었을 때 우리는 패널티를 받고 제한을받습니다. 따라서 CPU 할당량이 3 코어이고 처음 5ms 동안 3 코어를 소비 한 다음 100ms 슬라이스에서 95ms 동안 제한을 받게되며이 95ms에서는 컨테이너가 아무것도 할 수 없습니다. 그리고 CPU 사용량 메트릭에 CPU 스파이크가 표시되지 않는 경우에도 스로틀 링되는 것을 보았습니다. CPU 사용량을 측정하는 시간이 초 단위이고 조절이 마이크로 초 수준에서 발생하기 때문에 평균값을 내고 보이지 않기 때문이라고 가정합니다. 그러나 여기에 언급 된 버그는 우리를 혼란스럽게했습니다.

몇 가지 질문 :

• 노드가 100 % CPU 일 때? 모든 컨테이너가 사용량에 관계없이 제한되는 특별한 경우입니까?

• 이런 일이 발생하면 모든 컨테이너가 100 % CPU 제한을 받습니까?

• 이 버그가 노드에서 트리거되는 원인은 무엇입니까?

• limits 사용하지 않는 것과 cpu.cfs_quota 사용하지 않는 것의 차이점은 무엇입니까?

• 버스트 가능한 포드가 많고 하나의 포드가 노드의 불안정성을 유발하고 요청을 통해 실행중인 다른 포드에 영향을 미칠 수있는 경우 limits 비활성화하면 위험한 솔루션이되지 않습니까?

• 별도로, 커널 문서 프로세스에 따라 부모 할당량이 완전히 소비되면 제한 될 수 있습니다. 컨테이너 컨텍스트에서 부모는 무엇입니까 (이 버그와 관련이 있습니까)? https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt
  There are two ways in which a group may become throttled: a. it fully consumes its own quota within a period b. a parent's quota is fully consumed within its period

• 문제를 해결하려면 무엇이 필요합니까? 커널 버전을 업그레이드 하시겠습니까?

우리는 상당히 큰 중단에 직면했으며 모든 포드가 스로틀 링 재시작 루프에 갇혀 확장 할 수없는 것과 밀접한 관련이있는 것으로 보입니다 (근본 원인은 아닐지라도). 실제 문제를 찾기 위해 세부 사항을 파헤 치고 있습니다. 중단에 대해 자세히 설명하는 별도의 문제를 시작하겠습니다.

여기에 도움을 주시면 대단히 감사하겠습니다.

cc @justinsb

사용자 중 한 명이 CPU 제한을 설정하고 활성 프로브 시간을 초과하여 서비스가 중단되었습니다.

컨테이너를 CPU에 고정 할 때도 스로틀 링이 발생합니다. 예를 들어 CPU 제한이 1이고 해당 컨테이너가 하나의 CPU에서만 실행되도록 고정합니다. 할당량이 정확히 보유한 CPU 수인 경우 주어진 기간 동안 할당량을 초과 할 수 없지만 모든 경우에 제한이 있습니다.

나는 커널 4.18이 문제를 해결한다는 것을 어딘가에 게시했다고 생각했습니다. 아직 테스트하지 않았으므로 누군가 확인할 수 있으면 좋을 것입니다.

4.18의 https://github.com/torvalds/linux/commit/512ac999d2755d2b7109e996a76b6fb8b888631d 가이 문제에 대한 관련 패치 인 것 같습니다.

@mariusgrigoriu https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -462534360에서 설명한 것과 동일한 수수께끼에 갇혀있는 것 같습니다.

CPUManager 정적 정책을 사용하는 Guaranteed QoS 클래스의 포드에서 CPU 스로틀 링을 관찰합니다 (말이 안되는 것 같음).

이러한 Pod에 대해 limits 를 제거하면 Burstable QoS 클래스에 배치되며, 이는 우리가 원하는 것이 아니므로 남은 유일한 옵션은 시스템 전체에서 CFS cpu 할당량을 비활성화하는 것입니다. 바인딩되지 않은 CPU 용량에 대한 모든 Pod 액세스를 허용하면 위험한 CPU 포화 문제가 발생할 수 있기 때문입니다.

위의 상황에서 @vishh , 최선의 조치는 무엇입니까? 커널> 4.18 (cfs cpu 계정 수정이 있음)로 업그레이드하고 (아마도) cfs 할당 기간을 줄이는 것 같습니다.

일반적으로 제한되는 컨테이너에서 limits 만 제거하면 명확한 경고가 표시됩니다.
1) 이것이 보장 된 QoS 클래스의 포드이고 정수 코어 수 및 CPUMnanager 정적 정책이 적용된 경우- 이러한 포드는 버스트 가능한 QoS 클래스에 배치
2) 이러한 포드는 소비 할 수있는 CPU의 양과 관련하여 제한이 없으며 잠재적으로 특정 상황에서 상당한 피해를 입힐 수 있습니다.

귀하의 의견 / 안내는 매우 감사하겠습니다.

커널을 업그레이드하면 확실히 도움이되지만 CFS 할당량을 적용하는 동작은 여전히 ​​문서에서 제안하는 것과 일치하지 않는 것 같습니다.

나는 지금이 문제의 다양한 측면을 조사 해왔다. 내 연구는 LKML에 대한 내 게시물에 요약되어 있습니다.
https://lkml.org/lkml/2019/3/18/706
즉, 여기서 512ac99 이전 커널에 설명 된 문제를 재현 할 수 없습니다. 그러나 512ac99 이후 커널에서 성능 회귀를 보았습니다. 그래서 그 수정은 만병 통치약이 아닙니다.

감사 @mariusgrigoriu, 우리가 업그레이드 다소 도움이 될 것입니다 희망 커널을 위해 가고있다, 또한 체크 아웃 https://github.com/kubernetes/kubernetes/issues/70585 - 할당량이 참의 cpuset와 보장 포드 (설정되는 것 같다 즉 고정 cpus), 그래서 이것은 나에게 버그처럼 보입니다.

@chiluk 좀 더 자세히

512ac99 커널 패치는 일부 사람들의 문제를 해결하지만 구성에 문제를 일으켰습니다. 패치는 시간 조각이 cfs_rq간에 분배되는 방식을 수정하여 이제 올바르게 만료됩니다. 이전에는 만료되지 않았습니다.

특히 코어 수가 많은 머신에서 Java 워크로드는 차단 작업자 스레드로 인해 CPU 사용량이 적은 많은 스로틀 링을 볼 수 있습니다. 이러한 스레드에는 나중에 만료되는 일부만 사용하는 시간 조각이 할당됩니다. 내가 작성한 합성 테스트에서 * (해당 스레드에 연결됨) 약 30 배의 성능 저하를 볼 수 있습니다. 실제 성능에서 우리는 증가 된 스로틀 링으로 인해 두 커널 간의 응답 시간이 수백 밀리 초 감소하는 것을 확인했습니다.

4.19.30 커널을 사용하면 스로틀 링을 줄 이길 바랬던 포드가 여전히 스로틀 링되고 이전에 스로틀 링되지 않았던 일부 포드가 이제 상당히 심각하게 스로틀 링되고 있음을 알 수 있습니다 (kube2iam은 인스턴스가 가동 된 것보다 더 많은 초가 스로틀 링되었다고보고합니다. , 어떻게 든)

CoreOS 4.19.25-coreos에서 Prometheus가 시스템의 거의 모든 단일 포드에서 CPUThrottlingHigh 경고를 트리거하는 것을 볼 수 있습니다.

@williamsandrew @teralype 이것은 @chiluk 의 결과를 반영하는 것 같습니다.

다양한 내부 논의를 거쳐 실제로 cfs 할당량을 완전히 비활성화하기로 결정했습니다 (kubelet의 플래그 --cpu-cfs-quota=false ). 이것은 Burstable 및 Guaranteed (cpu 고정 또는 표준) 포드 모두에 대해 겪었던 모든 문제를 해결하는 것 같습니다.

이에 대한 훌륭한 덱 (및 기타 몇 가지 주제)이 여기에 있습니다 : https://www.slideshare.net/try_except_/ensuring-kubernetes-cost-efficiency-across-many-clusters-devops-gathering-2019

적극 권장되는 읽기 : +1 :

장기 발행 (자신에게 메모)

완전성 을 위해 연결된 토크 는 녹화 된 비디오로도 제공됩니다 : https://www.youtube.com/watch?v=4QyecOoPsGU

@hjacobs , 이야기를 좋아했습니다! 감사합니다 ...
이 수정 사항을 AKS 또는 GKE에 적용하는 방법을 아십니까?
감사

@agolomoodysaada 우리는 얼마 전에 GKE에 기능 요청을 제출했습니다. 상태가 무엇인지 확실하지 않아 더 이상 GKE를 집중적으로 사용하지 않습니다.

Azure 지원에 연락했는데 2019 년 8 월경까지는 사용할 수 없다고 말했습니다.

평생 동안 일관되게 조절되는 응용 프로그램의 그래프를 공유 할 것이라고 생각했습니다.

어떤 커널에 있었습니까?

" chiluk "4.15.0-1037-azure "

그래서 그것은 커널 커밋 512ac99를 포함하지 않습니다. 여기에 상응하는
출처.
https://kernel.ubuntu.com/git/kernel-ppa/mirror/ubuntu-azure-xenial.git/tree/kernel/sched/fair.c?h=Ubuntu-azure-4.15.0-1037.39_16.04.1 & id = 19b0066cc4829f45321a52a802b640bab14d0f67

즉, 512ac99에 설명 된 문제가 발생할 수 있습니다. 타고있다
512ac99는 우리에게 다른 회귀를 가져 왔습니다.

2019 년 4 월 5 일 금요일 오후 12:08 Moody Saada [email protected]
썼다 :

@chiluk https://github.com/chiluk "4.15.0-1037-azure"

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/67577#issuecomment-480350946 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACDI05YeS6wfUE9XkiMbxrLvPllYQZ7Iks5vd4MOgaJpZM4WDUF3
.

나는 이제 이것에 대해 LKML에 패치를 게시했습니다.
https://lkml.org/lkml/2019/4/10/1068

추가 테스트를 주시면 감사하겠습니다.

문서 변경과 함께이 패치를 다시 제출했습니다.
https://lkml.org/lkml/2019/5/17/581

사람들이 이러한 패치를 테스트하고 LKML의 스레드에 대해 댓글을 달 수 있다면 정말 도움이 될 것입니다. 현재 저는 LKML에 대해 언급 한 유일한 사람이며 커뮤니티 나 유지 관리자로부터 어떤 의견도받지 못했습니다. 내 패치에서 LKML에 대한 커뮤니티 테스트와 논평을 얻을 수 있다면 정말 먼 길을 갈 것입니다.

가치가있는이 특정 프로젝트 https://github.com/tensorflow/serving 은이 문제로 인해 심각한 영향을받는 것 같습니다. 그리고 그것은 대부분 C ++ 애플리케이션입니다.

@chiluk , 패치가 출시되는 동안 적용 할 수있는 해결 방법이 있습니까?
감사합니다

@chiluk 가이 커널 버그가 Kubernetes 및 CFS 할당량을 사용하는 다른 모든 사람에 미치는 심각한 영향에 대한 인용문을 수집하도록

Zolando는 지난주 프레젠테이션에서 현재 커널에 대한 나쁜 경험은 CFS 할당량을 현재의 모범 사례로 비활성화하는 것을 의미한다고 말했습니다.
https://www.youtube.com/watch?v=6sDTB4eV4F8

점점 더 많은 회사가 mytaxi, Datadog, Zalando와 같은 CPU 스로틀 링을 비활성화하고 있습니다. ( Twitter 스레드 )

@derekwaynecarr @ dchen1107 @ kubernetes / sig-node-feature-requests Dawn, Derek, 기본값을 변경할 때입니까? 및 / 또는 문서?

예 @whereisaaron 은 응용 프로그램을 제한하는 보고서를 수집 및 공유하고, 나쁜 동작으로 인해 꺼지는 경우 적절한 경우 lkml 스레드에 참여하는 것을 환영합니다. 현재로서는 커널 커뮤니티에이 문제에 대해 불만을 제기하는 것이 대부분인 것 같습니다.

@agolomoodysaada 해결 방법은 일시적으로 cfs 할당량을 비활성화하거나 영향을받는 응용 프로그램에 cpu 할당량을 과도하게 할당하는 것입니다.

또한 도움이되는 애플리케이션 스레드 수를 줄이는 모범 사례도 있습니다.
golang의 경우 GOMAXPROCS ~ = ceil (quota)
Java의 경우 CPU 할당량 제한을 인식하고 준수하는 최신 JVM으로 이동하십시오. 이전 jvms는 애플리케이션에서 사용할 수있는 코어 수가 아니라 CPU 코어 수를 기반으로 스레드를 생성했습니다.
이 두 가지 모두 성능에 큰 도움이되었습니다.

개발자가 할당량을 조정할 수 있도록 제한에 도달하는 애플리케이션을 모니터링하고보고합니다.

참고로,이 스레드를 Azure AKS 지원에 지적한 후, 기껏해야 9 월 말에 커널 5.0으로 업그레이드 할 때 패치가 출시 될 것이라는 답변을 받았습니다.
그때까지는 제한 사용을 중지하십시오. :)

@ prune998 CPUmanager를 사용하는 경우 약간의주의 사항이 있습니다 (즉, 보장 된 QoS에서 포드에 전용 CPU 할당).

제한을 제거하면 CFS 조절 문제를 피할 수 있지만 보장 된 QoS에서 포드를 제거하여 CPUmanager가 더 이상 이러한 포드에 전용 코어를 할당하지 않습니다.

CPUmanager를 사용하지 않는 경우-아무런 해를 끼치 지 않지만이 방향을 선택하는 사람에게는 참고로하십시오.

전용 CPU가있는 포드에 대해 CFS 할당량을 완전히 비활성화하는 PR (https://github.com/kubernetes/kubernetes/issues/70585)이 있지만 아직 병합되지 않았습니다.

또한 위에서 제안한대로 CFS 할당량 시스템 전체를 비활성화하도록 선택했으며 지금까지는 문제가 없습니다.

@ dannyk81 https://github.com/kubernetes/kubernetes/issues/70585 는 병합 할 수있는 PR이 아닙니다 (코드 스 니펫 문제). 귀하 (또는 다른 사람)가 PR을 제출할 수 있습니까?

이미 하나 있습니다 : https://github.com/kubernetes/kubernetes/pull/75682

@dims 나는 문제가 아닌 PR을 연결 ...하지만 문제는 PR에 연결되어 :) 실제로 그것이 https://github.com/kubernetes/kubernetes/pull/75682 하고 잠시 동안 거기에 매달려되어있어, 그래서 이것이 정말로 성가신 문제이기 때문에 당신이 이것을 밀 수 있다면 이것은 좋을 것입니다.

감사합니다 : +1 :

웁스! 감사합니다 @ dannyk81 나는 사람들을 할당하고 이정표를 추가했습니다

FWIW에서도이 문제가 발생했으며 CFS 할당량 기간을 기본 100ms가 아닌 10ms로 줄이면 테일 엔드 대기 시간이 크게 향상된다는 사실을 발견했습니다. 커널 버그가 발생하더라도 사용하지 않으면 훨씬 적은 양의 할당량이 낭비되고 프로세스가 더 많은 할당량 (작은 할당량으로)을 더 빨리 얻을 수 있기 때문이라고 생각합니다. 이것은 해결 방법 일 뿐이지 만 CFS 할당량을 완전히 비활성화하지 않으려는 사람들에게는 수정 사항이 구현 될 때까지 반창고가 될 수 있습니다. k8s는 1.12에서 cpuCFSQuotaPeriod 기능 게이트 및 --cpu-cfs-quota-period kubelet 플래그를 사용하여이 작업을 지원합니다.

확인해야했지만 코드에 슬라이스 최소값과 할당량 최소값이 있기 때문에 기간을 그렇게 줄이면 효과적으로 비활성화 할 수 있다고 생각합니다. 할당량을 해제하고 소프트 할당량으로 이동하는 것이 좋습니다.

@chiluk 내 평신도의 이해는 기본 슬라이스가 5ms이므로 그 이하로 설정하면 사실상 비활성화되지만 기간이 5ms를 초과하는 한 여전히 할당량 적용이 있어야합니다. 정확하지 않은 경우 확실히 알려주세요.

--feature-gates=CustomCPUCFSQuotaPeriod=true --cpu-cfs-quota-period=10ms 으로 내 포드 중 하나가 시작하는 데 정말 어려움을 겪었습니다. 첨부 된 prometheus 그래프에서 컨테이너는 시작을 시도하고 죽을 때까지 활성 상태 확인을 거의 충족하지 못합니다 (일반적으로 컨테이너는 약 5 초 안에 시작됩니다. 심지어 활성 상태를 initialDelaySeconds를 60 초로 늘려도 도움이되지 않았습니다). 그런 다음 새 것으로 교체됩니다.

kubelet 인수에서 cpu-cfs-quota-period를 제거 할 때까지 컨테이너가 크게 제한되는 것을 볼 수 있습니다.이 시점에서 제한이 훨씬 더 평평 해지고 컨테이너가 약 5 초 후에 다시 시작됩니다.

참고 : CPU 스로틀 링 비활성화 주제에 대한 현재 트위터 스레드 : https://twitter.com/it_supertramp/status/1133648291332263936

다음은 지연 시간에 민감한 서비스 2 개에 대해 프로덕션에서 --cpu-cfs-quota-period=10ms 로 이전하기 전 / 후의 CPU 제한 그래프입니다.

이러한 서비스는 다양한 인스턴스 유형에서 실행됩니다 (타인 / 내성). 두 번째 서비스의 인스턴스는 먼저 낮은 CFS 할당량 기간으로 이동되었습니다.

결과는 부하에 따라 크게 달라져야합니다.

@ d-shi 그래프에 다른 것이 있습니다. 기간이 너무 짧기 때문에 지금 당신이 타격하고있는 최소 할당량이있을 수 있다고 생각합니다. 확인하려면 코드를 확인해야합니다. 기본적으로 응용 프로그램에 사용할 수있는 할당량을 실수로 늘 렸습니다. 실제로 할당량을 늘려서 동일한 작업을 수행 할 수 있습니다.

우리에게는 스로틀 링보다는 지연 시간을 측정하는 것이 훨씬 더 유용했습니다. cfs-quota 비활성화하면 대기 시간이 크게 향상되었습니다. cfs-quota-period 변경에 대한 유사한 결과를보고 싶습니다.

@chiluk 우리는 실제로 할당량을

@blakebarnett 우리는 지연 시간을 측정하는 벤치 마크 프로그램을 개발했으며, 10ms-100ms 범위에서 --cpu-cfs-quota-period 업데이트 전 평균 약 18ms에서 평균 10ms-20ms 범위로 변경되었습니다. 그 후 약 11ms. p99 지연 시간은 약 98ms에서 20ms로 증가했습니다.

편집자 : 다시 돌아가서 내 번호를 다시 확인해야했던 편집에 대해 죄송합니다.

@ d-shi, 당신은 아마도 512ac999로 해결 된 문제에 부딪혔을 것입니다.

@chiluk 여러분의 패치를 몇 번이고 읽은 후,이 코드의 영향을 이해하는 데 어려움을 겪고 있음을 인정합니다.

    if (cfs_rq->expires_seq == cfs_b->expires_seq) {
-       /* extend local deadline, drift is bounded above by 2 ticks */
-       cfs_rq->runtime_expires += TICK_NSEC;
-   } else {
-       /* global deadline is ahead, expiration has passed */
-       cfs_rq->runtime_remaining = 0;
-   }

runtime_remaining이 글로벌 풀에서 얼마 동안 빌려도 할당량이 만료되는 경우. 최악의 경우 sched_cfs_bandwidth_slice_us에 따라 5ms 동안 제한됩니다. 그렇지 않습니까?
내가 뭔가를 놓친 건가요?

@chiluk 그래 내가 옳다고 생각합니다. 우리의 프로덕션 서버는 여전히 커널 4.4에 있으므로 수정하지 마십시오. 아마도 새로운 커널로 업그레이드하면 CFS 할당량 기간을 기본값으로 되돌릴 수 있지만, 현재로서는 테일 엔드 지연 시간을 개선하기 위해 노력하고 있으며 아직 부작용을 발견하지 못했습니다. 단 몇 주 동안 만 라이브되었습니다.

@chiluk 커널에서이 문제의 상태를 요약하고 있습니까? 512ac999라는 패치가있는 것 같지만 문제가있었습니다. 되 돌린 곳을 읽었습니까? 아니면 전체 / 부분적으로 고정되어 있습니까? 그렇다면 어떤 버전입니까?

@mariusgrigoriu 는 수정되지 않았습니다. @chiluk 는 추가 테스트가 필요한 문제를 수정해야하는 패치를 만들었습니다.

최신 상태는 https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -482198124를 참조

@Mwea 전역 풀은 cfs_b-> runtime_remaining에 저장됩니다. CPU 당 실행 대기열 (cfs_rq)에 할당되면 글로벌 풀에 남아있는 양이 줄어 듭니다. cfs_bandwidth_slice_us는 전역 풀에서 CPU 별 실행 대기열로 전송되는 CPU 런타임의 양입니다. 스로틀이 발생하면 cfs_b-> runtime_remaining == 0을 실행해야 함을 의미합니다. 할당량이 cfs_b에 보충 된 다음 배포 되려면 현재 기간 (기본적으로 100ms)이 끝날 때까지 기다려야합니다. 귀하의 cfs_rq. 최근에 만료 된 런타임의 양이 cfs_rq 당 최대 1ms라는 사실을 발견했습니다. 이는 여유 타이머가 CPU 당 실행 대기열에서 사용되지 않은 할당량의 1ms만큼 모두 다시 캡처하기 때문입니다. 그 1ms는 기간이 끝날 때 낭비 / 만료됩니다. 애플리케이션이 88 cpus에 걸쳐 퍼지는 최악의 경우 100ms 기간 당 88ms의 낭비 된 할당량 일 수 있습니다. 실제로 슬랙 타이머가 유휴 CPU 별 실행 대기열에서 사용되지 않은 모든 할당량을 다시 캡처 할 수 있도록 허용하는 대체 제안으로 이어졌습니다.

당신이 특별히 강조하는 선은. 내 제안은 CPU 당 실행 대기열에 할당 된 런타임 만료를 완전히 제거하는 것입니다. 이 줄은 512ac999에 대한 수정 사항의 일부입니다. 이는 CPU 당 실행 대기열 사이의 클록 불균형으로 인해 할당량이 조기에 만료되어 아직 할당량 (afaiu)을 사용하지 않은 애플리케이션을 제한하는 문제를 해결했습니다. 기본적으로 각 기간 경계에서 expires_seq를 증가시킵니다. 따라서 expires_seq는 동일한 기간에있을 때 각 cfs_rq간에 일치해야합니다.

@mariusgrigoriu- 낮은 CPU 사용량으로 높은 스로틀 링에 도달하고 커널이 512ac999 이전 인 경우 아마도 512ac999가 필요할 것입니다. 512ac999를 게시하는 경우 위에서 설명한 문제가 현재 lkml에서 논의되고있을 가능성이 높습니다.
이 문제를 완화하는 방법에는 여러 가지가 있습니다.

• CPU 고정
• 애플리케이션이 생성하는 스레드 수 줄이기
• 스로틀 링이 발생한 애플리케이션에 할당량을 초과 할당합니다.
• 지금은 하드 제한을 해제하십시오.
• 제안 된 변경 사항 중 하나로 사용자 지정 커널을 빌드합니다.

@chiluk 이미 커널 4.14와 호환되는이 패치의 버전을 이미 게시 한 적이 있습니까? 수천 개의 호스트를 4.9.62에서 4.14.121로 업그레이드했으며 다음과 같은 결과를보고 있으므로 꽤 공격적으로 테스트하려고합니다.

1. memcached, mysql, nginx 등에 대한 제한 감소
2. 자바 앱에 대한 제한 증가

여기에서 두 세계를 최대한 활용하기 위해 정말로 롤 포워드하고 싶습니다. 다음 주에 직접 이식을 시도 할 수 있지만 이미 가지고 있다면 멋질 것입니다.

헉헉
Ben Segull의 제안에 따라 지난 며칠 동안 실제로 패치를 다시 작성했습니다. 새로운 커널 패치는 클러스터에서 테스트 시간을 확보 할 수있는대로 곧 출시 될 것입니다.

@chiluk 해당 패치에 대한 업데이트가 있습니까? 아니더라도 걱정하지 마세요. 지나가는 패치를 놓치지 않았는지 확인하고 있습니다.

@PaulFurtado , 패치는 CFS 작성자에 의해 "승인"되었으며 스케줄러 관리자가 패치를 통합하여 Linus에 푸시하기를 기다리고 있습니다.

@chiluk 감사합니다!

방금 현재 프로덕션 커널 인 커널 4.14에 패치를 백 포트했습니다.
백 포트에 대한 요점과 fibtest의 결과를 여기에서 만들었습니다 : https://gist.github.com/PaulFurtado/ff6c67ec87416b66ba1c6fc70f7beec1

kubernetes 및 mesos 클러스터에서 사용하는 현재 세대 c5.9xlarge 및 m5.24xlarge ec2 인스턴스에서 패치는 fibtest 프로그램의 성능을 두 배로 높입니다. 이전 세대 r4.16xlarge 인스턴스 유형에서는 1.5 배 더 많은 CPU 사용률을 관리하지만 추가 반복은 거의 발생하지 않습니다 (이는 CPU 생성 및 피보나치 시퀀스의 지수 적 특성 때문이라고 가정합니다). 이 숫자는 테스트를 5 초 기본값 대신 30 초로 늘리면 거의 정확하게 유지됩니다.

이번 주에이를 QA 환경에 적용하여 최악의 스로틀 링을 겪고있는 앱에서 몇 가지 지표를 얻을 것입니다. 다시 한 번 감사드립니다!

@PaulFurtado 먼저 테스트에 감사드립니다. kernel.org 4.14 또는 우분투 4.14를 실행 중이라고 가정하겠습니다. 둘 다 512ac999가 들어 있습니다. fibtest의 경우 완료된 반복은 사용 된 cpu 시간만큼 중요하지 않습니다. 완료된 반복은 테스트를 실행하는 동안 cpu mhz의 영향을 크게받을 수 있기 때문입니다 (특히 클라우드에서 제어 할 수있는 정도가 확실하지 않음).

kernel.org 4.14 또는 우분투 4.14를 실행 중이라고 가정하겠습니다. 둘 다 512ac999가 들어 있습니다.

예, 우리는 메인 라인 4.14를 실행합니다 (Amazon Linux 2 커널의 패치 세트를 포함하지만이 경우에는 해당 패치가 중요하지 않음).

512ac999는 메인 라인 4.14.95에 착륙했으며 4.14.77에서 4.14.121+로 업그레이드 할 때 영향을 관찰했습니다. 이로 인해 memcached 컨테이너 (매우 적은 스레드 수)가 설명 할 수없는 제한에서 제한 없음으로 바뀌었지만, golang 및 Java 컨테이너 (매우 높은 스레드 수)에서 더 많은 제한을 경험하게되었습니다.

fibtest의 경우 완료된 반복은 사용 된 cpu 시간만큼 중요하지 않습니다. 완료된 반복은 테스트를 실행하는 동안 cpu mhz의 영향을 크게받을 수 있기 때문입니다 (특히 클라우드에서 제어 할 수있는 정도가 확실하지 않음).

더 새롭거나 더 큰 EC2 인스턴스에서는 실제로 프로세서 상태에 대한 적절한 수준의 터보 부스트를 끈 상태로 실행 하고 코어가 유휴 상태가되지 않도록합니다. 하지만 실제로 우리가 c- 상태를 조정하고 있지만 p- 상태가 아니라는 것을 깨달았습니다. 반복 증가를 보지 못한 인스턴스 유형은 p- 상태를 제어 할 수있는 유형이므로 매우 잘 설명 할 수 있습니다.

먼저 테스트 해주셔서 감사합니다

전혀 문제 없습니다. 주말 동안 사전 QA 환경에서 상황이 안정적이었으며 내일 주요 QA 환경에 패치를 배포하기 시작하여 더 많은 실제 효과를 볼 수 있습니다. memcached가 이전 패치의 혜택을 받았다는 점을 감안할 때, 우리는 케이크를 갖고 싶었고 두 패치를 모두 제자리에 두어 먹기를 원했기 때문에 기꺼이 테스트했습니다. 조절에 투입 한 모든 작업에 다시 한 번 감사드립니다!

논의중인 커널 패치에 대해 메모를 남기고 싶었습니다 ....

현재 테스트에서 사용하고있는 커널에 적용했으며 CFS 스로틀 링 속도에서 몇 가지 큰 이점을 얻었습니다. 변경의 이점을 확인하기 위해이를 최대 100ms로 가져오고 싶습니다.

패치는 오늘 아침에 끝났습니다.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=de53fd7aedb100f03e5d2231cfce0e4993282425

Torvald의 트리에 도달하면 Linux 안정 포함을 위해 제출하고 이후 주요 배포판 (Redhat / Ubuntu)을 제출합니다. 다른 것에 관심이 있고 그들이 리눅스 안정 패치를 따르지 않는다면 직접 제출하는 것이 좋습니다.

CPU를 많이 사용하는 이미지 처리 golang 마이크로 서비스로 패치 (ubuntu 18.04, 5.2.7 커널, 노드 : 56 코어 CPU E5-2660 v4 @ 2.00GHz)를 테스트했으며 매우 인상적인 결과를 얻었습니다. 노드에서 CFS를 완전히 비활성화하는 것과 같은 성능.

거의 0에 가까운 스로틀 링 속도에서 동시성 / CPU 사용률에 따라 지연 시간이 5 ~ 35 % 감소하고 RPS가 5 ~ 55 % 증가했습니다.

감사합니다, @chiluk !

@jhohertz 라고

golang의 성능을 높이려면 GOMAXPROCS를 ceil (quota) +2로 설정하십시오. 플러스 2는 일부 동시성을 보장하는 것입니다.

@chiluk 는 GOMAXPROCS = 8과 GOMAXPROCS = 10으로 cpu.limit = 8로 테스트했습니다. 큰 차이는 아니지만 약 1-2 % 정도입니다.

@zigmund 는 cpu.limit가 8 cpu의 cpuset에 프로세스를 바인딩해야하는 정수 8로 설정되기 때문입니다. 1-2 % 차이는 8 개의 CPU 작업 세트에서 2 명의 추가 고 루틴 러너를 사용하여 컨텍스트 전환에 대한 오버 헤드가 증가한 것입니다.

GOMAXPROCS = # 설정은 커널 패치가 널리 배포 될 때까지 go 프로그램에 대한 좋은 해결 방법이라고 말 했어야합니다.

프로덕션 클러스터를 패치 된 커널로 마이그레이션했으며 이제 몇 가지 흥미로운 순간을 공유 할 수 있습니다.
클러스터 중 하나의 통계-72 코어 E5-2695 v4 @ 2.10GHz, 128Gb RAM, Debian 9, 5.2.7 커널 패치 포함.
우리는 대부분 golang 서비스로 구성된 혼합로드가 있지만 php와 python도 있습니다.

골랑. 지연 시간이 더 짧고 올바른 GOMAXPROCS를 설정하는 것이 절대적으로 필요합니다. 다음은 기본 GOMAXPROCS = 72 인 서비스입니다. 우리는 ~ 16에서 커널을 변경했으며 그 후 지연 시간이 줄어들고 CPU 사용률이 크게 증가했습니다. 21:15에 올바른 GOMAXPROCS를 설정하고 CPU 사용률을 정규화했습니다.

파이썬. 추가 이동없이 패치를 통해 모든 것이 개선되었습니다. CPU 사용률과 지연 시간이 감소했습니다.

PHP. CPU 사용률은 동일하며 일부 서비스에서는 지연 시간이 거의 감소하지 않습니다. 큰 이익이 아닙니다.

감사합니다 @zigmund.
I setted correct GOMAXPROCS 라고 말했을 때 잘 모르겠습니다 ...
72 개의 코어 노드에서 하나의 포드 만 실행하고 있지 않다고 가정하므로 GOMAXPROCS 를 더 낮은 값으로 설정하거나 포드의 CPU 제한과 같을 수 있습니다.

감사합니다 @zigmund. 이동 변경은 예상했던 것과 거의 일치합니다.

GIL이 이것의 이점을 거의 무효화 할 것으로 예상했지만 파이썬 개선에 정말 놀랐습니다. 이 패치가 응답 시간을 거의 순전히 줄여야하는 경우 제한 기간의 비율을 줄이고 CPU 사용률을 높이십시오. 파이썬 응용 프로그램이 여전히 정상입니까?

@ prune998 죄송합니다, 철자가 틀렸을 수도 있습니다. GOMAXPROCS = limits.cpu를 설정했습니다. 현재이 클러스터에는 노드 당 약 110 개의 포드가 있습니다.

@chiluk 저는 파이썬에 강하지 않으며 패치가 하위 계층에서 어떻게 영향을 받았는지 모릅니다. 그러나 응용 프로그램은 문제없이 정상이며 커널 변경 후 확인했습니다.

@chiluk 다양한 Linux 배포판에서 패치 진행 상황을 추적하는 방법을 설명해 주시겠습니까? 저는 특히 데비안과 AWS Linux에 관심이 있지만 다른 사람들이 우분투 등에 관심이 있기를 기대합니다. 어떤 빛을 비추어도 감사합니다.

@Nuru https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?highlight=stable%20rules ... 기본적으로 내 패치가 Linus에 도달하면 linux-stable을 통해 제출합니다. tree, * (아마도 더 일찍), 그리고 모든 배포판은 linux-stable 프로세스를 따라야하며 안정된 유지 관리자가 허용 한 패치를 배포판 특정 커널로 가져와야합니다. 그렇지 않은 경우 배포판을 실행하지 않아야합니다.

@chiluk Linux 개발 프로세스에 대해 아무것도 모릅니다. "Linus '트리"는 https://github.com/torvalds/linux 를 의미합니까?

Linus의 트리는 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/에 있습니다. 내 변경 사항은 현재 개발 통합 트리 인 linux-next에 준비되어 있습니다. 예 커널 개발은 암흑기에 약간 갇혀 있지만 작동합니다.

그는 5.3이 릴리스되고 5.4-rc0에서 개발을 시작하면 linux-next 트리에서 변경 사항을 가져올 가능성이 높습니다. 그것은 안정된 커널이이 수정을 시작할 것으로 예상되는 시간 프레임입니다. Linus가 5.3이 안정적이라고 느낄 때마다 누구나 추측 할 수 있습니다.

[Linus]는 5.3이 릴리스되고 5.4-rc0에서 개발을 시작하면 linux-next 트리에서 변경 사항을 가져올 것입니다. 그것은 안정된 커널이이 수정을 시작할 것으로 예상되는 시간 프레임입니다. Linus가 5.3이 안정적이라고 느낄 때마다 누구나 추측 할 수 있습니다.

@chiluk Linus가 2019 년 9 월 15 일 에 5.3이 안정적이라고 결정한 것 같습니다. 그렇다면 "linux-next"란 무엇이며 다음 단계를 통해 패치 진행 상황을 어떻게 추적합니까?

데비안 스트레치 패키지 및 / 또는이 패치가 포함 된 AWS 이미지를 빌드 한 사람이 있습니까? https://github.com/kubernetes-sigs/image-builder/tree/master/images/kube-deploy/imagebuilder를 사용하여 그렇게하려고합니다.

이미 존재한다면 중복 노력을 피할 것이라고 생각했습니다.

이것은 이제 Linus의 트리 에 병합되었으며 5.4에서 릴리스되어야합니다. 나는 또한 그것을 linux-stable에 제출했고, 안정된 프로세스를 올바르게 따르는 모든 배포판이 순조롭게 진행된다고 가정하면 곧 그것을 선택하기 시작할 것입니다.

이 변경이 CentOS (7)로 내려가는 경우 / 어떻게 따라야할지 아는 사람이 있습니까? 백 포팅 등이 어떻게 작동하는지 확실하지 않습니다.

@till https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -531370333

안정적인 커널 대화는 여기에서 진행됩니다.
https://lore.kernel.org/stable/CAC=E7cUXpUDgpvsmMaMU6sAydbfD0FEJiK25R1r=e9=YtcPjGw@mail.gmail.com/

또한 KubeCon에가는 사람들을 위해이 문제를 거기에서 발표 할 것입니다.
https://sched.co/Uae1

스케줄러 관리자의 말은 다음과 같습니다. Greg HK가 안정적인 트리로 가져 오기 위해 찾고 있던 ack?

Greg KH는 스케줄러 관리자가 응답하지 않았기 때문에이 패치에 대한 결정을 미루 었습니다. 이 패치를 테스트하고 백 포팅되어야한다고 생각하는 LKML에 대한 저 이외의 다른 사람의 의견은 감사하겠습니다.

CoreOS를 사용하는 사람들의 경우, 개방 문제가있다 @chiluk의 패치가 백 포트 할 것을 요청.

CoreOS 커널 4.19.82에는 수정 사항이 있습니다 : https://github.com/coreos/linux/pull/364
CoreOS Container Linux 2317.0.1 (알파 채널)에는 다음과 같은 수정 사항이 있습니다. https://github.com/coreos/coreos-overlay/pull/3796 http://coreos.com/releases/#2317.0.1

Linux stable 로의 백 포트 는 패치가 제대로 적용되지 않기 때문에 중단 된 것처럼 보입니다. @chiluk Linux 안정을위한 백 포트 작업을 하시겠습니까? 그렇다면 4.9로 백 포트하여 Debian "stretch"로 들어가 kops 의해 선택되도록 하시겠습니까? "스트레치"에 들어가는 데 6 개월이 걸릴 것 같지만 그때 kops 가 "buster"로 마이그레이션 될 것입니다.

@Nuru , 나는 패치를 백 포트하고 스트레치 패키지 (stretch-backports 커널 기반)와 kops 1.11 친화적 인 AMI를 만들었습니다.

https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-4.19.67-pm_4.19.67-1_amd64.buildinfo
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-image-4.19.67-pm_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-image-4.19.67-pm-dbg_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-headers-4.19.67-pm_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-4.19.67-pm_4.19.67-1_amd64.changes
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-libc-dev_4.19.67-1_amd64.deb

293993587779 / k8s-1.11-debian-stretch-amd64-hvm-ebs-2019-09-26

@blakebarnett 귀하의 노력에 감사 드리며 귀찮게해서 미안하지만 조금 더 혼란 스럽습니다.

• "stretch"는 Linux 4.9를 기반으로하지만 모든 링크는 4.19 용입니다.
• "패치"를 백 포트했다고 말했지만 3 개의 패치가 있습니다 (세 번째는 실제로 중요하지 않은 것 같습니다.
  
  
  
  1. 512ac999 sched / fair : 대역폭 타이머 클럭 드리프트 상태 수정
  
  
  2. de53fd7ae sched / fair : CPU 로컬 슬라이스 만료를 제거하여 높은 스로틀 링으로 낮은 CPU 사용량 수정
  
  
  3. 763a9ec06 sched / fair : -Wunused-but-set-variable 경고 수정
  
  

3 개의 패치를 모두 4.9로 백 포트 했습니까? (저는 데비안 패키지로 변경 사항이 있는지 확인하기 위해 무엇을해야할지 모르겠습니다. "변경 사항"문서는 실제로 변경된 사항을 다루지 않습니다.)

또한 어떤 리전에서 AMI를 사용할 수 있습니까?

아니요, 4.19 인 stretch-backports 커널을 사용했습니다. AWS에서도 필요한 수정 사항이 있기 때문입니다 (특히 M5 / C5 인스턴스 유형의 경우).

내가 믿는 모든 패치를 통합 한 diff를 적용했습니다. 4.19에서 다른 곳에서 삭제 된 변수에 대한 추가 참조를 제거하기 위해 약간 변경해야했습니다. 먼저 https://github.com/kubernetes/kubernetes/issues/67577을 적용했습니다.

--- kernel/sched/fair.c 2019-09-25 16:06:02.954933954 -0700
+++ kernel/sched/fair.c-b   2019-09-25 16:06:56.341615817 -0700
@@ -4928,8 +4928,6 @@

    cfs_b->period_active = 1;
    overrun = hrtimer_forward_now(&cfs_b->period_timer, cfs_b->period);
-   cfs_b->runtime_expires += (overrun + 1) * ktime_to_ns(cfs_b->period);
-   cfs_b->expires_seq++;
    hrtimer_start_expires(&cfs_b->period_timer, HRTIMER_MODE_ABS_PINNED);
 }

--- kernel/sched/sched.h    2019-08-16 01:12:54.000000000 -0700
+++ sched.h.b   2019-09-25 13:24:00.444566284 -0700
@@ -334,8 +334,6 @@
    u64         quota;
    u64         runtime;
    s64         hierarchical_quota;
-   u64         runtime_expires;
-   int         expires_seq;

    short           idle;
    short           period_active;
@@ -555,8 +553,6 @@

 #ifdef CONFIG_CFS_BANDWIDTH
    int         runtime_enabled;
-   int         expires_seq;
-   u64         runtime_expires;
    s64         runtime_remaining;

    u64         throttled_clock;

AMI가 us-west-1에 게시됩니다.

도움이 되었기를 바랍니다.

이 패치를 백 포트하여 Linux 안정적인 커널에 제출했습니다.
v4.14 https://lore.kernel.org/stable/[email protected]/
v4.19 https://lore.kernel.org/stable/[email protected]/ #t

안녕하세요,
4.19 브랜치에 패치를 통합 한 후, buster 및 stretch-backport에서 kerner를 적절히 업그레이드하기 위해 데비안 버그 보고서를 열었습니다.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946144

데비안 패키지 업그레이드에 대한 새로운 주석을 추가하는 것을 망설이지 마십시오.

이것이 너무 스팸 적이지는 않지만 @chiluk의 훌륭한 강연을이 문제와 관련된 많은 배경 정보로 연결하고 싶었습니다 . https://youtu.be/UE7QX98-kO0.

GKE에서 조절을 피할 수있는 방법이 있나요? 우리는 PHP 컨테이너의 한 방법이 일반적인 0.1 초 대신 120 초를 사용하는 큰 문제가있었습니다.

CPU 제한 제거

우리는 이미 CPU 요청이 너무 적을 때 컨테이너가 제한되고 있습니다. 이것이 문제의 핵심이며 제한이 없으며 CPU 요청 만 사용하면 여전히 스로틀 링이 발생합니다.

@bartoszhernas 여기에 잘못된 단어를 사용하고 있다고 생각합니다. 이 스레드의 사람들이 "throttling"을 언급 할 때 cgroup 증가에 대한 cpu.stat의 nr_throttled 인 cfs 대역폭 제어를 의미합니다. 이는 CPU 제한이 활성화 된 경우에만 활성화됩니다. GKE가 사용자 모르게 팟 (Pod)에 제한을 추가하지 않는 한 나는 당신이 치는 것을 조절이라고 부르지 않을 것입니다.

나는 당신이 "프로세서에 대한 경합"이라고 묘사 한 것을 부를 것입니다. 요청한 것보다 자주 사용하기 때문에 상자의 프로세서 또는 기타 리소스에 대해 경쟁하는 잘못된 크기의 응용 프로그램 * (요청)이 여러 개있을 수 있습니다. 이것이 우리가 한계를 사용하는 정확한 이유입니다. 따라서 부적절한 크기의 응용 프로그램은 상자의 다른 응용 프로그램에만 영향을 미칠 수 있습니다.

다른 가능성은 부족한 요청 량이 단순히 잘못된 스케줄링 동작으로 이어질 수 있다는 것입니다. 요청을 낮게 설정하는 것은 더 높은 "요청"응용 프로그램에 비해 양의 "좋은"값을 설정하는 것과 유사합니다. 이에 대한 자세한 내용은 소프트 제한을 확인하십시오.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ remove-lifecycle stale

내 이해에서 커널의 근본적인 문제가 수정되어 https://github.com/coreos/bugs/issues/2623의 ContainerLinux에서 사용할 수 있습니다
이 커널 패치 이후 남은 문제를 알고있는 사람이 있습니까?

@sfudeus Kubernetes는 모든 Linux 버전 또는 AFAIK, POSIT 호환 Unix 버전에서 실행할 수 있습니다. 이 버그는 Linux를 사용하지 않는 사람들에게는 결코 문제가되지 않았으며 일부 Linux 파생 배포판에서는 수정되었으며 다른 배포판에서는 수정되지 않았습니다.

근본적인 문제는 Linux 커널 5.4에서 수정되었으며 현재로서는 거의 사용하지 않습니다. 패치는 다양한 이전 커널로 백 포팅 할 수 있으며 아직 5.4 커널로 이동할 준비가되지 않은 새 Linux 배포판을 포함하여 사용할 수 있습니다. 이 문제를 참조하는 위의 커밋 목록에서 볼 수 있듯이 버그 수정 패치는 누군가가 Kubernetes를 사용하고있을 수있는 무수한 Linux 배포판에 여전히 통합되는 과정에 있습니다.

따라서 활성 커밋 참조가 계속 표시되는 동안이 문제를 열어두고 싶습니다. 또한 누군가가 Kubernetes 설치가 영향을 받는지 여부를 결정하는 데 사용할 수있는 스크립트 또는 기타 쉬운 방법으로 종료되는 것을보고 싶습니다.

@Nuru 괜찮아요, 이미 알려진 다른 커널 문제가 남아 있지 않은지 확인하고 싶었습니다. 저는 개인적으로 수정 사항을 통합 한 대규모 배포판보다 더 오래 열어 두지 않을 것입니다. 끝없는 IoT 장치를 기다리는 것은 끝없이 기다리는 것을 의미 할 수 있습니다. 닫힌 문제도 찾을 수 있습니다. 하지만 그건 내 2 센트에 불과합니다.

이것이 사람들에게 정보를 제공 할 올바른 장소인지 확실하지 않지만 다른 곳에서이를 제기해야 할 곳은 확실하지 않습니다.

k8s 1.15.10 클러스터를 사용하여 Debian Buster (buster-backports 커널 사용)에서 5.4 Linux 커널을 실행 중이며 여전히 문제가 발생합니다. 특히 일반적으로 할 일이 거의없고 (kube-downscaler는 우리가 계속 돌아가는 예이며 일반적으로 약 3m의 CPU가 필요함) 할당 된 CPU 리소스가 매우 적고 (kube-downscaler의 경우 50m) 클러스터) 우리는 여전히 매우 높은 조절 값을 볼 수 있습니다. 참고로 kube-downscaler는 기본적으로 sleep 를 30 분 동안 실행하는 Python 스크립트입니다. cAdvisor는이 컨테이너에 대한 container_cpu_cfs_throttled_periods_total의 증가가이 컨테이너의 container_cpu_cfs_periods_total 값과 항상 다소 유사하도록 표시합니다 (5m 간격으로 증가를 확인할 때 둘 다 약 250 임). 제한 기간이 0에 가까울 것으로 예상됩니다.

이것을 잘못 측정하고 있습니까? cAdvisor가 잘못된 데이터를 출력합니까? 스로틀 기간이 감소해야한다는 우리의 가정이 맞습니까? 여기에서 조언을 주시면 감사하겠습니다.

5.4 커널로 전환 한 후이 문제가있는 Pod 수가 약간 (약 40 %) 감소하는 것을 보았지만 현재보고있는 것이 실제 문제인지 여부는 확실하지 않습니다. 주로 위의 통계를 볼 때 3m 평균 CPU 사용량으로 이러한 값을 얻는 경우 "조절"이 실제로 의미하는 바가 확실하지 않습니다. 실행중인 노드는 오버 커밋되지 않으며 평균 CPU 사용량이 10 % 미만입니다.

@timstoop 스케줄러가 신경 쓰는 간격은 큰 30 분 범위가 아닌 마이크로 초 영역에 있습니다. 컨테이너의 CPU 제한이 50 밀리 푸이고 100 마이크로 초의 범위에서 50 밀리 푸를 사용하는 경우 30 분 유휴 시간에 관계없이 제한됩니다. 일반적으로 50 밀리 푸는 매우 작은 CPU 제한입니다. 파이썬 프로그램이 낮은 제한으로 단일 HTTPS 요청을하는 경우에도 거의 제한을받을 수 있습니다.

실행중인 노드는 오버 커밋되지 않으며 평균 CPU 사용량이 10 % 미만입니다.

명확히하기 위해 노드의로드 및 기타 워크로드는 스로틀 링과 관련이 없습니다. 제한은 컨테이너 / cgroup의 자체 제한만을 고려합니다.

@PaulFurtado 귀하의 답변에 감사드립니다! 그러나 Pod 자체의 평균 사용량은 해당 절전 모드에서 3m cpu이며 여전히 조절 중입니다. 그 시간 동안 어떤 요청도하지 않고 잠을 기다리고 있습니다. 50m 안타도 할 수 있으면 좋겠죠? 아니면 어쨌든 잘못된 가정입니까?

나는 이것이 정확성 문제가있을 정도로 낮은 수치라고 생각합니다. 그리고 50m는 너무 낮아서 어떤 것이 든 넘어 질 수 있습니다. Python의 런타임은 잠자는 동안 스레드에서 백그라운드 작업을 수행 할 수도 있습니다.

당신 말이 맞았어요. 사실이 아닌 가정을하고 있었어요. 귀하의 안내에 감사드립니다! 지금은 이해가갑니다.

커널 패치가 4.19 LTS 커널에 적용되고 CoreOS / Flatcar에 나타난 이후로 여기에있는 모든 것이 크게 개선되었다고 말하고 싶었습니다. 그 순간, 내가 제한되는 유일한 것은 내가 한계를 올려야 할 몇 가지 것입니다. :미소:

@sfudeus @chiluk 커널에이 문제가 수정되었는지 확인하는 간단한 테스트가 있습니까?

kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17 (현재 공식 kops 이미지)이 패치되었는지 여부를 알 수 없습니다.

@mariusgrigoriu에 동의합니다. 정적 cpu 정책에 따라 독점 cpuset에서 실행되는 포드의 경우 단순히 cpu 할당량 제한을 비활성화 할 수 있습니다. 어쨌든 독점 cpu 세트에서만 실행할 수 있습니다. 위의 패치는 이러한 목적을위한 것이며 이러한 유형의 포드에만 해당됩니다.

@Nuru 나는 https://github.com/indeedeng/fibtest를 썼다.
당신이 얻을 수있는 것처럼 테스트의 결정적이지만 C 컴파일러가 필요합니다.

완료된 반복 횟수를 무시하되 단일 스레드 대 다중 스레드 실행에 사용 된 시간에 초점을 맞 춥니 다.

패치 된 커널을 확인하는 좋은 방법은 @chiluk 의 마지막 슬라이드 중 하나입니다 (이 btw에 감사드립니다) 토크 https://www.youtube.com/watch?v=UE7QX98-kO0

커널 4.15.0-67에 패치 (https://launchpad.net/ubuntu/+source/linux/4.15.0-67.76)가있는 것 같지만 요청 / 제한이 훨씬 높은 일부 포드에서 여전히 스로틀 링이 발생합니다. CPU 사용량.
요청이 250m로 설정되고 500m로 제한되는 약 50ms 사용량에 대해 이야기하고 있습니다. CPU 기간의 약 50 %가 조절되는 것으로 나타났습니다.이 값은 예상 할 수있을만큼 낮고 수용 할 수 있습니까? 나는 그것을 0으로 낮추고 싶습니다. 사용량이 한도에 가까워지지 않는 경우에는 전혀 제한하지 않아야합니다.

패치 된 새 커널을 사용하는 사람이 여전히 약간의 제한이 있습니까?

@ vgarcia-te 패치 된 목록과 패치되지 않은 목록에서 알기에는 너무 많은 커널이 순환하고 있습니다. 이 문제를 참조하는 모든 커밋을 살펴보십시오. 수백. Ubuntu의 변경 로그를 읽은 결과 4.15가 아직 패치되지 않았으며 (Azure에서 실행되는 경우 mabye 제외) 연결 한 패치가 거부 되었음을 알 수 있습니다.

개인적으로 저는 4.9 시리즈에 관심이 있습니다. 그 이유는 kops 이 사용하고있는 것이기 때문에 그들이 수정 된 AMI를 언제 출시하는지 알고 싶습니다.

한편, 나에게 꽤 좋은 @bobrik 의 테스트 를 실행할 수 있습니다.

wget https://gist.githubusercontent.com/bobrik/2030ff040fad360327a5fab7a09c4ff1/raw/9dcf83b821812064fa7fb056b8f22cbd5c4364f1/cfs.go

sudo docker run --rm -it --cpu-quota 20000 --cpu-period 100000 -v $(pwd):$(pwd) -w $(pwd) golang:1.9.2 go run cfs.go -iterations 15 -sleep 1000ms

제대로 작동하는 CFS를 사용하면 레코딩 시간은 항상 5ms입니다. 위의 숫자를 사용하여 테스트 한 영향을받는 커널로 99ms의 레코딩 시간을 자주 볼 수 있습니다. 6ms가 넘는 것은 문제입니다.

@nuru 문제가 있는지 여부를 찾는 스크립트에 감사드립니다.

@justinsb 기본 이미지는 패치가 없거나 KOPS 경우 제안하십시오
https://github.com/kubernetes/kops/blob/master/channels/stable

발행 된 문제 : https://github.com/kubernetes/kops/issues/8954

https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -617586330

업데이트 : kops 1.15 이미지에서 테스트를 실행했습니다. 불필요한 제한이 있습니다. https://github.com/kubernetes/kops/issues/8954#issuecomment -617673755

누루

2020/04/22 11:02:48 [0] burn took 5ms, real time so far: 5ms, cpu time so far: 6ms
2020/04/22 11:02:49 [1] burn took 5ms, real time so far: 1012ms, cpu time so far: 12ms
2020/04/22 11:02:50 [2] burn took 5ms, real time so far: 2017ms, cpu time so far: 18ms
2020/04/22 11:02:51 [3] burn took 5ms, real time so far: 3023ms, cpu time so far: 23ms
2020/04/22 11:02:52 [4] burn took 5ms, real time so far: 4028ms, cpu time so far: 29ms
2020/04/22 11:02:53 [5] burn took 5ms, real time so far: 5033ms, cpu time so far: 35ms
2020/04/22 11:02:54 [6] burn took 5ms, real time so far: 6038ms, cpu time so far: 40ms
2020/04/22 11:02:55 [7] burn took 5ms, real time so far: 7043ms, cpu time so far: 46ms
2020/04/22 11:02:56 [8] burn took 5ms, real time so far: 8049ms, cpu time so far: 51ms
2020/04/22 11:02:57 [9] burn took 5ms, real time so far: 9054ms, cpu time so far: 57ms
2020/04/22 11:02:58 [10] burn took 5ms, real time so far: 10059ms, cpu time so far: 63ms
2020/04/22 11:02:59 [11] burn took 5ms, real time so far: 11064ms, cpu time so far: 69ms
2020/04/22 11:03:00 [12] burn took 5ms, real time so far: 12069ms, cpu time so far: 74ms
2020/04/22 11:03:01 [13] burn took 5ms, real time so far: 13074ms, cpu time so far: 80ms
2020/04/22 11:03:02 [14] burn took 5ms, real time so far: 14079ms, cpu time so far: 85ms

그 결과는

Linux <servername> 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

우분투 18.04의 기본 최신 안정 우분투 커널입니다.

그래서 패치 가 있는 것 같습니다.

@zerkms Ubuntu 18.04에서 테스트를 어디에서 실행 했습니까? 패치가 Azure 용 커널로만 만든 것 같습니다. Ubuntu linux 패키지에 적용된 위치를 알려주는 릴리스 노트를 찾을 수 있으면 공유하십시오. 찾을 수 없습니다.

이 테스트는 CoreOS에서도 문제를 재현 할 수 없었습니다. 기본 구성에서 CFS 스케줄링이 전역 적으로 비활성화되었을 수 있습니다.

누루

Ubuntu 18.04에서 테스트를 어디에서 실행 했습니까?

내 서버 중 하나.

나는 릴리스 노트를 확인하지 않았고, 무엇을 찾아야할지조차 확신하지 못합니다. 그럼에도 불구하고 모든 사람들이 가지고있는 것과 같은 기본 커널입니다. 🤷

패치는 우분투 스 커널 git에 있어야합니다.
https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?id=aadd794e744086fb50cdc752d54044fbc14d4adb

여기에 그것에 관한 우분투 버그가 있습니다.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832151

바이오닉에서 방출되어야합니다.
apt-get source linux 하여 확인하고 다운로드 한 소스 코드를 체크인 할 수 있습니다.

@zerkms "어디에서 테스트를 실행 했습니까?"라는 말은 사무실의 서버였습니까? GCP, AWS, Azure 또는 다른 곳의 서버

분명히 Ubuntu가 배포되고 유지되는 방식에 대해 이해하지 못하는 것이 많이 있습니다. 귀하의 uname -a 출력도 혼란 스럽습니다. Ubuntu 릴리스 노트에는 다음과 같은 내용 이 있습니다.

18.04.4는 18.04.3의 v5.0 기반 커널에서 업데이트 된 v5.3 기반 Linux 커널과 함께 제공됩니다.

또한 18.04.4가 2020 년 2 월 12 일에 출시되었다고 말합니다. 출력에 따르면 2020 년 4 월 1 일 컴파일 된 v4.15 커널을 실행하고 있습니다.

@juliantaylor 저는 Ubuntu 서버 나 Git 저장소의 복사본이 없으며 aadd794e7440 과 같은 특정 커밋이 게시 된 안정적인 커널로 만든 위치를 추적하는 방법을 모릅니다. 방법을 알려 주시면 감사하겠습니다.

런치 패드 버그 댓글을 보면

• 이 버그는 linux-azure-5.0.0-1027.29 패키지에서 수정되었습니다.
• 이 버그는 linux-azure-5.0.0-1027.29 ~ 18.04.1 패키지에서 수정되었습니다.

그러나이 특정 패치 ( sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices )는 아래에 나열되지 않습니다.

• 이 버그는 linux-4.15.0-69.78 패키지에서 수정되었습니다.

또한 Ubuntu 18.04.4 출시 노트 에 '1832151'이 표시되지 않습니다.

이전 의견 은 4.15.0-67.76에서 패치되었다고 말했지만 linux-image-4.15.0-67-generic 패키지가 보이지 않습니다.

저는 우분투의 전문가와는 거리가 멀고이 패치 추적이 용납 할 수 없을 정도로 어렵습니다.

이 패치가 실제로 18.04의 현재 버전 인 Ubuntu 18.04.4에 포함되었다고 확신하지 못하는 이유를 이제 이해하시기 바랍니다. 내 _ 최고의 추측 _은 18.04.4가 출시 된 후 커널 업데이트로 출시되었으며 Ubuntu 커널이 4.15.0-69 이상을보고하는 경우 포함되었을 수 있지만 18.04.4를 다운로드하고 업데이트하지 않는 경우, 패치가 없습니다.

방금 데이터 센터의 베어 메탈 서버에서 커널 4.15.0-72 에서 Go 테스트 (매우 유용함)를 실행했는데 패치가있는 것 같습니다.

2020/04/22 21:24:27 [0] burn took 5ms, real time so far: 5ms, cpu time so far: 7ms
2020/04/22 21:24:28 [1] burn took 5ms, real time so far: 1010ms, cpu time so far: 13ms
2020/04/22 21:24:29 [2] burn took 5ms, real time so far: 2015ms, cpu time so far: 20ms
2020/04/22 21:24:30 [3] burn took 5ms, real time so far: 3020ms, cpu time so far: 25ms
2020/04/22 21:24:31 [4] burn took 5ms, real time so far: 4025ms, cpu time so far: 32ms
2020/04/22 21:24:32 [5] burn took 5ms, real time so far: 5030ms, cpu time so far: 38ms
2020/04/22 21:24:33 [6] burn took 5ms, real time so far: 6036ms, cpu time so far: 43ms
2020/04/22 21:24:34 [7] burn took 5ms, real time so far: 7041ms, cpu time so far: 50ms
2020/04/22 21:24:35 [8] burn took 5ms, real time so far: 8046ms, cpu time so far: 56ms
2020/04/22 21:24:36 [9] burn took 5ms, real time so far: 9051ms, cpu time so far: 63ms
2020/04/22 21:24:37 [10] burn took 5ms, real time so far: 10056ms, cpu time so far: 68ms
2020/04/22 21:24:38 [11] burn took 5ms, real time so far: 11061ms, cpu time so far: 75ms
2020/04/22 21:24:39 [12] burn took 5ms, real time so far: 12067ms, cpu time so far: 81ms
2020/04/22 21:24:40 [13] burn took 5ms, real time so far: 13072ms, cpu time so far: 86ms
2020/04/22 21:24:41 [14] burn took 5ms, real time so far: 14077ms, cpu time so far: 94ms

동일한 유형의 서버에서 커널 4.9.164 에서 동일한 실행이 5ms에 걸쳐 번짐을 보여줍니다.

2020/04/22 21:24:41 [0] burn took 97ms, real time so far: 97ms, cpu time so far: 8ms
2020/04/22 21:24:42 [1] burn took 5ms, real time so far: 1102ms, cpu time so far: 12ms
2020/04/22 21:24:43 [2] burn took 5ms, real time so far: 2107ms, cpu time so far: 16ms
2020/04/22 21:24:44 [3] burn took 5ms, real time so far: 3112ms, cpu time so far: 24ms
2020/04/22 21:24:45 [4] burn took 83ms, real time so far: 4197ms, cpu time so far: 28ms
2020/04/22 21:24:46 [5] burn took 5ms, real time so far: 5202ms, cpu time so far: 32ms
2020/04/22 21:24:47 [6] burn took 94ms, real time so far: 6297ms, cpu time so far: 36ms
2020/04/22 21:24:48 [7] burn took 99ms, real time so far: 7397ms, cpu time so far: 40ms
2020/04/22 21:24:49 [8] burn took 100ms, real time so far: 8497ms, cpu time so far: 44ms
2020/04/22 21:24:50 [9] burn took 5ms, real time so far: 9503ms, cpu time so far: 52ms
2020/04/22 21:24:51 [10] burn took 5ms, real time so far: 10508ms, cpu time so far: 60ms
2020/04/22 21:24:52 [11] burn took 5ms, real time so far: 11602ms, cpu time so far: 64ms
2020/04/22 21:24:53 [12] burn took 5ms, real time so far: 12607ms, cpu time so far: 72ms
2020/04/22 21:24:54 [13] burn took 5ms, real time so far: 13702ms, cpu time so far: 76ms
2020/04/22 21:24:55 [14] burn took 5ms, real time so far: 14707ms, cpu time so far: 80ms

그래서 내 문제는 커널이 패치 된 것처럼 보이지만 여전히 CPU 스로틀 링이 보인다는 것입니다.

@Nuru 맞아, 죄송합니다. 그것은 사무실에서 호스팅되는 베어 메탈 서버였습니다.

또한 18.04.4가 2020 년 2 월 12 일에 출시되었다고 말합니다. 출력에 따르면 2020 년 4 월 1 일 컴파일 된 v4.15 커널을 실행하고 있습니다.

이는 서버 LTS이기 때문입니다. 최신 커널을 사용하려면 HWE를 명시 적으로 옵트 인해야합니다. 그렇지 않으면 메인 라인 만 실행하면됩니다.

그리고 메인 라인 커널과 HWE 커널 모두 정기적으로 릴리스되므로 최근에 빌드 된 커널이 있다고 의심되는 것은 없습니다. http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-meta/linux-meta_4.15.0.96.87/ 변경 로그

@zerkms 정보 주셔서 감사합니다. 여전히 혼란 스럽지만 이곳은 나를 교육 할 곳이 아닙니다.

@ vgarcia-te 커널이 패치 된 것 같으면이 버그로 인한 제한이 아닙니다. 다음과 같이 말할 때 용어를 잘 모르겠습니다.

요청이 250m로 설정되고 500m로 제한되는 약 50ms 사용량에 대해 이야기하고 있습니다. CPU 기간의 약 50 %가 조절되는 것으로 나타났습니다.이 값은 예상 할 수있을만큼 낮고 수용 할 수 있습니까?

Kubernetes CPU 리소스는 CPU 단위로 측정됩니다. 1은 전체 CPU 1 개의 100 %를 의미하고 1m은 1 CPU의 0.1 %를 의미합니다. 따라서 "500m"의 제한은 0.5 CPU를 허용합니다.

CFS의 기본 예약 기간은 100ms이므로 제한을 CPU 0.5 개로 설정하면 프로세스가 100ms마다 50ms의 CPU로 제한됩니다. 프로세스가이를 초과하려고하면 제한됩니다. 프로세스가 일반적으로 단일 패스에서 50ms 이상 실행되는 경우 올바르게 작동하는 스케줄러에 의해 제한 될 것으로 예상 할 수 있습니다.

@Nuru 그게 말이 되겠지만, 기본 CPU 기간이 100ms라는 점을 감안할 때 프로세스에 1 개의 CPU가 할당 된 경우 해당 프로세스가 단일 패스에서 100ms 이상 실행되는 경우 스로틀 링됩니까?
이것은 기본 CPU 기간이 100ms 인 Linux에서 단일 패스에서 100ms 이상 실행되는 제한이있는 모든 프로세스가 스로틀된다는 것을 의미합니까?

단일 패스에서 100ms 이상 걸리지 만 나머지 시간 동안 유휴 상태 인 프로세스에 대한 좋은 제한 구성은 무엇입니까?

@ vgarcia-te가 물었다

기본 CPU 기간이 100ms라고 가정 할 때 프로세스에 1 개의 CPU가 할당 된 경우 해당 프로세스가 단일 패스에서 100ms 이상 실행되는 경우 제한됩니까?

물론 일정은 엄청나게 복잡해서 완벽한 답을 드릴 수는 없지만 간단한 답은 아니오입니다. 더 자세한 설명은 여기 와 여기에 있습니다 .

모든 유닉스 프로세스는 시간 조각을 기반으로하는 선점 형 스케줄링의 적용을받습니다. 단일 코어 단일 CPU 시절에는 여전히 30 개의 프로세스가 "동시에"실행되었습니다. 일어나는 일은 그들이 잠시 뛰고 잠을 자거나 시간 조각이 끝날 때 다른 것이 실행될 수 있도록 대기 상태가되는 것입니다.

할당량이있는 CFS는이를 한 단계 더 발전시킵니다.

하지만 프로세스가 CPU의 50 %를 사용하기를 원한다고 말할 때 실제로 무슨 말을하고 있습니까? 5 분 동안 CPU를 100 % 잡아 먹고 다음 5 분 동안 전혀 실행되지 않는 한 괜찮다는 말입니까? 이는 10 분 동안 50 % 사용량이지만 대기 시간 문제로 인해 대부분의 사람들에게 허용되지 않습니다.

따라서 CFS는 할당량을 적용하는 기간 인 "CPU 기간"을 정의합니다. 코어가 4 개이고 CPU주기가 100ms 인 시스템에서 스케줄러는 실제 (벽시계) 시간을 100ms 이상 할당하기 위해 400ms의 CPU 시간을가집니다. 병렬화 할 수없는 단일 실행 스레드를 실행하는 경우 해당 스레드는 기간 당 최대 100ms의 CPU 시간을 사용할 수 있으며 이는 CPU 1 개의 100 %입니다. 할당량을 1 CPU로 설정하면 제한되지 않습니다.

할당량을 500m (0.5 CPU)로 설정하면 프로세스가 100ms마다 실행되는 데 50ms가 걸립니다. 100ms 기간은 50ms 미만을 사용하므로 제한되지 않아야합니다. Ayn 100ms 기간은 50ms를 실행 한 후에도 완료되지 않으며 다음 100ms 기간까지 스로틀됩니다. 이를 통해 지연 시간 (실행할 수있을 때까지 기다려야하는 시간)과 호깅 (다른 프로세스가 실행되지 않도록 허용되는 시간) 사이의 균형을 유지합니다.

@Nuru 내 슬라이드가 정확합니다. 나는 우분투 개발자이기도하다 * (지금은 여가 시간에만). 가장 좋은 방법은 소스를 읽고 git blame + tag --contains를 확인하여 패치가 관심있는 커널 버전에 도달하는시기를 추적하는 것입니다.

@chiluk 나는 당신의 슬라이드를 보지 못했습니다. 아직 본 적이없는 다른 사람들을 위해, 패치가 얼마 전에 도착했다고 말하는 곳은 다음과 같습니다.

• Ubuntu 4.15.0-67 이상
• Ubuntu 5.3.0-24 +
• RHEL7 커널 3.10.0-1062.8.1.el7
  물론 Linux stable v4.14.154, v4.19.84, 5.3.9. Linux 안정적인 5.4-rc1에도 있습니다.

레거시 설치에서 다양한 커널을 지원하기 때문에 다양한 CFS 스케줄러 버그를 이해하고 소규모 AWS 서버에서 작동하는 안정적이고 해석하기 쉬운 테스트를 찾는 데 여전히 어려움을 겪고 있습니다. 타임 라인을 이해했듯이 2014 년 Linux 커널 v3.16-rc1에 버그가 발생했습니다.

• [51f2176d74ac](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51f2176d74ac) sched/fair: Fix unlocked reads of some cfs_b->quota/period

이로 인해 다양한 CFS 조절 문제가 발생했습니다. kops Kubernetes 클러스터에서 발생한 문제는 4.9 커널을 사용했기 때문에이 버그 때문이라고 생각합니다.

51f2176d74ac 는 2018 커널 v4.18-rc4에서 다음과 같이 수정되었습니다.

• [512ac999](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=512ac999d2755d2b7109e996a76b6fb8b888631d) sched/fair: Fix bandwidth timer clock drift condition

그러나 그것은 @chiluk 버그를 도입했습니다.

• [de53fd7ae](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de53fd7aedb100f03e5d2231cfce0e4993282425) sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices

물론 커널 패치가 배포판 전체에서 추적하기 어렵다는 것은 Chiluk 또는 다른 한 사람의 잘못이 아닙니다. 그래도 여전히 실망스럽고 혼란 스럽습니다.

예를 들어 Debuan buster 10 (AWS AMI debian-10-amd64-20191113-76 )에서 커널 버전은 다음과 같이보고됩니다.

Linux ip-172-31-41-138 4.19.0-6-cloud-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

내가 알 수있는 한,이 커널에는 51f2176d74ac 이 있어야하고 512ac999 가 없어야하므로 512ac999 설명 된 테스트에 실패해야하지만 그렇지 않습니다. (리눅스 커널 4.10에서 점진적으로 업그레이드되었고 변경 로그에 해당 패치에 대한 언급이 없기 때문에 512ac999 가 없다고 생각합니다.) 그러나 4 cpu AWS VM에서는 실패하지 않습니다. Chiluk의 fibtest 또는 Bobrik의 CFS 딸꾹질 테스트는 다른 작업이 진행 중임을 나타냅니다.

나는 Chiluk의 패치를 받기 전에 CoreOS에서 스케줄링 문제를 재현하는 데 비슷한 문제가있었습니다.

현재 제 생각은 Bobrik의 테스트가 주로 51f2176d74ac 대한 테스트이고, 제가 사용중인 Debian buster 10 AMI _does_는 512ac999 가 있으며 변경 로그에서 명시 적으로 호출되지 않았으며 fibtest 는 코어가 몇 개인 컴퓨터에서 매우 민감한 테스트가 아닙니다.

4 코어 CPU는 수정 된 문제를 재현하기에 충분하지 않을 수 있습니다.

chiluks kubecon talk (https://www.youtube.com/watch?v=UE7QX98-kO0)의 설명을 올바르게 이해했다면 40 cpus 이상의 더 큰 컴퓨터에서만 재현 가능해야합니다.

주변에는 많은 커널 버전이 있으며 많은 패치 및 패치 되돌리기가 진행 중입니다. 변경 로그와 버전 번호는 지금까지만 알려줍니다.
의심스러운 경우 유일한 신뢰할 수있는 방법은 소스 코드를 다운로드하여 여기에 링크 된 패치의 변경 사항과 비교하는 것입니다.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

/ remove-lifecycle stale

이 스레드의 앞부분에서 언급 한 테스트는 실제로 문제를 재현하지 못하지만 (몇 번의 번에 5ms 이상 걸리지 만 그중 0.01 %와 같습니다) 우리의 cfs 스로틀 링 메트릭은 여전히 ​​적당한 양의 스로틀 링을 보여줍니다. 클러스터 전반에 걸쳐 서로 다른 커널 버전이 있지만 가장 일반적인 두 가지 버전은 다음과 같습니다.

• Debian 4.19.67-2+deb10u2~bpo9+1 (2019-11-12)
• 5.4.38 의 수동 백 포트

이 버전에서 두 버그가 모두 수정되어야하는지 모르겠지만 그래야한다고 생각합니다. 그래서 테스트가 그다지 유용하지 않은지 궁금합니다. 16 코어와 36 코어가있는 컴퓨터에서 테스트 중입니다. 테스트가 유효하기 위해 더 많은 코어가 필요한지 확실하지 않지만 이러한 클러스터에서 스로틀 링이 여전히 표시되므로 ...

이 문제를 닫고 문제에 직면 한 사람들에게 새로운 문제를 시작하도록 요청해야합니까? 여기서 스팸은 대화를 매우 어렵게 만들 것입니다.

^ 동의합니다. 이 문제를 해결하기 위해 많은 일이 이루어졌습니다.

/닫기

위의 의견에 따라. 필요에 따라 새로운 호를여십시오.

@dims :이 문제를 마무리합니다.

이 이슈에 대한 후속 이슈를 알려 주시면 이슈를 구독 한 사람들이 새로운 이슈를 구독 할 수 있습니다.