AngularJS 与jersey进行通讯备忘

DPA应用使用angular 的$http与Jersey的RESTFul接口进行ajax访问,之前一直比较顺畅,没出过什么问题。近日在**电信的计费库部署时发现,部分功能不能正常使用。检查jersey端输出: Apr 02, 2018 5:37:37 PM org.glassfish.jersey.server.ServerRuntime$Responder writeResponseSEVERE: An I/O error has occurred while writing a response message entity to the container output stream.org.glassfish.jersey.server.internal.process.MappableException: org.apache.catalina.connector.ClientAbortException: java.net.SocketException: Broken pipe (Write failed) at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:96 at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:149 at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1139 at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:574 at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:381 at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:371 at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:262 at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271 at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267 at org.glassfish.jersey.internal.Errors.process(Errors.java:315 at org.glassfish.jersey.internal.Errors.process(Errors.java:297 at org.glassfish.jersey.internal.Errors.process(Errors.java:267

DPA在电信计费系统故障诊断案例

3月20日中午,电信客户的计费系统故障,所有操作响应缓慢,应用无法正常运行。现场DBA已经迅速将应用连接转移到RAC集群的另一节点,恢复应用服务,我们使用DPA来回看事故现场,此时离故障发生,已经一小时了…… 回溯负载情况,如下图   问题最严重时,实例堵塞了近700个连接操作…针对此时间段,进一步点击、下钻分析当时系统发生了什么 系统先是每分钟4~5次堵塞(像是咳嗽),到了13:40后,就处于长时间“梗”住的状态,对于外部业务来说,数据库实例已不可用了。   利用DPA,继续下钻,查看堵塞原因: 1654#会话导致80个会话被堵塞,这80个会话的等待事件是 sga:allocation forcing component growth,这80个会话中的一些会话又堵塞了一些其他会话,如下图 266号会话堵塞了3个会话,这三个会话的等待事件都是cursor:pin s wait on x,这个等待事件一般都是跟sql parse相关,所以,现场工程师开始查看oracle 自己的ADDM报告,说是解析有问题,建议应用分析解决问题…被误导了   至此,DPA下钻后清晰显示,堵塞的根源是1654号会话,DPA显示是MMAN进程,它堵塞了80个会话,这些会话又堵塞了更多其他会话,是一个3级的堵塞关系,幸好DPA以“树型”显示方式,把这种多层级堵塞关系显示的非常清晰。 结论:Oracle MMAN进程进行过于频繁的SGA内存组件(本例中是share pool)resize操作,导致了问题…   这张图中显示的share pool内部情况,看官能看出异常么?   “划一条线1美元,知道在哪里划线9999美元”。 至此,后续我们如何解决这个问题的就不再讨论了,解决问题从来不是难事,难的是发现问题。 后记: 从DPA的负载雷达上,我们看到在系统出现问题之前的一小段时间内,系统负载不正常的降的很低,其后负载飙升上去…… 那段时间负载异常降低,说明了什么? 应用程序发生了什么…… 这些从Database Performance Analyzing层面,就无从知晓了。

在MAC平台编译安装遇到的问题

在Unix/Linux平台编译源代码安装软件遇到的问题 Changzheng-Hes-MacBook-Pro:rems2-3.4.7-new changzhenghe$ make installCDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/changzhenghe/tmp/rems2-3.4.7-new/missing aclocal-1.14 -I m4/Users/changzhenghe/tmp/rems2-3.4.7-new/missing: line 81: aclocal-1.14: command not foundWARNING: 'aclocal-1.14' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: http://www.gnu.org/software/automake It

量化感知一切IT设备: 使用脚本监控PDU

PDU: Power Distribution Unit 电源分配单元 在REMS2的实施过程中,我们遇到了这样的需求: 客户需要监控很多台PDU的指标,所使用的PDU有一个WEB访问接口,输入用户名和口令后可以进行PDU的远程操作和状态查看. PDU并没有SNMP服务之类功能. 该类型PDU能够提供4个监控指标: 电流,电压,功率,温度.思路: 在Script中模拟浏览器访问(模拟用户名口令输入,查看指标页面), 对于获取到的HTML代码使用python进行处理. 效果: $ ./mon_pdu.py -h   Usage: mon_pdu.py [options]     Options: -h, --help show this help message and exit -H HOST, --host=HOST pdu admin address -p PORT, --port=PORT pdu admin port -u USER, --user=USER pdu admin username -P PASSWORD, --passwd=PASSWORD pdu admin password

REMS2使用案例

庄总昨儿应某知名500强邀请,出去开了一天会议,今早一上班,赶紧看看一天不在,各系统是不是都还给力……     哎呦,上午10点20有情况,62个Active会话,客户们一定很着急,公司服务质量受影响,很严重啊 看看10:20那一会儿谁在造…… 还好,就10:29的时候,来了个高峰,过去了也就过去了…… 我得看看是谁在搞事,最近开发王经理彪呼呼的…… 哎呦,67%都是Application类别的堵塞啊,Application! 王大彪,我一会让你给我解释一下什么是Application…… 再瞅瞅具体什么原因造成的堵塞: 嗯,enq: TX - row lock contention ,这个字面意思就很清楚了,我百度一下…… 原来是“锁”等待啊,王大彪手下的那些个程序员,每天一下班我还没走就都跑了,怎么连数据库里基本的“锁”都管不好!! 这回SQL语句我都给你抓出来了,看你如何抵赖! 来,我们今儿就开个《关于如何提升应用代码质量、增强公司IT基础架构稳定性的会议》……

REMS2 无代理程序监控Tomcat 用户指南

对Tomcat Server做的调整 REMS2需要使用JMX协议,对Tomcat Server进行连接、获取Tomcat配置、运行时数据;为保障Tomcat Server的运行安全,严格禁止关闭Tomcat Server的JMX认证功能,REMS2 会在Tomcat上配置: 指定JMX连接的端口,默认9999,如果多个Tomcat运行在同一个服务器上,考虑使用不同的端口 创建configRole和monitorRole,并指定连接密码 操作步骤如下 : 修改<TOMCAT_SERVER>/bin/下的catalina.sh (如果是windows平台,则修改catalina.bat)脚本: 在 # ----- Execute The Requested Command ----------------------------------------- 行之前,添加如下代码: JAVAOPTS="-Djava.awt.headless=true -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=$CATALINABASE/conf/jmxpasswdfile -Dcom.sun.management.jmxremote.access.file=$CATALINABASE/conf/jmxaccessfile -Djava.rmi.server.hostname=192.168.0.11" 根据需要,调整port,调整hostname为tomcat服务器的IP地址。 在<TOMCAT_SERVER>/conf 下创建jmx_passwdfile和jmx_accessfile cat jmxaccessfile monitorRole readonly controlRole readwrite cat jmxpasswdfile monitorRole tomcat controlRole tomcat jmx_passwdfile文件中的tomcat,是连接Tomcat所需要的认证密码,可以根据需要修改。 完成修改后,需要重新启动Tomcat REMS2 中需要完成的配置 添加监控host 在host上应用template : Template Tomcat JMX

利用DPA诊断Oracle锁等待问题

10:50分左右,REMS2系统发出系统性能告警,1套RAC的Active Session数量超过了200……收到告警之后,甲方DBA专家进入战位,查找原因。可是——现在的Active Session数量已经恢复了,往事不可追啊……REMS2 DPA出场~查看故障时间段,Active Session变化情况: 大概从10:48左右,Active Session持续增高,到10:53之后,由大概200左右,迅速恢复正常。我们使用DPA的BST History功能模块,查看问题最严重时,系统的Active Session都在干什么…… 可以发现,多个会话,在执行SQL ID为appfxqvj6scuv的SQL,因为无法获取enq:TM而被堵塞,这些会话本身又堵塞了其他的会话。Oracle中,一个DML操作,除了会以独占模式持有行级别的TX锁外,还需要持有表级别TM锁的共享模式,以防止在DML过程中,表的结构定义被修改(关于Oracle Enqueue、Lock机制此处不做过多描述)。现在这些会话无法获取到共享模式的TM锁,那说明什么? 说明TM锁被别的会话以独占模式持有,还没有释放……到这里,已经很清晰了,有人在业务高峰时期做了DDL操作,那么是改了表结构、还是建了索引呢?使用DPA的Top SQL模块,检查一下该时间段的SQL操作,如果有DDL操作,应为肯定耗时较长,会被记录下来…… 再次轻松几分钟诊断故障原因! 哦耶

Oracle活动会话异常增高诊断-续

……之前我们利用DPA-Lite,已经定位到LGWR进程在特定时刻,堵塞了几十、上百个会话,导致Active Session数量在短时间内出现高峰……之后是各种分析、诊断…… 到底是IO性能出现问题,还是Commit量太大,导致LGWR出现延迟,却是一时间无法分辨。甚至,由于REDO LOG是放在高端存储的SSD上的,SSD有无问题…… 每次“故障”也不过就10秒,想精确定位问题何其困难!我们还是通过DPA-Lite来仔细检查,看看能不能找出一些端倪……5月10日,16时左右,问题再现: 此时间段内,Active Session高峰多次出现;16:06:56秒,LGWR堵塞了68个会话; 我们仔细看一看都堵塞了哪些会话,有何特点…… 特点是: HTZT用户,通过JDBC连接的应用,在等待Commit; 当前操作的对象ID都是 131629872和131629864 通过DPA-Lite查询另外一个时间点: 再次确认了这个现象!我们再看看更早之前发生Active Session高峰时的现象(5月8日16时): 仍然是HTZT用户操作OBJECT ID 131629872 131629864时等待Commit……我们查询数据库,确认这两个对象,发现是一张LOG(日志)表和该表上的一个索引,这个表以BLOB方式保存日志,目前数据量极大——超过300G。使用DPA-Lite 查看对应时间段的Top Object: 问题时间点,对于该表索引的操作,在数据库中占用资源排名第一! 存储已经用的最高端的了,解决问题就从这个日志表入手吧……日志么,都是用来事后查询、分析使用的,我觉得存在文件系统里,利用Hadoop之类分析是最好不过的,核心数据库高端存储上存个几百GB的日志,还弄出这种问题来,赶紧迁走……一想到拿着这些证据,一会儿让应用开发那帮哥们哑口无言我就觉得兴奋!