简单的排障 - load高

最新推荐文章于 2025-02-10 22:43:30 发布
原创 最新推荐文章于 2025-02-10 22:43:30 发布 · 454 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#排障

本文记录了一次系统报警的情况，初步判断为计算资源不足导致的问题。通过对系统的进一步检查，发现CPU使用率高达80%，内存也开始使用swap空间，表明当前系统面临CPU和内存资源紧张的情况。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

mark

刚刚收到报警，load120。
第一反应是io问题，造成计算资源在等待io，任务挂起，导致。

但是，登录后，发现iowait几乎没有，ucloud的磁盘还是可以的。 但是cpu已经80%， 内存也有开始吃swap的迹象。

这就说明，cpu不够了，内存不够了。

Kubernetes 排障实战：用 Prometheus 提升集群可用性和排障效率
weixin_39009745的博客
12-27 866
一份超详细的用 Prometheus 监控 Kubernetes 平台指南
linux shell 脚本详解 | 服务器排障常用命令 | 创建窗口部件
u013669912的博客
10-28 1399
……
Load过高问题排查
04stone37
01-20 1226
情况1：CPU高、Load高 通过top命令查找占用CPU最高的进程PID； 通过top -Hp PID查找占用CPU最高的线程TID; 对于java程序，使用jstack打印线程堆栈信息； 通过printf %x tid打印出最消耗CPU线程的十六进制； 在堆栈信息中查看该线程的堆栈信息； 情况2：CPU低、Load高 通过top命令查看CPU等待IO时间，即%wa； 通过iostat -d -x
QNAP NAS 处理一次IO异常占用的问题
wanttolearn的专栏
03-03 1401
一次系统更新后，qnap ts212p3 NAS设备异常缓慢，但是没有完全死机，可以ping、可以ssh、可以HTTPS，但是非常慢，几乎无法打开HTTPS界面。
如何解决Linux中的高 I/O 等待时间
路人丙的奋斗史
11-10 4187
I/O 等待时间是一种用于衡量CPU等待磁盘 I/O 操作完成的时间的指标。高 I/O 等待时间表示CPU繁忙或者有大量未完成的 I/O 请求，虽然可能不会使系统出现问题，但会限制CPU性能。CPU的 I/O 等待意味着即使没有进程处于可运行状态，但至少有一个 I/O 操作正在进行中。简单地说，I/O 等待时间就是 CPU 等待 I/O 完成所花费的时间。
cpu等待io的原因！
clt3617的博客
05-07 965
What Is Disk Contention?Disk contention occurs when multiple processes try to access the same disk simultaneously....
记两次虚拟机群晖raid阵列降级、损毁、只读的恢复
2301_76186038的博客
11-03 3225
执行删除快照操作后，群晖提示正在回收快照的存储空间时，存储池警报大作，存储池变为只读。重建阵列并修改uuid的方法来重新恢复存储空间，其原因就是虚拟磁盘的io读写可能发生超时。群晖本身对于阵列的处理机制似乎还不是很好，文件都损坏了还只是警告一个“Checksum Mismatch”？应该报大警才对。虽然群晖的存储页面显示所有三个硬盘都正常，但是实际上有一个硬盘并没有在阵列里。
【安川7伺服高级排障】：代码层面的终极解决方案
本文针对安川7伺服系统，系统地介绍其概述、排障理论基础、代码层面的排障技巧，以及在实践中的应用。首先概述了安川7伺服系统的组成与特点，随后深入分析了排障的理论基础，包括故障的定位、分类、诊断工具使用和...
GAMS常见报错精解：从报错信息到快速排障指南
2403_88439206的博客
02-10 1329
作为优化建模领域的核心工具，GAMS的报错信息常让新手感到困惑。本文总结了6类高频错误，结合案例展示快速定位和修复方法。
六轴传感器ICM40607故障诊断与维修：实用指南，快速排障
[六轴传感器ICM40607故障诊断与维修：实用指南，快速排障](https://ecampusontario.pressbooks.pub/app/uploads/sites/69/2018/04/Part2-fig-3.png) 参考资源链接：[ICM40607六轴传感器中文资料翻译：无人机应用与...
【io】io等待为什么引发cpu过高?
michaelwoshi的博客
02-11 8110
磁盘读频繁，数据量大 ---> iowait高 ---> CPU飙升 IO（input output）主要指：文件IO，网络IO。 “等待IO就绪“究竟等的什么？ 你一定不止在一个地方看到类似"cpu等待IO就绪，线程挂起..."的描述，不知你有没有想过CPU到底在等待个啥，等待个寂寞吗？为什么CPU要等待呢？CPU不能参与吗？ 首先，cpu有两种状态，用户态和内核态，cpu会根据需要在两种状态之间切换。 用户态和内核态的cpu有什么区...
io等待为什么引发cpu过高_搞懂IO(二)
weixin_36301419的博客
12-11 5164
之前写过一篇《搞懂IO》，这篇算是对上一篇的补充吧。我们已经知道高级程序设计语言上的IO实际上依赖底层操作系统，可以说它是操作系统层面上的一个抽象吧。想想平时程序都部署在什么服务器上，可能是在linux，可能是在windows...不管怎样，别担心，既然是抽象，肯定支持刚才说的操作系统。基于更常见的是部署在linux系统，待会不得不说说linux下IO的五个模型。“等待IO就绪“究...
群晖NoteStation一直显示“正在加载”解决方法（适用黑白群辉）
小歆优快云博客
02-10 1万+
一、问题原因 最近套件中心提示NoteStation要升级（版本 2.6.0-1407），于是手贱点了升级按钮。 升级完成后打开NoteStation一直显示 “正在加载” ，等待许久也没有结束，还好PC客户端和手机客户端是正常的。 显然是升级新版的NoteStation导致的，于是重新安装旧版本的NoteStation解决问题。 二、解决办法 1、备份数据 首先备份数据（虽然没有用到备份，但是以防万一先备份吧），打开NoteStation，不用理会正在加载，点击顶部设置按钮，选择导入和导出选项卡，点击导出
群晖Docker加速的简单方法
everestzhang的专栏
12-27 2万+
群晖Docker加速的简单方法 官网的Docker，下载速度太慢，注册表添加加速源不能解决问题，发现还是官方的资源全，偶然发现一个方法，无需ssh等操作，可以满速了。 群晖版本为：6.1或6.2 1、打开Docker，依次点击。 2、选择官方的注册表，点击设置，在下图中的“注册表镜像URL”中填入你自己的加...
iowait过高问题查找及解决方案
一摩尔自由的博客
12-08 4324
一、iostat和iowait详细解说-查看磁盘瓶颈一、iostat基础 　　%iowait并不能反应磁盘瓶颈 1、安装iostat 　　iostat的包名叫sysstat yum install sysstat -y 　　2、iowait实际测量的是cpu时间： %iowait = (cpu idle time)/(all cpu time) 　　说明：高速cpu会造成很高的iowait值，但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法，就是很高的read/write时间，一般来说超..
黑群晖显示真实CPU信息 【支持7.0-7.1】
热门推荐
李佑辰
04-15 2万+
使用VMware安装完群晖默认显示的CPU并不是本机CPU信息，看着不是很爽，所以采用补丁形式可以显示真实CPU信息未修改前 修改后具体操作步骤：1.下载补丁包： 微云网盘：https://share.weiyun.com/eXs3hFj6蓝奏网盘：https://l13144.lanzoul.com/iGmp4038p03a阿里云盘：https://www.aliyundrive.com/s/nL3bRkPTnmM天翼云盘：https://cloud.189.cn/t/uqyMfaeURBra(访问码.
I/O相关的等待事件
weixin_33910385的博客
05-19 194
1. 查看Oracle数据库是否存在IO相关的竞争等待有下面三种方法： statpack报告的top 5 wait events或者AWR报告中的top 5 timed events。 数据库等待事件的sql语句跟踪中主要都是IO相关的等待事件的限制。 操作系统工具显示存储数据库文件的存储磁盘有非常高的利用率。 2. 对于出现IO问题的一些处理方法： 优化sql语句来减少数据...
在linux系统中跟踪高IO等待
weixin_30518397的博客
08-28 205
原文作者：Jon Buys 原文地址：http://ostatic.com/blog/tracking-down-high-io-wait-in-linux 译者：Younger Liu，本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。 跟踪大型分布式系统的性能问题，从本质上来讲是复杂的。应用为什么慢？瓶颈在哪里？以我的经验...
服务器load高，服务越跑越慢问题定位
weixin_44834554的博客
12-14 2366
服务器load高问题定位
Fusing layers... YOLOv5s-seg summary: 224 layers, 7611485 parameters, 0 gradients, 26.4 GFLOPs Traceback (most recent call last): File "C:\Users\lj33hh\Desktop\ML_project\yolov5-master\detect.py", line 438, in <module> main(opt) File "C:\Users\lj33hh\Desktop\ML_project\yolov5-master\detect.py", line 433, in main run(**vars(opt)) File "C:\Users\lj33hh\AppData\Local\anaconda3\Lib\site-packages\torch\utils\_contextlib.py", line 116, in decorate_context return func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\lj33hh\Desktop\ML_project\yolov5-master\detect.py", line 252, in run s += f"{n} {names[int(c)]}{'s' * (n > 1)}, " # add to string ~~~~~^^^^^^^^ KeyError: 94
最新发布
04-25
### YOLOv5s-seg 出现 KeyError: 94 的原因及解决方案 #### 错误背景分析 在执行 `detect.py` 脚本时遇到 `KeyError: 94`，表明程序试图访问字典中的键值为 `94` 的条目，但未能成功找到对应记录。此问题可能源于以下几个方面之一： 1. **模型配置文件损坏或不兼容**：如果使用的预训练权重与当前版本的模型架构存在差异，则可能导致部分参数丢失或者新增加的部分未初始化完全从而触发异常状况[^1]。 2. **数据集标注格式错误**：假设输入源并非标准 COCO 或 Pascal VOC 形式的检测任务所需结构化信息而是其他特殊定制样式的话那么就极有可能因为解析过程不符合预期而导致索引越界类别的报错现象出现[^3]. 3. **代码逻辑缺陷**：不排除官方发布版本身存在一定局限性特别是在频繁迭代更新期间难免会出现一些潜在隐患如果没有及时修复也可能成为诱发因素之一[^2]. --- ### 解决方法探讨 #### 方法一：确认并替换正确的预训练权重文件 首先应该核实所选用的基础网络是否适配最新发行包内含有的 segmentaion 功能扩展组件即 yolov5s-seg.pt 。如果不是则可以从 Ultralytics 官方仓库重新下载相应资源覆盖本地旧版本尝试解决问题。 另外值得注意的一点在于加载外部自定义 checkpoint 时候务必调用辅助函数 `attempt_load()` 来完成操作而不是简单直接赋值给 model.state_dict() ，前者可以自动处理不同尺寸之间的转换同时也支持增量微调模式更加灵活可靠[^1]: ```python from models.experimental import attempt_load weights_path = 'yolov5s-seg.pt' model = attempt_load(weights=weights_path, map_location=device) # 自动适应设备环境 GPU/CPU ``` --- #### 方法二：检查数据集标签一致性 针对第二种可能性需要细致审查整个 pipeline 中涉及到的所有环节确保没有任何地方偏离常规做法特别是对于 segmentation 类型的任务来说除了 bounding box 坐标之外还额外增加了 pixel-level mask 层次的信息描述所以必须保证两者同步无误才能顺利推进后续流程。 具体来讲可以通过编写简单的脚本来遍历所有样本逐一校验其合规程度例如下面给出了一段示范代码用于筛选出有问题的对象列表方便进一步排查修正: ```python import os import yaml from pathlib import Path def validate_dataset(dataset_yaml): with open(dataset_yaml, 'r') as f: data_config = yaml.safe_load(f) root_dir = Path(data_config['path']) image_dirs = {k: root_dir / v for k, v in data_config.items() if isinstance(v, str)} errors = [] for split_name, img_dir in image_dirs.items(): label_dir = img_dir.parent / ('labels_seg' if '_seg' in dataset_yaml else 'labels') if not label_dir.exists(): errors.append((split_name, f"Label directory does not exist at '{label_dir}'")) continue imgs = set(x.stem for x in img_dir.glob('*.jpg')) labels = set(x.stem for x in label_dir.glob('*.txt')) unmatched = imgs.symmetric_difference(labels) if unmatched: errors.extend([(split_name, stem) for stem in unmatched]) return errors errors = validate_dataset('./data/mydataset.yaml') if errors: print("Found issues:") for e in errors: print(e) else: print("All checks passed.") ``` --- #### 方法三：调试核心算法实现细节 假如前两步都没有发现明显线索那就可以深入到源码层面去探究根本成因所在。重点查看位于 utils/general.py 文件里的 non_max_suppression() 函数以及 utils/metrics.py 当中的 process_batch() 部分是否存在边界条件判断不当之处导致非法数值渗入最终引起崩溃事故的发生[^2]。 同时也可以开启 verbose mode 输出更多中间状态供开发者追踪定位疑难点位加快排障效率比如修改如下位置增加日志打印语句即可获取更详尽的过程轨迹图景帮助诊断难题: ```python # In detect.py or equivalent script where inference happens pred = model(img)[0] for i, det in enumerate(pred): # detections per image logger.info(f"Image #{i}: Found {len(det)} boxes before NMS.") if len(det): # Rescale boxes from img_size to im0 size ... logger.debug(f"After rescaling: Boxes={det[:, :4]}, Scores={det[:, 4]}") ... logger.warning("No detections were made.") if pred is None else None ``` --- ### 结论 通过以上三种途径综合施策相信能够有效缓解乃至彻底杜绝类似 KeyError: 94 此类顽疾再次发作的机会。当然具体情况还需结合实际运行环境中呈现出来的特征表现灵活应对不可拘泥于固定套路之上。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值