Trino Worker 规避 OOM 思路

背景

Trino 集群如果不做任何配置优化,按照默认配置上线,Master 和 Worker 节点都很容易发生 OOM。本文从 Trino 内存设计出发, 分析 Trino 内存管理机制,到限制与优化内存分配,使 Worker 节点不易发生 OOM。

Trino 内存类型

Trino(version 400)只有一个内存池,由 Coordinator 来管理这个内存池,即管理集群内存。
Coordinator 协调员一般为集群 Master 节点,Master 节点负责 SQL 解析、分析、优化以及分配查询 Task 给 Worker 节点;Worker 节点负责处理 Task,主要为 load 数据和计算数据,这也是集群内最吃资源的一块。所以我们也是针对这块进行优化处理。

Trino 内存管理机制

Trino 会每 2s 做一次内存分析:

  • 分析当前集群内存是否溢出
    • 当前内存集群内存溢出:Trino 会检查当前集群内存溢出的持续时间,如果持续时间超过了预设值(默认5min),则会根据配置好的 Kill Query策略去 Kill 掉查询。
      • query-low-memory-killer-policy:
        • none :不会杀死任何查询
        • total-reservation :终止当前使用最多总内存的查询。
        • total-reservation-on-blocked-nodes:终止当前在内存不足的节点上使用最多内存的查询
  • 分析当前时刻的所有查询是否超出了预设的内存上限
    • 分析查询是否超出了 query.max-memory-per-node / query.max-memory / query.max-total-memory,超出则 kill 掉
    • 这里 kill 掉查询的动作是有等待时间的。Trino 默认设置是等待5分钟,5分钟后集群依旧是oom状态才会去 kill 掉查询,可以设置 query.low-memory-killer.delay 值来减少等待时间。

以上的内存管理是针对 query 的,不针对 master 节点解析SQL、分析、优化和调度的操作

Trino 资源组限制内存

Trino 资源组也可以限制用户使用内存
主要是通过 softMemoryLimit 限制内存的使用。

官方文档
softMemoryLimit (required): maximum amount of distributed memory this group may use, before new queries become queued. May be specified as an absolute value (i.e. 1GB) or as a percentage (i.e. 10%) of the cluster’s memory.

意思是:在每个查询开始之前,会判断当前用户组使用集群的内存情况,如果超过了设定值,则在队列内等待。直至该用户组使用集群内存降下到预设值。
如:下面配置的意思是,所有的用户都属于admin组,admin组限制了在集群内最高并发50条查询,最长等待队列是300;当admin使用集群内存超过80%时,查询需要在队列中等待。

{
  "rootGroups": [
    {
      "name": "admin",
      "softMemoryLimit": "80%",
      "hardConcurrencyLimit": 50,
      "maxQueued": 300,
    }
  ],
  "selectors": [
    {
      "user": ".*",
      "group": "admin"
    }
  ]
}

优化思路:

  1. 配置每个查询的使用的内存上限
    a. query.low-memory-killer.delay = 4GB
    b. query.max-memory = 8GB
    c. query.max-memory = 8GB
  2. 降低当集群内存不足时, 降低 Trino kill query 的等待时间和 kill 查询的策略
    a. query.low-memory-killer.delay = query.low-memory-killer.delay
    b. query.low-memory-killer.delay = 10s
  3. 配置资源组,避免当集群内存负载高时插入新查询
  4. 开启 spill 选项,允许内存 load 到磁盘

通过以上配置,Trino Worker 就能变得稳定起来。另外可以通过 event listen 机制收集并持久化 query 日志,观察和分析 Trino 压力与瓶颈,从而针对性提升 Trino 的性能。Trino 调优我觉得是很艰难的一件事,我一步步摸索着过来,路漫漫而远兮,吾将上下而求索。