I am finding that most times my cpu load spikes while viewing montage. I have a dedicated system with an I7 processor. a load of 8 is considered 100% use from my understanding. normal on the console view I get about a 1 load. I hit montage with 7 cameras and I watch the load quickly climb to 15 or higher which makes the system nearly unresponsive. I have to ssh in and restart the zoneminder service to stop this as the load continues to spike even after closing the browser. I wish I could go back to 1.30 which ran great and the web UI worked also.
Can somebody help with the load issue, viewing montage should not and never used to spike the cpu load.
CPU Load spikes on montage
Re: CPU Load spikes on montage
Hmm. That may not be unexpected.
In your source/monitor configurations, under the STORAGE tab, do you have it set up to save JPEG's? If NOT, then it will have to generate those JPEG's on the fly in real time while in montage mode in addition to whatever processing it is already doing, and of course, the more cameras you have, the greater the load this will place on the CPU. FWIW: When setting up a camera in 1.32, it defaults to NOT save JPEGs, and to store video using x264 encoding. Now x264 video encoding isn't free, and neither is JPEG encoding. So if you switched from JPEG in 1.30 to x264 in 1.32, the storing and monitoring modes may result in similar load, but now you are adding in h264 decoding AND JPEG encoding during montage review.
The default is set that way for these reasons; (1) ANY source can be stored as h264 using x264 to encode it, which makes it universal, and (2) storing h264 saves a *TON* of disk space compared to JPEG. But like you've noticed, it may have a downside. You could revert it to the 1.30 behavior by setting it to save JPEGs AND disabling video writing, or you could perhaps find a more suitable medium ground for it. For instance, if one or more of your cameras natively feed h264 video, you could set the video writer to H264 camera passthrough. It would still spike your load when you are on montage, though not nearly as much as if you were encoding with x264. In addition, it may be useful to save "Analysis images only". The nice thing about h264 passthrough, if it is an option for you, is that it is lossless. I don't mean that the video format is lossless (its quite a lossy format), but rather with respect to the data provided by the camera you will not be degrading it any further by unnecessarily reencoding it.
Now the thing about system load is this; there is more information that you can get out of it than just to say that 8 = fully utilized, and <8 means less than fully utilized, since as you've noticed, you have managed to hit a load of 15+. What you can gather from load levels that exceed the number of CPU cores (or logical cores!!!) is that if the load level exceeds the number of logical cores, then the amount it exceeds it by indicates the average number of processes that are sitting there waiting for CPU time.
Now I can't really tell you if 15 is under or over utilized on your system. Does your CPU have hyperthreading available and enabled? If it does, then I think (you will have to look into this to confirm) that you may actually have 16 logical cores, which would suggest that 15 (being less than 16) would be LESS than fully utilized. Or (since you haven't provided the complete model number of your CPU), if that is actually a 4-core CPU with hyperthreading, it would present as having 8 logical cores (hyperthreading confuses a LOT of people), and 15 would mean average 7 processes waiting for CPU time. I am kind of wondering if it is a 4-core. I'm running a ZM server on an 8 core 4 GHz AMD Vishara -- 8 physical cores and no hyperthreading, and with 5 cameras (1@720p, 3@1080p, 1@4k -- all at 15 fps), my normal load in the high 1.x during daylight, and low 1.x at night (cameras lower their FPS to increase exposure), and (daylight) jumps to around 2.5 in montage view. Obviously loads like those are a lot more palatable than what you are seeing, but it is certainly possible that a difference in framerate and encoding could make up the difference from there to what you are seeing, even if yours is a true 8 core CPU. Its hard to say, play with the settings and see what you can come up with.
Also; if you need to alter the camera FPS, make the setting on the CAMERA, not in ZM. I think that ZM can safely discard frames from a raw or mjpeg stream, but weird things may happen if you try to limit the FPS on an h264 stream.
In your source/monitor configurations, under the STORAGE tab, do you have it set up to save JPEG's? If NOT, then it will have to generate those JPEG's on the fly in real time while in montage mode in addition to whatever processing it is already doing, and of course, the more cameras you have, the greater the load this will place on the CPU. FWIW: When setting up a camera in 1.32, it defaults to NOT save JPEGs, and to store video using x264 encoding. Now x264 video encoding isn't free, and neither is JPEG encoding. So if you switched from JPEG in 1.30 to x264 in 1.32, the storing and monitoring modes may result in similar load, but now you are adding in h264 decoding AND JPEG encoding during montage review.
The default is set that way for these reasons; (1) ANY source can be stored as h264 using x264 to encode it, which makes it universal, and (2) storing h264 saves a *TON* of disk space compared to JPEG. But like you've noticed, it may have a downside. You could revert it to the 1.30 behavior by setting it to save JPEGs AND disabling video writing, or you could perhaps find a more suitable medium ground for it. For instance, if one or more of your cameras natively feed h264 video, you could set the video writer to H264 camera passthrough. It would still spike your load when you are on montage, though not nearly as much as if you were encoding with x264. In addition, it may be useful to save "Analysis images only". The nice thing about h264 passthrough, if it is an option for you, is that it is lossless. I don't mean that the video format is lossless (its quite a lossy format), but rather with respect to the data provided by the camera you will not be degrading it any further by unnecessarily reencoding it.
Now the thing about system load is this; there is more information that you can get out of it than just to say that 8 = fully utilized, and <8 means less than fully utilized, since as you've noticed, you have managed to hit a load of 15+. What you can gather from load levels that exceed the number of CPU cores (or logical cores!!!) is that if the load level exceeds the number of logical cores, then the amount it exceeds it by indicates the average number of processes that are sitting there waiting for CPU time.
Now I can't really tell you if 15 is under or over utilized on your system. Does your CPU have hyperthreading available and enabled? If it does, then I think (you will have to look into this to confirm) that you may actually have 16 logical cores, which would suggest that 15 (being less than 16) would be LESS than fully utilized. Or (since you haven't provided the complete model number of your CPU), if that is actually a 4-core CPU with hyperthreading, it would present as having 8 logical cores (hyperthreading confuses a LOT of people), and 15 would mean average 7 processes waiting for CPU time. I am kind of wondering if it is a 4-core. I'm running a ZM server on an 8 core 4 GHz AMD Vishara -- 8 physical cores and no hyperthreading, and with 5 cameras (1@720p, 3@1080p, 1@4k -- all at 15 fps), my normal load in the high 1.x during daylight, and low 1.x at night (cameras lower their FPS to increase exposure), and (daylight) jumps to around 2.5 in montage view. Obviously loads like those are a lot more palatable than what you are seeing, but it is certainly possible that a difference in framerate and encoding could make up the difference from there to what you are seeing, even if yours is a true 8 core CPU. Its hard to say, play with the settings and see what you can come up with.
Also; if you need to alter the camera FPS, make the setting on the CAMERA, not in ZM. I think that ZM can safely discard frames from a raw or mjpeg stream, but weird things may happen if you try to limit the FPS on an h264 stream.