Kubernetes: CFSクォータは、不要なスロットリングにつながる可能性があります

/ sigノード
/種類のバグ

これは＃51135の複製ですか？

精神的には似ていますが、CFSクォータ期間の構成のトレードオフだけでなく、カーネルに実際のバグがあるという事実を見逃しているようです。 私はここに戻って＃51135が好きで、そこにいる人々により多くのコンテキストを提供します。

私が理解している限り、これはCFSクォータを無効にする（ --cpu-cfs-quota=false ）か、構成可能にする（＃63437）もう1つの理由です。

また、この要点（カーネルパッチからリンクされている）を見るのは非常に興味深いと思います（影響を測定するため）： https ：

cc @adityakali

クォータに関するもう1つの問題は、kubeletがハイパースレッドを「CPU」としてカウントすることです。 2つのスレッドが同じコアでスケジュールされるようにクラスターがロードされ、プロセスにCPUクォータクォータがある場合、そのうちの1つは、使用可能な処理能力のごく一部でのみ実行されます（他のスレッドで何かが発生した場合にのみ何かを実行します）ストール）が、それ自体に物理コアがあるかのようにクォータを消費します。 そのため、大幅な作業を行わなくても、必要なクォータの2倍を消費します。
これには、ハイパースレッディングが有効になっている完全にロードされたノードノードでは、ハイパースレッディングまたはクォータが無効になっている場合のパフォーマンスの半分になるという効果があります。

Imo the kubeletは、この状況を回避するために、ハイパースレッドを実際のCPUと見なすべきではありません。

@ juliantaylor ＃51135で述べたように、CPUクォータをオフにすることは、信頼できるワークロードを実行しているほとんどのk8sクラスターにとって最良のアプローチかもしれません。

これはバグと見なされますか？

一部のポッドがCPU制限を実際に使い果たしていないのにスロットルされている場合、それは私にはバグのように聞こえます。

私のクラスターでは、クォータ超過ポッドのほとんどはメトリック（ヒープスター、メトリックコレクター、ノードエクスポーター...）またはオペレーターに関連しています。これらは明らかにここで問題となっている種類のワークロードを持っています：ほとんど何もしません時間と目を覚まして、時々和解します。

ここで奇妙なのは、 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に感謝します。
私はGoogleGKEを使用していて、それを無効にする簡単な方法がわかりませんが、検索を続けています。

@ prune998 AFAIK、Googleはまだ必要なノブを公開していません。 アップストリームに到着したCFSを無効にする可能性の直後に機能リクエストを提出しましたが、それ以来ニュースはありません。

私はGoogleGKEを使用していて、それを無効にする簡単な方法がわかりませんが、検索を続けています。

今のところ、コンテナから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）は、CPUスロットリングを無効にするフラグをKopsに提供しました： https ：

ここで問題の概要を共有してください。 問題が何であるか、どのシナリオでユーザーが影響を受けるか、そしてそれを修正するために正確に何が必要かはあまり明確ではありませんか？

現在の私たちの理解は、私たちが限界を超えると、罰せられ、抑制されるということです。 つまり、CPUクォータが3コアで、最初の5ミリ秒で3コアを消費した後、100ミリ秒のスライスで95ミリ秒の間スロットルされ、この95ミリ秒ではコンテナは何もできません。 また、CPU使用率のメトリックにCPUスパイクが表示されていない場合でも、スロットルが調整されることがわかりました。 CPU使用率を測定する時間枠が秒単位であり、スロットリングがマイクロ秒レベルで発生しているため、平均化されて表示されないためと考えられます。 しかし、ここで言及されているバグにより、私たちは今混乱しています。

いくつかの質問：

• ノードが100％CPUにあるとき？ これは、使用状況に関係なくすべてのコンテナーがスロットルされる特殊なケースですか？

• これが発生すると、すべてのコンテナのCPUが100％抑制されますか？

• このバグがノードでトリガーされるトリガーは何ですか？

• 使用していないとの違いは何であるlimitsと無効化cpu.cfs_quota ？

• バースト可能なポッドが多数あり、1つのポッドがノードを不安定にし、要求を実行している他のポッドに影響を与える可能性がある場合、 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

ユーザーの1人がCPU制限を設定し、活性プローブをタイムアウトさせてサービスを停止させました。

コンテナをCPUに固定している場合でも、スロットルが発生しています。 たとえば、CPU制限が1で、そのコンテナを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静的ポリシーを使用したGuaranteedQoSクラスのポッドでのCPUスロットリングを観察します（これは意味がないようです）。

これらのポッドのlimitsを削除すると、それらはBurstable QoSクラスに配置されますが、これは必要なものではないため、残っている唯一のオプションは、システム全体でCFS CPUクォータを無効にすることです。これも、安全に実行できることではありません。すべてのポッドにバインドされていないCPU容量へのアクセスを許可すると、危険なCPU飽和の問題が発生する可能性があるためです。

@vishh上記の状況を考えると、最善の行動は何でしょうか？ カーネル> 4.18（cfs cpuアカウンティング修正があります）にアップグレードし、（おそらく）cfsクォータ期間を短縮しているように見えますか？

