2006年的电脑1GB内存机械硬盘还在嗡嗡作响2024年我把它重新翻了出来。装上Ubuntu 14.04在这台老机器上跑Python爬虫加定时自动化让它当一台“采集服务器”用。很多人觉得这种老机器早就该进回收站但实际上它对资源的需求远没有想象中那么高装一个轻量Linux系统后跑Python脚本完全没问题。这篇内容适合手上正好有旧电脑、想折腾点自动化任务但又不想花钱租服务器的朋友也适合对Linux环境下Python环境搭建、定时任务配置有需求的人。先说结论这台06年的老电脑在Ubuntu 14.04上跑Python爬虫和自动化脚本目前已经稳定运行了好几个月。我给它分配的任务不算重每天定时抓取几个公开资讯站点的更新内容做关键词过滤后落盘偶尔手动跑一下数据清洗脚本。整机功耗也就几十瓦放在角落里当个“数字管家”正合适。1. 为什么碰一台06年的机器硬件与系统的现实考量1.1 老电脑的配置与系统选型逻辑我手头这台机器是当年很常见的品牌机CPU是单核奔腾级别内存1GB硬盘80GB机械盘。这套配置放到今天连开机都费劲但跑Linux命令行系统还是绰绰有余的。系统选型上我几乎没有犹豫就选了Ubuntu 14.04 LTS原因很简单它发布的时候这类老硬件还在服役期内核和驱动的兼容性经过了大量真机验证对新硬件反而没有那么挑剔。选择14.04还有一个现实因素它对内存的占用很小纯命令行模式下系统启动完只占200MB左右内存剩下700MB以上可以全部给Python任务使用。新版本的Ubuntu反而更吃资源装上之后光是桌面服务就能把1GB内存吃干所以不是越新越好而是越合适越好。当然14.04在2021年停止了官方支持软件源也已经迁移到了old-releases。这意味着不能像以前那样直接apt-get update后装新包必须手动修改sources.list源地址。这一点可能劝退很多人但实际操作起来并不复杂就是把源地址从archive.ubuntu.com换到old-releases.ubuntu.com然后apt-get update就可以正常用了。我后面会详细说这个配置。1.2 老系统上的硬性约束在这台机器上开发最大的问题不是算力而是内存和磁盘IO。1GB内存意味着我不能开重型工具链什么IDE、现代浏览器、Docker一类想都不要想。但Python脚本本身内存开销很小一个requests请求加解析页面大约占用30-50MB只要不写特别离谱的并发程序内存完全够用。磁盘IO是另一个容易被忽视的瓶颈。机械硬盘的随机读写速度很慢这意味着大量小文件读写比如爬虫把每条数据存成单独的文件会非常吃力。我的做法是把所有数据写进一个JSON Lines格式的大文件里追加写入避免频繁创建小文件。这样既减少了磁盘寻道开销数据处理时也方便。还有一个容易被忽略的点这台老机器没有硬件虚拟化支持也没有高效的电源管理。如果系统负载长期处于高位CPU发热会比较明显在机箱里加个风扇能有效延长寿命。我实际测试下来跑单线程Python爬虫时CPU占用大约在30%以内发热可以接受但如果并发一多CPU占用直奔100%温度也跟着上去。2. 系统层面的瘦身与稳定性优化2.1 最小化安装和必要服务清理Ubuntu 14.04安装时选择“Ubuntu Server”模式安装过程中取消勾选所有附加服务只保留最基础的OpenSSH。这样装出来的系统非常干净没有桌面、没有打印服务、没有蓝牙栈连NetworkManager都可以不要。安装完毕后我关闭了所有用不到的服务。第一步先看当前开了哪些服务sudo service --status-all这里面很多东西对爬虫任务毫无意义比如cups打印服务、bluetooth蓝牙、whoopsie崩溃报告。全部停用并取消开机自启sudo stop cups sudo stop bluetooth sudo stop whoopsie sudo stop apport这些操作能省下大约100MB内存和一定的CPU轮询开销。对现代电脑来说这点资源不值一提但对1GB内存的老机器来说省下来的每一分资源都有意义。内核层面还可以做一点调整。Ubuntu默认的pid_max、文件句柄等参数对服务器场景做了保守设置普通应用够用不需要改动。真正值得调的是swap策略。系统默认的swappiness值是60这个值放在老机械硬盘上意味着系统会频繁把内存页换到磁盘上导致整体变慢。我直接改成10让系统优先使用物理内存只有真正不够时才用swap。echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf sudo sysctl -p2.2 内存与磁盘的细节优化1GB内存跑爬虫确实紧张一些但可以通过合理规划来缓解。第一swap分区在安装系统的时候我就专门分了2GB放在单独的swap分区而不是swap文件因为swap文件在机械硬盘上会读写得更加零碎性能更差。如果系统跑着跑着内存吃紧swap的命中率就会上升而机械硬盘上的swap读写速度只有几十MB/s程序会明显卡顿。我的优化思路是尽量避免触发swap控制爬虫的并发数、定期重启脚本清理内存碎片、用Python的gc模块手动触发垃圾回收。磁盘方面的优化是调整atime挂载参数。默认情况下系统每次读取文件都会更新访问时间戳这会导致机械硬盘额外的写入操作。我在/etc/fstab里给根分区加了noatime参数减少无意义的磁盘写入。还有一个在14.04上很实用的优化用tmpfs挂载/tmp目录。爬虫运行过程中产生的临时文件比如session的状态文件、csrftoken缓存都放在内存里省去了磁盘读写。tmpfs /tmp tmpfs defaults,noatime,mode1777 0 0日志也需要处理。Ubuntu默认的rsyslog会把系统所有日志都写下来爬虫跑起来后每天的日志量不容小觑。我直接把rsyslog的服务停掉由Python脚本自己统一记录日志统一管理。这样既减少了磁盘占用又避免了日志文件权限混乱的问题。3. Python环境搭建在老系统上准备开发环境3.1 选Python 3还是Python 2Ubuntu 14.04系统自带了Python 2.7.6和Python 3.4.3。这也是很多人被这个问题困住的关键点官方源里并没有更新版本的Python。选择Python 2是绝对不建议的因为连官方都停止维护了很多新库版本也不支持。Python 3.4虽然现在过时了但运行一些老版本兼容的库还是可以的。我当时评估了一下两个方案方案A使用系统自带的Python 3.4加pip优点是安装快、几乎零编译成本缺点是不能用最新版的第三方库方案B用pyenv编译最新的Python 3.10以上优点是用新特性缺点是在这台单核老机器上编译Python大约需要三四个小时而且很可能因为内存不足而失败我最后选了方案A。爬虫任务需要的库并不多requests、lxml、beautifulsoup4这三个就足够应付大多数场景了。这些库在Python 3.4时代就已经很成熟没必要为了“用新版”去花几个小时编译。确定环境之后下一步就是配置pip。3.2 pip源与依赖库安装的坑系统自带的pip对应的是Python 3.4时代的版本默认源指向pypi.org。问题来了老版本pip使用的TLS协议已经过期连不上现在的PyPI服务器。在配置源的时候需要格外注意协议选项。我的做法是先升级pip到兼容版本再把默认源指向国内镜像sudo apt-get update sudo apt-get install python3-pip pip3 install --upgrade pip9.0.3这里必须锁定pip版本因为pip 10以上最低要求Python 3.5装不上。pip 9.0.3是支持Python 3.4的最高版本。然后配置pip源在~/.pip/pip.conf里写入[global] index-url https://mirrors.aliyun.com/pypi/simple/ trusted-host mirrors.aliyun.comtrusted-host必须写上因为老版本pip访问HTTPS镜像站时证书校验可能失败。我实际测试过不写这个配置的情况下pip会直接报证书错误。接着安装核心依赖pip3 install requests beautifulsoup4 lxml retryinglxml在Python 3.4环境下的轮子文件很稀少如果pip下载的是源码包编译时需要libxml2和libxslt的系统库。我在安装前先补装了系统依赖sudo apt-get install libxml2-dev libxslt1-dev python3-dev如果不装这些lxml编译会直接报错“fatal error: libxml/xmlversion.h: No such file or directory”。这属于比较经典的依赖缺失提前装好能省不少事。3.3 虚拟环境隔离这台机器上我只跑一个爬虫项目理论上不用虚拟环境。但实际开发中你会因为各种原因尝试不同版本的依赖一旦装乱了系统自带的Python环境就被污染了。我建议还是用virtualenv隔离起来一劳永逸。Ubuntu 14.04的软件包里没有python3-virtualenv需要先用pip安装pip3 install virtualenv cd /home/ubuntu/projects virtualenv -p python3 spider_env source spider_env/bin/activate之后安装任何依赖都在这个环境里操作系统自带的Python环境保持干净。老机器上每重装一次依赖都很耗时隔离好环境之后迁移或重建也方便。虚拟环境里的pip一样要设置同样的源配置。别忘了在spider_env/lib/python3.4/site-packages旁边建pip.conf不然虚拟环境会继承系统配置有时因环境变量问题失效。放进SPIP_CONFIG_FILE环境变量指向的路径最稳妥。4. 爬虫任务的设计与实现4.1 单线程轻量爬虫的核心写法在老机器上写爬虫第一原则就是“克制”。不要一上来就是Scrapy框架或者大规模异步爬虫那在这台机器上根本玩不转。我用的是requests 标准库组合单线程循环抓取抓完一个休息几秒简单直接。下面是我实际跑的核心代码逻辑的简版import json import time import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } def fetch_page(url, retry3): for attempt in range(retry): try: resp requests.get(url, headersHEADERS, timeout15) resp.raise_for_status() return resp.text except (requests.ConnectionError, requests.Timeout) as exc: print(f第{attempt 1}次尝试失败: {exc}) time.sleep(5 * (attempt 1)) return None def parse_and_extract(html): soup BeautifulSoup(html, lxml) items [] for tag in soup.select(.article-list a): title tag.get_text(stripTrue) link tag.get(href) if title: items.append({title: title, link: link}) return items这里的核心是别的而是时间控制。每一次循环之间休息5-10秒既避免对目标站点造成压力也防止老机器CPU过热。对单核CPU来说频繁的网络请求上下文切换反而会让效率变低所以这里宁慢勿快。为什么是单线程而不是直接用线程池因为在这台老机器上GIL锁加单核CPU的组合意味着多线程对CPU密集型任务几乎没有提升而对IO密集型任务又有切换开销。单线程配合合理的sleep反而更稳定这是我在几轮实测后得到的结论。4.2 合规与反爬的正当姿势现在很多网站都有基础的反爬策略。我用的是最朴素的方案伪装浏览器的User-Agent、设置合理的请求间隔、遵循robots.txt规则。这不算什么高深技巧但足够应对那些只做基础校验的站点。不建议做对抗性的绕过操作比如验证码识别、代理池轮换这种。一是技术上的复杂度会成倍上升二是有潜在的法律风险。爬虫这事最好的原则就是只抓允许抓的抓的时候别影响对方服务数据只做个人研究和学习用途。如果你在做一个别人会来访问的站点想防止被爬虫骚扰思路也是同一个框架的反向限制单IP请求频率、校验User-Agent、针对异常行为返回验证码。理解了服务端的防护思路反过来在写爬虫时就会更清楚边界在哪里。4.3 断点续抓与数据落盘爬虫跑在特殊的老机器上随时可能因为断电、崩溃、内存不足等原因中断。所以数据采集任务必须做成断点续跑的形式。我的做法很简单抓取进度记录在一个单独的状态文件里每次成功抓取一条数据就更新一次进度。下次启动时先读这个状态文件直接跳到断点位置继续。import os class CrawlState: def __init__(self, state_filestate.json): self.state_file state_file self.state self._load() def _load(self): if os.path.exists(self.state_file): with open(self.state_file, r, encodingutf-8) as f: return json.load(f) return {crawled_ids: [], last_url: None} def mark_done(self, item_id): self.state[crawled_ids].append(item_id) self._save() def _save(self): with open(self.state_file, w, encodingutf-8) as f: json.dump(self.state, f, ensure_asciiFalse)这个状态文件每次更新都会覆写一次磁盘。考虑到机械硬盘写入寿命频率其实很低每条数据一次完全没有问题。数据本身追加到当日的数据文件里按天分文件后期好归档。5. 自动化调度与任务看护5.1 crontab定时任务配置细节爬虫脚本写好后剩下的是让它自动运行。Ubuntu 14.04默认使用cron来做定时任务配置方式非常简单。先写一个启动脚本run_spider.sh#!/bin/bash cd /home/ubuntu/projects source spider_env/bin/activate python spider.py logs/spider.log 21启动脚本里有几个细节需要注意。cron执行时默认PATH只有/usr/bin:/bin如果python的路径不在其中需要显式写明绝对路径或者在脚本里先导出PATH。第二个问题是cron不会自动加载用户的环境变量所以虚拟环境的激活必须在脚本内部处理。写好后把这个脚本放到crontab里crontab -e我设置的是每天凌晨3点执行一次避开网站访问高峰0 3 * * * /home/ubuntu/projects/run_spider.sh凌晨3点这个时间点是我特意选的网站服务器负载较低反爬策略相对宽松同时老机器在夜里跑任务也不会影响我做其他事情。如果任务本身更频繁比如几个小时一次可以在crontab里多加几个条目但每天彻底跑完一轮已经是这个场景下的最优选择频率太高反而会给目标站点造成压力。5.2 日志与异常自愈老机器上的爬虫任务最大的敌人是“静默失败”。脚本一旦崩溃没人知道第二天打开数据文件才发现什么都没抓到。我的解决思路是分层看护。第一层是脚本内部的重试机制单次请求失败自动重试3次。第二层是外部的看门狗脚本每隔1小时检查一次爬虫进程是否存活如果发现进程不存在自动重新拉起。#!/bin/bash if ! pgrep -f python spider.py /dev/null; then echo $(date) spider down, restarting logs/guard.log /home/ubuntu/projects/run_spider.sh fi这个脚本挂在同一张crontab表里0 * * * * /home/ubuntu/projects/guard.sh第三层是数据新鲜度校验。我每天早上看一眼数据文件里最新条目的时间戳如果停留在昨天之前说明任务可能出问题了。这种人工巡检配合自动重启已经能覆盖绝大多数故障场景。日志方面不要让脚本直接print了事。我在脚本里加了Logging模块输出到指定日志文件按天切割import logging logging.basicConfig( filenamelogs/spider.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s )机械硬盘上频繁写日志对寿命有一定影响但爬虫的数据量本身不大日志量就更小了完全能接受。如果需要更彻底的方案把日志目录也放到tmpfs上掉电就丢适合那些不需要追溯历史的场景。6. 常见问题与排查实录6.1 问题速查表我在这台老机器上踩过不少坑有些是Ubuntu 14.04特有的老版本问题有些是通用问题。整理成一张速查表方便你遇到同样的报错时快速定位。现象可能原因解决思路apt-get update报404源已迁移到old-releases将sources.list里的archive.ubuntu.com改为old-releases.ubuntu.compip3安装包报证书错误老版本pip TLS兼容问题使用pip 9.0.3并在pip.conf中配置trusted-hostlxml编译报xmlversion.h找不到缺少libxml2-devapt-get install libxml2-dev libxslt1-dev python3-dev爬虫运行几小时后变慢内存碎片或swap频繁调整swappiness10必要时定期重启脚本脚本crash后无感知缺少心跳看护加看门狗脚本定期检查进程状态数据文件写入卡顿机械硬盘碎片化或者swap改为追加写入大文件减少零散IOPython代码中文字符编码报错系统locale未设置export LANGen_US.UTF-8确保文件头注释正确crontab任务没有执行日志cron的MAILTO未配置脚本内自己记录日志不要依赖cron输出这里的不少问题都是14.04生命周期结束后的典型症状。如果用的是仍在支持期内的系统很多问题不会出现但老机器跑老系统这些问题几乎是必经之路。6.2 我对这套折腾的个人体会整个过程中我踩过最大的坑反而不在技术层面而在对这台机器的定位。最初我试图让它干太多事情既要跑爬虫又要做数据清洗还想时不时跑个自动化测试脚本。结果就是什么任务都慢内存频繁告急整个系统状态极不稳定。后来我把这台机器定位成“单一任务采集器”它就负责按计划爬取数据别的什么都不做。数据清洗脚本放在现代电脑上手动跑分析结果再存回来。这样职责单一之后稳定性立刻上了一个台阶连续跑了几个月都没出过大问题。这其实是一个很重要的思考老电脑复活的决心和技术论证再充分如果给它的任务超出硬件能力边界折腾的结局一定不好。找准机器的定位一台06年的电脑也能有它的高光时刻。现在这台电脑还在我书房的角落里安静地跑着每天凌晨3点醒来抓一次数据然后继续睡大觉。功耗极低噪音也低。每隔一周我检查一次数据和日志其他时间不用管它。如果你手上也有一台吃灰的老电脑不妨用这种方式让它重新发挥作用。配置过程中多留一份备份记录好每一个改过的配置文件就算失败了也能随时恢复原状。