- 综合排序
- 最热优先
- 最新优先
- 来自专栏爱明依
服务器cpu 爆满问题排查
找到 问题进程。
3K31发布于 2020-10-26 - 来自专栏YP小站
K8S 问题排查：cgroup 内存泄露问题
3、因为3.10 的内核已经明确提示 kmem 是实验性质，我们仍然使用该特性，所以这其实不算内核的问题，是 k8s 兼容问题。 2、这个问题归根结底是软件兼容问题，3.x 自己都说了不成熟，不建议你使用该特性，k8s、docker却 还要开启这个属性，那就不是内核的责任，因为我们是云上机器，想替换4.x 内核需要虚机团队做足够的测试和评审 影响范围 k8s在 1.9版本开启了对 kmem 的支持，因此 1.9 以后的所有版本都有该问题，但必须搭配 3.x内核的机器才会出问题。 、docker 而言，kmem 属性属于正常迭代和优化，至于 3.x 的内核上存在 bug 不能兼容，不是k8s 关心的问题。 避免掉这个问题。
10.1K41发布于 2020-11-03 - 来自专栏haifeiWu与他朋友们的专栏
测试环境服务器硬盘塞满问题排查
某天下午测试环境服务器出现tab无法补全命令，给出的提示大概意思就是说,无可用空间无法创建临时文件，不过这次跟上次出现的问题比较像，上次服务器出现的问题，因此楼主判断可能是服务器数据盘被占满，果不其然, 使用df -h命令看到服务器数据盘出现100%被占用的情况。 问题排查过程 楼主首先想到的是可以看到，linux系统中占用数据盘最大的文件，常情况下，最有可能找出占用磁盘空间文件或文件夹的地方，主要是 /tmp or /var or /home or /。 如果需要输出可读性更高的内容，请使用如下命令： du -hsx * | sort -rh | head -10 ok，到此为止问题华华丽丽的解决了，很开心哦。
71710发布于 2018-09-11 - 来自专栏DevOps
通过 AI Agent 自动排查 K8s 问题
原文通过 AI Agent 自动排查 K8s 问题郭子龙 发表于 2025/11/18一、背景与痛点现状痛点（Dev & Ops）：研发：排查 K8s 问题需要熟悉 kubectl/日志命令，遇到 CrashLoopBackOff @机器人 排查告警信息。自动回复结构化诊断结论、建议和关键日志片段2. @机器人，提出任何k8s相关需求，如资源优化。3. @机器人 排查容器异常退出。 三、实现方式技术流程：能力覆盖：场景支持：Pod 异常、Node 状态、Service 网络、镜像拉取、调度失败等常见问题信息聚合：容器日志、K8s 事件、资源状态、配置信息、调度详情、网络连通性等关键排查数据一次性呈现核心能力 链路追踪）、资源变更历史与回滚建议、DBA 能力（慢查询分析、锁等待排查、索引优化建议等）、打造"一站式"运维助手，统一入口解决跨域问题。 Agent 能解决日常大部分琐碎问题，显著提高排查效率，但个别疑难杂症仍需人工介入 —— 它是第一道防线和效率工具，而非完全替代。
41610编辑于 2025-11-18 - 来自专栏数据小冰
死锁问题排查
既然已知道异常服务，那可以从这里入手进行分析，又与同事沟通一番，确定了与该服务相关的一些后台模块，接下来重点排查这些模块。 首先通过pprof抓取了这些模块的堆栈日志,Go提供了net/http/pprof和runtime/pprof两个包用于性能测评分析，前者通常用于web服务器的性能分析，后者通常用于普通代码的性能分析。 下面是出现问题的参考日志，关键点已包含其中，因为原日志不方便展示。 排查方法 日志中出现了sync. 问题本质 上面问题的根因是死锁导致的，死锁也是计算机中常见出现的问题。 往往改动代码引发的死锁问题比较容易出现，像本文中出现的问题就是代码改动导致的，添加功能需求的时候关注点集中在了业务逻辑上，容易忽视锁的问题。
1.5K10编辑于 2022-08-15 - 来自专栏云学习笔记
linux服务器性能问题相关排查手册（总结向）
$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% 8A%9E image.png 使用du命令可以查看具体目录或者文件的大小。 注意：如果服务器中正在运行业务进程，kill 会直接终止进程，请慎重操作。 重启实例。重启实例系统会退出现有的进程，开机后重新加载，过程中会释放调用的 deleted 文件的句柄。 查看是否有异常内核模块，引用了其他文件，手册rmmod异常模块，查看df是否变化（容易被忽略） 常用性能排查工具介绍 uptime image.png top 实时CPU使用情况和进程信息 image.png
2.7K21发布于 2019-12-13 - 来自专栏TKE
TKE操作指南 - TKE K8S问题排查（十八）
如果出现terminating状态的话，可以提供让容器专家进行排查，不建议直接强行删除，会可能导致一些业务上问题。 问题三：Pod 状态一直 Terminating，存在 Finalizers 问题描述：k8s 资源的 metadata 里如果存在 finalizers，那么该资源一般是由某程序创建的，并且在其创建的资源的 code = Unknown desc = failed to create a sandbox for pod "apigateway-6dc48bf8b6-l8xrw": Error response 可以在 pod 里 telnet 一下 dns 的 53 端口 # telnet 172.16.1.2 53 //连 dns service 的 cluster ip 如果检查到是网络不通，就需要排查下网络设置 解决方案：更正 service 的 targetPort 问题二十二：服务不能被访问，k8s 支持 ipvs 的 bug 问题描述：node上直接访问pod能通，访问 service 不行且集群开启了
6.5K20发布于 2019-08-14 - 来自专栏dcmickey小站
排查Maven问题
排查Maven问题 mvn dependency:tree 三大技巧 第一板斧:找到传递依赖的鬼出在哪里？ } return result.toString(); } } 随便写一个测试，设置好断点，在执行到断点处按alt+F8动态执行代码 （这一步非常重要哦，经常项目组pom.xml是相同的，但是就是有些人可以运行，有些人不能运行，俗称人品问题，其实都是IDE的缓存造成的了 idea清除缓存,为了提高效率不建议采用reimport重新起开启项目的方式
68020编辑于 2022-06-09 - 来自专栏后端码事
线上问题排查
8、old区实例查询： jmap -histo pid | sort -n -r -k 2 | head -10 ?
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统计信息分析命令的合理开销之处。 内存交换 网络问题
55620发布于 2020-06-23 - 来自专栏OSChina
线上问题排查
4565 2582 265 587 2581 Swap: 7935 1 7934 8
95620发布于 2019-10-09 - 来自专栏Linyb极客之路
linux服务器负载问题排查思路以及常用指令总结
最近在维护公司线上的服务器，排查了一些问题，所以做一个总结。有一段时间，线上环境变得很卡，客户端请求很多都报超时，因为线上没有良好的apm监控，所以只能通过流量高峰期和日志去排查问题。 通过排查，发现数据库的慢查询日志在比之间的暴涨了十倍，然后发现，memcache服务器（8核）负载很高，cpu一直在50%的左右，原因就是memcache服务器内存用完，导致内存的淘汰十分频繁，这样就导致很多请求落到数据库 也就是说如果你是8核，那么这个数字小于等于8的负载都是没问题的，我看网上的建议一般这个值不要超过ncpu*2-2为好。 如果是内存问题，则通过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 网关两边链接保活时间不一致 我新功能上线的那一天的同时把我们的服务切到了 K8s下，运维侧对那边服务架构做了比较大的调整，对于代理这块，以前使用的是nginx，现在改用了traefik，我们知道在用了代理的情况下，其实客户端和服务器并不是直接交互建立连接的，而是客户端请求交给代理 那么这时候就会产生一个现象：前50秒没有传输内容，在第51秒的时候，浏览器向nginx发了一个请求，这时候ka1还没有断掉，因为没有到100秒的时间，所以这是没有问题的，但是当nginx试图向应用服务器发请求的时候就出问题了 因为ka2的超时设置是50秒，这时候已经超了，所以就断了，这时候nginx无法再从应用服务器获得正确响应，只好返回浏览器502错误！ 但是我们根本就没有设置过这些参数啊，怎么会有这种问题呢？ 后面观察了几天，发现调整后服务器完全正常了，再也没出现过502； 三 总结 其实这次问题还是比较明显的 1.出现时机是新功能发布上线后 2.502的同时往往伴随着链接数的下降（先是系统充分预热，链接数全部激活了
2.4K30编辑于 2022-06-08 - 来自专栏解Bug之路
日常问题排查-调用超时日常问题排查-调用超时
日常问题排查-调用超时 前言 日常Bug排查系列都是一些简单Bug排查，笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材^_^。 Bug现场 这次的Bug是大家喜闻乐见的调用超时。 B系统在将近8s后才收到请求，也就是说B系统还没开始处理，A系统就超时了。 开始排查 那么这5秒钟时间到底消失在哪里呢？ 于是笔者，就尝试着搜索了一下 https://blogs.oracle.com/poonam/long-class-unloading-pauses-with-jdk8 发现，官方也发现了这个问题，并给予了解释 为什么会有swap 实际上对应机器的内存使用率并不高，一共8G的内存，JVM只占用到了4G左右。但swap的逻辑并仅仅是内存吃紧了才使用swap分区。 所以看上去是概率上出现GC慢的问题。 另一个机房没出问题 这时候巧的是，业务开发向笔者反映，另一个机房的相同应用确不会出现此问题。捞了下对应日志，发现其class unloading只有0.9s左右。
1.5K30编辑于 2021-12-24 - 来自专栏Pou光明
手眼标定问题排查_圆网格数据排查
经过昨天晚上的调试，发现了一个主要问题：使用圆网格标定板标定时，不能使用cornerSubPix()函数，否则寻找角点时，会导致图一的情况(裁剪为30万像素)。就找到能参考的程序，推进还是很快的。 下次把有问题的数据列下。 上面数据均未使用图片校准。 目前这个相机标定程序比较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 三、环境 特别说明：客户在负责运行业务的k8s节点上坚持开启了cpu-manager 组件 版本 k8s 1.14.x 四、排查 1、接到客户反馈后，检查该pod所在节点的kubelet日志，如下 from a closed fifo" time="2021-05-06T16:51:40.170676532+08:00" level=error msg="Error running exec 8e34e8b910694abe95a467b2936b37635fdabd2f7b7c464d 经过排查，发现 runc exec 在运行期间会读取 container 的 state.json，并使用 json decode 时出现异常。 ?
5.5K10发布于 2021-06-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号