## 一、什么是终端复用？

### 核心定义

终端复用（Terminal Multiplexer）是一种**在单个物理终端窗口中管理多个虚拟终端会话**的软件层。它位于操作系统内核与用户 Shell 之间，提供以下关键能力：

```
┌───────────────────────────────────────┐
│           用户界面层                   │
│    （iTerm2、Windows Terminal、Kitty） │
├───────────────────────────────────────┤
│      🔧 终端复用层（Tmux/Zellij）      │  ← 核心位置
│   • 会话管理  • 窗口分割  • 状态保持    │
├───────────────────────────────────────┤
│           Shell 层（Bash/Zsh）         │
├───────────────────────────────────────┤
│           操作系统内核                 │
└───────────────────────────────────────┘
```

### 解决的三大痛点

| 痛点           | 传统终端                      | 复用工具               |
| -------------- | ----------------------------- | ---------------------- |
| **网络中断**   | SSH 断开，任务终止            | 会话保持后台，随时重连 |
| **单窗口限制** | 开多个终端窗口混乱            | 单窗口多会话，分屏管理 |
| **上下文丢失** | 关闭终端 = 丢失工作目录、历史 | 完整状态持久化         |

------

## 二、核心架构与工作原理

### 1. 会话生命周期管理

```
# 传统 SSH 连接的生命周期
[本地终端] ──SSH──► [远程 Shell 进程]
     │                    │
     │ 网络断开            │ 进程收到 SIGHUP，终止
     ▼                    ▼
  连接中断 ◄────────── 任务丢失

# 复用工具的生命周期
[本地终端] ──SSH──► [Tmux Server 守护进程] ◄── 长期存活
                         │
              ┌─────────┼─────────┐
              ▼         ▼         ▼
         [Shell A]  [Shell B]  [Shell C]
         运行任务    编辑文件    监控日志
              │         │         │
              └─────────┴─────────┘
                    网络断开不影响
              [新终端] ──attach──► 恢复原状
```

### 2. 核心组件模型

| 组件        | 类比         | 功能                         |
| ----------- | ------------ | ---------------------------- |
| **Server**  | 操作系统服务 | 后台守护进程，管理所有会话   |
| **Session** | 浏览器窗口   | 独立的工作空间，包含多个窗口 |
| **Window**  | 浏览器标签页 | 全屏的虚拟终端，可切换       |
| **Pane**    | 分屏区域     | 窗口内的分割区域，同时可见   |

### 3. 进程关系图解

```
系统启动
   │
   ▼
┌─────────────┐     ┌─────────────┐
│ Tmux Server │◄────│ Zellij Daemon│  （二选一，长期运行）
│  (PID 1234) │     │  (PID 5678)  │
└──────┬──────┘     └─────────────┘
       │
       ├─────────────────────────────────┐
       │                                 │
       ▼                                 ▼
┌─────────────┐                 ┌─────────────┐
│ Session: dev │                │ Session: ops │
│ ┌─────────┐ │                │ ┌─────────┐   │
│ │Window 1 │ │                │ │Window 1 │   │
│ │ ┌─┬───┐ │ │                │ │ ┌───┐   │   │
│ │ │ │   │ │ │                │ │ │   │   │   │
│ │ │Pane │ │ │                │ │ │Pane │   │   │
│ │ │ 1  2│ │ │                │ │ └───┘   │   │
│ │ │ │   │ │ │                │ └─────────┘   │
│ │ └──┴───┘ │ │                │ Window 2...   │
│ └─────────┘ │                └─────────────┘
│ Window 2... │
└─────────────┘

用户通过 Client 连接 Server：
tmux attach → Unix Socket → Server → 恢复 Session 状态
```

------

## 三、技术演进时间线

```
1970s ─────────────────────────────────────────► 2020s

1987  GNU Screen 诞生
      └─ 首个终端复用器，解决拨号连接不稳定问题

2007  Tmux 发布
      └─ BSD 协议，现代化设计，分屏功能革新

2010s 配置生态爆发
      └─ Tmuxinator、Teamocil 等会话管理工具

2020  Zellij 发布（Rust 重写）
      └─ 零配置、插件系统、WebAssembly 扩展

2021  WezTerm、Tabby 等 GPU 终端内置复用
      └─ 终端与复用层边界模糊化

2023  AI 终端（Warp、Fig）兴起
      └─ 复用功能成为基础能力，转向智能化
```

------

## 四、主流工具深度对比

### 功能矩阵

| 特性           | GNU Screen    | Tmux        | Zellij    | Byobu        |
| -------------- | ------------- | ----------- | --------- | ------------ |
| **首次发布**   | 1987          | 2007        | 2020      | 2009         |
| **代码语言**   | C             | C           | Rust      | Python/Shell |
| **后端依赖**   | 无            | 无          | 无        | Tmux/Screen  |
| **默认安装**   | 几乎所有 Unix | 主流服务器  | 需手动    | Ubuntu 预装  |
| **学习曲线**   | 陡峭          | 中等        | 平缓      | 平缓         |
| **配置复杂度** | 高            | 中          | 极低      | 低           |
| **分屏灵活性** | ⭐⭐            | ⭐⭐⭐⭐        | ⭐⭐⭐⭐⭐     | ⭐⭐⭐          |
| **鼠标支持**   | ❌             | ✅（需配置） | ✅（原生） | ✅            |
| **插件生态**   | 弱            | 极丰富      | growing   | 无           |
| **远程协作**   | ❌             | ✅（tmate）  | ✅（内置） | ❌            |
| **资源占用**   | 极低          | 低          | 中        | 中           |

