psutil.virtual_memory().available 是最接近“真实可用内存”的字段，但它仅表示内核估算的无需换页即可满足的内存，未考虑碎片、cgroup 限制或 locked 页面，需结合 percent 看趋势，容器中应读取 cgroup 内存路径。
psutil.virtual_memory() 返回的字段到底哪个是“真实可用内存”
很多人一上来就用 psutil.virtual_memory().available，以为这就是系统当前能立刻分配给新进程的内存，结果发现程序还是 OOM。其实不是它不准，而是理解偏差：这个值是内核估算的“无需换页即可满足的内存”，但不等于“你随便 malloc 就能成功”。它没考虑内存碎片、cgroup 限制、或某些被 locked 的页。
实操建议：
-
available是最接近“可用”的字段，但务必配合percent看趋势，单次采样意义有限 - 监控报警阈值别设死在 90%，Linux 有 page cache 回收机制，
available可能在压力下快速回升 - 如果跑在容器里（比如 Docker），
psutil默认读的是宿主机视图，得手动挂载/sys/fs/cgroup并用psutil.sensors_battery()？不对——那是错的，应该用psutil.Process().memory_info()查自身，或解析/sys/fs/cgroup/memory/memory.usage_in_bytes
为什么 psutil.disk_usage('/') 总比 df -h 少几个 GB
这是权限和统计口径差异导致的常见困惑。psutil.disk_usage() 调用的是 os.statvfs()，走的是标准 C 库接口；而 df 默认显示的是“用户可用空间”，会扣除 root 保留块（通常是 5%）并考虑当前挂载选项（如 noatime 不影响，但 usrquota 会影响）。
实操建议：
- 检查是否挂载了
ext4且设置了保留块：tune2fs -l /dev/sda1 | grep 'Reserved block count' - 用
psutil.disk_usage('/').free和df --output=avail / | tail -1对比，二者数值应一致（单位都是字节）；如果不一致，大概率是 Python 进程没权限读取某些挂载点的 statvfs，会 fallback 到父目录统计 - 监控脚本里别只看
total，重点盯free和used的变化速率，突发写入时free下降快于df显示，说明 page cache 正在被刷盘
psutil.cpu_percent() 第一次调用总是返回 0.0 怎么办
因为 psutil.cpu_percent() 是差分计算：它需要两次采样间隔才能算出百分比。首次调用只是“打点”，内部记录起始状态，返回 0.0 是设计使然，不是 bug。
实操建议：
- 启动监控前，先调用一次
psutil.cpu_percent(percpu=False)（不带参数或设为None），等至少 0.1 秒后再调第二次，才得到有效值 - 多核场景下慎用
percpu=True：返回列表长度等于逻辑 CPU 数，但索引不对应物理核心编号，也跟taskset绑定无关——它只是按内核报告顺序排列 - 长期运行的采集任务，别每秒都调用：设
interval=1.0即可；太短（如 0.01）会导致系统调用开销反超收益，还可能因时间精度不足返回 0.0 或 nan
在 systemd 服务里跑 psutil 监控脚本，为什么 get_process_list() 拿不到其他用户的进程
systemd 默认启用 PrivateTmp=yes 和 ProtectSystem=full，还会限制 /proc 可见性。即使你是 root 启动的服务，psutil.process_iter() 默认只遍历当前用户命名空间可见的进程，而普通用户进程对 root 服务不可见，除非显式放开。
实操建议：
- 在 service 文件里加两行：
ProtectProc=no和ProcSubset=all（systemd v244+ 才支持后者；老版本只能用ProtectProc=off） - 避免用
psutil.process_iter(attrs=['pid', 'name'])一次性拉全量——容易触发 PermissionError；改用try/except包裹单个proc.info访问 - 如果只需监控本服务相关进程，直接用
psutil.Process().children(recursive=True)更轻量、更可靠
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
