在进行性能测试时，发现CPU使用率提高10%，perf分析显示inet_csk_bind_conflict函数占用17%。通过ss -s命令观察到socket数量增加20万，原因是sipp测试脚本超时设置过短，导致socket time-wait状态增多，引起bind冲突。解决方案包括使用版本控制管理脚本，避免因脚本差异引发问题，并在内核5.19中引入第二个bind表来缓解冲突。
今天又遇到一例，性能测试，相同的业务量，最后发现CPU的使用率比之前提高了10%。使用perf看，发现是：inet_csk_bind_conflict这个函数的使用率很高占到应用的17%。如果使用ss -s 命令去看，会发现比原来多出20万个socket使用情况。这就很可以说明为什么inet_csk_bind_conflict这个函数使用率高。即使没有重复的可能，做这个conflict的check也是会非常的耗时。
然后就看为什么socket个数使用的多了，最后发现是sipp使用的脚本和之前不一样，其中的一个超时时间设置比之前的短了，导致超时重新发起业务时，老的socket需要一定的time-wait时间来终止，导致最终的新的socket，做bind-conflict。
再一次说明，使用sipp做性能测试时，需要注意的一个问题：一定要将相关的xml脚本文件，需要放到git repo里，需要使用版本控制的机制来管理，不能每次碰到问题，都是有脚本上的些许区别。因为这种问题倒推的过程实在是太过艰难。每次都需要花费很多精力，时间去调查问题，到底是在哪里？如果最后总是发现是脚本不一样，虽然说是一种锻炼机会，但也可以说是比较不放心的一个结果。
如果说每套lab，所对应的特定的信息需要改变xml脚本，那就将这些特定的信息，抽象话出来，把公共的部分放进去。
Mar 19 08:37:06 sc1-a kernel: [337626.332985
订阅专栏 解锁全文
扫一扫
315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
