：一般这种是同一个实例调用了多次start方法导致的。...：一般这种原因是调用了shutdown方法后，又调用了start。...一般我们惯性思维觉得是没问题的，其实rocketmq中producer和consumer的初始化过程是：初始化+ start、shutdown。...原因很多， 这里例举常见的问题：客户端访问Broker网络不通这种情况客户端处理不了，最好找服务维护人员发送到Broker报错可能的问题和分析处理：在确定可以ping通Broker后，一般Broker报错会有错误信息...以上是生产报错， 下一篇我们分享消费失败的问题排查方式。生产耗时比较大怎么定位？https://cloud.tencent.com/developer/article/2192667
找到 问题进程。
某天下午测试环境服务器出现tab无法补全命令，给出的提示大概意思就是说,无可用空间无法创建临时文件，不过这次跟上次出现的问题比较像，上次服务器出现的问题，因此楼主判断可能是服务器数据盘被占满，果不其然,...使用df -h命令看到服务器数据盘出现100%被占用的情况。...问题排查过程 楼主首先想到的是可以看到，linux系统中占用数据盘最大的文件，常情况下，最有可能找出占用磁盘空间文件或文件夹的地方，主要是 /tmp or /var or /home or /。...如果需要输出可读性更高的内容，请使用如下命令： du -hsx * | sort -rh | head -10 ok，到此为止问题华华丽丽的解决了，很开心哦。...一般情况下查看某一端口的占用情况的用法是： lsof -i:端口号 例如查看80端口的使用情况 lsof -i:80 COMMAND PID USER FD TYPE DEVICE SIZE
既然已知道异常服务，那可以从这里入手进行分析，又与同事沟通一番，确定了与该服务相关的一些后台模块，接下来重点排查这些模块。...首先通过pprof抓取了这些模块的堆栈日志,Go提供了net/http/pprof和runtime/pprof两个包用于性能测评分析，前者通常用于web服务器的性能分析，后者通常用于普通代码的性能分析。...下面是出现问题的参考日志，关键点已包含其中，因为原日志不方便展示。 排查方法 日志中出现了sync....问题本质 上面问题的根因是死锁导致的，死锁也是计算机中常见出现的问题。...codereview 通过代码评审，有经验的工程师对代码进行review之后，一些比较明显的存在死锁代码逻辑是容易发现的，当然有些逻辑隐藏的比较深，一般很难发现。
排查Maven问题 mvn dependency:tree 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？...（这一步非常重要哦，经常项目组pom.xml是相同的，但是就是有些人可以运行，有些人不能运行，俗称人品问题，其实都是IDE的缓存造成的了 idea清除缓存,为了提高效率不建议采用reimport重新起开启项目的方式
当出现异常以后，可以从以下几个原因入手排查。 API或数据结构使用不合理 慢查询。命令slowlog get [n]。 1）使用了复杂读为O(n)的命令导致，如hgetall等。...CPU饱和的问题。...可以使用redis-cli -h{host} -p{port} --stat获取当前redis服务器的统计信息，再根据info command-stats统计信息分析命令的合理开销之处。...内存交换 网络问题
1 查看当前系统的cpu，内存占用情况 [root@localhost ~]# top 2 平均加载时间 [root@localhost ~]# uptime...
jmap -histo pid | sort -n -r -k 2 | head -10
问题 客户端访问服务器时提示一下报错： 描述为Redis报错，连接不了Redis。...排查 进入服务器终端，由于使用的是FinalShell界面中就已经提示了磁盘已经满了的状态，所以基本可以确定为因为磁盘满了导致的。...解决 到这里就已经找到罪魁祸首了，由于服务器磁盘太小，而gitlab一直在输出日志占用了太多的磁盘空间，由于服务器中的gitlab不是我搭建的，不知道是否有用，只能暂时把服务停掉删掉日志文件。...最后重启Redis服务和数据库服务，服务恢复，问题解决。
如果单块磁盘的队列长度持续超过2，一般认为该磁盘存在I/O性能问题。...出现此种情况，很可能是系统中存在大量进程处于D的状态，也就是不可中断的睡眠状态，这一般是由于硬件问题导致的。...$2}' |xargs top -b -n1 -Hp | grep COMMAND -A1 | tail -n 1 | awk '{print $1}' | xargs printf 0x%x IO问题排查思路...注意：如果服务器中正在运行业务进程，kill 会直接终止进程，请慎重操作。 重启实例。重启实例系统会退出现有的进程，开机后重新加载，过程中会释放调用的 deleted 文件的句柄。...查看是否有异常内核模块，引用了其他文件，手册rmmod异常模块，查看df是否变化（容易被忽略） 常用性能排查工具介绍 uptime image.png top 实时CPU使用情况和进程信息 image.png
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。...CPU 占用率高很多情况下意味着一些东西，这也给服务器 CPU 使用率过高情况下指明了相应地排查思路： 当 user 占用率过高的时候，通常是某些个别的进程占用了大量的 CPU，这时候很容易通过 top...找到该程序；此时如果怀疑程序异常，可以通过 perf 等思路找出热点调用函数来进一步排查； 当 system 占用率过高的时候，如果 IO 操作(包括终端 IO)比较多，可能会造成这部分的 CPU 占用率高...，比如在 file server、database server 等类型的服务器上，否则(比如>20%)很可能有些部分的内核、驱动模块有问题； 当 nice 占用率过高的时候，通常是有意行为，当进程的发起者知道某些进程占用较高的...睡眠的进程数目；swpd 表示使用到的虚拟内存数量，跟 top-Swap-used 的数值是一个含义，而如手册所说，通常情况下 buffers 数目要比 cached Mem 小的多，buffers 一般
最近在维护公司线上的服务器，排查了一些问题，所以做一个总结。有一段时间，线上环境变得很卡，客户端请求很多都报超时，因为线上没有良好的apm监控，所以只能通过流量高峰期和日志去排查问题。...通过排查，发现数据库的慢查询日志在比之间的暴涨了十倍，然后发现，memcache服务器（8核）负载很高，cpu一直在50%的左右，原因就是memcache服务器内存用完，导致内存的淘汰十分频繁，这样就导致很多请求落到数据库...典型问题 java应用出问题一般都是内存和cpu的问题，像cpu飙高，内存不够等是通过这些来发现。...如果是内存问题，则通过gc日志和jmap输出dump文件。 二、磁盘问题 磁盘问题在mysql服务器中非常常见，很多时候mysql服务器的CPU不高但是却出现慢查询日志飙升，就是因为磁盘出现了瓶颈。...三、网络问题 在线上服务器，大部分服务器都是只能内网访问，放在公网的服务器也就那几台nginx和ftp的，另外公网的那些服务器都有流量监控，所以网络问题一般并不大，不再详细说明，推荐一些工具，如果有需要可以对着查下
我看了下，确实是每次出现502基本都是出现在群发任务调度比较多的情况，但是我在我们日志系统并没有发现成规模的其他报错，另外服务器资源有波动但是也没那么大的波动，因为我们这一般申请服务器资源比较容易，都是做了一定的富余的...这边咨询了下运维侧最近是否有什么变动或者解决方案，运维侧觉得是服务器资源问题，先直接给我们加了一倍的机器 但是观察后发现502少了但是问题还是没解决 1.2 网关两边链接保活时间不一致 我新功能上线的那一天的同时把我们的服务切到了...那么这时候就会产生一个现象：前50秒没有传输内容，在第51秒的时候，浏览器向nginx发了一个请求，这时候ka1还没有断掉，因为没有到100秒的时间，所以这是没有问题的，但是当nginx试图向应用服务器发请求的时候就出问题了...因为ka2的超时设置是50秒，这时候已经超了，所以就断了，这时候nginx无法再从应用服务器获得正确响应，只好返回浏览器502错误！ 但是我们根本就没有设置过这些参数啊，怎么会有这种问题呢？...后面观察了几天，发现调整后服务器完全正常了，再也没出现过502； 三 总结 其实这次问题还是比较明显的 1.出现时机是新功能发布上线后 2.502的同时往往伴随着链接数的下降（先是系统充分预热，链接数全部激活了
经过昨天晚上的调试，发现了一个主要问题：使用圆网格标定板标定时，不能使用cornerSubPix()函数，否则寻找角点时，会导致图一的情况(裁剪为30万像素)。就找到能参考的程序，推进还是很快的。...下次把有问题的数据列下。 上面数据均未使用图片校准。 目前这个相机标定程序比较OK，至此棋盘格和圆网格两种标定板。有需要的同志可在公众号后台留言“改进的相机标定程序”。
日常问题排查-调用超时 前言 日常Bug排查系列都是一些简单Bug排查，笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材^_^。 Bug现场 这次的Bug是大家喜闻乐见的调用超时。...开始排查 那么这5秒钟时间到底消失在哪里呢？有3个可能的点: 1)A日志打点到真正发出请求包 2)网络上 3)B真正接收请求包到B日志打点。...可是这又引入了一个新的问题，为什么一次Full GC能达到6s之巨。 为什么这么慢 观察监控，笔者发现Full GC有时候快有时候慢。翻出对应6s的那条gc监控日志。...所以看上去是概率上出现GC慢的问题。 另一个机房没出问题 这时候巧的是，业务开发向笔者反映，另一个机房的相同应用确不会出现此问题。捞了下对应日志，发现其class unloading只有0.9s左右。...另外， 对于一个偶发性的问题，我们应该通过监控等手段去寻找规律，这样就很容易找到突破点。
一、前言 问题排查过程，源码部分均由我的开发同事排查和记录；在征得其同意后，由我发表在此。...二、问题 某天接到客户反馈，pod的事件中出现大量的 warning event: Readiness probe failed: OCI runtime exec failed: exec failed...三、环境 特别说明：客户在负责运行业务的k8s节点上坚持开启了cpu-manager 组件 版本 k8s 1.14.x 四、排查 1、接到客户反馈后，检查该pod所在节点的kubelet日志，如下...经过排查，发现 runc exec 在运行期间会读取 container 的 state.json，并使用 json decode 时出现异常。 ?...此时排查 runc EOF 和 kubelet cpu-manager update container(默认每 10s 更新一次) 的时间，发现时间点刚好吻合，验证猜想。
1、top 查看占用资源信息以及pid top 2、查看pid下绑定线程 top -Hp pid1(进程id) 3、拿到需要查询的线程pid,转换成16进制 p...
查看宿主状态时提示 ‘container runtime is down’ ，根据经验，此时一般就是容器运行时出了问题。...2.重启kubelet变更宿主状态 kubelet重启后宿主状态从Ready变为NotReady，这个问题相较docker hang死而言，没有那么复杂，所以我们先排查这个问题。...因此单纯依赖协程调用链路定位问题这条路被堵死了。 截至目前，我们已经收集了部分关键信息，同时也将问题排查范围更进一步地缩小在containerd-shim与runc之间。...接下来我们换一种思路继续排查。 3.2 进程排查 当组件的运行状态无法继续获取时，我们转换一下思维，获取容器的运行状态，也即异常容器此时的进程状态。...后续 docker hang死的原因远非这一种，本次排查的结果也并非适用于所有场景。希望各位看官能够根据自己的现场排查问题。
1.8 网络问题排查 在NAT模式下变成为桥接模式（右下角，网络适配器） 桥接模式下的方框，不用去选择，打钩。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
