下面我包括文字解释的问题，我面临的风暴。无论如何，我知道这是一个很长的帖子（只是一个提示），任何评论/暗示都是非常受欢迎的。描述如下：
我已经在一台服务器上安装了storm 0.9.4和zookeeper 3.4.6（2个带有intel xeon 8核芯片的插槽，运行centos的96 gb ram），并设置了一个伪分布式单节点storm运行时。我的配置由1个zookeeper服务器、1个nimbus进程、1个supervisor进程和1个worker进程（提交拓扑时）组成，它们都运行在同一台机器上。我的实验的目的是观察当输入负载在执行器线程之间动态分布时，storm在单个节点设置上的行为。
为了我的实验，我有一个输入元组，由1个长元组和1个整数值组成。输入数据来自两个从磁盘文件读取元组的喷口，我控制输入速率以遵循以下模式：前24秒（时间0-24秒）为200元组/秒，后12秒（24-36秒）为800元组/秒，再转6秒（时间36-42秒）为200元组/秒，我有两种类型的螺栓：a）接收来自两个喷口的输入的调度程序螺栓，和（b）对元组执行操作并将一些元组保持为状态的使用者螺栓。dispatcher的并行性提示是一个（1个执行器/线程），因为我已经检查过它从来没有达到其容量的10%。对于消费螺栓，我有两个并行提示（该螺栓有两个执行器/线程）。我前面提到的输入速率是经过挑选的，这样我就可以在消费端上使用适当数量的执行器来监视小于10毫秒的端到端延迟。具体来说，我使用一个使用者执行器运行了相同的拓扑，它可以处理200元组/秒的输入速率，端到端延迟<10毫秒。类似地，如果我再添加一个使用者执行器（总共2个执行器），拓扑可以消耗800元组/秒，端到端延迟<10毫秒。在这一点上，我不得不说，如果我使用一个消费执行器，每秒800个元组，那么端到端延迟将达到2秒。顺便说一句，我必须提到，我使用bolts的ack（）函数测量端到端延迟，并查看在拓扑中发送元组到元组树被完全确认之间所花的时间。
正如您现在所意识到的，我们的目标是通过模拟添加另一个使用者执行器来查看是否可以保持输入峰值的端到端延迟<10毫秒。为了模拟添加输入峰值的处理资源，我使用直接分组，在峰值之前，我只向两个使用者执行器中的一个发送元组。当dispatcher上检测到峰值时，它也开始向另一个使用者发送元组，以便在两个线程之间平衡输入负载。因此，我希望当我开始向额外的使用者线程发送元组时，端到端延迟将回落到其可接受的值。然而，以前的情况并没有发生。
为了验证我的假设，即两个使用者执行器能够在峰值期间保持<10毫秒的延迟，我执行了相同的实验，但这次，我在整个实验生命周期内向两个执行器（线程）发送元组。在这种情况下，端到端延迟保持稳定并处于可接受的水平。所以，我不知道在我的模拟中到底发生了什么。在输入负载被重新定向到额外的使用者执行器的情况下，我真的不知道是什么导致了端到端延迟的恶化。
为了弄清楚更多关于风暴的机制，我在一台较小的机器上做了同样的设置，并做了一些分析。我看到大部分时间都花在lmax中断器的阻塞等待策略上，它控制着cpu。我的实际处理函数（在consumerbolt中）只使用了lmax blockingwaitstrategy的一小部分。因此，我认为这是队列之间的一个i/o问题，与使用者中元组的处理无关。
你知道什么地方出了问题，我会有这种激进/令人困惑的行为吗？
谢谢您。