1. 先搞清楚“卡顿”和“死机”到底算哪一类故障做工控的人基本都遇到过这种场面现场设备在跑突然鼠标一卡一卡的远程连上去敲命令回车半天没反应再过一会彻底没动静只能让产线的人断电重启。客户报障的时候通常就一句话——“你们的机器又来问题了”但背后的原因却五花八门。这次要说的是德承GP-3100这台无风扇嵌入式工控机在Ubuntu系统下出现的卡顿/死机问题我把完整的排查过程和方法整理出来给正在Linux工控一线做运维和集成的朋友做个参考。先说一个很多现场工程师容易忽视的点卡顿和死机是两个不同量级的故障排查方向差得很远。如果不加区分直接上手往往浪费大量时间在错误的方向上折腾。我习惯先把现象拆细再决定动哪一层。1.1 卡顿的三种典型形态与各自的“第一嫌疑对象”“卡顿”这个说法太笼统我在现场一般会把卡顿拆成三种形态来登记第一种是“渐冻式”开机前半小时很流畅之后越来越慢最后趋近死机。这类问题十有八九出在内存泄漏、存储性能衰减或者SSD温度过热上。日志服务、采集程序、桌面环境只要有一个在漏内存长时间运行后的表现都是这个走向。第二种是“节拍式”系统每过几十秒就卡一下卡的时候连鼠标指针都拖不动过几秒又恢复。这种多半是某个服务在周期性做事比如systemd的定时任务、日志轮转、某个内核模块在周期扫描或者是磁盘每次刷盘的时候卡顿。GP-3100这类机器如果系统盘是SATA SSD而且开启了较激进的文件系统屏障刷盘瞬间经常会出现这种节拍式卡顿。第三种是“触发式”平时正常一打开某个功能或者某个窗口就立刻卡死。这种问题定位最容易故障基本就落在触发组件上。典型的像浏览器硬解视频、GPU渲染、某个驱动在特定操作下加载以及Ubuntu的桌面合成器在切换窗口时卡住。你去看医生的时候得先说清楚是头疼还是肚子疼排查也是一样。把现象归好类后面每一步都有了明确目标不会在方向上来回折腾。1.2 死机的“真死”与“假死”一个SysRq动作快速区分“死机”同样要区分“真死”和“假死”。真死是内核或者硬件彻底锁死网络ping不通、串口完全没有输出、SysRq键也没反应只能断电。假死是图形界面和部分进程没了反应但系统内核还在工作ping能通SSH能连或者SysRq键还能触发。区分假死最简单的一个动作就是看SysRq。这个按键组合平时用不到但关键时刻是救命稻草。Ubuntu下默认可能没开先执行echo 1 /proc/sys/kernel/sysrq然后尝试按Alt SysRq R取回键盘控制再按Alt SysRq E、Alt SysRq I、Alt SysRq S、Alt SysRq B按顺序走一遍。能走完这套组合说明内核还活着问题大概率在图形栈或者某个具体驱动。如果连SysRq都无响应那就是硬件级或者内核级的真死。对工控机来说两种死的处理策略也不同假死可以通过远程SSH进去kill掉进程续命真死只能考虑加看门狗自动重启但那是善后不是根治。所以在动手之前花两分钟确认一下“死法”能帮你省下好几个小时的弯路。2. 别急着重装系统先给现场保留一份“证据链”很多人习惯一遇到卡顿就重装系统这个做法我强烈反对。重装系统确实能把系统层面的临时问题清掉但它同时也把最重要的现场证据全部抹掉了。工控现场的时间就是产量与其等故障第二次出现再排查不如第一次就把日志、性能数据、硬件状态全部留好让设备带着“监控设备”继续跑。2.1 日志是第一证人journalctl和dmesg怎么抓才有用先去确认日志有没有持久化。Ubuntu默认把systemd-journal的日志放到内存盘上只要一断电重启之前的东西全没了。我踩过这个坑客户报障死机我到现场一看journalctl -b -1是空的因为死机重启把日志冲掉了。所以第一件事是把日志改成持久化vim /etc/systemd/journald.conf把Storageauto改成Storagepersistent顺手设一个上限比如SystemMaxUse500M避免日志把系统盘塞满。然后重启journald服务让配置生效systemctl restart systemd-journald等故障再出现后逐条看上次启动的日志journalctl -b -1 -p err..emerg # 上次启动的错误和更高级别日志 journalctl -k -b -1 | tail -n 100 # 上次启动的内核日志最后100行关键证据一般在最后几十行里。死机前最常见到的几种记录包括Out of memory: Kill process、blocked for more than 120 seconds、ata3.00: status: { DRDY ERR }、NMI received for unknown reason。这些信息已经不是猜测而是直接给你点名了嫌疑对象。还有一点死机后重新开机日志时间戳可能是乱的尤其主板RTC电池没电的老平台。我建议顺便检查一下日志时间是否连续如果时间跳变说明RTC有问题也会干扰你判断事件先后顺序。2.2 用“三指标”连续采样把锅甩给CPU还是内存还是磁盘日志是人死前的遗言性能数据则是完整的体检报告。现场如果装不了atop、sar这类监控工具可以自己写一个极简的采样脚本就抓三个最关键指标负载、内存、温度。这个脚本丢到后台跑让它一直记录#!/bin/bash while true; do echo $(date %F %T) load$(cat /proc/loadavg | awk {print $1,$2,$3}) mem$(free -m | awk NR2{printf %d/%dMB, $3, $2}) temp$(cat /sys/class/thermal/thermal_zone0/temp 2/dev/null) | tee -a /var/log/ztrace.log sleep 10 done保存为/usr/local/bin/ztrace.sh然后nohup bash /usr/local/bin/ztrace.sh 放后台。采样频率10秒一次至少完整覆盖一个“从正常到卡死”的周期。判断思路其实很直接如果load average一直往上走但CPU的用户态和内核态占用都不高说明进程基本都在D状态等IO优先查磁盘和文件系统如果free和available数值一路往下掉swap开始增长优先查内存泄漏和应用占用如果温度读数长时间贴着85度甚至更高优先查散热、风扇堵转、硅脂干化。很多故障其实是多因素叠加的结果比如夏天车间环境温度高设备又连续跑了好几天SSD热量散不出去几个因素合在一起才导致卡死。所以采样数据至少要覆盖24小时以上最好跨一个完整的昼夜周期这样炎热时段和深夜低负载时段的对比数据都有了。3. 从软到硬逐层剥离GP-3100卡顿/死机的人工排查流程日志和数据齐了之后进入真正的排查环节。GP-3100是第四代酷睿Haswell平台的无风扇嵌入式工控机铝合金外壳被动散热支持PCIe扩展卡这类机器的问题规律性很强我按实际排查中按出现的概率排序来讲。3.1 CPU与内存先排除这两个“廉价嫌疑犯”无风扇工控机有个天然短板散热完全靠外壳和导热垫。GP-3100这类铝合金外壳机型用久了导热垫干裂、硅脂退化CPU温度会悄悄爬得很高。Haswell这一代平台一旦温度超过TjMax系统会通过降频来保护自己频率从3.x GHz瞬间掉到0.8 GHz附近。表现是什么整机操作从“跟手”变成“拖泥带水”而且越到夏天越明显。检查方法很简单apt install lm-sensors stress-ng watch -n1 grep MHz /proc/cpuinfo先看温度再看频率。如果温度读数稳定在85度以上、频率却只有800MHz基本就是热降频在作怪。再用stress-ng拉一把负载验证stress-ng --cpu 4 --timeout 60 一分钟内如果频率断崖式跌落那就坐实了。解决办法拆散热器换硅脂顺便清理进出风口灰尘检查散热胶垫有没有压扁变形。这一通做完很多“莫名卡顿”直接消失属于性价比最高的第一步。内存方面不要只信free命令先处理接触问题。工控机在厂房里常年振动内存条氧化、松脱的概率很高。断电、拔内存、用橡皮擦把金手指擦一遍、吹掉插槽里的灰、重新装回去这个两分钟的检查能解决相当一部分死机。如果擦过还不行用memtester跑一轮memtester 1G 5或者直接烧录memtest86到U盘开机自检阶段测一轮。内存颗粒出问题时的死机往往毫无规律有时候在登录界面就死有时候跑三天才出现一次。3.2 SSD与文件系统卡死问题里最容易被冤枉的“替罪羊”这块要重点讲因为在实际排查中十个卡死问题里大概有三四个最后落在存储上。工业现场通常配的是工规SSD但也不乏项目为了压低成本塞了一块消费级盘进去。消费级盘的不可靠表现在几个方面SLC Cache用完后的写放大、掉电保护缺失导致FTL重建、NAND磨损后读重试时间暴增。检查命令smartctl -a /dev/sda重点看几个字段Reallocated_Sector_Ct不为0就值得警惕如果持续增长说明盘在悄悄报废Wear_Leveling_Count能看到剩余寿命百分比掉到90%以下就要列入更换计划UDMA_CRC_Error_Count不为0优先怀疑SATA线缆接触不良或者供电不稳Temperature居高不下对SSD同样致命。文件系统方面先看dmesg里有没有ext4报错、I/O error。有的话开机时做一次fsck并且检查挂载参数。对工控机我一般直接建议挂载时加noatime减少不必要的写入mount -o remount,noatime /另一个隐蔽坑是系统盘容量爆了。Ubuntu的journal日志和/var/log/apport一直写如果不控制100G的系统盘也能被塞满。磁盘满之后的典型症状就是莫名卡顿、服务起不来。df -h看一眼如果/超过90%先清理。3.3 驱动与内核模块让系统“卡”住的往往是某个D状态进程走完前面两步还查不出问题就要看内核线程和驱动了。ps aux看到大量D状态进程时不用慌D状态就是不可中断睡眠意思是这些进程在等底层IO返回。等得久了系统调度器被堵住表现就是卡死。查看进程在等什么cat /proc/进程ID/stack cat /proc/进程ID/io dmesg | grep -i blocked如果D状态进程集中在某个驱动名字下面比如usb、xhci、e1000e、igb那就去查对应硬件。老平台跑新内核经常有驱动回归问题GP-3100这类机器如果跑的是Ubuntu 22.04以上遇到USB或者集显相关卡顿可以先降级到5.15 LTS内核试试成本很低但经常能解决问题。另外可以看/proc/interrupts如果某个中断次数在短时间内暴增多半是设备在风暴式触发中断。再用perf top --count 5000看看热点内核函数如果大量时间花在特定驱动的轮询逻辑上基本就是驱动和硬件在打架。3.4 外部因素电源、地线与EMC在工业现场的隐性干扰工控设备和实验室里跑Linux的机器最大区别就在这现场的电源和电磁环境极其恶劣。变频器一启动地线上的噪声就窜起来了。SATA、USB这类高速信号最容易被干扰表现为偶发I/O错误、设备掉线最终整机卡顿甚至死机。如果设备旁边有伺服电机、大功率变频器故障时间点恰好和大设备启停重合十有八九是干扰。排查动作把工控机的电源改到独立的UPS或带滤波的插座上外壳PE接地要真正接到接地排信号线和动力线分槽走。电源适配器功率也值得怀疑。GP-3100不带扩展卡时一台90W适配器一般够用但如果加了运动控制卡、多路串口/USB模块峰值功耗上去之后适配器会进入疲软状态12V电压跌到10V以下SSD读写出错、网卡丢包就会接踵而至。现场可以用功率计实测或者直接换大一档适配器花小钱排除一个大疑点。4. Ubuntu侧针对工控机的内核参数与桌面环境调整硬件层拿不出问题时就该从系统配置层面动手了。很多卡顿其实是Ubuntu默认配置的锅——它默认面向笔记本和台式机场景以省电和美观优先而不是稳定和响应速度优先。4.1 关闭“节能魔法”让CPU频率策略从调速器切换到performanceUbuntu默认的CPU调速器在不少机器上是powersave或者schedutil这套策略是为笔记本省电设计的频繁在低频和高频之间切换加上负载预测的滞后人眼看起来就是一顿一顿的卡。工业机反而不差那几瓦电响应速度优先。先看当前策略cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor如果是powersave切换cpupower frequency-set -g performance永久生效可以写一个systemd服务cat /etc/systemd/system/cpupower-performance.service EOF [Unit] DescriptionSet CPU governor to performance Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/bin/cpupower frequency-set -g performance RemainAfterExityes [Install] WantedBymulti-user.target EOF systemctl enable cpupower-performance.service切换后你能明显感到桌面操作跟手很多。代价是待机功耗高一点、发热大一点但这对工业控制场景来说完全值得。4.2 死机要“开口说话”kdump与内核转储的最小配置排查死机最痛苦的是它真死给你看了你却不知道它死前在想什么。所以最好提前给系统装好“黑匣子”。最小配置两件事一是预留crashkernel内存二是装kdump-tools。Ubuntu下的做法apt install kdump-tools然后编辑/etc/default/grub.d/kdump-tools.cfg把crashkernel256M加到GRUB_CMDLINE_LINUX_DEFAULT里再执行update-grub。死机时kdump内核会把一份vmcore存在/var/crash下事后用crash工具分析或者至少能把dmesg信息提取出来看最后几条。如果现场不愿意为crashkernel预留内存退而求其次在grub命令行加panic10。这样一旦内核panic10秒后自动重启虽然不能保留现场但至少产线能第一时间恢复不用等人去断电重启。还有pstore/ramoops部分主板BIOS支持在内存里保留一小块区域死机后重启之前的日志会出现在/sys/fs/pstore里。死机恢复后第一件事就是去翻这个目录经常有惊喜。4.3 图形栈的取舍TTY验证、Gnome动画与轻量桌面GP-3100这代处理器的集显是HD Graphics 4600跑Ubuntu默认的Gnome桌面其实有点吃力。Gnome的动画合成需要CPU/GPU来回切换一旦驱动配合不好画面就出现一帧一帧跳的卡顿而系统本身其实不卡。排查办法按Ctrl Alt F3切到TTY如果在TTY下操作流畅说明问题出在图形栈而不是整机。解法按激进程度分几档最低档关掉Gnome动画gsettings set org.gnome.desktop.interface enable-animations false中间档换轻量桌面装XFCE或者KDE Plasma的精简版或者用Openbox配一个极简面板。高档工控整机本来就不需要桌面把默认target改成multi-user开机直接进命令行态全靠自研应用或Web前端做界面。嵌入式工控机要的是稳定不是动画。4.4 swap和系统日志盘的“配置哲学”swap配置不当是又一个隐性卡顿源。Ubuntu默认把swap放在系统盘上如果系统盘是SSD且已近满负荷swap频繁换页会让系统慢到像掉进泥潭。先看当前swap占用和系统换页积极度free -h cat /proc/sys/vm/swappiness # 默认60如果swap用量长期在增长说明物理内存不够单纯调低swappiness只是缓解症状根治法要么加内存条要么用zram把swap层压缩到内存里来减少磁盘I/O。安装zramapt install systemd-zram-generator在/etc/systemd/zram-generator.conf里设置zram-size ram / 2重启后就会有一个压缩swap层。对工控机来说zram比磁盘swap好用得多——它不磨盘响应也快得多。系统日志盘的话如果日志写得很频繁且没有持久化需求可以把/var/log/journal挂到tmpfs上或者干脆限制journal大小。工控机的SSD写入寿命是有限的每一条多余的日志都在消耗它。控制住这些细水长流的写入对延长整机稳定运行时间很有帮助。5. BIOS/固件层最容易被忽略的“老平台暗坑”软件层面折腾完之后GP-3100这类老平台还有一个绕不过去的战场——BIOS和固件。这一层的坑往往在Linux发行版文档里根本查不到只有用多了老机器才摸得到规律。5.1 关闭C-States和EIST待机死机的经典源头Haswell这一代的C6/C7深度节能状态在工控现场是出了名的麻烦制造者。具体表现是系统在低负载下进入深度睡眠之后某个中断想把它唤醒结果唤醒过程卡住或者唤醒后ACPI状态混乱导致鼠标键盘无响应、网络假死。这类故障有个特征死机多半发生在系统空闲一段时间后比如中午休息没人操作、晚上自动化任务跑完后。如果你发现“待机后死机”先别怀疑硬件去BIOS把CPU C-States关掉特别是C6/C7BIOS里没有选项的话在grub命令行加idlehalt让内核使用HLT指令等待而不是mwait可以避开深C状态带来的坑。关闭EISTEnhanced Intel SpeedStep也可以一并考虑配合前面说的performance调速器响应会更稳。代价是功耗高一些但这对7x24小时的工业控制场景反而是好事——它至少不会因为频繁变频引入新的时序抖动。5.2 关闭VT-d和SR-IOV扫掉DMA重映射的“盲区”GP-3100的PCIe扩展槽如果插了运动控制卡、图像采集卡等VT-d和IOMMU可能和某些卡的驱动不兼容。表现是设备跑着跑着突然整机IO hang日志里全是DMAR报错或者干脆什么日志都没有就死了。排查成本很低进BIOS关掉VT-d也就是VT-x里的Directed I/O也可以在内核参数里加iommupt。如果故障消失说明就是DMA重映射的问题。这类问题在新硬件上不常见老平台加老设备时要重点怀疑。注意关VT-d不影响日常使用只有做KVM虚拟机设备直通时才需要开。5.3 启动模式与核显显存画面冻结不等于整机死机另一种现场常见的“伪死机”是画面停在某一帧完全不动但SSH还能进、程序还在跑。这种现象我见过不少次最后定位到显示输出自己挂了。检查方法SSH连进去执行systemctl restart gdm或lightdm如果画面恢复说明图形栈挂了不是整机死机。处理方向核显驱动和BIOS输出方式不兼容。老平台建议把BIOS里的CSM打开、启动模式保持Legacy兼容同时把DVMT预分配显存调大比如设到64M或128M避免核显显存分配不足导致渲染异常。如果还不行在grub命令行加nomodeset让内核用通用的framebuffer驱动。画面是基本款但稳定性往往能大幅提升。5.4 内存配置里的两个“老坑”电压、频率与插槽最后说内存配置的细节问题。GP-3100这一代用的是DDR3/DDR3L SO-DIMM注意两个原则一是不要混合插1.5V的标压条和1.35V的低压条两条电压不同在某些主板上不会立刻报错但会在高负载时出现随机死机二是内存频率并不是越高越好在兼容性一般的主板上把标称1600的内存手动降到1333跑反而更稳。另外很多工控机经常换内存、查内存后忘记再确认插槽卡扣是否完全闭合工控机的振动会让半咬合的内存条逐渐松脱两三个月后死机开始频繁出现。检查内存相关问题时我习惯把内存拔下来重插并确认两边卡扣都“咔哒”到位。这条经验看着不起眼但帮我解决过不少所谓“疑难杂症”。6. 一套可以直接抄作业的排查优先级清单整理一张按出现概率从高到低排列的排查顺序现场工程师对着这个表从上往下走基本能把绝大多数卡顿/死机问题锁死优先级排查项最快判断方式处理动作1散热与热降频查看thermal_zone0温度 观察CPU频率清灰、换硅脂、检查导热垫2SSD寿命与文件系统smartctl -a /dev/sdadf -h换盘、换SATA线、fsck、清理容量3内存接触与颗粒重插内存 memtester橡皮擦金手指、更换故障条4电源与适配器实测功率或直接换大功率适配器独立供电、加UPS、检查PE接地5系统级节能与桌面cpupower查看governor 切TTY测试设performance、关动画或换轻量桌面6BIOS节能与虚拟化待机后死机 / DMAR报错关C-States、VT-d、加idlehalt7驱动与内核回归dmesg的blocked记录 D状态进程降级LTS内核、卸载冲突模块8工业干扰EMC故障时间与大功率设备启停重合独立电源、分槽走线、加EMI滤波器按我个人的习惯到现场后前面四条加起来不会超过半小时却能解决大部分问题。不要一上来就改内核参数、调BIOS那样反而把简单问题复杂化。先把最便宜的检查做完剩下的才是真正的硬骨头。最后说点题外话。我做了这么多年工控集成发现这类卡顿死机问题最坑的地方是它不按你的计划复现——你带着仪器在现场蹲一天它没事你一走它就犯病。所以我的建议是不管问题最后出在哪现场的日志、温度、负载这三样数据一定要先留够。没有数据链排查就是大海捞针有了数据链哪怕一时半会查不出来你可以放心让设备先跑着等数据攒够了再定点打击。GP-3100在我手里跑了不少年头它的毛病基本都集中在散热、存储和固件这几个维度上这篇文章如果能在你排查时节约半天时间那就算没白写。