【问题标题】:nodejs v8 memory gc allocation failurenodejs v8内存gc分配失败
【发布时间】:2012-12-07 11:38:23
【问题描述】:

我正在尝试使用无操作服务器来分析 nodejs v8 内存。 我使用 node-memwatch 来获取堆差异。我在连接之前和连接断开之后收集堆信息。我使用了节点内存监视。我从客户端尝试了 200 个并发连接。

这是连接断开后的 gc 跟踪。

谁能帮我理解:

1.为什么内存在增加?连接断开后,服务器绝对什么都不做。它不应该总是随着垃圾被收集而丢弃吗?
2.那些分配失败是什么?我如何真正解释这里的痕迹?

 15802 ms: Mark-sweep 8.9 (45.0) -> 8.1 (45.0) MB, 58 ms [allocation failure] [GC in old space forced by flags].
 16144 ms: Mark-sweep 9.2 (45.0) -> 8.4 (45.0) MB, 53 ms [allocation failure] [GC in old space forced by flags].
 16495 ms: Mark-sweep 9.5 (45.0) -> 8.7 (46.0) MB, 60 ms [allocation failure] [GC in old space forced by flags].
 16837 ms: Mark-sweep 9.8 (46.0) -> 9.0 (46.0) MB, 56 ms [allocation failure] [GC in old space forced by flags].
 17197 ms: Mark-sweep 10.1 (46.0) -> 9.4 (46.0) MB, 62 ms [allocation failure] [GC in old space forced by flags].
 17905 ms: Mark-sweep 11.5 (46.0) -> 10.0 (47.0) MB, 74 ms [Runtime::PerformGC] [GC in old space forced by flags].                                                               
 18596 ms: Mark-sweep 12.2 (47.0) -> 10.7 (47.0) MB, 75 ms [Runtime::PerformGC] [GC in old space forced by flags].
 19315 ms: Mark-sweep 12.8 (47.0) -> 11.3 (48.0) MB, 83 ms [allocation failure] [GC in old space forced by flags].
 20035 ms: Mark-sweep 13.4 (48.0) -> 12.0 (49.0) MB, 90 ms [Runtime::PerformGC] [GC in old space forced by flags].
 21487 ms: Mark-sweep 16.0 (49.0) -> 13.2 (50.0) MB, 96 ms [Runtime::PerformGC] [GC in old space forced by flags].
 22950 ms: Mark-sweep 17.3 (50.0) -> 14.5 (52.0) MB, 116 ms [Runtime::PerformGC] [GC in old space forced by flags].
 24376 ms: Mark-sweep 18.8 (52.0) -> 15.9 (53.0) MB, 114 ms [allocation failure] [GC in old space forced by flags].
 25849 ms: Mark-sweep 19.9 (53.0) -> 17.2 (54.0) MB, 129 ms [Runtime::PerformGC] [GC in old space forced by flags].
 28773 ms: Mark-sweep 25.2 (54.0) -> 19.7 (57.0) MB, 149 ms [allocation failure] [GC in old space forced by flags].
 31725 ms: Mark-sweep 27.7 (57.0) -> 22.2 (59.0) MB, 172 ms [Runtime::PerformGC] [GC in old space forced by flags].
 34678 ms: Mark-sweep 30.2 (59.0) -> 24.7 (61.0) MB, 190 ms [Runtime::PerformGC] [GC in old space forced by flags].
 44045 ms: Mark-sweep 28.4 (61.0) -> 25.8 (63.0) MB, 180 ms [idle notification] [GC in old space forced by flags].
 44216 ms: Mark-sweep 25.8 (63.0) -> 25.8 (63.0) MB, 170 ms [idle notification] [GC in old space requested].
 57471 ms: Mark-sweep 26.9 (63.0) -> 25.8 (62.0) MB, 167 ms [Runtime::PerformGC] [GC in old space forced by flags].
 57651 ms: Mark-sweep 26.8 (62.0) -> 25.5 (62.0) MB, 160 ms [Runtime::PerformGC] [GC in old space forced by flags].
 57828 ms: Mark-sweep 26.5 (62.0) -> 25.5 (62.0) MB, 159 ms [Runtime::PerformGC] [GC in old space forced by flags].

谢谢,

【问题讨论】:

    标签: node.js memory garbage-collection v8


    【解决方案1】:

    “分配失败”听起来很戏剧化,但并没有涉及到真正的失败。这只是意味着我们分配了这么多内存,是时候进行一次 GC 来看看我们是否可以收集一些内存。

    看起来您正在使用 --gc-global 标志(“标志强制 GC”)运行。这对生产来说是个坏主意,尽管在调试时缩小问题范围可能很好。

    我不知道您的进程为什么会泄漏。您可能会发现堆分析器很有用。见https://github.com/felixge/node-memory-leak-tutorial

    【讨论】:

    • 是的,我正在使用 --gc-global 和 compact 来确保在获取堆差异之前收集所有垃圾。那是次要的。问题是为什么在 gc 期间 mem 会增加?
    【解决方案2】:

    根据代码:

    PrintF("%s %.1f (%.1f) -> %.1f (%.1f) MB, ",
           CollectorString(),
           static_cast<double>(start_object_size_) / MB,                                                                                    
           static_cast<double>(start_memory_size_) / MB, 
           SizeOfHeapObjects(),
           end_memory_size_mb);
    

    每一行是一个gc,当gc开始时,

    start_object_size_ = heap_->SizeOfObjects();
    

    在 gc 总结中:

    PrintF("total_size_before=%" V8_PTR_PREFIX "d ", start_object_size_);                                                                   
    PrintF("total_size_after=%" V8_PTR_PREFIX "d ", heap_->SizeOfObjects());
    

    至于为什么我的应用程序空闲时start_object_size_会增加,我猜可能在gc期间,一些对象被提升到旧空间并导致旧空间中的对象大小增加。

    【讨论】:

    • 即使在这么多年之后,这对我还是很有用的,因为它给了我在代码代码中搜索什么的线索。这是当前代码:github.com/nodejs/node/blob/…
    猜你喜欢
    • 2018-03-23
    • 2015-04-05
    • 1970-01-01
    • 1970-01-01
    • 2018-09-29
    • 1970-01-01
    • 2016-05-01
    • 2013-02-19
    • 2011-12-12
    相关资源
    最近更新 更多