LWN: facebook怎样利用CPU资源的同时不影响web server的响应?

LWN: facebook怎样利用CPU资源的同时不影响web server的响应? -1
点击上方蓝色字关注我们~



introduce cpu.headroom knob to cpu controller

From Song Liu<songliubraving-AT-fb.com>

Date: Mon, 8 Apr 2019 14:45:32 -0700

https://lwn.net/Articles/785302/


Facebook的Song Liu提出一组patch,试图尽量利用CPU的计算能力,同时不影响主要任务的latency。


Facebook的server上,经常有一个交互式的任务(后续称为主要任务)占据了CPU的主要计算资源。通常CPU还有剩余计算能力,因此facebook团队希望在这些CPU上也执行一些video encoding等次要任务。目标是希望尽量利用足CPU的同时,不要影响主要任务的执行。可是实测下来发现主要任务的latency受到很大影响


 side-job   main-load-level   main-avg-latency

     none          1.0              1.00
    none          1.1              1.10
    none          1.2              1.10
    none          1.3              1.10
    none          1.4              1.15
    none          1.5              1.24
    none          1.6              1.74

    ffmpeg        1.0              1.82
    ffmpeg        1.1              2.74

Note: both the main-load-level and the main-avg-latency numbers are
_normalized_.


这些测试里面,ffmpeg已经是放进一个cpu.weight=1的cgroup里面执行了,也就是已经给它最低priority了,实测下来ffmpeg会把CPU的idle时间全部吃光。而更多的试验表明,只要CPU的idle时间全部被吃光的话,哪怕主要任务的priority再高,latency也会大幅度增加。这里有各种原因:CPU的占用率达到100%之前其实一些其他共享资源已经饱和了;并且schedule导致的latency会在CPU满负荷之后开始拖慢主要任务的执行。


目前系统里面已有的cpu.weight和cpu.max能控制次要任务的占用资源,但是都有局限。上面已经说过了cpu.weight哪怕给次要任务设成1(最低优先级)仍然会占满CPU。而是用cpu.max来限制的话,虽然确实能限制住次要任务所能占用的最大CPU利用率,可是这个值无法跟当时系统整体的workload关联。举例来说,cpu.max设成30%的话,无论主要任务占用了1%还是99%的CPU,次要任务都被允许30%的CPU比例,也就是说仍然有可能CPU 100%忙于执行,从而没有idle时间。


因此facebook提出增加一个cpu.headroom的sysctl设置。用来对次要任务设置它运行起来后CPU需要保留多少idle比例。


例如下面这个例子:

main/cpu.headroom    main-cpu-load    low-pri-cpu-cycle   idle-cpu
     30%                 30%                40%              30%
     30%                 40%                30%              30%
     30%                 50%                20%              30%
     30%                 60%                10%              30%
     30%                 70%                minimal          ~30%
     30%                 80%                minimal          ~20%



以上可见,主要任务的CPU占用率不受影响,而如果系统空闲时间太少的话,次要任务就减少自己的执行时间,总之保证了系统有30%的空闲(除非主要任务已经占了超过70%)。


实测中,使用web server作为主要任务,ffmpeg作为次要任务,facebook测出了相关的latency影响。下表中列出了4种不同组合下的实测latency。其中w/ side是指带上次要任务,w/o-side就是指不带次要任务。


LWN: facebook怎样利用CPU资源的同时不影响web server的响应? -2


测试结果表明,增加次要任务后latency也随着main load level递增(甚至会太大,完全不值得测,表中留了空白),而保留30%的headroom或者20%的headroom之后,latency保持在比较合理的范围。


修改的文件如下:


Thanks!

Song Liu (7):
sched: refactor tg_set_cfs_bandwidth()
cgroup: introduce hook css_has_tasks_changed
cgroup: introduce cgroup_parse_percentage
sched, cgroup: add entry cpu.headroom
sched/fair: global idleness counter for cpu.headroom
sched/fair: throttle task runtime based on cpu.headroom
Documentation: cgroup-v2: add information for cpu.headroom

Documentation/admin-guide/cgroup-v2.rst | 18 +
fs/proc/stat.c | 4 +-
include/linux/cgroup-defs.h | 2 +
include/linux/cgroup.h | 1 +
include/linux/kernel_stat.h | 2 +
kernel/cgroup/cgroup.c | 51 +++
kernel/sched/core.c | 425 ++++++++++++++++++++++--
kernel/sched/fair.c | 143 +++++++-
kernel/sched/sched.h | 30 ++
9 files changed, 634 insertions(+), 42 deletions(-)

--
2.17.1


全文完

极度欢迎将文章分享到朋友圈 
热烈欢迎随意转载,只需保留出处~


长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~


LWN: facebook怎样利用CPU资源的同时不影响web server的响应? -3