在Nginx+；Gunicorn&x2B；Django堆栈 我遇到的问题

我遇到了一个问题，一些网站需要很长时间才能加载（我所说的“长时间”是指最多16秒）。有时，它们可能会完全超时，从而生成Nginx 504错误。通常，当一个站点超时时，我可以重新加载该站点，它会很快加载。我遇到问题的站点的访问量非常低。我正在通过加载Django管理索引页面来测试该站点，以尝试消除可能由于糟糕的代码而导致的任何缓慢。还应该注意的是，这个特定的站点只使用Django管理员，因为它是一个仅供员工使用的intranet类型的站点

主机设置 我托管的所有站点都位于两台Rackspace云服务器上。第一个服务器是我的应用服务器，它有1024MB的RAM，第二个服务器是我的数据库服务器，它有2048MB的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

为了尝试解决正在发生的问题，我写了一篇简短的文章，其中列出了应用服务器上的内存使用情况

使用匿名站点域打印的示例：

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，这完全修复了网站的缓慢。尽管我能够解决这个问题，但我花了比我想要的时间长得多的时间，我仍然觉得我基本上是在猜测是什么导致了网站速度变慢。所有这些都引出了我的问题

问题

如何判断低流量站点上的站点慢度不是由站点不活动引起的，这会导致站点变为不活动，然后导致Gunicorn在站点变为不活动后再次加载站点？是否有防止站点处于非活动状态的设置

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

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

确定是您的Gunicorn进程被交换还是其他进程被交换的最佳方法是什么

我主持的大多数网站都没有太多的流量，所以我只使用了一名Gunicorn员工。有没有更科学的方法来确定和调整一个站点上有多少Gunicorn员工

当在同一台服务器上托管多个站点时，是否有方法将其配置为使用更少的内存

---

在一台只有1GB内存的服务器上可以托管很多站点。您的内存利用率接近100%，您拥有的数字可能是“备用”数字。在服务请求的过程中，每个进程的RAM使用率可以而且将会膨胀。一开始，您需要向这个实例添加更多RAM，更好的是，将一些站点转移到另一台服务器上

关于你的问题：

你是从哪里想到网站会变得“不活跃”而Gunicorn必须重新加载该网站的？那是垃圾。只要Gunicorn进程正在运行（即未手动终止或因站点错误而终止），它将保持完全初始化并准备就绪，无论是一个小时还是一个月

你在这里砍树叶，让根不动。每个Gunicorn进程的内存使用都没有什么不寻常的地方。它需要RAM来运行。您的问题是试图在动力严重不足的服务器上运行过多。在这里，没有优化可以拯救你。您需要更多的RAM或更多的服务器。可能两者都有

没必要。同样，问题已经确定。事实上，从你发布的数字可以很清楚地看出

无法可靠地知道正在交换哪些进程。它每秒钟都会发生变化，这取决于哪些正在积极运行并需要更多的RAM，哪些处于非活动状态或根本不处于活动状态。当您的服务器如此缺乏资源时，它会花费一半的时间来决定下一步要处理哪个进程，特别是当它们都处于活动状态并在争夺资源时

对。Gunicorn建议使用2*cores+1。所以在双核系统上，这是5；在四核上，9。然而，在这个系统上，你不可能为每个站点运行5个工作人员。你甚至不能为每个人运行一个worker

这取决于“事物”。但是，当多个站点托管在同一台服务器上时，这些服务器是不可靠的。在像您这样的小型VPS实例上，尤其是只有1GB内存的情况下，一个站点几乎就是您的极限。两个，也许吧

1） 不知道你说的不活跃是什么意思？如中所示，是否被nginx禁用？还是工作太慢

2和3）django调试工具栏和django调试日志将是一个很好的开始。如果这没有帮助，那么是时候转到服务器级评测，看看是哪些进程导致了问题

4） 使用顶部：

5） 是-基准测试。选择一个基准测试工具（例如apachebench）并根据当前配置运行测试。调整一些东西。再次运行测试。重复此操作，直到您的性能问题消失！为了获得最佳效果，请使用与实时流量类似的流量（在URL分布、GET/POST等方面）

6） 是的，在nginx和应用程序级别。通过分析每个站点并提高其内存使用率，您可能会获得最大的好处（请参见2）。

关于：

关于你对5的回答，我相信Gunicorn的建议是 太过分了

我最近做了一些特别的测试