背景

#

有客户反馈，在系统中运行某个APP，会导致系统的网络卡顿。 关掉APP后可以恢复正常，开启APP后网络又会变得卡顿。

分析

#

• 先ping 127.0.0.1发现没有问题，说明问题和«06Linux性能优化实例_socket过多.md» 不一样，可能是硬件问题。

• 通过ifconfig可以看到网卡的收包数据停止增长。

• 根据《04Linux子系统- net网络.md》，可以分析出网卡的收包使用的是 NAPI+软中断 的方式。因此分析是否是NAPI没有触发。

定位

#

使用ftrace工具，追踪NAPI是否触发。

frace的使用教程，参考这4篇文章
https://tinylab.org/ftrace-usage/
https://tinylab.org/source-code-analysis-dynamic-analysis-of-linux-kernel-function-calls/
https://tinylab.org/trace-cmd/
https://events.static.linuxfound.org/sites/events/files/slides/praesentation_0.pdf

trace-cmd工具和kernelshark工具的使用参考：
https://wiki.stmicroelectronics.cn/stm32mpu/wiki/Trace-cmd_and_kernelshark_trace_viewer
https://blog.csdn.net/21cnbao/article/details/108414081
https://elinux.org/images/6/64/Elc2011_rostedt.pdf

首先需要重新编译内核，开启 FTRACE 选项，其他的识情况开启

cd /sys/kernel/debug/tracing
echo 1 > events/napi/napi_poll/enable #追踪napi_poll
echo 1 > tracingon #开启追踪
cat trace_pipe #查看追踪情况

可以看到napi_poll追踪点的触发情况。如下图所示：

启动有问题的APP后，可以看到napi_poll停止打印了，说明没有执行。没有执行的原因大概率是线程被抢占了，因此再使用 trace-cmd工具配合kernelshark工具追踪一下调度：

可以看到，出问题时，有CPU明显被抢占了。

通过查看线程优先级，可以看到此线程的优先级为实时优先级，关于线程优先级请参考《05Linux性能优化_线程调度.md》

解决

#

修改APP，不要调整线程的优先级，问题解决。