一般的に、スロットルされているコンテナーからlimitsを削除することを提案すると、明確な警告が表示されます。
1）これらが保証されたQoSクラスのポッドであり、整数のコアがあり、CPUMnanager静的ポリシーが設定されている場合-これらのポッドは、Burstable QoSクラスに配置されるため（要求なし==制限）、
2）これらのポッドは、消費できるCPUの量に関して制限がなく、特定の状況下でかなりの損傷を引き起こす可能性があります。

フィードバック/ガイダンスをいただければ幸いです。

カーネルのアップグレードは間違いなく役立ちますが、CFSクォータを適用する動作は、ドキュメントの提案と一致していないようです。

私はこの問題のさまざまな側面をしばらく研究してきました。 私の研究は、LKMLへの私の投稿に要約されています。
https://lkml.org/lkml/2019/3/18/706
そうは言っても、512ac99より前のカーネルで説明されている問題を再現することはできませんでした。 ただし、512ac99以降のカーネルでパフォーマンスの低下が見られました。 したがって、その修正は万能薬ではありません。

@mariusgrigoriuに感謝します。カーネルのアップグレードを予定しており、それがある程度役立つことを願っています。https：//github.com/kubernetes/kubernetes/issues/70585も確認しては実際に割り当て

@chiluk少し詳しく

512ac99カーネルパッチは一部の人々の問題を修正しますが、私たちの構成に問題を引き起こしました。 パッチは、タイムスライスがcfs_rq間で分散される方法を修正し、正しく期限切れになるようになりました。 以前は、有効期限はありませんでした。

特にコア数の多いマシンでのJavaワークロードでは、ワーカースレッドがブロックされているため、CPU使用率が低く大量のスロットルが発生するようになりました。 これらのスレッドにはタイムスライスが割り当てられ、その一部のみが後で期限切れになります。 私が書いた*（そのスレッドにリンクされている）合成テストでは、パフォーマンスが約30倍低下していることがわかります。 実際のパフォーマンスでは、スロットルの増加により、2つのカーネル間で応答時間が数百ミリ秒低下しました。

4.19.30カーネルを使用すると、スロットルが少なくなることを期待していたポッドが引き続きスロットルされ、以前はスロットルされていなかった一部のポッドが非常に厳しくスロットルされていることがわかります（kube2iamは、インスタンスが起動しているよりも多くの秒がスロットルされていると報告しています、 何とかして）

CoreOS 4.19.25-coreosでは、Prometheusがシステム内のほぼすべてのポッドでCPUThrottlingHighアラートをトリガーしているのがわかります。

@ williamsandrew @ teralypeこれは@chilukの調査結果を反映しているようです。

さまざまな内部の議論の結果、実際にはcfsクォータを完全に無効にすることにしました（kubeletのフラグ--cpu-cfs-quota=false ）。これにより、バースト可能ポッドと保証付き（CPU固定または標準）ポッドの両方で発生していたすべての問題が解決されるようです。

これ（および他のいくつかのトピック）に関する優れたデッキがここにあります： https ：

強くお勧めします：+1：

長期的な問題（自己メモ）

@ dannyk81完全をリンクされたトークは録画されたビデオとしても利用できます： https ： 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 PMムーディーサーダ[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（ Twitterスレッド）など、CPUスロットリングを無効にする企業が増えてい

@derekwaynecarr @ dchen1107 @ kubernetes / sig-node-feature-requests Dawn、Derek、デフォルトを変更する時が来ましたか？ および/またはドキュメント？

はい@whereisaaronは、不自由なアプリケーションの

@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を提出できますか？

すでに1つあります： //github.com/kubernetes/kubernetes/pull/75682

@dims PRではなく問題をリンクしました...しかし、問題はPRにリンクされています:)確かに

ありがとう：+1：

おっと！ ありがとう@ dannyk81私は人々を割り当て、マイルストーンを追加しました

FWIWでもこの問題が発生し、CFSクォータ期間をデフォルトの100ミリ秒ではなく10ミリ秒に下げると、テールエンドの遅延が劇的に改善されることがわかりました。 これは、カーネルのバグが発生した場合でも、使用しないと無駄になるクォータの量がはるかに少なくなり、プロセスがより多くのクォータを（より少ない割り当てで）より早く取得できるためだと思います。 これは単なる回避策ですが、CFSクォータを完全に無効にしたくない場合は、修正が実装されるまでこれはバンドエイドになる可能性があります。 k8sは、1.12でcpuCFSQuotaPeriod機能ゲートと--cpu-cfs-quota-periodkubeletフラグを使用してこれを行うことをサポートしています。

確認する必要がありますが、コードにはスライスの最小値とクォータの最小値があるため、期間をこれまで短縮すると、効果的に無効にする効果があると思います。 クォータをオフにしてソフトクォータに移行したほうがよいでしょう。

@chiluk私の素人の理解では、デフォルトのスライスは5ミリ秒であるため、それ以下に設定すると効果的に無効になりますが、期間が5ミリ秒を超えている限り、クォータが適用されます。 それが正しくない場合は、間違いなく私に知らせてください。

--feature-gates=CustomCPUCFSQuotaPeriod=true --cpu-cfs-quota-period=10msで、私のポッドの1つが起動するのに本当に苦労しました。 添付のプロメテウスグラフでは、コンテナは起動を試み、終了するまで活性チェックに近づくことはありません（通常、コンテナは約5秒で起動します-活性を初期遅延秒数を60秒に増やしても効果はありませんでした）。その後、新しいものと交換します。

