LINUX.ORG.RU

haskell GC отжирает все время

 , ,


0

4

Вот код https://github.com/s9gf4ult/hadan/blob/master/post.hs понимаю что быдлокод. Буду потом причесывать, сейчас не могу понять почему так работает сборщик мусора

% ./post +RTS -s -RTS
   9,876,377,664 bytes allocated in the heap
   1,574,223,056 bytes copied during GC
     215,586,000 bytes maximum residency (13 sample(s))
       3,664,088 bytes maximum slop
             526 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0     19005 colls,     0 par   93.99s   103.07s     0.0054s    0.0527s
  Gen  1        13 colls,     0 par    1.82s    2.52s     0.1938s    0.8928s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   15.76s  ( 28.54s elapsed)
  GC      time   95.82s  (105.59s elapsed)
  EXIT    time    0.00s  (  0.06s elapsed)
  Total   time  111.59s  (134.19s elapsed)

  %GC     time      85.9%  (78.7% elapsed)

  Alloc rate    626,256,589 bytes per MUT second

  Productivity  14.1% of total user, 11.8% of total elapsed
111 секунд из которых 95 проработал сборщик мусора ? Это странно. Дело точно не в genCandles проверил с

main = genCandles >>= (mapM (putStrLn . show)) . (take 100000)
% ./post +RTS -s -RTS > out
  11,409,643,848 bytes allocated in the heap
      26,326,000 bytes copied during GC
       2,299,992 bytes maximum residency (3 sample(s))
          57,656 bytes maximum slop
               6 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0     22097 colls,     0 par    0.85s    0.87s     0.0000s    0.0024s
  Gen  1         3 colls,     0 par    0.00s    0.01s     0.0024s    0.0052s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   15.62s  ( 16.29s elapsed)
  GC      time    0.85s  (  0.88s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   16.48s  ( 17.17s elapsed)

  %GC     time       5.2%  (5.1% elapsed)

  Alloc rate    730,048,395 bytes per MUT second

  Productivity  94.8% of total user, 91.0% of total elapsed

Как видим, если не работать с Postgre сборщик мусора не выпендривается. Как анализировать ? Что делать ? ЧЯДНТ ?

Почитай внимательнее документацию на postgresql-simple, там этому вопросу много внимания уделено. А так, deepseq - наше все... Хоть и не Ъ.

Macil ★★★★★
()
Последнее исправление: Macil (всего исправлений: 1)
Ответ на: комментарий от s9gf4ult

Я там такто ничего не запрашиваю, я инсерты делаю

Хм, ничего подозрительного на первый взгляд нет.

Только, во-первых при (++) операнды уйдут в мусор; во-вторых, список полей тоже уйдет в мусор; в-третьих, Candle после преобразования уйдет в мусор; в-четвертых, если делается не один insert то какие-то данные тоже обязаны уйти в мусор (я не очень хорошо разбираюсь в нутрях сабжа, чтобы сказать какие именно).

И последнее, если insert не вычислит какой-то из элементов списка параметров, то вроде бы возникает жуткая бяка.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Ну а как же все вычисления, которые идут до инсертов ? там ведь инстансы Random и тоже полно всего пойдет в мусор при генерации Candle ов. Однако, скорость вывода в stdout высокая и тормозит именно с инсертами.

Прочитал про эти space leaks - плохо понял суть. Как вообще повышение используемой памяти должно влиять на скорость работы сборщика мусора ?

И что мне нужно сделать с программой, чтобы вычисления были более строгие и Candle сразу после генерации инсертилась в базу одна за другой ?

s9gf4ult ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.