Ticket ID: 21317
|
Creation Date: 1/21/2015 8:42 PM
|
Product: SiteKiosk Classic Windows
|
Attachment: -
|
TicketType: Support Request
|
Version: 4.0.0
|
Language: English
|
Views: 24126
|
Last Modification Date: 1/22/2015 9:22 AM
|
Platform:
|
|
Level: Closed
|
|
|
Support Request: Database access errors and performance issues
Hello
Recently we recorded dozens and dozens of this message being logged by SQL Server in Event Viewer during an eight hour period:
Login failed for user 'IIS APPPOOL\DefaultAppPool'. Reason: Token-based server access validation
failed with an infrastructure error. Check for previous errors. [CLIENT: <local machine>]
SiteRemote is the only application using the Default Application Pool and corresponding user. Further investigation of logged events shows that this message is normally recorded once or twice a day, if at all.
The corresponding entries in the SQL Server log showed that this was Error 18456 State 11, meaning "valid login but server access failure". The timing of the start this spike in login failures coincides with the following events:
A) A spike in the memory utilization of the SiteRemoteServerService (from ~200 MB to ~ 4 GB)
B) A spike in the CPU utilization of the SiteRemoteServerServer (from 3% to 45% of available CPU, with other running processes not significantly changing their utilization during this time)
C) A reduction in the memory utilization of SQL Server (from ~3 GB to ~200 MB)
D) PCs managed by SiteRemote showed as having not contacted the server since roughly the start of the login failure spike
After the initial eight hour period had passed, identical login failures for the DefaultAppPool user were logged every 1-3 hours. However, the changes in SiteRemoteServerService and sqlserver resource utilization did not change, nor did the managed PCs show as contacted the server. Normal behavior was restored roughly 36 hours after the start of the login failure spike with a full reboot of the server hosting SiteRemote.
Generally, my question is: what's going on here? More specifically:
1) I assume that check-ins from the SiteKiosk PCs could not be recorded because the SiteRemote application could not connect to the database, but why would this failure to check-in persist after the login failure spike subsided?
2) Why would this login failure cause the massive spike in resource utilization by the SiteRemoteServerService?
3) Does a SQL Server login and user need to be explicit created for the app pool user?
Please let me know if I can clarify anything.