Plugins » foreman-tasks

For the record, when I was looking into the issue the other day, I was using SystemTap. I was not able to continue as I did not know the correct syntax for SCL Ruby, but I finally got it:

https://lukas.zapletalovi.com/2016/08/probing-ruby-20-apps-with-systemtap-in-rhel7.html

That could help maybe:

scl enable rh-ruby22 -- stap rubystack.stp -c "ruby dynflow.rb"

I have done a bit of investigation, but didn't find anything significant in dynflow engine itself.
What I did:
I was running a simple task based on dynflow example "remote_executor", the task was changed to perform GC.collect (in part of the cases) and write GC.stats to a file in /tmp.
What I found:
while adding GC.collect to the task - I saw that the memory footprint was pretty big, but steady.
without GC.collect - the memory footprint got up, but the number of garbage collections remained the same.
Conclusions:
1. Dynflow as engine is not leaking.
2. It uses a lot of objects to perform even a simple task - it can become a problem, but it's less critical then leak.
3. Since I was using ruby 2.2 where generations were already introduced, I could see a lot of objects surviving the young generation collections and promoted to older generation. This can explain the bloat without forced GC.collect - the system just didn't trigger full GC.
4. (2) leads to (3) - massive allocations cause younger generation collections which in turn promote objects to older generation.