How long reconcilation job takes in your environment?
How long FNMS Reconcilation job takes in your environment? It runs for 6 hours in our environment. We have usage data coming in from ADDM and Reporter for 100K end user workstations and 80K servers. Also, Oracle PURL is implemented but data would be coming in on weekly basis to process.
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
Hi Vinod, for comparison .. here are our numbers. We have approx. 35,000 servers.
When full inventory runs for the environment once a week , that reconciliation takes on average 12 -14 hours, starts at 2 am local time and completes around 6 pm later that day.
When full inventory runs do not take place, those reconciliations take on average 8 - 9 hours, starts again at 2 am local time and completes around 10 am later that day.
We use the North American Cloud environment ...
Here are some sample timings from a FlexNet instance I have access to:
- "Inventory import" step for FlexNet inventory for 53K devices: 3 hours
- "Inventory import" step for SCCM inventory for 8K devices: 15 minutes
- "Reconciliation" step: 90 minutes
Thanks Bruce. We are on EU Cloud environment.
12-14 hours execution time is too much. Is your application performance normal during the reconciliation run? Our business typically complains about application performance while reconciliation is running. I have raised multiple cases with Flexera support to reduce the run time of Reconcilation job and really hoping something can be done in this regards.
12-14 hours execution time is too much. Is your application performance normal during the reconciliation run?
Hi Vinod ... I agree that our reconciliation is a tad long, but as suggested, the size of our files are rather large even though we have spent some time working with the support teams to identify some of the directories we can exclude, we still have some pretty large inventory files. With respect to the performance of the User Interface (we are the North American Cloud) during the reconciliation, yes, at times the spinning cog really gets a work out lol while retrieving some data depending on the request being made.
As the number of customers grow on the Cloud and the amount of data being uploaded increases, it is somewhat predictable. I would trust that the Flexera Infrastructure team are constantly monitoring things and developing a game plan to keep on top of the expansion. We did see a huge improvement roughly 1.5 to 2 years ago when they re architected the Cloud environment, obviously increasing capacity on their end.
Let's hope for the best ...
What would be good if we can configure the reconcile so it is not all or nothing. I already requested this Flexera but never get an answer. What I would like if we could configure like on Monday we run "vendor X" and Tuesday "vendor Y" etc. And run the device import separately. Soin this case instead of blocking the system for the big run we can run separately on a time the system is less or not used.
Actually you can separate several parts of the "Inventory import and license reconcile". I regularly use some of the following options to make the standard process a bit more robust.
You can use the parameter "run inventoryimportreaders ---s <ConnectionName>" to run the reader for a specific connection only. Or leave out the ---s option to run all readers. With "run inventoryimportwriters" you can run the writer, including the license reconcile.
The documentation (FNMSSystemReference.pdf) offers some details, abstract "Separating Readers and Writers".
The ComplianceReader.exe is what is actually run by the above statements. It offers some options, I could not find in the documentation:
ComplianceReader.exe -it writers -e licensereconciliation -overrideparams publisherfilter="Oracle"
You could use this to run vendor-specific reconciles.
If you want to use the BatchProcessScheduler (which I would recommend), you'll nee to escape some of the characters. An example:
BatchProcessTaskConsole.exe run inventoryimportwriters ---e licensereconciliation -overrideparams publisherfilter="""Oracle"""
That is correct, what Markward describes are backend tasks.
(Anything expressed here is my own view and not necessarily that of my employer, Flexera)
Looks like most of Flexera customers are facing issues with Reconciliation job. My business keep complaining about system non-performance during those 6 hours run when reconciliation runs. We are on EU cloud.
After raising several incidents, Flexera support always put it on "Data volume to process"...Agreed but Flexera should suggest options to run it in better and efficient manner. Our user base is across regions (EMEA, APAC, AMER) and application is not usable to APAC members as we kick-off most of our jobs after US business hours (which is day time for APAC). With application response time being slow, acceptance won't increase in APAC region and we would have internal challenges.
So far, there are no positive recommendations from Flexera on the Reconcilation job timing.
Currently our full reconcile takes 15h with 100K workstations coming from SCCM and 30K servers from Flexera agent.
At this moment we have support case open as from our point of view the reconcile takes to long.
I'm currently on the EU Cloud environment and we have about 35k workstations and 5k servers reporting in - and rollout is still ongoing. (I'm not sure where you are in your Flexera journey.)
We also do not just ingest the agent data, we also do connect into multiple data sources.
On average, a reconcile takes about 3 hours, however I have noticed the following behaviours:
*If a mass deployment of the agent goes out, reconciliation takes far longer. For example the end of last week we rolled out 5k agents overnight to one of our environments this reconciliation then took about 8 hours.
* We use unique naming conventions for our packaged software, so we manually match the evidence to the application. Again when completing a high number of tasks, reconciliation normally takes longer.
*Once the above is completed, reconciliation times return.
In terms of performance I have not noticed any performance degradation to the end users when running the reconciliation. That said, I have certainly noticed a performance in FNMS on our corporate network (slow) to my own internet connection (super fast.) So that could be worth a try.