《Hadoop MapReduce性能优化》一2.3 性能监测工具

2.3 性能监测工具

Hadoop MapReduce性能优化
监测Hadoop集群节点的系统资源(如CPU利用率和磁盘平均数据传输率)有助于理解硬件资源的总体利用情况,并在诊断性能问题时找出瓶颈。Hadoop集群监测包括集群节点上系统资源使用情况的监测和核心服务指标的监测。最常监测的资源包括I/O带宽、每秒磁盘I/O操作的次数、平均数据传输率、网络延迟、平均内存和交换空间利用情况。

Hadoop性能监测建议收集性能计数器的数据,这样做是为了判断各种任务的响应时间是否在可接受的执行时间范围内。MapReduce任务的利用率平均百分比和一个时间段内的HDFS存储容量指明了集群资源是得到了最优利用还是利用不足。

Hadoop提供了大量用于监视与调试Hadoop服务的指标与信息源。这些系统与服务指标需要从集群节点收集并进行关联,以便分析Hadoop集群的整体状态,并诊断发现的问题。

有许多完全开源的监测系统(如Chukwa、Ganglia、Nagios及Ambari等)可以把Hadoop提供的各种指标和信息源整合起来,成为意义直观的面向服务的总结、图形以及警告,利用这些开源的监测系统可以提高你的监测经验。

2.3.1 用Chukwa监测Hadoop

Chukwa 是一个开源数据收集系统,用于监测和分析大型分布式系统。Chukwa构建于Hadoop之上,包含一个强大而灵活的工具集,用来监测、分析和观察结果。

Chukwa的许多组件采用了插件方式,支持轻松定制与功能增强。它提供了用于处理所收集数据的标准框架,其收集容量与分析容量可以扩展到几千个节点。

2.3.2 使用Ganglia监测Hadoop

Ganglia 初创于加利福尼亚大学伯克利分校,致力于提供一种可靠的资源消耗型计算集群性能监测解决方案。Ganglia可以监测成百上千个节点的集群。基本上,Ganglia收集每个受监测节点的CPU利用率和剩余磁盘空间等高阶变量。不仅如此,Ganglia还能监测发生故障的集群节点。

当前的Hadoop版本内置了对Ganglia(版本3.0+)的支持。它是一种高度可扩展的集群监测工具,提供单个集群、一组集群或者集群中某台机器的状态的图形化视图信息。

Hadoop上Ganglia的架构与实现支持集群联合体,可以监控联合体内每一集群内部的状态并对状态进行聚合。该架构包括Ganglia收集器(Ganglia Collector),Ganglia收集器运行监测守护进程并收集每个集群的性能指标,还运行一个元守护进程(meta daemon),用来聚合所有集群的性能指标。Ganglia收集器提供Web用户界面,展现内存使用情况、磁盘使用情况、网络统计、正在运行的进程以及其他性能指标的实时动态视图。

2.3.3 使用Nagios监测Hadoop

