We also identified that this happens mostly when some user logs into the system. Which led to a conclusion that there is something at the user login stage that is causing the problem. We took some help from microsoft support desk and generated the trace file for the login steps.
To generate the startup trace file follow the following steps : -
- Login to the application server where the AOS is installed.
- Start the performance monitor (start -> run -> perfmon ) and initiate the trace log
- Go to User Defined and new
- Create the new trace using the AOSTRACE.XML template
- Log in with a client and stop it
- Each trace would be created and saved in a folder with an .etl extension
- Copy the trace file created and open the same in Microsoft Dynamics AX Trace Parser. (can be found on the product CD).
These records were deleted using the following scripts : -
- C:\Program Files\Microsoft Dynamics AX\60\Server\XXX\bin\XppIL
- Stop All AOS
- Start one AOS and wait until it is Running
- Run AXBUILD on that AOS C:\Program Files\Microsoft Dynamics AX\60\Server\XXX\bin\AXBUILD.exe xppcompileall
- When Finished with compilation, Restart this AOS
- Log into a client and run a FULL CIL
- When finished, stop the client, Stop the AOS
- Start the second AOS and wait until it is up running
- Start the First AOS
- Log in users
Run AXUTIL SCHEMA
Run AXUTIL OPTIMIZE to rebuild the model database
Another possible reason that was potentially considered for the max out was that maybe due to internal procedures using the SystemSequences Table it is possible the locks are being escalated and the table is getting locked out. When AX is trying to read the locked table it is possible generating a higher no to avoid a duplicate.