- 综合排序
- 最热优先
- 最新优先
- 来自专栏kl的专栏
j2Cache线上异常问题排查记录
问题背景 开发反馈，线上有个服务在运行一段时间后，就会抛异常导致redis缓存不可用。 (Pool.java:49) ... 3 more j2Cache:红薯开源的2阶段缓存框架：https://gitee.com/ld/J2Cache 问题分析 从异常日志表象上看，很明显是由于jedis 小心求证 通过对问题的假设，我们需要在程序中找到从jedis pool中获取资源的代码，那首先需要找到初始化连接池的地方，j2Cache里是通过RedisCacheProvider来维护jedis pool 重新假设 如果不是连接泄漏导致的，那么肯定是并发问题了，最终的异常是j2Cache抛出来的，从j2Cache里获取连接的地方如下： 可以看到最上面红框里的是之前说的有问题，其实没有问题，他们都被包在了try 最终解决 设置连接池的maxTotal参数即可，但是有个问题是，这个项目使用的j2Cache的版本比较老，代码的配置信息限定死了就那么个几个，而且没有预留maxTotal的设置。
63530编辑于 2023-11-18 - 来自专栏后端码事
线上问题排查
2、找到线程pid top -Hp 进程pid ? 快捷键“R”进行排序，可以通过快捷键“H”查看帮助信息。 快捷键“1” 查看每个cpu使用情况： ? 8、old区实例查询： jmap -histo pid | sort -n -r -k 2 | head -10 ?
93110发布于 2020-09-10 - 来自专栏OSChina
线上问题排查
1 查看当前系统的cpu，内存占用情况 [root@localhost ~]# top 2 平均加载时间 [root@localhost ~]# uptime 16:45:18 up 18 days , 45 min, 4 users, load average: 0.03, 0.20, 0.64 3 查看cpu [root@localhost ~]# vmstat -n 2 3 procs - 633616 0 0 0 10 2846 9886 10 7 83 0 0 4 查看cpu核信息 [root@localhost ~]# mpstat -P ALL 2 秒 1 10.10 0.00 6.06 0.00 0.00 0.00 0.00 0.00 0.00 83.84 17时14分48秒 2 00:00:39 java -jar insight-iec-server-1.0.jar 5 root 6976 22153 0 17:30 pts/2 00:00:00 grep
1K20发布于 2019-10-09 - 来自专栏程序猿牧场
线上问题定位--OOM
服务器上部署了Java服务，出现了OutOfMemoryError，问题应该如何定位? 例如，某一台线上服务器的sshd进程PID是2820，查看 ll /proc/2820/fd ll /proc/2820/task
1.6K31编辑于 2023-01-17 - 来自专栏简尚
聊聊「线上问题跟进」
而且，很多时候，是谎报（并不是问题 ）； 对于跟进线上问题，不同公司、不同业务结构的团队，流程会稍微有差异 。 回到正题， 跟进线上问题 ，之前老徐画过流程图 ，一般来说，用户反馈，由「线上客服接收」，然后做一轮基础判断，再把觉得是Bug的，反馈给「质量部 / 或 技术团队 」。 测试同学，收到问题后，根据问题描述，去梳理、分类： 1）Bug 2）操作 3）需求 4）外部原因 等 。 对于是Bug的，如何复现 ？如何跟进 ？开发解决后，如何验证 ？ End ， 最后，补充： 1、Bug提的再多，抵不上一个漏测 ； 2、多分析线上每一个问题反馈；每个线上问题，都值得去思考、总结，为什么会漏 ？ 2、很多公司，各种流程都是不完整的，比较乱；各种乱 ； 要学会在已有的资源下，高效解决问题 ，提升自己的能力 ； 每个公司，都或多或少，有各种乱七八糟的问题 ； 接受 / 改变 / 离开 ； / 加油
1.4K30发布于 2020-10-19 - 来自专栏cywhat
Java线上问题排查
1、top 查看占用资源信息以及pid top 2、查看pid下绑定线程 top -Hp pid1(进程id) 3、拿到需要查询的线程pid,转换成16进制 printf '%x' pid2(线程id)
57310编辑于 2022-11-22 - 来自专栏第三方工具
线上问题排查方法
线上问题排查方法 1 OOM问题 1.1 堆内存OOM 1.2 栈内存OOM 1.3 栈内存溢出 1.4 GC OOM 1.5 元空间OOM 2 CPU100%问题 3 接口超时问题 4 索引失效问题 OOM异常演示 https://www.cnblogs.com/oktokeep/p/18205280 2 CPU100%问题 3 接口超时问题 4 索引失效问题 我们可以通过explain关键字，查看 2.循环等待：事务之间形成了一种互相等待对方释放资源的循环关系。 3.不当的事务设计：事务执行顺序不合理、执行时间过长等。 5.索引使用不当：如果索引设计不合理，可能导致事务在获取锁时出现问题。 如何减少死锁问题？ 1.设置合理的事务隔离级别。 2.避免大事务的业务代码。 3.优化sql性能。 4.增加锁等待超时处理。 2.然后找到日志文件，删除7天以前的日志。 这两种方式，一般会释放不少磁盘空间，暂时解决磁盘空间不足的问题。 从常用来看，我们需要对服务器的磁盘使用情况做监控，如果超过阀值有预警。
78210编辑于 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 不复用线程，每次都新启动一个线程.与问题表现一致 2.
75940编辑于 2022-01-10 - 来自专栏苏三说技术
线上问题排查指南
前言 最近经常有小伙伴问我，遇到了线上问题要如何快速排查。 这非常考验工作经验了。 有些问题你以前遇到，如果再遇到类似的问题，就能很快排查出导致问题的原因。 但如果某个问题你是第一次遇到，心中可能会有点无从下手的感觉。 这篇文章总结了，我之前遇到过的一些线上问题排查思路，希望对你会有所帮助。 2 CPU100%问题 线上服务出现CPU100%问题，也很常见。 出现这个问题，是由于服务长时间占用CPU资源导致的。 增加监控和分析 6 磁盘问题 服务器磁盘问题是众多线上问题中，最好排查的了。 磁盘问题一般有两种： 磁盘坏了 磁盘空间不足 如果是磁盘坏了，运维一般在短时间内，很难及时修复好。 比如有些接口名称改了，或者接口路径中/v1/user/query改成了/v2/user/query，版本号升级了。 如果没有通知所有的接口调用方，都可能会出现请求接口返回码为404的情况。
1.2K10编辑于 2024-08-14 - 来自专栏JavaEE
线上问题排查思路
若用户反馈线上服务请求无响应，可以按照以下步骤进行排查。 一、确认服务器内存使用情况 执行free命令，看看服务器内存是否正常。 268435456 (256.0MB) OldSize = 268435456 (256.0MB) NewRatio = 2 七、分析内存溢出问题 确定了是哪一个节点有问题，那么先把节点的流量切走。 如果第六步没分析出来是什么导致内存溢出，可以按如下步骤排查。 1. 导出dump文件 jmap -dump:format=b,live,file=<fileName>.hprof <pid> 执行该命令，可以导出名为fileName.hprof的dump文件 2. ，一般会列出有问题的对象； 选择有问题的对象，右键Merge Shortest Paths to GC Roots ---> exclude weak references； 然后再Java Basics
58030编辑于 2023-10-16 - 来自专栏一直在努力的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飙高的问题 进程号改变是因为我又重启了程序 通过打印出的信息可以在代码中搜索晓果冻线程名来查询到底是哪段代码出了问题
48730编辑于 2022-09-08 - 来自专栏架构师之路
线上操作与线上问题排查实战
技术同学需要经常登录线上的服务器进行操作，58到家架构部/运维部/58速运技术部，联合进行了一次线上操作与线上问题排查实战演练，同学们反馈有收获，特将实战演练的问题和答案公布出来，希望对大家也有帮助。 二、从已经备份好的日志中查询数据 问题：从已备份的suyun.2017-06-26.log.bz2日志中，找出包含关键字1.2.3.4的日志有多少条。 参考答案： bzcat suyun.2017-06-26.log.bz2 | grep '1.2.3.4' | wc -l bzgrep '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 说明：线上日志文件一般以bz2 压缩之后保留，如果解压查询，非常耗空间与时间 /opt/backup/shenjian.tar.gz \ -exclude /opt/web/suyun_web/logs \ /opt/web/suyun_web 说明：这个命令线上应用较为频繁
1.2K40发布于 2018-03-02 - 来自专栏九州牧云
线上操作与线上问题排查实战
技术同学需要经常登录线上的服务器进行操作，58到家架构部/运维部/58速运技术部，联合进行了一次线上操作与线上问题排查实战演练，同学们反馈有收获，特将实战演练的问题和答案公布出来，希望对大家也有帮助。 二、从已经备份好的日志中查询数据 问题：从已备份的suyun.2017-06-26.log.bz2日志中，找出包含关键字1.2.3.4的日志有多少条。 参考答案： bzcat suyun.2017-06-26.log.bz2 | grep '1.2.3.4' | wc -l bzgrep '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 说明：线上日志文件一般以bz2 压缩之后保留，如果解压查询 转自：架构师之路——线上操作与线上问题排查实战
62520发布于 2019-08-21 - 来自专栏老张的求知思考世界
线上问题如何复盘？
昨天知识星球社群里有同学问了一个问题：线上问题如何复盘？从流程、分析和后续措施落地有哪些好的建议？ 从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。 关于线上问题，在具体的复盘实践中，一般归类为下面两种： 线上问题：生产环境出现了影响用户使用或者影响业务目标达成的问题，但未造成直接损失或影响； 线上故障：生产环境出现了影响用户使用或者影响业务目标达成的问题 无论是线上问题还是线上故障，其本质都是证明我们交付的软件系统存在不足。区别在于一个未造成直接损失和影响，另一个造成了业务的直接损失和影响。 从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。从团队管理的角度来说，针对线上问题进行复盘也可以发现团队短板并针对性的补齐技术体系，提高团队效率。 可以理解为记录问题是事前，问题复盘是事中，跟进优化是事后。 线上问题复盘的核心是什么呢？我个人认为最核心的因素是找到问题的原因并且确定问题得到有效的解决。
1.5K20编辑于 2023-03-01 - 来自专栏用户4352451的专栏
jvm线上内存问题排查
2. jstat (JVM statistics Monitoring Tool)是用于监视虚拟机各种运行状态信息的命令行工具他可以显示本地或者远程虚拟机进程中的类装载，内存，垃圾收集，JIT编译等运行数据
1.4K20发布于 2020-08-26 - 来自专栏古时的风筝
线上问题排查神器 Arthas
线上问题排查神器 Arthas 之前介绍过 BTrace，线上问题排查神器 BTrace 的使用，也说它是线上问题排查神器。都是神器，但今天这个也很厉害，是不是更厉害不好说，但是使用起来非常简单。 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ Found existing java process, please choose one and hit RETURN. * [1]: 95301 org.kite.CmApplication [2] 正式交互开始，就到了大展拳脚的时候了，线上出现的问题基本上都可以找到合适的命令。 下面简单的介绍几个，就是为了演示一下使用方式。 另外，无论是 Arthas 还是 BTrace ，都是用来排查单机服务问题的，也就是应用内部的代码、性能问题，如果要排查不同服务之间的调用问题，那就是另一个维度上的事儿了。就需要 APM 的帮助了。
95430发布于 2019-09-29 - 来自专栏温安适的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 社区版本，
53230编辑于 2022-05-05 - 来自专栏学习道路指南
如何排查线上问题的？
因此，快速、准确地排查并解决线上问题变得至关重要。 本文将介绍一些高效的线上问题排查方法，帮助您在面对线上问题时，迅速定位并解决问题。 通过这些策略的实施，您将能够提高线上问题的解决速度，减少对业务的影响，并提高用户满意度。 请继续阅读，以了解更多关于如何排查线上问题的详细信息。 本文是链式风格，循序渐进！ 一、预警层面 1.1 做好监控告警 如果线上出现了问题，我们更多的是希望由监控告警发现我们出了线上问题，而不是等到业务侧反馈。所以，我们需要对核心接口做好监控告警的功能。 2.2 回归最近的版本 因为线上大多数的问题都来源于系统的变更，可能我们只是变更了很少的代码，但只要有一丝的逻辑没留意到，就真的很可能会导致出现问题，回滚很可能是最快能恢复线上正常运行的办法。 通过问题定位、分析、解决和预防等步骤的实践经验总结出一些有效的排查方法。同时需要不断学习和提升自己的技能水平以更好地应对各种线上问题。
78110编辑于 2024-01-19 - 来自专栏艾小仙
可恶，又是个线上问题！
这几天，在搞 ShardingSphere，这不又来了一个问题嘛，启动的时候报了一个NPE出来。 好在，这个问题不影响使用，只是启动会报点错，接下来，又是辛苦的排查过程。 问题原因 上面我们已经定位到问题出现的地方，接下来就分析下为什么会出现这个问题呢？ 从源码看到，主要是在这个地方去加载数据库表的列的元数据信息。 这时候我想看下这个到底是为啥，于是打开本地 debug 看了一下没有任何问题，然后去测试环境上发现也没有问题，好像只有生产有这个问题。 1. curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh 2. source ${ 文章写到这里，我还没想好怎么改，大概有 3 个方案： 完全去掉 TIDB 还用视图这离谱的操作，从根源上解决问题 按照这个方法，改成 Integer，就是不知道要改多少地方 不去加载视图的元数据，就可以避免这个问题了
42820编辑于 2022-12-05 - 来自专栏Java架构师必看
线上java JVM问题排查
作者：霞落满天 第一部分 是我以前公司的一则正式案例： 第二部分 是我另一个博客上写的主要是最近发现大家问的比较多就写了此文 第一部分 线上真实故障案例 下面是一个老系统，代码写的有点问题导致出现这样一个 JVM占比过高的问题，正常情况下也就是CPU负载不高的时候21:00左右的，也有30万，但是再多一点30几万就是阈值，就会出现堆积。 2、 建议查看一下dump文件中的线程消耗CPU情况， a、可能是有线程在不停的循环造成的CPU过高； b、 gc线程不停回收造成？ 线上问题当时的CPU占用情况如图所示： ? top+jstack分析cpu过高原因 1.jstack #jstack -l pid > jstack.log 使用jstack命令输出这一时刻的线程栈 jstack线程分析 jstack日志深入理解 2. 种原因、及解决办法 面试官问：平时碰到系统CPU飙高和频繁GC，你会怎么排查【评判标准】 1.如果是Full GC次数过多，那么通过jstack得到的线程信息会是类似于VM Thread之类的线程； 2.
1.7K40发布于 2021-07-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号