排除Nginx + Gunicorn + Django堆栈上的站点速度减慢故障
我遇到的问题
我遇到了一个问题，一些网站需要很长时间才能加载(“很长时间”，我指的是长达16秒)。有时它们可能会完全超时，这会生成一个Nginx 504错误。通常，当站点超时时，我可以重新加载该站点，它会加载得很快。我遇到问题的网站的访问量非常低。我正在通过加载Django管理索引页面来测试网站，以便尝试消除由于糟糕的代码可能导致的任何缓慢。还应该注意的是，这个特定的站点只使用Django管理员，因为它是仅供员工使用的内部网类型的站点。
主机设置
我托管的所有网站都在两个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为了尝试解决问题，我编写了一个快速的小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，这完全解决了站点的缓慢问题。尽管我能够解决这个问题，但我花的时间比我想象的要长得多，我仍然觉得我基本上是在猜测是什么导致了网站速度变慢。所有这些都引出了我的问题……
问题
- 如何判断低流量站点上的站点速度缓慢不是由站点不活动引起的，站点不活动会导致Gunicorn在站点不活动后再次加载站点？是否有阻止站点变为非活动状态的设置？
- 我似乎有一些站点占用了太多内存。我可以使用哪些工具来减少站点的内存使用量？我应该使用一些Python分析工具吗? Gunicorn有哪些工具和步骤可以用来确定在堆栈的哪一层出现瓶颈呢? occurring?
- What是确定是你的Gunicorn进程被交换了，还是其他进程在获取我托管的站点的swapped?
- Most时没有获得大量的流量，所以我只使用了一个
- 。有没有更科学的方法来确定和调整一个站点上有多少个Gunicorn工作进程？
- 在同一台服务器上托管多个站点时，有没有办法将其配置为使用更少的内存？
回答 3
Stack Overflow用户
发布于 2012-05-02 03:46:22
在一台只有1 1GB的服务器上托管的站点太多了。您的内存利用率接近100%，并且您拥有的数字可能是“备用”数字。在为请求提供服务的过程中，每个进程的RAM使用率都会激增。马上，您需要向该实例添加更多RAM，最好是将一些站点移到另一台服务器上。
有关你的问题：
- 你是从哪里得到这样的想法的:网站变得“不活跃”，Gunicorn必须重新加载网站？那都是废话。只要Gunicorn进程正在运行(即不是手动终止或站点上的错误)，它就会保持完全初始化并准备就绪，无论是一个小时还是一个月。
- 你在这里修改树叶，保持根不变。每个Gunicorn进程的内存使用都没有异常。它需要RAM来运行。您的问题是试图在一台性能严重不足的服务器上运行太多。在这里，任何优化都不会拯救你。您需要更多的RAM或更多的服务器。可能两者都有。
- 不需要。同样，问题已经被识别出来了。很明显，实际上，通过posted.
- There's的数字，无法可靠地知道哪些进程正在被交换。它每秒都在变化，并取决于哪些正在运行且需要更多RAM，哪些处于非活动状态或根本不活动。当您的服务器资源如此紧张时，它会花费一半的时间来弄清楚下一步该处理哪个进程，特别是当它们都处于活动状态并争用resources.
- Yes.时Gunicorn推荐2*cores+1，所以在双核系统上是5；在四核系统上是9。然而，你不可能在这一个系统上为每个站点运行5个工作进程。你甚至不能为每个人可靠地运行一个worker。
- 这取决于“事情”。但是，当多个站点托管在同一台服务器上时，这些服务器就是特定的野兽。在像您这样的小型VPS实例上，特别是在只有1 1GB的情况下，一个站点几乎是您的极限。也许是两个，
Stack Overflow用户
发布于 2012-05-08 14:42:18
1)不确定不活动是什么意思？例如，被nginx禁用？或者只是太慢而不能工作？
2和3) django-debug-toolbar django-debug-logging将是一个很好的起点。如果这还不能解决问题，那么是时候转向服务器级别的分析了，看看是哪些进程导致了问题。
4)使用top：How to find out which processes are swapping in linux?
5)是-基准测试。选择一个基准测试工具(例如apachebench)，并针对当前配置运行测试。调整一些东西。再次运行测试。重复以上操作，直到您的性能问题消失！为了获得最佳效果，请使用与实时流量相似的流量(在URL分布、GET/POST等方面)。
6)可以，在nginx和app两个级别。通过分析每个站点并改善其内存使用情况，您可能会获得最大的好处(请参见2)。
Stack Overflow用户
发布于 2012-05-09 18:48:31
关于：
关于你对5的回答，我认为Gunicorn推荐的是夸大其词。
我最近对工作进程的数量进行了一些特别测试，发现假设您有足够的内存，2*cores+1的经验法则是非常准确的。我发现请求/秒几乎是线性增长的，直到我接近这个数字，然后随着操作系统的崩溃而下降。
由于结果在很大程度上取决于工作负载，因此请尝试不同的值，并查看您的性能峰值。
https://stackoverflow.com/questions/10401513
复制相似问题
腾讯云开发者
