为什么我的代码有时会变慢（以及如何找出所有这些背后的原因）？

第2部分。理解

在本系列的上一篇文章中 ，我们介绍了用于捕获os抖动的可用工具，并提供了一种具有更高分辨率的新选择 ，当我们需要降至亚毫秒级时，该选择可能特别有用。

因此，让我们使用此工具并再次捕获一些操作系统抖动。 这次，我们运行的安装程序应该通过应用一些基本技巧来提供更优化的执行环境，这些技巧将使计算资源对用户进程更可用，并且不易被操作系统劫持，无法执行任何操作系统操作。天。

我们正在向内核传递一些额外的引导参数：

isolcpus = 6,7 nohz_full = 6,7 rcu_nocbs = 6,7处理器.max_cstate = 0 intel_idle.max_cstate = 0 transparent_hugepage =从不空闲=轮询电梯=无绳审计= 0 nosoftlockup = 0

如果您对他们的工作感兴趣，请阅读Jeremy Eder的精彩文章，或者只是通读内核os jitter README中的项目 。

这些内核启动参数应该为我们提供良好的CPU循环流，因此我们的程序可以毫无故障地执行。 对？

这次，我们不仅将尝试捕获抖动配置文件，还将记录潜在的活动以试图理解它。

为了自检内核活动，我们需要对其进行概要分析以识别任何抖动源。

最常见的是，人们使用ftrace（带有trace-cmd，内核鲨鱼）和function_graph插件。 这是许多需要深入研究系统内幕的专业人士使用的出色工具。 您还可以使用性能记录，然后使用性能报告脚本浏览捕获的配置文件，这些脚本还可以放大查看特定内核功能（或用户空间例程）执行了多少个周期。

如果您搜索内核配置文件工具，则您还会发现sysdig，systemtap或dtrace –如果您使用solaris或使用对Linux的实验性支持。

LTTng简介

我个人喜欢使用LTTng ，它是一个被低估并且相对很少了解Linux的性能分析堆栈。 它已经存在了很长一段时间，我认为它应该得到比现在更多的认可。

您可以在用户指南中了解其丰富的功能集以及如何有效使用它。

完成基本介绍后，让我们并行运行抖动采样器和lttng分析：

$ nohup jitter -c 6 -d 300 -r 10 -o influx://localhost:5581 &; lttng create jitter-sampling && lttng enable-events -k -a && lttng start && sleep 300 && lttng stop

现在，让我们看一下在我们隔离的内核之一上运行时，用户空间线程应该经历什么级别的中断：

哇，这不符合我们的预期，是吗？ 我们希望的是隔离一个完整的内核（用于HT设置的cpu6，cpu7）有助于我们实现相对较低的抖动水平。

几毫秒的峰值并不真正符合预期。 因此，为什么不放大这些尖峰之一，并尝试将其与LTTng记录的相关联。

在我看来，该工具最好的事情之一就是它以CTF（通用跟踪格式）持久保存已记录的事件，可以将其加载到另一个简洁的软件中：
跟踪罗盘 。

不错，不是吗？ 我会急切地想着发现它的奇迹。 现在，让我们继续关注相关核心以及它在停顿时正在执行的工作（21：40：07.200）：

所以现在情况变得清晰了。 我们的抖动采样线程由执行写回活动的kthread切换，作为处理相关工作队列的一部分。

工作队列是Linux内核的一种机制，用于管理通常与文件系统io，块设备或其他系统例程相关的延迟工作块。

让我们现在通过使用cpus 0-5关联写回工作队列来解决此问题。 这将排除我们的延迟关键集（CPU 6,7）。

echo 3f > /sys/bus/workqueue/devices/writeback/cpumask

现在该重新运行抖动采样器，看看是否有任何改进。

好多了…

尽管关联工作队列，irqs或rcu回调是一种非常基本的技术，但大多数面向性能的开发人员都熟悉本文的重点，而本文的重点完全不同。

我希望这篇简短的材料能够证明狩猎潜伏期尖峰并不一定总是令人恐惧的经历或某些黑暗系统工程技术的壮举。 通过使用和组合正确的工具，即使对于那些不太习惯深入研究OS内部的人来说，这也可能会成为富有成果的练习。

请继续关注本系列的下一篇文章，在本文中，我们将仔细研究硬件驱动的执行停顿源和其他不太知名的事件类型，这些事件导致了所谓的平台噪音。

翻译自: https://www.javacodegeeks.com/2017/04/code-slow-sometimes-find-whos-behind-2.html