服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 缓慢的Memcached：平均10ms的memcached`get`
Intereting Posts
一个FreeBSD amazon ec2实例的附加卷不会显示出来 无法通过VPN连接到非域计算机的Windowsnetworking共享 如何保护Mac服务器（日志中的“可能的破解尝试”） Pentaho BI服务器：Saiku在Linux和Windows上的性能 resize的ubuntu分区在VMWare中不能正常显示 Hyper-V avhd文件压缩 设置一个电子邮件服务器 开始学习如何设置WebServer的最佳地点？ syslog-ng无法从ASA捕获系统日志 Add-AppxPackage：0x80073CF6，…无法注册。 合并失败：错误0x80070003： Mysql性能问题＆DIMM失败 启用消费者和提供者ldap中的同步 如何将SSD连接到Azure VM并检查其types？ CIFS错误-512在一个安装 如何完全拥有IP地址？

缓慢的Memcached：平均10ms的memcached`get`

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

深入到前十几个Web视图（按请求数），我可以看到一些Memcache get占用了30ms ; 我找不到一次使用Memcache get返回时间不到10ms 。

有关系统架构的更多细节：

  • 目前我们有四个应用服务器，每个应用服务器都有一个memcached成员。 所有四个memcached成员都参与一个memcache群集。
  • 我们正在云托pipe提供商上运行，所有stream量都在“内部”networking上运行（通过“内部”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利用率非常低，因为这些机器只运行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...

我发现写入是快速的，单个读取是疯狂的缓慢，但缓冲读取是非常非常快。 您需要使用get_many进行缓冲读取，并传入要检索的键的数组。 这是我的testing：

  1. WRITE 100000写入（一个接一个，但可能在后台缓冲）在0.42605304718秒，每秒234712

  2. 读取100000与桶大小= 10000读取（许多）在0.651949167252秒，153386每秒

  3. 一次读取100000个（86.2907109261秒），每秒1158个

在我的情况下，我正在使用python pymemcache。

到目前为止，我的研究表明10ms是“慢”。 我的意思是，memcache文件本身是指1ms “预期”。 所以我们看到的响应时间要慢一个数量级。

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

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

  1. 糟糕的应用程序devise（或一个错误）
  2. networking拥塞
  3. 交换
  4. 来自共同租户应用程序的高CPU负载
  5. 触及最大连接
  6. 有状态的防火墙
  7. 错误的TCPconfiguration

我已经解决了几乎所有这些如下：

  1. 根据memcached-top （ https://code.google.com/p/memcache-top/ ），我们的应用程序的连接时间与我们在运行brutis （ https://code.google.com/ p / brutis / ）从这些相同的应用程序服务器。
  2. 尽pipe我们的系统具有明确的高峰负载时间，但响应时间始终保持一致。 如果这是一个拥挤问题，那么响应时间永远不会像人们所期望的那样“尖峰”。 （我们的托pipe服务提供商也声称为这些实例提供比我们正在使用的报告更高的Mbps）
  3. 观察到在系统上有足够的空闲内存（并且没有iowait）
  4. 整个caching的CPU使用率较低
  5. 每个服务器只能服务10-20个同时连接
  6. 我们使用状态防火墙（通过iptables），但是当我们删除所有有状态的条目时，性能没有变化。

  7. 盲目设置这些configuration选项，并希望他们改进的东西： 

     /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”的地步，希望它能更好地工作。

我注意到了2件事。 命中率非常低，应尽可能接近100％。 你有超过200MB的空闲内存，你可以使用memcached。

首先想到的是：您是使用FQDN / DNS启动与您的Memcache服务器的连接，还是使用IP地址或本地套接字？

如果您使用的是主机名称，则可能会在名称parsing中失去一些时间。

尝试将FQDN放在客户端和服务器的/ etc / hosts中，然后重新启动，这样没有任何caching，或者将引用改为基于IP地址，看看是否没有改进。

我刚刚做了一个memcached刷新，所以我想我会发布一个我认为正在工作的示例输出。 新的遗迹报告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.)

Django和memcached的问题是，它会连接每个请求。 所以这部分时间是连接build立时间。

这取决于您正在使用哪个memcache绑定。 但是你可以在你的wsgi.py中join类似的东西 

 # Fix django closing connection to memcached after every request (#11331) from django.core.cache.backends.memcached import BaseMemcachedCache BaseMemcachedCache.close = lambda self, **kwargs: None

基本上猴子补贴closures处理程序不closures。

如果这不起作用，请更换您的memcached类。