Please check the latest OSCAM 1.20-unstable_svn build #7314
I started it over 1 hour and there is not huge memory consumption so far with 35 cacheex readers under hood :)
Maybe Changeset 7296 and Changeset 7300 fix the problem.
Versions for pc are attached bellow
What sort of clients do you have ?
Edit: I've just tested, it indeeds stays alive for quite a good time (cache size 800).
It slowly increases (like 10kB/s), nothing to worry about currently, i'll check again later.
I've got mostly cccam and one camd35 readers, and only cccam clients.
Mixed cccam and camd35.
With this version i met other bug- very unstable after 2 hours work crashed every 2 minutes. I will switch back to 7190
Please report do you met issue like this in your system?
7/4hour of uptime ATM. I keep a look at it
I tested the latest release, crashed within 30 seconds with 60 peers connected.
Bug is still there, please do not upgrade!
Latest stable CACHE-EX release is still 7190.
Thx
Still stable after 2h30m ...granted i've got only 5 peers. I stop keeping an eye on it, but i setted it to fallback to 7190 on crash.
No memory leak observed.
@phh:Originally Posted by phh
Did you actually check your log to see if the bug still occurs ?
Start your Oscam with debug mode 1 (-d1) , and filter on "action 28"
Also filter on "WARNING:"
Fast crashing only occurs under heavy load, parsing the log in -d1 will give more reliable answers.
I've got only two readers for which I have those messages, the other clients never go higher than 3.
And it seems those hosts are slow ones, so it doesn't sound totally illegitimate that they got lost packets.
I'll rollback to 7190 tonight.
The result of filtering "action 28" should result in lines like:
2012/09/02 15:05:21 1CE0050 c add client job action 28
--
If you see lines like:
2012/09/02 15:05:21 1CE0050 c add client job action 28 length 20 ReaderA
.. means that the job-queue has run full (by a bug caused in >7190), and new (send-cache) jobs are ignored / deleted
--
The limit on 20 jobs / delete anything more has been applied by dev Corsair, to prevent Oscam from crashing. (but it still does).
See code here: http://streamboard.de.vu:8001/changeset/7287
Original bug is seen by the dev's, but the cause is still unclear and will be (hopefully) fixed in a future release.
Since yesterday, i'm running 7479...
It looks promising! Memory is rising VERY slow. (even slower than 7180 that i was using before)
6 cache-ex peers only, but anyway, i couldnt run any other version > 7190 because of the memleak)
CPU usage seems to be ok also.
Maybe the new locking mechanisme was the solution...
Posting Permissions
