I accidently added all of the controller tags from a PLC, including thousands of tags I do not need.
Every time I attempt to delete the tags the Gateway crashes and I need to restart it. Are there any tricks or tips to deleting a large amount of tags at once?
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?
I appreciate the suggestion. Unfortunately using scripts resulted in the same issue.
I checked the tag count is 138,118.
I am able to delete tags one-by-one. But obviously that will take a long-time.
All of the tags I am looking to delete are in one folder, which contains sub-folders.
Make the script delete in chunks, like maybe 100 or 1000 at a time? Then either let that loop a few times or manually run it a few times until the number gets a bit more manageable?
We had a similiar issue deleting a large amount of tags, but in our case it only crashes when the tags are inside the UDT area.
Only solution was delete by smaller batches.
The issue in our case was related to the internal configuration DB getting locked and creating a cascading lock.
and
We all seem to be thinking the same thing...
@Liam_Dietrich I know its not an instantaneous solution but might be worth a shot. 
Thank you @ryan.white, @GregCavazos , and @Estera_Cioroch for the suggestions.
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:
system.tag.browse()
system.tag.deleteTags()
IMO there is something else going on. I would get support involved. I have deleted over 140k tags and while it did take some time, maybe 20 seconds, it didn't crash.
Appreciate the recommendation.
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?
I'm on a laptop as well, and using the "stock" gateway settings. Ignition is installed on the host, not a VM.
We have the same issue. Deleting large amounts of tags crashes the server (8.1.26).
Isn't this something IA should be able to fix quite easily?
No, tag deletion (or bulk creation) is a very memory-intensive operation, and the defaults in ignition.conf aren't sufficient for manipulating tens of thousands of tags at once. (In most cases.)
Use better gateway hardware with more RAM for Ignition, or discipline yourself when working in wimpy systems.
Our RAM and CPU are not going over 30% while deleting, we are using pretty good hardware here.
I'm not saying tag deletion would not be intensive, but I do believe standard actions like tag deletion you execute in the designer should not cause a server crash in any case.
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.
Consider having support look at your environment.
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.
Not a bug, really. Just slow.
Ok, thanks for the explanation. The single-threadness explains the cpu indeed.
So it could mean our storage is slow? This is maybe something we could take up with support.
Edit: Our storage is not NVMe, but SATA