# Large amounts of data in session properties **URL:** \ **Category:** Ignition\ **Created:** [March 18, 2022, 6:25pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371 "2022-03-18T18:25:56Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 6:25pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/1 "2022-03-18T18:25:56Z")
Hi, I have been having problems with sudden memory growth. I believe that I have traced it to using and processing a large amount of session property memory. When I start a session, I load entries into a list that contains two serials, and a couple of other attributes and store that list in a session.custom property. As the session goes along, the list gets searched and a single entry updated until all serial numbers have been processed. Everything was seemingly fine, memory was steady just showing the usual garbage collection sawtooth, when we were loading a couple of thousand serials. We are now processing some 15000 serial jobs, and the memory use starts growing quickly when we process those. It seems like it is still collecting garbage, but not fully, and the memory use starts climbing. I don’t really know why this is happening, but it does seem correlated with the large jobs. I have put a memory graph below. It is just showing you the start, once it get up to 4 g it says there, it never comes back down in my experience. ![MemoryProblem](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/2/2290e00cb3093a890b12d119dc5ab9a42a367736.png) Where is the best place I can allocate memory for a large list in a session? Or may something else be going on? Thanks ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 18, 2022, 7:17pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/2 "2022-03-18T19:17:19Z")
Everything a Perspective session does is in the gateway, so there’s no “different” place to put something. That said, if you are on 8.1.14, I think there’s a known memory leak. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 7:30pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/3 "2022-03-18T19:30:51Z")
I’m on 8.1.10. Should it normally be ok to store large amounts of data in the perspective session custom properties like that? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 18, 2022, 7:37pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/4 "2022-03-18T19:37:34Z")
I don’t know. I wouldn’t think it a problem, but it probably isn’t very efficient (JSON encodings). Throw more memory at it to see if there’s an inflection point. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 7:38pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/5 "2022-03-18T19:38:50Z")
I just did that, I was at 4096, set max to 8192. We’ll see what happens. Thanks ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 18, 2022, 7:39pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/6 "2022-03-18T19:39:10Z")
At a minimum, make sure these custom properties are marked private. They should probably not be true session properties, but live in some other more persistent datastore, much as it would be ideal to have `session.custom` work for this. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 18, 2022, 7:39pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/7 "2022-03-18T19:39:30Z")
That graph doesn’t look like an Ignition graph. Is it an OS graph? If so, that is normal behavior. Java always keeps OS memory once it claims it. Production systems should have min and max memory allowances for the gateway set equal. Use Ignition’s own memory chart to see if you are wasting memory. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 7:55pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/8 "2022-03-18T19:55:55Z")
It is writing the value of tag [System]Gateway/Performance/Memory Usage once a minute to a database, you are seeing an SSRS report from the database. Are you saying that wrapper.java.maxmemory and wrapper.java.initmemory should be set to the same value? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 18, 2022, 7:56pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/9 "2022-03-18T19:56:51Z")
> [@ken.maze](#): > > Are you saying that wrapper.java.maxmemory and wrapper.java.initmemory should be set to the same value? Yes. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 7:59pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/10 "2022-03-18T19:59:05Z")
There is just this one application running at any one time in a perspective session, so nothing else would be using these custom properties. Would putting them in a document tag be a better solution? I guess it would have the same json encode/decode needs. Now that I think of it, could the constant JSON encoding/decoding be causing this? I wouldn’t think so, but I’m reaching for whatever here. Is there a different session-persistent datastore besides tags? Thanks ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 8:18pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/11 "2022-03-18T20:18:19Z")
ok, will do ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 18, 2022, 9:06pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/12 "2022-03-18T21:06:14Z")
> [@pturmel](#): > > That said, if you are on 8.1.14, I think there’s a known memory leak. This referenced memory leak was actually introduced in 8.1.10, it just wasn't reported and identified until later versions. The use-case here is directly in-line with replication steps, so it's potentially a result of that issue. The fix for the memory leak has been merged into 8.1.16 nightlies and the stable release of 8.1.16 should be in just a couple of weeks. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 18, 2022, 10:23pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/14 "2022-03-18T22:23:21Z")
Thanks, I will be watching with bated breath. I am supposed to put this in another facility this month that does 20x the work that the current one does. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 19, 2022, 3:27pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/15 "2022-03-19T15:27:19Z")
You could always spin up a development server with the 8.1.16 nightly build and see if the problem has been resolved there before you decide to adopt 8.1.16 for deployment. This would give you an excellent idea as to whether or not the build/version would be better-suited for your upcoming deployment. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 20, 2022, 4:58pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/16 "2022-03-20T16:58:20Z")
I set them both toe 8192. The server has 16g total. When I did this my sawtooth got really big, and it has just been idling since I did it, work doesn’t start back up until tomorrow. ![BigSawtooth](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/c/ac665bf1fbf0ffd24b1cfbbc94db22efb79bf70e.png) Is that what you would expect? Thanks ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 20, 2022, 4:59pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/17 "2022-03-20T16:59:09Z")
Good idea, if I get time I will, but I don’t see much time for that in the near future 😀 ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 21, 2022, 12:19am UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/18 "2022-03-21T00:19:19Z")
Yes, that sawtooth looks reasonable. The previous max was probably a bit too low. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [March 21, 2022, 6:39pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/19 "2022-03-21T18:39:11Z")
Would this memory leak bug be bypassed if I used a Document tag to store this instead of a perspective property? ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 21, 2022, 7:10pm UTC](https://forum.inductiveautomation.com/t/large-amounts-of-data-in-session-properties/57371/20 "2022-03-21T19:10:56Z")
Not necessarily. The memory leak is encountered when a Perspective property changes value. Assuming your new property is bound to the document tag, then the property would update as often as if you’d just written to the property in the first place.