Microsoft Dynamics AX Configuration for Production!
(Applies to Microsoft Dynamics AX 2009, Microsoft Dynamics AX 2012, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 R3 )
As we all are comfortable in setting up Microsoft Dynamics AX
VM’s server since all the components are on single OS.
Normally we need to Plan our Microsoft Dynamics AX (TEST, UAT
and Training Environments)
Let’s get started with Microsoft Dynamics AX Production Environment
(PROD)
Make sure your AX environment is properly configured for a
production environment.
This means SQL, AOS, SSRS, SharePoint, and Terminal Servers (TS)
are properly set up.
Some specific notes:
•Verify
your SQL Configuration -
http://technet.microsoft.com/en-us/library/dd309734.aspx
•For your AOS, make sure debugging
is not enabled, hot swapping is not enabled, X++ and CIL compile without error.
•If you are running on Virtualized
hardware make sure to follow Microsoft/VMWare best practices for configuration.
•Latest
available patches are installed.
If you are not yet live, and have some Visual Studio
experience on staff, I highly recommend using the Benchmark Toolkit -
http://www.microsoft.com/en-us/download/details.aspx?id=39082 to simulate a
full load on your system. Additionally, make sure to test your Terminal/Citrix
servers at full load.
If any of your infrastructure is Virtualized pay close
attention to CPU load, I/O, RAM and Network.
Finding the bottleneck
The main idea here is that you are in production and are
seeing problems and are looking for the current bottleneck. Here is the path I use to find the issue:
Is the issue being seen by one user or multiple users?
•Multiple
users:
1.Check SQL for Blocking/Locking, RAM, CPU, Disk
Space and Disk utilization.
There are many good packages to monitor SQL
and your DBA should be monitoring this, however many companies don't have
dedicated resources for this. I always
check here first. For RAM and CPU
issues, those should be easy to address.
Running out of disk space happens, make sure to check it. For disk utilization - that one is complex
depending on your setup. If you are
seeing locking/blocking regularly I recommend two things - first, make sure
that nothing is running from a SQL standpoint (Backup, Maintenance, etc.).
Second, use the Dynamics Performance
analyzer to determine the source - http://archive.msdn.microsoft.com/DynamicsPerf.
Lastly, check to make sure that any users
have access to the SQL server are not running expensive queries. As a general
rule, make sure that no one have ODBC access to your production database.
2.Check the AOS server(s). Look at
RAM, CPU and Disk Space. You should
regularly be monitoring the RAM usage of the AOS service to determine what is
normal for your environment. If overloaded, an AOS restart will fix the problem
but Root Cause Analysis (RCA) analysis will be required. If you are regularly seeing Memory issues,
check your buffer settings are appropriate, check to make sure that a table
caching is appropriate for the number of records in the tables. It is possible
the settings from go-live are no longer appropriate based on record growth.
3.Terminal/Citrix - Look for
CPU/RAM/Hard Disk issues. Check the number of users or maybe other applications
on the servers are eating up the system resources.
4.SSRS - Check CPU/RAM/Hard
Disk. The service restarts regularly and
can slow report processing down. Here is
a tool to make sure they keep running fast -
http://blogs.msdn.com/b/axsupport/archive/2014/03/11/ax-content-warm-up-those-ssrs-servers.aspx
5.Check batch processing in AX -
are there new batch processes which are using a lot of resources?
6.Check infrastructure - Network,
Switches, etc.
7.Client issues - Are patches
being applied or recently applied? Is a weekly virus scan running?
8.Is it month end or year end? The
month end process involves a lot of intensive reports and processes. Can you
move any of these to low activity times via batch processing?
•Single
User:
1.What was the user doing in AX?
Did they trigger a long running process? Have they recently closed AX via
CTRL-ALT-DEL and are now trying the same process they were doing before? This
can cause SQL issues. If not, see if you can replicate the issue in a test
environment and determine via profiling what the issue is.
2.Like above, check the Terminal
Server, Infrastructure, Patching and AV scans.
Note: If your system recently restarted, there can be a
significant warm-up time to rebuild the cache.
Prevention
Code can cause many issues from too many database calls,
poor use of indexes, over complexity.
Code needs to be performance tested. The AX trace parser and tracing cockpit are
very effective at finding the issue.
SQL:
•Check the server and logs every day.
•Make sure your indexes are appropriate. Both
adding missing indexes and disabling indexes you do not use.
•Check max degree of parallelism is set to 1.
•Check growth rate of data file and logs - should
be a set size, usually between 200 and 500 MB.
Client:
•Database logging - this causes significant
overhead and every setting should be scrutinized that the loss in performance
is made up with the data.
AOS:
• Make sure that the AOS is periodically restarted.
• Make sure that the clients have the same kernel
version as the AOS.
•Check batch processing has enough power.
Microsoft Dynamics AX 2012 R2
