I recently was working with a customer with a Lync 2013 Enterprise Edition single node front end who was finding that Lync and SQL services were frequently failing and generally performing very poorly. This was a new deployment and only homed about five users at the time.
After reviewing the Front End's CPU and RAM, we saw that it had 16GB of RAM at its disposal, and there was plenty of available memory, but we would see memory errors in the event log, and even while trying to pull up the properties of the SQL server itself:
After stopping and starting SQL, we were able to pull up the properties and found that the SQL memory was set very low.
LYNCLOCAL:
RTCLOCAL:
Comparing these settings to known working configurations, these values were about 10-12x too small. So we upped the memory here, and the server began behaving… for some time at least. The SQL memory settings are dynamically changed by Lync, so the following day, they would revert to the above settings and performance would take a hit.
In our findings, these settings are defined as a percentage of installed memory at time of Lync deployment. In this particular case, the Lync Front End deployment was performed at a time when the virtual machine was provisioned with VERY low system memory. So the SQL setting was set in Lync, and when memory was later upgraded to prepare for deployment, the change was unknown to Lync.
The Fix
The fix here was simply to re-run the Lync Deployment Wizard Step One for the local SQL instances with the system memory at its production value. Running this reset the setting and the servers have run without a performance issue since!
In testing this more since, here is what we found the defaults to be (roughly):
| Database | Min Memory | Max Memory |
| RTCLOCAL | 12% of installed | 15% of installed |
| LYNCLOCAL | 6% of installed | 8% of installed |
No comments:
Post a Comment