Linux系统监控脚本：基于Miniconda-Python3.9实时查看资源

Linux系统监控脚本：基于Miniconda-Python3.9实时查看资源

在AI模型训练任务跑了一整晚后突然中断，日志却只留下一行Killed——这种场景你是否似曾相识？问题往往出在资源耗尽，而开发者毫无察觉。当深度学习实验动辄持续数天，系统稳定性就成了隐形瓶颈。更糟的是，不同设备间“本地能跑，服务器报错”的环境差异，让调试变得异常低效。

有没有一种方式，既能快速搭建干净的Python环境，又能实时掌握CPU、内存、磁盘的运行状态？答案是肯定的：Miniconda + Python 3.9 +psutil的组合，正悄然成为科研与工程团队中的“标准配置”。

为什么是Miniconda-Python3.9？

传统Python环境的问题太常见了：全局安装包导致版本冲突、项目迁移时依赖缺失、多人协作中环境不一致……这些问题在复杂项目中尤为突出。Virtualenv虽然提供了一定隔离，但对非Python依赖（如BLAS库、CUDA工具链）束手无策。

Miniconda则从根本上改变了这一局面。它不像Anaconda那样预装上百个科学计算包，而是仅包含conda包管理器和Python解释器，初始体积通常不到100MB。这意味着你可以把它轻松部署到边缘设备或云实例上，再按需安装所需组件。

更重要的是，conda不仅管理Python包，还能处理C/C++库、编译器甚至R语言环境。比如你在Jetson Nano上部署一个视觉推理服务，可能需要OpenCV、TensorRT和PyTorch，这些都可以通过一条命令统一安装并解决依赖冲突：

conda install pytorch torchvision tensorrt opencv -c pytorch -c nvidia

而这一切的基础，正是Miniconda提供的强大依赖解析能力。它会构建一个满足所有约束的软件栈，避免出现“某个包升级后其他模块崩溃”的尴尬局面。

至于为何选择Python 3.9，这并非偶然。尽管Python已发布至3.12版本，但在许多企业级AI平台中，3.9仍是官方支持的基线版本。PyTorch 1.8到1.12、TensorFlow 2.4到2.7均完整兼容该版本，且绝大多数第三方库已完成ABI稳定化，极少因底层接口变动引发运行时错误。

根据JetBrains 2022年开发者调查，Python 3.9依然是当时使用最广泛的版本之一。对于追求稳定性的科研与生产环境而言，不必盲目追新，选一个经过时间验证的版本反而更可靠。

实时监控的核心：psutil实战

要编写一个真正有用的监控脚本，光打印几行数据远远不够。我们需要的是精准采集、合理频率、可扩展输出的能力。以下是一个经过优化的系统信息采集函数：

import psutil import time from datetime import datetime def get_system_info(): """ 获取关键系统资源指标 """ # CPU使用率（1秒平均） cpu_percent = psutil.cpu_percent(interval=1) # 内存（单位GB，保留两位小数） memory = psutil.virtual_memory() mem_total = round(memory.total / (1024**3), 2) mem_used = round(memory.used / (1024**3), 2) mem_percent = memory.percent # 根目录磁盘使用情况 disk = psutil.disk_usage('/') disk_total = round(disk.total / (1024**3), 2) disk_used = round(disk.used / (1024**3), 2) disk_percent = disk.percent # 网络I/O增量（本次与上次差值） net_io = psutil.net_io_counters() print(f"[{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}]") print(f"CPU: {cpu_percent}% | " f"Mem: {mem_used}/{mem_total}GB ({mem_percent}%) | " f"Disk: {disk_used}/{disk_total}GB ({disk_percent}%)") if __name__ == "__main__": while True: get_system_info() time.sleep(5) # 每5秒采样一次

这个脚本看似简单，实则暗藏细节：
-interval=1确保CPU采样不是瞬时值，而是1秒内的平均负载，更能反映真实压力；
- 所有数值转换为GB单位，便于人类阅读；
- 输出格式紧凑，适合滚动观察或重定向至日志文件；
- 5秒间隔平衡了响应速度与系统开销——过于频繁（如0.1秒）反而可能影响被监控系统的性能。

你只需在一个激活的Conda环境中执行：

conda install psutil python monitor.py

即可看到类似输出：

[2025-04-05 14:23:10] CPU: 68.2% | Mem: 12.45/31.20GB (39.9%) | Disk: 89.12/256.00GB (34.8%)

构建完整的监控工作流

真正的价值不在于单个脚本，而在于整个开发运维闭环。设想这样一个典型流程：

