Comments
Sort by recent activity
I can also confirm that adding the SQLMONITOR_Indexes system environment variable with a value of 0 to the base monitors and restarting them does bring back the stability. I have also received notification of the release of 13.0.43 this morning; however, it appears that release notes have not been published yet. Does 13.0.43 address the stability issue introduced by the Indexes feature? / comments
I can also confirm that adding the SQLMONITOR_Indexes system environment variable with a value of 0 to the base monitors and restarting them does bring back the stability.I have also received notif...
TheRealAndy said:I've turned off the indexes feature flag and SQL Monitor has been more stable. SQLMONITOR_Indexes = 0 system environment variable:
Interesting. This is the new indexes tab feature mentioned in the release notes for 13.0.38 that you are referring to, right? I believe the new indexes tab feature, was added with version 3.0.38, which checks with the timeframe that I started having stability issues. So perhaps disabling that feature until Red Gate works the kinks out will make it more stable. I tried looking though the documentation for information on the environment variable SQLMONITOR_Indexes and could not find any. But I guess the answer would just be to set it as a system environment variable as you described above and see if it helps. One question though that comes to mind since I run a multi-base monitor setup is would this need to be set on the Web host, the Base host or both? Having to recycle the systems daily now is getting old and if it's due to this new feature, I am happy to disable it.
/ comments
TheRealAndy said:I've turned off the indexes feature flag and SQL Monitor has been more stable. SQLMONITOR_Indexes = 0 system environment variable:
Interesting. This is the new indexes tab fea...
I upgraded to 13.0.42 yesterday and still had issues with the memory and loading problem today. / comments
I upgraded to 13.0.42 yesterday and still had issues with the memory and loading problem today.
I have also noticed stability issues with the product. Though I can't pinpoint when the exactly problem started, it seems that it was sometime after version 13.0.35. I will be starting a new thread with more detail. / comments
I have also noticed stability issues with the product. Though I can't pinpoint when the exactly problem started, it seems that it was sometime after version 13.0.35. I will be starting a new thr...
Thank you for the response Jon; however my fundamental issue is that pruning of my already alternatively configured path (per https://documentation.red-gate.com/sm/performance-and-activity-monitoring/dashboards-and-overviews/server-overview-pages/sql-server-overview/performance-diagnostics/top-queries/configuring-top-query-search), does not appear to be functioning. I am picking up that it's supposed to work, but when the vast majority of the timestamp of the files is well older than a week, it seems that it is not functioning as intended. I guess I need to open a ticket to have it looked at, but I believe it's an issue in the product. / comments
Thank you for the response Jon; however my fundamental issue is that pruning of my already alternatively configured path (per https://documentation.red-gate.com/sm/performance-and-activity-monitori...
I'm glad to hear that. Thanks for the update Greg! / comments
I'm glad to hear that. Thanks for the update Greg!
I noticed that 13.0.25 was released. I then updated the two systems that I had rolled back to 13.0.23 to 13.0.25 and noticed no ill effect on SQL Server performance. After confirming that to be the case I updated the rest of the SQL Monitor hosts to 13.0.25 and all looks good. Thanks for resolving this issue. / comments
I noticed that 13.0.25 was released. I then updated the two systems that I had rolled back to 13.0.23 to 13.0.25 and noticed no ill effect on SQL Server performance. After confirming that to be ...
I recycled the base monitors connected to the specific database server that is having issue and CPU went back to 100%. So something is going on with this release and SQL Server. I am going to roll this one back and see if it resolves the problem. I will first run a schema compare to see if I need to rollback schema changes as well. / comments
I recycled the base monitors connected to the specific database server that is having issue and CPU went back to 100%. So something is going on with this release and SQL Server. I am going to rol...
So I'm not sure I fully understand this, but after the CPU being cooked for about 18 hours and SQL Monitoring showing the query I provided as the culprit, the issue has calmed down. I assume that perhaps a better execution plan might be the answer. But things now seem better on my end. So for anyone who wants to try 13.0.24, you may not have the same experience I had. But proceed with caution. / comments
So I'm not sure I fully understand this, but after the CPU being cooked for about 18 hours and SQL Monitoring showing the query I provided as the culprit, the issue has calmed down. I assume that ...
Two base monitors in my multi monitor config are having issues with 13.0.24 in that they are running stuff that is absolutely spiking the CPU on the repository database server and after rolling these two back to 13.0.23 the issue resolved. But what's interesting is it's only two base monitoring systems that are having this issue. All of the others seem to be fine on 13.0.24. So what exactly is different on the two systems not liking 13.0.24, is something I haven't been able to figure out yet. I guess it's time to grab the logs and submit a ticket. / comments
Two base monitors in my multi monitor config are having issues with 13.0.24 in that they are running stuff that is absolutely spiking the CPU on the repository database server and after rolling the...