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: 24128 Last Modification Date: 1/22/2015 9:22 AM Platform:
Level: Closed

Support Request: Database access errors and performance issues

Description

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.

Answer: (3)
Re: Database access errors and performance issues 1/22/2015 11:13 AM
Hello,

This is a Windows / IIS /SQL issue and does not directly apply to the SiteRemote software. SiteRemote is just using SQL and DefaultAppPool (in IIS).

In regards to the error message you need to check for previous errors (in the event log) to find the reason for the problem.

If that doesn’t help you may send the Windows Event log and a ZIP of the SiteRemote Log folder (…\PROVISIO\SiteRemote\Log) with the information at which date and time the problem occurred to support-europe(at)provisio.com


>>>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?<<<
That the spike subsided doesn’t mean that the reason for the error is solved but e.g. that the requests/connections to the database have been lowered (by any of the involved components) so that the error will not occur so often anymore.

>>>2) Why would this login failure cause the massive spike in resource utilization by the SiteRemoteServerService?<<<
Every connection of a client machine will cause a request to the SQL Database (to store client information) and if that fails the SiteRemote Server service needs more performance because it has to wait for the connection time out and also needs to request again to send outstanding data the SiteKiosk client tries to send again and again.

>>>3) Does a SQL Server login and user need to be explicit created for the app pool user?<<<
No, that is not necessary (for SiteRemote).

Regards,
Michael Olbrich
Re: Database access errors and performance issues 1/23/2015 7:02 PM
Hello

In regards to your answer to my second question, I'd like to have a better understanding of how this works. Does the SiteKiosk client connect to the SiteRemote service or web application to update it's information? The SiteRemoteServerService is running as an actual user (SITEREMOTE) so if it was the service that could not log in to the SQL Server instance, would I not see login failures for that user instead of the app pool user?

That aside, I have reviewed the logs again and I cannot see any previous errors that seem related to this issue in any way. I will be sending an email to the address you supplied with all the requested information for further analysis.
Re: Database access errors and performance issues 1/27/2015 10:43 AM
Hello,

The SiteKiosk Client directly communicates with SQL through the SiteRemote Server service (running with user “SITEREMOTE”) and the web page communicates through the user “SITEREMOTEADMIN”.
The login failure of the app pool user might be caused by another process in IIS or as a follow-up issue, e.g. when opening a SiteRemote web page first the DefautlAppPool process starts in IIS with using the standard IIS user and then changes to the SITEREMOTEADMIN user with the information given in the corresponding “web.config” (identity impersonate=).

Regards,
Michael Olbrich

P.S. closed this ticket because we are in contact via e-mail.
Post comment
My Account
Login
Language (Tickets):