yon*_*ong 39 profiling garbage-collection haskell memory-management
我正在运行一个长期存在的Haskell程序,它可以保留大量内存.运行+RTS -N5 -s -A25M
(我的L3缓存的大小)我看到:
715,584,711,208 bytes allocated in the heap
390,936,909,408 bytes copied during GC
4,731,021,848 bytes maximum residency (745 sample(s))
76,081,048 bytes maximum slop
7146 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 24103 colls, 24103 par 240.99s 104.44s 0.0043s 0.0603s
Gen 1 745 colls, 744 par 2820.18s 619.27s 0.8312s 1.3200s
Parallel GC work balance: 50.36% (serial 0%, perfect 100%)
TASKS: 18 (1 bound, 17 peak workers (17 total), using -N5)
SPARKS: 1295 (1274 converted, 0 overflowed, 0 dud, 0 GC'd, 21 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 475.11s (454.19s elapsed)
GC time 3061.18s (723.71s elapsed)
EXIT time 0.27s ( 0.50s elapsed)
Total time 3536.57s (1178.41s elapsed)
Alloc rate 1,506,148,218 bytes per MUT second
Productivity 13.4% of total user, 40.3% of total elapsed
Run Code Online (Sandbox Code Playgroud)
GC时间是总运行时间的87%!我在具有大量RAM的系统上运行它,但是当我设置高-H
值时性能更差.
看来,无论-H
和-A
控件的大小gen 0
,但我真的很想做的是增加的大小gen 1
.做这个的最好方式是什么?
正如卡尔建议的那样,您应该检查代码是否存在空间泄漏。我假设您的程序确实需要大量内存,这是有充分理由的。
该程序花费了 2820.18s 进行主要 GC。您可以通过减少内存使用量(不是假设的情况)或主要集合的数量来降低它。您有大量可用 RAM,因此您可以尝试-Ffactor
以下选项:
-Ffactor
[Default: 2] This option controls the amount of memory reserved for
the older generations (and in the case of a two space collector the size
of the allocation area) as a factor of the amount of live data. For
example, if there was 2M of live data in the oldest generation when we
last collected it, then by default we'll wait until it grows to 4M before
collecting it again.
Run Code Online (Sandbox Code Playgroud)
在您的情况下,有大约 3G 的实时数据。默认情况下,当堆增长到6G时,将触发major GC。当堆增长到 9G 时它将-F3
被触发,为您节省约 1000 秒的 CPU 时间。
如果大多数实时数据是静态的(例如从不改变或改变缓慢),那么您将对稳定堆感兴趣。这个想法是从主要 GC 中排除长期存在的数据。它可以通过使用紧凑范式来实现,尽管它还没有合并到 GHC 中。
归档时间: |
|
查看次数: |
454 次 |
最近记录: |