一.项目架构 SpringCloud  Dalston.SR1 + SpringBoot 1.5.9 + Mysql +Redis + RabbitMQ 所有的业务模块的应用服务都部署在同一个服务器,且单实例部署,服务器配置4核32G, 二. 原因分析: 自己所负责的data模块这两天OOM较多,导致服务重启: data服务主要业务是报表相关,数仓对接的业务以及多个外部数据相关的小程序的后台,与数据库的交互比较多,业务逻辑相对其他模块较为简单, 第一次:2月25日OOM情况: 由于Redis反序…
排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo…
排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo…
在上周在的微供有数项目中(数据产品),需要对接企业微信中第三方应用,在使用Feign的去调用微服务的用户模块用微信的code获取access_token以及用户工厂信息时出现Feign重试超时报错的情况,通过此篇文章记录问题解决的过程. 一.问题重现: 1.SpringCloud部分依赖如下 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter…
昨天客户反馈业务系统很慢,而且偶尔报错. 查看nginx日志: [root@s2 nginx]# tail log/error.log 2017/03/14 12:54:46 [error] 17042#17042: *9305256418 upstream timed out (110: Connection timed out) while reading response header from upstream 看来是请求超时了.再查看nginx.conf配置,读取时间已经设置得比较长了…
记录CentOS 7.4 上安装MySQL&MariaDB&Redis&Mongodb 前段时间我个人Google服务器意外不能用,并且我犯了一件很低级的错误,直接在gcp讲服务器实例给释放掉,导致我的数据全部丢失,现在新搞一个服务器,顺便记录一下CentOS 7.4 MySQL&MariaDB&Redis&Mongodb 的安装 1祝大家:诸事顺利,2019 发大财! 本人将一如既往,更新我的博客,努力为博客园贡献文章! Mysql 安装 随着CentOS…
前些天线上除出了个OOM问题,今天闲下来记录下: OOM的提示信息是-PermGen space,说明问题出在方法区,方法区存的是什么东西?:类的加载信息.常量.静态变量. 按照方法区的定义:类加载的多了?常量.静态变量定义的多了? 我们项目中使用了Dubbo,大家知道因为Dubbo是通过动态代理的技术去动态生成调用类,与服务端通信的,动态生成的类多了,方法区内类的加载信息也就多了,所以就OOM了. 查看线上PermSize大小,用的默认的大小,大概80多M,增加配置:-xx:PermSize:…
中午的时候,我们生产上的某个数据库,cpu一直居高不下 通过例如以下的sql语句,我们查看当时数据库的等待,争用的情况: select s.SID, s.SERIAL#, 'kill -9 ' || p.SPID, s.MACHINE, s.OSUSER, s.PROGRAM, s.USERNAME, s.last_call_et, a.SQL_ID, s.LOGON_TIME, a.SQL_TEXT, a.SQL_FULLTEXT, w.EVENT, a.DISK_READS, a.BUFFE…
Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过日志输出错误信息: 得知websocket时时重新 连接的信息,然后找到原因 解决了. 当然这里幸好能通过日志大致分析出原因 那么我就在思考如果日志没有告诉任何信息 但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法…
记录一次线上bug,总的来说就是弱网和重复点击.特殊值校验的问题. 测试场景一:        在3g网络或者使页面加载速度需要两秒左右的时候,输入学号,提交学生的缴费项目,提交完一个 学生的缴费后,再输入另一个学号,这时候当前学生的信息还未显示完全,点击提交,就造成了前一个 学生的缴费数据和当前学生缴费数据的交叉. 通过浏览器的开发者工具(F12)模拟网速: 测试场景二:        特殊值校验,统计金额,前端将万元转换为元,数据为一些特殊值时,比如:0.69万元,页面上金额显示错误. 总结…