你正在远程调试一台GPU服务器上的训练任务。通过SSH登录后，先创建专用环境：

conda create -n sys_monitor python=3.9 -y conda activate sys_monitor conda install psutil matplotlib jupyter -y

接着启动Jupyter以便可视化分析：

jupyter notebook --ip=0.0.0.0 --port=8888 --no-browser --allow-root

此时可通过浏览器访问图表界面。若只想后台运行监控，也可直接用nohup守护进程：

nohup python monitor.py > system.log 2>&1 &

为了长期保存数据趋势，建议将结果写入CSV文件，便于后续分析：

import csv from datetime import datetime def log_to_csv(data, filename='system_log.csv'): file_exists = False try: open(filename).close() file_exists = True except FileNotFoundError: pass with open(filename, 'a', newline='') as f: writer = csv.writer(f) if not file_exists: writer.writerow(['timestamp', 'cpu_percent', 'mem_used_gb', 'mem_total_gb', 'disk_used_gb']) writer.writerow([ datetime.now().strftime('%Y-%m-%d %H:%M:%S'), data['cpu'], data['mem_used'], data['mem_total'], data['disk_used'] ])

这样即使程序意外终止，历史数据也不会丢失。

可视化的点睛之笔

终端文本虽实用，但人类对图形更敏感。结合matplotlib绘制动态折线图，能让资源波动一目了然：

import matplotlib.pyplot as plt import psutil plt.ion() # 开启交互模式 fig, ax = plt.subplots(figsize=(10, 4)) xs = list(range(100)) # 显示最近100个点 ys = [0] * 100 while True: cpu = psutil.cpu_percent(interval=1) ys.append(cpu) ys = ys[-100:] # 保持长度 ax.clear() ax.plot(xs, ys, color='tab:blue') ax.set_ylim(0, 100) ax.fill_between(xs, 0, ys, alpha=0.3, color='tab:blue') ax.set_title("实时CPU使用率", fontsize=14) ax.set_ylabel("CPU (%)") ax.grid(True, linestyle='--', alpha=0.5) fig.canvas.draw() fig.canvas.flush_events()

这段代码会在窗口中持续更新曲线，绿色填充区域增强视觉感知。当你在训练模型时，可以直观看到每轮迭代带来的CPU峰值，判断是否存在数据加载瓶颈。

当然，在无GUI的服务器上运行时，可改用Agg后端生成静态图像并定期保存，或集成Flask暴露API供前端调用。

工程实践中的关键考量

环境一致性保障

团队协作中最怕“我这边好好的”。解决方案是导出精确的环境快照：

conda env export > environment.yml

该文件会记录当前环境的所有包及其版本、来源频道，他人可通过：

conda env create -f environment.yml

重建完全相同的环境。相比requirements.txt仅列出pip包，environment.yml连Python解释器本身都锁定，真正实现“所见即所得”。

安全与稳定性加固

开放Jupyter远程访问时，务必设置Token或密码：

jupyter notebook password

或将服务绑定到本地，并通过SSH隧道转发：

ssh -L 8888:localhost:8888 user@server

防止未授权访问。同时，使用tmux或screen运行长周期任务，避免网络断连导致进程中断：

tmux new-session -d -s monitor 'python monitor.py'

性能与扩展性权衡

监控本身也是负载。对于资源紧张的边缘设备（如树莓派），应适当拉长采样间隔至10~30秒；而对于高性能服务器，可增加GPU监控（借助pynvml）或进程级追踪：

for proc in psutil.process_iter(['pid', 'name', 'cpu_percent']): if proc.info['cpu_percent'] > 50: print(f"高CPU进程: {proc.info['name']} (PID: {proc.info['pid']})")

帮助定位异常行为源头。

这套组合为何值得推广？

这套方案的价值远超“写个监控脚本”本身。它代表了一种现代化的工程思维：环境即代码、监控即服务、工具链标准化。

在AI实验室中，它可以作为学生理解操作系统资源调度的教学工具；在边缘计算节点上，能及时发现内存泄漏或存储耗尽风险；在云服务器集群里，则可作为自动化运维的基础模块，配合告警系统实现主动干预。

更重要的是，它的门槛足够低——无需复杂的Prometheus+Grafana堆栈，也能快速获得可观测性。对于中小团队或个人开发者而言，这是一种“够用、好用、耐用”的轻量级解决方案。

当你的下一个训练任务即将开始，请先运行一遍这个脚本。也许你会发现，那个一直困扰你的OOM问题，其实早在内存缓慢爬升的过程中就已埋下伏笔。而这一次，你不会再错过预警信号。