![Memcached 速度慢:memcached `get` 平均需要 10ms](https://linux22.com/image/800452/Memcached%20%E9%80%9F%E5%BA%A6%E6%85%A2%EF%BC%9Amemcached%20%60get%60%20%E5%B9%B3%E5%9D%87%E9%9C%80%E8%A6%81%2010ms.png)
我们正在使用 Newrelic 来衡量我们的 Python/Django 应用程序性能。Newrelic 报告称,在我们的系统中,“Memcached”平均需要 来12ms
响应命令。
深入研究排名前十的网页浏览量(按请求数计算),我发现有些网页浏览量Memcache get
最多需要30ms
;我找不到一个使用时间Memcache get
少于的网页返回结果10ms
。
有关系统架构的更多详细信息:
- 目前我们有四台应用服务器,每台都有一个 memcached 成员。所有四个 memcached 成员都参与 memcache 集群。
- 我们在云托管提供商上运行,所有流量都在“内部”网络上运行(通过“内部”IP)
- 当我从一个应用程序服务器 ping 另一个应用程序服务器时,响应如下
~0.5ms
不是10ms
一个慢的Memcached 的响应时间?
据我了解如果你认为“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 利用率非常低,因为这些机器只运行 memcache。)
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...
答案1
我发现写入速度非常快,单次读取非常慢,但缓冲读取非常快。您需要使用 get_many 进行缓冲读取,并传入要检索的键的数组。这是我的测试:
WRITE 写入 100000 次(一次写入,但可能在后台缓冲)耗时 0.42605304718 秒,每秒 234712 次
读取 100000 次,存储桶大小为 10000 次,读取(多次)耗时 0.651949167252 秒,每秒 153386 次
每次读取 100000 个,耗时 86.2907109261 秒,每秒 1158 个
就我而言,我使用带有 pymemcache 的 python。
答案2
到目前为止,我的研究表明这10ms
很“慢”。我的意思是,memcache 文档本身将子1ms
时间称为“预期时间”。所以我们看到的响应时间要慢一个数量级。
对性能的期望:https://code.google.com/p/memcached/wiki/NewPerformance
导致 memcached 响应缓慢的“可能原因”似乎是(按可能性大致排序):
- 应用程序设计不佳(或有错误)
- 网络拥塞
- 交换
- 共同租户应用程序导致 CPU 负载过高
- 达到某种连接最大值
- 状态防火墙
- 错误的 TCP 配置
我几乎已经解决了所有这些问题,如下所示:
- 根据
memcached-top
(https://code.google.com/p/memcache-top/)我们从应用程序获得的连接时间与运行时大致相同brutis
(https://code.google.com/p/brutis/) 来自相同的应用服务器。 - 尽管我们的系统有明显的峰值负载时间,但响应时间全天保持一致;如果这是拥塞问题,响应时间永远不会像人们所期望的那样“突然增加”。(此外,我们的托管服务提供商声称为这些实例提供的 Mbps 远远高于
atop
我们使用的报告) - 观察到系统上有足够的可用内存(并且没有 iowait)
- 整个缓存的 CPU 使用率低
- 每台服务器仅支持 10-20 个同时连接
- 我们正在使用状态防火墙(通过 iptables),但是当我们删除所有状态条目时,性能并没有变化。
盲目地设置这些配置选项并希望它们能够改善情况:
/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”的阶段,希望它能更好地工作。
答案3
首先想到的是:您是否使用 FQDN/DNS 启动与 memcache 服务器的连接,还是使用 IP 地址或本地套接字?
如果您使用主机名,则可能会在名称解析中浪费一些时间。
尝试将 FQDN 放入客户端和服务器的 /etc/hosts 中并重新启动,以便不缓存任何内容,或者将引用更改为基于 IP 地址,看看是否没有看到改进。
答案4
我刚刚完成了 memcached 刷新,所以我想发布一个我认为有效的示例输出。New Relic 报告在 memcached 上花费了 10.4 毫秒,所以我认为它计算了多个调用。您是在裸机上运行还是在虚拟机上运行,如果您关心速度,那么虚拟机不是最佳选择(http://redis.io/topics/benchmarks)
memcache-top v0.6 (default port: 11211, color: on, refresh: 3 seconds)
INSTANCE USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s
app01:11211 0.5% 49.8% 2994 0.7ms 0.0 75.2K 378.5K
app02:11211 0.5% 51.7% 2992 0.7ms 0.0 76.5K 143.9K
app03:11211 1.0% 69.6% 1469 0.7ms 0.0 42.0K 161.3K
app04:11211 2.0% 52.6% 801 0.5ms 0.0 66.0K 415.9K
app05:11211 2.2% 52.5% 801 0.4ms 0.0 71.9K 171.2K
app06:11211 2.0% 66.4% 800 0.5ms 0.0 135.9K 180.4K
app07:11211 1.9% 52.0% 800 0.6ms 0.0 65.5K 482.4K
app08:11211 1.1% 87.1% 1469 0.7ms 0.0 59.3K 365.3K
db01:11211 1.0% 82.4% 1469 0.5ms 0.0 64.6K 155.4K
elastic01:11211 1.7% 69.9% 737 0.5ms 0.0 44.2K 128.8K
elastic02:11211 1.7% 65.0% 737 0.5ms 0.0 48.2K 155.8K
elastic03:11211 1.8% 68.3% 737 0.6ms 0.0 24.5K 115.7K
elastic04:11211 1.8% 69.5% 737 0.7ms 0.0 95.3K 158.0K
AVERAGE: 1.5% 64.4% 1272 0.6ms 0.0 66.9K 231.7K
TOTAL: 12.1GB/ 1.0TB 16.2K 7.6ms 0.0 869.1K 2.9M
(ctrl-c to quit.)