### 架构设计哲学对比

#### Tmux：Unix 哲学

```
"Do one thing and do it well"
• 专注会话管理，不替代 Shell
• 通过插件扩展（TPM 管理器）
• 高度可定制，配置即代码

典型用户：运维工程师、后端开发者
```

#### Zellij：现代产品思维

```
"Batteries included"
• 约定优于配置，开箱即用
• 内置布局系统、插件市场
• 视觉反馈优先，降低记忆负担

典型用户：全栈开发者、新手友好
```

#### Screen：兼容至上

```
"Run everywhere"
• 30 年向后兼容
• 嵌入式、路由器、老旧系统
• 功能精简但稳定

典型用户：嵌入式开发、遗留系统维护
```

------

## 五、核心机制详解

### 1. 会话持久化原理

```
# 传统进程信号处理
SIGHUP (Hangup) → 终端断开 → 默认终止进程

# 复用工具的防护机制
┌─────────────┐
│   用户进程   │ ◄── 运行在伪终端（PTY）上
│   (vim/top) │
└──────┬──────┘
       │
┌──────▼──────┐
│  Tmux Server │ ◄── 守护进程，忽略 SIGHUP
│  (daemon)   │     通过 Unix Socket 通信
└─────────────┘
       │
┌──────▼──────┐
│  Tmux Client │ ◄── 可随时 attach/detach
│  (终端连接)  │
└─────────────┘
```

### 2. 滚动缓冲区与复制模式

```
┌────────────────────────────┐
│  屏幕显示区域（可见部分）    │ ◄── 实时输出
│  $ ps aux                  │
│  USER  PID %CPU %MEM       │
│  ...                       │
├────────────────────────────┤
│  滚动缓冲区（历史记录）       │ ◄── 可回溯查看
│  [10000 行历史数据]         │
│  支持搜索、复制、导出        │
└────────────────────────────┘

操作示例：
Ctrl+b [        # 进入复制模式
↑/↓ 或 PgUp/PgDn  # 滚动
/ 或 ?          # 搜索（正向/反向）
Space           # 开始选择
Enter           # 复制到缓冲区
Ctrl+b ]        # 粘贴
```

### 3. 客户端-服务器分离架构

```
# 查看 Tmux 进程结构
$ ps aux | grep tmux
user    1234  ... tmux: server (/tmp/tmux-1000/default)
user    5678  ... tmux: client (/tmp/tmux-1000/default)

# 服务器持续运行，即使所有客户端断开
$ tmux ls
dev: 2 windows (created Wed Jan 10 09:00:00 2024)
ops: 1 windows (created Wed Jan 10 10:30:00 2024)

# 从另一台机器重新连接
$ ssh server
$ tmux attach -t dev  # 恢复原会话
```

------

## 六、选型决策树

```
开始选择终端复用工具
        │
        ▼
    是否老旧/嵌入式系统？
        │
    ┌───┴───┐
    是       否
    │        ▼
    ▼    是否追求开箱即用？
 GNU Screen   │
              │
          ┌───┴───┐
          是       否
          │        ▼
          ▼    是否需要丰富插件？
       Zellij     │
                  │
              ┌───┴───┐
              是       否
              │        ▼
              ▼    是否需要状态栏增强？
           Tmux + TPM  │
                      │
                  ┌───┴───┐
                  是       否
                  │        ▼
                  ▼      选择 Tmux
               Byobu    （标准配置）
```

------

## 七、现代演进趋势

### 1. 边界模糊化：终端内置复用

```
# WezTerm 内置多路复用
wezterm cli spawn --new-window
wezterm cli list --format=json

# Tabby 内置分屏 + SSH 管理
# Warp 基于云的会话同步
```

### 2. 云原生适配

| 场景       | 解决方案                      |
| ---------- | ----------------------------- |
| Kubernetes | `kubectl exec` + tmux sidecar |
| 容器开发   | Dev Containers + Zellij 布局  |
| 云端 IDE   | GitHub Codespaces 内置复用    |
| 无服务器   | 不适用（无持久化环境）        |

### 3. AI 集成方向

```
传统复用工具          下一代工具
    │                    │
    ▼                    ▼
┌─────────┐        ┌─────────────┐
│ 状态保持 │   +    │ AI 上下文感知 │
│ 分屏管理 │        │ 智能命令建议  │
│ 会话恢复 │        │ 自然语言操作  │
└─────────┘        │ 自动错误诊断  │
                   └─────────────┘
                   
示例：Warp 的 AI 命令搜索
"帮我找一个占用 CPU 高的进程"
→ 自动生成：ps aux --sort=-%cpu | head -n 5
```

------

## 八、最佳实践总结

### 黄金法则

