[mythtv-users] 0.25->0.26: problems with high mem consumption and oom kils
warpme at o2.pl
Tue Sep 4 19:05:42 UTC 2012
On 9/4/12 7:34 PM, Tyler T wrote:
>>> Why bother trying to diagnose it? Why not add swap space?
>>> The other option is to add more RAM.
> If it's a memory leak, it'll still crash with 32GB of RAM installed...
> just takes a little longer.
>> BE seems to be little different story: 800-900MB for it seems to be little
>> too high, especially compared with 250-300MB I usually observed in 0.25
> Agreed. Have you considered enabling verbose logging and submitting a
> bug report?
> mythtv-users mailing list
> mythtv-users at mythtv.org
Thx for replay.
In fact I launch detailed logging for to be sure there is no error from
my side. Probability is low as 0.26 was compiled/installed on exactly
the same environment like 0.25, so I really doubt it is environment issue.
Next I observe RSS as function on time. It has stepped growth but after
reaching given level is practically constant in time. This hints me that
issue is probably related to particular code paths.
I.e. in BE it seems to almost directly related to number of running
recorders AND recording concurrency.
I can't resist to feeling that it is result of switching logging
messaging to zeromq - but this is only speculation.
What is more interesting - before upgrade to 0.26, I had 0.25 BE with
all major changes in EIT/recorders backported from 0.26->0.25.
It as working really nicely weeks without issues. So in recording
infrastructure I can fairly say 0.25 with 0.26's recording subsystem
don't have RSS issue. On the other hand, 0.26 BE RSS issue is directly
proportional to running recorders+concurrency...
I post to ML because I want to find most efficient way to diagnose this
type of problems. Software tools are constantly improved and probably I
missed some nice tools/techniques to diagnose memory consumption in
Having limited maintenance time windows on my production BE + somehow
limited time I can devote to this, I prefer hints from knowledgeable ppl
instead learning by try-error
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 83 bytes
Desc: not available
More information about the mythtv-users