NGIX背后的AWS Redis + uWSGI - 高负载

时间:2016-11-27 17:10:43

标签: python amazon-web-services redis uwsgi redis-py

我正在使用uwsgi + nginx并使用aws elasticache(redis 2.8.24)运行python应用程序(flask + redis-py)。

在尝试改善我的应用程序响应时间时,我注意到在高负载下(使用loader.io每秒500请求/ 30秒)我正在丢失请求(对于此测试我只使用一个没有负载均衡器的服务器,1个uwsgi实例,4个进程,用于测试)。 stress test

我挖得更深一些,发现在这个负载下,对ElastiCache的一些请求很慢。 例如:

  • 正常加载:cache_set time 0.000654935836792
  • 重载:cache_set时间0.0122258663177 所有请求都不会发生这种情况,只是随机发生..

我的AWS ElastiCache基于cache.m4.xlarge上的2个节点(默认AWS配置设置)。 查看过去3小时内连接的当前客户端: aws elasticache clients

我认为这没有意义,因为目前有14台服务器(其中8台服务器具有XX RPS的高流量使用此群集),我希望看到更高的客户端速率。

uWSGI config(版本2.0.5.1)

processes = 4
enable-threads = true
threads = 20
vacuum = true
die-on-term = true
harakiri = 10
max-requests = 5000
thread-stacksize = 2048
thunder-lock = true
max-fd = 150000
# currently disabled for testing
#cheaper-algo = spare2
#cheaper = 2
#cheaper-initial = 2
#workers = 4
#cheaper-step = 1

Nginx只是使用unix socket的uWSGI的web代理。

这是我打开redis连接的方式:

rdb = [
    redis.StrictRedis(host='server-endpoint', port=6379, db=0),
    redis.StrictRedis(host='server-endpoint', port=6379, db=1)
]

这是我设置值的方法,例如:

def cache_set(key, subkey, val, db, cache_timeout=DEFAULT_TIMEOUT):
    t = time.time()
    merged_key = key + ':' + subkey
    res = rdb[db].set(merged_key, val, cache_timeout)
    print 'cache_set time ' + str(time.time() - t)
    return res

cache_set('prefix', 'key_name', 'my glorious value', 0, 20)

这就是我获得价值的方式:

def cache_get(key, subkey, db, _eval=False):
    t = time.time()
    merged_key = key + ':' + subkey
    val = rdb[db].get(merged_key)
    if _eval:
        if val:
            val = eval(val)
        else:  # None
            val = 0
    print 'cache_get time ' + str(time.time() - t)
    return val

cache_get('prefix', 'key_name', 0)

版本:

  • uWSGI:2.0.5.1
  • 烧瓶:0.11.1
  • redis-py:2.10.5
  • Redis:2.8.24

所以结论:

  1. 如果连接了14台服务器,每台有4个进程,并且每个服务器都在redis集群中打开与8个不同数据库的连接,为什么AWS客户端数量很少
  2. 是什么导致请求响应时间爬升?
  3. 非常感谢任何有关ElastiCache和/或uWSGI在重载下的表现的建议

1 个答案:

答案 0 :(得分:2)

简答

所以,如果我做对了,在我的情况下问题不是Elasticache请求而是uWSGI内存使用。

长答案

我已使用此设置安装了uwsgitop

### Stats
### ---
### disabled by default
### To see stats run: uwsgitop /tmp/uwsgi_stats.socket
### uwsgitop must be install (pip install uwsgitop)
stats = /tmp/uwsgi_stats.socket

这会将uwsgi统计信息暴露给uwsgitop。

然后我使用loader.io以350-500个请求/秒对应用程序进行压力测试。

我在之前的配置中发现,uWSGI工作程序在使用的内存大小中不断增长,直到内存堵塞,然后cpu加速。需要重新生成的新工作者也需要cpu,这会导致服务器出现某种过载 - 这会导致nginx超时并关闭这些连接。

所以我做了一些研究和配置修改,直到我设法得到下面的设置,目前在每个实例上管理~650rps,响应时间约为13ms,这对我来说非常好。

*我的应用程序使用(仍使用一些)磁盘pickle dat文件,其中一些负载很重 - 我已将磁盘依赖性降低到最小*

对于将来可能会看到它的人 - 如果您需要快速响应 - 可以将所有内容异步化。例如,如果可能,请使用celery + rabbitmq进行任何数据库请求

uWSGI配置:

listen = 128
processes = 8
threads = 2
max-requests = 10000
reload-on-as = 4095
reload-mercy = 5
#reload-on-rss = 1024
limit-as = 8192
cpu-affinity = 3
thread-stacksize = 1024
max-fd = 250000
buffer-size = 30000
thunder-lock = true
vacuum = true
enable-threads = true
no-orphans = true
die-on-term = true

NGINX相关部分:

user nginx;
worker_processes 4;
worker_rlimit_nofile 20000;
thread_pool my_threads threads=16;
pid /run/nginx.pid;

events {
    accept_mutex off;
    # determines how much clients will be served per worker
    # max clients = worker_connections * worker_processes
    # max clients is also limited by the number of socket connections available on the system (~64k)
    worker_connections 19000;

    # optmized to serve many clients with each thread, essential for linux -- for testing environment
    use epoll;

    # accept as many connections as possible, may flood worker connections if set too low -- for testing environment
    multi_accept on;
}

http {
    ...
    aio                     threads;
    sendfile                on;
    sendfile_max_chunk      512k;
    tcp_nopush              on;
    tcp_nodelay             on;
    keepalive_timeout       5 5;
    keepalive_requests      0;
    types_hash_max_size     2048;
    send_timeout            15;
    ...
}

希望它有所帮助!