- 综合排序
- 最热优先
- 最新优先
- 来自专栏后端码事
线上问题排查
jmap -histo pid | sort -n -r -k 2 | head -10
83810发布于 2020-09-10 - 来自专栏OSChina
线上问题排查
1 查看当前系统的cpu，内存占用情况 [root@localhost ~]# top 2 平均加载时间 [root@localhost ~]# uptime 16:45:18 up 18 day
94920发布于 2019-10-09 - 来自专栏简尚
聊聊「线上问题跟进」
注：这个系列，把整个「软件测试职业」的「做事」姿势，普及一遍；虽然阅读量不是很大，但老徐个人觉得能对大家有点价值； -- IDO老徐 线上问题跟进，看起来很简单，人人都会，其实非常难 。 而且，很多时候，是谎报（并不是问题 ）； 对于跟进线上问题，不同公司、不同业务结构的团队，流程会稍微有差异 。 回到正题， 跟进线上问题 ，之前老徐画过流程图 ，一般来说，用户反馈，由「线上客服接收」，然后做一轮基础判断，再把觉得是Bug的，反馈给「质量部 / 或 技术团队 」。 总之， 用户反馈 -》线上客服接收问题 -》做一轮初筛 -》反馈给 测试同学 -》测试同学复现，提交Bug -》反馈给开发同学，开发修复 -》测试同学验证 -》上线 -》客服通知用户 。 End ， 最后，补充： 1、Bug提的再多，抵不上一个漏测 ； 2、多分析线上每一个问题反馈；每个线上问题，都值得去思考、总结，为什么会漏 ？
1.3K30发布于 2020-10-19 - 来自专栏程序猿牧场
线上问题定位--OOM
服务器上部署了Java服务，出现了OutOfMemoryError，问题应该如何定位? 例如，某一台线上服务器的sshd进程PID是2820，查看 ll /proc/2820/fd ll /proc/2820/task
1.5K31编辑于 2023-01-17 - 来自专栏cywhat
Java线上问题排查
1、top 查看占用资源信息以及pid top 2、查看pid下绑定线程 top -Hp pid1(进程id) 3、拿到需要查询的线程pid,转换成16进制 printf '%x' pid2(线程id) ==> 6a4 #6a4为输出结果 4、通过jstack讲java信息输出到文本 jstack pid1(进程id) > t.txt 如果jstack报错,请查看 jstack不存在 5、在t.txt文件中查找6a4 vim t.txt /6a4 6、然后找到自己的collectorl业务代码层
52510编辑于 2022-11-22 - 来自专栏第三方工具
线上问题排查方法
线上问题排查方法 1 OOM问题 1.1 堆内存OOM 1.2 栈内存OOM 1.3 栈内存溢出 1.4 GC OOM 1.5 元空间OOM 2 CPU100%问题 3 接口超时问题 4 索引失效问题 5 死锁问题 6 磁盘问题 7 MQ消息积压问题 8 调用接口报错 8.1 返回401 8.2 返回403 8.3 返回404 8.4 返回405 8.5 返回500 8.6 返回502 OOM问题在生产环境中，一旦出现，一般会是非常严重的问题，服务可能会挂掉。 但是OOM问题有多种情况，不同的情况，出现问题的原因不一样。 一致性hash算法 分库：是为了解决数据库连接资源不足问题，和磁盘IO的性能瓶颈问题。 分表：是为了解决单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。
56110编辑于 2024-11-29 - 来自专栏温安适的blog
线上问题-关于@Async
问题日志 # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation 减少 JVM堆大小（-Xmx/-Xms） 减少线程数量 减少线程栈大小(-Xss) 6.设置大的code cache（-XX：ReservedCodeCacheSize=） 分析问题 org.springframework.scheduling.commonj.WorkManagerTaskExecutor */ @SuppressWarnings("serial") SimpleAsyncTaskExecutor 不复用线程，每次都新启动一个线程.与问题表现一致
68440编辑于 2022-01-10 - 来自专栏苏三说技术
线上问题排查指南
前言 最近经常有小伙伴问我，遇到了线上问题要如何快速排查。 这非常考验工作经验了。 有些问题你以前遇到，如果再遇到类似的问题，就能很快排查出导致问题的原因。 但如果某个问题你是第一次遇到，心中可能会有点无从下手的感觉。 这篇文章总结了，我之前遇到过的一些线上问题排查思路，希望对你会有所帮助。 1 OOM问题 OOM问题在生产环境中，一旦出现，一般会是非常严重的问题，服务可能会挂掉。 但是OOM问题有多种情况，不同的情况，出现问题的原因不一样。 2 CPU100%问题 线上服务出现CPU100%问题，也很常见。 出现这个问题，是由于服务长时间占用CPU资源导致的。 增加监控和分析 6 磁盘问题 服务器磁盘问题是众多线上问题中，最好排查的了。 磁盘问题一般有两种： 磁盘坏了 磁盘空间不足 如果是磁盘坏了，运维一般在短时间内，很难及时修复好。
81410编辑于 2024-08-14 - 来自专栏一直在努力的Java菜鸡er
线上问题排查总结
线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数；乐观锁 死循环----cpu飙高的问题；控制循环次数 云服务器redis被注入挖矿程序；端口像公网暴露；Redis端口不要被外网访问 中搜索是哪段代码出了问题。 Linux环境下排查cpu飙高的问题 先模拟一种死锁的情况，让cpu飙高 /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45 */ public Demo.java 模拟死循环让cpu飙升的代码 编译，运行 启动arthas分析哪个进程占用cpu高 [1]:序号 8781 Demo:进程号，项目名 通过arthas的命令分析cpu飙高的问题 进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题
43530编辑于 2022-09-08 - 来自专栏JavaEE
线上问题排查思路
若用户反馈线上服务请求无响应，可以按照以下步骤进行排查。 一、确认服务器内存使用情况 执行free命令，看看服务器内存是否正常。 7919 2106384 [B 7: 17131 1934896 java.lang.Class 如果这里看到有自己写的类对象，那可能就可以找到问题了 七、分析内存溢出问题 确定了是哪一个节点有问题，那么先把节点的流量切走。 如果第六步没分析出来是什么导致内存溢出，可以按如下步骤排查。 1. 勾上了会保留不可达对象； 点击 file ---> open heap dump，选择刚才的dump文件，等待几分钟，mat工具会生成一个默认的报告； 默认报告里会列出problems，点击details就可以看到问题详情 ，一般会列出有问题的对象； 选择有问题的对象，右键Merge Shortest Paths to GC Roots ---> exclude weak references； 然后再Java Basics
49830编辑于 2023-10-16 - 来自专栏架构师之路
线上操作与线上问题排查实战
技术同学需要经常登录线上的服务器进行操作，58到家架构部/运维部/58速运技术部，联合进行了一次线上操作与线上问题排查实战演练，同学们反馈有收获，特将实战演练的问题和答案公布出来，希望对大家也有帮助。 1.2.3.4' suyun.2017-06-26.log.bz2 | wc -l less suyun.2017-06-26.log.bz2 | grep '10.37.9.11' | wc -l 说明：线上日志文件一般以 /opt/backup/shenjian.tar.gz \ -exclude /opt/web/suyun_web/logs \ /opt/web/suyun_web 说明：这个命令线上应用较为频繁 四、查询线程数 问题：查询服务器运行服务的总线程数，当机器线程数超报警阀值时，能快速查出相关进程及线程信息。 六、显示文件，过滤注释 问题：显示server.conf 文件，屏蔽掉#号开头的注释行 参考答案： sed -n '/^[#]/!
1.1K40发布于 2018-03-02 - 来自专栏九州牧云
线上操作与线上问题排查实战
技术同学需要经常登录线上的服务器进行操作，58到家架构部/运维部/58速运技术部，联合进行了一次线上操作与线上问题排查实战演练，同学们反馈有收获，特将实战演练的问题和答案公布出来，希望对大家也有帮助。 suyun.2017-06-26.log.bz2 | wc -l less suyun.2017-06-26.log.bz2 | grep '10.37.9.11' | wc -l 说明：线上日志文件一般以 /opt/backup/shenjian.tar.gz \ -exclude /opt/web/suyun_web/logs \ /opt/web/suyun_web 说明：这个命令线上应用较为频繁 四、查询线程数 问题： 查询服务器运行服务的总线程数，当机器线程数超报警阀值时，能快速查出相关进程及线程信息。 转自：架构师之路——线上操作与线上问题排查实战
56220发布于 2019-08-21 - 来自专栏老张的求知思考世界
线上问题如何复盘？
昨天知识星球社群里有同学问了一个问题：线上问题如何复盘？从流程、分析和后续措施落地有哪些好的建议？ 从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。 关于线上问题，在具体的复盘实践中，一般归类为下面两种： 线上问题：生产环境出现了影响用户使用或者影响业务目标达成的问题，但未造成直接损失或影响； 线上故障：生产环境出现了影响用户使用或者影响业务目标达成的问题 无论是线上问题还是线上故障，其本质都是证明我们交付的软件系统存在不足。区别在于一个未造成直接损失和影响，另一个造成了业务的直接损失和影响。 从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。从团队管理的角度来说，针对线上问题进行复盘也可以发现团队短板并针对性的补齐技术体系，提高团队效率。 可以理解为记录问题是事前，问题复盘是事中，跟进优化是事后。 线上问题复盘的核心是什么呢？我个人认为最核心的因素是找到问题的原因并且确定问题得到有效的解决。
1.4K20编辑于 2023-03-01 - 来自专栏古时的风筝
线上问题排查神器 Arthas
线上问题排查神器 Arthas 之前介绍过 BTrace，线上问题排查神器 BTrace 的使用，也说它是线上问题排查神器。都是神器，但今天这个也很厉害，是不是更厉害不好说，但是使用起来非常简单。 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 心里在想，要是早知道它，之前就不用为了一个诡异的线上 bug 重复发包打日志了。 不管你现在用不用得上，都请记住它吧，相信我，迟早会用的上的。 正式交互开始，就到了大展拳脚的时候了，线上出现的问题基本上都可以找到合适的命令。 下面简单的介绍几个，就是为了演示一下使用方式。 另外，无论是 Arthas 还是 BTrace ，都是用来排查单机服务问题的，也就是应用内部的代码、性能问题，如果要排查不同服务之间的调用问题，那就是另一个维度上的事儿了。就需要 APM 的帮助了。
88930发布于 2019-09-29 - 来自专栏用户4352451的专栏
jvm线上内存问题排查
正在和同事在外面吃饭，突然钉钉报警，有一个服务的机器内存飙到百分之90%多。和同事大概聊了一下说是队列累积，机器消费不过来，具体原因也没有深问，又一同事，说看一下是那个对象占的内存，使用jmap，jstat。当时我也在旁边围观，由于之前有看过，我就说jmap在生产环境敢使用吗？
1.4K20发布于 2020-08-26 - 来自专栏温安适的blog
长事务引起线上问题
下面是该问题的排查过程。 查询该问题，进行复盘。 问题分析 当时给partner_XXX表 加索引， ALTER TABLE `partner_XXX` ADD INDEX `idx_point_id` (`point_id`); partner_XXX表，线上数据 4W, 空间25M，理论加索引时间，小于1s 是什么造成卡住的，查看阿里云 自治服务-> 一键诊断 > 自治中心->事务和锁快照 部分，如下图发现： 加索引的语句 幽灵事务的产生 IDEA 社区版本，Database Navigator 插件 多次执行show index，操作，并查看返回结果中的数据时，会开启事务，如下图 问题总结 首先，IDEA 社区版本，
46730编辑于 2022-05-05 - 来自专栏学习道路指南
如何排查线上问题的？
因此，快速、准确地排查并解决线上问题变得至关重要。 本文将介绍一些高效的线上问题排查方法，帮助您在面对线上问题时，迅速定位并解决问题。 通过这些策略的实施，您将能够提高线上问题的解决速度，减少对业务的影响，并提高用户满意度。 请继续阅读，以了解更多关于如何排查线上问题的详细信息。 本文是链式风格，循序渐进！ 一、预警层面 1.1 做好监控告警 如果线上出现了问题，我们更多的是希望由监控告警发现我们出了线上问题，而不是等到业务侧反馈。所以，我们需要对核心接口做好监控告警的功能。 2.2 回归最近的版本 因为线上大多数的问题都来源于系统的变更，可能我们只是变更了很少的代码，但只要有一丝的逻辑没留意到，就真的很可能会导致出现问题，回滚很可能是最快能恢复线上正常运行的办法。 通过问题定位、分析、解决和预防等步骤的实践经验总结出一些有效的排查方法。同时需要不断学习和提升自己的技能水平以更好地应对各种线上问题。
65110编辑于 2024-01-19 - 来自专栏艾小仙
可恶，又是个线上问题！
这几天，在搞 ShardingSphere，这不又来了一个问题嘛，启动的时候报了一个NPE出来。 好在，这个问题不影响使用，只是启动会报点错，接下来，又是辛苦的排查过程。 问题原因 上面我们已经定位到问题出现的地方，接下来就分析下为什么会出现这个问题呢？ 从源码看到，主要是在这个地方去加载数据库表的列的元数据信息。 这时候我想看下这个到底是为啥，于是打开本地 debug 看了一下没有任何问题，然后去测试环境上发现也没有问题，好像只有生产有这个问题。 排查 这个环境问题还挺恶心的，因为没有 TIDB 的环境，只能自己装一个了去想办法重现一下了（过程很费时间）。 好在 Mac 装这些东西还是很方便的，安装、刷新环境变量、启动。 文章写到这里，我还没想好怎么改，大概有 3 个方案： 完全去掉 TIDB 还用视图这离谱的操作，从根源上解决问题 按照这个方法，改成 Integer，就是不知道要改多少地方 不去加载视图的元数据，就可以避免这个问题了
38720编辑于 2022-12-05 - 来自专栏Java架构师必看
线上java JVM问题排查
作者：霞落满天 第一部分 是我以前公司的一则正式案例： 第二部分 是我另一个博客上写的主要是最近发现大家问的比较多就写了此文 第一部分 线上真实故障案例 下面是一个老系统，代码写的有点问题导致出现这样一个 JVM占比过高的问题，正常情况下也就是CPU负载不高的时候21:00左右的，也有30万，但是再多一点30几万就是阈值，就会出现堆积。 线上问题当时的CPU占用情况如图所示： ? 下面是当时java内存dump ? ? ? ? ? Java命令学习系列（3）：Jmap jmap查看堆内存大小 #jmap -heap pid 注意：jmap使用的时候jvm是处在停顿状态的，只能在服务不可用的时候为了解决问题来使用，否则会造成服务中断 这些都可以排除掉，而剩下的线程基本上就可以确认是我们要找的有问题的线程。通过其堆栈信息，我们就可以得出具体是在哪个位置的代码导致该线程处于等待状态了。 5.deadlock死锁这种情况基本上很容易发现
1.6K40发布于 2021-07-13 - 来自专栏架构进阶
并发编程系列：线上问题定位
系列文章： 并发编程系列：关于线程中断 并发编程系列：阻塞队列的实现原理 一 背景 大家都知道，在服务/应用发布到预览或者线上环境时，经常会出现一些测试中没有出现的问题。 并且由于环境所限，我们也不可能在线上调试代码，所以只能通过日志、系统信息和dump等手段来在线上定位问题。 根据经验，系统上发生的主要问题是在cpu、内存、磁盘几个方面，因此会优先针对这类问题进行定位。由于绝大部分服务都是部署在Linux环境下，所以一下以Linux命令为例进行说明。 、内存回收等问题的可能。 有时可能存在CPU利用率达到100%，如果出现这种情况，那么很有可能是代码中写了死循环，继续看代码定位问题原因。
72620发布于 2021-03-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号