Shared Memory Limiits

[AnotherBrian]

Does hardware impose limits on the size of shared memory?

I am running a Dell E6330 i7 3rd Generation box with 8gb of ram. The system,, by default, configures 4 gb of shared memory.
7 cams run just fine under 720p resolution but when I bump em up to 1080p I end up with /dev/shm showing 100% used via df command and just one of the 7 cams fails. Converting that cam to 720p results all cams running fine. Nothing I do seems to change the maximum of 4gb shared memory via kernel shmmax and shmall parameters. I would think shared memory would be limited to less than or equal to ram and not 1/2 of ram. Am I running into a linux or hardware limitation here? Thx!

Code: Select all

Filesystem                   Size  Used Avail Use% Mounted on
udev                         3.9G     0  3.9G   0% /dev
tmpfs                        787M  9.6M  778M   2% /run
/dev/mapper/ubuntu--vg-root  1.8T  1.5T  198G  89% /
tmpfs                        3.9G  3.9G     0 100% /dev/shm
tmpfs                        5.0M  4.0K  5.0M   1% /run/lock
tmpfs                        3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1                    472M  207M  242M  47% /boot
tmpfs                        787M   28K  787M   1% /run/user/108
tmpfs                        787M     0  787M   0% /run/user/1000

[SteveGilvarry]

Look for details on resizing tmpfs /dev/shm, it defaults to half memory.

[AnotherBrian]

Thx much!

[jerrynavarete]

What is the photo all about?

[AnotherBrian]

It's the output of the df command. It shows disk space utilization. In the output you will see device /dev/shm is nearly full. Although labeled /dev/shm, I do believe this is a ramdisk and not shared memory.

A ramdisk is a filesystem that resides in real memory and not on a physical disk. Processes can read, write, create files or whatever using normal file io operations. By making the filesystem a ramdisk, the data stays in real memory. It is never written or read to a physical disk. The cost is that some of the physical memory is now dedicated to just a few processes and unavailable to other processes. Accesses to ramdisk may be faster but not necessarily so as compared to a physical disk.

The zoneminder designers choose to use a ramdisk. Apparently Linux, by default, limits the amount real memory that can be used as a ramdisk. Some minor configuration change are required to up the amount of memory allowed for the ramdisk.

On my system, I need just a little larger ramdisk than the default size.

[Baylink]

Well, strictly, they chose to use memory-mapped files; those actually can live on a non-ramdisk, but it's pretty futile... unless that physical device is, say, a *hardware* ramdisk, which they do make.

[AnotherBrian]

A lot of systems are coming out with SSDs instead of the physical drives (with spinning disks). Anyone know if there is still a significant benefit with using ramdisks stored in RAM versus stored in SSD? File io systems have a ton of overhead compared non-io based implementation but then software complexity can go up.

[Baylink]

My inclination is to say that if you put your shm on an SSD, you're going to burn it out *really* fast; this is really a RAM job, papered over by a filesystem to make interprocess sharing easier.