• 我的首页
  • 星空画廊

My thought on web

Think what ? think

性能

网卡中断性能调优的一点记录

2016年7月31日 by caoli5288 Leave a Comment

中文网络里面对于linux的网络性能调优这个话题有用的资料真的很少,分散在各家博客里面,只言片语并且没什么实际用例。说实话linux的网络性能真的不尽如人意,作为一个被大面积应用于服务器的系统内核,在默认参数下根本没办法负载很大的网络流量,不得不说是一件很坑爹的事情。

其中尤其是中断性能非常之低下。先看结论,在不存在任何调优选项的情况下,200M以上的的负载就有机会使linux网络中断超载,表面现象就是开始网络开始丢包,top可见某cpu使用率%sys非常高,有时候能看到ksoftirqd这个内核进程占用接近100%的使用率。但是在很简单的优化过后,就可以负载大得多的流量。

这里使用有机会这个词是因为实际情况还要考虑数据帧大小,越小的数据帧对系统压力越大。为什么网络性能存在瓶颈这里就不详细说了,放上一篇参考文章。

Linux转发性能评估与优化 这篇文章从内核实现上把性能问题的存在讲得很清楚了。

这里只讨论在已有的技术下,优化中断性能的两个方案。第一个是RSS,俗称网卡多队列。

RSS需要网卡硬件支持,好在现在大部分服务器网卡都是支持RSS的。也有少部分例外,比如某些e1000e的板载千兆网卡就不支持。如果网卡支持RSS,那么驱动程序在默认情况下会开启这个特性。本来,如果多个队列绑定到多个CPU上自然就能减轻中断负载对单一核心的压力,可惜萌傻的linux核心默认把多队列全绑在cpu0上。

红帽系的发行版开启irqbalance这个服务就可以根据负载均衡队列了,建议开启简单方便。有些极端负载情况下需要自行指定,方法也很简单,检查/proc/interrupts文件可以得到网卡队列对应的中断号,假如是88,我需要将其绑定到cpu8上,执行如下命令echo 8 > /proc/irq/88/smp_affinity_list。

另一个可用的技术是RPS,强调一下某些博客所说的RPS是RSS的软实现是错误的。RPS的做法就是,哪个cpu上的中断,哪个cpu去处理,这是一种调度策略,与RSS是截然不同的。在极端情况下RPS可以获得非常好的性能,可惜实际情况下反而对整机整体负载有所妨害,主要是进程调度导致的cpu缓存丢失导致,所以在应用负载已经非常高的情况下开启RPS是没意义的做法(开启RFS会稍微好转但是作用也不大)。下图所示为开启RSS不开启RPS的情况。

1

可见左侧cpu存在较高的%sys负载,是因为网卡队列都绑定在左侧的几个cpu上。下图所示为同时开启RPS的情况。

2

可见%sys较为均衡,同时整机负载略有上升。顺便强调一点纯转发工作负载下RPS没有太大作用,想想RPS的原理就知道了。纯转发工作负载下linux的性能表现更为不堪,附上一张转发负载约为300M的top图压压惊。

3

开启了RSS,eth0的8个队列绑定在cpu0-7,eth1的8个队列绑定在cpu8-15,看起来已经半载有多了,也就是说性能瓶颈会出现在500M左右的时候,非常的吓人。

参考资料:Red Hat Performance Tuning Guide

Posted in: 笔记 Tagged: linux, 性能, 网卡, 网络, 调优

标签

c docker dynamic fedora ffmpeg hevc java libmfx linux mingw mount mp4 NAS parallel qsv rime x264 x265 ZFS 事件 互联网 交叉编译 优化 分布式 反射 性能 文件系统 杂谈 游戏 站点 网卡 网络 自由 调优 透明代理

近期文章

  • lxc安装openwrt
  • NAS 文件系统方案的选择
  • 透明代理踩坑指北
  • QSV编码HEVC视频参数测试
  • FFmpeg中的几个新视频降噪滤镜

友情链接

  • 梦之地
  • Vultr

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

文章归档

Copyright © 2021 My thought on web.

Omega WordPress Theme by ThemeHall