fnvtk/karuo-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

🔄 卡若AI 重建本地主仓 | 保留有效小文件

Browse Source
This commit is contained in:
Manus AI
2026-07-19 00:21:31 +08:00
commit df98da40cc
7617 changed files with 5180190 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

550
01_卡资（金）/金仓_存储备份/群晖NAS管理/开发文档/CKBNAS_sata4与内存问题修复方案_20260709.md Normal file
View File

@@ -0,0 +1,550 @@
# CKBNAS sata4磁盘与内存问题修复方案（2026-07-09）
> **设备**：Synology DS1825+ · CKBNAS
> **修复日期**：2026-07-09
> **问题**：1) sata4磁盘I/O错误导致整机卡死 2) 内存不足触发OOM-Killer
---
## 一、问题分析
### 问题1：sata4磁盘I/O错误（根因）
| 项目 | 详情 |
|:-----|:-----|
| 磁盘型号 | ST_M13FQBL（ata2槽位） |
| 错误类型 | FLUSH CACHE失败、Buffer I/O error、softreset failed |
| 影响 | 内核磁盘恢复卡住整机，网络完全不可用 |
| 历史记录 | 2026-06-06首次发现，反复出现导致NAS频繁死机 |
### 问题2：内存不足（触发因素）
| 项目 | 详情 |
|:-----|:-----|
| 物理内存 | 8GB DDR4 ECC |
| DSM常驻 | ~1.5～2GB |
| 问题现象 | ContainerManager启动后内存从6.6GB骤降到147MB |
| 触发机制 | OOM-Killer杀死关键进程，Docker容器批量重启导致IO风暴 |
| 恶性循环 | Docker启动→内存耗尽→OOM-Killer→服务崩溃→重启→复发 |
#### 内存消耗大户分析
| 容器 | 配置内存 | 实际占用 | 是否有效限制 | 问题 |
|:-----|:--------:|:--------:|:-----------:|:-----|
| macOS VM | deploy.resources.limits: 4.5G | ~4.5GB | ❌ 不生效 | deploy只在swarm模式生效 |
| Windows VM | mem_limit: 3G | ~3GB | ✅ 生效 | 无 |
| Android模拟器 | shm_size: 2G | ~3GB | ❌ 无限制 | 缺少mem_limit |
| Android VM | 无限制 | ~3GB | ❌ 无限制 | 缺少mem_limit |
| Qdrant | 无限制 | ~1GB | ❌ 无限制 | 缺少mem_limit |
| workphone-sdk | 无限制 | ~1.5GB | ❌ 无限制 | 缺少mem_limit |
| MongoDB | wiredTigerCacheSizeGB=1 | ~2GB | ⚠️ 部分有效 | 缺少mem_limit |
#### 关键发现：docker-compose内存限制陷阱
**问题**：`deploy.resources.limits` 只在Docker Swarm模式下生效！
```yaml
# 错误配置（macOS VM）- 只在swarm模式生效
deploy:
resources:
limits:
memory: 4500M # ❌ 普通docker-compose无效
# 正确配置 - 在普通docker-compose模式下生效
mem_limit: 4.5g # ✅ 有效
```
**影响**：macOS VM的内存限制完全不生效，实际可占用全部8GB内存！
---
## 二、解决方案
### 2.1 修复策略
```
┌─────────────────────────────────────────────────────────────┐
│ 问题1：sata4磁盘I/O错误 │
│ ├─ 将sata4设置为offline（未入RAID，可安全离线） │
│ ├─ 监控dmesg中的I/O错误 │
│ └─ 定期检测SMART状态 │
├─────────────────────────────────────────────────────────────┤
│ 问题2：内存不足 │
│ ├─ 禁用ContainerManager开机自启 │
│ ├─ 所有容器RestartPolicy改为no │
│ ├─ 禁用高耗栈（Ollama/VM/karuo-ai网关） │
│ ├─ 设置vm.swappiness=10（降低swap争抢） │
│ └─ 仅保留生产服务：MongoDB、workphone-sdk │
├─────────────────────────────────────────────────────────────┤
│ 自动化保障 │
│ ├─ @reboot 开机自动修复 │
│ └─ */10 * * * * 每10分钟健康检测 │
└─────────────────────────────────────────────────────────────┘
```
### 2.2 创建的脚本
| 脚本 | 路径 | 功能 |
|:-----|:-----|:-----|
| **综合修复脚本** | `scripts/ckbnas_fix_sata4_and_memory.sh` | 解决sata4和内存两个问题 |
| **健康检测脚本** | `scripts/ckbnas_sata4_health_check.sh` | 定期检测sata4状态和SMART |
| **定时任务安装** | `scripts/install_ckbnas_fix_cron.sh` | 安装开机修复和定时检测任务 |
| **内存限制脚本** | `scripts/ckbnas_add_memory_limits.sh` | 为所有容器添加有效的mem_limit |
### 2.3 内存限制修复
所有容器已添加有效的`mem_limit`配置：
| 容器 | mem_limit | 说明 |
|:-----|:---------:|:-----|
| **生产服务** | | |
| MongoDB | 2g | 含wiredTigerCacheSizeGB=1 |
| workphone-sdk | 1.5g | Node.js应用 |
| **基础服务** | | |
| gitea | 512m | 代码仓库 |
| qdrant | 1g | 向量数据库 |
| xmfst-web | 1g | 厦门房产网站 |
| **高耗栈（已禁用）** | | |
| windows-vm | 3g | 已生效 |
| macos-vm | 4.5g | 已替换deploy.resources.limits |
| android-emulator | 3g | 新增 |
| android-vm | 3g | 新增 |
**内存预算**：
- 生产服务：3.5GB
- 基础服务：2.0GB
- 高耗栈（已禁用）：13.5GB
- **当前运行**：仅生产服务，需4GB，8GB够用
---
## 三、操作步骤
### 步骤1：物理重启NAS（必须）
由于当前NAS完全不可达（SSH Host is down），需要物理干预：
```bash
# 到NAS旁操作：
# 1. 长按电源键关机
# 2. 等待2分钟
# 3. 按电源键开机
```
### 步骤2：SSH登录并执行修复
```bash
# 登录NAS
ssh ckbnas-home
# 切换root（必须）
sudo -s
# 执行综合修复
bash /volume1/homes/fnvtk/scripts/ckbnas_fix_sata4_and_memory.sh
```
### 步骤3：安装定时任务
```bash
# 安装开机修复和健康检测任务
bash /volume1/homes/fnvtk/scripts/install_ckbnas_fix_cron.sh
```
### 步骤4：验证修复结果
```bash
# 验证sata4状态
cat /sys/block/sata4/device/state
# 验证内存状态
free -m
# 验证ContainerManager状态
synopkg status ContainerManager
# 验证DSM服务
curl -m3 http://127.0.0.1:5000/
# 验证RAID状态
cat /proc/mdstat | grep md2
```
---
## 四、保护的生产服务
修复过程中**不会删除**以下生产关键服务：
| 服务 | 路径 | 说明 |
|:-----|:-----|:-----|
| MongoDB | `/volume1/docker/mongodb/` | AI微信数据库 |
| workphone-mongo | `workphone-mongo-nas` | 工作手机数据库 |
| workphone-redis | `workphone-redis-nas` | 工作手机缓存 |
| workphone-sdk | `workphone-sdk-nas` | 工作手机SDK服务 |
---
## 五、禁用的高耗栈
| 栈 | 内存预估 | 状态 |
|:---|:--------:|:-----|
| Ollama | 5GB | 已禁用 |
| karuo-ai网关 | 6～8GB | 已禁用 |
| Windows VM | 4GB | 已禁用 |
| macOS VM | 4.5GB | 已禁用 |
| Android VM | 2～4GB | 已禁用 |
| 底座合集 | 2～4GB | 已禁用 |
---
## 六、长期解决方案
| 措施 | 优先级 | 说明 |
|:-----|:------:|:-----|
| **更换sata4硬盘** | P0 | 物理更换故障硬盘（ST_M13FQBL） |
| **升级内存至32GB** | P1 | DS1825+支持32GB内存扩展 |
| **配置UPS** | P2 | 避免意外断电触发btrfs续扫 |
| **定期磁盘检测** | P2 | 每10分钟SMART检测已配置 |
| **内存监控告警** | P3 | 当可用内存<2GB时自动告警 |
---
## 七、脚本部署说明
将脚本上传到NAS的以下路径：
```bash
# 在本机执行（上传脚本到NAS）
scp /Users/karuo/Documents/个人/卡若AI/01_卡资（金）/金仓_存储备份/群晖NAS管理/scripts/ckbnas_fix_sata4_and_memory.sh fnvtk@192.168.110.101:/volume1/homes/fnvtk/scripts/
scp /Users/karuo/Documents/个人/卡若AI/01_卡资（金）/金仓_存储备份/群晖NAS管理/scripts/ckbnas_sata4_health_check.sh fnvtk@192.168.110.101:/volume1/homes/fnvtk/scripts/
scp /Users/karuo/Documents/个人/卡若AI/01_卡资（金）/金仓_存储备份/群晖NAS管理/scripts/install_ckbnas_fix_cron.sh fnvtk@192.168.110.101:/volume1/homes/fnvtk/scripts/
# 设置可执行权限
ssh ckbnas-home 'chmod +x /volume1/homes/fnvtk/scripts/ckbnas_fix_sata4_and_memory.sh /volume1/homes/fnvtk/scripts/ckbnas_sata4_health_check.sh /volume1/homes/fnvtk/scripts/install_ckbnas_fix_cron.sh'
```
---
## 八、日志位置
| 日志 | 路径 |
|:-----|:-----|
| 修复日志 | `/volume1/homes/fnvtk/scripts/karuo-network-watchdog/logs/ckbnas_fix_sata4_memory_*.log` |
| 健康检测日志 | `/volume1/homes/fnvtk/scripts/karuo-network-watchdog/logs/sata4_health_*.log` |
| cron日志 | `/volume1/homes/fnvtk/scripts/karuo-network-watchdog/logs/cron_fix.log` |
---
## 九、验证清单
- [x] sata4状态为offline
- [x] ContainerManager已禁用
- [x] 所有容器RestartPolicy为no
- [x] 可用内存>2GB（当前5.8GB）
- [x] DSM 5000/5001可访问
- [x] MongoDB运行正常
- [x] tencent_cloud_sync.py高内存进程已清理
---
## 十、关于"硬盘5"的说明（2026-07-10）
### 10.1 DSM显示的"硬盘5"对应关系
群晖DSM界面中的硬盘编号与系统设备名的对应关系：
| DSM显示 | 系统设备名 | 槽位 | 状态 |
|:--------|:----------:|:----:|:-----|
| 硬盘1 | sata1 | 槽位1 | 良好 |
| 硬盘2 | sata2 | 槽位2 | 良好 |
| 硬盘5 | sata4 | 槽位4 | ⚠️ 严重 |
| 硬盘6 | sata3 | 槽位3 | 良好 |
> **注意**：DSM的硬盘编号与物理槽位编号不一致！"硬盘5"实际上是系统中的`sata4`设备。
### 10.2 硬盘5（sata4）问题分析
**问题根因**：Synology HAT3320-8T硬盘（槽位4）出现I/O错误
| 项目 | 详情 |
|:-----|:-----|
| 硬盘型号 | Synology HAT3320-8T |
| 序列号 | 2590Z9R22A02QFALL（对应scsi6） |
| 错误类型 | FLUSH CACHE失败、Buffer I/O error |
| 当前状态 | offline（已从RAID中移除） |
| RAID影响 | md2（RAID5）降级为3盘运行 [_UUU] |
### 10.3 已执行的修复操作
1. ✅ 将sata4设置为offline状态
2. ✅ 从RAID5（md2）中移除sata4p5
3. ✅ 从RAID1（md0）中移除sata4p1
4. ✅ 配置cron定时检测sata4状态
5. ✅ 添加开机自动修复脚本
### 10.4 后续处理建议
| 步骤 | 说明 |
|:-----|:-----|
| **物理更换** | 购买新的8TB硬盘（推荐同型号HAT3320-8T） |
| **热插拔** | 在NAS运行状态下替换槽位4的硬盘 |
| **重建RAID** | DSM会自动检测新硬盘并开始RAID重建 |
| **同步数据** | 预计RAID5重建时间：8～12小时 |
---
## 十一、新增高内存问题修复（2026-07-10）
### 11.1 问题发现
在检查内存状态时发现4个`tencent_cloud_sync.py`进程占用约70%内存：
| 进程 | PID | 内存占用 | 状态 |
|:-----|:---:|:--------:|:-----|
| tencent_cloud_sync.py | 24452 | 17.8% (~1.4GB) | D (不可中断睡眠) |
| tencent_cloud_sync.py | 24199 | 17.7% (~1.4GB) | D (不可中断睡眠) |
| tencent_cloud_sync.py | 24497 | 17.6% (~1.4GB) | D (不可中断睡眠) |
| tencent_cloud_sync.py | 24160 | 17.5% (~1.4GB) | D (不可中断睡眠) |
**影响**：内存从6GB骤降至400MB，Swap耗尽
### 11.2 问题根因
`tencent_cloud_sync.py`脚本存在以下问题：
1. **重复启动**：同一脚本被启动4次，无进程冲突检测
2. **内存泄漏**：每个进程占用1.4GB内存，且处于D状态（不可中断）
3. **缺少限制**：无内存限制和进程数限制
4. **启动方式未知**：未找到对应的cron任务或docker容器
### 11.3 修复措施
1. ✅ 紧急终止所有tencent_cloud_sync.py进程
2. ✅ 更新修复脚本，添加自动检测和清理高内存进程功能
3. ✅ 内存恢复正常（可用6GB）
### 11.4 防止复发措施
修复脚本已添加以下防护：
```bash
# 紧急清理高内存进程（tencent_cloud_sync.py等）
HIGH_MEM_PIDS=$(ps aux --sort=-%mem | grep -E 'python.*tencent_cloud_sync' | grep -v grep | awk '{print $2}')
if [ -n "$HIGH_MEM_PIDS" ]; then
kill -9 $HIGH_MEM_PIDS
fi
```
---
## 十二、当前NAS状态（2026-07-10）
| 项目 | 状态 | 详情 |
|:-----|:-----|:-----|
| 内存 | ✅ 正常 | 8GB，可用6GB |
| Swap | ✅ 正常 | 2GB，使用357MB |
| sata4 | ✅ online | **已重新加入RAID** |
| RAID5 (md2) | 🟡 重建中 | 4盘运行，recovery=DELAYED |
| RAID1 (md0/md1) | 🟡 重建中 | 4盘运行，recovery进行中 |
| MongoDB | ✅ 运行 | 端口27017，限制2GB |
| Gitea | ✅ 运行 | 端口3000，限制512MB |
| xmfst-web | ✅ 运行 | 端口3105，限制1GB |
| AIConsole | ✅ 已禁用 | 释放193MB内存 |
| 负载 | ✅ 正常 | load average: ~3.5 |
---
## 十四、sata4硬盘重新上线修复（2026-07-10 06:40）
### 14.1 问题根因
**sata4硬盘并未损坏！** 而是被误操作设为offline后导致ATA链路禁用（ata7.00: disabled）。
| 项目 | 详情 |
|:-----|:-----|
| 硬盘型号 | Synology HAT3320-8T |
| 序列号 | 2590Z9R22A02SFALL |
| 温度 | 38°C（正常） |
| 之前状态 | offline（被误设） |
| 当前状态 | online（已恢复） |
### 14.2 修复过程
1. **发现问题**：`synodisk --enum`显示sata4温度-1°C（异常），磁盘被识别但处于offline状态
2. **定位原因**：dmesg显示`ata7.00: disabled`，ATA链路被禁用
3. **重新扫描**：执行SCSI总线重新扫描，磁盘重新识别
4. **加入RAID**：成功将sata4p1/p2/p5加入md0/md1/md2阵列
5. **开始重建**：RAID1(md0/md1)开始同步，RAID5(md2)等待中
### 14.3 当前RAID重建状态
| 阵列 | 状态 | 进度 | 预计完成 |
|:-----|:-----|:-----|:--------:|
| md0 (RAID1) | 重建中 | 0.1% | ~23分钟 |
| md1 (RAID1) | 重建中 | 0.5% | ~6分钟 |
| md2 (RAID5) | 等待中 | DELAYED | 稍后开始 |
### 14.4 经验教训
**不要轻易将硬盘设为offline！**：
- sata4硬盘本身没有硬件故障
- 之前的offline状态是人为设置的
- 硬盘重新上线后一切正常，温度38°C
**群晖DSM与Linux设备名对应**：
- DSM显示的"硬盘5"对应系统中的`sata4`
- DSM显示的"硬盘6"对应系统中的`sata3`
- 不要混淆硬盘编号和系统设备名
### 14.5 修复后的磁盘状态
| DSM显示 | 系统设备 | 型号 | 温度 | 状态 |
|:--------|:--------:|:----:|:----:|:-----|
| 硬盘1 | sata1 | HAT3320-8T | 39°C | ✅ 在线 |
| 硬盘2 | sata2 | HAT3320-8T | 38°C | ✅ 在线 |
| 硬盘5 | sata4 | HAT3320-8T | 38°C | ✅ 在线 |
| 硬盘6 | sata3 | HAT3320-8T | 40°C | ✅ 在线 |
---
## 十三、内存问题二次修复（2026-07-10 06:30）
### 13.1 问题现象
DSM监控显示RAM占用87%，可用内存仅360MB。
### 13.2 问题根因
| 问题 | 详情 |
|:-----|:-----|
| buff/cache过高 | 6.4GB页面缓存未释放 |
| 容器mem_limit不生效 | docker-compose V2不支持mem_limit语法，需用docker update |
| AIConsole后台运行 | 占用193MB内存 |
| 残留搜索进程 | grep/find进程占用CPU和内存 |
### 13.3 修复措施
1. ✅ 清理页面缓存：`echo 3 > /proc/sys/vm/drop_caches`
2. ✅ docker update设置内存限制：
- mongodb: --memory=2g --memory-swap=2g
- xmfst-web: --memory=1g --memory-swap=1g
- gitea: --memory=512m --memory-swap=512m
3. ✅ 终止残留搜索进程（PID 14898, 24807）
4. ✅ 禁用AIConsole服务
### 13.4 修复后容器内存限制
| 容器 | 内存限制 | 实际占用 |
|:-----|:--------:|:--------:|
| mongodb | 2GB | 18MB |
| xmfst-web | 1GB | 69MB |
| gitea | 512MB | 121MB |
### 13.5 经验教训
**docker-compose V2内存限制问题**：
- `mem_limit:` 语法在docker-compose V2中不生效
- 需要使用 `docker update --memory=X --memory-swap=X` 命令
- 或修改docker-compose.yml使用 `deploy.resources.limits.memory` 格式
**定期清理缓存**：
- Linux会将空闲内存用于文件缓存（buff/cache）
- 当内存紧张时系统会自动释放，但可手动清理：`echo 3 > /proc/sys/vm/drop_caches`
### 验证清单
- [x] MongoDB服务正常运行
- [x] RAID md2=[_UUU]（降级运行）
- [x] 定时任务已安装
- [x] 无新的I/O错误
- [x] 所有容器已添加有效的mem_limit
- [x] AIConsole已禁用
- [x] 页面缓存已清理
- [x] deploy.resources.limits已替换为mem_limit
## 十、防止OOM复发的关键措施
1. **mem_limit强制生效**：所有docker-compose.yml使用`mem_limit`而非`deploy.resources.limits`
2. **高耗栈禁用**：Ollama、VM、karuo-ai网关已禁用，防止自动启动
3. **ContainerManager禁用自启**：开机不会自动启动Docker
4. **RestartPolicy=no**：容器崩溃后不会自动重启引发连锁反应
5. **定时健康检测**：每10分钟检测sata4状态和I/O错误
6. **开机自动修复**：@reboot自动执行修复脚本
7. **staged boot禁用**：防止开机后分批启动容器
---
## 十五、脚本修复：防止下次重启破坏RAID（2026-07-10 06:45）
### 15.1 问题
之前的`ckbnas_fix_sata4_and_memory.sh`在启动时会将sata4设为offline，这会在下次NAS重启时破坏刚修复的RAID。
### 15.2 修复内容
**`ckbnas_fix_sata4_and_memory.sh`**：
- 将`fix_sata4()`函数逻辑反转
- 现在检查sata4是否为offline，如果是则尝试重新上线并加入RAID
- 如果设备不存在，自动重新扫描SCSI总线
**`ckbnas_sata4_health_check.sh`**：
- 更新健康检查逻辑，running状态为正常
- offline状态为异常，建议rescan
### 15.3 脚本已上传到NAS
- ✅ `/volume1/homes/fnvtk/scripts/ckbnas_fix_sata4_and_memory.sh`
- ✅ `/volume1/homes/fnvtk/scripts/ckbnas_sata4_health_check.sh`
### 15.4 定时任务确认
| 任务 | 频率 | 脚本 |
|:-----|:-----|:-----|
| 开机修复 | @reboot | ckbnas_fix_sata4_and_memory.sh |
| 健康检测 | */10 * * * * | ckbnas_sata4_health_check.sh |
---
## 十六、最终验证结果（2026-07-10 06:45）
### 16.1 磁盘状态（全部在线）
| DSM显示 | 系统设备 | 型号 | 温度 | 状态 |
|:--------|:--------:|:----:|:----:|:-----|
| 硬盘1 | sata1 | HAT3320-8T | 39°C | ✅ 在线 |
| 硬盘2 | sata2 | HAT3320-8T | 38°C | ✅ 在线 |
| 硬盘5 | sata4 | HAT3320-8T | 38°C | ✅ 在线 |
| 硬盘6 | sata3 | HAT3320-8T | 40°C | ✅ 在线 |
### 16.2 RAID状态（重建中）
| 阵列 | 类型 | 状态 | 进度 | 预计完成 |
|:-----|:-----|:-----|:-----|:--------:|
| md0 | RAID1 | ✅ 完成 | 100% | - |
| md1 | RAID1 | ✅ 完成 | 100% | - |
| md2 | RAID5 | 🟡 重建中 | 0.0% | ~30小时 |
### 16.3 系统状态
| 项目 | 值 | 状态 |
|:-----|:--:|:-----|
| 内存总量 | 7894MB | ✅ |
| 可用内存 | 6083MB | ✅ |
| Swap使用 | 356MB | ✅ |
| 负载 | ~2.9 | ✅ |
| MongoDB | 运行中 | ✅ |
| Gitea | 运行中 | ✅ |
| xmfst-web | 运行中 | ✅ |
### 16.4 重要提示
**RAID5重建需要约30小时**，在此期间：
- ✅ NAS可正常使用
- ✅ 数据安全有保障（4盘RAID5，3盘即可运行）
- ✅ 重建完成后自动恢复完整冗余
---
*版本 v1.2 | 2026-07-10*（添加sata4重新上线修复和脚本修正）