page contents

Capacity Planning for Dynamics AX


Since Microsoft Dynamics AX 2012 was launched in 2011, hundreds of Premier customers engaged Premier Field Engineering team to provide guidance on new Dynamics AX 2012 infrastructure, especially when upgrade was executed from legacy versions such as Dynamics AX 2009.

Today, most of our customers are live and look for optimization of their existing infrastructure, they need to better justify cost associated with IT capacity and they want to match it to future demands of their  business. We have been running many Capacity Planning for Dynamics AX to answer those questions and I would like to share some learnings in this blog post.


Objectives: first, let’s summarize the three key outcomes of the Capacity Planning:

  • Optimize current infrastructure and save cost by allocating the right resources among all servers (scale up or down thanks to virtualization)
  • Increase uptime by adjusting business-critical components and avoid single points of failure (allow more redundancy with load balancing)
  • Prepare your infrastructure for another roll out of the solution by creating a baseline of the current workload (create cluster for more scalability

Methodology: depending on the objectives, there are many tools available. But the three important ones are:

  1. Windows Performance Monitoring (Perfmon): Collect light trace of counters in production instance for all servers related to your Dynamics AX solution and for one complete week. I recommend to include the week end even if the users are only working from Monday to Friday, because you might find out that other maintenance tasks can have negative impact. The servers’ roles we typically review are: SQL Server for OLTP, Reporting and Analysis Services, AOS Servers, Management Reporter and Help Server, Remote Desktop Session Host Server, SharePoint Server and BizTalk Server.
  2. Performance Analyzer of Logs (PAL) is very useful to automatically generate summary reports from Perfmon files. Such HTML reports can be automated with PowerShell scripts. You can also create your own templates for every server role.
  3. Performance Analyzer for Dynamics (DynamicsPerf): I recommend to leverage the SQL queries provided by this tool, especially in the benchmark section, to have a deep dive analysis of the database growth per database files and tables.

Note: the collection and the analysis of such data can be done remotely and on any version of the application.


Outcomes: here are examples of take aways we gathered from Capacity Planning analysis:

1 _ Dynamics AX AOS Servers : Memory and Processors contention

Dynamics AX AOS dedicated to batch processing can consume more than 14 GB of memory, which is the default recommendation from the official System of requirements. When a batch job generates lot of calculation and relies on multi-threading, like Sales invoicing or Master Planning, the AX32SERV.exe process can use all available memory. I have personally seen up to 96 GB of memory consumed by one AOS process during one intensive batch job. It really shows Dynamics AX 2012 is much more scalable than previous versions. But even if AOS releases such memory when the batch process is completed, it is crucial to understand which batch job is the root cause of such memory consumption to better optimize the Batch Configuration and improve performance.

Regarding Dynamics AX AOS dedicated to online users, we noticed that memory can vary from couple of GB up to 12 GB for same number of users. For example, we saw AOS consuming less than 5 GB for 300 online users while other AOS were consuming more than 10 GB for only 50 concurrent users. This is due to the nature of the users, the complexity of the scenarios and the level of customization. There is no better way to find this accurate value than running Capacity Planning for all AOS. And this is why we also recommend creating a cluster of AOS for every workload (User, Batch, Intgration, Enterprise Portal…) to match the resources with the needs. This is an example of scorecard you can get with Performance Monitoring:

aosmemory

Note: the same optimization can be done for the Processors allocation, especially for the AOS running batch jobs. The default recommendation of two threads per core is a good start but there is no easy good rule of thumb for Max Batch Threads and you must test what is the best configuration to achieve optimal performance.

2 _ Client Load Balancing and memory usage on Remote Desktop Session Host Servers

From the User Journal Log, you can easily validate if load balancing is working as expected across all Remote Desktop Session Host Servers (RDSH) and generate the following graph. You can also find out if some connections are still made from other computers using the rich clients, which can cause critical issues if there is a Kernel version mismatch between his machine and the AOS.

rdslb

To size the RDSH servers with accuracy, we need to know how many Dynamics AX clients are running at the same time and what is the memory consumption per session. The average memory consumption of  Dynamics AX 2012 client has been historically estimated around 250 to 500 MB. During the Capacity Planning, you can verify this value and create such graph by using Performance Monitoring memory counters. You can measure the impact of other applications like MS Office and any other third party applications. Then you can allocate the right amount of memory required by each RDSH server. This graph is showing the maximum memory used by each Dynamics AX client on the RDSH server:

ax32memory

Note: Dynamics AX client can consume up to 1 GB of memory for Development or Debugging sceenario. This is also why we recommend keeping the RDHS dedicated to Production workload only.

3 _ Estimate the database growth

By looking at the top tables in your database and their monthly growth since go live, you can better predict the future size of the database. In this example:

  • The transactional table is growing the most during winter time and we can estimate the future peaks.
  • The log table shows that clean up policy is working as designed. In this example, the rentention policy is to keep the last 3 months.
  • On the the custom table, we can see orphaned records from spring 2016. This looks like an opportunity for cleanup.

It is interesting to have a closer look at this data per company and day so that only relevant information remains in the database. You can use Intelligent Data Management Framework (IDMF) to easily visualize such data.

tablegrowth

Regards,

@BertrandCaillet
Principal Premier Field Engineer


Comments (1)

Comments are closed.

Skip to main content