help request: 内存持续增涨OOM

[pguokun]

Current Behavior

环境

服务器配置：阿里云(8核 32G) 操作系统：CentOS 7.9

问题现象：内存持续涨

apisix自定义配置

http_configuration_snippet配置： client_header_buffer_size 4k; client_body_buffer_size 512k; large_client_header_buffers 4 32k; sendfile on; tcp_nopush on; tcp_nodelay on; proxy_connect_timeout 300; proxy_read_timeout 300; proxy_send_timeout 300; proxy_buffer_size 32k; proxy_buffers 4 16k; proxy_busy_buffers_size 32k; proxy_temp_file_write_size 32k; 其他配置都是开源版本默认

插件使用

kafka-logger prometheus zipkin

Expected Behavior

No response

Error Logs

No response

Steps to Reproduce

1、阿里云-容器服务 ACK helm安装 2、apisix日志推送到kafka

Environment

• APISIX version (run apisix version): 2.12.1
• Operating system (run uname -a): Linux apisix-6d7cd4c778-28jgx 3.10.0-1160.15.2.el7.x86_64
• OpenResty / Nginx version (run openresty -V or nginx -V): openresty/1.19.9.1
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info): 无
• APISIX Dashboard version, if relevant: 2.10.1
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[kwanhur]

If ok, suggest you disable all the plugins to eliminate their effects. Then enable plugin one by one.

[tzssangglass]

Is the memory performance of instance 29zhg normal? Is there any difference?

[tokers]

@pguokun What about other metrics like QPS, CPU?

[jagerzhang]

@pguokun 我在腾讯云TKE（K8S）也发现有这个问题，内存增长趋于线性，内存缓缓增长到预设HPA之后会触发HPA弹性扩容，然后会一直扩再也不会缩回来了，得销毁重建才会回到最开始状态。

我们这边用的插件如下：

全局插件：

• request-id
• resonset-rewrite
• kafka-logger

路由插件：

• proxy-rewrite （5%）
• consumer-restriction （70%）
• hmac（70%）
• limit-count (70%)

以下是2C2G的Pod配置，之前用的1C1G跑半个月就会触发HPA扩容了。

不太清楚这里面有没有GC机制，如果有GC，GC的触发条件是不是内存占用到一定程度时才触发？而运行在容器里面，程序看到的内存其实是宿主机的内存，而非容器limit内存，会导致永远不可能触发GC呢？目前Python3.7及以下版本就有这个问题，看到的是宿主机的资源，导致GC不会被主动执行。

以上，仅供参考哈~

[spacewander]

LuaJIT manages the GC total count in the GCState.total field, so it won't depend on the host's memory info.

[jagerzhang]

LuaJIT manages the GC total count in the GCState.total field, so it won't depend on the host's memory info.

got it.

[GhangZh]

I have the same problem, deployed on k8s with 64G memory setting. i set client_body_buffer_size to 10240M. pressure test 20Gb traffic scenario is uploading large files and it will OOM. if i remove client_body_buffer_size configuration, disk io will be very high. I also tried to write client_body_temp_path to /dev/shm and it would also OOM.

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    client_header_buffer_size 16m;
    large_client_header_buffers 4 16m;
    client_body_buffer_size 10240m;
    client_max_body_size 10240m;
    proxy_buffering off;
    proxy_buffers 4 32k;
    proxy_buffer_size 32k;
    proxy_connect_timeout 30s;
    proxy_send_timeout   600s;
    proxy_read_timeout   600s;
    proxy_cache off;
    proxy_request_buffering off;
    client_body_temp_path /dev/shm;

But with traefik memory set to 8G there is no OOM problem either

[tokers]

Memory allocated by client_boy_buffer_size is not managed by LuaJIT. It will be recycled after the request finalizing.

[spacewander]

client_body_buffer_size 10240m

This buffer is preallocated per request. If you want to reduce disk io, you can configure to avoid request buffering via https://apisix.apache.org/docs/apisix/plugins/proxy-control

[tincopper]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。

解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

[jagerzhang]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。

解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

[chenglin321]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。 解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

这个问题，有解决吗？

[tokers]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。 解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

这个问题，有解决吗？

This may be due to the in-memory logs save.

[chenglin321]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。 解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

这个问题，有解决吗？

This may be due to the in-memory logs save.

谢谢，这个有对应诊断分析的工具不，我先自己诊断下？

[tincopper]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。 解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

这个问题，有解决吗？

This may be due to the in-memory logs save.

目前发现kafka-logger这个插件在我们环境中总是会断连，而且不会重连，导致一些日志积压在内存当中。感觉像是从lru当中获取的producer已经是断连了，想要添加重连逻辑的，但是没有发现有检测连接是否正常的api。现在处理是把从lru获取client对象改成直接从新获取producer，但是之前buffer的日志会发送失败。

[chenglin321]

我们也发现了这个问题，之前以为是代码的问题，但是发现nginx进程实际占用的内存是非常小的，后面排查是因为写日志文件accesss.log/error.log过大，然后导致page cache会很大，因为k8s的内存统计是包括rss + buffer/cache的。 在执行执行echo "" > access.log之后发现内存是直线下降的。不知道这个问题是不是也是这个原因导致的。 解决办法：目前是通过log-rotate插件进行日志的滚动切割定期删除历史文件。

我们这边没有开文件日志，用的kafka-logger插件，也有泄漏问题。

这个问题，有解决吗？

This may be due to the in-memory logs save.

目前发现kafka-logger这个插件在我们环境中总是会断连，而且不会重连，导致一些日志积压在内存当中。感觉像是从lru当中获取的producer已经是断连了，想要添加重连逻辑的，但是没有发现有检测连接是否正常的api。现在处理是把从lru获取client对象改成直接从新获取producer，但是之前buffer的日志会发送失败。

好的,谢谢。那我们还不一样。我这边是写一个自定义java插件,java插件的内存占用还好，openresty的内存不断增长，线上每两天realod下apisix。 - -

[github-actions[bot]]

This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.

[kqkdChen]

Did you finally find the cause and solution?