标签 系统监控 下的文章

让它不再专门在某个项目目录写代码。作为一个 shell 命令辅助工具运行,比如想不起来哪个复杂的 shell 命令的时候,随时 aish ,然后提问,aish 在你的允许下执行,然后退出....
https://github.com/chunhuitrue/aish

刚 vibe 出来,文档配置之类的还没加。

运行示例:
› 当前系统中有僵尸进程么?


• 我来检查系统中是否有僵尸进程。

• Ran ps aux '|' grep -w Z
└ ps: illegal argument: |
usage: ps [-AaCcEefhjlMmrSTvwXx] [-O fmt | -o fmt] [-G gid[,gid...]]
[-u]
[-p pid[,pid...]] [-t tty[,tty...]] [-U user[,user...]]
lll 61467 6.3 0.2 411403520 65552 s002 S+ 8:58 下午 0:00.45 aish

• Ran ps aux
└ USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
lll 429 32.8 3.0 413283760 1020816 ?? S 8 126

✔ You approved aish to run ps axo 'stat,pid,ppid,command' this time

• Ran ps axo 'stat,pid,ppid,command'
└ STAT PID PPID COMMAND
Ss 1 0 /sbin/launchd
Ss 83 1 /usr/libexec/logd
Ss 106 1 /usr/libexec/watchdogd
… +621 lines
Ss 750 552 -zsh
S+ 9711 750 emacsclient -nw
Ss+ 837 552 -zsh
Ss+ 882 552 -zsh
─ Took 41s

• 是的,当前系统中有 5 个僵尸进程:

| PID | PPID | 状态 | 父进程 |
|-------|------|------|--------|
| 54918 | 290 | Z | clash-core-service |
| 73753 | 290 | Z | clash-core-service |
| 75525 | 290 | Z | clash-core-service |
| 85212 | 290 | Z | clash-core-service |
| 97475 | 290 | Z | clash-core-service |

这些僵尸进程都是 clash-core-service (位于 /Users/lch/.config/clash/service/clash-core-service )产生的。

说明:僵尸进程是已经执行完成但父进程没有正确 wait() 它们的进程。它们不占用内存或 CPU ,只保留一个进程表项。

建议:通常不需要手动清理。重启 clash-core-service 服务可以让这些僵尸进程被 init 进程接管并自动清理。如果你想让这些僵尸进程消失,可以重启 clash 服务。


› 如果要手动清理,应该如何作?


• 僵尸进程无法直接 kill ,因为它们已经执行完成。清理方法是让父进程正确地 wait() 它们,或者让 init 进程( PID 1 )接管后自动清理。

针对你的情况,有两种方法:

方法 1:杀死父进程(推荐)

kill 290

这会终止 clash-core-service ,僵尸进程会被 init 接管并自动清理。如果 clash 是通过服务管理器启动的,它可能会自动重启。

方法 2:优雅重启 clash 服务

如果你知道如何重启 clash 服务(比如通过 launchctl 或 systemctl ),可以用相应命令重启服务,这样更安全。

———

注意事项:

- 方法 1 会中断 clash 服务,如果你的网络依赖它,可能会短暂断网
- 如果你使用 launchd 管理 clash ,可以用 launchctl 重启,更优雅

你是想直接杀死进程,还是需要我帮你查看如何正确重启 clash 服务?

在当今数字化工作流中,高并发文件转档处理已成为金融、法律、企业服务等众多行业的常态。系统需要在瞬间处理海量文件请求,而保持接近完美的转换精度则是保障业务连续性与数据可靠性的核心挑战。这不仅关乎单一文件的准确度,更涉及在持续高压下,系统整体表现的稳定性与一致性

本文将深入探讨实现这一目标的技术架构与策略,并以ComPDF的转档SDK V3.0为例,解析其如何通过技术创新应对这一挑战。

一、高精度与高并发的核心矛盾与解决思路

在高并发场景下,维持高精度主要面临三大矛盾:

1.  资源竞争与处理质量:大量并发任务争夺计算资源(CPU、内存),可能导致单个任务处理不充分,进而影响布局分析、字体还原等关键环节的精度。

2.  处理速度与深度分析的平衡:追求极速转换可能迫使简化分析算法,牺牲对复杂表格、混合版式的深度识别。

3.  系统稳定性与异常处理:在高负载下,系统需保持健壮,任何微服务宕机或性能波动都可能导致批量任务失败或精度下降。

解决这些矛盾,需要从系统架构、核心算法和工程实践三个层面协同设计。

二、架构基石:为高并发高精度而生的系统设计

1.  微服务化与弹性伸缩

    *   将文档转换流程拆分为独立的微服务,如文件解析、布局分析、元素识别(AI模型)、格式渲染、输出合成等。这允许对每个环节进行独立扩容。

    *   当并发请求激增时,通过Kubernetes等编排工具,弹性伸缩负责AI推理和渲染等计算密集型服务的实例数,确保每个任务都能获得足够的计算资源以维持精度,避免因排队过长或资源不足导致处理质量下降。

