|
一、网络性能指标
1、speed: 延时 lantency
ping的时间/2 就是一个网络延时
2、bandwidth 带宽
二、网络运行状况
1、网卡运行情况
（1）ifconfig ethx
 RX errors: 表示总的收包的错误数量，这包括 too-long-frames 错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
RX dropped: 表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。 RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一，上面那台有问题的机器就是因为 interruprs 分布的不均匀(都压在 core0)，没有做 affinity 而造成的丢包。 RX frame: 表示 misaligned 的 frames。 TX 表示发送，其参数与RX类似；
（2）ethtool 可以查看网卡队列长度等信息
ethtool -g eth1
2、系统情况
（1）cat /proc/net/snmp | grep Udp 查看udp或者tcp链接情况
 （2）netstat -su/st
 方法（1）（2）得到的两个结果接近；
（3）socket队列长度，cat /proc/sys/net/core/rmem_default (wmem_default是写队列长度)
3、进程情况
（1）netstat -au | grep 端口号，查看Recv-Q 和 Send-Q的大小，如果长期不为0，则说明该进程接收已经处理不过来了或者该进程发送包过多；
三、丢包常见原因（以下为转载自http://blog.csdn.net/turkeyzhou/article/details/7526081）
1) linux内核socket缓冲区设的太小
2) 服务器负载过高，占用了大量cpu资源，无法及时处理linux内核socket缓冲区中的udp数据包，导致丢包 一般来说，服务器负载过高有两个原因：收到的udp包过多；服务器进程存在性能瓶颈。如果收到的udp包过多，就要考虑扩容了，从日常运营的经验来看，公司现有的B5机器，在业务逻辑不复杂(简单的打包解包和内存hash等操作)、不超过网卡流量限制的情况下，每秒可以处理25万个udp包。至于如何提高服务器的性能，属于高性能服务器的设计和实现范畴，功力有限，不敢在这里班门弄斧，自己平时使用最多也就是三板斧：top+strace+ltrace,先使用top查看cpu内核态时间和用户态时间的比例，如果内核态时间占大头，就用strace查看主要的系统调用有哪些；如果如果用户态时间占大头，就用ltrace查看主要的库函数调用有哪些。找到性能瓶颈后，想办法优化系统架构和业务逻辑，减少不必要的系统调用和库函数调用。从以往的经验来看，很容易犯的一个错误是调用不必要的memset或memcpy操作一大片内存，当请求量小的时候，发现不了问题，一旦突发的请求过来，触发大量的memset或memcpy操作，占用了cpu资源，导致丢包和滚雪球，让人措手不及，所以系统上线前，一定要做好压力测试，通过压力测试找出性能瓶颈，将危险消灭在萌芽状态。
3) 磁盘IO忙 服务器有大量IO操作，会导致进程阻塞，cpu都在等待磁盘IO，不能及时处理内核socket缓冲区中的udp数据包。如果业务本身就是IO密集型的，要考虑在架构上进行优化，合理使用缓存降低磁盘IO。这里有一个容易忽视的问题:很多服务器都有在本地磁盘记录日志的功能，由于运维误操作导致日志记录的级别过高，或者某些错误突然大量出现，使得往磁盘写日志的IO请求量很大，磁盘IO忙，导致udp丢包。对于运维误操作，可以加强运营环境的管理，防止出错。如果业务确实需要记录大量的日志，可以使用内存log或者远程log。
4) 物理内存不够用，出现swap交换 swap交换本质上也是一种磁盘IO忙，因为比较特殊，容易被忽视，所以单列出来。 只要规划好物理内存的使用，并且合理设置系统参数，可以避免这个问题。
5) 磁盘满导致无法IO 没有规划好磁盘的使用，监控不到位，导致磁盘被写满后服务器进程无法IO，处于阻塞状态。公司的监控中心对机器的磁盘使用率有监控，使用率超过95%会通知机器负责人处理。但是如果机器负责人错过了告警，或者没有及时处理告警，仍然会导致磁盘被写满。最根本的办法是规划好磁盘的使用，防止业务数据或日志文件把磁盘塞满，同时加强监控，例如开发一个通用的工具，当磁盘使用率达到80%时就持续告警，留出充足的反应时间。 |
|
|
