将接收端和发送端的套接字缓冲区设置为【8MB, 8MB】，接收端是while循环recv的directrecv模式下，8个ROS进程，每个ROS处理一个socket, 发送和接收包长为2KB, 运行了大约12个小时的带宽曲线如下：
计算得到每个接收进程的平均带宽，以及8个进程的平均带宽的和为：
2.61563
3.5609
3.50985
3.12713
3.22121
3.13252
3.00344
3.99146
sum ave bw: 26.16214总的平均带宽为26Gb/s，且接收端的CPU idle 为0，发送端的CPU idle 为80%。此时的瓶颈为接收端的CPU。
通过top -H -p pid 命令可以查看进程的线程数，通过gstack pid可以看到线程的函数调用栈。用前面两条命令可以查看到每个ROS进程都有三个线程在执行:一个是ROS::UDPChannels, 一个是ROS::RequestHandler; 一个是Recv。其中只要Recv是当前接收数据线程。可以将另外两个线程disable掉，释放一部分CPU资源，增加线程数，看看带宽会不会继续增加。
问题是：如何disable掉UDPChannels?
记起来了，应该是在IOManager.cpp里面注释掉UDPCHannels有关的行，注释掉RequestHandler有关的行。
去掉UDPChannels和RequestHandler后，重新运行ROS和发送端程序，运行3个小时，带宽曲线和上图相似，平均带宽和也为26.1%左右，接收端的cpu idle 为 70%，发送端的cpu idle 为 74%, 接收端一共有8个接收线程，一个l2sv_main（占满了一个核），折算起来，发送端的8个进程单cpu占用率为（1-74%）/(8/24)=78%,接收端的9个进程的单CPU占用率为（1-70%）/（9/24）=80%。
接收端和发送端的cpu占用率都没有达到100%，带宽没达到40Gb/s，那什么是瓶颈呢？会不会因为多进程之间的切换占用了cpu时间，导致这段时间的cpu空闲。。？
继续增加ROS进程个数，当ROS进程个数为12时，查看接收端的CPU占用率，发现：
Tasks: 690 total, 3 running, 673 sleeping, 14 stopped, 0 zombie
Cpu(s): 5.0%us, 17.4%sy, 0.0%ni, 63.1%id, 0.1%wa, 0.0%hi, 14.4%si, 0.0%st
Mem: 32979808k total, 13664180k used, 19315628k free, 178272k buffers
Swap: 33554428k total, 140416k used, 33414012k free, 11532988k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27147 lhaaso 20 0 1219m 42m 29m S 100.8 0.1 10:10.56 l2sv_main
27223 lhaaso 20 0 1072m 29m 20m S 98.2 0.1 9:36.77 ReadoutApplicat
27191 lhaaso 20 0 1072m 32m 20m S 81.8 0.1 8:08.77 ReadoutApplicat
27169 lhaaso 20 0 1072m 28m 20m S 70.5 0.1 7:48.94 ReadoutApplicat
25 root 20 0 0 0 0 R 60.2 0.0 37:11.73 ksoftirqd/5
27256 lhaaso 20 0 1072m 28m 20m S 58.0 0.1 6:46.97 ReadoutApplicat
27201 lhaaso 20 0 1072m 29m 20m S 55.7 0.1 6:34.52 ReadoutApplicat
27241 lhaaso 20 0 1072m 28m 20m S 55.0 0.1 4:49.45 ReadoutApplicat
27176 lhaaso 20 0 1072m 28m 20m S 45.9 0.1 3:35.92 ReadoutApplicat
27247 lhaaso 20 0 1072m 28m 20m S 45.7 0.1 5:21.19 ReadoutApplicat
57 root 20 0 0 0 0 R 44.1 0.0 8:39.69 ksoftirqd/13
27162 lhaaso 20 0 1072m 28m 20m S 35.3 0.1 3:52.14 ReadoutApplicat
27213 lhaaso 20 0 1072m 32m 20m S 35.0 0.1 4:30.98 ReadoutApplicat
2234 root 20 0 0 0 0 S 26.6 0.0 28:43.09 kondemand/5
27154 lhaaso 20 0 1072m 29m 20m S 25.4 0.1 2:41.38 ReadoutApplicat
27183 lhaaso 20 0 1072m 31m 20m S 25.0 0.1 2:42.05 ReadoutApplicat
2242 root 20 0 0 0 0 S 17.9 0.0 27:40.58 kondemand/13
55 root RT 0 0 0 0 S 3.0 0.0 0:18.14 migration/13
23 root RT 0 0 0 0 S 0.5 0.0 1:20.04 migration/5
104 root 20 0 0 0 0 S 0.4 0.0 6:10.83 events/5
112 root 20 0 0 0 0 S 0.2 0.0 6:32.42 events/13
2230 root 20 0 0 0 0 S 0.2 0.0 22:22.66 kondemand/1
2233 root 20 0 0 0 0 S 0.2 0.0 14:14.19 kondemand/4
2246 root 20 0 0 0 0 S 0.2 0.0 16:26.91 kondemand/17
23800 lhaaso 20 0 10.2g 254m 14m S 0.2 0.8 0:19.68 java
26918 lhaaso 20 0 1394m 32m 24m S 0.2 0.1 0:00.30 es_servertop - 20:43:47 up 232 days, 9:55, 12 users, load average: 5.52, 5.35, 4.90
Tasks: 691 total, 2 running, 675 sleeping, 14 stopped, 0 zombie
Cpu0 : 6.2%us, 28.3%sy, 0.0%ni, 64.7%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st
Cpu1 : 8.2%us, 42.4%sy, 0.0%ni, 13.1%id, 0.0%wa, 0.1%hi, 36.2%si, 0.0%st
Cpu2 : 5.0%us, 20.9%sy, 0.0%ni, 73.3%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st
Cpu3 : 6.1%us, 29.9%sy, 0.0%ni, 62.5%id, 0.0%wa, 0.1%hi, 1.3%si, 0.0%st
Cpu4 : 10.2%us, 38.1%sy, 0.0%ni, 26.7%id, 0.0%wa, 0.0%hi, 25.0%si, 0.0%st
Cpu5 : 0.9%us, 5.3%sy, 0.0%ni, 0.2%id, 0.0%wa, 0.0%hi, 93.5%si, 0.0%st
Cpu6 : 2.4%us, 12.8%sy, 0.0%ni, 83.9%id, 0.9%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 2.6%us, 14.4%sy, 0.0%ni, 83.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 2.2%us, 11.7%sy, 0.0%ni, 86.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 1.4%us, 7.1%sy, 0.0%ni, 91.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 39.3%us, 60.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu12 : 8.8%us, 36.8%sy, 0.0%ni, 27.7%id, 0.1%wa, 0.0%hi, 26.6%si, 0.0%st
Cpu13 : 0.2%us, 1.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 98.6%si, 0.0%st
Cpu14 : 1.7%us, 6.8%sy, 0.0%ni, 91.1%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st
Cpu15 : 8.7%us, 37.4%sy, 0.0%ni, 26.7%id, 0.0%wa, 0.0%hi, 27.1%si, 0.0%st
Cpu16 : 1.7%us, 6.9%sy, 0.0%ni, 91.2%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Cpu17 : 8.3%us, 44.9%sy, 0.0%ni, 4.6%id, 0.0%wa, 0.0%hi, 42.2%si, 0.0%st
Cpu18 : 1.4%us, 8.8%sy, 0.0%ni, 89.5%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu19 : 1.3%us, 6.7%sy, 0.0%ni, 92.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu20 : 0.4%us, 2.3%sy, 0.0%ni, 97.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu21 : 0.5%us, 2.9%sy, 0.0%ni, 96.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu22 : 0.4%us, 1.2%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu23 : 0.0%us, 0.1%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st发现cpu5 和cpu13上 ksoftirqd ， kondemand两个程序把cpu占满了，主要是 si 时间达到接近100%，也就是说软中断消耗时间占满了两个核。此时的总平均带宽为29.7Gb/s。
在发送端运行sar -n TCP,ETCP 5命令，发现tcp有重传，重传率为0.1~0.4%. 是接收端服务器压力太大导致了丢包吗？接收端的软中断负载太高导致了丢包？此时的瓶颈也还是CPU。
11:45:56 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
11:46:01 AM 0.00 0.00 249.10 0.00 0.00
11:46:01 AM active/s passive/s iseg/s oseg/s
11:46:06 AM 0.00 0.00 158001.41 140671.89
11:46:01 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
11:46:06 AM 0.00 0.00 380.52 0.00 0.00
11:46:06 AM active/s passive/s iseg/s oseg/s
11:46:11 AM 0.00 0.00 152455.73 124130.38
11:46:06 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
11:46:11 AM 0.00 0.00 371.23 0.00 0.00
11:46:11 AM active/s passive/s iseg/s oseg/s
11:46:16 AM 0.00 0.00 152367.28 111925.20
11:46:11 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
11:46:16 AM 0.00 0.00 228.66 0.00 0.00
11:46:16 AM active/s passive/s iseg/s oseg/s
11:46:21 AM 0.00 0.00 154135.63 125263.97
11:46:16 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
11:46:21 AM 0.00 0.00 353.44 0.00 0.00
^C
继续增加ROS进程数量到16个，见下一篇随笔。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
