psutil.virtual_memory().percent 是判断内存压力最可靠的指标，应结合连续采样、冷却窗口、服务状态校验、日志记录和异常处理构建稳健的自动重启机制。
如何用 psutil 实时获取内存使用率
直接读 /proc/meminfo 容易漏掉缓存和缓冲区的干扰，psutil.virtual_memory() 返回的是内核实际可用内存的准确快照。它返回的 percent 字段是已用物理内存占总物理内存的百分比（不含 swap），这个值最贴近“服务是否可能 OOM”的真实判断依据。
- 不要用
psutil.swap_memory().used判断内存压力——swap 活跃只说明有交换，不代表物理内存已耗尽 -
psutil.virtual_memory().available是预估可用内存，但阈值设置建议仍用percent，更稳定、跨系统一致 - 采样间隔别设太短（如
time.sleep(1)），频繁调用psutil本身会轻微抬高 CPU 和内存开销
重启服务前必须验证进程是否存活且可控制
很多脚本直接执行 os.system("systemctl restart myapp")，但没检查当前用户是否有权限、服务名是否存在、或服务是否根本没用 systemd 管理——结果就是“以为重启了，其实什么都没发生”。
- 先用
subprocess.run(["systemctl", "is-active", "--quiet", "myapp"])检查服务状态，返回码 0 表示 active，非 0 表示 inactive 或不存在 - 用
subprocess.run(["systemctl", "show", "-p", "Type", "myapp"], capture_output=True)确认服务类型（Type=simple和Type=forking的重启行为不同） - 如果服务用
supervisord或裸进程管理，得改用kill -TERM $(cat /var/run/myapp.pid)+ 启动命令，不能硬套 systemctl
避免误重启：加双保险阈值和冷却窗口
内存瞬时飙到 95% 很常见（比如日志刷盘、GC 暂停），立刻重启反而引发雪崩。必须引入持续超标判定和操作冷却机制。
- 连续 3 次采样（比如每 30 秒一次）都 > 90%，才触发动作；单次超阈值只发告警不重启
- 重启后立即写一个时间戳文件（如
/tmp/myapp_last_restart），下次启动前检查：若距上次重启不足 5 分钟，跳过本次重启并记录 warn - 把阈值和冷却时间做成配置变量（如
RESTART_THRESHOLD = 90,COOLDOWN_SECONDS = 300），别硬编码在 if 判断里
日志和错误处理不能只靠 print
print("Restarting...") 在后台运行的守护进程中根本看不到，出错也没法追溯。必须用 logging 写文件，并捕获关键异常。
立即学习“Python免费学习笔记（深入）”；
- 用
logging.basicConfig(filename="/var/log/memory-guard.log", level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") - 对
subprocess调用必须加try/except subprocess.CalledProcessError，记录 stderr 输出，否则 systemctl 权限拒绝或服务未定义时脚本静默失败 - 内存采集本身也可能失败（如容器环境无权限读取
/proc），要包一层try/except RuntimeError并 fallback 到警告日志
真正难的不是写个重启逻辑，而是让这个脚本在凌晨三点内存突增时，既不漏判、也不乱判，还能告诉你“为什么这次没重启”——所有判断路径都要有日志落点，所有外部依赖都要有降级或报错出口。
