Memcached滞后
让我先说这是这个话题的后续问题。
这是通过从Solaris（SmartOS）切换到Ubuntu的memcached服务器“解决”。 现在我们已经把负载乘以大约5倍，并且再次遇到问题。
我们正在运行一个站点，每分钟处理约1000个请求，每个请求大约有3个读取和1个写入访问Memcached。 所以加载大约是每秒65个请求。 caching中的总数据大约是37M，每个键包含非常less量的数据（一个JSON编码的小于1K的整数数组）。
我们在这些页面上build立了一个基准testing脚本，并将这些数据提供给StatsD进行logging。 问题是Memcached需要很长时间才能响应。 这些似乎与交通高峰相关。
什么可能导致这些尖峰？ 为什么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
当Spiking：
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
networking堆栈可能有问题。 我有类似memcached的问题，原因是用尽了Linux conntrack处理程序。 你能检查峰值之前和之后的netstat -s -t输出来检查TCP错误和重传。 您也可以尝试使用wireshark查看stream量转储以获取有关该问题的更多信息。
除了检查您的networking统计信息之外，是否可以升级到版本为1.4.10（或更高）的版本？ 从1.4.10发行说明 ：
此版本专注于线程可伸缩性和性能改进。 这个版本应该能够比任何网卡在撰写本文时能够支持的速度快。
虽然我们的服务器没有获得stream量，但在我们的情况下，升级到1.4.10有助于压缩（我们的值大于1MB）和二进制协议。 有关详细信息，请参阅Drupal SE上的答案。
问题变成了，呼叫机器吃掉了所有可用的CPU。 这导致了奇怪的问题发生，而且看起来memcached是事实，事实上并非如此。 这只是一个更大问题的症状。
水平缩放Web层解决了这个问题。
如果你使用的是Joyent，那么查看你使用的CPU有多大的命令是jinf -c