Errors in Unit logs and CPU 100%
Peter TKATCHENKO
peter at bimp.fr
Wed May 22 20:03:00 UTC 2019
Hi,
Thanks for this information.
I had my monitoring active during the last incident.
It shows that the CPU was growing up during 20 minutes approximately
(from 20% to 100%). In the same time I can see physical RAM usage
growing up (from 30% to 60%), disk I/O were stable, far from critical
levels, network traffic began to grow up when the CPU reached 100%. I'm
in a private cloud, we are not limited neither in RAM I/O nor in HDD
I/O. So I still don't understand how can I improve the situation.
Best regards,
Peter
On 22/05/2019 21:10, Travis Warlick via unit wrote:
> I am seeing the same log entries and have experienced a very similar
> consumption problem about once a month. At the onset of the problem,
> there is a short spike in CPU usage, then the CPU usage goes to nearly
> 0, but the load-average stays near 2x the number of VCPUs. After
> about 20~30 minutes, the server becomes completely unresponsive, and
> I'm forced to reboot via the AWS console. Some painfully obtained
> observations indicated that all available network and file resources
> were being consumed at this point. After a couple occurrences, I
> noticed in AWS CloudWatch metrics that the EFS volume (Elastic File
> System, i.e. basically NFS) spiked to 100% throughput at nearly the
> same time as the short spike in CPU usage and stayed there. My
> solution was to increase the volume's provisioned throughput to 10
> Mbps, and I have not experienced the issue since, although I am still
> seeing the log entries you mention. My conclusion is that nginx unit
> was consuming massive amounts of network and file system resources and
> "choking" the server. This is obviously not a long-term solution,
> though, as there's no reason for such a massive amount of EFS volume
> throughput for a Wordpress application.
>
> *
> Travis Warlick*
> *Manager, Development Operations*
>
> *maxmedia*
> www.maxmedia.com <https://www.maxmedia.com/>
>
> Find us on: LinkedIn <https://www.linkedin.com/company/maxmedia/> |
> Twitter <https://twitter.com/maxmedia_atl> | Facebook
> <https://www.facebook.com/MaxMediaATL> | Instagram
> <https://www.instagram.com/maxmedia_atl/> | Vimeo <https://vimeo.com/mxm>
>
>
>
>
> On Wed, May 22, 2019 at 11:01 AM Peter TKATCHENKO <peter at bimp.fr
> <mailto:peter at bimp.fr>> wrote:
>
> Hello,
>
> I'm using Unit to publish a PHP application (NextCloud). I am on
> FreeBSD 11.2 (jailed), I use PHP 7.2 from packages. There is an
> NGINX server as front-end.
>
> When I check Unit logs I see many records like this:
>
> 2019/05/16 12:44:39 [info] 88085#101952 *73260 shutdown(177, 2)
> failed (57: Socket is not connected)
>
> And sometimes like this:
>
> 2019/05/16 12:53:39 [alert] 88085#101951 *74551 socket close(177)
> failed (54: Connection reset by peer)
>
> The application seems to work correctly, but I would like to
> understand the cause of these errors, probably I need to tune
> something?
>
> Another problem is more important. Sometimes (once a week) 'unit:
> router' process begins to consume 100% of 4 VCPU (!!), it takes
> about 15 minutes to grow the CPU usage, and finish by blocking
> completely the application ('bad gateway' error on nginx). Restart
> of unitd service solves the problem. I see many errors of the
> first type in logs at this moment, but nothing more interesting.
>
> Best regards,
>
> Peter TKATCHENKO
> _______________________________________________
> unit mailing list
> unit at nginx.org <mailto:unit at nginx.org>
> https://mailman.nginx.org/mailman/listinfo/unit
>
>
> _______________________________________________
> unit mailing list
> unit at nginx.org
> https://mailman.nginx.org/mailman/listinfo/unit
--
*Peter TKATCHENKO | Consultant technique*
04 72 60 39 00 | 0 812 211 211
150 allée des Frènes - 69760 LIMONEST
BIMP Groupe LOGO
*Retrouvez-nous sur _www.bimp.fr <https://www.bimp.fr/>_* *|*
_*www.bimp-pro.fr <http://www.bimp-pro.fr/>*_ *|*
_*www.bimp-education.fr <http://www.bimp-education.fr/>*_
Ce message et éventuellement les pièces jointes, sont exclusivement
transmis à l'usage de leur destinataire et leur contenu est strictement
confidentiel. Une quelconque copie, retransmission, diffusion ou autre
usage, ainsi que toute utilisation par des personnes physiques ou
morales ou entités autres que le destinataire sont formellement
interdits. Si vous recevez ce message par erreur, merci de le détruire
et d'en avertir immédiatement l'expéditeur.
L'Internet ne permettant pas d'assurer l'intégrité de ce message,
l'expéditeur décline toute responsabilité au cas où il aurait été
intercepté ou modifié par quiconque.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/unit/attachments/20190522/0e6285f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogdmnndjjpbchhkf.
Type: image/png
Size: 9948 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/unit/attachments/20190522/0e6285f1/attachment.png>
More information about the unit
mailing list