如何解决 Compute 节点上的内存溢出（OOM）问题

本文主要是介绍如何解决 Compute 节点上的内存溢出（OOM）问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

内存溢出（Out-of-memory）是数据处理系统中常见的问题，本文将分析 OOM 的各种原因并提供有效的解决方法。

RisingWave 使用像 AWS S3 这样的共享存储，并将 Compute 节点的内存用作缓存以增强流处理性能。缓存以 Least Recently Used （近期最少使用算法，LRU）的方式运作，即当内存不足时，将删除最少使用的条目。

为了获得最佳性能，建议 Compute 节点的最低内存为 8 GB，但生产环境中建议使用 16 GB 及以上。

本文重点解决 Compute 节点上的 OOM 问题。如果在其他节点上遇到 OOM，请首先升级到最新版本。如果问题仍然存在，请联系我们。

1. OOM 判断方法

Kubernetes 显示 Compute 节点 Pod 由于 OOM Killed (137) 而突然重新启动。

Grafana 指标显示内存无限增长，超出了为 Compute 节点设置的 total_memory 限制。内存设置可以在 Compute 节点的启动日志中找到。搜索关键字“Memory outline"以定位特定部分。

内存溢出判断方法

2. 创建物化视图时的 OOM

如果在创建新的物化视图时发生 OOM，可能是由上游系统（如 Kafka）中存在的大量现有数据引起的。这种情况下，在创建或重新创建物化视图之前，可以通过指定每个并行度的速率限制来减少流量：

CREATE MATERIALIZED VIEW mv WITH ( source_rate_limit = 200 ) AS

参数 source_rate_limit 表示每个并行度在每个源上的每秒最大记录数，其中流作业的默认并行度是集群中所有 CPU 核心的总数。例如，假设一个物化视图有 4 个并行度和 2 个 Source 连接在一起，每个 Source 的吞吐量将被限制为 4 * source_rate_limit 条记录/秒。

或者，您可以使用 risectl 来更改现有物化视图的流速限制，其中 <id> 可以在 RisingWave 看板或 rw_catalog Schema 中找到。

risingwave ctl throttle source/mv <id> <source_rate_limit>

3. 屏障延迟导致的 OOM

屏障在我们的系统中发挥着关键作用，支持内存管理和 LRU 缓存等重要组件的正常运行。

从 Grafana 看板的屏障延迟面板可以观察到屏障延迟，如图所示，延迟曲线异常。

与仅解决内存问题不同，建议关注为何屏障出现问题。可能是由繁重的流作业、输入流量的突然冲击或一些临时问题引起。

以下方法可以帮助解决此问题：

在 Grafana 中，观察片段（actor）之间的背压。两个片段之间的高背压表明下游片段无法足够快地处理数据，从而减慢整个流作业的速度。
在 RisingWave 看板中检查所有 Compute 节点的 Await Tree Dump。如果屏障陷入困境，Await Tree Dump 将显示屏障正在等待特定操作完成。这个片段可能是流作业的瓶颈。

不管是哪种情况，您都可以试着将更多节点添加到集群中，以增加并行度，或检查 SQL 查询语句看看是否有优化的空间。

4. 长时间批量查询时的 OOM

如果在长时间批查询期间发生 OOM，可能是由 Compute 节点上的内存使用过多而引起。在这种情况下，可以通过调整 TOML 文件中的 storage.prefetch_buffer_capacity_mb 参数来减少预取的内存使用。

参数 storage.prefetch_buffer_capacity_mb 定义了预取的最大内存。它通过预读来优化流执行器和批查询性能。此功能允许 hummock（为流计算而生的存储引擎）在单个 I/O 操作中读取更大的数据块，但这样一来，内存成本更高。当预取操作期间的内存使用达到此限制时，hummock 将恢复到原始读取方法，以 64 KB 块处理数据。如果将参数设置为 0，则将禁用此功能。默认情况下，它设置为总机器内存的 7％。