### 资源
可压缩 -> CPU -> 降速
不可压缩 -> 内存 -> 异常终止(OOM kill)
为避免服务中断,用户习惯性申请更多资源,造成资源浪费
autopilot 自动调节资源,提升资源利用率
主要目标,降低申请的资源上限和真实资源使用率之间的差值
Autopilot依据资源利用率的历史数据,依靠AI算法计算
可以将slack(limit-usage)降低到23%,人工调整的均值在46%
### 云用户
为作业声明单个实例的资源需求(limit)和实例数量,但资源limit往往造成麻烦
CPU/内存/实例数量很难测算
- 通常资源请求都是基于压力测试结果设定的,但是实际的资源需求会随时间不断变化,比如昼夜,星期模式
- 同时随着应用变得更流行或更不流行,并发请求也会随时间变化,影响资源占用率
- 随着软件功能变更,软件和硬件的性能优化和升级,资源需求同样不可控
### Recommender基于聚合的资源使用率输入信号
#### 𝑟𝑖[𝜏]
- 原始的,单个Task的CPU/MEM时间序列,1秒解析度
- i代表第i个Task,𝜏代表数据采样时间
- 每1秒一个采样数据
#### 𝑠𝑖[𝑡]
- 汇聚的,单个Task的CPU/MEM的时间序列Histogram,5分钟解析度
- 为降低数据存储量以及计算资源上限时的计算量,原始时间序列通常会被按5分钟汇总
- i代表第i个Task,𝑡代表5分钟的时间窗口,𝜏 属于(∈) 𝑡
- 针对CPU,𝑠𝑖[𝑡]被汇聚成切分成400个bucket的Histogram𝑠𝑖[𝑡][k]
- 针对MEM,𝑠𝑖[𝑡]只记录5分钟时间窗口的内存用量最高值
#### 𝑠[𝑡]
- 一个Job中所有task在5分钟窗口中的资源使用聚合向量,是一个简单的SUM(𝑠𝑖 [𝑡][𝑘])
#### h[𝑡]
- 一个Job的负载调节Histogram
#### 𝑏[𝑘]
- Histogram第k个bin值(bucket的边界值)
### Moving window recommenders
基于汇聚信号s进行数据统计,并计算资源请求上限
我们期望资源Limit快速提升,以快速响应资源利用率上升的场景。
但希望资源Limit慢速降低,以防请求波动时,资源被过快回收
为使针对压力高峰的响应平滑,我们通过指数消亡权重(exponentially-decaying)来处理信号
𝑤[𝜏] = 2^(−𝜏/𝑡1/2)
𝜏采样时间
𝑡1/2half life,权重下降一半的时间
autopilot为long-running job优化,其中CPU的的half life是12小时,MEM的half life是48小时