不同业务对网络的要求

前段时间遇到一起比较严重涉及业务也比较广的 outstage。跟大家分享下,我认为比较经典。
由于前端的接 webserver 的交换机(普通的 2960S 1G)在晚高峰阶段撑不住了,导致了大量的丢包。可以看下面这张图。

仔细观察可以发现,在大概 22:00 的时候,只有 outcoming 出现了一个明显的凹陷,而对于 incoming 流量说,几乎没有影响,曲线保持的非常好。
后来通过大量的排查发现,其实这个 imcoming 的主要对应某个单独的业务,而该业务的最明显的特点就是几乎只有进没有出流量,仅仅是一个 POST 请求,而蓝色曲线的则对应其他的几个业务,其同时涉及到进跟出的流量。
再到 SW 上看看就明白情况了:
#show interfaces GigabitEthernet0/48
GigabitEthernet0/48 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is xxxx.yyyy.zzzz (bia xxxx.yyyy.zzzz)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 85/255, rxload 116/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:52, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 793838

看到这里是不是就明白问题的原因了。

最初的时候,我发现我们的前端机器上 dmesg 有大量的报错,怀疑是 Nginx 的某个 bug 导致的,后来结合上面的情况就一目了然了。现在推测下来,应该是由于交换机的大量丢包,导致 Nginx 不断的向 upstream 重试,消耗了大量的内存,导致上面现象的出现,对比发现,我们同样负载的机器,只有 16G 的内存,没有出现任何的问题。

所以有时候出现问题,需要综合的思考各种情况,站的高才能看的远,这就是为什么有些问题别人解决不了而你能很快的定位到问题的根源。如果在排查过程中根本不知道或者压根没有想起有这回事,把自己仅仅局限于某个工作流水上的某一个零件,那估计一辈子都发现不了问题的根源了,在这种情况下,之前积累的经验会显的更为重要。