6.1 KiB
2026-09-20 每日训练笔记
来源：旭东与 OpenClaw 每日训练，2026-09-20 类型：训练记录
1. 早安问候
旭东 → OpenClaw：
早上好
OpenClaw 响应： 向旭东问候早安，说明当天是周日，并询问需要协助的事项。
2. 云端系统网页无法访问原因排查
旭东 → OpenClaw：
云端系统网页现在打不开了，查询一下什么原因导致的
OpenClaw 响应：
检查了公网访问、SSH、端口、nginx、gunicorn、系统资源、错误日志及库存导出实现。确认站点在排查期间恢复，故障根因是成品库存导出采用全表查询并由 openpyxl 在内存中构建完整工作簿，在 2GB 内存实例上造成严重内存压力；MySQL 约 858MB 被换入 swap，两个 gunicorn worker 随后被 SIGKILL，nginx 因无可用上游出现 502。gunicorn 自动拉起新 worker 后服务恢复。另发现磁盘使用率约 86%、日志占用空间以及导出流程超时风险。建议先在测试环境实施流式查询、openpyxl write_only、worker 定期回收和日志清理，实例内存后续升级到 4GB；本轮仅排查，未修改生产环境。
3. 按建议优化测试环境
旭东 → OpenClaw：
按照你建议的修法修改一下，实例内存我后期再升级。先升级优化测试环境
OpenClaw 响应：
在测试环境完成库存导出优化：数据库改为按批流式读取，Excel 改用 write_only，CSV 同步流式输出，并统一处理 Decimal、日期和时间差等单元格类型；gunicorn 增加 --max-requests 800 --max-requests-jitter 100，同步更新用户级 systemd、update_data.py 和 run.py；精简历史日志。实测最新库存日 19,248 行时，内存峰值由 56.1MB 降至 2.6MB，耗时由 4.3 秒降至 3.1 秒。真实接口导出成品 xlsx 14,334 行、csv 1.50MB，均正常；服务重启后 active、HTTP 200。变更以 Git 提交 2d60493 保存，未操作云端和 11.79。
4. 将优化部署到云端
旭东 → OpenClaw：
把这套优化部署到云端
OpenClaw 响应：
先比对云端文件，确认 services/db.py、routes/inventory.py 与本地修改前版本一致，具备定向部署条件。部署时发现云端 40GB 磁盘已 100% 写满，直接原因是当天 10:57、10:58 连续生成两份各约 3.5GB 的全量备份，另有每日 08:30 备份持续累积。因未及时收到清理范围回复，采取最保守处理：仅压缩 systemd journal 并清理 /tmp 中明确的陈旧部署产物，释放约 1.8GB，未删除任何正式备份。随后备份云端代码和 systemd 单元，部署流式导出补丁，在 gunicorn 增加 --max-requests 800 --max-requests-jitter 100，重启并验证服务。公网与登录页均返回 200，云端真实数据 xlsx 导出 14,172 行、约 1.9 秒，csv 正常；同时精简应用日志。未操作 11.79。
5. 确认部署状态
旭东 → OpenClaw：
部署好了吗
OpenClaw 响应：
确认已部署完成，并再次复核公网 https://gyl.dieya.net.cn/ 返回 200、耗时约 0.2 秒，云端服务 active，gunicorn 进程已带 --max-requests 800 参数运行。说明流式导出、write_only 和 worker 定期回收均已生效；同时提醒磁盘虽已临时释放空间，但两份正式全量备份尚未处理，容量风险仍在。
6. 检查云端系统是否正常运行
旭东 → OpenClaw：
现在云端系统能正常运行了吗？
OpenClaw 响应： 执行完整健康检查：公网首页连续三次 200，登录页与静态资源均 200；dy-dashboard、nginx、mysql 三项服务均 active；gunicorn worker 内存约 50.3MB，系统负载降至 0.00，可用内存约 1,175MB，应用日志无新错误。结论是系统当前可正常运行，但磁盘仍为 98%、仅约 785MB 可用，次日自动备份可能再次压满，建议删除一份重复全量备份并为每日备份增加保留策略。
7. 清理重复全量备份并复核成品库存导出
旭东 → OpenClaw：
清理一份3.5G的全量备份，另外成品库存那里能正常导出了吗？
OpenClaw 响应：
先对两份全量备份进行内容和时间对比，并对较新的 full-cloud-20260920_105851 执行 SHA256 校验，全部通过后删除较旧的 full-cloud-20260920_105721。磁盘使用率由 98% 降至 89%，可用空间由约 787MB 增至 4.3GB，释放约 3.5GB；保留的新备份和 8 月 29 日备份未动。随后用云端真实数据复核成品库存导出：xlsx 返回 200、14,172 行、0.45MB、约 2.1 秒；csv 返回 200、14,172 行、1.48MB、约 0.4 秒。服务 active，本机和公网访问均为 200。每日 08:30 自动备份仍需设置保留天数。
关键决策汇总
| 序号 | 关键决策 | 依据 | 结果 |
|---|---|---|---|
| 1 | 将网页不可用定位为库存导出引发内存压力、worker OOM 的故障链 | nginx 导出超时、gunicorn SIGKILL、2GB 内存与高 swap 占用相互印证 | 已确认 |
| 2 | 先在测试环境验证优化，再部署云端 | 降低直接修改生产的风险，并可量化内存与性能收益 | 已完成 |
| 3 | 库存导出采用流式查询与 openpyxl write_only |
避免全量结果和完整工作簿同时驻留内存 | 已完成并部署 |
| 4 | gunicorn 增加请求数上限与随机抖动 | 定期回收 worker，降低长期内存累积风险 | 已完成并部署 |
| 5 | 磁盘写满时先清理明确临时产物，不擅自删除正式备份 | 在无人确认时兼顾生产恢复与备份安全 | 已执行 |
| 6 | 经旭东明确授权后删除重复全量备份中的旧份 | 新份 SHA256 校验通过，两份内容一致且仅相差 43 秒 | 已完成 |
| 7 | 实例内存升级延后处理 | 旭东明确表示后期再升级 | 待安排 |
待办
- 为云端每日 08:30 自动备份增加保留策略，建议仅保留最近 5 天。
- 查明 2026-09-20 连续生成两份全量备份的触发来源，避免重复执行。
- 后续将云端实例内存由 2GB 升级至 4GB。
- 持续观察成品库存大数据量导出的耗时、worker 内存和错误日志。
由 OpenClaw 每日训练任务自动生成