这个系列的读者应该都有体会：OpenClaw在本地或者单机环境跑起来非常简单，装好依赖、配好模型Key、启动服务，一个能帮你查资料、写周报、管日程的AI助理就能用了。但真要让它7x24小时在线，随时响应，不卡死、不丢任务、不掉线，那完全是另一码事。我自己的部署跑了半年多，踩过内存泄漏、任务堆积、日志撑爆磁盘、进程假死等各种坑，这篇就把我做性能调优和高可用部署的完整思路整理出来。内容偏向已经跑通基础OpenClaw、想把它当生产服务用的读者；如果你是刚装好还在折腾插件，可以先收藏，后面大概率用得上。
所谓“不掉线”，不等于进程不退出就够了。真正的生产级可用，是进程崩溃能自动拉起、假死能被发现并恢复、流量能自动切换到健康节点、数据和日志不会成为新的故障点。这篇文章我会按照“先定位问题、再做参数调优、再上高可用架构、最后治理长期运行隐患”的顺序讲，每一段都来自实际踩坑后的沉淀，不是从文档里抄出来的。
1. 先诊断再调优：性能瓶颈的定位思路
1.1 三张监控表，先看数据再动手
我见过很多朋友一上来就问“OpenClaw跑几天就卡死怎么办”，这个问题没法直接答，因为卡死的原因千差万别。我自己的习惯是先把三组数据拉出来：进程内存RSS走势、CPU占用、健康检查接口的响应延迟。这三组数据能覆盖80%的稳定性问题。
先说内存RSS。如果这个值持续上涨不回落，基本可以断定有对象在累积，最常见的三个来源是会话历史没裁剪、工具调用结果被无限追加、日志缓冲区没释放。再说CPU。如果某个进程长期占满一个核，通常是事件循环里混入了同步阻塞操作，导致其他任务只能排队。最后是健康检查延迟。这个指标最直观，如果从正常的几毫秒涨到几百毫秒甚至超时，说明进程已经在“假死”状态，请求全部卡住了。
我用的工具很简单：本机用psutil写了一个打点脚本，每分钟把RSS、CPU、健康检查延迟追加到CSV文件；生产环境上了Prometheus加Grafana，用node_exporter加自定义exporter采集。如果不想上监控平台，crontab加脚本也完全够用，关键是坚持记录，出事的时候才有时序数据可以回看，不然就只能靠猜。
1.2 内存与并发：两个最常见的“假死”元凶
实际排查中，最常遇到的是内存泄漏和事件循环阻塞。内存泄漏我遇到过一次印象特别深：RSS从300MB一路涨到2GB，最后被内核OOM杀掉。用tracemalloc定位发现，是某个工具插件把每次调用的结果append到一个全局列表，同时会话上下文字符串也在无限累积。这其实是使用方式的问题，OpenClaw的设计假设是“会话有边界”，如果你在服务端把它当成无状态HTTP服务跑，又不做上下文裁剪，内存必然涨。
用Python内置的tracemalloc很容易定位泄漏点：
import tracemalloc tracemalloc.start() # 触发一次完整的对话流程 snapshot = tracemalloc.take_snapshot() top_stats = snapshot.statistics('lineno') for stat in top_stats[:10]: print(stat)跑几轮对话后对比两次快照，哪一行新增内存最多，哪一行就是泄漏点。这个手段比翻代码猜要高效得多，也是我每次做性能排查的第一步。
再说并发问题。OpenClaw底层是asyncio，但它调用模型API、外部工具时经常用到同步客户端，一旦某个同步调用没有放到线程池里跑，整个事件循环会被卡住，表现为进程还活着、端口还开着，但所有请求都超时。解决思路是把同步阻塞操作包进run_in_executor，或者直接换异步客户端。
1.3 日志里的蛛丝马迹
很多时候进程没有崩溃，只是行为异常，这类问题排查主要靠日志。我建议把OpenClaw的日志级别调到INFO以上，单独开一个error.log记录WARNING和ERROR。排查的时候先看有没有反复出现的异常，比如连接池超时、上游429、SQLite锁超时，这些异常往往是“假死”的先兆。
看日志还有一个技巧：不要只看application日志，系统日志也要看。比如dmesg里出现oom-killer记录，说明是内存问题而非业务逻辑问题；journalctl里看到进程被systemd反复拉起，说明服务没真正起来。如果你用Docker部署，别漏了docker stats和容器日志，多实例场景下还要看负载均衡的upstream状态。日志里藏着大量线索，关键是形成“现象到日志再到根因”的排查路径。
2. 核心配置调优：让AI助理在高压下不崩
2.1 模型调用链路的超时与重试
OpenClaw最核心的外部依赖就是模型API。这个调用链一抖，整个服务就像被点了穴。默认配置下，很多模型客户端没有设置超时，或者超时时间放得特别长，一旦上游网络抖动，一个请求能卡好几分钟，后面所有任务全堵上。
我的做法是三层控制：连接超时3秒、读超时60秒、总请求超时120秒。然后加上重试策略，但重试不是无脑重试。429和5xx可以重试，4xx（尤其是400和401）重试没有意义，因为参数错了重试一万次也是错。用tenacity库实现指数退避加重试，最多3次，加一点随机抖动，避免多个实例同时重试造成“惊群效应”。如果下游模型服务本身不稳定，优先考虑用消息队列做削峰填谷，而不是靠重试硬扛。
这里特别提醒一下，超时值不要设置得过于激进。连接超时3秒是合理的，但读超时如果小于模型推理时间，会出现明明在正常生成却被打断的情况。我实际测下来，读超时60秒比较合适，既能覆盖大多数模型的正常返回时间，又不会因为网络抖动拖垮整个服务。
2.2 任务队列与并发上限的配合
OpenClaw的任务执行机制我梳理过：用户请求进来后，会进入任务队列，然后由worker并发消费。默认并发数如果不限制，系统资源会被瞬间打满；如果队列无上限，堆积的任务会吃掉所有内存。这两个问题叠加起来，就是服务在流量高峰时“雪崩”的典型路径。
我用asyncio.Semaphore限制同时执行的外部调用数量，默认是5，具体值看模型API的速率限制。队列长度上限设为200，超过就立刻返回“服务繁忙”，而不是让用户无限等待。这里的关键是“背压”思想：宁可拒绝新请求，也不要让老请求堆积。很多稳定性问题不是流量太大，而是系统没有拒绝能力。
任务队列建议直接用Redis来做，这样多实例共享一个队列，任何一个worker空闲都能取任务。单机内存队列虽然简单，但进程重启就全丢了，多实例也没法共用，属于看起来省事实际埋雷的方案。
2.3 会话上下文的裁剪策略
内存泄漏的根源往往是上下文无限增长。OpenClaw默认会把完整会话历史传给模型，对话轮数多了以后token数会超限，表现为请求报错或者响应质量下降，模型越聊越“失忆”。
我在服务端做两层处理：滑动窗口保留最近20轮消息；超过40轮的会话触发摘要压缩，把较早的内容用LLM总结成一段摘要顶替原始消息。这样token数可控，内存也稳定。配置项上要开启上下文裁剪，设置max_context_messages和enable_summarization这两个参数。
值得注意：摘要压缩会损失细节，对于需要精确回忆的任务要慎重。我的做法是交互型任务走摘要，定时任务保留全量上下文但限制最大轮数。这个取舍没有标准答案，要看你的实际场景对上下文细节的依赖程度，建议先设一个保守值跑一段时间，观察内存和响应质量再调整。
3. 高可用部署：从“挂了自己拉起”到“挂了无缝切换”
3.1 systemd守护：最基础的保命手段
很多新手用nohup启动OpenClaw，进程挂了没人知道，这是最不推荐的方式。我用systemd管理服务，崩溃自动拉起、开机自启、日志统一走journald，运维成本比nohup低一个量级。
给一个可以直接用的service文件：
[Unit] Description=OpenClaw AI Assistant Service After=network.target redis.service [Service] Type=notify WorkingDirectory=/opt/openclaw EnvironmentFile=/etc/openclaw/env ExecStart=/usr/bin/python3 -m openclaw serve --port 8700 Restart=always RestartSec=5 WatchdogSec=30 NotifyAccess=main User=openclaw Group=openclaw StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target这里重点说WatchdogSec。OpenClaw支持systemd通知，服务启动后调用systemd_notify告知“我准备好了”。如果代码里没实现通知，Type=notify会导致启动失败，这时可以退回Type=simple并去掉WatchdogSec。Watchdog的作用是：事件循环卡死时systemd能感知并重启服务。我实测下来，这个机制对“假死”状态非常有效，比单纯依赖HTTP健康检查要快。
3.2 健康检查与自动重启的联动
systemd能拉起崩溃的进程，但“假死”的进程systemd不一定认得出来。所以我给OpenClaw加了一个/healthz健康检查端点，它不光返回“进程活着”，还要检查Redis连接、任务队列堆积数、上游模型服务连通性。Redis连不上或者队列深度超过阈值，就返回503。
healthz的代码示意：
from fastapi import FastAPI from fastapi.responses import JSONResponse app = FastAPI() @app.get("/healthz") async def healthz(): try: queue_len = await redis.llen("openclaw:task_queue") if queue_len > 500: return JSONResponse(status_code=503, content={ "status": "unhealthy", "queue": queue_len }) except Exception: return JSONResponse(status_code=503, content={ "status": "unhealthy", "redis": "down" }) return {"status": "healthy", "queue": queue_len}配合systemd的WatchdogSec，假死状态最长几十秒就会被发现并重启。如果用了负载均衡，把503状态当成“摘除节点”的信号，请求会自动切换到健康实例。健康检查不是写出来就完了，要定期自己去curl验证一下，确保返回值符合预期，我见过不少健康检查因为依赖挂掉而一直返回200的反例。
3.3 多实例负载均衡与会话共享
单机单实例再怎么调优，总有不小心的升级窗口和硬件故障。更进一步的做法是跑两个实例，前面挂一层负载均衡。用Docker Compose跑两个OpenClaw实例加一个nginx：
services: openclaw-a: image: openclaw:latest environment: - INSTANCE_ID=a - REDIS_URL=redis://redis:6379/0 ports: - "8701:8700" restart: always openclaw-b: image: openclaw:latest environment: - INSTANCE_ID=b - REDIS_URL=redis://redis:6379/0 ports: - "8702:8700" restart: always nginx: image: nginx:alpine ports: - "8700:8700" volumes: - ./nginx.conf:/etc/nginx/nginx.confnginx配置：
upstream openclaw_backend { server openclaw-a:8700 max_fails=3 fail_timeout=30s; server openclaw-b:8700 max_fails=3 fail_timeout=30s; } server { listen 8700; location / { proxy_pass http://openclaw_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }多实例最大的坑是状态同步。OpenClaw的会话状态和任务状态都放在Redis里才能多实例共享，否则用户上次对话的内容在另一个实例上完全接不上。如果你有定时任务类的逻辑，一定要用分布式锁保证同一时刻只有一个实例在执行，否则任务会重复跑。锁我直接用Redis的SET NX EX实现，获取到锁的实例执行，没拿到的跳过，几行代码就能搞定。
4. 日志、数据与长期运行的治理
4.1 日志轮转：别让日志把磁盘撑爆
磁盘被日志撑满是我遇到过的真实事故，而且是很快的事故。OpenClaw开启DEBUG日志后，日志文件几天就能涨几个GB，磁盘满了服务直接崩溃，API key都写不进去。这个问题最气人的是它完全可预防，只是很多人拖到最后才配。
logrotate配置：
/var/log/openclaw/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }这里用copytruncate而不是默认的rename，是因为OpenClaw进程持有文件句柄，rename后进程还会往旧文件里写，新日志反而丢了。copytruncate是先复制再截断，对运行中的服务更友好。如果日志特别多，可以改成按50MB轮转，别光靠天数。配好之后用logrotate -d验证一下配置语法，别等磁盘满了才想起来测试。
4.2 状态持久化与优雅退出
进程重启最怕丢状态。我梳理过OpenClaw里哪些状态必须持久化：会话历史存PostgreSQL（SQLite也行，但多实例必须用中心化数据库），任务状态存Redis，配置文件走EnvironmentFile。这样重启后用户之前的对话还能接上，不会因为一次部署就像失忆了一样。
优雅退出也很重要。我写的关闭流程是：捕获SIGTERM，停止接收新任务，把正在执行的任务标记为interrupted并保存断点，清掉Redis里的锁，最后退出。systemd发SIGTERM后默认等90秒，超时杀进程。如果你的任务跑得久，需要在service文件里加TimeoutStopSec=120。实测下来，优雅退出能极大减少任务丢失，尤其是那些执行到一半的定时任务，有断点就能续跑，没有就只能重来。
4.3 定时自愈与升级流程
长期运行的服务，即使没有泄漏，内存碎片也会导致性能缓慢下降。我的做法是每天凌晨4点低峰期优雅重启一次。配合systemd定时器和健康检查，重启后确认healthz恢复再结束操作。这一步看着简单，其实帮我挡掉了很多潜在的稳定性问题。
升级流程同样需要严谨：先备份数据库，拉取新代码跑一遍冒烟测试，然后逐实例重启。多实例环境下先重启一个，确认健康再重启下一个，避免所有实例同时重启造成服务完全不可用。升级前记得查看changelog，配置项有变更时提前改好配置，不然新版本启动直接失败，而且报错信息可能还不明显。
5. 常见问题排查速查表
| 现象 | 常见原因 | 排查手段 | 处理方法 |
|---|---|---|---|
| 进程RSS不断上涨 | 会话历史、工具结果未清理 | tracemalloc快照对比 | 开启上下文裁剪，配置定时重启 |
| 进程活着但请求全部超时 | 事件循环被同步阻塞卡住 | py-spy dump 看线程堆栈 | 同步调用改run_in_executor |
| 日志占满磁盘 | 未配置日志轮转 | df -h、du -sh /var/log | 配置logrotate，按大小轮转 |
| 任务队列无限堆积 | 并发未限制、下游模型响应慢 | Redis LLEN 查看队列长度 | 加Semaphore、队列上限、背压策略 |
| 定时任务重复执行 | 多实例没有分布式锁 | 日志里看到重复执行记录 | Redis SET NX 实现分布式锁 |
| 上游模型API抖动 | 未设置超时和重试 | 查看error.log中的429、5xx | 配置超时、指数退避重试 |
| systemd一直重启但起不来 | Type=notify但代码没发通知 | journalctl -u openclaw 查看日志 | 改回Type=simple或实现通知 |
排查假死进程，我强烈推荐py-spy dump这个工具。用法很简单，py-spy dump --pid <pid>，几秒钟就能打出当前所有线程的堆栈，一眼看到卡在哪个调用上。比起翻日志猜原因，这是直接证据。另外提醒一句，不要在生产环境随便strace一个线上进程，性能损耗太大，py-spy这类工具才是专门为线上环境设计的。
最后说一点自己的体会。稳定性和性能调优这件事，做得越早、成本越低。不要等服务隔三差五挂掉再回头补课，我强烈建议部署OpenClaw的头一天就把三样东西配好：日志轮转、健康检查、systemd守护。这三样东西不花你半小时，但之后能帮你省下无数个半夜起来重启进程的夜晚。改参数也建议一次只改一个变量，配合监控数据对比，不然出了问题你根本不知道是哪个配置引起的。我这个系列还会继续写，下一篇准备聊多租户隔离和调用成本控制，有类似踩坑经历的朋友随时评论区交流。
