今天收到线上的resource manager报警：
报错信息如下：
2014-07-0813:22:54,118INFOorg.apache.hadoop.yarn.util.AbstractLivelinessMonitor:Expired:xxxx:53356Timedoutafter600secs 2014-07-0813:22:54,118INFOorg.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl:DeactivatingNodexxxx:53356asitisnowLOST 2014-07-0813:22:54,118INFOorg.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl:xxxx:53356NodeTransitionedfromUNHEALTHYtoLOST 2014-07-0813:22:54,118FATALorg.apache.hadoop.yarn.server.resourcemanager.ResourceManager:ErrorinhandlingeventtypeNODE_REMOVEDtothescheduler java.lang.NullPointerException atorg.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.removeNode(FairScheduler.java:715) atorg.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.handle(FairScheduler.java:974) atorg.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.handle(FairScheduler.java:108) atorg.apache.hadoop.yarn.server.resourcemanager.ResourceManager$SchedulerEventDispatcher$EventProcessor.run(ResourceManager.java:378) atjava.lang.Thread.run(Thread.java:662) 2014-07-0813:22:54,118INFOorg.apache.hadoop.yarn.server.resourcemanager.ResourceManager:Exiting,bbye.. 2014-07-0813:22:54,119INFOorg.apache.hadoop.yarn.event.AsyncDispatcher:Sizeofevent-queueis1000 2014-07-0813:22:54,119INFOorg.apache.hadoop.yarn.event.AsyncDispatcher:Sizeofevent-queueis2000 |
这是一个bug，bug id：https://issues.apache.org/jira/browse/YARN-502
根据bug的描述，是在rm删除标记为UNHEALTHY的nm的时候可能会触发bug（第一次已经删除，后面删除再进行删除操作时就会报错）。
根据堆栈信息来看代码:
org.apache.hadoop.yarn.server.resourcemanager.scheduler.ResourceScheduler: protectedResourceSchedulerscheduler; privatefinalclassEventProcessorimplementsRunnable{//开启一个EventProcessor线程，对event进行处理 run(){ SchedulerEventevent; while(!stopped&&!Thread.currentThread().isInterrupted()){ event=eventQueue.take();//从eventqueue里面拿出event }catch(InterruptedExceptione){ LOG.error("Returning,interrupted:"+e); return;//TODO:KillRM. scheduler.handle(event);//处理event }catch(Throwablet){//cacheevent的异常 //Anerroroccurred,butweareshuttingdownanyway. //IfitwasanInterruptedException,theveryactof //shutdowncouldhavecauseditandisprobablyharmless. LOG.warn("Exceptionduringshutdown:",t); LOG.fatal("Errorinhandlingeventtype"+event.getType()//根据日志来看，这里获取的event.getType()为NODE_REMOVED +"tothescheduler",t); if(shouldExitOnError &&!ShutdownHookManager.get().isShutdownInProgress()){ LOG.info("Exiting,bbye.."); |
这里可以看到可以通过shouldExitOnError可以控制RM线程是否退出。
基于Apache+Tomcat负载均衡的两种实现方法 如果我们将工作在不同平台的apache能够实现彼此间的高效通信，因此它需要一种底层机制来实现--叫做apr
Apr的主要目的就是为了其能够让apache工作在不同的平台上，但在linux上安装apache的时候通常都是默认安装的
[root@node2 ~]#rpm -qi apr
Name :apr Relocations: (not relocatable)
Version :1.3.9 Vendor: CentOS
Release :5.el6_2 Build Date: Thu 14 Jun 2012 06:53:03 PM CST
Install Date: Fri 16 May 2014 07:11:23 PM CST Build Host:c6b5.bsys.dev.centos.org
Group :System Environment/Libraries Source RPM: apr-1.3.9-5.el6_2.src.rpm
Size :303205 License: ASL 2.0
Signature : RSA/SHA1,Thu 14 Jun 2012 08:27:12 PM CST, Key ID 0946fca2c105b9de
Packager :CentOS BuildSystem <http://bugs.centos.org>
URL http://apr.apache.org/
Summary :Apache Portable Runtime library
Description :
The mission of the Apache Portable Runtime (APR) is to provide a
free library of C data structures and routines, forming a system
portability layer to as many operating systems as possible,
including Unices, MS Win32, BeOS and OS/2.
Tomcat连接器架构：
基于Apache做为Tomcat前端的架构来讲，Apache通过mod_jk、mod_jk2或mod_proxy模块与后端的Tomcat进行数据交换。而对Tomcat来说，每个Web容器实例都有一个Java语言开发的连接器模块组件，在Tomcat6中，这个连接器是org.apache.catalina.Connector类。这个类的构造器可以构造两种类别的连接器：HTTP/1.1负责响应基于HTTP/HTTPS协议的请求，AJP/1.3负责响应基于AJP的请求。但可以简单地通过在server.xml配置文件中实现连接器的创建，但创建时所使用的类根据系统是支持APR(ApachePortable Runtime)而有所不同。
APR是附加在提供了通用和标准API的操作系统之上一个通讯层的本地库的集合，它能够为使用了APR的应用程序在与Apache通信时提供较好伸缩能力时带去平衡效用。
同时，需要说明的是，mod_jk2模块目前已经不再被支持了，mod_jk模块目前还apache被支持，但其项目活跃度已经大大降低。因此，目前更常用的方式是使用mod_proxy模块。如果支持APR：
1、HTTP/1.1：org.apache.coyote.http11.Http11AprProtocol
2、AJP/1.3：org.apache.coyote.ajp.AjpAprProtocol
不支持APR：
HTTP/1.1:org.apache.coyote.http11.Http11Protocol
AJP/1.3: org.apache.jk.server.JkCoyoteHandler
tomcat的运行方式
・standalone 独立运行的服务，使其本身就能接收web服务，而且能服务动态又能服务静态内容
在tomcat处理静态内容完全不亚于apache，因为如果必须将动静分割开来的话，至少可以降低动态请求的压力，在架构上是必须的，但tomcat本身的确是具有web服务响应能力的
而tomcat的连接器有多种类型，它的主要目的是服务于动态程序，所以我们是不应该让它直接面对用户的
・apache+tomcat 将节点分离，使apache接受请求而tomcat在后端进行动态请求处理
如果tomcat不直接面向客户端的话，而是只接受apache的请求，有种协议非常高效，叫做ajp，这种方式可以完全禁用tomcat的http连接器，而只启用ajp
这样用户是绝对不可能访问tomcat，由此所有的请求要想访问tomcat，必须先由apcahe代理，而apache是支持ajp协议的
这就是为什么很多场景都使用apache跟tomcat结合的原因
其好处是，tomcat不会直接面对用户，很多用户的连接进来的请求只能跟前端apache建立关系，如果支持长连接，但是这段时间又没请求新的内容，可以将这些连接当做非活动链接，非活动链接是不会被apache转向后端的，所以如果前端是长连接而后端使用的是ajp或http协议没有使用长连接方式，尤其是非活动请求都只到apache就停止活动，因此tomcat的资源就被释放出来
如果能够这样配置会更好：
静态内容都直接交给apache响应，而不会向后转发，动态内容则直接交给tomcat，这样就算使用nginx也可以
・tomcat+apache 都工作在独立主机上
如果跨主机的方式转发，网络延迟是不容忽视的，网络必然要有延迟的
如果在同台主机上，基于127.0.0.1作为转发地址的话，所有请求都会在内核中进行转发
内核最大带宽大概为10G左右甚至更高，内核通信间也是需要占用带宽的
那么问题又来了：
如何进行会话保持呢？如果是电商站点，很显然是必须要使用会话保持的
好在tomcat已经考虑到会话机制了，因此在tomcat中有很多内置会话管理器
tomcat会话管理器
・标准会话管理器(StandardManager)
有持久功能，比如tomcat已关机，会话是不会丢失的会将会话提前保存在磁盘中（定期保存），此后上线还会读取，但是突然崩溃会话一定会崩溃的
tomcat正常关闭，会话不会丢失，但是如果主机崩溃或者进程崩溃，会话一定会丢失
・持久会话管理器(PersistentManager)：
在进程关闭的的时候将会话保存在磁盘上，就算崩溃了也只是丢失一部分没有来得及同步的会话，其他已同步的会话依然可用 阅读更多内容
没有评论:
发表评论