腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

综合排序丨最热优先丨最新优先

Keepalived问题定位

此问题中忘记了另一个同事也在测HA的稳定性，发现他也在用同样的组播地址和虚拟路由id，我修改之后重启keepalived，完美解决。

2022-12-30

8690

标签:

RocketMQ 问题定位

问题背景与现象昨晚收到了应用报警，发现线上某个业务消费消息延迟了 54s 多（从消息发送到MQ 到被消费的间隔）： 2021-06-30T23:12:46.756 message processing 问题分析首先联想到的是，是否是消费线程卡住了呢？，我们来看看 RocketMQ 是否有什么问题。之前提到了，发送到这个 Topic 是指定了 hashKey 的，通过消息的 hashKey 我们可以定位到是哪个 broker： int hashCode = "我们的hashKey".hashCode 我们来查看 broker-2 上面的日志定位问题。

2021-12-18

9340

标签:

问题定位记录

JVM（HotSpot JVM）进行了优化。当第一次发生异常（通常为NullPointerException）时，将打印完整的堆栈跟踪，并且JVM会记住堆栈跟踪（或者可能只是代码的位置）。当该异常经常发生时，将不再打印堆栈跟踪，这既可以实现更好的性能，【CoederBaby】又不会使相同的堆栈跟踪充满日志。

2022-11-10

6210

标签:

问题定位的思考

领导同事都曾问到过，如果出现一个数据库问题，或者应用的问题，应该怎么快速定位该问题？这个问题很开放，同一个故障现象，可能不同人都会有不同的排查路径，但是殊途同归，能定位问题，解决问题，这才是关键，区别就在速度和准确性，有人1分钟定位，有人1小时定位，都可以解决，有人能找到问题的根因，有人歪打正着解决了问题其实这种有具体报错的问题，还是有很多线索可用的，最难的可能就是那些很隐秘的问题，例如应用执行慢，如果应用日志记录了具体操作的步骤和执行时间，我们就可能定位到某个逻辑，再判断是程序处理的问题，磁盘读写的问题《应用执行慢的定位案例》，就介绍了一种定位问题的思路，可以向程序增加一些断点，无论是要打印到控制台，还是应用日志，通过断点，逐步定位，其中需要注意的一点，就是断点的粒度，如果断点粒度很粗，很可能就无法精确定位借此机会，补充一些环节，同样的问题现象，原因可能不同，因此，对基础原理的理解和实践，对日常问题处理的积累，对相关知识点的融会贯通，都是提高我们定位和解决问题能力的重要途径。

2021-12-14

1.7K0

标签:

StackOverflowError 问题分析定位

= 1; i <= n; i++) { result *= i; } return result; }}上述代码将递归转换为迭代，避免了栈溢出的问题性能测试：通过性能测试，模拟高负载情况下的应用表现，及时发现潜在的栈溢出问题。监控和日志：实施实时监控和日志记录，一旦发生StackOverflowError，能够快速定位问题源头。结语StackOverflowError是Java开发中一个不可忽视的问题。通过本文的分析和指导，希望你能对这个问题有更深入的理解，并掌握避免它的策略。

2024-11-28

6580

标签:

线上问题定位--OOM

服务器上部署了Java服务，出现了OutOfMemoryError，问题应该如何定位?

2023-01-17

1.6K0

标签:

JVM 问题定位工具

熟悉 JDB 还是有价值的，很多情况下需要我们在命令行下完成简单的 debug 问题定位。总的来说，通常监控型的工具功能最强大，但是对系统资源要求也很高，对于生产环境上特有的问题，还是多考虑使用一些快照工具，内存和 CPU 占用小，系统中断时间短。

2022-07-15

6540

标签:

定位 | 常见问题

定位 1.腾讯位置服务在PC端测试过程中使用定位组件，一直显示定位中，没有地图显示？目前地图提供的组件只支持手机端使用，PC端无法使用H5定位组件。如何反馈 1.问题反馈的渠道入口： ① 点击本文末左下角“阅读原文”发帖反馈； ② 关注“腾讯位置服务”微信公众号，进入“帮助支持-> 论坛”发贴反馈； ③ 访问bbs.map.qq.com，进入“论坛

腾讯位置服务

2018-11-07

8630

标签:

“定位”那些事儿—sigkill定位爆内存问题

---- 导语：定位爆内存crash原因—iOS App性能中影响各位开发友人发量的重要问题，我们通过对QAPM上报的一例sigkill有效个例的分析,为大家提供一些思路。 ---- 问题背景在iOS App中，爆内存导致杀进程，一直是业界的难以定位的问题。通过iOS官方的工具Instruments->Allocations里的Heapshot功能来查找原因，不一定能定位到问题堆栈，还相当耗时。而QAPM-SIGKILL就能做到监控app爆内存场景，并且及时定位到问题关键堆栈信息，还能实时上报数据。通过以下相册管家（ios）案例来说明。 [图片2.png] 开发同学根据上报的堆栈信息结合代码分析，马上定位到了问题原因：对尺寸过大的图片进行解码时会导致爆内存。

硬骨见小鹿

2020-05-21

8K0

标签:

RocketMQ 问题定位方法

问题分析首先联想到的是，是否是消费线程卡住了呢？ Stop-the-world 的 safepoint 事件： image image 在这段时间，线程是 park 的，并且堆栈显示是消费线程并没有消息可以消费： image 既然应用并没有什么问题，我们来看看 RocketMQ 是否有什么问题。之前提到了，发送到这个 Topic 是指定了 hashKey 的，通过消息的 hashKey 我们可以定位到是哪个 broker： int hashCode = "我们的hashKey".hashCode 我们来查看 broker-2 上面的日志定位问题。

派大星在吗

2021-12-18

1.2K0

标签: