慢速 Memcached：平均 10 毫秒 memcached `get`

Question

我们正在使用 Newrelic 来衡量我们的 Python/Django 应用程序性能。Newrelic 报告说，在我们的系统中，“Memcached”正在平均12ms响应命令。

深入到前十个左右的 Web 视图（按请求数），我可以看到有些Memcache get占30ms; 我无法Memcache get在小于10ms.

有关系统架构的更多详细信息：

• 目前我们有四台应用服务器，每台服务器都有一个 memcached 成员。所有四个 memcached 成员都参与了一个 memcache 集群。
• 我们在云托管提供商上运行，所有流量都在“内部”网络上运行（通过“内部”IP）
• 当我从一个应用程序服务器 ping 到另一个应用程序服务器时，响应在 ~0.5ms

Memcached 的响应时间不是10ms很慢吗？

据我了解，如果您认为“Memcache 太慢”那么“您做错了”。那我做错了吗？

这是memcache-top命令的输出：

memcache-top v0.7   (default port: 11211, color: on, refresh: 3 seconds)

INSTANCE        USAGE   HIT %   CONN    TIME    EVICT/s GETS/s  SETS/s  READ/s  WRITE/s 
cache1:11211    37.1%   62.7%   10      5.3ms   0.0     73      9       3958    84.6K   
cache2:11211    42.4%   60.8%   11      4.4ms   0.0     46      12      3848    62.2K   
cache3:11211    37.5%   66.5%   12      4.2ms   0.0     75      17      6056    170.4K  

AVERAGE:        39.0%   63.3%   11      4.6ms   0.0     64      13      4620    105.7K  

TOTAL:      0.1GB/  0.4GB       33      13.9ms  0.0     193     38      13.5K   317.2K  
(ctrl-c to quit.)

** 这是top在一台机器上的命令输出： ** （在所有集群机器上大致相同。如您所见，CPU 利用率非常低，因为这些机器只运行内存缓存。）

top - 21:48:56 up 1 day,  4:56,  1 user,  load average: 0.01, 0.06, 0.05
Tasks:  70 total,   1 running,  69 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Mem:    501392k total,   424940k used,    76452k free,    66416k buffers
Swap:   499996k total,    13064k used,   486932k free,   181168k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                               
 6519 nobody    20   0  384m  74m  880 S  1.0 15.3  18:22.97 memcached                                                                                              
    3 root      20   0     0    0    0 S  0.3  0.0   0:38.03 ksoftirqd/0                                                                                            
    1 root      20   0 24332 1552  776 S  0.0  0.3   0:00.56 init                                                                                                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                                                               
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0                                                                                            
    5 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kworker/u:0                                                                                            
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0                                                                                            
    7 root      RT   0     0    0    0 S  0.0  0.0   0:00.62 watchdog/0                                                                                             
    8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                                                                                                 
    9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper                                                                                                
...output truncated...

Answer 1

到目前为止，我的研究表明这10ms是“慢”的。我的意思是 memcache 文档本身将子1ms时间称为“预期”。因此我们看到的响应时间慢了一个数量级。

对性能的期望： https: //code.google.com/p/memcached/wiki/NewPerformance

memcached 响应缓慢的“可能的罪魁祸首”似乎是（按可能性的粗略顺序）：

1. 糟糕的应用程序设计（或错误）
2. 网络拥塞
3. 交换
4. 共同租户应用程序的高 CPU 负载
5. 达到某种连接最大值
6. 状态防火墙
7. TCP 配置错误

我已经解决了几乎所有这些问题，如下所示：

1. 根据memcached-top（https://code.google.com/p/memcache-top/brutis ），我们从应用程序中获得的连接时间与运行时（https://code.google.com/p/brutis/）大致相同）来自那些相同的应用程序服务器。
2. 尽管我们的系统有明确的峰值负载时间，但响应时间全天保持一致；如果这是一个拥塞问题，响应时间永远不会像人们预期的那样“尖峰”。（此外，我们的托管提供商声称为这些实例提供的 Mbps 远高于atop我们正在使用的报告）
3. 观察到系统上有足够的可用内存（并且没有 iowait）
4. 整个缓存的 CPU 使用率较低
5. 每台服务器仅服务 10-20 个并发连接
6. 我们使用有状态防火墙（通过 iptables），但是当我们删除所有有状态条目时，性能没有变化。

7. 盲目地设置这些配置选项并希望它们能够改进：

   /sbin/sysctl -w net.ipv4.tcp_tw_recycle=1
   /sbin/sysctl -w net.ipv4.tcp_tw_reuse=1 
   /sbin/sysctl -w net.ipv4.tcp_fin_timeout=10 
   

结果没有变化。

我们基本上无法诊断这个问题。我们即将“安装 Redis”并希望它能更好地工作。