Forum Stats

  • 3,839,768 Users
  • 2,262,532 Discussions
  • 7,901,053 Comments

Discussions

EPM 11.2.6 HFM Performance Bug

1234689

Answers

  • EPMTek
    EPMTek Member Posts: 14 Bronze Badge

    Hi Thanos

    Yep - ConsolidationMultiThreadScheme=6 halved the time from 20 minutes to 9-10 minutes post-11.2.6.2 Dev patch.

    This could well be application-specific though!

    Steve

  • EPMTek
    EPMTek Member Posts: 14 Bronze Badge

    11.2.7 patch is imminent, I hear - can't see it on the Support site yet though

    Steve

  • Megan Michnick
    Megan Michnick Member Posts: 10 Blue Ribbon

    We have tried the latest patch and Oracle has helped with initial testing for us (our servers are with Oracle data center) with updating the NumConsolidationThreads/ConsolidationMultiThreadingSchema with multiple options and consolidations are worse. Oracle has issue logged with microsoft so I guess one fix for one company is not necessarily the fix for others. We are supposed to go live in May and these consolidation times will definitely impact our close process if some other patch fix is not provided.

  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy
  • deeziel
    deeziel Member Posts: 6 Blue Ribbon

    11.2.7 released as well (Monday it seem, but now you can actually find it as well)


  • Megan Michnick
    Megan Michnick Member Posts: 10 Blue Ribbon
    edited Mar 18, 2022 3:16PM

    This is the version they installed on our test env(pasted below). As i mentioned the settings changes that our Oracle guy tried made things worse and the spinning wheel in the running tasks is annoying too. i asked him to revert settings back to 8 and 2 ( NumConsolidationThreads/ ConsolidationMultiThreadingSchema) because these seem to show the best in this environment but obviously timings are quite worse compared to 11.2.4.

    UPDATED: I had the 2 settings flipped - it is 8 and 2.

  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy

    Hi Megan,

    That is interesting.

    Depending on the available cores of your servers, I think that the NumConsolidationThreads = 2 is quite low. Based on the 11.2.4 (before patching) the optimal value is NumConsolidationThreads = 12 (in 11.1.2.4 was 48 for a massive server). After patching, this should be increased.

    What ConsolidationMultiThreadingSchema = 8 represents? I know that the option 2 improves performance and Steve (in the previous posts) has tested the option 6 (combination of 2 and 4). Option 4 is the one that impacts the spinning wheel.

    Cheers,

    Thanos

  • Benedikt L.
    Benedikt L. Member Posts: 5 Green Ribbon

    so we finally updated the test env to 11.2.6.2.0000.13 and do some testing on this version as the first application of the patch has been quite successful. numconsolthreads is set to 8 (we tried up to 24 but it got worse and worse), 6 to 8 is the magic number for us. consolidationmultihreading = 2.

    we run hfm on a 8 / 16 core VM with an oracle DB.

  • Thanos A
    Thanos A Consolidation System Manager Member Posts: 1,443 Silver Trophy

    Yes, the NumConsolidationThreads should be less than the available threads. You need threads available for the rest of the processes.

  • EPMTek
    EPMTek Member Posts: 14 Bronze Badge
    edited Mar 18, 2022 4:13PM

    Spinning wheel is a bug, confirmed yesterday. Oracle are able to recreate it when ConsolidationMultiThreadScheme has the 4-bit set (so values >=4).

    From some of my testing, I can get faster consolidations/calcs with NumConsolidationThreads available vCPUs (but my test VM is a pure Consolidation server and I am only running a single consolidation as a benchmark). This would have to be reduced if the server is doing anything else or you have Consolidation happening!

    It could be that this path has unlocked the observer 12-core wall OR it might be that (say) the calculations are able to scale more than the consolidations in my case. It definitely seems to be app-specific.

    Initial testing by users confirms that we still get the same Consolidated numbers.

    Steve