如何优化 Haskell 中软实时应用程序的垃圾收集？

Posted 2023-03-06

【中文标题】如何优化 Haskell 中软实时应用程序的垃圾收集？

【英文标题】：How do I optimise garbage collection for a soft real-time application in Haskell?

【发布时间】：2015-11-05 13:43:42

【问题描述】：

我在 Haskell 中编写了一个软实时应用程序，它处理模拟物理、碰撞检测以及所有这些好东西。在做所有这些时，我分配了大量内存，如果我愿意，我可能会优化我的内存使用，但由于我很好地坐在 40% 的 CPU 上，而且无论如何只使用了 1% 的 RAM，这似乎没有必要。不过，我看到的是，很多时候，当垃圾收集器启动时，会跳过帧。我已经通过使用threadscope 进行分析验证了这是问题的原因：在垃圾收集器执行其业务时，有时最多 0.05 秒内没有发生有用的计算，导致最多 3 个跳过帧，这非常明显并且很烦人。

现在，我尝试通过在每一帧手动调用 performMinorGC 来解决这个问题，这似乎缓解了这个问题，使它更加流畅，除了整体 CPU 使用率急剧上升到 70% 左右。显然我宁愿避免这种情况。

我尝试的另一件事是使用 -H64k 将 GC 的分配空间从 512k 减少到 64k，我还尝试设置 -I0.03 以尝试更频繁地收集它。这两个选项都改变了我在threadscope 中看到的垃圾收集模式，但它们仍然导致跳帧。

任何有 GC 优化经验的人都可以在这里帮助我吗？我是否注定要手动调用performMinorGC 并忍受由此带来的巨大性能损失？

编辑

我尝试在这些测试中运行它类似的时间，但由于它是实时的，因此没有“完成”的时间。

performMinorGC 每 4 帧的运行时统计信息：

     9,776,109,768 bytes allocated in the heap
     349,349,800 bytes copied during GC
      53,547,152 bytes maximum residency (14 sample(s))
      12,123,104 bytes maximum slop
             105 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     15536 colls, 15536 par    3.033s   0.997s     0.0001s    0.0192s
  Gen  1        14 colls,    13 par    0.207s   0.128s     0.0092s    0.0305s

  Parallel GC work balance: 6.15% (serial 0%, perfect 100%)

  TASKS: 20 (2 bound, 13 peak workers (18 total), using -N4)

  SPARKS: 74772 (20785 converted, 0 overflowed, 0 dud, 38422 GC'd, 15565 fizzled)

  INIT    time    0.000s  (  0.001s elapsed)
  MUT     time    9.773s  (  7.368s elapsed)
  GC      time    3.240s  (  1.126s elapsed)
  EXIT    time    0.003s  (  0.004s elapsed)
  Total   time   13.040s  (  8.499s elapsed)

  Alloc rate    1,000,283,400 bytes per MUT second

  Productivity  75.2% of total user, 115.3% of total elapsed

gc_alloc_block_sync: 29843
whitehole_spin: 0
gen[0].sync: 11
gen[1].sync: 71

没有performMinorGC

  12,316,488,144 bytes allocated in the heap
     447,495,936 bytes copied during GC
      63,556,272 bytes maximum residency (15 sample(s))
      15,418,296 bytes maximum slop
             146 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     19292 colls, 19292 par    2.613s   0.950s     0.0000s    0.0161s
  Gen  1        15 colls,    14 par    0.237s   0.165s     0.0110s    0.0499s

  Parallel GC work balance: 2.67% (serial 0%, perfect 100%)

  TASKS: 17 (2 bound, 13 peak workers (15 total), using -N4)

  SPARKS: 100714 (29688 converted, 0 overflowed, 0 dud, 47577 GC'd, 23449 fizzled)

  INIT    time    0.000s  (  0.001s elapsed)
  MUT     time   13.377s  (  9.917s elapsed)
  GC      time    2.850s  (  1.115s elapsed)
  EXIT    time    0.000s  (  0.006s elapsed)
  Total   time   16.247s  ( 11.039s elapsed)

  Alloc rate    920,744,995 bytes per MUT second

  Productivity  82.5% of total user, 121.4% of total elapsed

gc_alloc_block_sync: 68533
whitehole_spin: 0
gen[0].sync: 9
gen[1].sync: 147

由于某种原因，现在没有performMinorGC 的整体生产力似乎比我昨天测试它时要低 - 之前它总是 >90%。

【问题讨论】：

请粘贴运行时统计信息 (+RTS -s)

幼稚的建议，但是如果您只是每隔 10 帧就调用 performMinorGC 怎么办？

你在分配什么？如果你可以避免分配，GC 就不是问题了。

@PaulJohnson 我正在执行碰撞检测比这更天真，将区域分成固定大小的网格，然后循环遍历每个网格单元中的所有内容。它是 2D，而不是 3D，所以这对我来说非常好。但是，是的，避免分配将非常困难，至少在不牺牲大量优雅的情况下。我试图让代码对初学者来说非常易读，所以我宁愿不放弃我的许多不错的抽象。

每秒分配 1GB？哇...模拟有多大？无论如何，有可能是某种懒惰/严格的问题导致你吃掉了不必要的内存。除此之外，我不知道该建议什么......

【参考方案1】：

你有不同的大型老年代。它有 100Mb 大。

默认情况下，GHC 在最后一次主要 GC 后堆大小达到其大小的 2 倍时执行主要 GC。这意味着在某些时候 GC 必须扫描和复制 50Mb 的数据。如果您的处理器有 10Gb 内存吞吐量限制，那么加载和复制 50Mb 将至少需要 0.01 秒（与 gen1 平均和最大暂停相比。）

（我假设您检查了事件日志以确保主要 GC 在 0.05 秒暂停期间实际工作。因此，当 GC 正在等待其他线程而不是实际工作时，这不是线程同步的问题。）

因此，为了尽量减少 GC 暂停，您应该确保老年代很小。如果这 50Mb 中的大部分是一开始就分配的静态数据，并且一直存在到最后（例如纹理或网格），那么您就是 stuck。我知道的唯一解决方法是将数据打包到例如可存储的向量，并在需要时再次解压其中的一部分。

如果数据是在执行期间分配的，并且存在有限的时间（但足以在几代人中存活），那么请尝试重新考虑您的管道。通常没有数据应该在一帧中存活，所以你做错了什么。例如。您在不应该保留数据时保留数据。

其他不好的迹象——gen0 最大暂停 0.02 秒。这很奇怪。默认情况下 gen0 分配区域为 0.5Mb，因此 gen0 GC 应该很快。可能你有很大的remembered set。可能的原因：可变结构（IORef、可变向量等）或大量延迟更新。

还有一个小问题（可能不相关）：看起来您正在使用隐式并行，但只有 1/3 的火花被转换。您分配了太多的 spart，其中 1/2 是 GC'd。

【讨论】：

好的，基于此我做了一些实验，最后注释掉了我所有的逻辑代码，除了主循环的旋转。事实证明，如果我这样做，我会一直达到 3.3GB/s 的分配速率。因此，我实现主循环的方式意味着每次迭代都会分配大量内存......我想我不应该对 GC 造成如此大的停顿感到惊讶，因为它有这么多要处理的事情！我想这一定与我的变压器堆栈有关。我会尝试隔离问题。我会接受答案，因为它告诉我出了什么问题。

更新：将threadDelay 100 粘贴到主循环中大大缓解了这个问题。事实证明，由于我在单独的线程中进行渲染，所以主循环只是不断地旋转，而在大多数迭代中没有做任何实际工作。 threadDelay 看起来有点像黑客......