1. **服务器必装**：所有远程服务器预装 tmux/screen
2. **命名规范**：`环境-项目-用途`（如 `prod-api-logs`）
3. **定期清理**：`tmux ls` 检查僵尸会话，避免资源泄漏
4. **配置同步**：dotfiles 管理配置文件，跨机器一致
5. **组合使用**：Mosh（网络层）+ Tmux（会话层）= 终极稳定

### 性能考量

```
资源占用对比（空闲状态）：
• Screen: ~1MB 内存
• Tmux:   ~5MB 内存  
• Zellij: ~15MB 内存（Rust 运行时）
• 每个窗格额外: +~2MB

现代服务器可忽略，嵌入式选 Screen。
```

------

## 结语

终端复用工具是**命令行工作流的基石基础设施**。从 1987 年的 Screen 到 2024 年的 AI 终端，其核心使命始终不变：**让计算会话超越物理连接的局限**。

掌握这一层工具，意味着从"操作终端"进阶到"编排计算环境"，是每位命令行用户的必修课。

终端复用原理到实践

## 一、故障症状速查表

| 现象                              | 可能层级  | 紧急程度   |
| --------------------------------- | --------- | ---------- |
| `nvidia-smi` 报错 / 无输出        | 驱动/内核 | 🔴 高       |
| GPU 温度 > 90°C / 降频            | 散热      | 🟡 中       |
| 显存不足 OOM                      | 应用/配置 | 🟡 中       |
| ECC 单比特错误 (SBE)              | 显存老化  | 🟡 中       |
| ECC 双比特错误 (DBE)              | 显存损坏  | 🔴 **极高** |
| 训练 loss 异常 / 结果不对         | 计算单元  | 🔴 高       |
| PCIe 报错 / 掉卡                  | 硬件连接  | 🔴 高       |
| 功耗不达标 / 电源告警             | 供电      | 🟡 中       |

------

## 二、分层排查流程图

```
┌─────────────────┐
│   现象观察      │
│  nvidia-smi /   │
│  应用报错 /     │
│  系统日志       │
└────────┬────────┘
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 驱动是否正常？   │ ─────────→│  驱动层排查      │
│ nvidia-smi 有输出│           │ 重装/降级/补丁   │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 能否识别硬件？   │ ─────────→│  硬件层排查      │
│ lspci 有 NVIDIA │           │ 重插/换槽/换卡   │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 温度/功耗异常？  │ ─────────→│  散热/供电排查   │
│                 │           │ 清灰/换硅脂/查电源│
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐     Y     ┌─────────────────┐
│ 显存/计算错误？  │ ─────────→│  ECC/计算单元排查│
│ ECC 报错 / loss 异常│        │ 隔离故障卡/报修  │
└────────┬────────┘           └─────────────────┘
         │ N
         ▼
┌─────────────────┐
│  软件/应用层    │
│  CUDA 版本 /    │
│  代码逻辑 /     │
│  集群调度       │
└─────────────────┘
```

------

## 三、逐层详细排查

### 第一层：驱动层（最常见）

#### 3.1.1 快速诊断

```
# 基础检查
nvidia-smi                    # 无输出 = 驱动问题
dmesg | grep -i nvidia        # 内核报错
cat /var/log/nvidia-installer.log  # 安装日志

# 驱动状态
modinfo nvidia                # 驱动模块信息
lsmod | grep nvidia           # 模块是否加载
cat /proc/driver/nvidia/version  # 驱动版本
```

#### 3.1.2 常见问题与修复

| 现象                                         | 根因             | 修复                       |
| -------------------------------------------- | ---------------- | -------------------------- |
| `nvidia-smi` 报 `Failed to initialize NVML`  | 驱动与内核不匹配 | 重装驱动或降级内核         |
| `modprobe: ERROR: could not insert 'nvidia'` | Secure Boot 阻止 | BIOS 关闭 Secure Boot      |
| 新内核启动后失效                             | DKMS 未自动编译  | `sudo dkms autoinstall`    |
| CUDA 版本不匹配                              | 多版本冲突       | `update-alternatives` 管理 |

#### 3.1.3 驱动重装（保留配置）

```
参考该篇文章
http://8.148.180.168:4000/post/87
```

------

### 第二层：硬件识别层

#### 3.2.1 PCIe 链路检查

```
# 查看 GPU 是否在总线上
lspci | grep -i nvidia
# 输出示例：0000:41:00.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB]

# 详细链路状态
sudo lspci -vv -s 0000:41:00.0 | grep -E "LnkCap|LnkSta"
# LnkCap: 链路能力（支持 PCIe 3.0 x16）
# LnkSta: 当前状态（实际协商速度）

# 关键：若 LnkSta 显示 x4 或 PCIe 1.0 = 插槽/线缆问题
```

#### 3.2.2 物理定位

```
# 获取槽位信息（用于带外定位）
sudo dmidecode -t slot | grep -B2 -A2 "Bus Address: 41"

# 或结合温度定位（跑压力测试后看 BMC 温度）
./gpu_burn 60 &
# 然后到 IPMI/BMC 查看各 PCIe 设备温度，最高即目标卡
```

