Maybe try scripting something using system.tag.deleteTags()? It takes a list of tag paths so if you grab a list via system.tag.browse or system.tag.getConfiguration. Check the manual pages for more information on them.
If you go to the Gateway under Status > Systems > Tags, what is your tag count? Does the Gateway crash when you delete just a few tags? Finally, do you have the tags organized in folders in the Tag Browser?
After leaving the Gateway overnight, the tags have been deleted. Thus, I believe deleting the tags with scripting did in fact work. If anyone else does encounter this issue I would recommend delete the tags in chunks using scripting, as suggested by @ryan.white.
I used the following two functions in the script to access the paths and deletes the tags, respectively:
It should be noted that these tags are were added to a laptop that I am using for development, not a dedicated Gateway PC. Could it be possible that the limited resources of the laptop could be the culprit?
Then something else is going on. By "crashed", do you mean the gateway process died (and restarted itself)? Or did you get an "Internal Error" on the gateway web interface? The latter is not a crash, and commonly occurs when the config database is locked for an excessive length of time--common with bulk tag operations.
Yes, this. But it stayed like this for over 20 minutes, which made us restart the gateway.
Support took many looks at our environment, we designed the whole system together with Kevin McClusky from IA.
Yes, the internal database is single-threaded, and all of the changes to tag configuration have to be written to it. (Which explains why your CPU wasn't pegged.) This is one of the few cases where the speed of the gateway's own storage devices matter. If you had continued waiting, your system would have eventually finished the bulk tag operation.
I've bumped into this many times this year as I test my EtherNet/IP driver with PLCs of tens and hundreds of thousands of tags. But the delays using NVMe storage are tens of seconds, not tens of minutes.