我的hadoop执行瓶颈在CPU？

我在一台服务器上启动了1-3个并发的hadoop实例（v.1.2.1） 这些是完全独立的，其中：

• 他们正在使用不同的端口
• 他们可以访问完整的独立文件系统（HDFS）

我已采取措施消除任何潜在的瓶颈：

• 设置唯一的服务器作为“主”（Namenode / Jobtracker）和“从属”（Datanode / Tasktracker）节点。 这已经完成，以消除任何潜在的networking瓶颈。
• 在tmpfs上挂载整个hadoop文件系统; 这包括hadoop.tmp.dir （在core-site.xml ）以及dfs.name.dir和dfs.data.dir （在hdfs-site.xml ）。 因此，HDFS和映射器的中间数据都直接写在tmpfs 。 这已经完成，以消除任何潜在的硬盘瓶颈。

我试图解决的问题是：当这1-3个并行实例同时执行相同的数据集时，执行时间会更长。 每个执行都被configuration为尽可能less的任务资源：每个执行产生11个映射器和1个reducer。

我已经测量了各种潜在的瓶颈，但是我没有能够拿出令人信服的解释。 我的本能告诉我这是在CPU上，但是我的测量结果certificate了我的不然。 特别是：（数字如下）

• 当rc.local脚本停止防火墙时，zookeeper自动启动操作失败
• Apache Ambari以及如何检查Ambari服务状态
• ambari + spark不能从CLI启动
• 如何用blueprint.json文件重新configurationAmbari服务值
• ambari + API语法，以更改ambari服务的参数

• 时间：我运行的并行执行越多，执行时间就越长。 Mappers似乎直接受到影响，并有助于延长执行时间。
• CPU：使用PCM工具测量的利用率。 活动核心的利用率在80％左右，表明这些工作确实是CPU密集型的，但整体（名义）利用率根据租户数量进行很好的扩展，表明我们有足够的CPU资源来执行所有的工作。
• 内存IOPS：IOPS的规模与租户数量一样好，因此似乎没有明显的瓶颈。 内存IOPS很高，因为我们直接写入tmpfs 。 还使用PCM工具测量。
• 内存空间：绰绰有余; 每个执行需要大约3个GiB（input，映射器的输出，reducer的输出），并且在每个hadoop实例的临时/ HDFS文件夹上挂载10个GiB的tmpfs 。
• PCIe（QPI）：随着越来越多的租户带宽的增加，似乎也没有任何瓶颈。 基于另一个问题 ，我的系统似乎能够支持高达32 GB /秒，因此我们远远没有达到最大容量。 还使用PCM工具测量。
• 硬盘：写入IOPS非常低，因为我们没有写入硬盘。 读取IOPS报告为零。 使用iotop -bot测量。
• 交换：通过htop视觉检查; 没有使用交换空间。
• networking：只有一台机器正在使用，所以networking没有被利用。

我的瓶颈在哪里，或者我应该测量什么？ 此外，我是否正确解释CPU测量 ？ 很明显，在一个活动周期内，我们的利用率在80-100％之间，但这只影响一次执行的执行时间。 由于我们有足够的核心，理论上可以在不影响性能的情况下维持多次执行，总体利用率的提高表明了这一点。 我错了吗？

由于映射器需要更多的时间来执行，我怀疑有一个CPU问题，但是我的测量显示，否则。

以下是我的测量数据。 这些在物理机器上被采取，测量总时间/利用率/吞吐量。 例如，CPU利用率显示了正在运行1个执行（红色），正在运行2个并发执行（绿色）和正在运行3个并发执行（蓝色）时的利用率。