Python driving up CPU utilization in Blue Iris?

[caduceus26]

Beginning around a week ago or so, my CPU utilization started spiking at 100%. It was consistent at around 15-40% before. Checking task manager I saw that the two processes chewing up CPU were BI and Python with Python hitting 30-40% range at times, and sometimes with multiple instances. We have a lot of construction activity in and around our property during the day triggering lots of alerts. At night, the system settles down and runs in the 15-25% range. I'm running BI 5.5.4.4 with 11 Amcrest 8MP turret cams on an HP mini DT with i7-6700T processor and 1 TB SSD. In addition, I have a 1 TB USB 3.0 HD for System and BI registry backups, and 4 TB USB 3.0 HD for New, Stored, and Alerts. I know about the performance caveat on i7-6700T but the system has been running smoothly for 7 months now.

Any ideas on why Python is spiking all of a sudden? Any help would be appreciated. Thanks in advance.

 

[samplenhold]

Version 5.5.3.7 is the latest Stable Version.

Why do you have Python running? What other things are your BI PC being used for?

I only have BI, Net TimeSync, and Norton running on my BI PC. No Python.

 

[wittaj]

If you are running Deepstack, that would be the python tasks.

If so, then look at backing down the sensitivity so it isn't sending so many triggers to Deepstack or adjust which ones are using DeepStack.

AND have you done EVERY optimization in the wiki? Substreams and direct-to-disc are a must. I suspect you haven't because a member here runs 50 cams on a 4th generation CPU at less CPU than you are.

Optimizing Blue Iris's CPU Usage

Blue Iris uses a lot of CPU time. In most Blue Iris installations, your CPU is the limiting factor which determines how many cameras you can have. As such, it is extremely important to optimize your configuration to ensure you can get the most out of your system while consuming the least...

ipcamtalk.com

 

[wittaj]

A couple of ways to bring down the CPU when using DeepStack:

• First and foremost is make sure that every optimization, including substreams, is being followed.
• Uncheck the use mainstreams box - in my experience the substreams are just fine.
• Use low mode instead of medium or high mode - in my experience the %confidence has been the same, but CPU and time to make increases with each increased mode.
• Sometimes a slight adjustment of the field of view (or motion detection area) is needed so that fewer images need to be sent to deepstack for analysis.
• Reducing the number of times that images are being sent to Deepstack:
  • Us long timers probably had BI motion settings fairly well dialed in prior to DeepStack, so it is more of a confirmation and knock out the few false triggers that could happen from time to time. NOOB tend to make the BI motion detection sensitive and triggers on everything. Spending some time in the BI motion detection settings to not send every moving leaf to deepstack will help tremendously.
  • Consider how important having the little orange vehicle or person icon really is - if you have a camera with built-in AI, consider using that instead. For alerts, I set up a clone camera that alerts me based on the IVS triggers from the AI camera, and then the main camera I have set up to record 24/7 and trigger on IVS as well as less sensitive BI motion detection settings.
  • Consider how important is it to have deepstack running 24/7 - maybe it is best to only use it at night when motion is typically less. Several of my cameras only run Deepstack at night. But I do have a few that run it in the day as well.
  • If possible, try to have Deepstack running on cameras that are not triggering at the same time. Sometimes that isn't possible.

 

[caduceus26]

Version 5.5.3.7 is the latest Stable Version.

Why do you have Python running? What other things are your BI PC being used for?

I only have BI, Net TimeSync, and Norton running on my BI PC. No Python.

Thanks for the response. My running apps are: BI, Deepstack, Dropbox, Splashtop Streamer (for remote access), MalwareBytes, Network Time Protocol, EaseUS todo Backup, and Amcrest Config Tool. All of these apps were on the system and running fine before the CPU started spiking. I think that Python is associated with Deepstack, which you don't have in your apps list.

 

[caduceus26]

If you are running Deepstack, that would be the python tasks.

If so, then look at backing down the sensitivity so it isn't sending so many triggers to Deepstack or adjust which ones are using DeepStack.

AND have you done EVERY optimization in the wiki? Substreams and direct-to-disc are a must. I suspect you haven't because a member here runs 50 cams on a 4th generation CPU at less CPU than you are.

Optimizing Blue Iris's CPU Usage

Blue Iris uses a lot of CPU time. In most Blue Iris installations, your CPU is the limiting factor which determines how many cameras you can have. As such, it is extremely important to optimize your configuration to ensure you can get the most out of your system while consuming the least...

