Presto内存管理原理和调优

内存池

Presto有三种内存池，分别为GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。这三个内存池占用的内存大小是由下面算法进行分配的：

1
2
3
4
5
6
7
8
9
builder.put(RESERVED_POOL, new MemoryPool(RESERVED_POOL, config.getMaxQueryMemoryPerNode()));

builder.put(SYSTEM_POOL, new MemoryPool(SYSTEM_POOL, systemMemoryConfig.getReservedSystemMemory()));

long maxHeap = Runtime.getRuntime().maxMemory();
maxMemory = new DataSize(maxHeap - systemMemoryConfig.getReservedSystemMemory().toBytes(), BYTE);
DataSize generalPoolSize = new DataSize(Math.max(0, maxMemory.toBytes() - config.getMaxQueryMemoryPerNode().toBytes()), BYTE);
builder.put(GENERAL_POOL, new MemoryPool(GENERAL_POOL, generalPoolSize));

梳理这块代码对应的逻辑和配置文件，得出RESERVED_POOL大小由config.properties里的query.max-memory-per-node指定；SYSTEM_POOL由config.properties里的resources.reserved-system-memory指定，如果不指定，默认值为Runtime.getRuntime().maxMemory() * 0.4，即0.4 * Xmx值；而GENERAL_POOL值为 总内存（Xmx值）- 预留的（max-memory-per-node）- 系统的（0.4 * Xmx）。

而这三种内存池分别用于不同的地方，分析代码和阅读Presto开发手册，大体可以定位出：

  • GENERAL_POOL is the memory pool used by the physical operators in a query.
  • SYSTEM_POOL is mostly used by the exchange buffers and readers/writers.
  • RESERVED_POOL is for running a large query when the general pool becomes full.

简单说GENERAL_POOL用于普通查询的physical operators；SYSTEM_POOL用于读写buffer；而RESERVED_POOL比较特殊，大部分时间里是不参与计算的，只有当同时满足如下情形下，才会被使用，然后从所有查询里获取占用内存最大的那个查询，然后将该查询放到 RESERVED_POOL 里执行，同时注意RESERVED_POOL只能用于一个Query。

1、GENERAL_POOL有节点出现阻塞节点（block node）情况，即该node内存不足
2、RESERVED_POOL没有被使用

GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL应配合合理的值，如果并发比较大时，建议SYSTEM_POOL保持默认或者稍微再大一点。目前我的经验配置是SYSTEM_POOL为1/3 * Xmx(虽然我们并发较多，但是依然调低了此值)；RESERVED_POOL 为 1/9 * XMX。

当然你可以通过HTTP请求查看每台Worker的/v1/status，来预估具体需要配置多大的内存，如图所示，显示了各内存池的使用量。

内存限制和管理

单机维度

  • GENERAL_POOL每次内存申请时，都会判断内存使用量是否超过了最大内存，如果超过了就报错，错误为“Query exceeded local memory limit of x”，这保护了Presto会无限申请内存，只会导致当前查询出错。同时，如果该节点的GENERAL_POOL可使用内存以及可回收内存为0，那么认为该node为Block node。

  • RESERVED_POOL可以认为是查询最大的SQL，其能满足GENERAL_POOL的内存限制策略，那么肯定会满足RESERVED_POOL的策略（复用了GENERAL_POOL策略）。

  • RESERVED_POOL目前版本未发现可以限制内存，所以当并发非常高，且scan的数据非常大时，有低概率会引起OOM问题。但是配合Resource Group，内存设置合理，也基本会避免OOM问题。

集群维度

同时满足以下两点时，Presto便认为集群超出要求的内存了：

  • GENERAL_POOL出现阻塞节点（Block node）
  • RESERVED_POOL已经被使用

当判断出集群超出CLuster Memory时，有两种方式管理内存：
1、挨个遍历每个查询，判断当前查询占用的总内存是否超过了query.max-memory（config.properties里配置），如果超过了，那么该查询就被failed。
2、如果query.max-memory配置的不合理，值非常大，那么可能过了5秒（默认时间）依然不满足第一种情形，那么将会使用第二种方法管理查询。第二种管理方法又分为两种小的管理，根据LowMemoryKillerPolicy来决定Kill查询策略，其分为total-reservation和total-reservation-on-blocked-nodes。配置total-reservation的作用是kill掉所有查询里最费内存的查询；而total-reservation-on-blocked-nodes杀死在内存不足（阻塞）的节点上使用最多内存的查询。

Resource Groups

Resource Groups 可以认为是Presto实现了一个弱资源限制和隔离功能。其可以为每个group指定队列大小、并发大小、内存使用大小。为每个group设置合理的hardConcurrencyLimit（最大并发数）、softMemoryLimit（内存最大使用值）及maxQueued（队列大小）一方面可以使不同业务影响降低，另一方面也大概率避免OOM问题，当然善于运用user及做下二次开发，就可以让Presto支持多用户共用同一分组和权限认证功能。

OOM

即使按照上述内存管理做了调优，但Presto依然会遇到OOM问题，此时会显示”INTERNAL_ERROR”，仔细查看错误原因为报类似的错误：

1
Encountered too many errors talking to a worker node. The node may have crashed or be under too much load. This is probably a transient issue, so please retry your query in a few minutes.

如果是这种情形，大概率是JVM OOM了。如果确定了确实是JVM OOM的原因，那么可以参考我们的JVM（G1 GC）调参经验，以下配置添加到jvm.config里会明显避免OOM问题。

1
2
3
4
-XX:G1ReservePercent=15
-XX:InitiatingHeapOccupancyPercent=40
-XX:ConcGCThreads=8

好了，本文简单介绍了下Presto内存管理方面的原理和一些经验，因为Presto相关的技术文章比较少，且关注的用户越来越多，所以我会不定期更新一些Presto相关的技术文章，如果有错误的地方也请及时提醒，有关注Presto的同行也欢迎与我讨论交流。

目录

  1. 1. 内存池
  2. 2. 内存限制和管理
    1. 2.1. 单机维度
    2. 2.2. 集群维度
  3. 3. Resource Groups
  4. 4. OOM