Not really sure if this is a program thing or a pc thing. After doing the newest update to v1.0.207, I noticed a few days later my machine started to slow down. I typically leave Openbuilds Control running in the background as I have a project in works. I started looking at the pc and found under Task Manager that Control was using about 13 GB out of 16 GB available. I wasn't able to end the task, so I had to reboot. When it came back up I removed Control and installed v1.0.205. It appears to be OK now, after a few days. Just wondering if you have heard of this happening before, like a runaway memory incident?
Was one other report like that maybe a year ago, but never happened again. Keep an eye on it, if it happens again it'd be interesting. Just once is probably just Windows doing something weird
OK; updated to v1.0.207 yesterday and today it started to show up again. got some screen shots showing task manager in the process screen as well as performance screen. Before and after ending Control task. Did notice it took about a minute for the memory to drop back to normal. Then control is back at where it was before. Sequence of task manager pictures are usage1, usage2, after back on 1, after back on 2
The worst case ram usage from CONTROL according to the screenshots is around 443mb, which is not unheard of (could be busy downloading an update in the background, or have some loaded gcode) So not sure why Windows was using as much ram, it wasn't allocated to CONTROL. I suspect closing CONTROL just forced it to flush the cache (see below) If CONTROL was using the RAM, it would should up in the memory/cpu columns of the detail view in Task Manager You can test this theory, next time it sits there with Windows using a lot of ram, by going to Start, Run and pasting Code: %windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks Give it a couple minutes and see if start going down? What that does is, instruct Windows to begin processing pending system “idle” tasks. These are hidden Windows tasks that are performed in the background when system resources aren’t being used. If that's the case, you can look into disabling things like Windows Superfetch etc, but then at least it rules out CONTROL. Also try RAMMap - Windows Sysinternals - its much better at helping you trace memory allocations than Task Manager (don't forget the tabs along the top - more details)
Hi Peter I had already disabled superfetch a couple of days before after seeing the drive bottle-necked for half an hour at 100% but I will try the other when it comes back. Thx
I'm Back Seems to have lasted a week. This morning memory pegged, and disk said 50 %, but if you displayed the drive it was a lot higher. downloaded and installed RaMMap. I'm attaching my screenshots with task manager and RaMMap. Only weird thing I saw was a brief flash of a memory error as it was shutting down. Wasn't able to really see the message, it was in a little box just below and left of center screen. Could it be something like a memory hang that avalanches when accessed? Just a hairy assed guess .
In that one OpenBuilds is using 1.2Gb of RAM (less than 10% of what you have), what'd we typically see with a largish gcode job (3d Viewer objects take quite a bit of ram if its lots of short segments) - nothing looks out of the oridinary in that. OpenBuildsCONTROL doesn't use your disk for anything, so can't tell you why its that busy. There's still nothing pointing a finger at CONTROL. Maybe a visit to the local IT guy? (malware scan etc)