Nagios(http://www.nagios.org/)是一个流行的开源监测工具系统,主要用于高性能计算(High Performance Computing,HPC)和其他环境,设计目的是获取系统资源的性能指标。Nagios用来监测Hadoop集群资源以及应用程序和操作系统属性的状态,如CPU使用情况、磁盘空间及内存利用情况。

Nagios具有集成的内置通知系统,用来进行通知而不是系统性能指标的收集与跟踪。当前Nagios版本允许在目标主机上运行代理,并提供灵活、可定制的架构,用来收集有关Hadoop集群的状态的性能指标和信息数据。

Nagios用来提供以下几方面的监测信息。

  • 获取Hadoop基础设施组织的即时信息。
  • 系统故障时产生并接收警告。
  • 针对集群利用情况进行分析、报告并生成图形,对以后的硬件采购做出决策。
  • 检测问题并参加后续的问题解决。
  • 监测队列消耗情况,查找正在运行作业的节点的可用性。
时间: 2024-10-25 11:59:36

《Hadoop MapReduce性能优化》一2.3 性能监测工具的相关文章

SQL性能优化之定位网络性能问题的方法(DEMO)_MsSql

最近项目组同事跟我说遇到一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,很不科学.我帮了分析出了原因并得到解决.下面小编安装类似表结构,构造了一个案例,测试截图如下所示: 这个表有13800KB(也就是13M多大小),因为该表将图片保存到数据库(Item_Photo字段为iamge类型),这个是历史原因,暂且不喷这种的设计.看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,而是在网络数据传时间上(服务器与客户端位于异地,两地专线带宽6M,不过很多应

SQL性能优化之定位网络性能问题的方法(DEMO)

最近项目组同事跟我说遇到一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,很不科学.我帮了分析出了原因并得到解决.下面小编安装类似表结构,构造了一个案例,测试截图如下所示: 这个表有13800KB(也就是13M多大小),因为该表将图片保存到数据库(Item_Photo字段为iamge类型),这个是历史原因,暂且不喷这种的设计.看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,而是在网络数据传时间上(服务器与客户端位于异地,两地专线带宽6M,不过很多应

【性能优化】ORACLE数据库性能优化概述

   为了保证ORACLE数据库运行在最佳的性能状态下,在信息系统开发之前就应该考虑数据库的优化策略.优化策略一般包括服务器操作系统参数调整.ORACLE数据库参数调整.网络性能调整.应用程序SQL语句分析及设计等几个方面,其中应用程序的分析与设计是在信 分析评价ORACLE数据库性能主要有数据库吞吐量.数据库用户响应时间两项指标.数据库吞吐量是指单位时间内数据库完成的SQL语句数目:数据库用户响应时间是指用户从提交SQL语句开始到获得结果的那一段时间.数据库用户响应时间又可以分为系统服务时间和

Linux性能优化1.2 性能调查概要

1.2 性能调查概要 本节列出了开始性能调查时的几个重要步骤.由于终极目标是解决问题,因此最好的方法是在你接触性能工具之前就开始研究问题.遵循如下特定步骤是解决问题的有效方法,并且不会浪费宝贵的时间. 1.2.1 找到指标.基线和目标 性能调查的第一步就是确定当前的性能,并明确其应提升的程度.如果你的系统明显性能不佳,你就可以确定值得花时间进行研究.但是,如果系统性能接近其峰值,那么就不值得研究.明确性能峰值有助于你设置合理的性能期望值,并能给你一个性能目标,这样你就知道何时应该停止优化.你可能

教你怎样来优化Apache服务器的性能

apache|服务器|性能|优化 测试与提高性能 Apache服务器已经被设计得尽可能的快,即使你用一台配置不高的机器,用不着进行太复杂的设置,它的响应内容就足以塞满以前的各种窄带连接.但随网站内容日益复杂和带宽的增加,对Apache进行优化以取得更好的性能变得日益重要起来. 如果优化的结果仅仅是极小的性能提升那真是浪费时间.试想一下,你花了好几个小时甚至几天调整Apache的各种参数但结果仅是几个百分点的性能提升?因此,在优化前你做的第一步应该是测试你目前的服务器的性能水平以便决定如何优化你的

如何优化JavaScript脚本的性能

javascript|脚本|性能|优化 随着网络的发展,网速和机器速度的提高,越来越多的网站用到了丰富客户端技术.而现在Ajax则是最为流行的一种方式.JavaScript是一种解释型语言,所以能无法达到和C/Java之类的水平,限制了它能在客户端所做的事情,为了能改进他的性能,我想基于我以前给JavaScript做过的很多测试来谈谈自己的经验,希望能帮助大家改进自己的JavaScript脚本性能. 语言层次方面 循环 循环是很常用的一个控制结构,大部分东西要依靠它来完成,在JavaScript

JDBC学习笔记-jdbc性能优化

笔记|性能|优化 jdbc程序的性能主要由两个因素决定,一是数据库本身的性质,另一个是与数据库相对独立的jdbc应用程序接口(api)的使用.这里说的是如何正确使用jdbc编程接口,以获得更好的性能. jdbc主要优化有: 1.选择正确的jdbc驱动程序 2.Connention的优化 使用连接池来管理Connection对象 3.Statement的优化 使用批量更新等 4.Result的优化 正确的从数据库中get数据等 (1)选择正确的jdbc驱动程序: 1 jdbc-odbc 桥 2 本

Java 性能优化之 String 篇

String 在 JVM 的存储结构 一般而言,Java 对象在虚拟机的结构如下: 对象头(object header):8 个字节 Java 原始类型数据:如 int, float, char 等类型的数据,各类型数据占内存如 表 1. Java 各数据类型所占内存. 引用(reference):4 个字节 填充符(padding) 表 1. Java 各数据类型所占内存 然而,一个 Java 对象实际还会占用些额外的空间,如:对象的 class 信息.ID.在虚拟机中的状态.在 Oracle

C#性能优化实践

性能主要指两个方面:内存消耗和执行速度.性能优化简而言之,就是在不影响系统运行正确性的前提下 ,使之运行地更快,完成特定功能所需的时间更短. 本文以.NET平台下的控件产品MultiRow为例,描 述C#性能优化的实践. 性能优化原则 理解需求 MultiRow的一个性能需求是:"百万行 数据绑定下平滑滚动."整个MultiRow项目的开发过程一直在考虑这个目标. · 理解瓶颈 99%的性能消耗是由于1%的代码造成的.大部分性能优化都是针对这1%的瓶颈代码进行的.具体实施也 就分为两步

前端工程与性能优化之静态资源管理与模板框架

本系列文章从一个全新的视角来思考web性能优化与前端工程之间的关系,通过解读百度前端集成解 决方案小组(F.I.S)在打造高性能前端架构并统一百度40多条前端产品线的过程中所经历的技术尝试 ,揭示前端性能优化在前端架构及开发工具设计层面的实现思路. 在上一部分,我们介绍了静 态资源版本更新与缓存.今天的部分将会介绍静态资源管理与模板框架的用法. 静态资源管理与模板框架 让我们再来看看前面的优化原则表还剩些什么: 很不幸,剩下的优化原则都 不是使用工具就能很好实现的.或许有人会辩驳:"我用某某工具