ons占用cpu资源较高的处理

昨天从湖南回到深圳,今天上班,心情不太好,有点想湖南老家的那个小家伙,唉。。。
 
一上班,同事就说有套10G rac的系统上,ons及tns进程占用了较多的系统资源,烦,心情不好事情还不少,上吧。。。
 
连接上两个节点,发现这两个进程在资源使用上都占了前两位,一头雾水,打开ons的log看,没有任何异常信息。
 
crs_stat -t 及srvctl status nodeapps -n rac02都正常。
 
苦恼。。。
 
试着用lsnrctl status看看,初看没看到问题,后来突然发现在listener的log文件名称显示上,没有显示节点的名称,怀疑
是开监听时,直接使用lsnrctl start开启,因此才出现问题。
 
试着分别使用srvctl stop listener -n rac01 和srvctl stop listener -n rac02来关闭两个节点监听器,然后再分别使用
srvctl start listener -n rac01    srvctl start listener -n rac02开启监听
 
再查看状态正常,使用top看资源占用,ons及tns进程不会再出现在最上面。
 
问题到此处理完。具体原理还需要查资料,或者各位大大给小弟讲讲,这里谢过。
 
后续rac的维护还是通过crs或者srvctl来比较好,避免使用单节点维护命令,以免再出现问题。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/110321/viewspace-616095/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/110321/viewspace-616095/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、MQ场景     1)订单异步解耦     2)解决分布式事务问题     3)应用于聊天平台     4)大规模机器的Cache同步     5)MySQL BinLog订阅数据分发 2、ONS应用场景     异步、解耦、最终一致、并行 3、设计假定     1)每台PC机器都可能down机不可服务     2)任意集群都可能处理能力不足     3)最坏情况一定会发生     4)内网环境需要低延迟来提供你最佳用户体验 4、关键设计     1)分布式集群化         a、理论上无限处理能力         b、集群级别可用     2)强数据安全         a、单机磁盘级别冗余         b、单组多队列级别冗余         c、多组消息队列冗余     3)海量数据堆积         a、推模式:订阅者逻辑简单         b、拉模式:关注吞吐量,快         c、推拉结合:队列通知消费者,消费者去拉取(两次交互)         d、阿里采用长连接和轮询:轮询去拉,有则拉取,无则保持长连接等待,直到有消息     4)毫秒级投递延迟 5、关键概念     1)Topic:第一级消息类型,主标题     2)Tug:第二级消息类型,分标题     3)发送组:生产者所在集群     4)订阅组:消费者所在集群     5)RocketMQ不是一对一,也不是一对多,是随机一对一     6)网络三种状态:成功、失败、没响应 6、消息乱序问题:Message服务器不处理,恰好不需要解决     1)发送时对消息进行编号     2)一组消息只有唯一一个订阅者处理(sharding)     3)一组消息的数量(即“锁的颗粒度”)越小越好 7、消息重复问题     1)重复原因:网络不可达     2)幂等:某个操作无论重复多少次,结果都一样(不需要解决,性能极)     3)非幂等,去重         a、保证有个唯一ID标记每一条消息;         b、保证消息处理成功与去重表日志同时出现     4)去重代价:额外的tps和qps 8、事务的分布式优化     1)事务1-->MQ Server-->事务2     2)同时成功,同时失败:         a、发消息;         b、执行事务1;         c、确认消息发送;         d、投递消息到消费者     3)处理超时问题(重复):事务2增加消息确认表(去重表)     4)消息失败(事务2失败):记录后人工处理(小概率事件)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值