ubuntu 我的VPS上100%的CPU利用率- Django app gunicorn

7gcisfzg  于 2023-10-17  发布在  Go
关注(0)|答案(1)|浏览(112)

我有一个在Docker compose环境中运行Nginx,Django,Postgres和Golang微服务的VPS,最近我注意到它一直达到100%的CPU利用率,并且不再工作。我怀疑这可能是由于DDoS攻击或奇怪的gunicorn行为。

**VPS操作系统:**Ubuntu 22.04.2 LTS
意见:

高CPU使用率从昨天(24小时前)开始。

采取的步骤:

设置和配置ufw,和一个digitalocean防火墙。

NGINX酒店,伊斯坦布尔

...
89.44.9.51 - - [29/Sep/2023:05:09:58 +0000] "OPTIONS /webclient/api/MyPhone/session HTTP/1.1" 444 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 3CXDesktopApp/18.13.959 Chrome/112.0.5615.165 Electron/24.3.0 Safari/537.36" "-"
89.44.9.51 - - [29/Sep/2023:05:10:01 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:07 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:12 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:17 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:22 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:27 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:32 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
89.44.9.51 - - [29/Sep/2023:05:10:38 +0000] "GET /provisioning/5lbr5h6kse0q/TcxProvFiles/3cxProv_YU8SR32OGF200.xml HTTP/1.1" 444 0 "-" "electron-fetch/1.0 electron (+https://github.com/arantes555/electron-fetch)" "-"
...

顶部

15284 root      20   0  298336 133468  18568 S  90.7   3.3   4:06.24 gunicorn                                                                                                                           
  15477 lxd       20   0  216928  18104  15104 R   8.6   0.5   0:03.21 postgres

当访问域时,它直接达到CPU限制。我正在实现一些新的功能,这就像一个魅力(本地),但我想不出会做这样的事情。实际上,我也回滚了所有内容,遇到了同样的问题。
我被困在哪里看。
会很感激任何提示。
PS:如果你需要更多的信息,请在评论中告诉我。我不想再拖下去了。
在此先谢谢您!

编辑附加信息

docker logs 7e3e93cda248 -f
Collect static files

254 static files copied to '/staticfiles', 756 post-processed.
Apply database migrations
System check identified some issues:

WARNINGS:
?: (urls.W005) URL namespace 'v1' isn't unique. You may not be able to reverse all URLs in this namespace
Operations to perform:
  Apply all migrations: admin, app, auth, contenttypes, sessions
Running migrations:
  No migrations to apply.
System check identified some issues:

WARNINGS:
?: (urls.W005) URL namespace 'v1' isn't unique. You may not be able to reverse all URLs in this namespace
No changes detected in app 'app'
System check identified some issues:

WARNINGS:
?: (urls.W005) URL namespace 'v1' isn't unique. You may not be able to reverse all URLs in this namespace
Operations to perform:
  Apply all migrations: admin, app, auth, contenttypes, sessions
Running migrations:
  No migrations to apply.
[2023-09-29 04:52:38 +0000] [10] [INFO] Starting gunicorn 21.2.0
[2023-09-29 04:52:38 +0000] [10] [INFO] Listening at: http://0.0.0.0:8000 (10)
[2023-09-29 04:52:38 +0000] [10] [INFO] Using worker: gthread
[2023-09-29 04:52:38 +0000] [11] [INFO] Booting worker with pid: 11
Not Found: /favicon.ico
gunicorn --pythonpath . app.wsgi:application --bind 0.0.0.0:8000 --timeout 120 --threads=3
2 vCPUs
xmd2e60i

xmd2e60i1#

所以很明显这是一个应用程序级别的问题,当我看到Postgres PID也消耗了大量的CPU时,我就猜到了。
有一个不执行的ORM操作,不知何故在超时结束。

相关问题