Alarms are dropping frames

[dmitripr]

Hi All, hope someone can help me troubleshoot my issue.

I just installed ZM 1.29 on a fresh Ubuntu 16.04 machine -- following the guide on these forums. I'm running this on Intel NUC with Pentium 4-core processor and 8GB of RAM. I've got a Samsung 2TB 2.5" drive installed. I have 2 Dahua 4MP cameras running in Modect mode. I'm using ffmpeg mode on the ZM side to process. The cams output 1920x1080 @ 10 FPS, and I'm recording in 8bit greyscale. The load on the system varies between 1.5 and 0.4 (CPU usage stays pretty much constant at 25%).

The PROBLEM: very much the same as skidd described here: viewtopic.php?t=23529
i.e.: during alarms I'm getting about 1 second of frame drop after the first alarm frame and consecutive frames FPS drop to about 4 or 5 for the remainder. I have no problems with setting the cams into Record mode, all frames are recorded, no drops. The live view also works perfectly, no drops.

I've tried pretty much all the items skidd outlined in the linked post (except playing around with RAID, as it doesn't apply). But I'm still having this issue.

MAX FPS and ALARM MAX FPS are blank
Analysis FPS is set to 8
Image Buffer Size (frames) 25
Warmup Frames 20
Pre Event Image Count 20
Post Event Image Count 20
Stream Replay Image Buffer 300
Alarm Frame Count 1
Enabled OPT_FRAME_SERVER, and set my wmem_max to 12GB (recommended in some forums) - I don't get "only read 219224 bytes" errors
Turned off CREATE_ANALYSIS_IMAGES
I followed advice on MySQL tuning here and elsewhere and from mysqltuner, added recommended values to conf file. I saw InnoDB is enabled by default, so, as I understand ZM already uses InnoDB (I use MarinaDB version of mysql) -- or is that not true? How can I check?
PATH_MAP and PATH_SWAP are in default directories: PATH_MAP (/dev/shm) and PATH_SWAP (/tmp/zm) -- however, I don't know if they're mapped to RAMDISK? When installing Ubuntu I only created 2 partitions, "/" and "swap".

most of the other stuff is default -- I only had a couple of days to play with this. Otherwise, the system works great!

Thanks a lot for your help!

[dmitripr]

I played around with "Analysis FPS" I originally had it set to 8, but once I removed it (blank now), this seems to have improved things a bit. When I now force an alarm there are no frames dropped (maybe a few/negligible). However, for non-forced event it still drops 1/2 of the frames during the alarm and a few frames after the alarm. There is no more 1 sec gap after the first alarm frame.

So, step in the right direction, but still dropping frames, though fewer.

[bbunge]

MySQL 5.7 with Ubuntu 16.04 does use innodb_file_per_table by default. Mariadb 10 should use it also. If you installed with MySQL you can switch to Mariadb but take a dump of the ZM database first.
I have never enabled OPT_FRAME_SERVER as most modern hard drives are quite fast. I have 17 cameras running at low resolution with no read/write issues on a WD Blue 1 TB drive.
I recommend PATH_SWAP set to /dev/shm (tmpfs) Ubuntu, by default, uses half of your RAM for tmpfs. With your image size you should check that /dev/shm is not running out of space.
Analysis FPS should be blank for remote cameras.
Set your camera resolution lower to see if that helps. Large images are not always needed...

[dmitripr]

Thanks bbunge.

I did a clean install of ZM on clean MariaDB, so I don't think I need to move anything around.

I've moved PATH_SWAP to /dev/shm. No change in behavior, still dropping. I also played around with resolution. It seems to have some, but very little effect. Increasing resolution does cause it to drop a few more frames, decreasing it does make a small improvement, maybe captures additional frame per second than previously, but still drops 3-4 FPS during alarm. I've dropped the cam down to 720P, it's the lowest it can go.

Here are my partitions:

Code: Select all

sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
[sudo] password for user:
NAME   FSTYPE  SIZE MOUNTPOINT LABEL
sda            1.8T
├─sda1 vfat    512M /boot/efi
├─sda2 ext4    1.8T /
└─sda3 swap    7.9G [SWAP]

I don't see tempfs there. Could that be the issue, I don't have ramdisk?

Thanks!

[dmitripr]

Ok, nevermind. Used wrong command. Looks like everything is OK with my /dev/shm, and I'm not running out of space.

Code: Select all

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           791M  9.0M  782M   2% /run
/dev/sda2       1.8T   12G  1.7T   1% /
tmpfs           3.9G  135M  3.8G   4% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1       511M  3.5M  508M   1% /boot/efi
tmpfs           791M     0  791M   0% /run/user/1000

[dmitripr]

Ok, I think I finally got this under control. It was the DB tuning after all. I've added a few lines recommended by @knnniggett here: viewtopic.php?t=14664

I'm not sure which one of the lines did it (or combination thereof), but I'm not dropping frames during alarms (maybe 2 frames at the start of the alarm, but I can live with that).

The only thing I couldn't do with MarinaDB is setting the mysql tempdir to /dev/shm, mysql was failing to start. I've read some guides online, stating that I need to make changes to Apparmor, but after following the instructions, still didn't work for me. If anyone has done this on Ubuntu 16.04 with MarinaDB, please let me know.

Thanks!

[Pedulla]

Okay have the same issue.
2 second gap from the 1st alarm frame to the second. Then all is well...

60 Normal 19:47:56 3.93 0
61 Alarm 19:47:56 4.00 50
62 Alarm 19:47:58 5.90 50
63 Alarm 19:47:58 5.95 50

I'm using the MariaDB instead of MySQL.
Do the innodb still not apply?

[dmitripr]

I'm still dropping frames as well. It consistently drops at least one frame after alarm is triggered. However, during some alarms it will drop more frames during the alarm, while during other alarms it doesn't (except for the first alarm frame). It's inconsistent as far as I can see.
I was able to set tmp variable of MariaDB to ramdisk (/dev/shm/), however that didn't seem to help at all.

I believe MariaDB uses innodb by default.

Maybe there is something funky with MariaDB? Shouldn't be, but that one thing we have in common.