记一次服务器跑 Python 脚本踩坑的小排查

最近在服务器上部署一个 Python 脚本，用来拉取数据做报表整理和日志归档。分享下碰到的小问题。脚本逻辑挺简单的，写完在本地测过没啥毛病，就直接丢到服务器上跑了。结果刚放上去就遇到个挺搞人的事：用 nohup python3 archive.py > run.log 2>&1 & 扔到后台，关了 SSH 以为完事了，过会儿上去看 run.log，里面居然就开头打印了两行，后面全是一片空白。当时还以为进程挂了，结果用 ps 一查发现还活着。后来才反应过来是 Python 输出重定向给文件时会默认走缓冲，数据不够多它压根不急着往磁盘写，必须得加个 -u 参数强制刷新（或者在 print 里写 flush=True），日志才能实时看得到。好不容易日志能正常打了，跑了几天又突然歇菜。去翻日志最后几行，干干净净，一个报错堆栈都没有，直接凭空蒸发了。没报错反而是最烦的，排查了一圈去翻 dmesg -T，果然在内核日志里看到被系统的 OOM Killer 给掐死了。说白了就是代码写得太随手，几十万条数据全在循环里往同一个 list 里面 append，自己电脑内存大不觉得，服务器就 2G 内存，哪遭得住这么造。后来只能老老实实改成分段读写，顺便随手给机器加了个 2G 的 swap 分区兜底，内存这块才算消停。再后来觉得常驻后台占资源，干脆配个 crontab 每天凌晨跑一次得了，结果定时任务一跑又给我报 ModuleNotFoundError 找不到 pandas。手动去目录敲命令明明跑得飞起，查了下才想起来 cron 执行时根本不带用户环境的 PATH，调用的解释器路径不对。最后还是得老老实实写全套绝对路径，包括先 cd 进去再用具体的 /usr/bin/python3 去执行才算彻底搞定。平时在自己电脑上折腾习惯了，挪到线上哪怕是个几十行的小脚本，遇到环境和资源限制还是容易踩这些细碎的坑。