Stephen Wolfram云端捉虫之旅(二)

到底是什么在消耗CPU？

我开始考虑在同一台机器上运行的其他Wolfram云服务了，但看起来它们不像是会导致我们所看到的缓慢运行问题。但是想要简化系统的想法使我想把这些都删除。一开始，我隔离了生产集群上的一个节点，然后我建立了一个自己的Wolfram Private Cloud。但是缓慢运行的问题仍然存在，但令人疑惑的是，在不同时段和不同机器上，它们表现出了一些不同的特点。

在我的Private Cloud上，我可以登录Linux系统查看数据。我做的第一件事就是将 top 和 ps axl 的结果导入到Wolfram 语言中并进行分析。我立刻发现很多系统运行速度被消耗了：Linux内核正处理一些别的东西。实际上，速度变缓好像并不是因为用户运行的程序，而是可能由于操作系统内核的原因。

这使我想跟踪系统调用的整个过程。我已经快25年没做过类似的事情了，在我以往的经验中，我可以通过这种方式获得很多代码，但是却很难解释和翻译它们。但是现在，我可以使用Wolfram语言。我在调用API的这几秒期间同时运行Linuxstrace，这产生了28,221,878行代码，而这只需要Wolfram语言的几行代码就能开始或者结束特定的系统调用，并生成系统调用周期的柱状图。经过几次相同的操作后，我得到以下柱状图：

有意思的是，图中显示了离散高峰。当我查看在离散高峰期间的系统调用数据时，发现它们看起来更像是futex调用--Linux线程同步系统的一部分。所以当我把futex调用单独挑选出来以后，看见了明显的高峰节点

-250ms，500ms和1s：

但这能称之为问题吗?futex调用一般情况下都处于睡眠状态,不消耗运行时间。而且，这种调用等待输入和输出是很正常的。因此对我来说，观察到的最有趣的现象就是其他的系统调用没有出现消耗几百毫秒的情况。

操作系统冻结了

那么，到底是怎么回事呢？我开始观察每一个节点内核的情况。现在，

Tomcat和基础架构的其他部分处于很好的多线程环境中。这样看来，无论是什么因素导致了速度变慢，这个因素都是在冻结所有的节点内核，虽然这些节点内核在不同的线程中运行。而能够导致这种现象出现的只有操作系统内核。

但是到底是什么导致Linux内核冻结呢？我想到了调度器。我不知道现在的状况为什么使我联想到调度器出了问题，但是我还是检查了调度器，并修改了很多设置，结果还是没用。

然后我有了一个更奇怪的想法，我当前操作的Wolfram Cloud实例正在虚拟计算机上运行。有没有可能速度变慢的原因来自外部？我找到了一台不带虚拟机的裸机来运行Wolfram Cloud。在开始操作之前，我找到一个实用程序来衡量虚拟机本身=偷走的时间，这时间几乎是可以忽略不计的。

到这个时候为止，我每天花一个小时的时间研究这件事，已经持续了好多天了。恰好到了参加SXSW(小编语:老沃今年在此大会有非常精彩的演讲)的时间，而我们负责云产品的工程师们都对这个难题跃跃欲试，所以我就把问题交给他们了.

当我飞机刚落地的时候，他们已经得出一些新的有趣的数据。我们把每一个API调用分解成15个步骤，然后我们的物理工程师将某个小步骤中速度变慢的用时（左边）与该步骤平均用时（右边）进行了对比：

除了一个例外（由一个已知的原因导致），两者显示出了很好的相关性。看起来Linux 内核(以及在其之下运作的所有程序)似乎真的受到了某种外部因素的不定时扰乱，如果扰乱恰好在调用API的过程中发生，速度就变慢了。

