Jason, the default report interval of the client is 60 seconds. Doesn’t that mean we should see “Report Posted” every 60 seconds in the client log? In many cases, we do not see “Report Posted” for hours. What would keep the report from posting. Is there some logic for posting report that is tied into the evaluation cycle? I am trying increase our report time to every 180 seconds to see if that helps with our report times.
The client can’t post a report if it’s not connected to a Relay so first check that the most-recent Relay Select was successful.
Next I’d check the section “If the client is posting reports, but much less frequently than expected; is receiving GatherHashMV messages, but is slow to execute or report back Analysis results, there may be long-running evaluations” above.
If you have a number of properties set to evaluate “Every Report”, then the report won’t post until those have evaluated. If, combined, they take five minutes, or ten, or twenty, then it will take the client that long to evaluate before each report is posted. I’d use the Analyses I reference, along with BES Client Debug Logging, to see if something is taking a long time for the client to evaluate.
A repeatable issue I see is that we can create a long-running property to evaluate “once a day” to reduce the client load, but then if someone uses that same property in action targeting or an action constraint, that long-running property relevance is copied to the Action, where it has to evaluate “Every Report”.
I am looking at one client log out of many that are reporting slowly, and the last time a report was posted was 3:45 AM and it is now 10:30 AM and still no report. That is 6 + hours of no report. Surely, that cannot be because of a long running analysis? If my clients would report at least once per hour, I would be happy, but should they report every 15 minutes.
You’d need a client debug log enabled to see what the client is spending it’s time on…I encountered one case where six different analysis properties each performed full hard-drive scans like descendant files whose (name of it = "some bad exe") of drives and those each took hours.
The Analyses I link in the opening post can also tell which properties are taking longest and howling they’re taking.
Another thought is to check whether you have any of the Power Save client settings enabled…by default a client won’t post a report until it’s power save time expires.
I am running fixlet ID 361 TROULBSHOOTING:Enable BES Client Usage Profiler. This Task will enable the BES Client usage profiler, which allows you to see which Fixlet messages, tasks, actions, or properties consume most of the BES Client’s time.
It does not seem that the client is being overly stressed.
Since I am looking at servers right now, there should not be any power saving settings in play.
I’ve split this out into a new topic…what results do you have from the client profiler log? This maybe worth opening a support incident, without going through the logs in detail I would have to guess at your issue. But hours between reports is not normal or expected and I suspect there’s something to troubleshoot in your environment.
If the evaluation cycle is 58 minutes and Bigfix is getting maybe 2% of the processor of a virtual Citrix server with 5 procs of a 2600 MHz Xeon processor, do you think it will take 6 hours to complete an evaluation cycle and post a report? Is a report only posted at the end of the evaluation cycle?
Going back to the original question: “Doesn’t [the default report interval of the Client being 60 seconds] mean that we should see ‘Report Posted’ every 60 seconds in the Client log”, the answer is No, not necessarily.
The setting you are referring to, if I’m not mistaken, is _BESClient_Report_MinimumInterval (https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/r_client_set.html). This defines the most frequently that the Client would be allowed to report, but it doesn’t mean that the Client will report at this interval on a continuous/ongoing basis.
The Client sends reports based on changes identified by the Client. If nothing changes on the endpoint (such as changes to Fixlet applicability, new action statuses, etc…), there’s nothing really for the Client to report. Without other, broader changes, the Client will report on an ongoing basis on its heartbeat interval, which is 15 minutes by default (https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Console/Dialogs/preferences.html?hl=heartbeat)
3 Likes
I have learned that there is a property called “Evaluation Cycle”. The Relevance “Average of evaluation cycle of the client” will return the average evaluation cycle for the last 10 loops. Anything in the 15-minute range is considered excellent. Anything over 30-45 minutes, is worthy of investigation. The evaluation cycles will depend heavily on the amount of content-enabled in your environment, so these times are just a rough recommendation. Use the Client Profiler to debug Fixlets taking too long to evaluate.
The evaluation time also depends on the amount of processor Bigfix is allow to have. At the default 2% of processor our evaluation cycle is 60 minutes on some of my machines. Even though the evaluation cycle is 60 minutes it can take over 6 hours for the client to post a report. I guess that means that it takes 6 plus hours for the client to get 60 minutes worth of processing time. If I give Bigfix 20% processor, the evaluation cycle drops to 10 minutes and does post a report at least every 15 minutes.
| CPU | Evaluation Cycle | |
|---|---|---|
| 2% | 60 minutes | |
| 5% | 20 minutes | |
| 20% | 10 minutes |
After further investigation, I feel there is an issue when the Bigfix agent is given 2% of the processor on some machines. Report posting seems to get lost. There is no way it should take 6 to 9 hours for a report to post. At 5% processor, reports are posted normally.
1 Like