2.  智能队列与优先级调度

    *   并非所有文档都同等复杂。系统可集成智能预分析模块,根据文档页数、内容密度、包含元素(如大量表格、图片)初步判断处理难度。

    *   据此实施差异化队列调度:将简单文档分配至快速通道,复杂文档分配至拥有更强算力保障的精确处理通道。这种资源精细化调度是保证整体吞吐量与高精度并存的关键。

3.  状态持久化与断点续转

    *   在高并发环境下,任何节点故障都可能发生。必须将每个转换任务的中间状态和进度持久化到可靠的分布式存储中。

    *   一旦某个处理节点失败,任务能被迅速重新调度至其他节点,并从断点处继续,避免整个文档转换重头开始,这对处理到一半的大型文件至关重要,既节省资源,也保障了任务完成的可靠性。

三、精度引擎:ComPDF转档SDK V3.0的技术实践

ComPDF的转档SDK V3.0的设计体现了上述架构思想,并通过多项核心技术,将高并发下的高精度转化为了可实现的指标

1. AI驱动的混合布局分析技术

这是其实现高精度的核心。传统转换SDK往往只能在“流式布局”(利于编辑,但易失真)和“固定布局”(保持原貌,但编辑困难)间二选一。

  • 技术突破:V3.0版本集成了PP-YOLOE AI模型,并升级了布局分析算法,创新性地采用了智能混合布局技术。它能动态分析文档不同区域的特征,智能结合流式与固定布局的优势。
  • 精度影响:此举能99%准确还原多栏排版、图文混排、目录等复杂结构,同时保持内容的自然阅读顺序。在高并发时,该AI模型以服务化部署,通过弹性伸缩保障每个文档的布局分析深度,这是维持高精度的算法基础。

2. 像素级元素识别与恢复

精度体现在细节。V3.0的AI模型经过海量文档训练,能识别超过30种文档元素类型。

  • 关键改进:通过像素级精准分析,有效防止了将页眉、页脚内容误判为正文,同时将段落间距和行高的还原准确率提升了80%
  • 高并发适配:这种精细化的识别能力,确保系统即使在批量处理时,也不会因为“赶工”而忽略细节。统一的AI模型服务确保了处理标准的一致性,无论第1个还是第1000个并发任务,都能获得相同的识别精度。

3. 企业级性能与批量处理优化

高精度离不开性能支撑。V3.0通过重构数据结构和转换流水线,实现了效率飞跃。

  • 性能数据:支持数千页文档秒级批量转换,平均处理速度达到每页0.5–0.8秒,且整体处理速度比以往提升50%。
  • 高并发意义:极高的单任务处理速度,直接降低了系统在单位时间内的平均负载,为应对并发洪峰留下了更多资源余量。快速处理也意味着更短的队列等待时间,减少了任务因排队超时或资源调度延迟而出错的风险。

四、超越SDK:构建全链路保障体系

仅依靠一个强大的SDK并不足够。在生产环境中,围绕它构建全链路保障体系至关重要:

1.  渐进式负载测试与降级策略

    *   在上线前,必须进行远高于预估峰值的负载测试,观察在不同压力下转换精度的变化曲线,找到性能拐点。

    *   制定清晰的服务降级策略。例如,当系统负载超过阈值80%时,可自动暂时关闭对“高保真图片嵌入”等非核心但耗资源功能的支持,优先保障正文、表格等核心元素的转换精度,实现“精度有损,服务可用”。

2.  多维度的监控与告警

    *   监控指标不应仅有CPU、内存和QPS(每秒查询率),更需包含业务精度指标。例如,通过抽样对比,监控“表格结构保持率”、“字体属性正确率”的时序变化。

    *   设置精度阈值告警(如批次任务平均精度跌破99.9%),使运维团队能在用户体验受影响前主动干预。

3.  持续的回流验证与模型迭代

    *   建立自动化回流验证管道,定期抽取生产环境中已处理的文档,进行精度复核。

    *   将发现的问题案例(如特定版式的转换缺陷)加入训练集,持续迭代优化SDK内部的AI模型,形成一个从线上问题到模型改进的闭环,让系统精度在动态中持续进化。

结论

在高并发场景下坚守99.99%的文档转换精度,是一项系统性的工程。它要求我们将弹性可扩展的微服务架构智能精准的核心算法以及严谨的全链路工程实践三者深度融合。

其终极目标,是在流量洪峰中,让每一份文档的转换,都如同在静水中处理一样精准、可靠。这不仅是技术的胜利,更是对业务连续性与数据价值的最坚实保障。

自己做了一个 macOS 上的完整版任务管理器

为什么

macOS 上的官方任务管理器,也就是 “活动监视器 (Activity Monitor)”,是

只能监视,不能管理

也就是:只能查看进程,不能结束进程,更不能看进程文件位置

基本上没用

但我又是一个对这方面有大量需求的开发者,刚好我会 iOS 开发,于是我不能自己造一个呢?

怎么做