kubelet argsからcpu-cfs-quota-periodを削除するまで、コンテナーが大幅にスロットルされていることがわかります。この時点で、スロットルは非常にフラットになり、コンテナーは約5秒で再び起動します。

参考：CPUスロットリングの無効化に関する現在のTwitterスレッド： https ：

これらは、2つのレイテンシに敏感なサービスの本番環境で--cpu-cfs-quota-period=10msに移行する前/後のCPUスロットリンググラフです。

これらのサービスは、さまざまなインスタンスタイプ（さまざまな汚染/許容範囲）で実行されます。 2番目のサービスのインスタンスは、最初に低いCFSクォータ期間に移動されました。

結果は負荷に大きく依存する必要があります。

@ d-shi何か他のことがあなたのグラフで起こっています。 期間が非常に短いため、現在ヒットしている最小クォータ割り当てがある可能性があると思います。 確かにコードをチェックする必要があります。 基本的に、アプリケーションで使用可能なクォータの量を誤って増やしました。 実際にクォータの割り当てを増やすことで、同じことを達成できたはずです。

私たちにとっては、スロットルよりもレイテンシーを測定する方がはるかに便利でした。 cfs-quota無効にすると、レイテンシが劇的に改善されました。 cfs-quota-periodを変更しても同様の結果が得られるようにしたいと思います。

@chilukは、実際にクォータの割り当てを増やしてみました（ポッドごとのkubernetesでサポートされる最大値まで）。テールエンドのレイテンシやスロットリングが大幅に削減されることはありませんでした。 p99のレイテンシーは、4コアの制限での約98msから16コアの制限での86msになりました。 CFSクォータを10ミリ秒に減らした後、p99は4コアで20ミリ秒になりました。

@blakebarnettレイテンシを測定するベンチマークプログラムを開発しました。レイテンシは10ミリ秒から100ミリ秒の範囲で、 --cpu-cfs-quota-periodを更新する前の平均は約18ミリ秒でしたが、平均で10ミリ秒から20ミリ秒の範囲でした。その後約11msの。 p99の待ち時間は約98ミリ秒から20ミリ秒になりました。

編集：編集して申し訳ありませんが、戻って番号を再確認する必要がありました。

@ 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に基づいて5ミリ秒間スロットルされます。 そうじゃない？
私は何かが恋しいですか？

@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に補充されてから、あなたのcfs_rq。 私は最近、スラックタイマーがCPUごとの実行キューから未使用のクォータを1ミリ秒ずつ再キャプチャするため、期限切れのランタイムの量がcfs_rqごとに最大1ミリ秒であることを発見しました。 その1msは、期間の終わりに無駄になり、期限切れになります。 アプリケーションが88CPUに広がる最悪のシナリオでは、100ミリ秒の期間あたり88ミリ秒の無駄なクォータになる可能性があります。 それは実際には、スラックタイマーがアイドル状態のCPUごとの実行キューから未使用のクォータをすべて再キャプチャできるようにするという代替案につながりました。

あなたが特に強調する線に関しては。 私の提案は、CPUごとの実行キューに割り当てられているランタイムの有効期限を完全に削除することです。 これらの行は、512ac999の修正の一部です。 これにより、CPUごとの実行キュー間のクロックスキューによりクォータが早期に期限切れになり、クォータをまだ使用していないアプリケーションが抑制される問題が修正されました（afaiu）。 基本的に、各期間の境界でexpires_seqをインクリメントします。 したがって、expires_seqは、同じ期間にある場合、各cfs_rq間で一致する必要があります。

@ mariusgrigoriu -CPU使用率が低く、スロットリングが高く、カーネルが512ac999より前の場合は、おそらく512ac999が必要です。 512ac999を投稿している場合は、現在lkmlで議論されている上記で説明した問題が発生している可能性があります。
この問題を軽減する方法はたくさんあります。

• CPUピン留め
• アプリケーションが生成するスレッドの数を減らす
• スロットルが発生しているアプリケーションにクォータを過剰に割り当てます。
• 今のところ、ハード制限をオフにします。
• 提案された変更のいずれかを使用してカスタムカーネルを構築します。

@chilukカーネル4.14と互換性のあるこのパッチのバージョンをすでに投稿している可能性はありますか？ 数千のホストを4.14.121（4.9.62から）にアップグレードしたばかりなので、かなり積極的にテストすることを検討しています。

1. memcached、mysql、nginxなどのスロットリングの削減
2. Javaアプリのスロットリングの増加

ここで両方の世界を最大限に活用するために、本当に前進したいと思っています。 来週は自分で移植することもできますが、すでに持っているのであれば、それは素晴らしいことです。

@PaulFurtado
Ben Segullの提案を受けて、私は過去数日間にパッチを実際に書き直しました。 新しいカーネルパッチは、クラスターでテスト時間を取得できるようになり次第、リリースされる予定です。

@chilukそのパッチの更新はありますか？ そうでなければ心配ありません、私はただパッチが通過するのを見逃していないことを確認しています

@PaulFurtado 、パッチはCFS作成者によって「承認」されており、スケジューラのメンテナがそれを統合してLinusにプッシュするのを待っています。

@chilukありがとうございます！

パッチを現在の本番カーネルであるカーネル4.14にバックポートしました。
私はここでバックポートとあなたのfibtestからのいくつかの結果で要点を作りました： https ：//gist.github.com/PaulFurtado/ff6c67ec87416b66ba1c6fc70f7beec1

