If I look at the status in ViewX I can see that there are a few hundred or more Outstanding Template Transactions and it's processing maybe 4 or 5 each second.
I have a little faster PC at home and when running the same import on a copy of the same VM there are no Outstanding Template Transactions. That don't seem right but when I look at the PointNumber they have been updated.
The import only has the FullName, Name, OutstationId and PointNumber columns.
I say it don't seem right as I've only run the import on the VM on the work PC before now and it has always been this slow.
I suspect that the system that is slow has additional load to it, like field communications, other clients connected etc.
It possibly also has badly configured anti-virus or other things which are resulting in overall bad system performance.
Template Transactions can only be processed if it can obtain and action a database lock. So you should check your current lock statistics. You want these to be low (less than 10% total time in lock is typically good enough).
If there are template transactions then you are obviously updating a template, so you might want to have a look at the release notes of new versions of Geo SCADA, there have been some improvements to template propagation in recent releases.
It's a virtual machine and I just copied it from my work computer to my home computer and the network is disabled in the VM. The host machines are clean Windows 10 installs with nothing else really installed other than Microsoft office. The task managers on both look very similar for CPU usage and hard drive usage before during and after the imports. Also, one of the first imports I did was typical or what has been typical where you always have to wait while it completes the template transactions before you can do any new modifications. So I've gotten in the habit of checking the status and seeing how many are left. It took a while to figure out the first time that happened as I'd run an import thinking it was done and then want to make new changes or continue working on the application and didn't understand why I couldn't make any new changes. Now seemingly out of nowhere the VM on my home computer finishes the import instantly with no transactions and when I go in and look at the settings I wanted to change they appear to be changed.
Normal to me is using the bulk edit tool to do an export, the export is usually very fast under a minute or so if that. Then after modifying the CSV I run an import and that's usually much slower and you can see the process and the status bar at the bottom of the bulk edit tool. After that's done I go in and look at the status and normally see a few hundred or after larger imports at few thousand outstanding template transactions. But now after moving the virtual machine from one computer to the other and doing an original import that did show outstanding transactions now no longer seems to show any outstanding transactions even if I do a large test export and import. So that made me think that something's been wrong all along and is now changed but it's still wrong on the other VM.
It's almost like when you do an import in ViewX and you're like wow that was fast and oh it's got an error of some kind in the messages so it didn't actually run the import, that's why it finished so quickly. This seems to be finishing unbelievably quickly with no errors. So that's one of the first questions, is it normal to see a lot of outstanding transactions that take a long time to clear. Is it normal to see any. My home computer may be a little faster but not to the point where something that takes now 10 to 15 minutes on a previous instance of the very same virtual machine is now instantaneous. Like now it's fast enough to finish the same time the bulk edit utility finishes.
I'm not sure where to read the total time in lock. I did find the server status read write lock diagnostics but there's hundreds of rows and I'm not sure if you're just looking for the row with the longest time in readlock percentage. There's only one above 1% background integrity check at 1.7%.
Found the mouse over DB Lock Usage and the VM on the slower work PC is at 37.5% and the little faster home PC is at 39.6%.
A base copy of the same VM before the import of the current app is resting at 4.0% on the same work PC.
'before the import of the current app'... you mean a completely empty database has 4% lock? That doesn't sound right.
~38% isn't a good number to have your lock rate at steady state.
It's not going to kill your system, but you will suffer some significant performance lags when making DB configuration changes.
You should probably get someone to audit the system to determine what items are resulting in the high lock ratio, and to get that lower.
Configuration actions typically don't get actioned instantly through out the database. They need to propagate from the top down to the bottom, and to do that it needs a lock on the database. If your system is already locked close to 40% of the time.. that doesn't leave much of a window for the template propagation events to occur (which will themselves increase the lock ratio also.. since they need to get a lock to make the changes).
You should also note that Windows 10 is not recommended as a server environment. It prioritises UI events above background service tasks, which is definitely not desirable for a server. It also has licence limitations that means that in most situations it is not allowable to be used as a server (you should read the Microsoft Windows EULA around this).
Discuss challenges in energy and automation with 30,000+ experts and peers.
Find answers in 10,000+ support articles to help solve your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!