通用企业网站织梦模板(红绿蓝三色),哪些平台属于c2c模式,北辰正方建设集团有限公司官方网站,镇江网站建设数据中心 incast#xff0c;广域网拥塞#xff0c;内存墙都是一类问题。
我接触 incast 很久了#xff0c;大多是帮忙查问题#xff0c;也解过几例。
我记得有一次在业务几乎总是(在统计学上#xff0c;几乎和总是属同义强调) tail latency 很大时#xff0c;我建议在 …数据中心 incast广域网拥塞内存墙都是一类问题。
我接触 incast 很久了大多是帮忙查问题也解过几例。
我记得有一次在业务几乎总是(在统计学上几乎和总是属同义强调) tail latency 很大时我建议在 sender 方加一个 0rtt/2 的随机 delay果然就缓解了。我尝试把这个方案 “永久” 化。
我觉得无论 clos 还是 leaf-spine 都太正则它们是问题的原因而不是解法特别在 mapreduce 场景正则拓扑往往引发全局同步所有服务器在 10ns 粒度同时发送数据经过几乎等长的光纤同时到达 tor剩下的交给 buffer 和时间这就是 incast。
也因此我建议插入随机时延。随机几乎是万金油当你没有办法时就想想随机。
但何必绕这么个圈子呢先同步再打乱谁说下面的拓扑不合适呢 我知道 mesh 不该那样我是故意的。光纤随机长度汇聚 sw 下直接挂服务器乱七八糟互联都是些不负责任的拓扑但都能缓解 incast核心在于都引入了随机至于它带来的混乱问题就看和 incast 相比孰轻孰重了。
简单计算信号 10ns 可传输 2m40Gbps 交换机为例报文间隔 200ns 即可避免拥塞服务器只要有 020m 随机长度差即可缓解大部分 incast这很容易。带宽越高要求随机长度差越小实施越容易。这只是开始。
站在这视角上升然后往下看就看到了 cpu 的内存墙。核越多内存显得越慢本质还是拥塞好像多条流穿越一个瓶颈受制于带宽。
只要涉及通信那么 rtt 的开销就必不可少而 rtt 处理时延 传播时延 排队时延。传播时延只能减少距离来降低cdn内存离核越来越近都在干这事。而处理时延受限于自身跟别人无关一会儿说排队时延比较有趣先说它。
信道容量有限需要通信方同步同步是对通信信道达成共识的过程因此排队时延是一种同步时延通信量随通信方指数增长而带宽却不能。cdn 卸载了骨干流量但回源流量还在前端总线越来越堵加带宽也没法弥补干脆处理核独享内存控制器但只要内存本身还共享问题就没解决。
回来说处理时延处理时延也是种同步时延即通信双方能力的同步最终对木桶达成共识效率取决于弱者。像 cpu 和内存本就是两类东西几乎可以肯定内存一定不比 cpu 快否则二者就会反转你快你算吧至少能加速存内计算的普及。
综上无论数据中心广域网还是 cpu 和内存问题都围绕三个 rtt 组分一方快另一方慢距离太远带宽太小而拥塞。解决这些问题的方法也一致拉近距离要么独享要么错开。 L1/L2 cache 和 cdn 一样但问题也和 cdn 一样只是被小时延放大了问题尺度。这些都是细枝末节。
周五早上问 chatgpt “能不能随机化服务器光纤长度来缓解 incast”chatgpt 说能但不好教我 “要用拥塞控制流控和 buffer 来解决问题“我一看这些就烦这不都是经理们天天瞎咧咧的吗瞎 JB 卷结果这些恰是问题的原因而不是方案我发了个朋友圈把 cu 口去了 问行不行就是行问好不好就是不好。就算编程的人都知道尽量别动共享变量避开同步要异步要percpu怎么到了网络这里就开始天天瞎扯拥塞控制而不是异步避免拥塞同样在处理器访存时那么多核心一起访问内存内存墙越来越高后瞎折腾 L2/L3 cache 而不是搞独占和错峰都 TMD 治标不治本且越搞越复杂好吗一回事的解法也是一回事三层架构和叶脊都太正则了这不明显去硬碰同步的吗路边摊小贩都知道摆一路而不是摆一排公务员和经理都知道错峰上班一帮工人一起挤着打卡堵了不是活该就不能不规定准点上班谁规定汇聚设备下不能挂服务器了让你们错开为你们好总有 SB 瞎怼挑毛病。当然为了卷绩效的话你说什么都对。 多跟编程的学学避开共享避开同步放之四海而皆准。编程的时候知道不编就忘了同步就是峰谷落差太大集中力量闯大祸。所有人一起跺脚的频率和桥匹配能把桥振塌所有流量一起到能把 buffer 干爆所有处理核一起 spin能把板子烧了。
尝试一下如何从根本上解决问题而不是 “尽可能缩短时间”后者毕竟只是缓解而不是解决。根本方案就是消除数据通信。这会儿从 cpu 说起。
最初cpu 是数据面核心所有数据都要送往 cpu。冯诺依曼存结构cpu 负责计算内存负责存储两者之间必然要通信。于是计算存储通信三大件儿各按自身规律独立发展。但随着单一功能外设(我关注网卡)快速发展cpu 很快成了慢速设备更别提内存了。事实上cpu 大多也是被内存拖累 访存时间太慢但无论如何冯诺依曼结构决定了 cpu 和内存只能共荣辱。
cpu 成了控制面不再被寄希望于干重活。Linux 内核被认为不是千万并发的方案而是问题所在大家想方设法 bypass kernelbypass cpukernel 和 cpu 在高性能网络领域被认为很 low。
事实上不是 cpu low高性能网卡毕竟功能相对单一携带大量 offloading engine比 cpu 更快处理网络报文理所当然但当它们遇到甚至 1.6Tbps 时也会逐渐吃力你看它们和 cpu 内存没有本质区别。
问题不在 cpu问题在冯诺依曼结构根本上是个网络通信结构统计复用的带宽同步争抢问题是固有的再大带宽也挡不住概率性突发。
如果倒转视角把 cpu 当作控制面而不再是 “中央(数据)处理” 器而以内存为 “中央”并在内存的存储颗粒间嵌入计算单元(摩尔定律允许这么做)cpu 只负责将 “代码” 发给内存内存自己进行计算和存储就打破了冯诺依曼结构消除了数据通信时对内存带宽的同步争抢 mapreduce 网络传输也可以这么玩举一例不要将片段扇入到一个节点再一边走一边拼接走到底也拼完了以数据本身为中心而不是以数据传输为中心过交换机的时候一定是一份大数据而不是多份小数据只有一条流显然就消除了同步访问更容易做流控 无意同步却全局同步有意同步以合作代替争抢这很辩证。
性能问题就是时间问题时间问题的根源在等待资源无论网络传输还是 cpu 内存传输都一样。最终所有问题归根结底就是多路复用问题而多路复用则分为统计复用和非统计复用(如时分复用)区别在于统计复用会因个体异常拉偏均值比如 tail latency.
当我们说 “系统性能差” 时一定是在抱怨时间太久但真实的 “系统” 性能差一定不针对个体它一定是全局的。系统性能差几乎一定是资源不足剩下的就是使用资源的方式了由于统计复用个体会拉偏整体“要异步使用资源而不是同步使用”也就是本文的主旨。
说一万次了buffer 不属于系统资源带宽才是。
浙江温州皮鞋湿下雨进水不会胖。
