深夜十二点半我盯着终端里刷了半小时没停下来的日志那台用来跑量化实盘策略的Windows服务器又一次莫名重启了。检查一圈既不是电源问题也不是内存报错最后还是系统自动更新惹的祸——一个凌晨两点强制安装的补丁直接把我挂单中的策略进程带走了。那晚之后我就意识到一个问题量化交易这行选错计算机操作系统策略代码写得再好也可能白搭。这篇文章想聊的就是量化交易场景下“计算机操作系统”怎么选、怎么配、怎么调。内容覆盖了我从回测、实盘到维护策略主机这几年折腾下来的全部经验包括Windows、Linux、macOS的实测对比系统底层原理在量化场景中的体现Python量化交易策略代码的部署方式量化交易用的数据API怎么选以及PTrade、期货量化这类环境下常被忽略的坑。适合刚开始跑量化策略的新手也适合已经上线但总觉得系统不稳定的同路人。1. 量化交易对操作系统的“硬性要求”和普通办公完全不同很多人觉得操作系统就是个“装软件的平台”Windows能用Linux也能用区别不大。但只要跑过一段时间的实盘策略就会发现量化交易对系统的要求跟办公、打游戏完全是两个维度。1.1 长期无人值守稳定压倒性能量化策略最大的特点就是“机器替你看着盘”尤其低频或中频策略一台服务器跑上一两个星期不关机是常态。这时候操作系统的稳定性直接决定策略能不能持续运行。Windows不是不能做这种事但系统更新、驱动兼容性、偶发的GUI进程崩溃都会成为实盘运行的不稳定因素。我有一次跑了三周的CTA策略就是被Windows自动更新在凌晨给重启掉的当时持仓恰好有隔夜单重启期间行情一变再启动时策略状态和真实持仓已经对不上直接导致当天手工平仓处理费时费力。Linux这类开源系统则完全不同内核本身设计就考虑了长时间运行服务器发行版默认关闭了桌面和自动更新机制理论上跑几个月不重启没有任何问题。我后来把实盘服务器换成Ubuntu Server半年没重启过一次稳稳当当。1.2 I/O、延时与实时性行情在敲门系统在排队量化交易是典型的I/O密集型加延时敏感型应用。你订阅的行情推送、你发出的交易指令每一条都要经过操作系统内核的协议栈、调度器、驱动层。系统处理这些事件的方式直接关系到你的延迟水平。举个例子你在Python里写简单的while True: socket.recv()循环接收行情数据量一上来单线程可能就处理不过来了。高并发、高频的行情订阅必须依赖事件驱动模型而这背后就是操作系统级的多路复用机制。Linux提供了epoll、io_uring这类高性能机制Windows虽然有IOCP但从量化生态的使用广度和代码样例来看Linux明显占优。另外还有时钟精度的问题。我在做时间序列回测时发现Windows的非实时时钟会导致很小的sleep误差几毫秒的偏差在普通应用里无所谓但在需要精确对齐tick数据时会带来数据对不齐的麻烦。Linux的timer精度更高配合实时调度策略能让你在行情处理的竞争中少吃亏。1.3 生态兼容策略代码不只跑在一台机器上一个容易被忽略的点是量化交易从来不是单机行为。你的策略代码可能要部署到券商的PTrade、恒生UFT这类托管环境里或者需要接行情源、数据API、数据库、消息队列。这些服务端软件对系统的要求几乎一边倒地倾向Linux。我再分享一个实际感受当时把实盘系统从Windows迁移到Linux原本跑的很多回测脚本只需稍微调整路径分隔符和编码就能在Linux上跑通。而券商提供的PTrade量化环境底层本身就是Linux服务器策略上传后其实是在Linux上运行的。你要是从Windows本地代码直接搬过去不去提前理解Linux环境下的进程、文件权限、资源限制可能上线第一天就报错。1.4 安全与审计资金相关的事情权限要抠细节实盘策略主机上运行的是拿真金白银下注的程序安全性和可审计性比什么都重要。Linux的权限模型对普通用户有严格的读写限制万一策略代码里有Bug不至于把整个系统文件都搞坏定时任务、日志记录也更透明。我之前一台Windows服务器中过挖矿病毒因为远程控制相关端口被扫到折腾了整整一天才清理干净。Linux服务器如果只开放SSH再配合密钥登录和防火墙被攻击面要小很多。运维视角也更清楚一切都靠配置文件和命令管理谁在什么时候改过什么都能通过日志查出来。2. Windows、Linux、macOS三大系统在量化场景下的实测比较既然要说“最佳”就绕不开三大家底的正面对比。我常年在这三个系统上切换分别总结一下真实体感。2.1 Windows回测友好但生产环境坑不少Windows的长处是图形界面友好、软件生态普及。如果你刚开始学量化用Windows跑一跑聚宽、米筐的本地研究环境或者把vn.py这类框架装在Windows上回测一些日线级策略是完全没问题的。很多开源量化库的文档和示例默认用Windows截图新手照做不容易卡壳。但到了生产环境Windows的问题就会集中爆发。自动更新无法彻底关闭策略跑得正好的时候被系统服务抢占资源是常事。还有一个让人抓狂的问题是内存管理Windows的进程内存回收不及时Python跑重度回测后内存容易越占越高短时间连续跑多个回测时会出现内存不足而实际上并没有那么多进程在占用。如果你只是做研究、写代码、看图表Windows没问题。但你打算让策略无人值守跑实盘我建议至少得用Windows Server版本然后把自动更新策略、远程管理权限都配置成“生产模式”才能勉强上线但相比Linux仍然是费心不少。2.2 Linux发行版量化实盘服务器的主流答案Linux下的量化开发体验整体上是“前面麻烦后面省心”。你要先把环境配好安装Python、装TA-Lib之类的C扩展库、搭建PostgreSQL、Redis这些操作对新手来说比Windows要复杂一点但每一步都有迹可循。配置好之后Linux带来的好处特别实在。systemd可以帮你写一个服务文件策略崩溃了自动拉起开机自动启动资源占用超限自动降级。cron可以精确到分钟执行数据更新任务。我用Ubuntu Server跑期货量化Python策略连续稳定运行一个月是基本盘中的基本盘。有一个容易被忽略的点Linux发行版的版本策略。Debian和RHEL系更保守软件版本旧但很稳定Ubuntu LTS则是社区资料最丰富、踩坑答案最多。量化交易策略代码本身对系统版本不是特别敏感但对Python版本有依赖建议选能装到Python 3.10以上版本的发行版否则有些较新的库装不上。2.3 macOS适合写代码不适合长期跑策略macOS的核心优势是类Unix底层加漂亮界面开发体验极佳。如果你用MacBook写着玩回测一些小策略那很顺手行情API、Python、Docker都是原生支持不会像Windows那样出现路径和编码的奇怪问题。但Mac不适合当实盘服务器。一方面是硬件贵普通Mac mini笔记本长期高负载跑策略散热和寿命都不理想另一方面是macOS的更新策略越来越激进我遇到过几次系统后台升级导致Python环境崩溃的情况。有同行把Mac mini当服务器用了一年之后硬盘I/O明显变慢查下来是系统日志和Spotlight索引吃掉了太多磁盘资源。所以我的结论很明确开发机可以用Mac但实盘主机还是选纯Linux服务器。2.4 横向对比表延迟、稳定性、生态、运维成本维度WindowsLinuxUbuntu Server / RHEL系macOS上手友好度高图形界面完备中低命令行为主高Unix内核界面系统稳定性中自动更新是隐患高可长期不重启中系统更新偶发风险事件驱动性能IOCP能力不错但生态少epoll/io_uring成熟kqueue不错但部署场景少量化相关工具对vn.py、聚宽等支持好支持最全面服务端首选开发体验好生产不推荐资源占用高GUI和后台服务常驻低净系统内存占用小中后台服务多运维管理GUI组策略可远程桌面SSH/命令行脚本化程度高有限不适合真正服务器运维社区答疑数量多最多文档更系统较少针对量化的运维经验适合角色研究/回测/新手入门实盘/数据服务/程序化部署开发测试如果你是个人开发电脑上跑回测可以继续用Windows或Mac但只要涉及实盘、自动交易、长期进程Linux就是目前量化圈主流的选择。3. 从操作系统底层看“为什么Linux更适合量化”很多人推荐Linux时只说“稳定、免费、命令行好用”这个理由太虚了。真正支撑Linux在量化领域胜出的是底层机制设计上的优势。3.1 进程调度与实时性CFS、nice 和 PREEMPT操作系统负责把CPU时间片分配给各个任务。Linux默认的CFS调度器核心思想是让所有任务公平分享CPU每个进程都有个nice值值越小优先级越高。量化策略里行情接收线程和策略计算线程如果共存在一台机器上可以通过调整nice值和CPU亲和性把关键线程绑定到固定核心上减少调度延迟。Windows的调度器设计更偏向桌面交互响应后台任务的优先级动态调整比较频繁容易导致策略线程在行情堆积时被“降频处理”。Linux下则可以把实盘进程设置为SCHED_FIFO这种实时调度策略让关键路径更少被其他进程打扰。当然实时调度要慎用用不好会让系统卡死但对行情处理这种单线程任务设置优先级是实打实的收益。我在自己的期货策略里会做一件事把接收行情和计算信号的线程set_affinity到物理核0和1其余回测任务全部用nice 10跑。这样即使回测任务同时进行行情接收也不会被拖累。3.2 内存与文件系统页面缓存、共享内存、零拷贝量化系统里频繁发生的事就是读行情数据、读历史切片。Linux的文件系统会充分利用空闲内存做页面缓存同一份数据被多次读取时直接从内存返回不需要反复访问磁盘。这对回测场景特别友好第一次加载数据慢之后再次读取快得多。进程间通信也是一大块。策略进程和数据采集进程往往分离Linux的共享内存机制可以让两个进程同时访问同一块行情数据不需要走网络协议栈延迟能降到微秒级。相比之下如果像一些Windows程序那样用命名管道每次写读都经过内核拷贝效率差不少。还有零拷贝技术比如sendfile、mmap能让行情转发服务在数据量巨大时减少一次内存拷贝CPU占用低一大截。这些特性普通用户平时感知不到但当你的数据吞吐量到一定程度差别会非常明显。3.3 管程和协程并发编程视角下的策略代码大学《计算机操作系统》课程里汤小丹教材重点讲过管程Monitor的概念。管程是一种并发控制结构把共享资源的操作封装起来同一时间只允许一个线程进入用来解决多线程同步互斥问题。在量化场景里这个思想太常用了行情缓存、订单状态机、持仓数据这些共享变量如果没做好同步轻则数据错乱重则重复下单。管程这种机制在Python里更多体现为threading.Lock、queue.Queue在Java或C里有synchronized、std::mutex。核心原则是别让多个线程同时改一块关键数据。我在自己的策略框架里会单独写一个行情缓存模块所有读写都通过加锁的接口完成内部再维护多个数据源推送下的最新行情快照。刚开始写觉得麻烦但后来避免了大堆诡异Bug。协程是另一个常用工具。Python的asyncio本质上是用户态调度不依赖操作系统线程切换开销小很多。在量化数据采集、Websocket行情订阅这类I/O密集型任务上协程能把单机并发能力放大很多倍。运行原理上协程自己让出和恢复执行流不需要内核介入所以能轻松支持几千路连接。操作系统课程里说的“用户态线程”就是这玩意。3.4 网络事件模型epoll 与 io_uring 如何影响行情推送拿Websocket行情举例早期用多线程一对一处理连接一个线程负责一个客户端100个连接就要开100个线程线程切换开销极大性能天花板也低。Linux的epoll机制改变了这种情况——用一个线程管理数万个连接的文件描述符内核只告诉你哪些连接有数据可读程序再做业务处理。io_uring是Linux内核5.1以后引入的新一代异步I/O接口把读写请求直接提交给内核处理再异步回收结果省去了传统read、write系统调用在用户态和内核态之间的切换开销。在高吞吐数据接口场景这个优势更明显。Windows虽然有IOCP但在公开量化库的底层实现上用的很少反而很多老牌库基于select模式并发能力较差。这也解释了为什么同一套策略Linux上跑出来的实盘延迟更稳定。如果你正在用Python写策略代码可以检查一下网络请求到底用的是不是asyncio或基于selectors的实现如果是同步阻塞式的websocket-client并发连接一多操作系统的线程数限制就会很快成为瓶颈。4. 实操在Linux上搭建一套可以长期运行的量化环境理论说了一堆接下来是最实际的部分。我会按自己搭建的一套环境来讲解你可以照着操作再根据策略需求调整。4.1 系统与版本选型为什么我选Ubuntu Server LTS目前常用服务器Linux发行版主要有Ubuntu Server、Debian、Rocky Linux/AlmaLinux、openEuler等。个人和中小型量化团队用得最多的是Ubuntu Server LTS原因很简单包更新快、资料多、任何报错都能搜到答案。我推荐选择Ubuntu Server 22.04 LTS或更新版本比如24.04 LTS。LTS版本有5年标准支持不会频繁大版本升级系统环境稳定可控。环境选型上还有一个关键点用linux-image-generic-hwe这类硬件驱动增强内核还是默认GA内核实盘服务器求稳建议用默认GA内核避免HWE内核在硬件上踩兼容性坑。如果你跑的是RHEL系比如公司运维环境是Rocky Linux也可以但要注意Python版本兼容性。RHEL系的软件包通常偏旧要用python39或自己编译Python否则部分较新库装不上。4.2 系统安装后的基础加固配置系统装完别急着装策略先做几件基础事创建专用用户别用root直接跑策略。违规文艺地说root的误操作代价太大一条rm -rf就能让服务器数据灰飞烟灭。配置SSH密钥登录禁用root密码登录和密码登录。实盘主机暴露在公网上弱密码被扫爆是迟早的事。配置防火墙只保留必要的端口比如SSH端口、数据API端口、Web端口其余一律deny。更新系统软件包到最新版修复已有安全漏洞。这些做完跑一下systemctl reboot确保重启后还能正常SSH再进入下一步。4.3 量化软件栈部署Python环境、数据库、守护进程我推荐的软件栈是Python 3.10、MiniConda或pyenv管理Python环境、PostgreSQL存历史数据、Redis做行情缓存和任务队列、Nginx做Web API入口、Supervisor或systemd管理进程。Python环境的坑最多强烈建议用虚拟环境不要直接pip install到系统环境里。我用MiniConda创建量化环境后固定所有依赖版本每次部署都用conda env export导出environment.yml新机器一条命令就能还原环境。PostgreSQL适合存日线、分钟线等结构化行情数据安装后建议设置独立的数据库用户和密码别用默认的postgres超级用户跑应用。Redis适合存实时快照和任务队列例如盘中计算出的信号可以先写到Redis再由下单程序消费。数据库选型这块没有绝对但如果你只是个人跑策略PostgreSQLRedis已经完全够用没必要上ClickHouse这类重型分析型数据库。4.4 数据API怎么选几个常用源的取舍这也是热词里反复出现的问题“量化交易用的数据API最好的是什么”。说实话没有绝对最好的只有适不适合你。如果做研究、验证想法Tushare Pro、AkShare这类免费/低门槛接口很合适注册后就拿到Token能拉股票、期货、基金等数据。但要注意接口频率限制拉大量数据时要本地缓存别每次都远程拉。如果做实盘行情券商或期货公司提供的官方行情API优先级最高延迟低、稳定比如CTP环境的行情接口。如果需要更灵活、更专业的历史数据Wind、聚宽、米筐这类商业数据源的字段更全价格也更贵适合团队或者做中高频策略的场景。还有一个常见思路混合用。历史数据用Tushare补齐实时行情用官方的API日终再用商业数据源做核对。我的实际经验是不管选哪个数据源都一定要在本地做一层缓存层。每天收盘后定时任务把数据拉下来存进PostgreSQL盘中所有策略都只读本地数据库这样既能绕开API频率限制又能让回测和实盘数据口径一致。4.5 用systemd管理实盘策略进程Systemd是Linux下最标准的服务管理器。让策略进程开机自启、崩溃自动重启、日志统一收集靠它最方便。我一般会为每个策略写一个service文件放/etc/systemd/system/strategy_xxx.service内容大致如下[Unit] DescriptionQuant Strategy XXX Afternetwork.target postgresql.service redis.service [Service] Userquant Groupquant WorkingDirectory/home/quant/strategies/xxx EnvironmentPATH/home/quant/miniconda3/envs/quant/bin ExecStart/home/quant/miniconda3/envs/quant/bin/python main.py --config config.yaml Restartalways RestartSec5 RuntimeMaxSecinfinity LimitNOFILE65535 MemoryMax8G [Install] WantedBymulti-user.target有几个参数值得解释Restartalways表示进程异常退出时自动拉起RestartSec5表示5秒后再启动防止崩溃后疯狂重启LimitNOFILE调高文件句柄上限避免大量连接时Linux默认1024句柄不够用MemoryMax限制内存上限策略内存泄漏时不至于拖垮整个系统。写好后执行systemctl daemon-reload、systemctl enable strategy_xxx、systemctl start strategy_xxx服务就跑起来了。查看日志用journalctl -u strategy_xxx -f非常直观。4.6 一次真实部署现场进程、内存、日志长什么样有一次部署一套期货量化Python策略跑了一个星期后我看服务器状态top看到策略进程CPU占用在2%~8%之间波动行情接收线程固定在CPU0上CPU1跑策略计算内存占用稳定在2.1G左右Redis缓存占800MPostgreSQL占500MPython策略主体650M其余是系统缓冲journalctl能看到每天正常的开收盘日志、信号触发记录没有异常重启记录系统已经连续运行了11天负载和启动第一天基本一致。这种“稳定得无聊”的状态就是量化系统最好的状态。对比之前Windows服务器上三天两头冒出的异常弹窗、自动更新重启日志操控感完全不一样。5. 策略代码与操作系统交互时我踩过的那些坑操作系统只是平台策略代码跑在上面总会因为对系统机制理解不到位而踩坑。这里挑几个经典案例分享。5.1 文件句柄和socket泄漏开着开着就没了一开始我用Python写行情订阅时websocket连接每秒都会收到新行情但代码里会在on_message回调中直接创建新连接获取补充数据却忘记关闭旧连接。跑了几天后Linux报 “Too many open files”策略进程直接挂掉。排查时用lsof -p 策略进程PID | wc -l看句柄数发现不断上涨定位到是socket泄漏问题。修复逻辑后给service文件加了LimitNOFILE65535做兜底之后再也没遇到这个事。所以写量化代码有个习惯每个连接、文件、锁都要考虑“什么时候关闭”的问题不要只关心“什么时候打开”。5.2 时区与夏令时策略时间线错位的典型现场用Linux部署策略默认时区往往是UTC而中国量化交易用的是北京时间UTC8。如果数据库里存的时间戳全是UTC策略端又是本地时区信号触发时间和实际K线收盘时间不一致会造成下单时机偏移半个交易日的情况。有人可能会说“我代码里写了本地时间”但操作系统层面的date、cron、journalctl时间戳都可能仍然是UTC日志分析时容易错乱。最稳妥的办法是统一做两件事一是系统时区设置成Asia/Shanghai二是数据库和代码里所有时间全部存UTC时间戳只在展示和策略信号判断时转成北京时间。夏令时的坑主要在国外市场如果你做美股、欧股尤其要注意pytz或zoneinfo的时区转换。国内策略不用考虑夏令时但日志系统还是建议统一UTC8。5.3 在PTrade这类托管环境中写策略的注意点很多券商的PTrade策略环境是封装的Linux服务器你在本地Python里写策略上传后实际运行在一个黑盒Linux环境中。以下几点比较关键一是依赖库受限。PTrade环境只支持预装的库你本地用pip install装了最新的pandas上传后可能还在用老版本接口行为可能有差异。写策略前先在模拟环境里把关键依赖测一遍尽量少用外部库多依赖Python标准库。二是路径和中文编码。本地Windows路径是C:\xxx上传到Linux后是绝对路径路径分隔符写错会直接FileNotFoundError中文注释或中文日志在终端上可能乱码。建议代码里所有路径用os.path.join拼接日志统一用英文。三是不能直接访问任意网络端口。托管环境有白名单机制想自己拉外部数据通常放行不了策略写成只能使用平台自带的数据接口。所以在开发策略时接口要抽象成一层方便不同环境之间切换。5.4 期货量化Python策略线程模型和行情的实时性做期货量化的人很多用Python调用CTP类接口。这类原生接口的回调线程是操作系统级别的当你收到行情回调后如果直接在回调线程里做复杂计算会阻塞下一个行情的处理导致漏单。正确做法是回调线程只把数据放进缓存队列立刻返回另开一个计算线程处理队列数据。这样行情接收和策略计算解耦接收延迟非常稳定。Python的GIL在I/O密集场景影响不大但遇到CPU密集的计算建议用multiprocessing把计算放到单独进程避免GIL的拖累。另外实盘前一定要在模拟环境里跑几个完整的交易日观察系统负载、延迟、日志量确认行情尖峰时段系统不会卡顿再切实盘。我见过有人在实盘里直接跑策略结果行情爆发时Python进程CPU冲到100%下单延迟从2毫秒飙到300毫秒错过价格滑了很久。5.5 内核参数的适度调优别乱改先监控关于Linux内核参数在不明确的情况下不要乱改。比较常见的几个优化项fs.file-max系统级文件句柄上限连接数大时才需要调。net.core.somaxconnTCP监听队列长度同时接入连接多时调大。net.ipv4.tcp_tw_reuse复用TIME_WAIT连接。行情服务连接频繁断开重连时有用默认是关闭的可以设置成1。vm.swappiness控制系统换页积极性。有大量内存做页面缓存时建议调整成较低值比如10避免不必要的swap。vm.overcommit_memory影响Redis等应用内存申请策略如果你跑Redis需要看官方建议再改。我的建议是先跑稳定了再通过dmesg、journalctl、vmstat、free看到具体瓶颈时再针对性调优。像net.ipv4.tcp_tw_reuse这种改动比较安全但有些参数比如kernel.sched_rt_runtime乱调会导致系统假死一定谨慎。6. 运行期常见问题排查与经验技巧6.1 问题速查表从现象到解决办法现象可能原因排查手段解决办法策略进程无故消失内存OOM被kill、代码异常退退出dmesg -T、journalctl -u 服务名调大MemoryMax、修复异常、设置Restartalways网络连接突然连不上文件句柄耗尽、防火墙规则ulimit -n、ss -ant调大LimitNOFILE、检查防火墙白名单行情延迟不稳定线程切换频繁、CPU被其他任务抢占vmstat 1、top -H设置CPU亲和性、降低其他进程优先级磁盘空间写满日志过多、数据库膨胀df -h、du -sh *日志轮转、定期清理历史数据时间对不上时区设置不一致date、timedatectl统一Asia/Shanghai代码统一UTC时间戳Python装包失败编译依赖缺失pip install xxx报错日志安装对应gcc、头文件包策略触发重复下单多实例运行、共享状态未加锁ps aux检查进程数量用进程锁或确认只启动一个实例数据库连接数打满连接池配置不合理show processlist调整连接池大小、关闭空闲连接这张表是我运维过程中反复会看的出现类似问题时先对照排查大多数时候几分钟就能定位。6.2 我最常看的几个监控指标不要等到出问题了才去看指标量化服务器日常监控必须要有。我日常用htop、nmon、glances看系统整体状态重点关注这些Load Average1分钟、5分钟、15分钟的值如果5分钟持续大于CPU核心数说明系统已经超负荷。上下文切换和中断拿vmstat 1看cs和in两列行情尖峰时段明显升高是正常的如果平时也居高不下说明系统调度太频繁。IoWait磁盘I/O等待占比回测时大量读历史数据特别容易高如果长时间高要考虑是不是数据库索引没建好。内存free -h看 available 和 cached 比例available很低、swap开始增长基本就是内存不够了。句柄数ss -s和lsof可以确认连接数和句柄数防止跑到上限后崩溃。监控工具上PrometheusGrafana是团队级的方案个人策略机直接写个shell脚本每分钟把核心数据追加到日志文件再配个邮件/微信告警就够用了。让我比较放心的是Linux日志文件足够透明出问题后能很快定位根因。6.3 团队协作中的系统管理经验如果你是个人量化上面那些管理方式已经够用了。但如果你是有两三个人的小团队还需要注意几点每台服务器统一命名规则比如prod-cta-01、dev-data-01配置文件和脚本里注明用途。系统账号按人分配别所有人共用一个root。出了问题至少知道是谁执行的哪步操作配合安全审计。所有部署都用脚本或配置文件管理别在服务器上手动东改西改。建议把配置文件纳入git版本控制改动有记录回滚也方便。数据库和策略代码要定时备份。备份不要放在同一台机器上可以和对象存储做异地备份防止磁盘损坏导致数据全丢。有一次同事在服务器上手动改了策略的启动参数没有同步更新配置文件后来服务器重启后systemd读到的还是旧参数策略行为跟预期完全不一致还白跑了两天。从那以后所有改动都强制走脚本和配置文件禁止手动裸改。6.4 让策略“活得更久”的几个小习惯最后分享几个让策略长期稳定运行的习惯第一给所有策略进程加上日志轮转。用logrotate按天切分日志保留最近30天避免单个日志文件无限膨胀占满磁盘。第二每周定时重启一次非核心服务比如行情采集进程、回测任务避免长驻进程积累隐藏问题。实盘策略进程没必要频繁重启因为它有状态保持稳定运行更重要。第三重要交易时段尽量不登录服务器做改动。盘中修改策略、升级依赖库是大忌万一引入Bug整个实盘都会受影响。有次我盘中更新了一个共用的Python库结果把行情解析模块的接口行为弄变了策略订单直接异常手动处理到收盘才恢复从那以后立下规矩盘中只查看不修改。第四给服务器配个智能PDU或者远程控制卡万一系统死机可以远程强制重启。用带外管理比机房托管时打电话求人强太多了。7. 写在服务器边上的一点体会如果问我“最佳量化交易的计算机操作系统”是什么我的答案是开发用你最顺手的系统回测用一个稳定的大内存机器实盘就用Linux服务器越简单越可靠越好。但是最佳系统只是一个地基不是全部。策略代码本身的质量、数据API的稳定、风控逻辑的严密这些都在地基之上。操作系统帮你解决的是“程序能不能跑得久、跑得稳”的问题而不是“策略能不能赚钱”的问题。很多新手一开始花太多时间研究系统、研究环境反而忽略了策略逻辑这是本末倒置。我自己从Windows迁移到Linux的过程也没那么轻松初期踩了一堆小坑但坚持下来后再也没有因为系统问题打断过实盘策略的运行。如果你也在纠结要不要换系统我的建议是先在虚拟机里把整套环境跑通再把回测脚本迁移过去最后再把实盘策略搬过去一步一个脚印稳扎稳打。第一台跑满一个月不重启的Linux策略服务器那份“什么都不用管”的省心是值得你折腾一次的。
