☰

Memcached 滞后

tag-icon • tag-icon ubuntu php memcached scalability memcache
Memcached 滞后

首先我想说的是，这是一个后续问题这个话题。

通过将 memcached 服务器从 Solaris (SmartOS) 切换到 Ubuntu，这个问题得到了“解决”。现在我们的负载增加了约 5 倍，并且再次遇到问题。

我们正在运行一个网站，该网站每分钟大约处理 1000 个请求，每个请求大约对 Memcached 进行 3 次读取和 1 次写入。因此，每秒的负载大约为 65 个请求。缓存中的总数据量约为 37M，每个键包含的数据量非常小（JSON 编码的整数数组，总计不到 1K）。

我们在这些页面上设置了一个基准测试脚本，并将数据输入到 StatsD 进行记录。问题是 Memcached 需要很长时间才能响应，而这些似乎与流量高峰无关。

来自 StatsD 的执行时间

是什么导致了这些峰值？为什么 memcached 需要一秒钟以上的时间来回复？我们刚刚启动了第二台服务器并将其放入池中，峰值的频率或严重程度并没有明显变化。

这是服务器上 getStats() 的输出：

Array
(
    [-----------] => Array
        (
            [pid] => 1364
            [uptime] => 3715684
            [threads] => 4
            [time] => 1336596719
            [pointer_size] => 64
            [rusage_user_seconds] => 7924
            [rusage_user_microseconds] => 170000
            [rusage_system_seconds] => 187214
            [rusage_system_microseconds] => 190000
            [curr_items] => 12578
            [total_items] => 53516300
            [limit_maxbytes] => 943718400
            [curr_connections] => 14
            [total_connections] => 72550117
            [connection_structures] => 165
            [bytes] => 2616068
            [cmd_get] => 450388258
            [cmd_set] => 53493365
            [get_hits] => 450388258
            [get_misses] => 2244297
            [evictions] => 0
            [bytes_read] => 2138744916
            [bytes_written] => 745275216
            [version] => 1.4.2
        )

    [-----------:11211] => Array
        (
            [pid] => 8099
            [uptime] => 4687
            [threads] => 4
            [time] => 1336596719
            [pointer_size] => 64
            [rusage_user_seconds] => 7
            [rusage_user_microseconds] => 170000
            [rusage_system_seconds] => 290
            [rusage_system_microseconds] => 990000
            [curr_items] => 2384
            [total_items] => 225964
            [limit_maxbytes] => 943718400
            [curr_connections] => 7
            [total_connections] => 588097
            [connection_structures] => 91
            [bytes] => 562641
            [cmd_get] => 1012562
            [cmd_set] => 225778
            [get_hits] => 1012562
            [get_misses] => 125161
            [evictions] => 0
            [bytes_read] => 91270698
            [bytes_written] => 350071516
            [version] => 1.4.2
        )

)

编辑：这是设置和检索 10,000 个值的结果。

普通的：

Stored 10000 values in 5.6118 seconds.
Average: 0.0006
High: 0.1958
Low: 0.0003

Fetched 10000 values in 5.1215 seconds.
Average: 0.0005
High: 0.0141
Low: 0.0003

扣球时：

Stored 10000 values in 16.5074 seconds.
Average: 0.0017
High: 0.9288
Low: 0.0003

Fetched 10000 values in 19.8771 seconds.
Average: 0.0020
High: 0.9478
Low: 0.0003

答案1

网络堆栈可能存在问题。我遇到了与 memcached 类似的问题，原因是 Linux 连接跟踪处理程序用完了。您可以检查峰值前后的 netstat -s -t 输出以检查 tcp 错误和重传。您还可以尝试使用 wireshark 查看流量转储以获取有关该问题的更多信息。

答案2

除了检查网络统计数据外，是否可以升级到版本 1.4.10（或更高版本）以提高性能？来自1.4.10 发行说明：

此版本专注于线程可扩展性和性能改进。截至撰写本文时，此版本应该能够以比任何网卡所能支持的速度更快地反馈数据。

虽然我们的服务器没有你们的服务器那样的流量，但在我们的案例中，升级到 1.4.10 有所帮助，启用压缩（我们的值大于 1MB）和二进制协议也有帮助。请参阅我的回答Drupal SE了解详情。

答案3

问题原来是调用机器耗尽了所有可用 CPU。这导致奇怪的问题发生，看起来问题出在 memcached 上，但实际上并非如此。这只是更大问题的一个症状。

水平扩展 Web 层解决了该问题。

如果你使用 Joyent，查看你使用的 CPU 上限的有用命令是jinf -c

相关内容