#### 3.2.3 掉卡/链路降级处理

```
# 1. 软件层面重扫描（无需重启）
echo 1 | sudo tee /sys/bus/pci/rescan

# 2. 若无效，热卸载后重识别（内核 4.19+）
sudo nvidia-smi drain -p 0000:41:00.0 -m 1    # 卸载
echo 1 | sudo tee /sys/bus/pci/rescan          # 重扫
sudo nvidia-smi drain -p 0000:41:00.0 -m 0    # 重新启用

# 3. 仍无效 = 物理重插或换槽
```

------

### 第三层：散热与功耗层

#### 3.3.1 温度监控

```
# 实时温度
watch -n 1 nvidia-smi

# 详细温度与限制
nvidia-smi -q -d TEMPERATURE,PERFORMANCE,POWER
# 关键字段：
# - GPU Current Temp
# - GPU Shutdown Temp（硬限制，通常 100°C）
# - GPU Slowdown Temp（软限制，通常 85°C）
# - Clocks Throttle Reasons（若显示 "HW Slowdown" = 过热降频）
```

#### 3.3.2 压力测试验证散热

```
# 满载测试 5 分钟
./gpu_burn 300

# 观察：
# - 温度是否持续上升至 90°C+
# - 是否触发 [Clocks Throttle Reasons] "HW Slowdown"
# - 功耗是否达到 TDP（如 300W/300W）
```

#### 3.3.3 散热故障处理

| 现象                 | 处理                          |
| -------------------- | ----------------------------- |
| 温度高但风扇不转     | 检查风扇电源线 / 更换风扇模组 |
| 温度高但风速低       | BIOS 清灰 / 更换轴承老化风扇  |
| 温度高、风速高仍降频 | 更换硅脂 / 检查散热器接触     |
| 多卡温差 > 15°C      | 检查风道 / 调整卡间距         |

------

### 第四层：显存与计算层（ECC 错误）

#### 3.4.1 ECC 错误查询

```
# 查看 ECC 统计
nvidia-smi -q -d ECC
# 或
nvidia-smi ecc --error-correcting-code-config

# 关键字段：
# - Aggregate ECC Errors
#   - Single Bit: 可纠正，监控即可
#   - Double Bit: 不可纠正，立即更换
```

#### 3.4.2 显存压力测试

```
# 显存满载测试（触发潜在故障）
./gpu_burn 600 -m 100%  # 10 分钟满载

# 同时监控
watch -n 5 'nvidia-smi -q -d ECC,MEMORY | grep -A5 "ECC Errors"'
```

#### 3.4.3 ECC 错误处理流程

```
发现 SBE（单比特错误）
    │
    ├── 错误数 < 10/天 ──→ 监控，记录趋势
    │
    └── 错误数 > 10/天 或持续增长
            │
            ▼
    运行显存压力测试 30 分钟
            │
            ├── 测试期间无新增 ──→ 继续监控
            │
            └── 测试期间新增或出现 DBE
                    │
                    ▼
            标记故障卡 → 隔离任务 → 申请更换
```

#### 3.4.4 显存行重映射（Row Remapping）

```
# 查看重映射状态
nvidia-smi -q | grep -A10 "Row Remapper"

# 关键字段：
# - Remapping Failure: Yes = 显存物理损坏，必须换卡
# - Remapped Rows: 计数持续增长 = 老化预警
```

------

### 第五层：软件与应用层

#### 3.5.1 CUDA 与驱动兼容性

```
# 查看 CUDA 版本
nvcc --version
cat /usr/local/cuda/version.json 2>/dev/null || ls /usr/local/cuda*

# 兼容性矩阵（关键）
# CUDA 12.x 需要驱动 >= 525.60.13
# CUDA 11.8 需要驱动 >= 450.80.02

# 若应用报 CUDA error 35 / 999
# = 驱动/CUDA/应用版本三角不匹配
```

#### 3.5.2 应用级调试

```
# CUDA 内存检查
cuda-memcheck ./your_app

# Nsight 详细分析
nsys profile -t cuda,nvtx,osrt -o report.qdrep ./your_app
ncu --metrics sm__throughput.avg.pct_of_peak_sustained_elapsed ./your_app
```

------

## 四、故障定位速查命令集

```
# ========== 30 秒快速诊断 ==========
nvidia-smi                                    # 基础状态
nvidia-smi -q | grep -E "Serial|Product|Temp|Power|ECC|Remap"  # 关键信息
dmesg | tail -50 | grep -iE "nvidia|pcie|error|warn"           # 内核日志
lspci | grep -i nvidia                        # 硬件识别
sudo ipmitool sel list | grep -iE "gpu|pcie|temp|fan"          # 带外日志

# ========== 深度诊断 ==========
nvidia-smi -q -d ECC,TEMPERATURE,PERFORMANCE,POWER,CLOCK,PCIE  # 全维度
cat /proc/driver/nvidia/gpus/*/information                     # 每卡详情
sudo nvidia-bug-report.sh                                      # 官方诊断脚本

# ========== 压力验证 ==========
./gpu_burn 300 -m 100%                      # 核心+显存满载
./gpu_burn 600                              # 长时间稳定性
```

