docker上的Django在启动后需要花费很多时间来立即响应任何HTTP请求

我正在运行一个dockerized Django应用程序:只有Django + Postgres在本地。当我启动应用程序并转到任何本地主机URL时，最多需要3-4分钟才能响应。然后按预期工作，响应时间为100-200毫秒。

没有繁重的进程在运行，不管URL是什么，它的行为都是这样的，它可以是admin, swagger或任何其他。
在"冻结"期间，它明显地加载了我的CPU。我在一台很旧的机器上遇到这个问题已经有一段时间了，我以为这只是因为它老了，但我刚刚在一台全新的机器上测试了它，它有同样的问题，所以这不是硬件。
部署和URL/API测试不受此影响，并且不会冻结。
使用docker-compose exec或~run执行任何命令都可以正常工作，尽管应用程序不响应任何HTTP请求。

PS:如果有必要，我可以添加线程转储或任何其他日志，我真的不知道在哪里寻找问题的根源。

这是我的.yml文件内容，以防它可能是罪魁祸首:

version: '3'
volumes:
backend_local_postgres_data: {}
backend_local_postgres_data_backups: {}
services:
django: &django
build:
context: .
dockerfile: ./compose/local/django/Dockerfile
image: backend_local_django
container_name: backend_local_django
depends_on:
- postgres
volumes:
- .:/app:z
env_file:
- ./.envs/.local/.django
- ./.envs/.local/.postgres
ports:
- "8000:8000"
command: /start
postgres:
build:
context: .
dockerfile: ./compose/production/postgres/Dockerfile
image: backend_production_postgres
container_name: backend_local_postgres
volumes:
- backend_local_postgres_data:/var/lib/postgresql/data:Z
- backend_local_postgres_data_backups:/backups:z
env_file:
- ./.envs/.local/.postgres

应用程序启动日志，在几个答案中请求:

(venv) docker-compose -f local.yml up
[+] Running 1/1
- Network backend_default  Created                                                                                                                                                                                          0.6s 
[+] Running 3/34T19:42:41+01:00" level=warning msg="mount of type `volume` should not define `bind` option"
- Network backed_default            Created                                                                                                                                                                                0.6s
- Container backend_local_postgres  Created                                                                                                                                                                                0.1s
- Container backend_local_django    Created                                                                                                                                                                                0.1s
Attaching to backend_local_django, backend_local_postgres
| 
| PostgreSQL Database directory appears to contain a database; Skipping initialization
| 
| 2023-02-04 18:42:42.783 UTC [1] LOG:  starting PostgreSQL 14.6 (Debian 14.6-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
| 2023-02-04 18:42:42.783 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
| 2023-02-04 18:42:42.783 UTC [1] LOG:  listening on IPv6 address "::", port 5432
| 2023-02-04 18:42:42.792 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
| 2023-02-04 18:42:42.804 UTC [27] LOG:  database system was shut down at 2023-02-01 11:55:22 UTC
| 2023-02-04 18:42:42.814 UTC [1] LOG:  database system is ready to accept connections
| PostgreSQL is available
| Operations to perform:
|   Apply all migrations: account, admin, auth, authtoken, constructor, contenttypes, django_celery_beat, sessions, sites, socialaccount, users
| Running migrations:      
|   No migrations to apply.
| WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
|  * Running on all addresses (0.0.0.0)
|  * Running on http://127.0.0.1:8000  
|  * Running on http://172.18.0.3:8000 
| Press CTRL+C to quit
|  * Restarting with watchdog (inotify)
| Performing system checks...
| 
| System check identified no issues (0 silenced).
| 
| Django version 4.0.8, using settings 'config.settings.local'
| Development server is running at http://0.0.0.0:8000/
| Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
| Quit the server with CONTROL-C.
|  * Debugger is active!
|  * Debugger PIN: 130-235-671

如果问题可能连接到我正在使用的一个库，下面是我的requirements.txt:

pytz==2022.6  # https://github.com/stub42/pytz
python-slugify==7.0.0  # https://github.com/un33k/python-slugify
Pillow==9.3.0  # https://github.com/python-pillow/Pillow
argon2-cffi==21.3.0  # https://github.com/hynek/argon2_cffi
redis==4.3.5  # https://github.com/redis/redis-py
hiredis==2.0.0  # https://github.com/redis/hiredis-py
celery==5.2.7  # pyup: < 6.0  # https://github.com/celery/celery
django-celery-beat==2.4.0  # https://github.com/celery/django-celery-beat
flower==1.2.0  # https://github.com/mher/flower
# Django
# ------------------------------------------------------------------------------
django==4.0.8  # pyup: < 4.1  # https://www.djangoproject.com/
django-environ==0.9.0  # https://github.com/joke2k/django-environ
django-model-utils==4.3.1  # https://github.com/jazzband/django-model-utils
django-allauth==0.51.0  # https://github.com/pennersr/django-allauth
django-crispy-forms==1.14.0  # https://github.com/django-crispy-forms/django-crispy-forms
crispy-bootstrap5==0.7  # https://github.com/django-crispy-forms/crispy-bootstrap5
django-redis==5.2.0  # https://github.com/jazzband/django-redis
# Django REST Framework
djangorestframework==3.14.0  # https://github.com/encode/django-rest-framework
django-cors-headers==3.13.0 # https://github.com/adamchainz/django-cors-headers
djangorestframework-simplejwt==5.2.2
drf-yasg==1.21.4

-r base.txt
Werkzeug[watchdog]==2.2.2 # https://github.com/pallets/werkzeug
ipdb==0.13.9  # https://github.com/gotcha/ipdb
psycopg2-binary==2.9.5  # https://github.com/psycopg/psycopg2
watchfiles==0.18.1  # https://github.com/samuelcolvin/watchfiles
# Testing
# ------------------------------------------------------------------------------
mypy==0.982  # https://github.com/python/mypy
django-stubs==1.12.0  # https://github.com/typeddjango/django-stubs
pytest==7.2.0  # https://github.com/pytest-dev/pytest
pytest-sugar==0.9.6  # https://github.com/Frozenball/pytest-sugar
djangorestframework-stubs==1.7.0  # https://github.com/typeddjango/djangorestframework-stubs
# Documentation
# ------------------------------------------------------------------------------
sphinx==5.3.0  # https://github.com/sphinx-doc/sphinx
sphinx-autobuild==2021.3.14 # https://github.com/GaretJax/sphinx-autobuild
# Code quality
# ------------------------------------------------------------------------------
flake8==5.0.4  # https://github.com/PyCQA/flake8
flake8-isort==5.0.3  # https://github.com/gforcada/flake8-isort
coverage==6.5.0  # https://github.com/nedbat/coveragepy
black==22.10.0  # https://github.com/psf/black
pylint-django==2.5.3  # https://github.com/PyCQA/pylint-django
pylint-celery==0.3  # https://github.com/PyCQA/pylint-celery
pre-commit==2.20.0  # https://github.com/pre-commit/pre-commit
# Django
# ------------------------------------------------------------------------------
factory-boy==3.2.1  # https://github.com/FactoryBoy/factory_boy
django-debug-toolbar==3.7.0  # https://github.com/jazzband/django-debug-toolbar
django-extensions==3.2.1  # https://github.com/django-extensions/django-extensions
django-coverage-plugin==2.0.4  # https://github.com/nedbat/django_coverage_plugin
pytest-django==4.5.2  # https://github.com/pytest-dev/pytest-django

如果启动服务器并在访问任何页面之前等待几分钟，那么访问第一个页面是否仍然需要几分钟?有可能由于某种原因，集装箱需要很长时间才能启动。弄清楚启动时间是否很长，或者某些特定的请求可能是一个很好的起点。

根据这个线程，Werkzeug有一个bug:https://github.com/cookiecutter/cookiecutter-django/issues/4179
更具体地说，从需求中删除watchdog并将Werkzeug更新到2.3.0或更高版本可以修复此问题。显然，它正在重新启动Django，而代码没有更改。因此，它被无限循环，每次都崩溃并重新启动。

这可能是由于多种原因造成的。请提供更多详细信息。

也许postgresql需要很长时间才能启动?
您使用的是什么操作系统?
您正在使用哪些第三方软件包?
您是否尝试从docker-compose中删除:z ?
你是否尝试做一些分析，例如使用行分析器?
您是否尝试监视容器内的进程?或者，一般来说，查找哪个进程负载CPU?

这个缓慢的初始响应时间可能是由于您的应用程序执行一些耗时的任务。

分析的起始点可以是"-X importtime"选项设置为Python解释器。这可能有助于识别速度较慢的模块(如果有的话)。

相关内容

最新更新

热门标签：