ipcamtalk.com

Thanks for your response. I have EVERY optimization set, plus substreams, and as you know direct-to-disk is most critical in the optimization process. I've actually set up two additional BI platforms for friends and relatives (less cameras) they are running in 5-15% CPU utilization range. With respect to sensitivity, I am currently set at 198/40 (very sensitive.) I'll back that off a bit to see if that helps.

 

[caduceus26]

A couple of ways to bring down the CPU when using DeepStack:

• First and foremost is make sure that every optimization, including substreams, is being followed.
• Uncheck the use mainstreams box - in my experience the substreams are just fine.
• Use low mode instead of medium or high mode - in my experience the %confidence has been the same, but CPU and time to make increases with each increased mode.
• Sometimes a slight adjustment of the field of view (or motion detection area) is needed so that fewer images need to be sent to deepstack for analysis.
• Reducing the number of times that images are being sent to Deepstack:
  • Us long timers probably had BI motion settings fairly well dialed in prior to DeepStack, so it is more of a confirmation and knock out the few false triggers that could happen from time to time. NOOB tend to make the BI motion detection sensitive and triggers on everything. Spending some time in the BI motion detection settings to not send every moving leaf to deepstack will help tremendously.
  • Consider how important having the little orange vehicle or person icon really is - if you have a camera with built-in AI, consider using that instead. For alerts, I set up a clone camera that alerts me based on the IVS triggers from the AI camera, and then the main camera I have set up to record 24/7 and trigger on IVS as well as less sensitive BI motion detection settings.
  • Consider how important is it to have deepstack running 24/7 - maybe it is best to only use it at night when motion is typically less. Several of my cameras only run Deepstack at night. But I do have a few that run it in the day as well.
  • If possible, try to have Deepstack running on cameras that are not triggering at the same time. Sometimes that isn't possible.

Thanks for your response. I'm short on BI experience (8 months or so) but have been installing, supporting and working with desktop/servers/networks and surveillance cams for a while now. BI is the best most cost effective surveillance software I've come across in that time. Optimizations were the first thing I learned after installing BI as that has been emphasized repeatedly by the experienced BI users and experts. Having said that your checklist is very helpful and I am going to go through it item by item see what helps. One additional piece of information on my system: In motion sensor I am using Zones and Hotspots only and I spent some time masking out trees, bushes, and passing cars on street, etc. Object Detection is unchecked. Wonder what effect having both turned on might have? Thanks again.

 

[wittaj]

Hotspots trigger for any motion in that zone and should be used very sparingly.

Object detection is used to further elminate false triggers - normally people use it the wrong way and it is eliminating true triggers. None of my cameras use that feature. But in some fields of view, it is necessary. But spending some time to work out the motion detection first doing the masking of trees and stuff will go a long way towards not sending every blowing branch to deepstack.

 

[caduceus26]

Hotspots trigger for any motion in that zone and should be used very sparingly.

Object detection is used to further elminate false triggers - normally people use it the wrong way and it is eliminating true triggers. None of my cameras use that feature. But in some fields of view, it is necessary. But spending some time to work out the motion detection first doing the masking of trees and stuff will go a long way towards not sending every blowing branch to deepstack.

Good feedback. I avoid hotspots for that reason. I've spent considerable time masking and eliminating duplicate areas being triggered on multiple cameras. However, after reviewing the masking I've found several areas that could have been done better. I'll leave object detection off as is for the reasons you've given. Thanks.

 

[caduceus26]

Follow-up response to all the excellent recommendations I received from you guys:

I've managed to get CPU utilization back down to the 20-40% range. There were a combination of things I did, some based on the suggestions I received here. Also, as we learned a long time ago -- "Check your work!" During the period in question I renumbered and reordered the cameras on the screen for a better flow. One camera was deleted and re-added as a different cam. In checking it, I discovered that Deepstack was not turned on for Alert confirmation after re-adding the camera. In addition, I un-checked "Use main stream if available." After reviewing the MOTION, TRIGGER, and ALERTS columns in the status report I went back through each camera and cleaned up the masking. Where more than one camera was looking at the same area there were duplicate alerts being sent out (along with all the attendant processing to generate the alerts.) I'm now monitoring to see if the problem is solved.

Thank you all for your feedback.