那么，现在的问题是究竟是什么外部因素在扰乱系统呢？我们怀疑是数量庞大的输入和输出活动。在我们进行测试的裸机上，Wolfram Cloud利用NFS网络文件系统来获取文件。我们尝试调试NFS、修改参数、选择异步模式、用UDP来代替TCP、修改NFS服务器的输入/输入的调度程序等，但结果表明这些都不是问题所在。我尝试采用完全不相同的分布式文件系统Ceph，问题依旧存在。当我们尝试使用本地磁盘储存时，事情终于出现了转机-我们减少了绝大部分速度变慢的情况，但速度变慢并没有完全消失。我们沿着这个线索开始对输入和输出进行深入调查。在一个实验中，我们在一个节点上编辑带有大量代码的笔记本文档，同时在该节点进行大量的API调用操作，结果如下图所示：

结果很有趣。在编辑笔记本的时候（同时在不断自动保存），API调用时间突然从100ms变成了500ms。但为什么这种简单的操作会对一个节点的8个内核产生这么大的作用？

罪魁祸首找到了！

我们开始进行更深入的调查，并快发现那些看起来简单的文件操作其实并不简单，我们很快找出了原因！5年前，在Wolfram Cloud发展早期，我们曾经想试用文件版本管理，而作为概念验证，我们插入了一个简单的版本控制系统RCS。

尽管RCS在过去三十年没有持续更新，市面上也有很多其他更好的实现版本控制的方法和软件（例如我们在笔记本文档无限撤销功能中使用的软件），还是有很多软件系统在运用这个RCS。而我们用来实现概念验证的RCS始终存在于Wolfram Cloud 基础代码中，没有被替换，也就是说，RCS一直在每一个文件中运行！

RCS的特点之一是当一个文件被修改时，哪怕只改了微小的部分，也会造成大量数据（甚至比文件自身大好几倍）被拷贝进磁盘。这将产生多少输入和输出工作，我们现在也没有一个大概的估计。但是可以明确的是，RCS造成了很多不必要的输入和输出工作.

那么，输入和输入活动能影响整个Linux内核吗?也许还存在某种神秘的原因呢；也许磁盘子系统由于无法快速缓冲文件导致了系统冻结呢；也许内核一直忙于对页面进行重新映射以实现更大的内存呢。然而不管还有什么其他的因素，目前我们要做的就是抛弃RCS，看看会发生什么。于是我们这么做了，抛弃了RCS并仔细观察，结果是速度变慢的现象立刻完全消失了！

在一周的紧张调试和排除故障以后，我们对此做出了解决方案。然后我们重复了我最开始做的那个实验，一切都很顺畅，API调用时间完全由网络传输和测试集群决定：

Wolfram语言与Wolfram Cloud

我从这件事学到了很多东西。首先，它强化了我对云技术难度的印象-云环境是我从事软件行业以来遇到的最难的，甚至可以说是不友好的发开和调试环境。第二，这件事使我意识到，作为分析、可视化和组织云等复杂系统内部结构的元系统，Wolfram 语言是多么强大和实用。当涉及到调试和排除故障时，可以说我这么多年真是太轻松了，甚至是被宠坏了，因为我绝大部分的程序都在Wolfram语言中完成，而在Wolfram语言中调试系统是非常容易的，绝大多数bug在几分钟之内就能发现。那么，为什么在Wolfram语言中调试和排除故障这么容易呢？我想，首先也是最重要的原因是代码简洁、可读性强。用户可以在笔记本文档中输入、测试代码并进行文档化。还值得说明的一点是，Wolfram语言是一种符号语言，因此用户可以抽取程序中的任意部分输入Wolfram语言，Wolfram语言能以其特定的方式识别并运行。

与此相反, 在其他软件底部层次进行调试是很不一样的体验。这个过程更像是医疗诊断，诊断的同时还要考虑一个复杂多元的系统，并从测量和实验中找出问题所在。（我觉得我们的版本控制问题就像是DNA复制中出现的一些可怕的缺陷）

我想，在云技术中的这番经历也体现了Wolfram Cloud的宗旨和价值。

Wolfram Cloud的宗旨之一就是使人们不需要再面对云设施中错中复杂的问题，而是通过Wolfram语言直接进行执行和部署。