Sep 30 2020 07:51 AM
Sep 30 2020 07:51 AM
We are running a BT 2010 environment which processes over 150,000 messages per day during the peak business hours. We have an SQL Server instance running on a separate Windows server 2008 R2 instance.
For past few weeks, we are experiencing intermittent outages and the error logged on BizTalk APP server says "Login is from an untrusted domain.....". upon checking the logs on database server we have NETLOGON errors (unable to contact AD for credential validation) due to "Unavailable Memory". CPU Utilization and Memory utilization is 95-100% on SQL server most of the times.
Following are the settings on SQL server - RAM: 16 GB, SQL Server Min and Max memory Allocation is 12 GB. ENTSSO is also running on the same SQL server.
Please suggest any change in setting on SQL server which can reduce High Utilization and free up some memory for background windows processes and ENTSSO.
Oct 15 2020 04:22 PM
@sudhanshu3992 16GB sounds too small for such environment. My developer laptop has 64GB. I would recommend also to upgrade to BizTalk 2020 from supportability perspective. I would recommend here to increase to 32GB at least and then put MAX server memory to around 26-28 GB instead. Adding a cpu core to SQL might also be a good idea as it sounds too much to be on 95-100%. With increased memory it may be less, but still sounds like you need more CPU power. To offload SQL pressure, you can change default 500ms maxreceiveinterval (polling) to something larger, e g 2000ms (2s). Try to avoid low latency polling SQL intensively if not really necessary. If needed limit that to one or few hosts only and increase the other batch hosts. For pure receive hosts they don't use dequeue polling since they get their items from other sources so you can even put more, e g 30000ms (30s).
Given your logon failures, you may actually also hit MaxConcurrentAPI NTLM netlogon limit. Search and you will find a script to measure if you need to change it (there is some potential area in 15-45s which is not really measurable here though). You can try to increase MaxConcurrentAPI to 10 or 20 on BizTalk and SQL servers (I assume domain controllers already have higher setting) to see if that helps as well, but you should reconfigure SQL to use Kerberos (cached tickets) instead so it doesn't need to go to domain controller on each new connection. BizTalk uses quite a lot of SQL connections.
Also, try to minimise or disable tracking if not needed as it will reduce SQL load as well.
Some customers have lots of host instances. You need to find good balance as this increases the number of pollings/dequeues also. It depends on your network, cpu, memory, and load. Some may be fine with 40+ BizTalk host instances if having really powerful lots of cpu/128GB SQL server, others it is better with 10-20. But as mentioned, you can also increase polling interval in host settings as a balance here.
You can also increase large message size limits in BizTalk group settings. Then your messages are kept larger and not split into lots of small sub-transactions (parts). If BizTalk server has enough memory this may be good if you process larger messages than 100KB. This can have good effect on SQL and general performance as well.