A place for discussion of topics that are not specific to ZoneMinder. This could include Linux, Video4Linux, CCTV cameras or any other topic.
-
AnotherBrian
- Posts: 104
- Joined: Tue Jul 27, 2010 6:36 am
Post
by AnotherBrian » Thu Feb 02, 2017 10:23 pm
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
- Posts: 445
- Joined: Sun Jun 29, 2014 1:12 pm
- Location: Melbourne, AU
Post
by SteveGilvarry » Fri Feb 03, 2017 10:35 am
Look for details on resizing tmpfs /dev/shm, it defaults to half memory.
Production Zoneminder 1.35.x
Random Selection of Cameras (Dahua and Hikvision)
More Dev VM's than I care to count.
-
jerrynavarete
- Posts: 12
- Joined: Wed Jun 21, 2017 9:55 am
- Location: Upper Coomera, Queensland, Australia
-
Contact:
Post
by jerrynavarete » Wed Jun 21, 2017 10:05 am
What is the photo all about?
-
AnotherBrian
- Posts: 104
- Joined: Tue Jul 27, 2010 6:36 am
Post
by AnotherBrian » Wed Jun 21, 2017 12:15 pm
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
- Posts: 330
- Joined: Sun Jun 19, 2005 3:19 am
Post
by Baylink » Fri Aug 25, 2017 2:16 pm
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
- Posts: 104
- Joined: Tue Jul 27, 2010 6:36 am
Post
by AnotherBrian » Fri Aug 25, 2017 6:32 pm
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
- Posts: 330
- Joined: Sun Jun 19, 2005 3:19 am
Post
by Baylink » Fri Aug 25, 2017 6:36 pm
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.
Who is online
Users browsing this forum: No registered users and 3 guests