Page 1 of 1

Use /dev/shm for zoneminder's temporary files

Posted: Tue Nov 17, 2009 1:58 pm
by knight-of-ni
So I recently took the plunge and recompiled my instance of zoneminder to use mapped memory rather than shared memory. It works great.

That got me thinking.... since /dev/shm is bascially a dynamic ram disk, why not use it for zm's temporary files as well as zm's mapped memory files?

To test this, I went to Options -> Paths and changed the last three options (PATH_SOCKS, PATH_LOGS, & PATH_SWAP) to point to /dev/shm instead of /tmp.

Here are a few notes if you are interested in trying this:
  • - Don't make this change while zoneminder is running. Stop it first, make the changes, and then start zoneminder.

    - make sure that /dev/shm exists on your system. If you are already using mapped memory then you should already have verified this.

    - df reports that zoneminder's usage of /dev/shm is in the kilobyte range so, unless you've got debug turned up high, you likely do not need to be concerned about the ram disk using up a lot of memory.

    - After making the change, I had to set the max FPS and max alarm FPS for each of my network cameras to match what I had programmed in each camera.... otherwise the system tried to record at 50+ fps and ran itself out of buffer. I guess that means things are running faster, eh?
I have one lingering concern about this configuration. My concern is whether or not zoneminder saves any temporary files that need to survive a reboot. So far I have not noticed this to be the case, but I will post if I discover any problems over the long term... i.e. no news is good news.

Posted: Tue Nov 24, 2009 2:52 am
by Blazer
I did some testing of this on a slow system (old laptop) with crappy 5400 RPM drive, and it made no difference.

I'm pretty sure that socket files are actually processed in memory anyway. In other words, the data passing through a socket is not actually stored on the disk (Remember in unix everything is represented as a file, such as all the memory-resident things in /proc, just because they have file names though does not mean they actually reside on the hard drive).