------

## 五、典型故障案例

### 案例 1：训练中途 loss 突变为 NaN

| 排查            | 结果                    |
| --------------- | ----------------------- |
| `nvidia-smi -q` | ECC SBE 计数 10万+      |
| 显存压力测试    | 10 分钟内新增 50 个 SBE |
| 根因            | 显存老化，偶发位翻转    |
| 处理            | 隔离该卡，更换后正常    |

### 案例 2：8 卡集群随机掉卡

| 排查        | 结果                                         |
| ----------- | -------------------------------------------- |
| `lspci -vv` | 掉线卡显示 `LnkSta: Speed 2.5GT/s, Width x4` |
| 正常卡      | `LnkSta: Speed 16GT/s, Width x16`            |
| 根因        | PCIe 延长线接触不良，协商降级                |
| 处理        | 重插线缆，固定卡扣，正常                     |

### 案例 3：新装机 nvidia-smi 无输出

| 排查         | 结果                                            |
| ------------ | ----------------------------------------------- |
| `dmesg`      | `NVRM: The NVIDIA probe routine was not called` |
| `secureboot` | BIOS 中 Enabled                                 |
| 根因         | Secure Boot 阻止未签名驱动                      |
| 处理         | BIOS 关闭 Secure Boot，正常                     |

------

## 六、预防性维护建议

| 周期 | 动作                    | 工具                         |
| ---- | ----------------------- | ---------------------------- |
| 每日 | 监控 ECC 错误趋势       | `nvidia-smi -q` + Prometheus |
| 每周 | 温度/功耗基线对比       | `nvidia-smi dmon`            |
| 每月 | 压力测试验证稳定性      | `gpu_burn 600`               |
| 每季 | 物理清灰，硅脂检查      | 目视 + 温度压测              |
| 每年 | 全卡 ECC 清零，趋势分析 | `nvidia-smi --ecc-reset`     |



常见GPU故障问题排查步骤

## 一、测试哲学：理解「瞬冲」与「稳态」

| 测试类型     | 代表工具                | 特点                                 | 适用场景               |
| ------------ | ----------------------- | ------------------------------------ | ---------------------- |
| **瞬冲极限** | FurMark、gpu-burn       | 人为解锁功耗墙，散热允许下的绝对极限 | 散热设计验证、出厂烤机 |
| **稳态负载** | 实际训练任务、stress-ng | 持续可预期的负载模式                 | 日常稳定性评估         |
| **随机轰炸** | stress-ng 混合模式      | CPU/内存/IO/中断同时扰动             | 系统级鲁棒性测试       |

**关键认知**：

- 压测工具的「瞬冲」是 **人为解锁 + 散热允许** 的极限场景
- 日常训练/推理 **不会触及** 这种极限（有自动降频、队列调度）
- 故障定位时，**先稳态复现，再瞬冲确认**

------

## 二、CPU 压力测试

### 2.1 基础满载测试

```
# 全核满载 5 分钟（自动选择最优算法）
stress-ng --cpu 0 --timeout 5m --times

# 指定 8 线程跑矩阵乘法 30 分钟（AVX/AVX-512 自动启用）
stress-ng --cpu 8 --cpu-method matrixprod --timeout 30m
```

### 2.2 温度与节流观察

```
# 全核满载 + 实时温度监控（10 分钟）
stress-ng --cpu 0 --matrix 0 --tz -t 600

# 90% 负载非满血（观察动态调频行为）
stress-ng --cpu 0 --cpu-load 90 --timeout 10m
```

**关键指标**：

- `tz` 列显示温度，超过 85°C 观察是否触发 `CPU MHz` 降频
- `bogo-ops/s` 突降 = 热节流发生

### 2.3 系统级随机轰炸

```
# CPU + IO + VM + 磁盘同时扰动（模拟混沌生产环境）
stress-ng --cpu 4 --io 4 --vm 2 --hdd 2 --timeout 5m --times
```

------

## 三、内存压力测试

### 3.1 基础压测

```
# 安装
sudo apt install stress-ng

# 4 个 worker 分配 4GB，占住不释放，20 分钟
stress-ng --vm 4 --vm-bytes 4G --vm-keep --timeout 20m

# 按总内存百分比施压（24GB 系统压 20% ≈ 4.8GB）
stress-ng --vm 0 --vm-bytes 20% --vm-keep --timeout 10m
```

### 3.2 ECC 错误检测（企业级关键）

```
# 压测同时开另一个终端监控
sudo dmesg -w | grep -iE 'edac|ecc|corrected|uncorrected|hardware error'

# 或通过 IPMI 查看系统事件日志
sudo ipmitool sel list | grep -iE 'memory|ecc|dimm'

# 查看 EDAC 驱动统计
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count   # 可纠正错误
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ue_count   # 不可纠正错误
```

### 3.3 故障内存条定位流程

```
# 步骤 1：带外日志定位故障 DIMM 槽位
sudo dmidecode -t memory | grep -B5 -A5 "Locator:.*DIMM.*" | grep -E "Locator:|Size:|Type:|Speed:"

# 步骤 2：物理拔出后，单条压力测试验证
stress-ng --vm 4 --vm-bytes 80% --vm-method flip -t 5m --times

# 步骤 3：复测带外日志确认无新增 ECC
sudo ipmitool sel clear && stress-ng ... && sudo ipmitool sel list
```

