I just realized maybe part of the extra CPU load could be from the extra debug information my current build is generating....the CPU usage might be a complete red herring.
I have a maintenance window scheduled for tomorrow night.
I wasn't able to do the install on Wed night but I did tonight. I'll have an update sometime tomorrow morning, I expect.
Thanks, again.
Jason
Unfortunately, I can report that the latest build 12.6.2 (beta) didn't seem to have any positive effect on the problem.
Can you confirm you tried changing the notify_max_time setting? What values did you try setting it to?
Jon, sorry, I forgot that there were additional recommended values to try. I tried 200. I'll do some playing around with that setting. Should it take effect immediately or do I need to close and reopen Opus?
I haven't yet tried to do anything with notify_min_items. Should I?
Please try setting it to 0, then restarting Opus, and wait a couple of minutes, then see if the problem still happens.
sorry,. which parameter should I be setting to 0? It's not clear to me which one you're referring to, Leo.
Apologies, I meant set notify_max_time to zero.
I am also able to add now (I wasn't sure of the correlation before) that when Opus isn't showing updates we are also having a problem using DDE to communication between a programming environment and Excel. One of the things we do is use DDE to read and write data to and from Excel pro grammatically. When the Opus issue is happening those interactions with Excel are extremely slow (minutes compared to the usual seconds).
I don't know if that will help you understand what's going on but I'm certain that the 2 things are correlated.
Regarding my earlier comment that I would look for things on the server that might be involved in this issue: I've been unable to find anything that I can correlate with the issue.
Leo,
Thanks, that's what I had guessed and it's set that way now. I'll post an update when I have one.
On another note, can you tell me how best to quote a previous post in this forum?
The issue continues with notify_max_time=0.
I am going to try to see if there's a specific frequency and duration to this issue. I'm starting to suspect that there might be and if there is that might be a further clue.
Select text and a quote option will appear.
What's the CPU usage like when the issue is happening, with it set to 0?
Is the lister still responsive to mouse input and so on?
I've sent you a private message with a link to a new version to test.
(Please also don't overlook Leo's questions in his previous post).
I've seen it happening when the CPU usage by Opus is low (like when I'm the only one logged on for example) and when it's unusually high (every single instance is using a percent or 2). The CPU symptom feels like it might be a chicken and egg situation .
FYI: We experienced a very unusual problem with the latest version of Opus 12.6.2.(beta) today. Nearly every instance of Opus was using ~1 GB of RAM or more. I've never observed that before and unfortunately I was away from the system so I don't have any idea what was going on at the time. From my logging system I can see that CPU usage was within normal limits.
I'm expecting to be able to install it tonight, thanks!
The RAM usage may mean the change notification queue is growing faster than it can be processed for a time, although it looks like things recovered to normal as the high values are in the Peak column not the current one.
Similar temporary memory usage could also be the result of showing a folder in thumbnails mode (which can use a lot of memory to load all the thumbnails in memory) and then closing the window, or archiving files (7z can use large buffers), or other operations that use a lot of memory but then release it.
If it was due to the change notification queue, the version Jon sent will likely help with that as it will collapse redundant events in the queue (more so than previous versions) so that far fewer events need to be processed.
Thanks, so far I've not had any luck tracking down what happened and no one has responded to my request about possible user actions that I thought might cause it (FlatView'ing the root folder of our primary network share which contains millions of files and surely tens of thousands of folders, or searching a very large set of files for particular text content). What I find odd is that all the instances would have been using such a large amount of RAM at some point. I can imagine that for the notification queue but it doesn't quite make sense to me for much else; even the stuff I mentioned earlier, to be honest. It seems that only certain global things should cause all the instances of the EXE to have a memory spike at exactly or at least roughly the same time.
I agree that the capture shows historical information about the RAM spike for the dopus.exe processes and that it did recover. Also, the issue has not recurred to my knowledge.
I really don't know if this event has anything at all to do with this current issue hence the FYI phrasing.
Let's hope that the version Jon made for me to try will sort out the notifications issue. If it doesn't then I think I want to revert to a debug version that logs the notifications to DebugView and then probably get some information from you that will let me extract a list of all the events that are in the queue when the issue is happening. If the issue is really just too many events for Opus or any other software to be able to deal with then I think I would suspect that something unexpected is generating such large volume of events and I'll want to track that down.
1 Like
Agreed, having the spike happen for everyone does point to something happening on the machine, more than something a user did.
The only user action I can think of would be something like one person creating a file in an area that everyone else had a window/tab displaying, and that file causing high memory use while it was inspected by each person. (The temporary memory spike for that is unlikely, but not impossible, especially when factoring in third party components, antivirus, etc.)
If it was notifications queuing up, it seems to fit with other things we've seen, and hopefully Jon's change will improve things there. Either way, it's worth knowing about as another part of the puzzle. Thanks for spotting it and letting us know.
I've now installed the version that Jon provided (12.6.2 beta build 6498). I'm now waiting to see if the problem recurs. So far I haven't seen it happen but I haven't been able to spend much time watching for it.
1 Like