I have a reconcile in FNMS takes around 7 to 13 hours to complete.
Is there any thing that we can check to improve reconcile time. The DB is optimised to the best that we have.
The below step takes over 5 hours to run.
2022-12-07 06:38:31,941 [INFO ] WriteFileEvidence - Match double ended wildcards
2022-12-07 06:38:31,941 [INFO ] Writer step 'WriteFileEvidence - Match double ended wildcards' with non-default execution path (Fallback) meets condition TestingOrFallback.
2022-12-07 12:29:55,700 [INFO ] Matched 1554186 records to existing File Evidence with start and end wildcards
2022-12-07 12:29:55,700 [INFO ] Successfully processed in 5 hours, 51 minutes, 21 seconds
I have attached the log accordingly.
Dec 07, 2022 07:48 AM
Thanks for the attention this issue is getting.
In my case, the issue started with the 12/4 reconciliation. My ARL was updated on 12/3 (and is done weekly on Saturdays). (I originally thought it had something to do with my agent rollout but I now see that was just a big coincidence.)
Edit: I am using FNMS 2019 R1 on prem (server upgrade is planned in a few weeks).
Dec 08, 2022 10:03 AM - edited Dec 08, 2022 10:18 AM
Hi all ... My reconciliation process that ran last night (Sunday 12/11) was back to normal. Total time was about 6 1/4 hours and the double-wildcard step ran in 54 minutes:
2022-12-12 04:57:36,288 [INFO ] WriteFileEvidence - Match double ended wildcards
2022-12-12 04:57:36,288 [INFO ] Writer step 'WriteFileEvidence - Match double ended wildcards' with non-default execution path (Fallback) meets condition TestingOrFallback.
2022-12-12 05:52:21,608 [INFO ] Matched 40923 records to existing File Evidence with start and end wildcards
2022-12-12 05:52:21,608 [INFO ] Successfully processed in 54 minutes, 45 seconds
(Is 54 minutes a decent time to match on 40,923 records?)
Dec 12, 2022 08:03 AM
Thanks for confirming the import time is back to normal - that's great to know!
The time taken by "WriteFileEvidence - Match double ended wildcards" step largely depends on how many unique file paths & names have been gathered from your managed devices, which in turn is typically broadly proportional to the number of devices you are managing. The time taken is not proportional to the number of "matched records" that the step finds.
Based on your observation of this step taking 54 minutes, I would guess that you have file evidence from some 10s of thousands of devices.
Dec 13, 2022 05:06 AM
OK, thanks @IronManMK10 and @diaz06 for sharing. The issue is not isolated, happens after the last ARL update. We are going to consider removing these Tibco evidences from tomorrow's ARL before looking for better solutions.
The "ignore evidences" approach I provided earlier will not enhance performance as the matching step will still happen. It does not hurt to try but removal of the evidences will probably be the only solution.
Dec 08, 2022 07:33 AM
ARL file evidences are referenced in Multiple places (SoftwareTitleFileEvidence, ImportedFileEvidenceMapping), so, a simple DELETE FROM FileEvidence (Or NewFileEvidence_MT) would not work.
Tomorrow's ARL will have the Tibco File evidence removed, this is confirmed.
I would rather update the ARL than make a dangerous SQL Deletion.
Dec 08, 2022 08:52 AM