[mythtv-users] mythbackend still eats memory: the current status
Allan Stirling
dibblah.allan.stirling at googlemail.com
Sat Jan 24 13:07:15 UTC 2009
Udo van den Heuvel wrote:
> AntiCat wrote:
>> Udo van den Heuvel schrieb:
>>> AntiCat wrote:
>>>
>>>> Jan Ceuleers schrieb:
>>>> I did a 1hour recording and a 5minute recording, both with valgrind
>>>> running.
>>>> (The Reports are attatched to the Ticket #5545)
>>
>> It should be fixed with commit 19705 (trunk) or
>> 19706 (release-0-21-fixes).
>
> After running a few days with svn 19714 from fixes I have these figures:
>
> %CPU %MEM VSZ RSS TTY STAT START TIME
> 8.5 9.1 396948 88952 ? Ssl Jan18 97:53
> 9.7 13.2 461016 128748 ? Ssl Jan18 252:16
> 10.2 14.9 478488 145068 ? Ssl Jan18 411:36
> 10.4 16.2 491164 157904 ? Ssl Jan18 572:08
> 10.7 17.9 507172 174568 ? Ssl Jan18 739:58
> 10.8 19.3 521604 188232 ? Ssl Jan18 902:52
>
> Older numbers at the bottom.
> These figures tell me that indeed EIT was not the main source of memory
> leaks on my system.
> BTW: Do the numbers grow quicker than before?
> What do you think?
>
> In other news: I have the AMD Thunderbird system ready and waiting, with
> disks etc to run a test system on.
> Only issue is a (faked?) video stream to simulate the multirec
> situation. How could I accomplish this?
Hi Udo.
The patch in 19705 had nothing really to do with EIT
parsing. It was in the handling of freeing memory for NITs
and SDTs.
Have you actually tried disabling EIT?
Myth actually has some support for increased buffers to work
around increased latency caused by valgrind:
./configure --enable-valgrind --compile-type=profile
Can you please try these on your production system, for a
short (4 hour) run?
I would suggest that without DVB cards matching your
production system, a test system will not reproduce this leak.
It may also be valuable to back up your database and try
current trunk.
Cheers,
Allan.
More information about the mythtv-users
mailing list