Question

我有一个Node.js应用程序，可以在Redis Pubsub和Websockets之间进行实时消息传递。该应用程序处理每个消息中长度大约为2.5 MB的字符串。除了GC启动时，它表现良好。以下是我在启用-trace_gc标记时看到的内容：

[GC interrupt] [GC in old space requested].
[29290:0x35826f0] 104218566 ms: Mark-sweep 104.2 (1139.5) -> 20.7 (1057.8) MB, 153.4 / 0 ms (+ 19.4 ms in 16 steps since start of marking, biggest step 17.0 ms) [GC interrupt] [GC in old space requested].
[29290:0x35826f0] 104219639 ms: Mark-sweep 110.8 (1146.0) -> 110.1 (1146.0) MB, 20.1 / 0 ms (+ 63.3 ms in 25 steps since start of marking, biggest step 59.0 ms) [GC interrupt] [GC in old space requested].
[29290:0x35826f0] Increasing marking speed to 3 due to high promotion rate
[29290:0x35826f0] 104222147 ms: Mark-sweep 384.7 (1415.3) -> 128.1 (1163.8) MB, 390.0 / 0 ms (+ 19.9 ms in 27 steps since start of marking, biggest step 17.0 ms) [GC interrupt] [GC in old space requested].
[29290:0x35826f0] 104224639 ms: Mark-sweep 394.0 (1424.5) -> 48.0 (1084.9) MB, 324.0 / 0 ms (+ 22.7 ms in 10 steps since start of marking, biggest step 17.0 ms) [GC interrupt] [GC in old space requested].
[29290:0x35826f0] 104225695 ms: Mark-sweep 175.1 (1209.9) -> 88.2 (1124.0) MB, 169.0 / 0 ms (+ 18.3 ms in 11 steps since start of marking, biggest step 16.3 ms) [GC interrupt] [GC in old space requested].

以下是我的尝试：

使用--expose-gc标志运行节点并每分钟手动调用GC。在这种情况下，没有多大帮助。
我使用--max-old-space-size=3072将旧空间大小增加到3GB。这降低了应用程序卡在GC中的频率，但我无法无限期地增加内存。

我从各个地方读到的东西是，我在旧物体区域的自由空间用完了，所以V8触发了完整的标记和扫描收集，这需要很长时间。由于我的应用处理大型对象（主要是JS字符串），它们可能直接放在旧空间中。

可以采取哪些措施来缩短GC时间？请注意，应用程序会交换大量消息并切断字符串，以便每个字符串的长度都是非选项。

对于巨大的物体

0 个答案: