Presto内存管理原理和调优

内存池

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

1
2
3
4
5
6
7
8
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
-XX:G1ReservePercent=15
-XX:InitiatingHeapOccupancyPercent=40
-XX:ConcGCThreads=8

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