Summary: | KStars hogs CPU until unusable | ||
---|---|---|---|
Product: | [Applications] kstars | Reporter: | Rob <kstars> |
Component: | general | Assignee: | Jasem Mutlaq <mutlaqja> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | akarsh.simha |
Priority: | NOR | Keywords: | usability |
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Callgraph for KStars when in "slow down" state
kcachegrind overview kcachegrind screenshots for each item > 20% (part 1) kcachegrind screenshots for each item > 20% (part 2) HTMesh_performIntersection callgraph EKOS window freezes 1 EKOS window freezes 2 Normal case for comparison |
Description
Rob
2016-04-11 21:03:37 UTC
One more thing: before running on Xubuntu I had tried KStars on Ubuntu and the situation was the same. FYI, I've tried disabling all OpenGL items in the NVidia X Server Settings dialogue and selecting "High Performance" for the image settings rather than "Quality", then rebooting. I've also tried switching off stars, planets and deep-sky objects in the KStars screen so that it is just ground and black sky. Nothing makes a difference so far. Dear Rob I'm sorry that this is happening. Such an issue is rather hard to debug, unless we can find out what KStars is doing / spending time on. If we can isolate the problem a bit more and find what can be disabled to prevent this, we could introduce a patch that has timers to further trace the issue. The other option, if it works is to run KStars on valgrind with callgrind, keep the machinery off until the problem begins, and then turn on the machinery to investigate what KStars is spending most of its time. I didn't read this anywhere in your post, but have you tried turning off the simulation clock? Does that have any impact? I had a similar issue a while ago with simulation clock running. If the simulation clock being off ameliorates the problem, a temporary solution would be to keep it off and update the time once every minute using a DBus command like this: while true; do qdbus org.kde.kstars /KStars org.kde.kstars.setTimeToNow; sleep 55; done; It's very hard to confirm this. I just left KStars running for 3 days straight and came back to only 11% CPU usage. Not different from what it started at 3 days ago. It's usually some issue with graphics driver. Thanks for the comments guys. I agree that this is likely some interaction with the graphics driver. I suggest that we keep this open while I experiment with settings so that we can track the resolution here. I'll also see if I can find the simulation clock in the settings and get valgrind running. It will take a little time to do, hopefully I'll get back with more information next week. Created attachment 98551 [details]
Callgraph for KStars when in "slow down" state
This is a callgraph output from kcachegrind after I loaded it with callgrind output from a session where kstars was started off and got into it's "slow" state.
Above I've added a callgraph that was generated as follows: - Clean reboot of computer - Start kstars under callgrind to generate a callgrind log - Wait for it to get to about 20% loaded NGIC/IC objects - Give up 'cos I know it's going to take too long running this way - Now start kstars in the normal way and find that it is running very slowly - Use kcachegrind to generate the call tree. Now of course this may not necessarily be the case in question but it is most definitely a slow-down and it definitely occurred while starting kstars. Unfortunately I managed to delete the callgrind file while attempting to zip it (:-() so I only have the call tree above and, I will next load, a screenshot from kcachegrind. Created attachment 98552 [details]
kcachegrind overview
The top-level view from kcachegrind of the callgrind tree. Detailed views for each kstars element above the 20% mark follows.
Created attachment 98553 [details]
kcachegrind screenshots for each item > 20% (part 1)
Detailed views for each kstars element in the callgrind tree above 20% (part 1).
Created attachment 98554 [details]
kcachegrind screenshots for each item > 20% (part 2)
Detailed views for each kstars element in the callgrind tree above 20% (part 2).
In case there is anything that looks unusual, I do still have the callgrind output loaded in kcachegrind and i will [attempt to remember to] not close kcachegrind or shut down the computer...! Rob Created attachment 98568 [details]
HTMesh_performIntersection callgraph
One thing: RangeConvex::testTrixel() seems to be recursive: surely that's not good?
Rob
Created attachment 98674 [details]
EKOS window freezes 1
OK, let's try a different attack. The attached callgrind output was taken as follows:
- Run kstars with Valgrind but with callgrind instrumentation off (valgrind --tool=callgrind --instr-atstart=no kstars)
- Use kstars and find that Ekos window freezes up; I can't cause close it or cause other dialogue boxes to appear
- Switch on callgrind instrumentation (callgrind_control -i on)
- Wait a few seconds and switch callgrind instrumentation off (callgrind_control -i off)
Rob
Created attachment 98675 [details]
EKOS window freezes 2
This is another case of the same EKOS window freezing, captured in the same way.
Rob
Created attachment 98676 [details]
Normal case for comparison
This is a normal case, no EKOS window freezing, for comparison.
Note that I'm not at all sure that these frozen windows are exactly the same as the slow-down I saw originally.
Hi Rob, I just made a change that should help performance. If you're using my PPA, please wait until tomorrow and then update and try the new version. That's excellent news, I'll update tomorrow and let you know how it goes. Many thanks. Rob Hi Jasem. I tried sudo apt-get install kstars-bleeding ...last night but no update. Should I have seen one? If you update now you should see a newer version Ah, yes, got it now, testing... Any update? I've not reached a conclusion yet, but results so far suggest: - the latest KStars may be slightly better but the slow down is still there (sorry!) - switching off as much OpenGL as I can in the video driver doesn't help - pausing the KStars clock at launch doesn't help - I needed to increase the speed/use of my CPU fan to keep improve laptop performance in general That said, I've now performed four sessions, rebooting inbetween, without a slow down and the only difference is that setting in KStars to use the computer for time/location etc. rather than the devices. I'm going to leave it running for the evening and then I will try switching KStars back to using device for time/location to see if the problem then comes back. KStars/Ekos/Indi is sooo sweet with this problem resolved, I'm really looking forward to using it for real. :-) OK, I think I have confirmed to my satisfaction that there are two things going on here: 1. My laptop sometimes suffers from a generic slow-down which seems to be connected with the fan not running aggressively enough. Looking at the core temperatures they don't _seem_ excessive (not much more than 60 C worst case) but running the fans more aggressively seems to have removed that problem. 2. Irrespective of (1), if I tell KStars to get time/location etc. from the device rather than from the computer then, sometimes immediately, sometimes after a little while, KStars slowly starts to freeze up. I can see CPU usage start pulsing to max and then I can see 100% of one CPU used, etc. Maybe some sort of beating going on as clocks slip? Or maybe something wrong in my EQMod driver configuration? Anyway, unless you want me to do more experimentation, I'm happy with the workaround of setting KStars to use the computer for time/location as that is more natural for me in any case. |