django - 解决Nginx + Gunicorn + Django堆栈上的网站缓慢问题

Question

我遇到的问题

我遇到了一个问题，即某些站点需要很长时间才能加载(“长时间”是指最多16秒)。有时它们可​​能会完全超时，从而产生Nginx 504错误。通常，当站点超时时，我可以再次重新加载该站点，并且它将很快加载。我遇到问题的网站的流量很小。我正在通过加载Django admin索引页面来测试站点，以尝试消除由于代码差而导致的运行缓慢。还应注意，此特定站点仅使用Django admin，因为它是仅供员工使用的Intranet类型站点。

托管设置

我托管的所有站点都在两个Rackspace云服务器上。第一个服务器是我的应用程序服务器，它具有1024 MB的RAM，第二个服务器是我的数据库服务器，它具有2048 MB的RAM。应用服务器使用Nginx为每个站点提供服务，Nginx提供所有静态文件，并将其他所有内容代理给每个站点的Django Gunicorn工作人员。

当查看数据库服务器的RAM和CPU负载时，似乎数据库服务器上的一切都很好。

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1999       1597        402          0        200       1007
-/+ buffers/cache:        389       1610
Swap:         4094          0       4094


Top shows a CPU load average of: 0.00, 0.01, 0.05

为了尝试对发生的问题进行故障排除，我编写了一个简短的script，它打印出应用服务器上的内存使用情况。

带有匿名站点域的示例打印:

Celery:     23 MB
Gunicorn:  566 MB
Nginx:       8 MB
Redis:     684 KB
Other:      73 MB

             total       used       free     shared    buffers     cached
Mem:           993        906         87          0         19         62
-/+ buffers/cache:        824        169
Swap:         2047        828       1218

Gunicorn memory usage by webste:
site01.example.com    31 MB
site02.example.com    19 MB
site03.example.com     7 MB
site04.example.com     9 MB
site05.example.com    47 MB
site06.example.com    25 MB
site07.example.com    14 MB
site08.example.com    18 MB
site09.example.com    27 MB
site10.example.com    15 MB
site11.example.com    14 MB
site12.example.com     7 MB
site13.example.com    18 MB
site14.example.com    18 MB
site15.example.com    10 MB
site16.example.com    25 MB
site17.example.com    13 MB
site18.example.com    18 MB
site19.example.com    37 MB
site20.example.com    30 MB
site21.example.com    23 MB
site22.example.com    28 MB
site23.example.com    80 MB
site24.example.com    15 MB
site25.example.com     5 MB

示例Gunicorn配置文件:

pidfile = '/var/run/gunicorn_example.com.pid'
proc_name = 'example.com'
workers = 1
bind = 'unix:/tmp/gunicorn_example.com.sock'

Nginx配置示例:

upstream example_app_server {
    server unix:/tmp/gunicorn_example.com.sock fail_timeout=0;
}

server {

    listen       80;
    server_name  example.com;
    access_log   /var/log/nginx/example.com.access.log;
    error_log    /var/log/nginx/example.com.error.log;

    location = /favicon.ico {
        return  404;
    }

    location  /static/ {
        root  /srv/sites/example/;
    }

    location  /media/ {
        root  /srv/sites/example/;
    }

    location  / {
        proxy_pass            http://example_app_server;
        proxy_redirect        off;
        proxy_set_header      Host             $host;
        proxy_set_header      X-Real-IP        $remote_addr;
        proxy_set_header      X-Forwarded-For  $proxy_add_x_forwarded_for;
        client_max_body_size  10m;
    }

}

如您所见，有很多内存可以交换，因此为了解决我的问题，我在应用服务器上升级了ram，这完全解决了网站的运行速度问题。即使我能够解决此问题，但花费的时间比我想要的要长得多，而且我仍然觉得我基本上是在猜测造成网站运行缓慢的原因。所有这些使我想到了问题...

问题

如何判断低流量站点上的站点缓慢不是由站点不 Activity 引起的，该站点不 Activity 导致站点不 Activity ，然后导致Gunicorn必须在站点不 Activity 后再次加载该站点？是否有设置来防止站点处于非 Activity 状态？

似乎我的某些网站占用了太多内存。我可以使用哪些工具来减少站点使用的内存量？我应该使用一些Python分析工具吗？

需要采取哪些工具和步骤来确定瓶颈在堆栈的哪个级别上发生？

确定是正在交换Gunicorn进程还是正在交换其他进程的最佳方法是什么？

我托管的大多数网站流量都很少，因此我只使用了一名Gunicorn worker 。有没有更科学的方法来确定和调整您的站点上有多少个Gunicorn worker ？

在同一服务器上托管多个站点时，是否可以通过一些方式配置事物以使用更少的内存？

Answer 1

只有1GB RAM的服务器上可以托管许多站点。您的内存利用率接近100％，您拥有的数字可能是“备用”数字。每个进程的RAM使用情况可以并且将在服务请求的过程中迅速增加。马上，您需要为该实例添加更多的RAM，更好的是，将某些站点移到另一台服务器上。

关于您的问题:

您从哪里得知站点变为“非 Activity ”，然后Gunicorn必须重新加载该站点？那是垃圾只要Gunicorn进程正在运行(即不是手动终止或因站点错误而终止)，它就会保持完全初始化并准备就绪，无论是一个小时还是一个月。

您正在这里的树叶上乱砍，使根保持不变。每个Gunicorn进程的内存使用情况都与众不同。它需要RAM才能运行。您的问题是试图在功率严重不足的服务器上运行过多。没有任何优化可以将您保存在这里。您需要更多RAM或更多服务器。可能两者都有。

不需要。同样，该问题已经确定。实际上，通过您发布的数字可以很清楚地看到。

无法可靠地知道正在交换哪些进程。它每秒更改一次，具体取决于哪个正在运行并且需要更多RAM，哪些不处于 Activity 状态或根本不处于 Activity 状态。当您的服务器被资源所束缚时，它花费了一半的时间来弄清楚下一步该如何处理，特别是如果它们都处于 Activity 状态并且正在争夺资源。

是的。 Gunicorn建议2 *核心+1。因此在双核系统上为5；在四核9上。但是，在该系统上，您无法为每个这些站点甚至运行5个工作程序。您甚至无法可靠地为每个 worker 运行1名 worker 。

它取决于“事物”。但是，当多个站点托管在同一台服务器上时，这些服务器就成了特定的野兽。在像您这样的小型VPS实例上，尤其是只有1GB RAM的情况下，一个站点几乎是您的限制。两个，也许。