[VU+ Duo] Enigma 2 Process - Memory Leak? (3.0.268)

[Lyze]

Hi Guys,

I'm running ViX Team Image 3.0.268 on a Vu Duo. After a few days (2-3 days) without rebooting, the box response gets quite sluggish - 10 to 20 seconds elapse before the pushes of the remote have any effect.

I used ssh to connect to the box - everything seems fine, except for the fact that enigma2 which seems to take all the memory

[FONT=Courier New]Mem: 126496K used, 11884K free, 0K shrd, 324K buff, 3768K cached
CPU:   0% usr  12% sys   4% nic  80% idle   0% io   0% irq   4% sirq
Load average: 3.09 1.77 1.20 2/83 8718
[B]  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND[/B]
 8716  8677 root     R     2656   2%   8% top
[COLOR="#800000"][B]  370   365 root     S     235m 174%   4% /usr/bin/enigma2[/B][/COLOR]
 8309     1 root     S     7284   5%   0% /usr/sbin/smbd
[…][/FONT]

Over the past couple of days I tried to find out what's triggering the issue. I couldn't figure it out. The utilized memory increases gradually over several days (when I'm watching it seems to be stable though... It looks like I loose 10 to 20 MB in discrete steps )

A few notes about my ViX configuration:

- Installed 208 (did not restore old Config files of course), Upgraded to 268 via online update a couple of days ago.
- Installed Samba, nothing else (no plugins)
- swapfile is on USB Stick (92 MB)
- I deleted the EPG files, which reside on a USB Stick, while Enigma was sleeping. This did not help
- tried upgrading to the latest unstable ViX Image today, did not work (Enigma crashed on launch)​

Would you have any ideas for further troubleshooting?

I really apologize if I missed any important information or troubleshooting steps. Currently I'm a bit short on time due to my job. I would defer getting help until I have time, but my family seems a bit bothered about the unreliabilty of the tv.

Thanks in advance for your help.

 

[Larry-G]

There is a known but not especially common problem with some Duo models suffering a memory leak on the 3.1.1 kernel. Vu are aware of this, but as of yet no fix is available than to go back to a earlier 2.6.18 kernel based image.

Sent from my GT-I9300 using Tapatalk 2

 

[Lyze]

Hi Phoenix,

thanks for the info. That makes sense.
I think I will try to set the box to do a nightly reboot. That'll hopefully be enough to mitigate the issue in the short term.

 

[Larry-G]

Hi Phoenix,

thanks for the info. That makes sense.
I think I will try to set the box to do a nightly reboot. That'll hopefully be enough to mitigate the issue in the short term.

There is at least one plugin available that can flush the memory of the box when as and when you want to, although i'm not too sure of the name at present as it's been a long time since i tried it.

 

[Lyze]

Sounds interesting, although I would not know how that kind of software might work. It can't know which sections of the memory are in use after all, I guess.

Nevertheless I seem to be getting closer to the root of the issue.
I am now fairly certain that reloading the EPG is causing my leak.

I can reliably reproduce the issue on my system now:

1. Go to Menu > Settings > System > EPG > Load / Save > Load EPG.
2. Accept by clicking "yes"
3. Repeat above mentioned steps ad lib. On my system the memory usage increases every time by 0.5 MB to 10 MB (I presume depending on the size of my EPG.dat file)

I previously set my EPG to reload every couple of hours, so over time that was causing my box to struggle. I disabled that now and will see how it goes.

 

[Larry-G]

Sounds interesting, although I would not know how that kind of software might work. It can't know which sections of the memory are in use after all, I guess.

Nevertheless I seem to be getting closer to the root of the issue.
I am now fairly certain that reloading the EPG is causing my leak.

I can reliably reproduce the issue on my system now:

1. Go to Menu > Settings > System > EPG > Load / Save > Load EPG.
2. Accept by clicking "yes"
3. Repeat above mentioned steps ad lib. On my system the memory usage increases every time by 0.5 MB to 10 MB (I presume depending on the size of my EPG.dat file)

I previously set my EPG to reload every couple of hours, so over time that was causing my box to struggle. I disabled that now and will see how it goes.

setting the EPG to refresh every couple of hours is fairly extreme and frankly overkill, once a day is more than adequate, all of mine are set to update in the early hours at around 04:00 and are good after that. also be aware that EPG data is held in live memory and only written to or read from storage media upon bootup or shutdown.

 

[Lyze]

setting the EPG to refresh every couple of hours is fairly extreme and frankly overkill, once a day is more than adequate, all of mine are set to update in the early hours at around 04:00 and are good after that.

Oh, I think there's a misunderstanding. I don't talk about downloading the EPG. This I also set to do only once in the early morning hours.

I (think) I'm talking about periodic write / read of epg.dat. This - at least if my interpretations of the settings are correct - should not be required at all. As you state, the System automatically loads / saves the data when shutting down / boot up.
(I did enable this setting because I had trouble with the epg getting lost occasionally - turned out it was a bad usb stick - after replacing the stick I naturally forgot to disable both settings... silly me)

I'd still consider this behavior to be a bug, but luckily it should not affect me in the future.


Anyways: Phoenix, thanks for your support.

 

[judge]

Have you an internal HDD in the Duo?
I moved EPG to internal HDD & picons to flash about 6 months ago & have never had any EPG related issues on the DUO since.
Saying that, I never set automatic refresh on EPG & see no need to.
Does seem like the auto refresh is killing your box though, thanks for the pointers.

 

[Lyze]

Hi judge,

yes, I've gotten an internal HDD as well. I think it makes sense for me to move EPG to the internal drive as well. I might try that for the future.

 

[judge]

Hi judge,

yes, I've gotten an internal HDD as well. I think it makes sense for me to move EPG to the internal drive as well. I might try that for the future.

Well worth trying as EPG is only read on boot & download, written on shutdown.
Internal HDD seems to be a better option for the DUO.

 

[Lyze]

You're absolutely right. I didn't know that back when I first set up the box.
I already modified my config accordingly.

Cheers, Christian

 

[judge]

Not a solution to your issues but helps us recommend preferred options while we look into them.
If you have a working internal HDD, EPG seems better stored there.

 

[Rob van der Does]

I would use some stronger words here: flash is the worst possible location for EPG.
The amount of EPG-data, and hence the storage file, can grow enormously. Even to the point of filling flash completely and making the box unbootable; this is especially the case on low-memory boxes like Solo, DUO and ET5000. Using a HDD or an USB device makes no difference, but flash is 'not done'.
For picons however flash is fine.

 

[Lyze]

Today I did just that. EPG resides on my internal hard drive now. It is indeed a better fit.

Cheers, Christian

 

[Lyze]

I would use some stronger words here: flash is the worst possible location for EPG.
The amount of EPG-data, and hence the storage file, can grow enormously. Even to the point of filling flash completely and making the box unbootable; this is especially the case on low-memory boxes like Solo, DUO and ET5000. Using a HDD or an USB device makes no difference, but flash is 'not done'.
For picons however flash is fine.

A few notes about my ViX configuration:
[…]
- I deleted the EPG files, which reside on a USB Stick, while Enigma was sleeping.

I never used the internal flash to store the EPG Database

 

[Faz1]

I have been having this issue too, using 3.1.1 kernel
I had my EPG on HDD previously but this didn't seem to make any difference.
Suspecting it was due to too many EPG sources I decided to disable EPG entirely and this seemed to have resolved it, no issues after week or two. Although I wasn't checking memory usage at the time.

I then enabled just one CrossEPG provider (XEPGDB) with 3 Rytec XMLTV (Italy, Poland, UK).
Things seem to be going OK for a week or so until just now.
Checking memory usage confirmed engima2 was using 234Mb. Having read this thread I used used CrossEPG Downloader and observed this process usage increase by several Mb.
Next I tried Engima restart using on-screen menu (long power button). ViX logo was spinning for some time and after several minutes there was still no change to engima2 process so I then restarted the process via SSH using the command "killall -HUP enigma2". Within a few seconds I was back to normal, with enigma2 process showing 74548 (e.g. ~73Mb) and seems to be stable.

Downloading EPG again as before saw enigma2 process increase to about 80Mb as it hit the merging, dropping back to around 74Mb.
Once it reached the final Loading Data I saw enigma2 increase again, settling at 103Mb.

So it does seem EPG leaks into engima2, kind of like a misbehaving browser plugin or something.

Although confusingly after a reboot via the on-screen menu engima2 is using 101Mb.
No EPG loaded as I have not enabled loading during boot.
Repeated rebooted as before, now 106Mb
Next tried "reboot" via SSH, this time 108 Mb.
Restarted engima using "killall -HUP engima2" and now engima2 process is consuming 132 Mb (98%) WTF?!
So I suspect CrossEPG is not the cause but is merely bringing it on or triggering that bit quicker due it's regular spikes in memory usage.
Loading EPG at this point brings engima2 usage to 139Mb (103%).

So I have decided to use Cron Manager (via ViX menu) to restart engima2 every day. Hopefully that will do for now.

 

[Rob van der Does]

So it does seem EPG leaks into engima2, kind of like a misbehaving browser plugin or something.

No, I wouldn't dare concluding that.
It is known that Cross-EPG is a very memory hungry task, and not all boxes are capable of handling that.
Using a (large) SWAP-file and CacheFlush usually helps.

In fact (daily) rebooting the box serves the same purpose, but the above way is more subtile and doesn't interfere with the normal usage of the box.

 

[andyblac]

guy's there is nothing wrong with e2 taking all available ram it is supposed too, just designed this way, it is not USING it all it has just cached it. for faster access.

 

[Faz1]

No, I wouldn't dare concluding that.
It is known that Cross-EPG is a very memory hungry task, and not all boxes are capable of handling that.
Using a (large) SWAP-file and CacheFlush usually helps.

In fact (daily) rebooting the box serves the same purpose, but the above way is more subtile and doesn't interfere with the normal usage of the box.

Definetely not concluding, I don't have anywhere enough understanding and evidence for that.

But engima2 process does include EPG and other data?
Would be nice if this could be kept as a child process.

I am using largest allowed swap. Thanks for suggestion of CacheFlush, I'll give this a try.

 

[Faz1]

guy's there is nothing wrong with e2 taking all available ram it is supposed too, just designed this way, it is not USING it all it has just cached it. for faster access.

Understood, but surely something is going wrong somewhere when it's exceeding 100%, and keeps climbing to the point where system becomes unresponsive?