search

6.stap script

在probe一些函数的时候，会有额外的开销，systemtap在检测到overhead过大时，会终止脚本运行，下面我们利用一个脚本来验证：

  #system-overhead.stp
  1 global veth_xmit_cnt
  2 
  3 probe begin
  4 {
  5         veth_xmit_cnt=0;
  6 }       
  7 
  8 probe module("veth").function("veth_xmit")
  9 {
 10         veth_xmit_cnt++;
 11 }       
 12 
 13 probe timer.s(1)
 14 {
 15         printf("veth xmit :%d pps\n",veth_xmit_cnt);
 16         veth_xmit_cnt=0;
 17 }

这个脚本能够probe veth模块中veth_xmit()函数被调用的次数，通过pktgen对veth建立的两个接口发包测试，开启probe时候,通过stap统计得到veth上传输的速率：

另一方面，通过sar命令统计接口上的传输速率，得到一致的结果：

接下来，我们停止stap脚本，可以看出veth传输具有明显的提升：

甚至在解析数据结构的时候会出现overhead过重而终止脚本，我们可以使用-DSTP_NO_OVERLOAD来使得脚本即使在负重下也能运行。因此接下来我们使用stap脚本在性能探测的时候probe点每次只放置在一个地方。probe结果应该偏功能。

接下来探测linux设备驱动将数据包扔到linux网络协议栈后，来自一个以太网接口的数据包的在SMP多对成处理器上的分散情形。 首先探测来自网卡驱动的手包情况，通常网卡驱动的硬件中断会触发所在队列的NAPI，从而进行收发包并通过netif_receive_skb()或者netif_rx()函数递交给协议栈，单最终会经过enqueue_to_backlog()函数在硬件中断NAPI底半部分发给其他cpu，且在这个过程中完成RPS分布。

探测RPS功能的脚本如下所示：

主要记录enqueue_to_backlog（）由谁调用，以及入队列的时候将数据包交给谁。

接下来我们利用pktgen发包测试，pktgen构造数据包的时候源地址随机保障hash值变化。并且初始状态下网卡的队列掩码为0.

开始发包后，可以看到脚本输出：

通过观察发现，我们可以知道：

  • 由驱动接收数据包都在一个cpu上完成，这个cpu是cpu0，原因是veth虚拟网卡只有一个队列。

  • 虚拟网卡队列0默认没有开启RPS，所以在网上入队列的时候会与处理函数这个cpu所在的队列softnet上。

Previous5.SystemTap instrument.1Next6 stap script.1

Last updated