系统异常排查思路

最新推荐文章于 2024-07-27 11:51:32 发布
原创 最新推荐文章于 2024-07-27 11:51:32 发布 · 1.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

目录

        1、查看机器的cpu、内存、磁盘、网络等问题

2、日志分析

3、dump文件分析

 

nginx 日志 、tomcat日志、应用日志等

 

C++软件调试与异常排查技术从入门到精通学习路线分享
dvlinker的技术专栏
12-17 6万+
详细讲述C++软件调试与异常排查技术从入门到精通学习路线。
【C++软件调试技术】C++软件开发维护过程中典型软件异常问题的排查与总结
dvlinker的技术专栏
04-15 17万+
本文以问答的方式进行展开，罗列了C++软件日常开发和维护中遇到的多个软件调试问题及有代表性的场景，给出详细的处置思路和处理办法，以供大家借鉴和参考。
系统问题排查思路
weixin_30906671的博客
06-10 274
一、确定CPU是否有问题 首先看cpu 有没有问题要先看负载，如果负载高，用vmstat看r和b，队列排队的情况 再结合CPU使用率，看用户还是系统cpu 高 1、用户高，看具体哪个用户的应用进程导致的高，再找出那个线程导致的高，然后是线程栈，找到具体的方法 2、系统高，看中断和io ，如果是io导致的看读和写，读大概是内存问题，如果是写，大概是写日志，写数据...
故障排查思路
weixin_34307464的博客
03-04 311
为什么80%的码农都做不了架构师？>>> ...
系统问题排查
weixin_30312557的博客
07-24 207
1. thread dump方案 kill -3 pid 执行后文件的保存路径为：/proc/${pid}/cwd jstack pid pstack pid profiler top -Hp pid 查看进程的线程资源占用情况（printf "%x\n" id 将十进制转换为16进制） 2. javacore与heapdump 为了能够保留Java应用发生致...
故障排除的思路及见解
u012516914的专栏
01-27 1134
正常运行的代码总会出现问题，而且总会以出乎你意料的方式表现出来。代码的正常运行只不过是不正常的一种特殊情况，不正常反而是常态。之所以把问题归结为不可能的玄学问题或者偶现事件，是因为问题超出...
【转载】 由简单密码引发的血案
weixin_33937913的博客
07-30 177
正在努力板砖，一阵急促的电话铃想起，同事紧急告知，论坛访问很慢，其它技术人员已经折腾了半天找不到原因，需要尽快处理。 首先简单了解了一些情况，运营的同事说前几天有管理员帐号被泄漏（咋泄漏的？设置简单密码，真像把后备箱那块砖拿过去拍他），被人用工具自动发帖，好家伙，一晚上发了上万个帖子。上午在qq群里看他们聊天，说费了很多时间才把这些垃圾...
C++软件调试与异常排查从入门到精通专栏介绍与文章汇总
热门推荐
dvlinker的技术专栏
06-29 22万+
根据近几年排查软件异常的实践与经验，系统地讲解了C++软件异常常见原因与常用排查方法，以图文并茂的方式给出具体的分析实例，带领大家逐步掌握C++软件异常排查的相关技术与要领。
排查C++软件异常的常见思路与方法（实战经验总结）
dvlinker的技术专栏
07-27 4449
排查C++软件异常的常见思路与方法（实战经验总结）
两例典型的C++软件异常排查实例分享
dvlinker的技术专栏
10-24 9396
两例典型的C++软件异常崩溃问题详细分析
系统故障排查
m0_55834564的博客
08-16 564
无法正常进系统时，用来执行修复操作的应急环境−提供独立的Shell环境，拥有root权限−能够自动检测并挂载故障系统（/mnt/sysimage/）
系统问题排查定位流程
在青海看海的企鹅的博客
01-21 5291
在分析故障原因时，通常可从一个或一系列症状入手，对它们进行跟踪以发现问题发生的原因。如果是一系列症状，也必须选定其中的一个作为切入点。切入点，一定是要那种可以量化的东西，而不能是“也许”、“估计”、“负荷高”这类的字眼。换句话说，出现这些字眼，表示问题没有辅证。寻找问题中，错误日志即是一种简单易行、快速有效的手段，通过查看错误日志往往能一针见血地迅速解决问题。换句话说，能直接通过业务的程序日志定位问题的，就不要麻烦全面排查的方式。
线上问题排查的四类方法
xiexiaojing的博客
08-14 1853
最正统的方法日志这是排查问题的最常用的方法，需要预估自己每日日志量和需要存储的日志时间。申请磁盘空间时一般会留35%的冗余以备突发流量。一...
捕捉异常出现异常排查思路
黄金黄不黄的博客
11-27 225
如果出现try catch捕捉不到的情况.: 首先看你捕捉的是什么异常. 而具体抛出的是什么异常.是否能对应上,大包小.Exception按理说都能捕捉.
Linux系统的排查思路
weixin_43467082的博客
03-14 572
处理linux系统故障的思路： 1.重视错误提示信息。 2.查阅日志文件 。message （系统日志） 服务的日志 error（应用日志） 3.分析，定位问题。 4.解决问题。 忘记root密码？ 重置：centos5或者6 启动加载grub引导菜单时 按esc 找到当前系统引导选项。 按方向键找到需要的系统引导内核，按 “e“ 进入编辑状态。 然后通过方向键选中带有kernel指令的行 ...
网络问题排查
weixin_33885253的博客
10-17 154
正常情况下的状态如下：问题1：当启动系统后，发现网络不通时解决：检查配置文件/etc/sysconfig/network-scripts/ifcfg-eno16777736 ，将"ONBOOT=no"修改成"ONBOOT=yes"，然后再重启系统问题2：ping www.baidu.com不通 解决：dns没设置，ping下网关，若是网关ping不通，说明配置文件的网关没设...
Linux入侵问题排查思路
qq_41453632的博客
06-12 1495
一、检查隐藏账户及弱口令 1. 检查服务器系统及应用账户是否存在 弱口令： 检查说明：检查管理员账户、数据库账户、MySQL 账户、tomcat 账户、网站后台管理员账户等密码设置是否 较为简单，简单的密码很容易被黑客破解。 解决方法：以管理员权限登录系统或应用程序后台，修改为复杂的密码。 风险性：高 2. 使用 last 命令查看下服务器近期登录的账户记录，确认是否有可疑 IP 登录过机器...
NO31 配置网卡--主机名--网络故障排查面试题--DNS
weixin_34302798的博客
05-30 240
修改网卡配置信息： 修改主机名规范的三个步骤： 配置默认网关： DNS解析过程，用命令看： ...
定位错误日志排查Bug的基本思路大汇总（持续更新）
我的技术日常
03-26 4919
前言：根据项目提炼了的经验总结。主要提供一种BugFree的思路 1.写日志时要养成的好习惯 保证在定位日志时可以离开代码情镜还能看懂问题是什么。 在方法前加 @Transactional，抛出异常之后，事务会自动回滚，数据不会插入到数据库。 规范打印日志的格式 其中最重要的是接口和关键字，用于追踪定位 log.warn(String.format("[接口名或操作名][Key Msg]:%s...
GPu带宽异常排查思路
最新发布
03-25
<think>好的，用户现在需要了解GPU带宽异常的排查思路。首先，我得回忆一下之前用户询问服务器双网不通的问题，当时我给出了分层的排查步骤，从物理层到网络层再到应用层。这次是GPU带宽异常，可能需要类似的层次化方法，但具体内容不同。 首先，用户可能遇到了GPU性能问题，比如训练速度慢或者数据传输延迟高。他们作为运维人员或者开发人员，需要系统地排查问题所在。需要考虑到硬件、驱动、系统配置、应用代码等多个方面。 接下来，我需要确定GPU带宽异常的可能原因。带宽通常和PCIe通道、显存访问、数据传输等有关。比如PCIe版本或通道数不足，驱动问题导致DMA效率低，或者应用层没有优化数据传输，比如过多的小批量传输或者未使用Pinned Memory。 然后，思考如何分步骤排查。应该从硬件检查开始，比如使用lspci确认PCIe的版本和宽度，确保硬件连接正常。接着检查驱动和固件版本，是否有已知的兼容性问题。然后使用性能工具如nvidia-smi、nvprof或Nsight Systems来分析带宽使用情况。系统配置方面，可能需要检查NUMA设置、CPU-GPU亲和性，以及是否有其他进程占用带宽。最后，审查应用代码，确保数据传输的最佳实践，比如使用异步传输、合并内存访问等。 用户可能没有提到的深层需求是希望快速定位问题，减少系统停机时间，并且预防未来类似问题。因此，除了排查步骤，提供一些优化建议和预防措施也是有必要的，比如定期更新驱动、使用监控工具进行长期性能跟踪。 需要注意避免使用过于专业的术语，保持解释清晰，步骤明确。同时，要结合之前的回答结构，保持一致性，让用户容易理解。可能还需要对比之前的网络排查思路，强调不同点，比如GPU问题更多涉及硬件和驱动，而网络问题更多涉及路由和防火墙。 最后，确保回答结构清晰，分层次逐步展开，每个步骤都有对应的命令或工具示例，便于用户实际操作。同时，提醒用户关键注意事项，比如备份配置、使用监控工具等，确保他们能安全高效地进行排查。</think>以下是GPU带宽异常的**系统化排查指南**（基于深度学习集群运维经验），按**硬件→驱动→系统→应用**的分层逻辑进行问题定位： --- ### **一、硬件层检查** #### **1. PCIe拓扑验证** ```bash lspci -vvv | grep -i nvidia # 查看PCIe链路信息 # 关键指标： # - LnkSta: Speed 8.0GT/s（PCIe3.0）或16.0GT/s（PCIe4.0） # - LnkCap: Width x16（实际带宽） nvidia-smi topo -m # 查看GPU互连拓扑 ``` - **典型问题**： - 物理插槽限制（如x16插槽实际运行在x8模式） - PCIe版本不匹配（GPU支持PCIe4.0但主板仅支持3.0） #### **2. 显存带宽基准测试** ```bash # 使用官方带宽测试工具 nvidia-smi dmon -s pcm # 实时监控显存带宽 bandwidthTest --memory=pageable # 可分页内存测试 bandwidthTest --memory=pinned # 固定内存对比 ``` - **判断标准**： - A100 PCIe显存理论带宽1555GB/s，实测值低于90%需排查 - 多卡间NVLink带宽应达到>200GB/s（第三代NVLink） --- ### **二、驱动与固件层** #### **1. 驱动兼容性验证** ```bash nvidia-smi -q | grep "Driver Version" # 查看驱动版本 modinfo nvidia | grep version # 确认加载驱动版本 ``` - **注意项**： - CUDA Toolkit版本与驱动版本匹配（[官方兼容表](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html)） - 禁用nouveau驱动（`lsmod | grep nouveau`） #### **2. GPU BAR空间检测** ```bash sudo cat /proc/driver/nvidia/gpus/0000:3B:00.0/information # 检查"BAR1 Used"是否接近"BAR1 Total" ``` - **异常处理**： - 修改GPU BAR空间（需在BIOS中调整Above 4G Decoding设置） - 更新主板BIOS解决地址映射问题 --- ### **三、系统层优化** #### **1. NUMA绑定检查** ```bash numactl -H # 查看NUMA节点分布 nvidia-smi nvlink -s # 验证GPU与CPU NUMA对齐 ``` - **优化建议**： - 使用`numactl --cpunodebind=0 --membind=0`绑定进程 - 避免跨NUMA节点访问内存（使用`numactl --interleave=all`） #### **2. 内核参数调整** ```bash sysctl -a | grep dirty_ratio # 检查脏页刷新策略 # 建议值： vm.dirty_ratio = 20 vm.dirty_background_ratio = 10 ``` - **影响分析**： - 过高值导致内存堆积，突发写入时阻塞PCIe传输 - 过低值增加系统开销 --- ### **四、应用层诊断** #### **1. 数据传输模式分析** ```bash nvprof --print-gpu-trace python train.py # 捕获数据传输事件 # 关注： # - [CUDA memcpy HtoD] 主机到设备拷贝耗时 # - cudaMalloc/cudaFree调用频率 ``` - **常见反模式**： - 频繁小批量数据传输（应合并为单次大传输） - 使用可分页内存（应改用`cudaMallocHost`分配固定内存） #### **2. P2P访问验证** ```python import torch print(torch.cuda.get_device_properties(0).can_access_peer(1)) # 检查P2P支持 ``` - **优化措施**： - 启用P2P访问：`torch.cuda.set_device(0)` - 禁用P2P的场景：跨PCIe Switch的GPU通信 --- ### **五、高级诊断工具** #### **1. Nsight Systems时间线分析** ```bash nsys profile -t cuda,nvtx --stats=true python train.py ``` - **分析重点**： - PCIe传输与kernel执行的间隔时间 - 内存拷贝操作是否与计算重叠 #### **2. 总线带宽监控** ```bash # 使用PCIe带宽监控工具 sudo apt install pciutils sudo setpci -v -d 10de: -s 00:02.0 CAP_EXP+0x30.L # 输出解释： # 0000:0200 表示2.5GT/s x1带宽 # 0001:0400 表示5GT/s x4带宽 ``` --- ### **典型故障案例库** 1. **PCIe链路降级**： - 现象：GPU-Z显示运行在x8 1.1模式 - 处理：清理金手指/更换主板插槽 2. **内存锁页不足**： - 现象：`cudaErrorMemoryAllocation`报错 - 解决：`ulimit -l unlimited` 3. **RCU锁竞争**： - 现象：高负载时PCIe延迟飙升 - 修复：`sysctl -w kernel.pid_max=65535` --- ### **关键优化原则** 1. **数据传输最小化**： - 使用`torch.utils.data.PrefetchGenerator`预加载数据 - 启用FP16/INT8量化减少传输量 2. **计算通信重叠**： ```python with torch.cuda.stream(stream): # 创建独立流 data = data.to(device, non_blocking=True) # 非阻塞传输 ``` 3. **监控常态化**： - 部署Prometheus + NVIDIA DCGM Exporter - 设置带宽利用率告警阈值（建议>85%触发告警） 通过上述分层排查，可系统性定位GPU带宽瓶颈。**黄金法则：先确认硬件能力上限，再逐层分析软件损耗**。建议在业务压力测试阶段使用Nsight工具生成性能基线报告。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值