json - Haskell 导管 Aeson : Parsing Large JSONs and filter matching key/values

Question

我用 Haskell 编写了一个应用程序，它执行以下操作:

1. 递归列出一个目录，
2. 解析目录列表中的 JSON 文件，
3. 寻找匹配的键值对，并且
4. 返回找到匹配项的文件名。

我的这个应用程序的第一个版本是我能写的最简单、天真的版本，但我注意到空间使用似乎单调增加。

因此，我切换到 conduit，现在我的主要功能如下所示:

conduitFilesFilter :: ProjectFilter -> Path Abs Dir -> IO [Path Abs File]
conduitFilesFilter projFilter dirname' = do
  (_, allFiles) <- listDirRecur dirname'
  C.runConduit $
    C.yieldMany allFiles
    .| C.filterMC (filterMatchingFile projFilter)
    .| C.sinkList

现在我的应用程序已限制内存使用，但它仍然很慢。对此，我有两个问题。

1)

我使用 stack new 生成框架来创建这个应用程序，它默认使用 ghc 选项 -threaded -rtsopts -with-rtsopts=-N。

(对我而言)令人惊讶的是，当我实际运行该应用程序时，它使用了所有可用的处理器(目标机器中大约有 40 个)。但是，我没有编写要并行运行的应用程序的任何部分(实际上我考虑过)。

什么是并行运行的？

2)

此外，大多数 JSON 文件都非常大 (10mb)，可能有 500k 需要遍历。这意味着由于所有 Aeson 解码，我的程序非常慢。我的想法是并行运行我的 filterMatchingFile 部分，但是查看 stm-conduit 库，我看不到并行运行这个中间操作的明显方法少数处理器。

任何人都可以建议一种使用 stm-conduit 或其他方式巧妙地并行化我的函数的方法吗？

---

编辑

我意识到我可以将我的 readFile -> decodeObject -> runFilterFunction 分解成 conduit 的单独部分，然后我可以使用 stm-conduit 有一个有界 channel 。也许我会试一试...

---

我使用 +RTS -s 运行我的应用程序(我将它重新配置为 -N4)，我看到以下内容:

 115,961,554,600 bytes allocated in the heap
  35,870,639,768 bytes copied during GC
      56,467,720 bytes maximum residency (681 sample(s))
       1,283,008 bytes maximum slop
             145 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     108716 colls, 108716 par   76.915s  20.571s     0.0002s    0.0266s
  Gen  1       681 colls,   680 par    0.530s   0.147s     0.0002s    0.0009s

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

  TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4)

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

  INIT    time    0.001s  (  0.007s elapsed)
  MUT     time   34.813s  ( 42.938s elapsed)
  GC      time   77.445s  ( 20.718s elapsed)
  EXIT    time    0.000s  (  0.010s elapsed)
  Total   time  112.260s  ( 63.672s elapsed)

  Alloc rate    3,330,960,996 bytes per MUT second

  Productivity  31.0% of total user, 67.5% of total elapsed

gc_alloc_block_sync: 188614
whitehole_spin: 0
gen[0].sync: 33
gen[1].sync: 811204

Answer 1

从您的程序描述来看，它没有理由增加内存使用量。我认为这是由于错过了惰性计算而导致的意外内存泄漏。这可以通过堆分析轻松检测到:https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#hp2ps-rendering-heap-profiles-to-postscript .其他可能的原因是运行时不会将所有内存释放回操作系统。在达到某个阈值之前，它将保持与处理的最大文件成比例的内存。如果通过进程 RSS 大小进行跟踪，这可能看起来像是内存泄漏。

-A32m 选项增加了苗圃规模。它允许您的程序在触发垃圾收集之前分配更多内存。统计数据显示，在 GC 期间保留的内存非常少，因此这种情况发生的频率较低，程序花在实际工作上的时间更多。