首页
Python
Java
IOS
Andorid
NodeJS
JavaScript
HTML5
【
记录一次线上OOM调优经历
】的更多相关文章
记录一次线上OOM调优经历
现状: k8s 的一个pod 有32G内存,每秒产生新对象的峰值在900Mb ---- 1900Mb(根据jstat计算Eden区获得) . 修改之前的参数 就一个命令行参数是-Xmx31g; 我修改为: -Xms:30g -Xmx:30g -Xmn:15g -XX:SurvivorRatio=6 以上目的是为了减少年轻代GC频率(由6秒1次 增加到10+秒一次),让Queue队列中的大对象在to区停留的更长.同时,由于队列的大对象紧到不死,通常存活的对象空间就>to区(s0.s1)空间,被移到…
纪一次线上cms调优
过去也有对JAVA性能调优的分析,有过以下case: 1. JVM outOfMemory, 主要是使用jmap dump 出来 hprof,使用MAT进行分析 2. JVM outOfMemory, 使用jmap dump 出来hprof, 使用jhat 找出异常内存对象 3. JVM调优,程序运行1个月后崩溃 4. JVM调优,根据JFR 采样,分析性能消耗在哪里,如何优化高频的性能消耗. 等等其他(如 多线程竞争锁导致的性能下降等). 这次的case 比较有意思,所以记录下来. 先描述本次…
记一次令人窒息的线上fullgc调优
今天第二篇采坑了... ... 现场因为处理太急促没有保留,而且是一旁协助,没有收集到所有信息实在是有些遗憾...只能靠记忆回想一些细节 情况是一台服务器一启动就开始full gc,短短1分钟可以有几十次的full gc. 主要几个配置参数为-Xmx2g -XX:NewRatio=3(CMS相关和其他的和这次无关不列了) 很简单的参数. 下意识dump了heap,结果并没什么特别明显的问题. 在想是不是内存不够,加到3g还是一样的问题. 那似乎只能看是不是业务代码有内存泄漏了. 用jmap -h…
MySQL慢查询优化(线上案例调优)
文章说明 这篇文章主要是记录自己最近在真实工作中遇到的慢查询的案例,然后进行调优分析的过程,欢迎大家一起讨论调优经验.(以下出现的表名,列名都是化名,实际数据也进行过一点微调.) PS:最近做了一个面试题精选精答的开源项目,如果想要了解更多MySQL相关的技术总结,可以看一看,如果对大家有帮助,希望大家帮忙给一个star,谢谢大家了! <面试指北>项目地址:https://github.com/NotFound9/interviewGuide 一.复杂的深分页问题优化 背景 有一个articl…
记一次线上gc调优的过程
近期公司运营同学经常表示线上我们一个后台管理系统运行特别慢,而且经常出现504超时的情况.对于这种情况我们本能的认为可能是代码有性能问题,可能有死循环或者是数据库调用次数过多导致接口运行过慢.应领导要求,我们将主站中进行性能测试的框架代码(见我前面一篇博文记录一次通过性能日志处理线上性能问题的过程)添加到了该后台管理系统中.上线运行一段时间后,查看相关日志可以看到如下分析日志: 通过该日志可以发现,dao方法一直获取不到数据库链接池,但是根据实际情况考虑应该不大可能,…
一次线上OOM故障排查经过
转贴:http://my.oschina.net/flashsword/blog/205266 本文是一次线上OOM故障排查的经过,内容比较基础但是真实,主要是记录一下,没有OOM排查经验的同学也可以参考. 现象 我们之前有一个计算作业.最近经常出现不稳定,无法正常响应的情况.具体表现是:各种连接超时,从mysql.mongodb和zookeeper到netty,能超时的都超时过了.其他看不到太多有效的异常. 所以我们首先怀疑的是网络问题,打电话跟运维确认,运维说网络问题的可能性几乎为0,因为我…
【转】又一次线上 OOM 排查经过
又一次线上OOM排查经过 最近线上一个服务又出现了频繁Full GC的情况,导致提供的业务经常超时.问题出现非常不稳定,经过两周的时候,终于又捕捉到了一次Full GC,于是联系运维做Heap Dump之后,经过一系列分析,终于解决问题.这次的问题稍微复杂一点,但是也比较有代表性,用到了VisualVM和MAT两个工具,继续记录如下. 现象 这次使用公司的CAT监控平台看到的内存表现如下: 可以看到,具体表现是: 在很长一段时间内(数个小时),New GC比较频繁,Full GC较少(一小时个位…
Linux(2)---记录一次线上服务 CPU 100%的排查过程
Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过日志输出错误信息: 得知websocket时时重新 连接的信息,然后找到原因 解决了. 当然这里幸好能通过日志大致分析出原因 那么我就在思考如果日志没有告诉任何信息 但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法…
记录一次线上bug
记录一次线上bug,总的来说就是弱网和重复点击.特殊值校验的问题. 测试场景一: 在3g网络或者使页面加载速度需要两秒左右的时候,输入学号,提交学生的缴费项目,提交完一个 学生的缴费后,再输入另一个学号,这时候当前学生的信息还未显示完全,点击提交,就造成了前一个 学生的缴费数据和当前学生缴费数据的交叉. 通过浏览器的开发者工具(F12)模拟网速: 测试场景二: 特殊值校验,统计金额,前端将万元转换为元,数据为一些特殊值时,比如:0.69万元,页面上金额显示错误. 总结…
火山引擎MARS-APM Plus x 飞书 |降低线上OOM,提高App性能稳定性
通过使用火山引擎MARS-APM Plus的memory graph功能,飞书研发团队有效分析定位问题线上case多达30例,线上OOM率降低到了0.8‰,降幅达到60%.大幅提升了用户体验,为飞书的性能品质保驾护航. 应用程序稳定性是影响用户体验及留存的关键因素 对于移动App的开发者来说,最基础也是最关注的问题就是应用程序的稳定性.而崩溃问题是影响稳定性的重要因素, 包括NSException.Signal.卡死.OOM(Out Of Memory)等问题类型.其中,OOM问题是随着业务的迭…