kubernetesおよびmesosクラスターで使用する現世代のc5.9xlargeおよびm5.24xlargeec2インスタンスでは、パッチによってfibtestプログラムのパフォーマンスが2倍になります。 前世代のr4.16xlargeインスタンスタイプでは、1.5倍のCPU使用率を管理しますが、追加の反復はほとんどありません（これは、CPU生成とフィボナッチ数列の指数関数的な性質によるものと思います）。 テストをデフォルトの5秒ではなく30秒に増やすと、これらの数値はすべてほぼ正確に保持されます。

今週、これをQA環境にロールインして、最悪のスロットルに苦しんでいるアプリからいくつかの指標を取得します。 再度、感謝します！

@PaulFurtadoは最初にテストに感謝します。 kernel.org4.14またはubuntu4.14を実行していると仮定します。どちらにも512ac999が含まれています。 fibtestに関しては、完了した反復はCPU時間の使用ほど重要ではありません。完了した反復は、テストの実行中にcpu mhzの影響を大きく受ける可能性があるためです（特に、それをどの程度制御できるかわからないクラウドでは）。

kernel.org4.14またはubuntu4.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インスタンスでは、実際にはプロセッサの状態を適切なレベルでターボブーストをオフにして

まずはテストありがとうございます

まったく問題ありません。週末のQA前の環境では状況が安定しており、明日からメインのQA環境にパッチを展開して、より現実的な効果を確認できるようにします。 memcachedが以前のパッチの恩恵を受けていたことを考えると、私たちは本当にケーキを用意して、両方のパッチを配置した状態でそれを食べたかったので、テストできました。 あなたがスロットルに費やしているすべての仕事にもう一度感謝します！

議論されているカーネルパッチに関して、メモを残したかっただけです。

現在のテストで使用しているカーネルに適合させて、CFSスロットリングレートで大きな成果が見られましたが、以前にcfs期間を緩和策として10ミリ秒に設定した場合は、次のようになります。変更のメリットを確認するには、それを100ミリ秒まで戻したいと考えています。

パッチは今朝先端に着陸しました。
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=de53fd7aedb100f03e5d2231cfce0e4993282425

Torvaldのツリーに到達したら、Linuxに安定したインクルージョン、続いて主要なディストリビューション（Redhat / Ubuntu）に提出します。 他のことに関心があり、Linuxに安定したパッチに準拠していない場合は、直接送信することをお勧めします。

私はパッチ（ubuntu 18.04、5.2.7カーネル、ノード：56コアCPU E5-2660 v4 @ 2.00GHz）をCPUを多用する画像処理golangマイクロサービスでテストし、かなり印象的な結果を得ました。 ノードでCFSを完全に無効にした場合のようなパフォーマンス。

ほぼゼロのスロットルレートでの同時実行性/ 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に設定されているためです。これにより、プロセスが8cpusのCPUセットにバインドされます。 1〜2％の違いは、8つのCPUタスクセットで2つの追加のGoroutineランナーを使用したコンテキスト切り替えのオーバーヘッドの増加だけです。

カーネルパッチが広く配布されるまで、GOMAXPROCS =＃を設定することはgoプログラムの良い回避策であると言っておくべきでした。

本番クラスターをパッチを適用したカーネルに移行しました。興味深い瞬間をいくつか紹介します。
クラスターの1つからの統計-72コアE5-2695v4 @ 2.10GHz、128Gb RAM、Debian 9、5.2.7カーネルの4ノードとパッチ。
混合ロードは主にgolangサービスで構成されていますが、phpとpythonもあります。

ゴラン。 レイテンシーは低く、正しいGOMAXPROCSを設定することは絶対に必要です。 これがデフォルトのGOMAXPROCS = 72のサービスです。 カーネルを約16で変更し、その後、レイテンシーが低下し、CPU使用率が大幅に上昇しました。 21:15に、正しいGOMAXPROCSとCPU使用率を正規化して設定しました。

Python。 余分な動きをせずにパッチを適用すると、すべてが改善されました。CPU使用率と遅延が減少しました。

PHP。 CPU使用率は同じで、一部のサービスではレイテンシーがほとんど低下していません。 大きな利益ではありません。

@zigmundに感謝します。
あなたがI setted correct GOMAXPROCSと言ったときに私がそれを得るかどうかはわかりません...
72コアノードでポッドを1つだけ実行しているわけではないので、 GOMAXPROCSをポッドのCPU制限と同じくらい低い値に設定しますか？

@zigmundに感謝します。 外出先の変更は、予想されたものとほぼ一致しています。

GILがこれの利点を大幅に打ち消すと思っていたので、Pythonの改善には本当に驚いています。 どちらかといえば、このパッチはほぼ純粋に応答時間を短縮し、抑制された期間の割合を減らし、CPU使用率を向上させるはずです。 あなたのPythonアプリケーションはまだ健全でしたか？

@ prune998申し訳ありませんが、スペルミスの可能性があります。 GOMAXPROCS = limits.cpuを設定しました。 現在、このクラスターにはノードあたり約110個のポッドがあります。

@chiluk私はPythonが

@chilukさまざまなLinuxディストリビューションへのパッチの進行状況を追跡する方法を説明していただけますか？ 私は特にdebianとAWSLinuxに興味がありますが、他の人もUbuntuなどに興味を持っていると思いますので、どんな光を当ててもよろしくお願いします。

