We have redundant Ignition Gateway 7.7.8 and 4 workstation with Ignition client.
Multi-monitor structure (2-3 monitors) is used on each workstation. Ignition project is very big and customer wants to display a lot of charts for a long period.
Maximum client memory is set to 4 GB (maximum value), because project is too heavy.
Ignition client application freezed and not unfreezed (client restarted after 5 minutes by operator) 6 times in the last week. This happened on different workstations.
After that we started to monitor clients state by VisualVM. It’s displayed that
heap used =2-3 GB
heap size = 3-4 GB
We have not log when clients freezed.
How to increase the maximum heap size on clients or decrease memory usage without project change ?
[quote=“HooK’a”]… customer wants to display a lot of charts for a long period.[/quote]Sounds familiar. I wrote a module to optimize handling of very large chart datasets for multiple client displays. You can find it here.[quote=“HooK’a”]How to … decrease memory usage without project change ?[/quote]I wouldn’t hold my breath waiting for a magic solution. You’ll almost certainly need to go through the project window by window eliminating duplication, finding overly aggressive bindings, and auditing event script performance – all to pinpoint wasted memory and CPU time.
HooK’a, a 4 GB Client JVM should be more than enough for all but a few applications. My recommendation is to look at the actual setup of your charts, tag history settings used, and the database performance. As pturmel noted, there is not going to be a magic solution here - if you are querying a lot of data frequently and / or simultaneously, you will eventually overwhelm the system
If you’d like to put the effort into optimizing the application, here are some things for you to look into:
Check how tag history is logged. To avoid unnecessary logging:
Make sure “Max Time between records” setting is set to “unlimited”
Make sure you are making a good use of deadband settings.
Check how data is retrieved.
For the Easy Chart component:
Slow down the poll rate (use the Easy Chart’s “Poll Rate” property)
Adjust Tag History Resolution and Tag History Resolution Mode to make sure not too many datapoints are being requested
For the History provider settings (in the Gateway, under Configure > Tags > History, click “Edit” next to the provider name)
Is partitioning used? How are tables partitioned? (monthly partitions are default; you will typically want to set your partition size such that most of the time the queries do not have to span multiple partitions)
Check the health of the database (if you are not familiar with SQL databases, you may want to ask your database administrator for help with this one):
Are there too many entries in the sqlth_sce table? ( If so, you may need to contact Support for help cleaning it up)
How many entries on average does a partition table (sqlt_data_*) have? 100K? 500K? Over a million?
How many rows are there per tagid for the time range normally requested by the chart? How long does your database take to return that data if queried outside Ignition (e.g. using your database’s default front end software)? If it’s taking too long, you may need to rebuild index(es).
How good is the network connection between the database and the Gateway?
There may be other things to look at, but this should give you enough to start.
We decided problem with heap size by switch off cache of window but time of window opening has become uncomfortable.
We are also seeing slowdown and freezing at the moment when number of opened charts is over 30.
anna, regarding your post:
“Max time between records” is set to “1 minutes”, otherwise we had problem with the realtime chart (graph started from middle of the subplot).
“Deadband” is set to default value, we didn’t set up it.
How does value mode of store history affect on the client ? It’s only affected on the server performance, isn’t it ?
“Poll rate” of the charts reduced to 2 seconds, the customer doesn’t agree with further reduce.
Initially following values were set:
“Tag History Resolution Mode” to “Fixed”
“Adjust Tag History Resolution” to “0”
Now we have attained the best result with following value: “Chart Width” and “1”.
A long time ago we discovered that partitioning should be used by “one day”.
Pre-processing is used.
squlth_sce table have 4500 entries.
sqlt_data_* (per one day) tables have 5kk entries.
System stored per tagid about 6k rows everyday. The customer prefers to use 4 day period for charts (The customer has a similar system on DeltaV and he wants to make it all likewise).
MySQL database installed with ignition on one server. The clients connected to server by 1GB ethernet which loaded only for 0.5%.
[quote]How long does your database take to return that data if queried outside Ignition (e.g. using your database’s default front end software)? If it’s taking too long, you may need to rebuild index(es).[/quote]It needs to be done while few charts are open and everything is fine, and again while many charts are open and they are bogged down. With daily partitions, the indexes are unlikely to be a problem. I suspect you’ll see that your database is simply overwhelmed.
If so, you have two courses of action to pursue:
One, put a really big and powerful database on a separate machine.
Two, redesign your data storage to use wide tables instead of Ignition’s tag historian. You lose some data storage efficiencies that the tag historian offers (deadband & variable recording intervals) on a per-tag basis, but for steady recordings, indexes and table metadata are substantially reduced. Historical transaction groups exist for this purpose. Then you can get much more data for your charts into single database queries, and it becomes possible to cache data (like with my module referenced above).
The client computers hard-locked due to unstability of the R7 260x graphics card installed in them. As a result, we changed graphics card.
The Ignition clients dead-locked due to open windows script.
We used the following script:
Window = system.nav.openWindow(Label)
Window.setLocation(x, y)Sometimes the clients dead-locked when trying to relocate the newly opened window, we solved this as follows: