我在Ubuntu服务器上运行了一个Node.js / Express应用程序。它位于NGINX反向代理的后面,该代理将端口80(或ssl的443)上的流量传递到应用程序的端口。
我最近遇到了一个问题,在没有可识别原因的情况下,尝试访问/
的流量最终会出现504
错误并超时。作为测试,我增加了超时,现在出现502
错误。我可以在我的应用程序/login
上访问其他一些路径,例如,没有任何问题。
当我重新启动Express应用程序时,我的应用程序运行正常,没有任何问题,通常会持续几天,直到再次发生这种情况。查看我的Express应用程序的日志,一个好的请求看起来像:
GET / 200 15.786 ms - 1214
而没有正确响应的请求看起来像这样:
GET / - - ms - -
此应用程序已正常运行约13个月,没有任何问题,此问题已出现,没有提示。我没有在发生这种情况的时间内推送任何更新。
这是我的NGINX配置(为了安全而修改了一点,例如example.com
)
upstream site_upstream {
server 127.0.0.1:3000;
}
server {
listen 80;
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
location / {
proxy_pass http://site_upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_redirect http://rpa_upstream https://example.com;
}
}
我不确定我的NGINX配置或我的应用程序本身是否存在问题,因为我的配置都没有改变。
答案 0 :(得分:1)
这听起来像是nginx或Node应用程序中的内存泄漏。如果它在重新启动Node应用程序后重新开始工作,但没有重新启动nginx,那么它似乎是你的Node应用程序的问题。
尝试在没有代理的情况下直接访问您的应用,看看在这种情况下你有什么问题。您有时可以在浏览器的开发人员工具中使用这种方式获得更详细的信息,也可以使用像curl这样的命令行工具或像Apache ab
这样的基准测试。使用ab
运行繁重的基准可以帮助您更快地发现问题而不是等待。
当你没有显示任何代码时,很难说出究竟是什么问题。
如果以前工作正常,并且在此期间你没有升级任何东西(你的应用程序,任何Node模块或Node本身),那么你的流量可能会略有增加,现在你开始看到那些不是以前表现出来。或者,您的系统现在可以使用更多RAM来执行其他任务,并且内存泄漏开始比以前更快地出现问题。
您可以定期开始记录process.memoryUsage()
返回的数据,看看是否有任何问题。
还可以使用ps
,top
,htop
或其他命令监控您的节点流程,或查看内存使用量/proc/PID/status
等。
您还可以定期监视/proc/meminfo
并查看系统中使用的总内存是否与您的应用程序无响应相关。
可能导致问题的另一件事是,例如,如果您没有在应用程序内部处理错误和超时,则对数据库的连接响应缓慢或根本不响应。添加更广泛的日志记录(进入每个路由处理程序的行,每个I / O操作开始之前的一行和,在每次I / O操作成功或失败或超时后)都应该让您更深入地了解它