**关键参数 --vm-method flip**：
对内存地址做位翻转（bit flip），专门触发潜在硬件缺陷。

------

## 四、磁盘与 I/O 压力测试

```
# 4 路并发随机写，每路 8GB，5 分钟
stress-ng --hdd 4 --hdd-bytes 8G --timeout 5m

# 同时压测 + IO 延迟监控
iostat -x 1 &
stress-ng --hdd 8 --hdd-bytes 10G --timeout 10m
kill %1
```

**观察指标**：

- `%util` 接近 100% 但 `await` < 10ms = 健康
- `%util` 100% 且 `await` > 50ms = 磁盘瓶颈或故障

------

## 五、GPU 压力测试（核心章节）

### 5.1 工具安装

```
# 官方源（国内可能慢）
git clone https://github.com/wilicc/gpu-burn.git

# 国内加速镜像
git clone https://ghfast.top/https://github.com/wilicc/gpu-burn.git

cd gpu-burn && make
```

### 5.2 基础压测

```
# 全卡满载 120 秒（显存 100% + 核心 100% + Tensor Core）
./gpu_burn 120 -m 100%

# 稳定 80% 负载 500 秒（模拟实际训练强度）
./gpu_burn 500

# 指定显卡（0 号和 3 号卡）
export CUDA_VISIBLE_DEVICES=0,3
./gpu_burn 100
```

### 5.3 与 FurMark 的对比

| 特性           | FurMark           | gpu-burn                  |
| -------------- | ----------------- | ------------------------- |
| 平台           | Windows/Linux GUI | Linux CLI                 |
| 负载类型       | 图形渲染          | CUDA GEMM 计算            |
| 覆盖单元       | 核心 + 显存       | 核心 + 显存 + Tensor Core |
| 自动化         | 难                | 易（脚本化）              |
| 数据中心适用性 | 低                | **高**                    |

### 5.4 温度与故障定位

```
# 实时观察（另开终端）
watch -n 1 nvidia-smi

# 关键指标
nvidia-smi -q -d TEMPERATURE,PERFORMANCE,POWER
```

**过热处理流程**：

```
# 1. 识别故障卡 PCI 槽位
lspci -vv -s 0000:41:00.0 | grep -i "physical slot"
# 或
sudo dmidecode -t slot

# 2. 获取 SN 码（报修用）
nvidia-smi -q | grep "Serial Number"

# 3. 若以上无效，跑压力测试 + 带外温度对比定位
./gpu_burn 60 &
# 然后到 BMC/IPMI 查看各 PCIe 设备温度，最高即目标卡
```

------

## 六、高级：GPU 热插拔与维护

### 6.1 软件层面卸载（内核 4.19+）

```
# 查看卡槽地址
nvidia-smi -q | grep "Bus Id"
# 输出：Bus Id : 0000:41:00.0

# 热卸载（需无进程占用）
sudo nvidia-smi drain -p 0000:41:00.0 -m 1

# 验证状态
nvidia-smi
# 显示：|   2  Tesla V100-PCIE...  Off  | 00000000:41:00.0 Off | **Drain**
```

### 6.2 重新启用

```
# 1. 解除 drain
sudo nvidia-smi drain -p 0000:41:00.0 -m 0

# 2. 重扫 PCIe 总线
echo 1 | sudo tee /sys/bus/pci/rescan

# 3. 验证
nvidia-smi
```

------

## 七、完整验收测试脚本

```
#!/bin/bash
# hardware_stress_test.sh - 出厂验收全流程

LOG="stress_$(date +%F_%H%M).log"
echo "=== 硬件压力测试开始 $(date) ===" | tee $LOG

# 1. CPU 10 分钟满载 + 温度
echo "[1/4] CPU 压力测试..." | tee -a $LOG
stress-ng --cpu 0 --matrix 0 --tz -t 600 --times 2>&1 | tee -a $LOG

# 2. 内存 20 分钟 + ECC 监控
echo "[2/4] 内存压力测试..." | tee -a $LOG
stress-ng --vm 0 --vm-bytes 80% --vm-method flip -t 20m --times 2>&1 | tee -a $LOG &
PID=$!
sleep 10
echo "ECC 错误统计：" | tee -a $LOG
cat /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count 2>/dev/null | tee -a $LOG
wait $PID

# 3. 磁盘 5 分钟
echo "[3/4] 磁盘压力测试..." | tee -a $LOG
stress-ng --hdd 4 --hdd-bytes 8G -t 5m --times 2>&1 | tee -a $LOG

# 4. GPU 2 分钟满载
echo "[4/4] GPU 压力测试..." | tee -a $LOG
if [ -x ./gpu_burn ]; then
    timeout 130 ./gpu_burn 120 -m 100% 2>&1 | tee -a $LOG
else
    echo "gpu-burn 未安装，跳过" | tee -a $LOG
fi

echo "=== 测试完成 $(date) ===" | tee -a $LOG
echo "日志保存至: $LOG"
```

