SRS性能(CPU)、内存优化工具用法

SRS提供了一系列工具来定位性能瓶颈和内存泄漏，这些在./configure && make后的summary中是有给出来用法的，不过不是很方便，所以特地把用法写到这个文章中。

文中所有的工具，对于其他的linux程序也是有用的。

备注：所有工具用起来都会导致SRS性能低下，所以除非是排查问题，否则不要开启这些选项。

备注：本文CSDN链接在这里，简书链接在这里，以简书为准。

RTC是UDP的协议，先设置网卡队列缓冲区，下面命令是UDP分析常用的：

也可以修改系统文件/etc/sysctl.conf，重启也会生效：

查看接收和发送的丢包信息：

实例说明： 224911319 packets received，这是接收到的总包数。 65731106 receive buffer errors，接收的丢包，来不及处理就丢了。 123534411 packets sent，这是发送的总包数。 0 send buffer errors，这是发送的丢包。

备注：SRS的日志会打出UDP接收丢包和发送丢包，例如loss=(r:49,s:0)，意思是每秒有49个包来不及收，发送没有丢包。

查看接收和发送的长度：

实例说明； Recv-Q 427008，程序的接收队列中的包数。Established: The count of bytes not copied by the user program connected to this socket. Send-Q 0，程序的发送队列中的包数目。Established: The count of bytes not acknowledged by the remote host.

下面是netstat的一些参数：

--udp|-u 筛选UDP协议。 --numeric|-n 显示数字IP或端口，而不是别名，比如http的数字是80. --statistics|-s 显示网卡的统计信息。 --all|-a 显示所有侦听和非侦听的。 --listening|-l 只显示侦听的socket。 --program|-p 显示程序名称，谁在用这个FD。

PERF是Linux性能分析工具，参考[PERF](perf record -e block:block_rq_issue -ag)。

可以实时看到当前的SRS热点函数：

或者记录一定时间的数据：

记录堆栈，显示调用图：

Note: 也可以打印到文件perf report --call-graph --stdio >t.txt。

Remark: 由于ST的堆栈是不正常的，perf开启-g后记录的堆栈都是错乱的，所以perf只能看SRS的热点，不能看堆栈信息；如果需要看堆栈，请使用GPERF: GCP，参考下面的章节。

GPROF是个GNU的CPU性能分析工具。参考SRS GPROF，以及GNU GPROF。

Usage:

GPERF是google tcmalloc提供的cpu和内存工具，参考GPERF。

GCP是CPU性能分析工具，就是一般讲的性能瓶颈，看哪个函数调用占用过多的CPU。参考GCP。

Usage:

Note: 用法可以参考cpu-profiler。

图形化展示，在CentOS上安装dot：

然后生成svg图片，可以用Chrome打开：

GMD是GPERF提供的内存Defense工具，检测内存越界和野指针。一般在越界写入时，可能不会立刻导致破坏，而是在切换到其他线程使用被破坏的对象时才会发现破坏了，所以这种内存问题很难排查；GMD能在越界和野指针使用时直接core dump，定位在那个出问题的地方。参考GMD。

Usage:

Note: 用法可以参考heap-defense。

Note: 注意GMD需要链接libtcmalloc_debug.a，并且开启环境变量TCMALLOC_PAGE_FENCE。

GMC是内存泄漏检测工具，参考GMC。

Usage:

Note: 用法可以参考heap-checker。

GMP是内存性能分析工具，譬如检测是否有频繁的申请和释放堆内存导致的性能问题。参考GMP。

Usage:

Note: 用法可以参考heap-profiler。

VALGRIND是大名鼎鼎的C分析工具，SRS3之后支持了。SRS3之前，因为使用了ST，需要给ST打PATCH才能用。

Remark: SRS3之前的版本，可以手动给ST打PATCH支持VALGRIND，参考state-threads，详细的信息可以参考ST#2。

系统调用的性能排查，参考centos6的性能分析工具集合

在OSX/Darwin/Mac系统，可以用Instruments，在xcode中选择Open Develop Tools，就可以看到Instruments，也可以直接找这个程序，参考Profiling c++ on mac os x

Remark: 也可以在Active Monitor中选择进程，然后选择Sample采样。

还有DTrace可以用，参考动态追踪技术（中） - Dtrace、SystemTap、火焰图或者浅谈动态跟踪技术之DTrace。

多核时，一般网卡软中断在CPU0上，可以把SRS调度到其他CPU：

或者，指定SRS运行在CPU1上：

调整后，可以运行top，然后按数字1，可以看到每个CPU的负载：

或者使用mpstat -P ALL：

可以使用命令cat /proc/softirqs，查看所有CPU的具体软中断类型，参考Introduction to deferred interrupts (Softirq, Tasklets and Workqueues)。

如果将SRS强制绑定在CPU0上，则会导致较高的softirq，这可能是进程和系统的软中断都在CPU0上，可以看到si也比分开的要高很多。

如果是多CPU，比如4CPU，则网卡中断可能会绑定到多个CPU，可以通过下面的命令，查看网卡中断的绑定情况：

我们可以强制将网卡软中断绑定到CPU0，参考Linux: scaling softirq among many CPU cores和SMP IRQ affinity：

Note：如果要绑定到CPU 0-1，执行echo 3 > /proc/irq/$irq/smp_affinity

然后将SRS所有线程，绑定到CPU0之外的CPU：

如果要获取极高的性能，那么可以在SRS的启动脚本中，在启动SRS之前，执行绑核和绑软中断的命令。

可以设置SRS为更高的优先级，可以获取更多的CPU时间：

说明：nice的值从-20到19，默认是0，一般ECS的优先的进程是-10，所以这里设置为-15。

可以从ps中，看到进程的nice，也就是NI字段：