@Nuru https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?highlight=stable%20rules ...基本的に、パッチが「Linus」にヒットしたら、linux-stableを介して送信し

@chilukLinuxの開発プロセスについては何も知りません。 「Linus'tree」とは、 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が安定していると感じるときはいつでも、誰の推測でもあります。

@chilukLinusが2019年9月15日に5.3が安定していると判断したようです。 では、「linux-next」とは何ですか。次のステップでパッチの進行状況をどのように追跡しますか？

このパッチを含むDebianストレッチパッケージや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

スケジューラのメンテナからの言葉は次のとおりです。AckGregHKは、安定したツリーに入れるために探していましたか？

Greg KHは、スケジューラのメンテナが応答しなくなったため（おそらくメールを見逃しただけ）、このパッチに関する決定を延期しました。 このパッチをテストし、バックポートする必要があると考えているLKMLに関する私以外の人からのコメントをいただければ幸いです。

CoreOSを使用している人には、 @ chilukのパッチのバックポートを要求する問題があります。

CoreOSカーネル4.19.82には修正があります： https ：
CoreOS Container Linux 2317.0.1（アルファチャネル）には修正があります： https ： http://coreos.com/releases/#2317.0.1

Linux安定版へのバックポートは、パッチが正しくているように見えます。 @chiluk Linux安定版のバックポートに取り組むつもりですか？ もしそうなら、それがDebianの「ストレッチ」に入り、 kopsによってピックアップされるように、4.9にバックポートしてください。 「ストレッチ」に入るのに6か月もかかると思いますが、それまでにkopsは「バスター」に移行するでしょう。

@Nuru 、私はパッチをバックポートし、ストレッチパッケージ（stretch-backportsカーネルに基づく）と、テストしたい場合はkops1.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」はLinux4.9に基づいていますが、すべてのリンクは4.19用です。
• 「パッチ」をバックポートしたとおっしゃっていますが、3つのパッチがあります（3つ目はそれほど重要ではないと思います。
  
  
  
  1. 512ac999 sched / fair：帯域幅タイマーのクロックドリフト状態を修正
  
  
  2. de53fd7ae sched / fair：cpu-localスライスの有効期限を削除することにより、高いスロットリングで低いCPU使用率を修正
  
  
  3. 763a9ec06 sched / fair：-Wunused-but-set-variable警告を修正
  
  

3つのパッチすべてを4.9にバックポートしましたか？ （変更がそこにあるかどうかを確認するためにDebianパッケージをどうすればよいかわかりません。また、「変更」ドキュメントでは実際に何が変更されたかについては触れていません。）

また、AMIはどの地域で利用できますか？

いいえ、ストレッチバックポートカーネル（4.19）を使用しました。これは、AWSでも必要な修正が含まれているためです（特にM5 / C5インスタンスタイプの場合）。

私は信じるすべてのパッチを組み込んだ差分を適用しました。他の場所で削除された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が私たちに公開されました-west-1

お役に立てば幸いです。

これらのパッチをバックポートし、Linuxで安定したカーネルに送信しました
v4.14 https://lore.kernel.org/stable/[email protected]/
v4.19 https://lore.kernel.org/stable/[email protected]/ #t

こんにちは、
4.19ブランチにパッチを統合した後、バスターとストレッチバックポートのカーナーを適切にアップグレードするためのdebianに関するバグレポートを開きました。

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

debianパッケージのアップグレードについて新しいコメントを追加することを躊躇しないでください。

これがあまりスパムではないことを願っていますが、 @ chilukからのこのすばらしい講演を、この問題に関連する多くの背景の詳細​​にリンクしたいと思いましたhttps://youtu.be/UE7QX98-kO0。

GKEのスロットルを回避する方法はありますか？ phpコンテナの1つのメソッドが通常の0.1秒ではなく120秒かかるという大きな問題が発生しました

CPU制限を削除します