------

## 八、关键结论与建议

| 场景         | 推荐工具                                  | 时长      | 通过标准                      |
| ------------ | ----------------------------------------- | --------- | ----------------------------- |
| 出厂验收     | 上述完整脚本                              | 40 分钟   | 无 ECC 错误、无热节流、无掉卡 |
| 日常巡检     | `stress-ng --cpu 0 -t 60`                 | 1 分钟    | 温度 < 80°C                   |
| 故障内存定位 | `stress-ng --vm-method flip` + 单条测试   | 5 分钟/条 | 故障条复现 ECC，健康条无错    |
| GPU 散热验证 | `gpu_burn 300`                            | 5 分钟    | 温度 < 83°C 无降频            |
| 混沌测试     | `stress-ng --cpu 4 --io 4 --vm 2 --hdd 2` | 10 分钟   | 系统不崩溃、服务不中断        |

------



硬件压力测试

Linux与Windows系统启动原理及故障排查

## 一、安装驱动与 CUDA

### 1.1 在线安装（推荐，自动解决依赖）

#### 步骤 1：添加 NVIDIA 官方源

```bash
# 下载并安装官方密钥包
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb

# 更新软件源缓存
sudo apt update
```
#### 步骤 2：选择驱动版本（二选一）

| 版本          | 适用场景                     | 命令                                        |
| ------------- | ---------------------------- | ------------------------------------------- |
| **Server 版** | 数据中心、无显示器、计算节点 | `sudo apt install nvidia-driver-570-server` |
| **普通版**    | 工作站、有显示器、图形界面   | `sudo apt install nvidia-driver-570`        |

> **注意**：Server 版与普通版 **互斥**，同时安装会导致冲突！

#### 步骤 3：选择 CUDA 安装方式（二选一）

| 方式                  | 特点                       | 命令                                   |
| --------------------- | -------------------------- | -------------------------------------- |
| **官方 CUDA Toolkit** | 版本可控、功能完整、推荐   | `sudo apt install cuda-toolkit-12-8`   |
| **Ubuntu 仓库版**     | 版本固定、可能滞后、不推荐 | `sudo apt install nvidia-cuda-toolkit` |

#### 步骤 4：配置环境变量（官方 CUDA 必需）

```
# 创建环境变量文件
echo 'export PATH=/usr/local/cuda/bin${PATH:+:${PATH}}' | sudo tee /etc/profile.d/cuda.sh
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' | sudo tee -a /etc/profile.d/cuda.sh

# 立即生效
source /etc/profile.d/cuda.sh

# 验证
nvcc --version
nvidia-smi
```

------

### 1.2 离线安装驱动（精确控制小版本）

#### 适用场景

- 需要 **精确驱动版本**（如 580.65.06）
- 内网环境无法连接公网
- 生产环境要求版本锁定

#### 步骤

```
# 1. 从官网下载对应版本
# https://www.nvidia.cn/drivers/lookup/
wget https://us.download.nvidia.cn/XFree86/Linux-x86_64/580.65.06/NVIDIA-Linux-x86_64-580.65.06.run

# 2. 添加执行权限
sudo chmod +x NVIDIA-Linux-x86_64-580.65.06.run

# 3. 安装（关键参数说明）
sudo ./NVIDIA-Linux-x86_64-580.65.06.run \
  --no-opengl-files \      # 不安装 OpenGL（Server 场景推荐）
  --dkms \                  # 使用 DKMS 自动重建内核模块
  --silent \                # 静默安装（批量部署用）
  --no-x-check              # 不检查 X Server（无图形界面必需）

# 4. 验证
nvidia-smi
```

#### 关键参数说明

| 参数                | 作用                               |
| ------------------- | ---------------------------------- |
| `--no-opengl-files` | 不安装 OpenGL 库，避免与 Mesa 冲突 |
| `--dkms`            | 内核升级后自动重建驱动模块         |
| `--silent`          | 无交互安装，适合脚本               |
| `--no-x-check`      | 忽略 X Server 运行状态             |
| `--uninstall`       | 卸载当前驱动                       |

------

### 1.3 离线安装 CUDA（精确控制小版本）

#### 适用场景

- 需要 **精确驱动版本**（如 580.65.06）
- 内网环境无法连接公网
- 生产环境要求版本锁定

#### 步骤

```
# 因为 cuda12.2 已经被官方下架，只能通过本地建仓库或者从官方下载 runfile 进行安装 cuda12.2
# 下载 12.2 runfile（含 535 驱动，但只装 Toolkit）
wget https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run
sudo sh cuda_12.2.0_535.54.03_linux.run --toolkit --silent --override

# 写环境变量
echo 'export PATH=/usr/local/cuda/bin${PATH:+:${PATH}}' | sudo tee -a /etc/profile.d/cuda.sh
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' | sudo tee -a /etc/profile.d/cuda.sh
source /etc/profile

# 验证
nvcc --version
# 若是没有正确返回，则重启后再次尝试
```

------

## 二、完全卸载驱动与 CUDA

### 2.1 标准卸载流程