架构选型

最开始,我的目标很明确:做一个 macOS 版的 Windows 任务管理器 。

为了保证 “原生” 和 “极速”,我果断放弃了 Electron 这种网页套壳方案,选了 SwiftUI 。

但是,监控软件有个特点:数据更新非常快。如果让每个界面自己去拉数据,CPU 肯定受不了,界面也会卡。

所以,我确立了 MVVM + 单向数据流 的架构:

  1. 心脏 (SystemMonitorService.swift) :这是一个单例(Singleton)。它像心脏一样,每隔 2 秒跳动一次(Timer),负责把所有数据采集回来。
  2. 大脑 (AppViewModel.swift) :这是为了解决 “刷新页面数据重置” Bug 引入的。它把数据存住,不管界面怎么切,数据都在那儿。
  3. 脸面 (Views) :界面只负责展示,不负责逻辑。

数据获得

这是项目最难的部分。macOS 的上层 API(像 ProcessInfo )给的数据太浅了,根本不够用。我不得不 “下潜” 到内核层。

  1. CPU 计算
    我们不能直接问系统 “CPU 占用多少”,系统只会告诉你 “这一瞬间” 的状态。
    我们用的是 C 语言的 host_statistics 接口。
  • 逻辑 :现在看一眼 CPU,记录下 User/System/Idle 的时间滴答数(Ticks);过 2 秒再看一眼。
  • 计算 : (第二次的总数 - 第一次的总数) 就是这段时间的总工作量。然后算出百分比。这部分逻辑都在 SystemMonitorService.swift 的 getSystemCpuUsage 方法里。 内存压力
    普通的 “已用内存” 其实没意义。macOS 有个 “内存压缩” 技术。
    我们用了 host_statistics64 ,专门去读 VM_WIRE_COUNT (内核占的)、 VM_ACTIVE_COUNT (App 正在用的)和 VM_COMPRESSOR_PAGES (被压缩的)。
  • 磁盘读写(最硬核的部分)
    这个是很多同类软件做不到的。我没有监控文件系统(那样太慢了),而是直接找 驱动 。
    我们用了 IOKit 框架,去遍历硬件注册表,找到所有类型为 IOBlockStorageDriver 的硬件,直接问它们:“你们一共读写了多少字节?”。这招非常底层,但效率极高。
  • 网络测速
    这个相对标准,我们用了 BSD Socket 的 getifaddrs 。
    难点在于 去重 。电脑里有很多虚拟网卡(比如 lo0 本地回环),如果不剔除,速度会翻倍。我们写了个过滤器,只把真实网卡(WiFi、以太网)的流量加起来。

进程列表

做完监控,接下来就是那个密密麻麻的进程列表了 (ProcessListView.swift)。

这里有个大坑: 权限 。

  • 如果你是普通用户运行,macOS 的 SIP(系统完整性保护)不让你看别人的进程内存。
  • 所以我做了一套 Fallback(回退)机制 :
    • 先试着用高级 API (task_for_pid),如果系统报错说 “没权限”;
    • 我们立马切换到 libproc 库的 proc_pidinfo 。虽然拿不到极度精确的内存细节,但至少能把 CPU、内存占用显示出来,保证不白屏。

还有一个痛点优化: “打开文件位置” 。
以前点击这个,会跳转到 App 里面的二进制文件(比如 Safari.app/Contents/MacOS/Safari )。用户会一脸懵。
我们写了个正则逻辑:如果路径里包含 .app ,就自动截断路径,直接选中那个 App 图标。这就很符合直觉了。

画图

数据有了,得画出来。
在 PerformanceView.swift 里,我们用 SwiftUI 的 Path 画贝塞尔曲线。
为了让波形图平滑,我维护了一个长度为 60 的数组(代表最近 60 次采样),每次新数据进来,就把最老的数据挤出去(FIFO 队列),然后重绘线条。

能做什么

系统级性能监测

CPU

提供基于内核 Ticks 差值计算的实时负载分析,可以显示 CPU 利用率,实时绘制波形图

内存

实现内存压力 (Memory Pressure) 实时评估,精确展示、内存分页状态,内存使用率

磁盘 I/O

基于 IOKit 驱动层的数据采集,提供全系统块设备 的实时读写吞吐量监控。

网络流量

支持多网卡流量聚合 (Interface Aggregation) 及回环过滤,提供精确的上下行速率统计。

高级进程管理

进程结束

进程查看文件位置

总之,Windows 上的主要功能都有(不想写了)

硬件信息

可以查看当前设备的基本硬件信息

彩蛋

连续点击几下设备名称,就会可以进入一个

(自己去看)

的功能

「合法使用」!

如何安装?

只支持 macOS14 + 系统,M2 + 芯片(M1CPUData 算不出来,也不知道为什么)

App 文件:

XH Task Manager.zip

关于开源

这个项目目前还很不成熟,并且设计暴露系统 API,所以目前暂时不开放原代码。


📌 转载信息
转载时间:
2026/1/18 08:42:25