- 原文:Linux上到了
定负载的后
UDP
性能下降地很厉害
这是由于当从多个线程通过单个套接字传递数据时在UDP套接字锁上产生大量锁竞争导致要通过分离锁来修复内核恐怕不太容易所以我们使用了分离UDP套接字来传递回复(每个线程用个答复套接字)这样改动的后我们就可以部署UDP同时后端性能不打折
另个Linux中问题是到了定负载后某个核心可能因进行网络软终端处理会饱和而限制了网络IO在Linux中网络中断只会总是传递给某个核心因此所有接受软终端网络处理都发生在该内核上另外我们还发现某些网卡有过高中断频率我们通过引入网络接口“投机”轮询解决了这两个问题在该模型中我们组合了中断驱动和轮询驱动网络IO旦进入网络驱动(通常是传输个数据包时)以及在进程调度器空闲循环时候对网络接口进行轮询另外我们也用到了中断(来控制延迟)不过网络中断用到数量大大减少(般通过大幅度提升中断联结阈值
errupt coalescing thresholds)由于我们在每个核心上进行网络传输同时由于在调度器空闲循环中对网络IO进行轮询我们将网络处理均匀地分散到每个核心上
最后当开始部署8核机器时候我们在测试中发现了新瓶颈首先memcachedstat工具集依赖于个全局锁这在4核上已经很令人讨厌了在8核上这个锁可以占用20-30%CPU使用率我们通过将stats工具集移入每个线程并且需要时候将结果聚合起来其次我们发现随着传递UDP数据包线程数量增加性能却在降低最后在保护每个网络设备传送队列锁上发现了严重争用数据包是由设备驱动进行入队传输和出队该队列由Linux“netdevice”层来管理它位于IP和设备驱动的间每次只能有个数据包加入或移出队列这造成了严重争用我们当中位工程师修改了出队算法实现了传输批量出队去掉了队列锁然后批量传送数据包这个更正将请求锁开销平摊到了多个数据包显著地减少了锁争用这样我们就能在8核系统上将memcached伸展至8线程
做了这些修改的后我们可以将memcached提升到每秒处理20万个UDP请求平均延迟降低为173微秒可以达到总吞吐量为30万UDP 请求/s不过在这个请求速度上延迟太高因此在我们系统中用处不大对于普通版本Linux和memcached上50,000 UDP请求/s而言这是个了不起提升
我们希望尽快将我们修改集成到官方memcached仓库中去我们决定在这的前先将我们对memcached修改发布到github上
TAG: Facebook Memcached
延伸阅读
 |
最新评论