```
# 步骤 1：停止相关服务
sudo systemctl stop nvidia-persistenced
sudo systemctl stop docker  # 如使用 GPU 容器

# 步骤 2：卸载 NVIDIA 驱动包
sudo apt --purge remove nvidia*

# 步骤 3：卸载 CUDA 相关包
sudo apt --purge remove "*cublas*" "cuda*"

# 步骤 4：再次确认无残留
sudo apt --purge remove "*nvidia*"

# 步骤 5：清理自动依赖
sudo apt autoremove
sudo apt autoclean

# 步骤 6：运行官方 CUDA 卸载程序（如存在）
sudo /usr/local/cuda-12.8/bin/cuda-uninstaller

# 步骤 7：删除残留目录
sudo rm -rf /usr/local/cuda*
sudo rm -rf /opt/cuda*

# 步骤 8：清理内核模块
sudo dkms status | grep nvidia
# 如有输出，执行：
sudo dkms remove nvidia/$(dkms status | grep nvidia | awk -F', ' '{print $2}' | head -1) --all

# 步骤 9：重建 initramfs
sudo update-initramfs -u

# 步骤 10：重启验证
sudo reboot
nvidia-smi  # 应提示 command not found
```

### 2.2 离线安装驱动的卸载

```
# 使用官方自带的卸载脚本
sudo /usr/bin/nvidia-uninstall

# 或重新运行 run 文件加 --uninstall
sudo ./NVIDIA-Linux-x86_64-580.65.06.run --uninstall
```

------

## 三、精准卸载：只卸驱动，保留 CUDA

### 3.1 适用场景

- CUDA 版本正确，只需更换驱动版本
- 驱动升级/降级，不想重装 CUDA Toolkit
- 排查驱动故障，快速回滚

### 3.2 完整步骤

```
# 步骤 1：停止驱动相关服务
sudo systemctl stop nvidia-persistenced

# 步骤 2：尝试卸载内核模块
sudo rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia 2>/dev/null || true

# 步骤 3：如模块正在使用，查找占用进程
sudo lsof /dev/nvidia* 2>/dev/null | grep -v "^COMMAND"

# 步骤 4：停止占用进程（示例：停止容器、推理服务等）
sudo docker stop $(sudo docker ps -q --filter "device=nvidia.com/gpu=all") 2>/dev/null || true
sudo kill -9 <PID>  # 替换为实际 PID

# 步骤 5：确认模块已卸载
lsmod | grep -E 'nvidia|nouveau'  # 应无输出

# 步骤 6：查询已安装的驱动包（精确匹配）
dpkg -l | grep -E 'nvidia-(driver|dkms|kernel|utils|firmware|modprobe|persistenced)'

# 步骤 7：卸载驱动包（保留 cuda-toolkit）
sudo apt-get remove --purge -y \
  nvidia-driver-* \
  nvidia-dkms-* \
  nvidia-kernel-common-* \
  nvidia-firmware-* \
  nvidia-utils-* \
  nvidia-modprobe \
  nvidia-persistenced

# 步骤 8：清理 DKMS 残留
sudo dkms status | grep nvidia
# 如有，执行：
sudo dkms remove nvidia/$(sudo dkms status | grep nvidia | head -1 | awk -F', ' '{print $2}') --all 2>/dev/null || true

# 步骤 9：删除驱动配置文件
sudo rm -rf \
  /lib/modules/*/updates/dkms/nvidia* \
  /etc/nvidia* \
  /etc/modprobe.d/nvidia* \
  /etc/udev/rules.d/*nvidia* \
  /var/lib/dkms/nvidia* \
  /usr/lib/nvidia*

# 步骤 10：重建 initramfs
sudo update-initramfs -u

# 步骤 11：重启并验证
sudo reboot

# 验证：驱动已卸载，CUDA 仍在
nvidia-smi        # 应提示 command not found
nvcc --version    # 应正常显示 CUDA 版本
```

------

## 四、常用诊断命令

### 4.1 查看内核模块状态

```
# 查看已加载的 NVIDIA 模块
lsmod | grep nvidia

# 查看模块详细信息
modinfo nvidia

# 查看模块依赖关系
modprobe --show-depends nvidia
```

### 4.2 查看 GPU 状态

```
# 基础信息
nvidia-smi

# 详细信息（包括温度、功耗、ECC 等）
nvidia-smi -q

# 只看显存信息（指定 GPU 0）
nvidia-smi -q -d MEMORY -i 0

# 持续监控（每秒刷新）
nvidia-smi -l 1

# 查看进程占用
nvidia-smi pmon -s um
```

### 4.3 查看驱动与 CUDA 版本

```
# 驱动版本
cat /proc/driver/nvidia/version

# CUDA 版本（多方式）
nvcc --version
cat /usr/local/cuda/version.json 2>/dev/null || true
ls -la /usr/local/cuda | grep -Po '\d+\.\d+'
```



一、什么是终端复用？

核心定义

一、故障症状速查表

一、测试哲学：理解「瞬冲」与「稳态」

第一部分：Linux 系统启动详解

一、Linux 启动六阶段总览

一、安装驱动与 CUDA

1.1 在线安装（推荐，自动解决依赖）

步骤