High CPU on nph-zms process

[wilso027]

I noticed the load was high on my zoneminder service. I checked it out and I had a nph-zms process running since I rebooted my box with a load of 16.6% and everything else was around 3%. What is nph-zms and why would it have run for so long? There where others in there but they had not been running for nearly so long. Thanks

Allan

[W.]

zms/nph-zms is cgi-bin exec that provides image stream to zm web frontend.

[jameswilson]

yeah as above its the servers that provide the live streams and are cpu intensive

[John Williams]

I generally see them at the top of the list when streaming. One thing I also observed is that if for some reason they fail to establish the stream, they will stay active and start leaking memory. I think this is only happening on my cheepo ebay card when I ask for 2 camera views in quick succession, like in the montage, running localhost. If I do the same from another machine, it works quite well.

[jameswilson]

try removing the nph- bit from your paths that will help the unused process issue

[wilso027]

I saw a post on BlueCherry forums about removing the nph- part so I will give that a try. From what you are saying I should only see those when someone is actually viewing a camera live?

If no one if viewing the stream live can I kill the process w/o any problems?

On the BlueCherry post they recommended streaming flash files instead of jpeg. It seems to take a little longer to start but once it does it looks better. Has anyone else tried this? Any recommendations?

Thanks

Allan

[jameswilson]

flash can cause other issues and i have had big problems with flash and n=montage unless all the framerates are very close.
Jpeg is best, if you have the bandwidth
everything else is compromise

You can kill the zms (zm stream) if no one is streaming quite safley

[BrownBottle]

What paths and where??? I'm at a loss as I only see the path defined to the cgi-bin directory. Where does ZM refer to the nph-cgi? Sorry for the ignorance

[jameswilson]

in the settings tab under paths

[mathewss]

I have found that the biggest performance issues in the streaming portion existi in zm_monitor.cpp in ::StreamImages

If you ask zm to modify or scale the image it uses a very poor performance function to do this and eats cpu badly. A simple trick if you still want to scale the images is to let the applet on the browser do this for you and trick the software into thinking it has done this already.

Modify StreamImages and where it says if ( scale != 100 ) comment out the lines inside of that if statement so it wont actualy do any scaling.

This will drop your cpu load down a fair amount and you will still have your images large when you look at them through your browser.

On a side note I purchased an LMLBT4M from linuxmedialabs. It is a nice card though the person who runs this site or is selling them never answered any email or provided any support. Lucely the card works or i would be out $100+ bux.

The card works very will with Linux but Zoneminder has poor handling of a multiplexed card. They have a parameter to allow you to wait XX frames before taking the video frame but this is a poor way of doing this. I modified the C++ code and added a small 5000us sleep after the capture request prior to reading the frame buffer and that seems to be enough to allow the fame buffer to be filled with the chosen input port and get a stable image. I would suggest the Zoneminder people add this sleep as a parameter and even consider loosing the xxx captures before taking a frame parameter as it is a silly way to handle this. The true issue with a multiplexed card is that you have to allow time for the frame buffer to fill before reading it not ask it 4 times in a row for a specific channel and then read that is just a waste and ill still leave you a poluted frame buffer. If a capture method was based upon a callback where the kernel driver told you when the buffer was full to trigger you to read it this would also solve this issue, but it seems zm is just doing an ioctl trigger to the driver so it is up to the software to give the driver time to do its job.


Hope This helps.

Regards
Sean Mathews Nu Tech CTO

struct SoftwareProfessional {
double salary;
long lunches;
float jobs;
char unstable;
void work;
short tempers;
};

[jameswilson]

I modified the C++ code and added a small 5000us sleep after the capture request prior to reading the frame buffer and that seems to be enough to allow the fame buffer to be filled with the chosen input port and get a stable image. I would suggest the Zoneminder people add this sleep as a parameter and even consider loosing the xxx captures before taking a frame parameter as it is a silly way to handle this

NOt being huge (in fact very poor) on C+ im suprised with this statement as everything that Phil writes seems to be spot on.
Phil is this the case taking into account on camera xtals for sync, can this be done or are there some side effects?

James

[cordel]

I have found that the biggest performance issues in the streaming portion existi in zm_monitor.cpp in ::StreamImages

If you ask zm to modify or scale the image it uses a very poor performance function to do this and eats cpu badly. A simple trick if you still want to scale the images is to let the applet on the browser do this for you and trick the software into thinking it has done this already.

Modify StreamImages and where it says if ( scale != 100 ) comment out the lines inside of that if statement so it wont actualy do any scaling.

This will drop your cpu load down a fair amount and you will still have your images large when you look at them through your browser.

This is great assuming that you are always viewing over a local network or have enough up to the internet to support the required bandwidth. Hence why there are bandwidth settings in ZM.

[mathewss]

Just to be clear this scaling hack is just that a hack. I am on a local network and I am actualy scaling UP to 640 from 320 downscaling is a different story for sure. I am not even sure if the scaling function has the same performance issues as it does when scaling up. I never tested it for downscaling.

Again this is a hack and is not to be construde as solving everyones problems just mine.

In any case upscaling imho is best done by the browser to conserve bandwith and cpu cycles regardless if its local or remotely tranmitted.
I cant think of any reason off the top of my head to store or transmit upscaled images. I am sure someone will come up with one but I cant think of any.


Re
Sean M

[mathewss]

I modified the C++ code and added a small 5000us sleep after the capture request prior to reading the frame buffer and that seems to be enough to allow the fame buffer to be filled with the chosen input port and get a stable image. I would suggest the Zoneminder people add this sleep as a parameter and even consider loosing the xxx captures before taking a frame parameter as it is a silly way to handle this

NOt being huge (in fact very poor) on C+ im suprised with this statement as everything that Phil writes seems to be spot on.
Phil is this the case taking into account on camera xtals for sync, can this be done or are there some side effects?

James

The C++ code is very clean the best I have seen in an open source project in a long time.

The issues is revolving around the video capture and driver communication. It is possible that the real culprit is the bt878 driver on linux and that the ioctl command "should" block the calling program untill the buffer is fully loaded with the frame. I have not looked over the bt878 driver but if needed I can to confirm this. I am however very sure that the call to my bt878 driver on linux is "not" blocking and the buffer is not fully filled with a complete frame unless one waits.

Re
Sean M

[jameswilson]

if i recall, downscaling was introduced for megapixel cameras, and upscaling to make them all appear the same size to the user, ie 320x240 and 640x480 and 1280x1024 all on the same system