Simple Settings to Help - AXUG
Transcript of Simple Settings to Help - AXUG
4/18/2019
5 Ways to Tell if You’re Ready for
Connected Field Service
Simple Settings to Help
Your AX Solution to Run Faster
Foto’s van collega’s
Awards
Global Credibility
Local, Strong Skills
Leverage the Microsoft
Cloud to Your
Advantage with HSO
Retail
Manufacturing
Services
Distribution
…
…
…
…
Public …
Industry Expertise and References
Presenter Introduction
Steve WalshDirector of Managed Services
HSO North America
Technical/Developer Background
13 years w/Microsoft
MCS
Global Support Prg Mgr
Tech Acct Manager
Premier Field Engineer
7 years in Partner Channel
Managing Managed Services
Working with AX/D365 since 2005
What is Managed Services?
Client Trusted Partner
Post Go Live Consulting Technical & Functional Application Optimization
Performance Topics
➢ Factors that affect Performance
➢ Assumptions
➢ SQL Server Settings
➢ AOS Server Settings
➢ Maintenance
➢ User Features
➢ Resources
Factors that affect performance
▪ There is NO Silver Bullet for performance improvement.
▪ It is like an onion with many layers.
Factors that affect performance
▪ Hardware – Physical layer to the system; includes server box, network
bandwidth, storage devices, and client machines. Should meet the minimal
requirements stated by Microsoft.
▪ Windows Server Configuration – Operating system, firewalls, anti-virus, etc.
▪ SQL Server Configuration – Application layer to the SQL server. Overall
settings within SQL applications.
▪ Database Schema & indexes – within SQL Server; specific settings the
database has setup, the table layouts, and the indexes associated with each
table.
▪ Application Code – Kernel and application code; ISV code, Customizations, and
X++ query calls.
▪ Application Configurations – within AX; Parameters settings, sequence
numbers, and database logging
▪ Users/Business Process – Running a report or specific process multiple times;
running a specific job
Assumptions
▪ Hardware is bigger and better than recommendation from MS
installation documents.
▪ Most of this information is technical.
▪ You have access to SQL and know how to pull up settings.
▪ Information may not apply to your specific system; Consult with
your AX partner or Microsoft.
▪ Always TEST in your Test environments first.
The Process
Settings
• Proper settings
Analyze
• Performance Assessment
Maintain
• DB & Code Tuning
• Maintenance
Repeat Continuous
Improvement
Today’s
Topic
SQL Server Settings
SQL Settings
▪ Production SQL Server – Only production databases should be on the
production servers. Any Dev or Test type activity should be
separated completely.
▪ SQL Server should be configured to run as a background services– Control Panel → Advance System Settings → Advanced Tab → Performance →Settings
→Advanced Tab → Processor scheduling → Background Services.
SQL Settings
▪ Configure max degree of parallelism set to 1
▪ Max Server Memory - Operating System needs to have some memory available to function correctly. Either leave 4 GB or 10%, which ever is greater.
SQL Settings
▪ TempDB
• One file per core & up to 8
• 20% of database size
• Each file should be set to same size
• Set to Simple Recover Model
• Auto growth set to 250-500MB
• Some will recommend setting to 1 Gig to start with
• When SQL is adding size to Temp files… it locks activity down.
SQL Settings
▪ Trace Flags
➢ 1117 – Enabled – This flag grows all file groups simultaneously in the case of
an auto growth event.
➢ 4199 – Enabled – This activates query optimizer fixes from several hotfixes.
➢ 4136 – Disabled – This has parameter sniffing; disabling can improve
performance.
➢ 1224 – Enabled – lock escalations based on the number of locks
➢ 2371 – Enabled – Reduces the threshold for auto-update statistics for large
tables > 25k rows.
SQL Settings
▪ Read Committed Snapshot Isolation (RCSI) – should be set to True
▪ Auto Create Stats – should be set to True
▪ Disk I/O (storage should be on a RAID system)
– Reads – Less than 10ms
– Writes – Less than 20ms
SQL Settings
▪ Maintenance:
– Periodic indexing▪ Administration > Periodic > SQL Administration
– Statistic rebuilding
– Specific Table Sizes:– INVENTSETTLEMENT
» Run cleanup (inventory management > Periodic > Clean Up > Inventory Settlements
– EVENTCUD
– INVENTSUMLOGTTS
– SYSTRACETABLESQL
– SYSDATABASELOG» Administration > Setup > Database Log
– SALESPARMLINE» Administration > Periodic> SQL Administration
AOS Settings
AOS Settings
▪ Memory - No less than 16 GB
▪ Only 1 instance per server
▪ Breakpoints – Should be disabled
▪ Max buffer size – Set between 24 to 48 (default for 2012 R2 is 48)
▪ Max No. Table to Join – Max is 30
▪ Entire table Cache size = Set to 96
▪ Global object cache elements = 100000
▪ Statement Cache = set to 450
▪ AOS Max Memory Setting = set to 80%
▪ Dedicated AOS for batch = should be 2 AOSes minimum; 1 for users; 1
for everything else. --- Greater than 3, can group batch types to
different servers
Maintenance
Kernel
▪ Check and update the Kernel from Microsoft
– Generally a performance improvement was made
– Make sure your Kernel version match
▪ Client, AOS, SQL Server and all locations
▪ Keep in mind… DEV/TEST/Production should all be the same Kernel
▪ Not necessarily dependent on the application level/version
Monthly Checks
▪ Database Log
– System setting to capture when a record is inserted/deleted/updated
– Select count(recid) from sysdatabaselog
– If >200K, query for records older than a specific date
– Transaction type tables should not have logging turned on
– Clean-up process: Use Export/Import tools to archive data.
– Clean-up too: Administration -> inquiries -> Database Log -> Clean up Log
Monthly Checks
▪ Temporary Sales Order/Purchase Order Processing Data
– Table stores temporary order lines when orders have been posted.
– Some lines hang out here and never get deleted
– SQL Query:
▪ Select Count(recid) from salesparmline
▪ Select count(recid) from purchparmline
– Clean-up Process:
▪ AR>periodic>Clean Up > Sales Update History Clean up
▪ AP>Periodic>Clean up> Purchase Update History Clean Up
– No Reason to keep data over a month
Monthly Checks
– Temporary Master Planning Data
– Table stores inventory movements caused by master planning
▪ Select count(recid) from InventSumLogtts
– Clean-up Process: AX should purge this data automatically. Should be a small
record count in the table. Check to make sure the data is for production data
versus test company data.
Quarterly Checks
▪ Sales Line
– Select count(recid) from SalesLine
– Clean Up Process: AR > Periodic > Delete Orders
– Depending on your parameter settings; SO may go to voided table
Quarterly Checks
▪ Inventory Settlement
– Stored temporary data during inventory close and other periodic adjustments
▪ Select count(recid) from inventsettlement
– If record count is > 200K, then run clean up job
▪ Inventory Mgt>Periodic>Clean Up>Inventory Settlement Clean Up.
▪ Only run cleanup on previous financial YEARs.
Batch Jobs
▪ No batch jobs with recurrence of every minute
– Will cause Jobs to get stuck in execution state
– Over lapping jobs (not just limited to 1 minute)
▪ Use the Batch Job Groups and time schedule
– Map out and track job processing length
– Be aware of similar processing and their times
▪ Which jobs are hitting Inventory at the same time?
– When does your backups run?
Reports
▪ Reports can have a big impact on the systems.
– Users will see a performance issue on data entry when someone else is
running a big report.
– Performance hits during the morning hours? Good chance someone is
running their morning reports.
▪ Daily Reports can be setup to run in batch over night.
▪ If you have a real-time backup; can you run your reports from there?
Consistency Checks
▪ System Admin > Periodic >Database > Consistency Checks
– Should run these once a quarter.
– It checks for missing data/misaligned data.
– More issues from customizations or imported data.
– If you are finding data popping up a lot, then you need to investigate
– This may cause a data query to take longer or present incorrect data set.
– If you hit the Max or a timeout, get an AX developer to help with a custom
search/dump.
Miscellaneous
▪ GUID
– Check AX Environments Unique GUID
▪ SysSQMSettings SQL Table
▪ If the same GUID is Dev/Test/Production; could have User Usage data issues
▪ Usually happens when refreshing from Prod to Dev/Test
▪ Clear the Dev/Test environments (AX will generate a new GUID)
User Features
Fact Boxes & Preview Panes
▪ Don’t use them? Turn them off!
Fact Boxes & Preview Panes
Fact Boxes & Preview Panes
▪ System Admin > Setup > System > Client Performance Options
– System wide; may not be a great option
▪ Developers can turn it off, system wide per Form
Favorites
▪ Check to see how users are access standard forms.
▪ If using a Favorite, did they create a query that might not be optimal?
User Usage Data
▪ Some Performance issues are caused by Usage Data
▪ Usually when other users can use the form or report without issues
▪ Clear our specific Usage Data components
– You can remove specific settings, if you know the form or report
▪ May lose personal preference settings
▪ Nuclear Option = Clear all of the user’s Usage Data
Resources
What else? It is still slow…
▪ Get a Performance
Assessment
– Check Indexes
– Long running queries
▪ All tests great with 100
records; how about a
few 100,000?
▪ Train your DBA on AX
Performance Tools and
Settings
Resources
▪ Storage Article:
▪ https://blogs.msdn.microsoft.com/dynamics-coe/2013/02/10/storage-requirements-for-microsoft-dynamics-ax/
▪ Performance Page
▪ https://blogs.msdn.microsoft.com/axsupport/2015/09/28/ax-performance-what-information-and-data-to-collect-when-you-want-to-open-a-support-case/
▪ Microsoft Performance Team Blog
▪ https://blogs.msdn.microsoft.com/axperf/
▪ Performance Analyzer
▪ https://blogs.msdn.microsoft.com/axinthefield/cat/dynamicsperf/
Questions?
Learn More
LEARN MORESchedule a virtual assessment with one of our service experts
today.
www.hso.com
(847) 348-0588
www.hso.com