ZoneMinder Forums

I'm using centos 7 with the zmrepo, all updated late last week.
ZM was working wonderfully with load no more than around 8 until I updated it last friday. Ever since the idle load is around 40. All the zma and zmc processes are in a constant run state even when nothing is happening. I noticed I have both openjpeg and turbo-jpeg installed and zoneminder seems to be making use of both according to ldd, even though openjpeg isn't listed as a zm dependency. Is this normal?
I can stream with firefox, no problem. But it's losing frames and running very slowly.
I didn't change any options except for the cgi-bin spec, as per instructions. The db update seemed to work fine.
All the cameras are remote, running a mixture of rtsp and http, in modect mode.
The log files look normal except for losing frames when it's under load.
My next step is to try compiling from source, but if anyone has any ideas I'm all ears!

Thanks!

ZM was working wonderfully with load no more than around 8 until I updated it last friday. Ever since the idle load is around 40.

These values don't have a lot of meaning unless you describe your hardware. If you consider 8 to be "normal" then you need to have more than 8 cpu cores.

You have neglected to tell us how many cameras you have, their frame rate, and their resolution. Since this directly affects the system load, knowing this would be helpful.

When the load spikes, would does top say? Is a single process hogging all the resources? That will provide a clue as to what kind of problem you are looking at.

I noticed I have both openjpeg and turbo-jpeg installed

As long as you are using the packages from the CentOS base repo, and have not replaced any CentOS core packages with third party packages, then you are good to go.

But it's losing frames and running very slowly.

Well yes, if your system load is 40 (assuming you don't have 40 cpu cores), then this should be expected.

All the cameras are remote, running a mixture of rtsp and http, in modect mode

There are three interchangeable source types: remote/rtsp, ffmpeg, and libvlc. We have three because none of them are perfect. Remote/rtsp is the least refined, and will support the fewest cameras. Try ffmpeg instead.

The log files look normal except for losing frames when it's under load.

Please copy and paste exactly what you see in your logs. Don't cherry pick. More is better.

My next step is to try compiling from source

This won't help you. Your system will not work any differently than it is now.

Since this is a case of "working fine until something happened", a common cause is a temporary drop in communication with the camera(s) caused the cpu to spike. To alleviate that, set your Max and Alarm Max FPS values to something 1 fps higher than the incoming stream from each IP camera. Never put a value in these fields lower than the incoming stream. That is guaranteed to cause problems.

There is a newer, development snapshot in the testing repo. It improves the ffmpeg recovery process when a camera comes back online. We have a 1.29 release around the corner.