GHC 每线程 GC 策略答案

【问题标题】：GHC per thread GC strategyGHC 每线程 GC 策略
【发布时间】：2015-08-13 21:56:16
【问题描述】：

我有一个Scotty api 服务器，它构造一个Elasticsearch 查询，从ES 获取结果并呈现json。

与Phoenix 和Gin 等其他服务器相比，我使用BloodHound 提供ES 响应的CPU 利用率和吞吐量更高，但Gin 和Phoenix 比@ 好很多内存效率为 987654330@。

斯科蒂的统计数据

 wrk -t30 -c100 -d30s "http://localhost:3000/filters?apid=1&hfa=true"
Running 30s test @ http://localhost:3000/filters?apid=1&hfa=true
  30 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   192.04ms  305.45ms   1.95s    83.06%
    Req/Sec   133.42    118.21     1.37k    75.54%
  68669 requests in 30.10s, 19.97MB read
Requests/sec:   2281.51
Transfer/sec:    679.28KB

这些统计数据位于我安装了 GHC 7.10.1 的 Mac 上

处理器信息 2.5GHx i5
内存信息 8GB 1600 Mhz DDR3

GHC 的基于轻量级线程的并发给我留下了深刻的印象，但内存效率仍然是一个大问题。

分析内存使用情况为我提供了以下统计信息

    39,222,354,072 bytes allocated in the heap
     277,239,312 bytes copied during GC
     522,218,848 bytes maximum residency (14 sample(s))
         761,408 bytes maximum slop
            1124 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       373 colls,   373 par    2.802s   0.978s     0.0026s    0.0150s
  Gen  1        14 colls,    13 par    0.534s   0.166s     0.0119s    0.0253s

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

  TASKS: 18 (1 bound, 17 peak workers (17 total), using -N4)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.001s  (  0.008s elapsed)
  MUT     time   31.425s  ( 36.161s elapsed)
  GC      time    3.337s  (  1.144s elapsed)
  EXIT    time    0.000s  (  0.001s elapsed)
  Total   time   34.765s  ( 37.314s elapsed)

  Alloc rate    1,248,117,604 bytes per MUT second

  Productivity  90.4% of total user, 84.2% of total elapsed

gc_alloc_block_sync: 27215
whitehole_spin: 0
gen[0].sync: 8919
gen[1].sync: 30902

Phoenix 占用的内存从未超过 150 MB，而 Gin 占用的内存要少得多。

我相信 GHC 对 GC 使用标记和清除策略。我也相信使用类似于 Erlang VM 的每线程增量 GC 策略会更好，以获得更好的内存效率。

通过解读唐·斯图尔特对related question 的回答，肯定有一些方法可以改变 GHC 中的 GC 策略。

我还注意到，当并发水平较低时，内存使用量保持稳定且相当低，所以我认为只有在并发量很高时内存使用量才会激增。

解决此问题的任何想法/指针。

【问题讨论】：

您真正的问题是什么？如何减少内存使用？
大体上是的。更具体地说，如果我能找到一种在 GHC 中启用每线程 GC 策略的方法。
我的印象是最新版本的 GHC已经进行了每线程 GC，但我可能错了...
我相信 GHC 使用标记和清除策略。它使用分代机制来管理内存。如果我错了，请纠正我。
这绝对是世代相传的，我相信它是标记/扫描。但是，我的印象是最年轻的一代是按核心计算的。不过，我会看看是否可以找到实际的参考。

标签： multithreading haskell memory garbage-collection ghc

【解决方案1】：

http://community.haskell.org/~simonmar/papers/local-gc.pdf

Simon Marlow 的这篇论文描述了每个线程的本地堆，并声称这是在 GHC 中实现的。它的日期是 2011 年。我不确定这是否是当前版本的 GHC 实际所做的（即，这是否进入了 GHC 的发布版本，是否仍然是当前状态等），但似乎我的回忆并没有完全编造出来。

我还将指出 GHC 手册中解释您可以调整垃圾收集器的设置的部分：

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime-control.html#rts-options-gc

特别是，默认情况下，GHC 使用 2 空间收集器，但添加 -c RTS 选项使其使用稍慢的 1 空间收集器，这应该会占用更少的 RAM。（我完全不清楚这些信息适用于哪一代。）

我的印象是 Simon Marlow 是做 RTS 大部分工作（包括垃圾收集器）的人，所以如果你能在 IRC 上找到他，他就是那个问你是否想要直接真相的人......

【讨论】：