D365 Finance & Operations and Dynamics AX Forum

Expand all | Collapse all

The "Maximum batch threads" setting for batch servers

  • 1.  The "Maximum batch threads" setting for batch servers

    TOP CONTRIBUTOR
    Posted Jan 06, 2020 11:10 AM
    ​Our Customer aging snapshot job takes several hours to complete, which sometimes causes a backlog of waiting jobs when it runs longer than usual.  So we're looking for ways to decrease the runtime of that job.

    Recently I increased the Maximum batch threads setting from 8 to 16 on the batch server that the job runs on, and it decreased the runtime by approximately 30%.
                
    Max batch threads

    (The Customer aging snapshot job is scheduled to run a little after midnight, and no other jobs are scheduled to run during the timeframe that snapshot job is running.)

    We're hoping to decrease the runtime even more, so I'm thinking of increasing the Max batch threads again from 16 to 24 (original setting was 8).

    But is 24 considered to be "too many" batch threads?  What is considered to be a "reasonable" number for the Maximum batch threads setting?

    ------------------------------
    Rudy Salcedo
    Senior Programmer/Analyst
    LaForce, Inc
    Green Bay WI
    ------------------------------
    Conference-AXUG_200x200


  • 2.  RE: The "Maximum batch threads" setting for batch servers

    MICROSOFT MVP
    Posted Jan 07, 2020 06:05 AM
    Hi Rudy,

    It depends on the hardware you have. You can "play" with the number to find the optimal value. You can monitor the CPU usage when using different numbers.
    However, besides this setting, you can also monitor other performance counters like fragmented indexes, database locks, disk I/O.
    Eventually, you can use the Trace parser to find out the exact execution times on database calls, Business logic execution and caching. Probably you can gain time on other areas as well. E.g. a customer in the past had HDD drives for the TempDB. When they changed it to SSDs they really gained a lot of performance as the TempDB is heavily used by AX 2012.

    ------------------------------
    kind regards,

    André Arnaud de Calavon
    Product manager, Microsoft MVP - Microsoft Dynamics Business Solutions
    ------------------------------

    Conference-AXUG_200x200


  • 3.  RE: The "Maximum batch threads" setting for batch servers

    D365UG/AXUG ALL STAR
    Posted Jan 08, 2020 07:21 AM
    in D365 Microsoft if I remember correctly has a suggestion of 16. I believe this is the sweet spot. with it running long I have also seen where the execution plan in SQL gets wonky and might need to be cleared and recreated, at a previous job, we used a tool to track what was happening, and found that correcting an index made a huge difference. and adding an index for what seemed to be a small thing made a huge impact. Just a few other things to consider.

    ------------------------------
    Paul Martin
    Production Program Manager
    Elite Comfort Solutions, LLC
    Rutherfordton NC
    ------------------------------

    Conference-AXUG_200x200


  • 4.  RE: The "Maximum batch threads" setting for batch servers

    TOP CONTRIBUTOR
    Posted Jan 08, 2020 01:28 PM
    Wouldn't this be similar to setting threads for Master Planning? If so, there is a white paper out there with some tips. I have ours set to the number of cores-1 (so 7 for an 8 processor cores). Agree with Paul and Andre - there are several factors that can affect performance.
    ​​​

    ------------------------------
    Mark Prouty
    Programmer / Analyst
    ANGI Energy Systems
    Janesville WI
    ------------------------------

    Conference-AXUG_200x200


  • 5.  RE: The "Maximum batch threads" setting for batch servers

    TOP CONTRIBUTOR
    Posted Jan 09, 2020 03:32 PM
    Edited by Rudy Salcedo Jan 10, 2020 09:03 AM
    ​Thanks everyone for all your info & advice.  We've been experimenting with 20 & 24 batch threads this week, and it appears that 20 is our magic number.  We've been able to reduce the job's runtime by over 2 hrs, which was our goal.

    As mentioned, there are other ways that we could realize additional performance improvements.  If we find ourselves needing to shorten the runtime of this job again, we'll look into those suggestions, as well as look into the possibility of processing the bigger customers with the most transactions separately via Customer Pools.

    ------------------------------
    Rudy Salcedo
    Senior Programmer/Analyst
    LaForce, Inc
    Green Bay WI
    ------------------------------

    Conference-AXUG_200x200


If you've found this thread useful, dive deeper into User Group community content by role