docker上的Django在启动后立即响应任何HTTP请求都需要花费大量时间

z0qdvdin  于 2023-02-05  发布在  Go
关注(0)|答案(3)|浏览(217)

我正在运行一个停靠的Django应用程序:只有Django + Postgres在本地。当我启动应用程序并转到任何本地主机URL时,它需要长达3-4分钟的时间才能响应。然后它就像预期的那样工作,响应时间为100-200毫秒。

  • 有没有沉重的进程运行,它的行为就像不管网址,它可以是管理员, Swagger 或任何其他。
  • 在“冻结”期间,它会明显地加载我的CPU。我在一台非常旧的机器上遇到这个问题已经有一段时间了,我认为这只是因为它太旧了,但我刚刚在一台全新的机器上测试过,它也有同样的问题,所以不是硬件问题。
  • 部署和URL/API测试不受此影响,并且不会冻结。
  • 尽管应用未响应任何HTTP请求,但使用docker-compose exec~run执行任何命令仍能按预期工作。
  • 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
一个二个一个一个

dba5bblo

dba5bblo1#

如果你启动服务器并在访问任何页面之前等待几分钟,那么第一个页面是否仍然需要几分钟呢?可能是由于某种原因,容器需要很长时间才能启动。弄清楚这是一个很长的启动时间,还是一些特定于请求的启动时间,这可能是一个很好的开始。

qybjjes1

qybjjes12#

这可能是由于各种原因。请向我们提供更多详细信息。

  • 也许postgresql启动需要很长时间?
  • 您使用的是什么操作系统?
  • 您使用的是哪些第三方软件包?
  • 您是否尝试从docker-compose中删除:z?
  • 你有没有尝试过不使用第三方软件包来运行django?
  • 您是否尝试过进行一些分析,例如使用line-profiler
  • 你有没有试过监视你的容器内的进程?或者,一般来说,找到哪个进程负载CPU?

这种缓慢的初始响应时间可能是由于应用程序执行了一些耗时的任务。
分析的起点可以是Python解释器的"-X importtime"选项,这有助于识别速度较慢的模块(如果有的话)。

sd2nnvve

sd2nnvve3#

听起来您可能遇到了从本地主机访问Django应用程序时性能变慢的问题。以下是您可以尝试解决该问题的一些方法:
检查Django应用程序日志中的错误。可能是某个错误导致应用程序冻结了几分钟。
检查系统的资源使用情况,如CPU和内存使用情况。如果系统资源不足,则可能会影响应用程序的性能。
检查Postgres数据库的性能。如果数据库响应缓慢,可能会影响Django应用程序的性能。
检查本地主机和Docker容器之间的网络连接。如果网络连接存在问题,则可能会影响应用程序的性能。
检查Docker容器的配置。确保容器配置了适当的资源限制,并且使用正确的环境变量运行。
如果这些步骤都不能解决问题,您可以尝试在Django应用中添加调试日志,以更好地了解冻结期间发生的事情。此外,您可以尝试使用分析器来识别应用的哪些部分执行时间最长,并优化这些部分。
根据docker-compose.yml文件的内容,您的服务配置似乎设置正确。您可以尝试以下几项操作:
检查服务的资源使用情况。确保服务在CPU和内存等资源上运行时不会不足,这会导致性能降低。
请检查服务之间的网络连接。如果网络连接存在问题,则可能会影响应用程序的性能。
请检查Postgres服务的日志中是否存在任何错误消息。如果数据库存在问题,则可能会影响应用程序的性能。
检查.env文件中的环境变量。确保设置了正确的环境变量,并且这些变量不会导致任何问题。
尝试通过禁用任何不需要的服务或卷来隔离此问题。这将帮助你确定此问题是否与其中一个服务或卷有关。
如果这些步骤都不能解决问题,您可以尝试在Django应用和Postgres服务中添加调试日志,以更好地了解冻结期间发生的情况。此外,您可以尝试使用分析器来识别应用的哪些部分执行时间最长,并优化这些部分。

相关问题