1) please specify if only Community Server container re-start solves the issue? or the issue solves itself also?
It is my habit to restart both containers when I restart the server manually. I do them in this order in case it's important to note:
Start: Document Server then Community Server
Stop: Community Server then Document Server
Please note: In accordance with the current recommended Docker installation the containers are set to start automatically upon system boot. They do so without a problem.
We had an outage/slowdown yesterday. When I looked at the server the equivalent of one CPU was running flat out at 100%. I manually stopped the server following the sequence above. As soon as the Community Server was down the CPU utilization dropped. I then stopped the Document Server for completeness before restarting both.
Once the two containers are started I see a couple minutes of high activity - all four cores running flat out - then the activity subsides. Once it returns to the quiescent state I attempt a login.
This time I received this error upon login:
Application Exception
Runtime Error
A runtime error has occurred
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed (for security reasons).
Details: To enable the details of this specific error message to be viewable, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
Version Information: 4.4.2 (Stable 4.4.2.11/f72fe45 Fri Jul 29 09:58:49 UTC 2016); ASP.NET Version: 4.0.30319.42000
Powered by Mono
I refreshed the browser window and the CS main screen appeared. The server was still not responsive. When I attempted to logout I got the following (again):
Application Exception
Runtime Error
A runtime error has occurred
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed (for security reasons).
Details: To enable the details of this specific error message to be viewable, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
<!-- Web.Config Configuration File -->
<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>
Version Information: 4.4.2 (Stable 4.4.2.11/f72fe45 Fri Jul 29 09:58:49 UTC 2016); ASP.NET Version: 4.0.30319.42000
Powered by Mono
I should add that normally when I encounter an issue with OnlyOffice I reboot the entire server not just the containers. Once I restarted the server everything started as expected and is still working.
2) How many users do you have on your protal and do they often use the portal?
Presently there are no users on the server until this issue is resolved. This is a "test" server for evaluation and even when under "load" there are only 3 or 4 simultaneous users.
There are maybe 10 registered users for evaluation purposes.
3) Did you notice after which actions the portals become slow?
Given the current problem and the fact that at present I am the only test user, there are no actions other than Logout that precede the slowdowns. I never leave a login burning at the end of the day. I always logout out and the slowdown state/event seems to happen on the next login attempt after some time has passed (again, usually about ~24 hours from the time of initial spinup of the containers).
I've been thinking of leaving a login burning overnight to see if it keeps the server alive but have not to date.
Also, there are no scheduled events or cron jobs running at night or between logins.
Statistics: Posted by Merc — Wed Sep 07, 2016 6:13 pm