贵阳煤矿摆摊视频曝光群
[[437200]]
本文转载自微信公众号「极客新生」，作家极客新生。转载本文请臆测极客新生公众号。
hi ，公共好，今天分享一篇后台功绩器性能优化之齐集性能优化，但愿公共对Linux齐集有更深的交融。
曾几何时，一切齐是那么浅陋。网卡很慢，只消一个部队。当数据包到达时，网卡通过DMA复制数据包并发送中断，Linux内核收罗这些数据包并完成中断处理。跟着网卡越来越快，基于中断的模子可能会因多数传入数据包而导致 IRQ 风暴。这将破费大部分 CPU 功率并冻结系统。
为了惩处这个问题，NAPI(中断+轮询)被忽视。当内核收到来自网卡的中断时，它开动轮询开导并尽快收罗部队中的数据包。NAPI 不错很好地与当今常见的 1 Gbps 网卡配合使用。然而，关于10Gbps、20Gbps甚而40Gbps的网卡，NAPI可能还不够。如果咱们仍然使用一个 CPU 和一个部队来袭取数据包，这些卡将需要更快的 CPU。
交运的是，当今多核 CPU 很流行，那么为什么不并行处理数据包呢?
Receive Side Scaling(RSS)是所述机构具有多个RX / TX部队进程的数据包。当带有RSS 的网卡袭取到数据包时，它会对数据包应用过滤器并将数据包分发到RX 部队。过滤器平方是一个哈希函数，不错通过“ethtool -X”进行确立。如果你想在前 3 个部队中均匀分散流量：
# 贵阳煤矿摆摊视频曝光群ethtool -X eth0 equal 3
或者，如果你发现一个极端有用的魔法哈希键：
# ethtool -X eth0 hkey <magic hash key>
关于低延迟齐集，除了过滤器除外，CPU 亲和性也很关键。最好竖立是分派一个 CPU 专用于一个部队。早先通过查验/proc/interrupt找出IRQ号，然后将CPU位掩码竖立为/proc/irq//smp_affinity来分派专用CPU。为幸免竖立被粉饰，必须禁用看管程度irqbalance。请预防，字据内核文档，超线程对中断处理莫得任何平正，因此最好将部队数与物理 CPU 内核数相匹配。
RPS：袭取数据包适度
RSS提供硬件部队，一个称为软件部队机制Receive Packet Steering (RPS)在Linux内核已毕。
当驱动措施袭取到数据包时，它会将数据包包装在套接字缓冲区 ( sk_buff ) 中，其中包含数据包的u32哈希值。散列是所谓的第 4 层散列(l4 散列)，它基于源 IP、源端口、场所 IP 和场所端口，由网卡或__skb_set_sw_hash() 盘算。由于换取 TCP/UDP 斡旋(流)的每个数据包分享换取的哈希值，因此使用换取的 CPU 处理它们是合理的。
RPS 的基本念念想是字据每个部队的 rps_map 将归并流的数据包发送到特定的 CPU。这是 rps_map 的结构：映射字据 CPU 位掩码动态改造为/sys/class/net//queues/rx-/rps_cpus。比如咱们要让部队使用前3个CPU，在8个CPU的系统中，咱们先构造位掩码，0 0 0 0 0 1 1 1，到0x7，然后
#echo 7 > /sys/class/net /eth0/queues/rx-0/rps_cpus
这将保证从 eth0 中部队 0 袭取的数据包参加 CPU 1~3。驱动措施在 sk_buff 中包装一个数据包后，它将到达netif_rx_internal()或netif_receive_skb_internal()，然后到达 get_rps_cpu()
struct rps_map { unsigned int len; struct rcu_head rcu; u16 cpus[0]; };
将被调用以将哈希映射到 rps_map 中的要求，即 CPU id。得到CPU id后，enqueue_to_backlog()将sk_buff放到特定的CPU部队中进行进一步处理。每个 CPU 的部队在 per-cpu 变量softnet_data 平分派。
使用RPS的平正是不错在 CPU 之间摊派数据包处理的负载。然而，如果RSS 可用，则可能莫得必要，因为网卡照旧对每个部队/CPU 的数据包进行了排序。然而，如果部队中的CPU数更多，RPS 仍然不错弘扬作用。在这种情况下，每个部队不错与多个 CPU臆测联并在它们之间分发数据包。
RFS: Receive Flow Steering
尽管 RPS 基于流分发数据包，但它莫得计划用户空间应用措施。应用措施可能在 CPU A 上运行，而内核将数据包放入 CPU B 的部队中。由于 CPU A 只可使用我方的缓存，因此 CPU B 中缓存的数据包变得无须。Receive Flow Steering(RFS)进一步蔓延为RPS的应用措施。
代替每个部队的哈希至CPU舆图，RFS爱戴全局flow-to-CPU的表，rps_sock_flow_table：该掩模用于将散列值映射成所述表的索引。由于表大小将四舍五入到 2 的幂，因此掩码竖立为table_size - 1。
struct rps_sock_flow_table { u32 mask; u32 ents[0]; };
何况很容易找到索引：a sk_buff与hash & scok_table->mask。
该要求由 rps_cpu_mask别离为流 id 和 CPU id。低位用于CPU id，而高位用于流id。当应用措施对套接字进行操作时(inet_recvmsg()、inet_sendmsg()、inet_sendpage()、tcp_splice_read())，将调用sock_rps_record_flow()来更新sock 流表。
当数据包到来时，将调用get_rps_cpu()来决定使用哪个 CPU 部队。底下是get_rps_cpu()如何决定数据包的 CPU
ident = sock_flow_table->ents[hash & sock_flow_table->mask]; if ((ident ^ hash) & ~rps_cpu_mask) goto try_rps; next_cpu = ident & rps_cpu_mask;
使用流表掩码找到条场所索引，并查验散列的高位是否与要求匹配。如果是，它会从要求中检索 CPU id 并为数据包分派该 CPU。如果散列不匹配任何要求，它会回退到使用 RPS 映射。
不错通过rps_sock_flow_entries颐养 sock 流表的大小。举例，如果咱们要将表大小竖立为 32768：
#echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
sock流表天然提高了应用的局部性，但也带来了一个问题。当革新器将应用措施移动到新 CPU 时，旧 CPU 部队中剩余的数据包变得未完成，应用措施可能会得到乱序的数据包。为了惩处这个问题，RFS 使用每个部队的rps_dev_flow_table来追踪未完成的数据包。
底下是该结构rps_dev_flow_table：到袜子流表中，访佛的rps_dev_flow_table也使用table_size - 1动作掩模而表的大小也必须被进采选入到2的幂当流量分组被入队，last_qtail被更新
struct rps_dev_flow { u16 cpu; u16 filter; /* For aRFS */ unsigned int last_qtail; }; struct rps_dev_flow_table { unsigned int mask; struct rcu_head rcu; struct rps_dev_flow flows[0]; };
到 CPU 部队的尾部。如果应用措施移动到新 CPU，则 sock 流表将响应改造，何况get_rps_cpu()将为流竖立新 CPU。在竖立新 CPU 之前，get_rps_cpu() 会查验现时部队的头部是否照旧通过 last_qtail。如果是这样，这意味着部队中莫得更多未完成的数据包，何况不错安全地改造 CPU。不然，get_rps_cpu()仍将使用rps_dev_flow->cpu 中记载的旧 CPU 。
每个部队的流表(rps_dev_flow_table)的大小不错通过 sysfs 接口进行确立：
/sys/class/net/<dev>/queues/rx-<n>/rps_flow_cnt
建议将rps_flow_cnt竖立为 ( rps_sock_flow_entries / N) 而 N 是 RX 部队的数目(假定流在部队中均匀分散)。
ARFS：加速袭取流量转向
Accelerated Receive Flow Steering(aRFS)进一步蔓延RFS为RX部队硬件过滤。要启用 aRFS，它需要具有可编程元组过滤器和驱动措施搭救的网卡。要启用ntuple 过滤器。
# ethtool -K eth0 ntuple on
要使驱动措施搭救aRFS，它必须已毕ndo_rx_flow_steer以匡助set_rps_cpu()确立硬件过滤器。当get_rps_cpu()决定为流分派一个新 CPU 时，它会调用set_rps_cpu()。set_rps_cpu()早先查验网卡是否搭救 ntuple 过滤器。如果是，它将查询rx_cpu_rmap为流找到合适的 RX 部队。
rx_cpu_rmap是驱动爱戴的罕见映射。该映射用于查找哪个 RX 部队适当 CPU。它不错是与给定 CPU 平直关联的部队，也不错是处理 CPU 在缓存位置最接近的部队。获取 RX 部队索引后，set_rps_cpu()调用ndo_rx_flow_steer()以见告驱动措施为给定的流创建新过滤器。ndo_rx_flow_steer()将复返过滤器 id，过滤器 id 将存储在每个部队的流表中。
除了已毕ndo_rx_flow_steer() 外，驱动措施还必须调用rps_may_expire_flow() 如期查验过滤器是否仍然灵验并删除落后的过滤器。
SO_REUSEPORTlinux man文档中一段笔墨刻画其作用：
The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems.
浅陋说，SO_REUSEPORT搭救多个程度或者线程绑定到归并端口，用以提高功绩器措施的性能。咱们想了解为什么这个特质这样火(通常被大厂口试官问到)，到底是惩处什么问题。
Linux系统上后台应用措施，为了垄断多核的上风，柬埔寨修车群一般使用以下相比典型的多程度/多线程功绩器模子：
1. 单线程listener，在处理高速度海量斡旋时，相通会成为瓶颈;
2. CPU缓存行失效(丢失套接字结构socket structure)气候严重;
扫数责任线程齐accept()在归并个功绩器套接字上呢，相通存在问题：1. 多线程探询server socket锁竞争严重;
2. 高负载下，线程之间处理不平衡，随机高达3:1不平衡比例;
3. 导致CPU缓存行当先(cache line bouncing);
4. 在忙绿CPU上存在较大延迟;
上头模子天然不错作念到线程和CPU核绑定，但齐会存在以下问题：
单一listener责任线程在高速的斡旋接入处理时会成为瓶颈 缓存行当先 很难作念到CPU之间的负载平衡 跟着核数的膨大，性能并莫得跟着培植SO_REUSEPORT搭救多个程度或者线程绑定到归并端口：
允很多个套接字 bind()/listen() 归并个TCP/UDP端口1.每一个线程领有我方的功绩器套接字。
2.在功绩器套接字上莫得了锁的竞争。
内核层面已毕负载平衡。 安全层面，监听归并个端口的套接字只可位于归并个用户底下。其中枢的已毕主要有三点：
膨大socket option，增多SO_REUSEPORT选项，用来竖立 reuseport。
修改 bind 系统调用已毕，以便搭救不错绑定到换取的 IP 和端口。 修改处理新建斡旋的已毕，查找 listener 的时期，好像搭救在监听换取 IP 和端口的多个 sock 之间平衡采用 带来意念念 CPU之间平衡处理，水平膨大，模子浅陋，爱戴便捷了，程度的管束和应用逻辑解耦，程度的管束水平膨大权限下放给措施员/管束员，不错字据本体进行适度程度启动/关闭，增多了纯真性。这带来了一个较为微不雅的水平膨大念念路，线程若干是否合适，景况是否存在分享，裁减单个程度的资源依赖，针对无景况的功绩器架构最为适当。 针对对客户端而言，名义上感受不到其变动，因为这些责任统统在功绩器端进行。 功绩器无缝重启/切换，热更新，提供新的可能性。咱们迭代了一版块，需要部署到线上，为之启动一个新的程度后，稍后关闭旧版块程度措施，功绩一直在运行中不终止，需要平衡过度。这就像Erlang话语层面所提供的热更新相通。 SO_REUSEPORT已知问题 SO_REUSEPORT分为两种步地，即热备份步地和负载平衡步地，在早期的内核版块中，即即是加入对reuseport选项的搭救，也只是为热备份步地，而在3.9内核之后，则统统改为了负载平衡步地，两种步地莫得共存，天然我一直齐但愿它们不错共存。 SO_REUSEPORT字据数据包的四元组{src ip, src port, dst ip, dst port}和现时绑定归并个端口的功绩器套接字数目进行数据包分发。若功绩器套接字数目产生变化，内核会把本该上一个功绩器套接字所处理的客户端斡旋所发送的数据包(比如三次抓手期间的半斡旋，以及照旧完成抓手但在部队中列队的斡旋)分发到其它的功绩器套接字上头，可能会导致客户端恳求失败。如何珍摄以上已知问题，一般惩处念念路：
1.使用固定的功绩器套接字数目，不要在负载忙绿期间平静变化。
2.允很多个功绩器套接字分享TCP恳求表(Tcp request table)。
3.不使用四元组动作Hash值进行采用腹地套接字处理，比如采用 会话ID或者程度ID，挑选附庸于归并个CPU的套接字。
4. 使用一致性hash算法。
与其他特质联系 1. SO_REUSEADDR：主如若地址复用1.1 让处于time_wait景况的socket不错快速复用原ip+port
1.2 使得0.0.0.0(ipv4通配符地址)与其他地址(127.0.0.1和10.0.0.x)不突破
1.3 SO_REUSEADDR 的污点在于，莫得安全适度，而且无法保证扫数斡旋均匀分派。
2.与RFS/RPS/XPS-mq合营，不错得到进一步的性能2.1.功绩器线程绑定到CPUs
2.2.RPS分发TCP SYN包到对应CPU核上
2.3.TCP斡旋被已绑定到CPU上的线程accept()
2.4. XPS-mq(Transmit Packet Steering for multiqueue)，传输部队和CPU绑定，发送 数据
2.5. RFS/RPS保证归并个斡旋后续数据包齐会被分发到归并个CPU上，网卡袭取部队 照旧绑定到CPU，则RFS/RPS则无须竖立，需要预防硬件搭救与否，场所是数据包的软硬中断、袭取、处理等在一个CPU核上，并行化处理，尽可能作念到资源垄断最大化。
SO_REUSEPORT的演进 3.9之前内核，好像让多个socket同期绑定统统换取的ip+port，但不可已毕负载平衡，已毕是热备。 Linux 3.9之后，好像让多个socket同期绑定统统换取的ip+port，不错已毕负载平衡。 Linux4.5版块后，内核引入了reuseport groups，它将绑定到归并个IP和Port，何况竖立了SO_REUSEPORT选项的socket组织到一个group里面。场所是加速socket查询。 追念Linux齐集堆栈所存在问题
TCP处理&多核 一个齐全的TCP斡旋，中断发生在一个CPU核上，但应用数据处理可能会在另外一个核上 不同CPU中枢处理，带来了锁竞争和CPU Cache Miss(波动抵御衡) 多个程度监听一个TCP套接字，分享一个listen queue部队 用于斡旋管束全局哈希表格，存在资源竞争 epoll IO模子多程度的惊群气候 Linux VFS的同步损耗严重 Socket被VFS管束 VFS对文献节点Inode和目次Dentry有同步需求 SOCKET只需要在内存中存在即可，非严格意念念上文献系统，不需要Inode和Dentry 代码层面略过不必须的成例锁，但又保持了宽裕的兼容性RSS、RPS、RFS 和 aRFS，这些机制是在 Linux 3.0 之前引入的，SO_REUSEPORT选项在Linux 3.9被引入内核，因此大多数刊行版照旧包含并启用了它们。深远了解它们，以便为咱们的功绩器系统找到最好性能确立。
性能优化混沌限，咱们下期再接续分享!
膨大与参考https://garycplin.blogspot.com/2017/06/linux-network-scaling-receives-packets.html?m=1
https://jamal-jiang.github.io/2017/02/03/TCP-SO-REUSEPORT/
http://www.blogjava.net/yongboy/archive/2015/02/05/422760.html