すでに行ったように、CPU要求が小さすぎると、コンテナーが抑制されます。 それが問題の核心であり、制限がなく、CPU要求のみを使用すると、スロットルが発生します:(

@bartoszhernasここで間違った単語を使用していると思います。 このスレッドの人々が「スロットル」を参照するとき、彼らはcfs帯域幅制御を参照し、cgroupの増加のためにcpu.statでnr_throttledを参照します。 これは、CPU制限が有効になっている場合にのみ有効になります。 GKEがあなたの知らないうちにあなたのポッドに制限を追加していない限り、私はあなたが打っているものをスロットルとは呼びません。

あなたが説明したことを「プロセッサの競合」と呼びます。 おそらく、サイズが正しくないアプリケーション*（リクエスト）が複数あると思われます。これらのアプリケーションは、リクエストしたものよりも多く使用しているため、ボックス上のプロセッサやその他のリソースをめぐって競合しています。 これが、制限を使用する正確な理由です。 そのため、これらの不適切なサイズのアプリケーションは、ボックス上の他のアプリケーションにのみ影響を与える可能性があります。

もう1つの可能性は、要求量が不十分なためにスケジューリング動作が不十分になる可能性があります。 要求を低く設定することは、より高い「要求」アプリケーションに対して正の「適切な」値を設定することに似ています。 その詳細については、ソフト制限を確認してください。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

私の理解では、カーネルの根本的な問題が修正され、 https：//github.com/coreos/bugs/issues/2623のContainerLinuxなどで利用できるようになりました
このカーネルパッチの後に残っている問題を知っている人はいますか？

@sfudeus Kubernetesは、Linuxの任意のフレーバー、またはAFAIK、UnixのPOSIT準拠のフレーバーで実行できます。 このバグは、Linuxを使用していない人にとっては問題ではなく、一部のLinux派生ディストリビューションでは修正されており、他のディストリビューションでは修正されていません。

根本的な問題はLinuxカーネル5.4で修正されましたが、現時点ではほとんど誰も使用していません。 パッチは、さまざまな古いカーネルへのバックポートに利用できるようになり、まだ5.4カーネルに移行する準備ができていない新しいLinuxディストリビューションに含まれています。 この問題を参照している上記のコミットのリストからわかるように、バグ修正パッチは、誰かがKubernetesを使用している可能性のある無数のLinuxディストリビューションに組み込まれる過程にあります。

したがって、アクティブなコミット参照がまだ表示されている間、この問題を開いたままにしておきたいと思います。 また、Kubernetesのインストールが影響を受けるかどうかを判断するために、誰かが使用できるスクリプトまたはその他の簡単な方法で閉じてもらいたいと思います。

@Nuru Fine私にとっては、他のカーネルの問題が残っていないことを確認したかっただけです。これはすでにわかっています。 私は個人的に、修正を組み込んだ大規模なディストリビューションよりも長くこれを開いたままにしないでしょう。無限のIoTデバイスを待つことは、無限に待つことを意味する可能性があります。 クローズされた問題も見つけることができます。 しかし、それは私の2セントだけです。

これが人々に知らせるための正しい場所であるかどうかはわかりませんが、これをどこに持ち出すかは本当にわかりません。

k8s1.15.10クラスターを使用してDebianBusterで5.4Linuxカーネルを（buster-backportsカーネルを使用して）実行していますが、これにはまだ問題があります。 特に、通常はほとんど実行する必要がなく（kube-downscalerは、通常、約3mのCPUを必要とする例です）、割り当てられているcpuリソースが非常に少ないポッド（kube-downscalerの場合は50m）の場合は特にそうです。クラスター）まだ非常に高いスロットル値が表示されます。 参考までに、kube-downscalerは基本的にPythonスクリプトであり、 sleepを30分間実行してから何かを実行します。 cAdvisorは、このコンテナーのcontainer_cpu_cfs_throttled_periods_totalの増加が、このコンテナーのcontainer_cpu_cfs_periods_total値と常にほぼ同じであることを示しています（5m間隔で増加を確認すると両方とも約250です）。 抑制された期間は0に近いと予想されます。

これを間違って測定していますか？ cAdvisorは誤ったデータを出力していますか？ 抑制された期間の低下が見られるはずであるという私たちの仮定は正しいですか？ ここでアドバイスをいただければ幸いです。

5.4カーネルに切り替えた後、この問題のあるポッドの数が少し（約40％）減少するのがわかりましたが、現在、実際の問題であるかどうかはわかりません。 主に、上記の統計を見ると、3mの平均CPU使用率でこれらの値を取得した場合、ここで「スロットリング」が実際に何を意味するのかわかりません。 実行中のノードはオーバーコミットされておらず、平均CPU使用率は10％未満です。

@timstoopスケジューラーが気にする間隔は、30分の大きな範囲ではなく、マイクロ秒の領域にあります。 コンテナーのCPU制限が50ミリクプで、100マイクロ秒のスパンで50ミリクプを使用する場合、30分間アイドル状態であるかどうかに関係なく、コンテナーはスロットルされます。 一般に、50ミリクプは非常に小さいCPU制限です。 Pythonプログラムがその下限値で単一のHTTPS要求を行った場合でも、抑制されることはほぼ確実です。

実行中のノードはオーバーコミットされておらず、平均CPU使用率は10％未満です。

明確にするために、ノードの負荷とノード上の他のワークロードは、スロットルとは何の関係もありません。 スロットリングは、コンテナー/ cgroup自体の制限のみを考慮しています。

@PaulFurtadoご回答ありがとうございます！ ただし、ポッド自体は、そのスリープ中の平均使用量が3m cpuであり、まだ抑制されています。 その間、リクエストは行われず、スリープを待機しています。 50mに当たらずにできるといいですね。 それとも、それはとにかく間違った仮定ですか？

これは非常に少ない数である可能性が高いため、精度の問題が発生する可能性があります。 そして、50mは非常に低いので、何でもつまずく可能性があります。 Pythonのランタイムは、スリープ中にスレッドでバックグラウンドタスクを実行している場合もあります。

あなたは正しかった、私は真実ではない仮定をしていました。 ご指導ありがとうございます！ 今は理にかなっています。

カーネルパッチが4.19LTSカーネルにヒットしてから、ここにあるものが大幅に改善され、CoreOS / Flatcarに表示されたと言いたかっただけです。 現時点を見ると、抑制されているのは、おそらく制限を引き上げるべきいくつかのことだけです。 ：スマイル：

@sfudeus @chilukカーネルでこれが修正されているかどうかを確認する簡単なテストはありますか？

kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17（現在の公式kopsイメージ）にパッチが適用されているかどうかはわかりません。

@mariusgrigoriuに同意します。静的CPUポリシーの下で排他的CPUセットで実行されるポッドの

@Nuru私はhttps://github.com/indeedeng/fibtestを書きました
それはあなたが得ることができるのとほぼ同じくらい決定的なテストですが、あなたはCコンパイラを必要とするでしょう。

完了した反復回数は無視しますが、シングルスレッド実行とマルチスレッド実行に使用される時間に焦点を合わせます。

どのカーネルにパッチが適用されているかを確認する良い方法は、 @ chilukの最後のスライドの1つにあると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％が抑制されているのがわかりますが、この値は予想されるほど低く、受け入れることができますか？ ゼロまで下げてほしいのですが、使用量が制限に近づいていない場合は、まったく抑制されるべきではありません。

新しいパッチを適用したカーネルを使用している人は、まだスロットルが残っていますか？

@ 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が適切に機能している場合、書き込み時間は常に5ミリ秒になります。 上記の数値を使用してテストした影響を受けるカーネルでは、99msの書き込み時間が頻繁に見られます。 6msを超えるものはすべて問題です。

@nuru問題が存在するかどうかを見つけるためのスクリプトに感謝します。

@justinsbデフォルトのkopsイメージにパッチがあるかどうかを提案してください
https://github.com/kubernetes/kops/blob/master/channels/stable

問題を開きました： https ：

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

更新：kops 1.15イメージでテストを実行しましたが、不要なスロットリングがありますhttps://github.com/kubernetes/kops/issues/8954#issuecomment -617673755

@Nuru

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

これは、ubuntu18.04のデフォルトの最新の安定したubuntuカーネルです。

だから、パッチがあるようです。

@zerkms Ubuntu 18.04でテストをどこで実行しましたか？ パッチがAzureのカーネルにしか組み込まれていないように見えます。 Ubuntu linuxパッケージのどこに適用されたかを示すリリースノートを見つけたら、共有してください。 見つかりません。

このテストでは、CoreOSでも問題を再現できなかったことにも注意してください。 デフォルト設定では、CFSスケジューリングがグローバルに無効になっている可能性があります。

@Nuru

Ubuntu 18.04のどこでテストを実行しましたか？

私のサーバーの1つ。

私はリリースノートをチェックしませんでした、何を探すべきかさえわかりません、そしてそれにもかかわらず、それは誰もが持っているようなデフォルトのカーネルです。 🤷

パッチはここubuntusカーネルgitにあるはずです：
https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?id=aadd794e744086fb50cdc752d54044fbc14d4adb

そしてここにそれに関するubuntuのバグ：
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で修正されました。

また、 Ubuntu18.04.4リリースノートに記載されている「1832151」も表示されません。

以前のコメントでは、4.15.0-67.76でパッチが適用されてlinux-image-4.15.0-67-genericパッケージが表示されません。

私はUbuntuの専門家から遠く離れており、このパッチの追跡は容認できないほど難しいと感じているので、私が見た限りではそうです。

このパッチが18.04の現在のバージョンであるUbuntu18.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で同じ実行を行うと、5ミリ秒以上の書き込みが発生することがわかります。

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スロットリングがまだ表示されることです

@ヌルそう、ごめんなさい。 それは、オフィスでホストされている私のベアメタルサーバーでした。

また、18.04.4が2020年2月12日にリリースされたことも示しています。出力には、2020年4月1日にコンパイルされたv4.15カーネルを実行していることが示されています。

これはサーバーLTSであるためです。新しいカーネルを使用するには、HWEを明示的にオプトインする必要があります。そうしないと、メインラインを実行するだけです。

また、メインラインカーネルとHWEカーネルの両方が定期的にリリースされているため、最近ビルドされたカーネルを使用することに疑いの余地はありません： http ：

@zerkms情報をありがとう。 私は混乱したままですが、これは私を教育する場所ではありません。

@ vgarcia-teカーネルにパッチが適用されている場合は、このバグが原因ではないようです。 あなたが言うとき、私はあなたの用語がわかりません：

リクエストを250mに設定し、500mに制限して、約50msの使用量について話しています。 CPU期間の約50％が抑制されているのがわかりますが、この値は予想されるほど低く、受け入れることができますか？

Kubernetes CPUリソースはCPUで測定され、1は1つのフルCPUの100％を意味し、1mは1つのCPUの0.1％を意味します。 したがって、「500m」の制限は、0.5CPUを許可すると言います。

CFSのデフォルトのスケジューリング期間は100ミリ秒であるため、制限を0.5 CPUに設定すると、プロセスは100ミリ秒ごとに50ミリ秒のCPUに制限されます。 プロセスがそれを超えようとすると、抑制されます。 通常、プロセスが1回のパスで50ミリ秒を超えて実行される場合は、そうです。適切に機能するスケジューラーによってプロセスが抑制されることが期待されます。

@Nuruは理にかなっていますが、デフォルトのCPU期間が100ミリ秒を
これは、デフォルトのCPU期間が100ミリ秒であるLinuxで、1回のパスで100ミリ秒を超えて実行される制限があるプロセスが抑制されることを意味しますか？

1回のパスで100ミリ秒以上かかるが、残りの時間はアイドル状態であるプロセスの適切な制限構成は何でしょうか。

@ vgarcia-teが尋ねた

デフォルトのCPU期間が100ミリ秒であるとすると、プロセスに1つのCPUが割り当てられた場合、そのプロセスが1回のパスで100ミリ秒を超えて実行されると、スロットルされますか？

もちろん、スケジューリングはめちゃくちゃ複雑なので、完璧な答えを出すことはできませんが、単純化された答えはノーです。 より詳細な説明はこことここにあり

すべてのUNIXプロセスは、タイムスライスに基づくプリエンプティブスケジューリングの対象となります。 シングルコアシングルCPUの時代に戻ると、30個のプロセスが「同時に」実行されていました。 何が起こるかというと、彼らはしばらく走り、眠るか、タイムスライスの終わりに、何か他のものが走れるように保留にされます。

クォータ付きのCFSは、それをさらに一歩進めます。

ただし、プロセスでCPUの50％を使用する必要があると言った場合、実際には何を言っているのでしょうか。 次の5分間、CPUがまったく動作しない限り、CPUを100％占有して5分間は問題ないと言っていますか？ これは10分間で50％の使用量になりますが、遅延の問題があるため、ほとんどの人には受け入れられません。

したがって、CFSは、クォータを適用する時間枠である「CPU期間」を定義します。 4コアでCPU周期が100ミリ秒のマシンでは、スケジューラーには400ミリ秒のCPU時間があり、100ミリ秒を超える実時間（実時間）を割り当てます。 並列化できない単一の実行スレッドを実行している場合、そのスレッドは1期間あたり最大100ミリ秒のCPU時間を使用できます。これは、1 CPUの100％になります。 クォータを1CPUに設定した場合、スロットルされることはありません。

クォータを500m（0.5 CPU）に設定すると、プロセスは100msごとに50msを実行します。 100ミリ秒の期間は50ミリ秒未満の使用であり、スロットルされるべきではありません。 Ayn 100ms期間は、50msを実行した後は終了せず、次の100ms期間までスロットルされます。 これにより、レイテンシー（実行できるようになるまで待機する必要がある時間）とホギング（他のプロセスが実行されないようにするために許可される時間）のバランスが維持されます。

@Nuru私のスライドは正しいです。 私はUbuntu開発者でもあります*（今は暇なときだけです）。 最善の策は、ソースを読み、git blame + tag --containsをチェックして、パッチが関心のあるカーネルのバージョンに到達したときを追跡することです。

@chiluk私はあなたのスライドを見ていませんでした。 それらを見たことがない他の人のために、ここに彼らがパッチがしばらく前に着陸したと言うところです：

• Ubuntu 4.15.0-67 +
• Ubuntu 5.3.0-24 +
• RHEL7カーネル3.10.0-1062.8.1.el7
  そしてもちろん、Linuxの安定版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バスター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で説明されているテストに失敗するはずですが、そうではありません。 （Linuxカーネル4.10から段階的にアップグレードされ、変更ログにそのパッチについての言及がないため、 512ac999はないと思います。）ただし、4 cpu AWSVMでは失敗しません。 ChilukのfibtestまたはBobrikのCFSヒカップテストは、何か他のことが起こっていることを示唆しています。

Chilukのパッチを受け取る前でも、CoreOSのスケジューリングの問題を再現するのに同様の問題がありました。

現時点での私の考えでは、Bobrikのテストは主に51f2176d74acのテストであり、私が使用しているDebianバスター10 AMIには512ac999があり、変更ログで明示的に呼び出されていません。 fibtestは、コアが数個しかないマシンでの感度の高いテストではありません。

4コアCPUは、修正された問題を再現するのに十分な大きさではない可能性があります。

chiluks kubeconトーク（https://www.youtube.com/watch?v=UE7QX98-kO0）の説明を正しく理解していれば、40CPU以上の大型マシンでのみ再現できるはずです。

周りにはたくさんのカーネルバージョンがあり、パッチのパッチ適用と元に戻すことがたくさん行われています。 変更ログとバージョン番号は、これまでのところしか得られません。
疑問がある場合の唯一の信頼できる方法は、ソースコードをダウンロードして、ここにリンクされているパッチの変更と比較することです。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

このスレッドで前述したテストでは、問題を実際に再現することはできません（5ミリ秒以上かかるが、0.01％程度です）が、cfsスロットリングメトリックは、中程度のスロットリングを示しています。 クラスタ間でカーネルバージョンは異なりますが、最も一般的な2つのバージョンは次のとおりです。

• Debian 4.19.67-2+deb10u2~bpo9+1 (2019-11-12)
• 5.4.38手動バックポート

これらのバージョンで両方のバグが修正されるかどうかはわかりませんが、修正されるはずだと思うので、テストはそれほど役に立たないのではないかと思います。 16コアと36コアのマシンでテストしていますが、テストを有効にするためにさらに多くのコアが必要かどうかはわかりませんが、これらのクラスターでスロットルが発生していることがわかります...

この問題を閉じて、問題に直面している人々に新しい問題を開始するように依頼する必要がありますか？ ここでのスパムは、会話を非常に困難にする可能性があります。

^同意します。 これを解決するために多くのことが行われてきました。

/閉じる

上記のコメントに基づいています。 必要に応じて新しい号を開いてください。

@dims ：この問題を解決します。

この問題のフォローアップの問題を通知してください。そうすれば、問題をサブスクライブした人は、フォローする新しい問題をサブスクライブできます。