Opened 13 years ago

Closed 13 years ago

#1811 closed defect (fixed)

oscam svn 5070 still goes to 99% cpu load after a while on arm & i686

Reported by: Madmaxx Owned by:
Priority: critical Component: General
Severity: high Keywords: 99% CPU LOAD
Cc: Sensitive: no

Description

On xscale/arm (wrt350nv2) and i686 oscam svn 5070 and some versions down still has the 99% load Problem for unknown Reason.

The 99% CPU load comes up after 6-20 hours of normal operations and without using the webinterface and or monitor. There a few services defined on booth platforms (was always working and was never a problem before)

On the arm/xscale i have 7 readers without loadbalancer and newcamd only.

on the i686 i have 11 readers with newcamd and cccam clients mixed mode and active loadbalancer.

I´am not sure which one was the latest working version without the 99% CPU load bug.

Can someone from the developers with more local cards and newcamd clients can let run oscam for 1-2 days and watch out for this problem again ?

Change History (8)

comment:1 by Madmaxx, 13 years ago

Today i got the same result. After 24 hours of operations on xscale/arm i got 99% oscam load for unknown reason. Newcamd-only clients.

No useful entrys in logfile that show the "trigger" of this problem.

Actual trunk really needs a longer view in "debug" mode or similar to figure out what is triggering the 99% load. In my case the loadbalancer on the xscale was OFF, Monitor OFF and webinterface OFF, CCCAM off. Only newcamd with 2 clients connected.

comment:2 by Admin, 13 years ago

I can't reproduce this. I have lot more newcamd connections but I don't have that much readers to test with (only 2), so maybe that's the reason.
You could try to kill threads/stop readers via webinterface status/reader page in order to see what causes the load. Could you also post your complete config as an attachment (please don't forget to XX sensitive information but don't leave items away)? Furthermore, any information about since which revision this happens could be helpful.

comment:3 by Madmaxx, 13 years ago

I will today disable for testing the srvids/services. Only thing i know is, that with unchanged config 200-300 SVN Versions before, this 99%-Problems newer comes up. Now i must figure out, what change causes this problem.

comment:4 by Madmaxx, 13 years ago

I figured out, what´s the problem is with the high cpu load:

enabling CCCAM protocol causes 99% load after a few hours BUT: i just enabled the protocol by defining a valid port - but don´t using it. So it is standby here.

The last 2 days i disabled cccam with Port = 0, and now i have no longer high cpu load.

I use just these settings on cccam:

[cccam]
port = 20000
reshare = 2
reshare_mode = 0
ignorereshare = 0
version = 2.0.11
stealth = 1
minimizecards = 0
keepconnected = 1

comment:5 by Admin, 13 years ago

Are you sure that there were really no users connecting to cccam if it is enabled and that also no other program (does not need to be related with oscam; could also be a portscanner for example) accidently connected to this port?
I can't believe that an opened cccam server without any real requests could cause such a high cpu load.

comment:6 by Madmaxx, 13 years ago

Yes! I configured cccam-port only for myself for testing from time to time. NO connection was made in the time of checking!

i think must be some problems with the cleanup-routines or something like, generally when cccam is enabled, no matter it is active used or not.

The high load mostly comes up after 10-30 hours of cccam-idleing. Now with completly disabled protocol, it is stable as before ;-)

on i686 with enabled cccam no high load problems after 3 days with latest trunk. thats courious, so the high load i noted only on the arm/xscale platform.

i will reenable cccam and let it idle with a > 100 numbers newer trunk to reverify again now.

comment:7 by Admin, 13 years ago

If it still exists in current revision, you could try to set "updateinterval" in cccam section (defaults to 240 minutes) to a high value in order to check if maybe that's causing your problem.

comment:8 by john_28, 13 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.