终于找到写的 Node.js 微服务都支持不到 1 天的原因了
终于找到写的 Node.js 微服务都支持不到 1 天的原因了
前情： https://www.v2ex.com/t/392238
从 Python 转过来写了几个 Node 微服务全它妈的跑一天就 Out of memory，之前暂时用了高内存就主动自杀的补丁顶着。
然后这二天查了相关文章，发现 Node 的 gc 和 Python 是完全不同的，Python 的 gc 相当主动（可能和引用计数有关），一有无用内存当场就回收了，而 Node 不会（类似于 Java ）。 默认 64 位机器 Node gc 认为你有 1.4G 内存，到这个点之前 gc 干活相当偷懒，可是我都是跑在 1G 小鸡上的，所以就 BOOM 了。
所以你是在内存小于 1G 的机器上跑比较忙的需长时间运行的程序，需要在 Node 命令行上加上 --max_old_space_size=384 --optimize_for_size 这二参数，我跑了几天内存都没过 400M，而以前没多长时间就超 700M 引起 OOM。
CPython 使用引用计数，没有循环引用的话会立即回收的。JavaScript、Java （以及 Go ）都是经常性地找有没有垃圾，所以会不及时。Python 文档中也有提及，不要依赖对象立即被销毁，因为在其它实现里不一定如此。
不过我也是第一次听说有人使用 NodeJS 遇到 gc 的问题。绝大部分遇到 gc 问题的都是 Go 用户，绝大部分调 gc 参数的都是 Java 用户呀。
根据普遍的反映，Python 在内存方面并不省心。 据说 Python 程序一旦在某个时刻占用了很高的内存，后面就下不来了。而我的多次实践也未能幸免于此，我的 Django 应用不得不启用 max-requests + max-memory 来不断采用新的 worker 来轮回，另一个 flask 应用里面的 celery workers 也不得不根据消费的任务数量来自杀轮回。关于此大神能否谈谈看法？
可以试试关键词 python memory leak not release 看看相关材料。
#20 你可以看看 gc.garbage 里有没有东西。然后试试 tracemalloc 和 objgraph、memory_profilter 之类的工具。我有一些长期工作的 Python 程序，仅有一个偶尔会出现内存泄漏（并且需要数月才能明显观察到）。
我的 Python 程序都是靠自杀+接力来实现长期运行的，搞不搞笑，我觉得很羞辱，曾经拒绝启用这样的参数（比如 gunicorn 或 uwsgi 里面），后来不得不妥协了。
我想要说明的是，不是我写的所有 node 应用都撑不到一天。
二个 HTTP Web 服务可以撑相当长时间（一个月起）。
而另三个队列处理的就不行。不过逻辑和 http server 有点不同，主要是处理响应比较慢，不是当场返回结果，而是会在内部有一个内存列队，并用了大量 Promise 异步（刚转到 node 这点很爽，用得没有节制）。我一开始以为用的异步太多了导致的内存泄漏，现在看来并不是。
猜想是简单的 http 服务请求内存分配释放很快，总是在新生代。而处理队列+大量 promise 基本都是在老生代，所以有区别。
你的 django 程序是不是用了 celery?可能是 celery 配置不当导致的内存泄漏,你有没有设置
BROKER_POOL_LIMIT = 0 这个东西，设置为 0 会内存泄漏
我那个 Django 应用的并发量和日访问量都很小，问题是数据量很大，经常是上万条记录(再加上关联查询)一起 load 到前端，实际上一两次这样的请求消耗的内存总量并不大，要命的是内存不及时释放(或者根本不释放)，持续上涨一直到爆。
我也知道 Django 可以用迭代器模式遍历 queryset，这样能大大优化内存占用。但我觉得这有点自欺欺人(减少单次请求的内存消耗，并没有实际解决内存的不释放问题，顶多是缓兵之计)，而且我是配合 drf 使用，改成迭代器模式不太自然。
python 那个不是泄露。python interpreter 不会把从系统申请到的内存返回给系统，所以给人“越用占内存越多”的感觉。比如你写一个最大支持 1G 上传的服务器，并且用最大 25 个 threads，那么高峰时期你 python process 的最大内存占用会是 25G+，但并不会增大到无限多。所以在用 python 写大内存需求的程序时需要仔细考虑，如果内存 intensive 的操作要加锁。
针对你提到的Node.js微服务支持不到1天的问题，这通常与内存管理有关。Node.js的垃圾回收（GC）机制与Python等语言有所不同，它可能不会像Python那样主动回收无用内存。
在Node.js中，如果微服务运行在内存较小的机器上，并且需要长时间运行，可能会遇到内存溢出（OOM）的问题。为了解决这个问题，你可以尝试调整Node.js的内存限制。例如，在启动Node.js应用时，可以通过命令行参数来设置最大旧空间大小：
node --max_old_space_size=384 your_app.js
这里的384表示将最大旧空间大小设置为384MB。此外，你还可以使用--optimize_for_size参数来优化内存使用，尽管这可能会牺牲一些性能。
另外，建议监控你的Node.js微服务的内存使用情况，以便及时发现并解决内存泄漏等问题。你可以使用Node.js内置的性能监控工具，或者集成第三方监控服务来实时监控应用的性能。
总之，通过调整内存限制和监控内存使用情况，你应该能够解决Node.js微服务支持不到1天的问题。如果问题依旧存在，建议进一步排查代码中的内存泄漏等问题。
