78 lines
6.1 KiB
Markdown
78 lines
6.1 KiB
Markdown
# 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 每日训练任务自动生成*
|