-
-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
increased CPU and/or memory usage over time #553
Comments
@segordon - do you compile from source? I have a patch to test. If not, I'll upload a binary. |
Have been using the binary releases, but can compile to facilitate trouble-shooting. The problem persists in 1.2.504. UI lag accompanied by abnormal CPU usage @ the 18hr mark. Will now compile from source and test the new commits. |
Getting software versions lined up for compilation is a pain in the neck on my platform -- a binary test release would be much appreciated. If I don't hear back in a few hours i'll spin a *buntu VM and tackle compilation again. (what ever happened to a nice make file? I feel so old nowadays ... Kidding ;) ) |
I really have no idea where the issue is. There are two options: I assume the issue only is in the montage screen? Can you confirm? Here is a test build: What I'm doing is reloading the montage screen every 1 hr - please see if that helps. |
I have the test build running -- i'll let you know how it's going in a few hours.
I've only had the problem develop in montage mode (since the app sits in that mode 95% of the time), but I cannot confirm whether or not it would eat CPU if it were sitting in a different mode. Can try that next.
Is this the same type of reload that occurs when one changes modes from the hamburger menu (say from system status/settings to montage/events) ? If so , I have done that manually when I felt the UI start getting sluggish with little to no effect on symptoms. As for the electron stuff -- yeah I understand. If electron is eating CPU cycles that fast for us then I can't imagine the havoc it's causing elsewhere -- at least if the problem is on that side it'll probably be hunted down pretty fast. Anyway, I have it running. I'll let you know how it goes and report back. |
Looking good so far. Caught the montage reload; CPU usage on the main thread dropped from ~7-9% back down to 2-5%. The rendering thread sits consistently at about 15-30% regardless, but doesn't seem to inflate from there. No UI sluggishness yet, either. Will continue testing. |
I haven't yet seen the memory usage inflate with my particular problem, but I'll keep an extra close watch this session to see if I notice it change. I'll test with 1.2.504 too to see if I can trigger the sluggish UI problem again and take a look at the memory usage. I'm fairly sure that memory usage was tame when I saw the CPU pegged, but I don't have any logs saved. Not by any means saying the problems are unrelated, just being specific in the interest of helping to track this down. |
New test build ran smoothly all night. No noticeable resource inflation. Great! Reverted back to 1.2.504. The primary zmNinja process is sane, with no unusual CPU or memory inflation. '--type=renderer' process, forked from process above, pegged at 80-100% usage after 4 hours of montage view. Sluggish UI. Memory use slightly elevated, from an initial 670m reserved at startup to now about 830m reserved at 4 hours of use. The montage reset in the new test build seems to keep the renderer process subdued in the short-term. Haven't tested long enough to rely on it solving the issue completely. |
Thanks for the reports - I'll wait for confirmation from you before I can close this out. I'll keep this running on my android phone too tonight. |
Test build still looks good. No unusual resource allocation. Montage reset timer appears to have worked -- I'll keep an eye on it, but the former build would've ate itself many times over by now. I'd say this hack is a success -- at least until the real cause is found. I think it might be a good idea to revisit this later on -- either when electron and the supporting software matures a bit longer, or we get more eyes on zmNinja. Non-conditional watchdog timers are usually not that great of a way to deal with these sort of gremlins; and if this is ends up being an issue with one of the underlying libraries we might wake up one day with this problem disappeared for us. Thanks for all your effort! |
No problem. I can confirm my android phone survived an overnight montage onslaught as well. I actually don't think its an electron issue. Its either my app, or Angular/Ionic framework itself, because this happens on phones too. |
@knnniggett recently reported this 'force reload' causes issues in Android 4.4 (crosswalk build). I could blame him for being the only one that uses 4.4 ;-) but I guess its time to revisit. Still keeping this closed - I'll reopen when my spirits are raring to dive into this |
Now, now, my odroid is open and free. I only noticed the issue with android 4.4 on my way up to android 7. Sounds like a good idea to wait to look into this, however. If someone else reports it, we will know exactly what to look at. Since I am likely going to forget what the error was, I'll post it here:
|
@pliablepixels @knnniggett what issues were experienced with 4.4? I have a 24 inch tablet that I use as a wall-mounted ZM head that runs Android 4.4.2 that began experiencing API connection failure messages on force-reload. The only way to reconnect to the ZM server is to kill the process and reload it completely. Is this similar to what you're seeing? I haven't done much to diagnose it yet since it's easy enough to reload the app, and I hardly use the tablet (and i've been lazy) -- but if we're seeing something similar I can provide logs. (I band-aided it by sitting the tablets' browser on the image stream for the camera that mattered; but i'd prefer to use zmninja again on that head) |
Sounds like you've noticed the same issue. After 60 minutes of runtime, zmninja re-authenticates with the zerver. However, when I loaded Android 4.4.4 on my test machine or ran the test on my Galaxy Pro tablet w/ Android 4.4.2, the screen would flash but then zmninja would go to the to API failed, see the FAQ, screen. I have to completely exit zmninja and restart it. It's like it silently gives up. No errors are visible in the zmninja log or the web server log. The logs you see in my previous post are from running logcat at a rooted command prompt. Since it sounds like you are using zmninja for the same purpose, I'd be curious to learn what hardware you are using. Do they really make a 24" tablet, or is this something you have built? |
grudglingly reopened two people in the world are still using 4.4 :-)) |
@knnniggett https://www.nabitablet.com/nabi-big-tab-hd24 . They are a re-brand of some other Chinese group. They come loaded with a bunch of kid stuff, but they are rootable, and make a nice wall-mountable surveillance head. The resolution isn't that hot, but they can be had for pretty cheap. That said : I wouldn't expect updates for it, and i'd keep it on the private network that we all keep around for shady overseas network devices. (we DO do that, right?!) |
Wow, it's even 1080p, and to think I was going to couple an odroidxu4 to one of these instead: Talk about paying more for less. |
That's almost exactly what I was going to do initially. The big tab is a nice solution if you just want a surveillance head to run zmNinja on, but the odroid will always offer a lot more flexibility for future projects. I just needed a screen for my elderly parents to look at a surveillance camera on, and it worked beautifully for that. As a tinkerer i'd probably go for the odroid otherwise. |
@segordon I have an APK that seems to be working with Xwalk (android 4.4). Would you like to give it a try? If so, please shoot me an email (pliablepixels gmail) - give it the usual soak test - overnight, and if it also continues to help with CPU like the original version did |
closing, please follow #598 |
(Edited by @pliablepixels - this issue affects devices as well, not just desktops)
Platform & OS Version
Linux x64. Arch. Kernel 4.14.r1028.g1122
The version of the app you are reporting:
1.2.503D
Device details:
Lenovo D30 workstation. 2x Xeon E5-2660, 32gb ECC RAM
What is the nature of your issue
BUG
Details
Increased CPU usage over time. Main process slowly creeps from 1%-3% to 100% over 50 hour span (could be shorter, gathering data now regarding how aggressively it eats CPU.)
UI becomes sluggish/slow to respond with relation to resources taken. Requires non-graceful forced exit at its' worst.
Let me know what I can provide to help. I'm going to upgrade to 1.2.504 to see if the issue is resolved, but I didn't read anything regarding this problem in the CHANGELOG...
Thanks!
The text was updated successfully, but these errors were encountered: