- 综合排序
- 最热优先
- 最新优先
- 来自专栏爱明依
服务器cpu 爆满问题排查
找到 问题进程。 3 top -H -p pid 找到 进程对应的 线程数飘高的 线程Id 4 将线程Id 转换为16进制 printf “%x\d” 线程Id 5 jstack pid|grep tId -A90
3K31发布于 2020-10-26 - 来自专栏haifeiWu与他朋友们的专栏
测试环境服务器硬盘塞满问题排查
某天下午测试环境服务器出现tab无法补全命令，给出的提示大概意思就是说,无可用空间无法创建临时文件，不过这次跟上次出现的问题比较像，上次服务器出现的问题，因此楼主判断可能是服务器数据盘被占满，果不其然, 使用df -h命令看到服务器数据盘出现100%被占用的情况。 问题排查过程 楼主首先想到的是可以看到，linux系统中占用数据盘最大的文件，常情况下，最有可能找出占用磁盘空间文件或文件夹的地方，主要是 /tmp or /var or /home or /。 如果需要输出可读性更高的内容，请使用如下命令： du -hsx * | sort -rh | head -10 ok，到此为止问题华华丽丽的解决了，很开心哦。
71710发布于 2018-09-11 - 来自专栏数据小冰
死锁问题排查
既然已知道异常服务，那可以从这里入手进行分析，又与同事沟通一番，确定了与该服务相关的一些后台模块，接下来重点排查这些模块。 首先通过pprof抓取了这些模块的堆栈日志,Go提供了net/http/pprof和runtime/pprof两个包用于性能测评分析，前者通常用于web服务器的性能分析，后者通常用于普通代码的性能分析。 下面是出现问题的参考日志，关键点已包含其中，因为原日志不方便展示。 排查方法 日志中出现了sync. 问题本质 上面问题的根因是死锁导致的，死锁也是计算机中常见出现的问题。 l.order[lock A-lock B] l.order[lock A-lock C] l.order[lock B-lock C] 3.情形3：获取了锁但没有释放，会导致其他goroutine
1.5K10编辑于 2022-08-15 - 来自专栏云学习笔记
linux服务器性能问题相关排查手册（总结向）
最高的线程 1.在命令行输入top，然后shift+p查看占用CPU最高的进程，记下进程号 2.查看占用CPU最高的线程，并得到其16进制进程号 top -Hp 进程号 printf 0x%x 线程号 3. $2}' |xargs top -b -n1 -Hp | grep COMMAND -A1 | tail -n 1 | awk '{print $1}' | xargs printf 0x%x IO问题排查思路 mod=viewthread&tid=1805&highlight=%E7%B3%BB%E7%BB%9F%E7%9B%98%E6%BB%A1%E4%BA%86%E6%80%8E%E4%B9%88%E5% 注意：如果服务器中正在运行业务进程，kill 会直接终止进程，请慎重操作。 重启实例。重启实例系统会退出现有的进程，开机后重新加载，过程中会释放调用的 deleted 文件的句柄。 查看是否有异常内核模块，引用了其他文件，手册rmmod异常模块，查看df是否变化（容易被忽略） 常用性能排查工具介绍 uptime image.png top 实时CPU使用情况和进程信息 image.png
2.7K21发布于 2019-12-13 - 来自专栏dcmickey小站
排查Maven问题
排查Maven问题 mvn dependency:tree 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？ compile [INFO] \- org.hibernate:hibernate:jar:3.2.5.ga:compile [INFO] +- cglib:cglib:jar:2.1_3: （这一步非常重要哦，经常项目组pom.xml是相同的，但是就是有些人可以运行，有些人不能运行，俗称人品问题，其实都是IDE的缓存造成的了 idea清除缓存,为了提高效率不建议采用reimport重新起开启项目的方式
68020编辑于 2022-06-09 - 来自专栏后端码事
线上问题排查
3、查看gc情况 jstat -gc 进程pid ? 也可以加额外的参数循环输出：jstat -gc 进程pid 间隔时间 输出次数 ?
84010发布于 2020-09-10 - 来自专栏PHP开发者那些事
redis问题排查
当出现异常以后，可以从以下几个原因入手排查。 API或数据结构使用不合理 慢查询。命令slowlog get [n]。 1）使用了复杂读为O(n)的命令导致，如hgetall等。 CPU饱和的问题。 可以使用redis-cli -h{host} -p{port} --stat获取当前redis服务器的统计信息，再根据info command-stats统计信息分析命令的合理开销之处。 3）HugePage写操作阻塞。由于操作系统开启Transparent HugePages导致的副作用。 在redis的官方文档 中对常见阻塞有说明。 外在原因： CPU竞争 进程竞争。 内存交换 网络问题
55620发布于 2020-06-23 - 来自专栏OSChina
线上问题排查
[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 -----------memory---------- ---swap-- -----io---- -system -- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 1024 2612868 16 633524 0 0 3 16 3 5 12 6 81 0 0 1 0 1024 2612908 秒 2 10.61 0.00 5.56 0.00 0.00 0.51 0.00 0.00 0.00 83.33 17时14分48秒 3
95620发布于 2019-10-09 - 来自专栏技术实操
Linux运维必备：3个内存问题排查命令
前言Linux服务器如果出现程序突然卡得动不了，但是日志没报错，CPU也没跑满，这很有可能就是内存的问题。 只要掌握free、vmstat、sar这3个命令，就像给电脑做“体检”一样，几分钟就能定位问题所在。一、为什么要排查内存？内存就像服务器的“临时工作台”——程序运行时会把数据放到内存里，方便快速调用。 实际场景：找“内存+CPU+IO”的连环瓶颈比如某服务器用vmstat 5 3发现：swpd=1GB（备用仓库在用）、si=50KB/s（持续读备用仓库）、wa=25%（IO等得久）——说明内存不够，导致用备用仓库 ；小于10%说明紧张，需要进一步排查。 IO拖慢）——定位是纯内存问题，还是内存+CPU/IO的混合问题。
1.7K11编辑于 2025-09-29 - 来自专栏Linyb极客之路
linux服务器负载问题排查思路以及常用指令总结
最近在维护公司线上的服务器，排查了一些问题，所以做一个总结。有一段时间，线上环境变得很卡，客户端请求很多都报超时，因为线上没有良好的apm监控，所以只能通过流量高峰期和日志去排查问题。 通过排查，发现数据库的慢查询日志在比之间的暴涨了十倍，然后发现，memcache服务器（8核）负载很高，cpu一直在50%的左右，原因就是memcache服务器内存用完，导致内存的淘汰十分频繁，这样就导致很多请求落到数据库 下面说下主要的排查思路和用到的工具 服务的性能主要看的就是四大件：cpu、内存、磁盘、网络。排查过程的重要程度也是有重到轻。 如果是内存问题，则通过gc日志和jmap输出dump文件。 二、磁盘问题 磁盘问题在mysql服务器中非常常见，很多时候mysql服务器的CPU不高但是却出现慢查询日志飙升，就是因为磁盘出现了瓶颈。 三、网络问题 在线上服务器，大部分服务器都是只能内网访问，放在公网的服务器也就那几台nginx和ftp的，另外公网的那些服务器都有流量监控，所以网络问题一般并不大，不再详细说明，推荐一些工具，如果有需要可以对着查下
3.6K30发布于 2018-12-27 - 来自专栏北京马哥教育
Linux 服务器性能出问题，排查下这些参数指标
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。 CPU 占用率高很多情况下意味着一些东西，这也给服务器 CPU 使用率过高情况下指明了相应地排查思路： 当 user 占用率过高的时候，通常是某些个别的进程占用了大量的 CPU，这时候很容易通过 top 找到该程序；此时如果怀疑程序异常，可以通过 perf 等思路找出热点调用函数来进一步排查； 当 system 占用率过高的时候，如果 IO 操作(包括终端 IO)比较多，可能会造成这部分的 CPU 占用率高 ，比如在 file server、database server 等类型的服务器上，否则(比如>20%)很可能有些部分的内核、驱动模块有问题； 当 nice 占用率过高的时候，通常是有意行为，当进程的发起者知道某些进程占用较高的 大家都知道本地调试的时候喜欢使用 wireshark，但是线上服务端出现问题怎么弄呢？
2.2K61发布于 2018-05-02 Linux 服务器端口不可访问问题排查
问题描述 项目中使用的服务器是物理机，使用 centos 7.6 版本的操作系统， 4 个千兆网口，上架时间 23 年 8 月份。 但是从 10 月底开始，机器开始频繁性出现不可访问的问题，开始接入排查。 同机房同机柜还有其他 3 台服务器，ip 地址分别为 172.87.7.246，172.87.7.247，172.87.7.248。 DHCP 但是在排除上述可以排查的所有问题之后，我又把排查思路转义回到了这个问题上，并开始测试。这里使用的工具是 arp-scan。 最后想说的就是，一个耗费相当大精力排查的问题，不一定是复杂的问题，往往这个问题的产生原因是相关简单的。
2K10编辑于 2025-06-07- 来自专栏linux、Python学习
Linux 服务器性能出问题，排查下这些参数指标
一个基于 Linux 操作系统的服务器运行的同时，也会表征出各种各样参数信息。 CPU 占用率高很多情况下意味着一些东西，这也给服务器 CPU 使用率过高情况下指明了相应地排查思路： 当 user 占用率过高的时候，通常是某些个别的进程占用了大量的 CPU，这时候很容易通过 top 找到该程序；此时如果怀疑程序异常，可以通过 perf 等思路找出热点调用函数来进一步排查； 当 system 占用率过高的时候，如果 IO 操作(包括终端 IO)比较多，可能会造成这部分的 CPU 占用率高 ，比如在 file server、database server 等类型的服务器上，否则(比如>20%)很可能有些部分的内核、驱动模块有问题； 当 nice 占用率过高的时候，通常是有意行为，当进程的发起者知道某些进程占用较高的 大家都知道本地调试的时候喜欢使用 wireshark，但是线上服务端出现问题怎么弄呢？
1.9K40发布于 2019-06-05 - 来自专栏软件工程
线上服务器出现零星502的问题排查
这边咨询了下运维侧最近是否有什么变动或者解决方案，运维侧觉得是服务器资源问题，先直接给我们加了一倍的机器 但是观察后发现502少了但是问题还是没解决 1.2 网关两边链接保活时间不一致 我新功能上线的那一天的同时把我们的服务切到了 那么这时候就会产生一个现象：前50秒没有传输内容，在第51秒的时候，浏览器向nginx发了一个请求，这时候ka1还没有断掉，因为没有到100秒的时间，所以这是没有问题的，但是当nginx试图向应用服务器发请求的时候就出问题了 因为ka2的超时设置是50秒，这时候已经超了，所以就断了，这时候nginx无法再从应用服务器获得正确响应，只好返回浏览器502错误！ 但是我们根本就没有设置过这些参数啊，怎么会有这种问题呢？ 后面观察了几天，发现调整后服务器完全正常了，再也没出现过502； 三 总结 其实这次问题还是比较明显的 1.出现时机是新功能发布上线后 2.502的同时往往伴随着链接数的下降（先是系统充分预热，链接数全部激活了 ） 这次的盲点 盲点主要是不清楚运维侧代理把nginx换成了traefik，不然问题会更加明显，定位的更快些；
2.4K30编辑于 2022-06-08 - 来自专栏解Bug之路
日常问题排查-调用超时日常问题排查-调用超时
日常问题排查-调用超时 前言 日常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左右。 另外， 对于一个偶发性的问题，我们应该通过监控等手段去寻找规律，这样就很容易找到突破点。
1.5K30编辑于 2021-12-24 - 来自专栏Pou光明
手眼标定问题排查_圆网格数据排查
经过昨天晚上的调试，发现了一个主要问题：使用圆网格标定板标定时，不能使用cornerSubPix()函数，否则寻找角点时，会导致图一的情况(裁剪为30万像素)。就找到能参考的程序，推进还是很快的。 0.9895718596886195] 第2幅图像的平移向量： [7.823904018403115; -50.14423917119736; 453.4540216899545] 第3幅图像的旋转向量 Rodrigues ： [0.1622441852597525; 0.1859276514794853; 0.2367861820170687] 第3幅图像的旋转矩阵： [0.9551215908890158 0.9592045201131139, -0.1373011150301307; -0.1633023398839765, 0.1808987853474367, 0.9698494600958647] 第3幅图像的平移向量 下次把有问题的数据列下。 上面数据均未使用图片校准。 目前这个相机标定程序比较OK，至此棋盘格和圆网格两种标定板。有需要的同志可在公众号后台留言“改进的相机标定程序”。
35510编辑于 2024-04-13 - 来自专栏Windows技术交流
windows update问题排查
Get-WindowsUpdateLog执行报错的时候，可以拿日志C:\Windows\Logs\WindowsUpdate\ （压缩成.7z格式）到正常的系统使用Get-WindowsUpdateLog 加参数指定源和目标位置导出
91810编辑于 2024-08-21 - 来自专栏运维开发故事
Docker EOF问题排查
一、前言 问题排查过程，源码部分均由我的开发同事排查和记录；在征得其同意后，由我发表在此。 二、问题 某天接到客户反馈，pod的事件中出现大量的 warning event: Readiness probe failed: OCI runtime exec failed: exec failed 3、因为日志中显示 probe 类型为 Failure，因此 e.CombinedOutPut() 的 err ! 经过排查，发现 runc exec 在运行期间会读取 container 的 state.json，并使用 json decode 时出现异常。 ? 此时排查 runc EOF 和 kubelet cpu-manager update container(默认每 10s 更新一次) 的时间，发现时间点刚好吻合，验证猜想。
5.5K10发布于 2021-06-24 - 来自专栏linux
网络问题故障排查
网络问题故障排查 一、服务器网络卡慢 参考文档https://cloud.tencent.com/document/product/213/14633 1、检查本地访问域名速度 https://itango.tencent.com /huatuo) 2、检查ping指令是否ping通 ping ip地址/域名 3、检查端口情况 telnet ip地址 端口 4、使用nslookup查看DNS是否生效情况 nslookup 地址 5 、使用MTR分析网络延迟及丢包 https://cloud.tencent.com/document/product/213/14638 二、CDN网络访问故障 CDN网络故障原因排查https:// 是否生效以及是否需要刷新预热 https://cloud.tencent.com/document/product/228/56144 2、检查加速域名是否加速生效 nslookup qt=cname 加速域名 3、
34710编辑于 2025-07-04 - 来自专栏第三方工具
线上问题排查方法
线上问题排查方法 1 OOM问题 1.1 堆内存OOM 1.2 栈内存OOM 1.3 栈内存溢出 1.4 GC OOM 1.5 元空间OOM 2 CPU100%问题 3 接口超时问题 4 索引失效问题 如果生产环境中，出现了这个问题，可以排查一下递归调用是否正常，有可能出现了无限递归的情况。 5.增加监控和分析 6 磁盘问题 磁盘问题一般有两种： 磁盘坏了 磁盘空间不足 如果是磁盘空间不足。 一般需要登录到那台服务器， 使用命令： df -hl 查看当前服务器的磁盘使用情况。 这两种方式，一般会释放不少磁盘空间，暂时解决磁盘空间不足的问题。 从常用来看，我们需要对服务器的磁盘使用情况做监控，如果超过阀值有预警。 如果没有使用线程池，则只能临时增加服务器节点了。 如果MQ生产者没有批量发送消息，则需要排查MQ消费者的业务逻辑中，哪些地方出现了性能问题，需要做代码优化。
57810编辑于 2024-11-29
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号