Elasticsearch容器化后pod出现throttle的情况

现象

ES节点的pod跑了一段时间就偶尔会出现一次cpu throttle。

进而触发写入、查询队列的堆积，然后出现一些请求reject的情况。

图中可以看出来throttle的时间是25s，由于采集是1min一次，即1min内累计了 25s 的时间是被throttle的。

CPU限流（throttle）

k8s使用CFS（Completely Fair Scheduler，完全公平调度）限制负载的CPU使用率：

• CPU使用量的计量周期为100ms，100ms作为一个时间片；
• CPU limit决定每计量周期（100ms）内容器可以使用的CPU时间的上限；例如分配了1cpu，即当前周期（100ms）内，线程总共允许消耗100ms；以此类推，0.2 CPU = 20ms CPU时间每计量周期，2.5 CPU = 250ms CPU时间每计量周期；
• 24 CPU = 2400ms CPU时间每计量周期，当前周期（100ms）允许2400ms的CPU时间被消耗。
• 如果程序用了多个核，CPU时间会累加统计。（上面描述的 2400ms，指所有线程在周期内可消耗的累积值，重叠/并行的部分都需要叠加计算）
• 本周期内若容器的CPU时间用量达到上限，CPU限流开始，容器只能在下个周期继续执行；

分析

1.监控图粒度较大，1min采集1次，累计throttle时间25s，如果并发请求在100ms（周期）的开始就拿到了大量的时间，那后续时间就只能被阻塞。

2.并行（非并发）的请求如果占满了核心数，其余线程只能等待，一般不会出现，一般API主要是IO密集型。在一个周期内如果时间被消耗完，那所有线程都要阻塞，等到下一个周期开始执行。

3.容器环境io相互影响导致的wait，可能导致cpu消耗的情况

4.ES是个java程序，会有jit、gc，这两个都十分消耗CPU

结论

1.ES大部分请求还是IO密集型，磁盘推荐使用SSD。

2.核心应用尽量不做超分。

3.核心应用给足够的内存，防止频繁GC、频繁缺页中断。

4.throttle的问题几乎无法彻底解决，只能尽可能调优。根据业务请求的并发来调整cpu limit（或request）