Issue with large number of memory tags in Ignition

Hi,

I have an Ignition (8.3.3) container in Docker; the project has a considerable amount of memory tags and OPC tags.
Due to the number of tags, the file valueStore.idb located in the folder /config/Ignition/tags has a big size, sometimes even several GB, and in this case, when this file is big, I guess due to the persistence of the tag's values, the container does not start because Docker seems to reset the container before the gateway completes the start process.
In those cases, I had to remove the valueStore.idb file to allow Docker to start, but the tags start with the null value, due to the missing file.

I have tried to increase the start time of the container, but it does not work properly, and sometimes the container gets stuck in starting and reboots itself, causing the gateway to stay in the starting process forever.
When this happens, the workaround is to delete the valueStore.idb file and restart the container, after that Ignitions starts normally.

So, is there any way to handle this in Docker to let the Ignition start properly, considering that for the amount of tags, the start will be slow?
I already tried with this in the compose file:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8088"]
interval: 30s
timeout: 10s
retries: 10
start_period: 60s

But it does not really change the behavior
I want to keep the tags' persistence if it's possible, but for now, I have changed the provider to non-persistence to avoid this issue.

The number of the tags is over 10 000, but I am afraid I need them all, so I can not reduce the number of tags.

I am open to any suggestions. Thanks in advance.

Best regards,
Daniel Fernandez.

What are you storing in these tags? Is there no way to store this data in a database table (Or Multiple) and fetch on startup/demand?

Hi,

Those tags store information for intermediate calculations, the memory ones I mean; their persistence is useful just in cases the gateway stops or crashes, so yes, it's possible to store them manually in a database, except for the crash events, that is the main reason for keep their values, but I don't know if it is the best solution due to the purpose of those tags, as I mentioned the persistence is useful just if something happens to the gateway not all the time, those tags are auxiliar tags, but I guess is an option, thanks.