# Ignition 8.3 - ignition/var/data to /shm (RAM)

**URL:** <https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [January 28, 2026, 10:08pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614 "2026-01-28T22:08:35Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![adam.haney](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@adam.haney](https://forum.inductiveautomation.com/u/adam.haney)\
**Post date:** [January 28, 2026, 10:08pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614/1 "2026-01-28T22:08:35Z")

</div>

**Background:**

Host: Ubuntu 24.04.3 running Ignition 8.3 gateway with Perspective as target.

We have a relatively data intensive application with a database written to both by Ignition and a separate application. We have been tuning the relationship with the database, as we’ve experience high write cycles on our SSD, largely due to the external application (which we are mitigating through changes).

**Question:**

One of our engineers recommended moving ignition/data/var to /shm (RAM storage, I’m not a Linux guru) to reduce write operations to disk from Ignition. I’m looking for any feedback from Ignition experts on if this is a NASA Challenger-level bad idea or okay. As I understand it, the biggest issue is volatility on power cycle, so certain loss of data on power up, but I am most concerned with the Ignition application starting properly and running.

Thank you. Disclaimer: I’m dumb.

---

<div class="post-metadata">

**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:** [January 28, 2026, 10:14pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614/2 "2026-01-28T22:14:25Z")

</div>

Make a new mount point with a `tmpfs` (/shm collision would worry me.)

Move your **database**'s tablespace to this mount point, and use DB-specific settings to mark it transient. (MEMORY storage engine in MariaDB, for example.)

(Your database shouldn't be in the same server as Ignition, anyways.)

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 28, 2026, 10:16pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614/3 "2026-01-28T22:16:29Z")

</div>

Do you have some evidence that `$IGNITION/var/data` is even seeing a lot of writes?

Anyway, I wouldn't do it. It's not a temp directory.

---

<div class="post-metadata">

**Author:** ![adam.haney](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@adam.haney](https://forum.inductiveautomation.com/u/adam.haney)\
**Post date:** [January 29, 2026, 3:13pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614/4 "2026-01-29T15:13:59Z")

</div>

@Kevin.Herron I believe `iotop` was used but I’m not sure the exact amount of throughput to the hard disk from Ignition.

But based on your feedback and @pturmel, we will remove this change to our system.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [January 29, 2026, 5:30pm UTC](https://forum.inductiveautomation.com/t/ignition-8-3-ignition-var-data-to-shm-ram/113614/5 "2026-01-29T17:30:33Z")

</div>

If there are actually an abnormal amount of writes I'd be interested in knowing what the throughput and target file(s) is.