我在Kubernetes集群(k8s v1.18.12,运行4.9.0-11-amd 64 #1 SMP Debian 4.9.189-3+ deb 9 u2(2019-11-11)x86_64 GNU/Linux)中遇到了很多CPU节流问题(参见下面的nginx图表,其他pod通常为25%到50%)。
由于backports的原因,我不知道我的集群是否包含https://lkml.org/lkml/2019/5/17/581中描述的Linux内核bug。我该如何查找?有简单的方法来检查或测量吗?
如果我有错误,修复的最佳方法是什么?或者我应该采取其他缓解措施,例如不使用CFS配额(--cpu-cfs-quota=false
或无CPU限制)或减少cfs_period_us
和cfs_quota_us
?
nginx的CPU节流百分比(水平缩放约15:00,移除约19:30的CPU限制):
3条答案
按热度按时间ee7vknir1#
由于修复程序被后移植到许多旧的内核版本,我不知道如何轻松地查找是否有修复程序,例如
4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
。但是,您可以测量CFS是工作顺畅还是限制过多,如https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1中所述:
1.您可以运行给定的
cfs.go
,并为其睡眠和迭代设置合适的设置,以及CFS设置,例如docker run --rm -it --cpu-quota 20000 --cpu-period 100000 -v $(pwd):$(pwd) -w $(pwd) golang:1.9.2 go run cfs.go -iterations 100 -sleep 1000ms
1.检查是否所有
burn
都花费了5ms。如果不是,则CFS限制过多。这可能是由于原始错误198197(请参阅https://bugzilla.kernel.org/show_bug.cgi?id=198197)或错误198197修复程序引入的回归(详细信息请参阅https://lkml.org/lkml/2019/5/17/581)。https://github.com/kubernetes/kops/issues/8954中也采用了这种测量方法,表明Linux内核
4.9.0-11-amd64
的节流太多(然而,使用比Debian 4.9.189-3+deb9u2 (2019-11-11)
更早的Debian4.9.189-3+deb9u1 (2019-09-20)
)。kxeu7u2r2#
Recently, I'm working on debuging the cpu throttling issue, with the following 5 tests, I've tested out the bug in kernel (Linux version 4.18.0-041800rc4-generic)
This test case is intended to hit 100% throttling for the test 5000ms / 100 ms periods = 50 periods. A kernel without this bug should be able to have a CPU usage stats about 500ms.
Maybe you can try these tests to check whether your kernel will be throttlled.
[Multi Thread Test 1]
[Result]
[Multi Thread Test 2]
[Result]
[Multi Thread Test 3]
Result
For the following kubernetes test, we can use "kubectl logs pod-name" to get the result once the job is done
[Multi Thread Test 4]
Result
[Multi Thread Test 5]
Result
fnatzsnv3#
CFS错误已在Linux 5.4中修复,执行
kubectl describe nodes | grep Kernel
或转到任何Kubernetes节点,执行uname -sr
将告诉您正在运行的内核版本。