服务器相关常用操作手册

• 服务器相关常用操作手册
  • 硬件-device
    • 内存条-DRAM
      • 选配-for-GPU-servers
      • 黄灯常亮
      • 开游戏直接断电重启
  • 系统-system
    • install-debian
    • 用户
      • sudo-免密码
      • ssh
    • 关闭自动锁屏
    • 重启桌面系统
    • hostname
    • PVE
      • 虚拟机系统盘扩容
      • PVE 检修
      • LVM 卷修复
      • 虚拟机网络优化
  • 网络-net
    • 查看网卡型号
    • 配置静态-IP
    • 速度不达标
    • 光口与电口
    • 硬件网络管理协议
    • ethtool 网卡协商
    • iperf3 带宽测试
  • 存储-storage
    • 查看硬盘和分区
    • 网络存储协议
      • ISCSI
      • NFS
    • rsync
    • rclone
      • rclone-s3-migrate
    • tar-压缩解压
    • truenas-zvol-mount
    • ZFS 池维护
    • 硬盘空间
    • 硬盘健康检查
  • 显卡-nvidia
    • 型号分类-diff
    • 驱动-driver
      • 驱动版本选择
      • 卸载降级重装驱动
      • ubuntu-drivers
    • 显卡压测
    • 显卡掉卡
      • 找出故障显卡
      • Xid 79 诊断
      • 暂时禁用故障显卡
      • 查看和限制功率
    • 查看-PCIE
  • terminal
    • tmux
    • btop
      • locale
  • 其他
    • pwm-风扇调控
  • 借物表

搞机相关的攻略收藏夹: ゚ Weidows 的个人空间-゚ Weidows 个人主页-哔哩哔哩视频

硬件-device

内存条-DRAM

选配-for-GPU-servers

经常能看到听到网上的论调是 显存:内存 = 1:2

实际我体验下来, 1:1 完全足够, 训练需要足够大的显存, 但内存一般不会占太高

而且与 Gaming PC 不太一样, 内存的频率和时序对服务器没任何影响, DDR4+ECC 是标准答案

黄灯常亮

主板 DRAM 黄灯常亮, 无法过自检启动

1. 尝试单条测试
2. 尝试换插槽 (13 -> 24, 我就遇到了这个问题, 13 不通过)
3. 等待长一些, 初次加载或者内存超频后内存会自训练半分钟, 自检时间会在半分钟以上, 这段时间也会持续黄灯, 之后就会白灯 -> 绿灯 -> 进系统

---

开游戏直接断电重启

找了贴吧/B 站上很多帖子, 总结一下

• 断电后自动重启 -> 内存/CPU/主板有问题

• 断电后不重启, 需要手动开机 -> 大概率电源坏了

我遇到的是自动重启的 (情况是开 VRchat 时必断电, 开浏览器或者 tm5 时小概率, 甚至有一次开机进桌面直接断电)

我的配置是 14600KF + 5070ti + 750W 鑫谷金牌, 按道理讲完全满载也能冗余出接近 300W, 不应该是电源先炸

最先怀疑的是内存 XMP, 调了半天 XMP 和手动调电压, 无效

然后怀疑电源, AIDA64+furmark2 双烤也没啥问题, 单测各跑分完全正常

能顶得住双烤那说明主板硬件也没毛病, 那就得怀疑是设置或者兼容问题了

重刷了 bios, 恢复默认设置, 无效

最后把主机全拆了, 检查所有供电线和配件没问题, 拔出来用小刷子扫扫灰, CPU 上了新硅脂, 重新理线和排机箱尾部风扇安上

就好了, 问题居然解决了 (怀疑不知道是哪个线虚接了或者接口有灰尘)

系统-system

install-debian

debian 安装时无法连接 WiFi, 显示 秘钥减缓与协商失败, 试试刷新 WiFi 列表时, 拉到最下面, 手动输入 WiFi 名称/密码

用户

# 添加用户
sudo adduser weidows

# 添加权限
usermod -aG docker weidows
# 或者
/usr/sbin/usermod -aG sudo weidows
/usr/sbin/usermod -aG docker weidows
sudo systemctl restart docker
# 重新连接 ssh 生效

# 修改用户组/权限
chown -R weidows:weidows ./data
chmod 755 ./data

# 移除用户
sudo pkill -u username
sudo userdel username

# 删除用户目录
sudo userdel -r username

sudo-免密码

sudo visudo
# 在末尾加上
userxxx ALL=(ALL) NOPASSWD: ALL

ssh

# 秘钥生成
ssh-keygen -t ed25519 -C "your_email@example.com"

关闭自动锁屏

隐私 -> 屏幕 -> 自动锁屏

重启桌面系统

linux 在插拔显示器后, 桌面系统还是很容易崩的, 虽然等一段时间它自己会恢复吧…

sudo systemctl restart gdm3

hostname

sudo hostnamectl set-hostname ds-xxx

PVE

虚拟机系统盘扩容

先去 pve 扩容虚拟盘: 对应虚拟机 -> Hardware -> Hard Disk -> Disk Action -> Resize

并不需要重启

lsblk 可以看到有未使用空间 (300-150=150, sda 有 150G 未使用空间)

root@1Panel:~# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   300G  0 disk
|-sda1   8:1    0   512M  0 part /boot/efi
`-sda2   8:2    0 149.5G  0 part /
sdb      8:16   0    10T  0 disk
sr0     11:0    1   670M  0 rom

# 安全扩容分区
sudo apt update
sudo apt install cloud-guest-utils -y

# 分到 sda2
sudo growpart /dev/sda 2
sudo resize2fs /dev/sda2

df -h

重连生效

PVE 检修

PVE 宿主机有一些比较反直觉的坑，记录一下。

• 关机和自检时间非常长：PVE 关机时会等待所有 VM 和 LXC 优雅停止，如果某个容器卡住了，整个过程会拖很久。耐心等，或者强制关机。
• 开机时建议插键盘：部分主板在走自检（POST）时如果没有检测到键盘输入设备，可能会卡在 D7 状态不动。远程管理前先确认机器能正常过自检。

LVM 卷修复

PVE 存储基于 LVM，异常关机后可能出现卷未激活的情况，导致虚拟机无法启动或存储不可见。

# 查看所有卷（包括未激活的）
lvs -a
lvscan

# 激活所有检测到的卷
vgchange -ay

# 查看卷组和逻辑卷状态
vgs
lvs

# 如果精简池隐藏了，手动激活元数据卷
lvchange -ay pve/data

虚拟机网络优化

在 PVE + TrueNAS + 算力节点的架构里，虚拟机存储网络的优化是很容易被忽略的点。模型文件动辄几十 GB，拉取速度直接决定训练能不能按时启动。

网卡模型必须选 VirtIO：

模型	原理	适用场景
VirtIO	半虚拟化，直接在内核间交换数据包	万兆及以上必选
Intel E1000	模拟真实物理网卡	仅用于无驱动时的兜底

Multiqueue 打破单核瓶颈：

VirtIO 默认只走单个 vCPU 核心处理网络中断。大流量时该核心迅速被打满（%si 飙高），带宽直接卡死。

Multiqueue 把网络流量分摊到多个 vCPU 核心并行处理。在 PVE 里设置：对应虚拟机 -> Hardware -> Network Device -> Multiqueues，数值填 vCPU 核心数（如 4 或 8）。

配合 NFS nconnect：

Multiqueue 解决了"车道"问题，但 NFS 如果只开一个 TCP 连接，流量还是会挤在一个核心上。挂载时加上：

mount -t nfs -o nconnect=8 10.0.14.1:/mnt/data /mnt/data

Multiqueue 提供多车道，nconnect 提供多辆车，两者结合才能榨干万兆网卡。

避坑：修改 Multiqueue 后必须彻底关机再启动（冷启动）才能生效，热重启不生效。

验证方法：虚拟机里执行 top 按 1，传输大文件时观察各核心 si 是否均匀分布。

网络-net

查看网卡型号

lspci | grep -i net

配置静态-IP

iface enp6s18 inet static
    address 10.0.10.1
    netmask 255.255.0.0
    gateway 10.0.0.1
    dns-nameservers 10.0.0.1 8.8.8.8

速度不达标

1. 重新拔插网线
2. 检查水晶头是否接好 (其中接错线或者虚接, 能联网但网速会降级)

光口与电口

SFP+ / RJ45

光口需要接光模块, 光模块对不用品牌和速率有很多适配问题, 光模块物理接口分为单纤/双纤/光转电不同类型

同一机房内 (距离 10m 以内推荐用电口), 购置方便, 稍便宜一点 (电口交换机稍贵, 总体便宜)

远距离传输推荐使用光口, 只是需要成套配光网卡 + 光模块 + 光交换机 + 光纤, 麻烦也有兼容问题

---

硬件网络管理协议

BMC (Baseboard Management Controller)
底板管理控制器。它是一颗嵌入在主板上的独立微控制器（相当于服务器里的“小电脑”）。

• 功能：无论服务器是否开机，只要电源插头插着，BMC 就会运行。它监控传感器（温度、电压、风扇转速），并允许管理员远程开关机、安装操作系统。
• 常见实现：华为的 iBMC、戴尔的 iDRAC、惠普的 iLO。

PXE (Preboot Execution Environment)
预启动执行环境。一种让计算机通过网络接口而非本地硬盘启动的技术。

• 功能：在没有安装系统的裸机上，通过网卡从远程服务器下载启动镜像。
• 场景：机房大规模自动部署操作系统。

ethtool 网卡协商

查看和强制设置网卡速率和协商模式：

# 查看网卡状态
ethtool nic1

# 查看支持的速率和模式
ethtool nic1 | grep -i speed

# 强制 10G 全双工（失败会在 20 秒后自动恢复，防止失联）
echo "正在尝试强制 10G..." && ethtool -s nic1 speed 10000 duplex full autoneg off && sleep 20 && ethtool -s nic1 autoneg on && echo "已恢复默认配置"

如果网卡协商异常（比如万兆网卡降到千兆），先检查物理层（网线、模块、接口），再尝试强制握手。

---

iperf3 带宽测试

ethtool 看的是物理层协商速率, iperf3 测的是实际可用带宽 — 配合用能区分到底是"网卡协商没到位"还是"协商 OK 但跑不满".

sudo apt install iperf3 -y

服务端 (被测目标机) 起监听:

iperf3 -s -p 5202

客户端 (打流端) 打过去:

# -P 8: 8 条并发流, 跑满多队列网卡; 单流跑不满经常是 CPU 单核或 NIC 队列瓶颈
iperf3 -c 10.0.13.1 -p 5202 -P 8

• 万兆口实测能跑到 9.4 Gbps 上下属正常 (TCP/以太网头部开销).
• 跑不到一半时排查: CPU 单核打满 (mpstat 1 看 %si 软中断) / NIC offload 没开 / 中间交换机限速 / MTU 不一致.

跨机房或经过 SDN 网关测时, 同一对节点用 -R 反向跑一次, 上下行不对称往往说明 QoS / 限速策略在一侧.

存储-storage

查看硬盘和分区

df -h
sudo fdisk -l
sudo nano /etc/fstab

网络存储协议

协议/技术	数据类型	传输速度/延迟	兼容性/适配	配置难度	权限隔离	多机并发写(共享)	缓存策略	典型应用场景
SMB/CIFS	文件级 (File)	中/高 (依赖TCP，开销大)	极佳 (Win原生，Mac/Linux完美)	低 (UI配置极简)	强 (AD域/ACL)	支持	客户端缓存(Oplocks)	办公协同、日常网盘共享
NFS (v3/v4)	文件级 (File)	高 (小文件和元数据优异)	极佳 (Linux原生，Win需组件)	低 (需配置UID映射)	中/强 (v4支持ACL)	支持	客户端缓存/异步写	Linux服务器共享、容器挂载
iSCSI	块级 (Block)	高 (受限于TCP/IP，延迟中等)	极佳 (各大OS均有启动器)	中 (Target/LUN/Initiator)	强 (CHAP/LUN Masking)	不支持 (需集群文件系统)	依赖OS与阵列缓存	虚拟化集群(PVE)、传统SAN
NVMe-oF	块级 (Block)	极高/超低延迟 (逼近本地)	中等 (需较新内核与网卡支持)	高 (Fabric/网络拓扑)	强 (命名空间/NQN)	不支持 (同iSCSI)	绕过软件栈直通内存	AI计算集群、高性能数据库
Ceph	统一 (块/文件/对象)	极高 (横向扩展，单点看网络)	好 (Linux/K8s/OpenStack)	极高 (集群部署与调优)	强 (CRUSH/CephX)	部分支持 (RBD不支持)	OSD日志/缓存层	私有云底座、K8s持久卷
S3 (MinIO)	对象级 (Object)	中/高 (基于HTTP，延迟高)	极佳 (Web/API/全平台)	低 (部署简单，API调用)	强 (IAM/Bucket Policy)	支持 (最终一致性)	依赖网关/CDN代理	海量非结构化数据、云备份
—	—	—	—	—	—	—	—	—
ZFS (本地文件系统)	本地数据块/数据集	极高 (本地总线速度 PCIe/SAS)	好 (FreeBSD原生，Linux良好)	中 (需理解zpool/dataset/vdev)	强 (本地POSIX/NFSv4 ACL)	不适用 (仅限单机内核管理)	ARC / L2ARC (极其依赖内存)	TrueNAS等底层存储池、防数据损坏
Btrfs (本地文件系统)	本地数据块/子卷	极高 (本地总线速度)	中 (Linux原生，其他OS支持弱)	中 (需理解Subvolume)	强 (本地POSIX ACL)	不适用 (仅限单机内核管理)	内存缓存 / COW机制	群晖NAS底层、单机快照管理
RDMA (网络传输技术)	网络数据帧 (绕过内核)	极速带宽 / 纳秒级延迟	弱 (需专用网卡如RoCE/IB)	高 (需调优PFC/ECN流控等)	中 (基于VLAN/网络层路由)	不适用 (仅负责搬运数据)	零拷贝 (Zero-copy)	加速大模型微调、海量DICOM传输

ISCSI

sudo apt install open-iscsi -y
sudo systemctl enable open-iscsi
sudo systemctl start open-iscsi

# 查看可连接目标
sudo iscsiadm -m discovery -t sendtargets -p 10.0.14.1
# 登录
sudo iscsiadm -m node -T truenas:pve -p 10.0.14.1 --login
# 自动挂载
sudo iscsiadm -m node -T truenas:pve -p 10.0.14.1 --op update -n node.startup -v automatic

# 查看连接
iscsiadm -m session
# 退出登录
sudo iscsiadm -m node -T truenas:pve -p 10.0.14.1 --logout

# 查看块设备
lsblk
# 查看分区UUID
sudo blkid

# 开机自动挂载, 编辑 /etc/fstab
sudo nano /etc/fstab
# /dev/disk/by-uuid/8c28b3a9-fcbc-4ea3-895f-57aca986b243 /mnt/dataset auto nosuid,nodev,nofail,x-gvfs-show 0 0

# 不重启刷新挂载
sudo mkdir -p /mnt/dataset
sudo systemctl daemon-reload && sudo mount -a

NFS

大文件读写速度一般可以跑慢, 小文件会很慢

场景	直连 HDD	NFS + HDD	NFS + TrueNAS 缓存
大文件顺序读写	~150MB/s	~100-120MB/s	~100-120MB/s（无明显差别）
小文件随机读	~100 IOPS	~10-30 IOPS	几百到几千 IOPS（取决于 ARC/L2ARC 大小）
小文件同步写	~100 IOPS	~5-20 IOPS	几百 IOPS 甚至上千（取决于 SLOG SSD）

sudo apt install nfs-common -y
sudo nano /etc/fstab
# 10.0.14.1:/mnt/data/data /mnt/data nfs defaults 0 0

# 检测更改并应用挂载
sudo mount -a
# 卸载某个目录挂载
sudo umount /mnt/data

传输优化

遇到海量小文件时很头疼, 传输速度非常慢

mount -t nfs -o vers=3,tcp,rsize=1048576,wsize=1048576,noatime,nodiratime  server:/export /mnt/nfs

• rsize/wsize=1048576：增大读写块，提高吞吐。
• tcp：用 TCP 而不是 UDP。
• noatime,nodiratime：减少时间戳更新。
• nconnect=8：建立多个 TCP 连接，配合 VirtIO Multiqueue 压榨万兆带宽。

生产环境 fstab 配方 (NFSv4.1)

跑了一阵子稳下来后, 把基本 defaults 换成完整调优参数:

10.0.2.1:/mnt/data/data  /mnt/data  nfs  _netdev,vers=4.1,proto=tcp,hard,noatime,nodiratime,async,rsize=1048576,wsize=1048576,nconnect=8,timeo=600,retrans=5  0  0

参数	作用
_netdev	等网络起来再挂载, 避免开机时 systemd 挂死在 mount 阶段
vers=4.1	走 NFSv4.1, 比 v3 多 multi-session 和更好的元数据语义, 支持 nconnect
proto=tcp	强制 TCP, 避免某些客户端默认 UDP 在大块传输时丢包
hard	服务端短暂不可用时无限重试 (相对的 soft 会直接报 I/O 错误, 数据会丢)
async	异步写, 牺牲一点崩溃可靠性换吞吐
nconnect=8	8 条 TCP 并行传输, 万兆网卡必备
timeo=600	RPC 单次超时 60 秒 (单位 0.1 秒)
retrans=5	超时后重试 5 次再判定为软失败

改完 fstab 后刷新挂载并验证实际生效的参数:

# 已挂载的需要先卸 (-f 强制, 解决 stale handle / busy 问题)
sudo umount -f /mnt/data
sudo mount -a

# 看真实生效的挂载选项 (内核可能对部分选项做了校正/降级, 这里看到的才是事实)
findmnt /mnt/data

findmnt 比 cat /proc/mounts 干净, 能直观看到 vers、nconnect、rsize 实际谈成的值. 如果 nconnect 没生效, 多半是内核版本 < 5.3 或 NFS 服务端不支持 v4.1.

root-权限

使连接的服务器 root 权限可用 (默认下 root 无法起效)

sudo nano /etc/exports

# 加上 no_root_squash
# /mnt/data  10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)

sudo exportfs -r

rsync

sudo apt install rsync -y
sudo rsync -avzP --no-owner --no-group --info=progress2 data/ /mnt/data/

• -a

  归档模式，等价于 -rlptgoD，意思是：

  -r 递归进入子目录

  -l 保留符号链接

  -p 保留权限

  -t 保留时间戳

  -g 保留组信息

  -o 保留属主

  -D 保留设备文件和特殊文件

• -v

  verbose，显示详细输出。

• -P

  等价于 --partial --progress：

  –partial 保留部分传输的文件，以便断点续传

  –progress 显示传输进度

  适合大文件传输，尤其是可能中断时。

• -z

  压缩传输，在网络上传输前压缩文件内容，节省带宽。适合网络慢的场景，但 CPU 会增加负担。

---

rclone

如果需要复制的文件比较多, rsync 单进程会非常慢, rclone 会强很多

sudo apt install rclone -y

rclone copy /home/xxx/.cache/huggingface \
    /mnt/data/data/byuser/xxx/.cache \
    --progress \
    --transfers=16 \
    --checkers=32 \
    --fast-list \
    --copy-links \
    --ignore-existing \
    --bwlimit=100M

• rclone copy

  把源目录复制到目标目录。只会新增/覆盖目标文件，不会删除目标中多余的文件（与 sync 不同）。

• –progress

  显示实时进度条，包括文件数、传输速度、已完成大小等。

• –transfers=16

  设置同时传输文件的并发数，默认是 4。

  这里设置为 16，意味着最多同时传输 16 个文件，可以加快整体速度。

• –checkers=32

  设置用于检查/扫描源和目标目录的并发数（比如比较文件是否存在、文件大小/校验和等），默认是 8。

  提高这个数值可以更快列出和比对大目录下的文件。

• –fast-list

  使用更高效的方式一次性获取源/目标目录的完整文件列表（减少 API 调用次数或目录遍历开销）。

  缺点：需要一次性加载全部文件列表到内存，如果文件数特别多，会占用较大内存。

• –copy-links

  如果源目录中有符号链接（symlinks），会复制符号链接指向的实际文件内容，而不是复制符号链接本身。

• –ignore-existing

  已存在于目标目录的文件将会被跳过，不会覆盖。

  只复制目标中没有的文件 → 适合增量拷贝。

rclone-s3-migrate

nano /root/.config/rclone/rclone.conf

[old-s3]
type = s3
provider = Other
env_auth = false
access_key_id = admin
secret_access_key = admin123
endpoint = http://10.0.13.1:17030
region = us-east-1
no_check_certificate = true
force_path_style = true

[new-s3]
type = s3
provider = Other
env_auth = false
access_key_id = xxx
secret_access_key = xxx
endpoint = https://fs.infra.dolphin-ai.cn
region = us-east-1
no_check_certificate = true
force_path_style = true

rclone copy old-s3:harbor new-s3:harbor \
  --progress \
  --transfers=32 \
  --checkers=16 \
  --s3-chunk-size=64M \
  --s3-upload-concurrency=4 \
  --size-only \
  --log-file=rclone-harbor-migrate.log \
  --log-level=INFO

tar-压缩解压

sudo tar -zcvf data.tar.gz data/
sudo tar -zxvf data.tar.gz -C /path/to/target/directory/

truenas-zvol-mount

sudo mkdir /mnt/zvolmnt

sudo mount -t ext4 /dev/zvol/data/dataset /mnt/zvolmnt

/dev/zvol/ 后面跟的是 zvol 路径, 前面需要指定其内部硬盘格式 (如 ext4)

ZFS 池维护

消费级 SSD 长时间随机写之后, 内部 GC 越来越重, 写入延迟一路飙. 必须开 autotrim 让 ZFS 主动下发 TRIM 让出空块, 同时定期 scrub 校验数据完整性.

# 看当前 autotrim 状态 (off / on)
zpool get autotrim

# 开启 autotrim (按 vdev 异步下发, 不阻塞业务 I/O)
zpool set autotrim=on sata-ssd-2t_mirror

# 全盘 scrub: 校验所有数据块的校验和, 静默坏块会被发现并自动从镜像/奇偶校验修复
zpool scrub sata-ssd-2t_mirror

# 看池状态 — scrub 进度 / resilver 状态 / 错误计数全在这
zpool status

scrub 走的是空闲 I/O, 不阻塞业务, 但 TB 级机械盘可能跑半天. 建议每月一次, cron 里加: 0 3 1 * * /sbin/zpool scrub <pool>.
autotrim 是 OpenZFS 2.x 引入的, 旧版需要手动 zpool trim <pool> 定期跑.
看到 zpool status 里有 errors: 非 0 立刻备份换盘, 不要等 DEGRADED.

硬盘空间

# 查看目录大小
sudo du -sh .
# 查看目录内文件数
sudo find . -type f | wc -l

# 占用分析
sudo apt install ncdu
ncdu /path/to/directory

硬盘健康检查

长期运行的服务器关机前一定要检查硬盘状态。因为关机前硬盘即使出现严重错误，数据还在 RAM 缓存中，系统不会立刻崩；一旦重启，缓存丢失，问题就暴露出来了。

# 查看 NVMe 硬盘 SMART 信息
smartctl -a /dev/nvme0n1

不要只看 PASSED。重点关注 Media and Data Integrity Errors：

指标	含义	操作建议
PASSED	整体健康评估通过	仅表示未达到临界阈值，不代表没问题
Media and Data Integrity Errors	介质和数据完整性错误数	非 0 即告警，数值越高损坏越严重，立刻备份换盘
Percentage Used	已用寿命百分比	接近 100% 时准备更换
Unsafe Shutdowns	异常断电次数	过多可能加剧损坏

下面这个盘虽然显示 PASSED，但 Media and Data Integrity Errors 已经 40 多万，属于严重质量问题，必须立刻全盘导出数据并换硬件。

典型异常示例：

SMART overall-health self-assessment test result: PASSED
Media and Data Integrity Errors:    419,790

显卡-nvidia

型号分类-diff

型号	架构	显存类型	显存容量	带宽（约）	Transformer Engine	用途定位	是否限速 / 特供	备注
H200	Hopper	HBM3e	141 GB	~4.8 TB/s	✅	超大模型训练 / 推理	否	Hopper 最强训练卡
H100	Hopper	HBM3	80 GB	~3.35 TB/s	✅	高端训练 / HPC	否	主流大模型训练卡
H800	Hopper	HBM3	80 GB	~1.6 TB/s 限速	✅	中国市场训练 / 推理	✅	限制互联带宽
H20	Hopper	HBM3	96 GB	更低（大幅限速）	✅	轻量推理	✅	核心/带宽精简，入门型
A100 80GB	Ampere	HBM2e	80 GB	~2.0 TB/s	❌	高端训练 / HPC	否	老牌训练卡
A800 80GB	Ampere	HBM2e	80 GB	~1.0 TB/s 限速	❌	中国市场训练卡	✅	限速版
L40S	Lovelace	GDDR6	48 GB	~864 GB/s	✅	推理 / 渲染 / 中型训练	否	性价比高，支持 Transformer Engine
L40	Lovelace	GDDR6	48 GB	~864 GB/s	❌	渲染 / 图形 / 基础推理	否	无 TE，偏图形工作站
L20	Lovelace	GDDR6	24 GB	~400 GB/s	❌	入门推理卡	❓	功耗低、低成本部署
RTX 6000 Ada	Lovelace	GDDR6	48 GB	~960 GB/s	✅	高端工作站 / 推理	否	桌面工作站卡，带显示输出
RTX A6000	Ampere	GDDR6	48 GB	~768 GB/s	❌	渲染 / 工作站 / 中型推理	否	无 TE，适合图形与轻量训练
RTX A5000	Ampere	GDDR6	24 GB	~576 GB/s	❌	渲染 / 推理 / 开发	否	中端工作站卡
RTX 4090	Ada	GDDR6X	24 GB	~1.0 TB/s	✅	AI 训练 / 消费级极限性价比	否	桌面旗舰，性价比极高
RTX 3090	Ampere	GDDR6	12 GB	~600 GB/s	❌	AI 训练 / 消费级极限性价比	否	轻量级工作站卡

驱动-driver

驱动版本选择

版本类型	特点	优点	缺点	适用场景
开源版 (nvidia-driver-550-open)	内核模块开源（GPL/MIT），用户态库依旧闭源；自 515 起支持	内核升级兼容性好；数据中心 GPU 支持更佳；安全审计和长期维护方便	桌面卡功能缺失（功耗管理、视频编解码、Ray Tracing 等）；消费级显卡不推荐	数据中心 GPU（A100/H100/A40 等），服务器环境
闭源版 (nvidia-driver-550)	传统专有驱动；功能完整	功能最全，性能最优；完全兼容 CUDA/OptiX/TensorRT	内核更新后可能需要等 DKMS 更新或手动补丁	桌面显卡、游戏、CUDA 开发、AI 训练
Server 版 (nvidia-driver-550-server)	面向数据中心/工作站/云计算；长期支持（LTSB）；稳定优先	更新节奏慢但稳定性高；专注计算型 GPU	功能更新不及时；版本号常低于桌面版	科研、生产环境，对稳定性要求高

卸载降级重装驱动

dpkg -l | grep nvidia-driver
sudo apt remove --purge nvidia-driver-550
sudo apt autoremove
sudo apt install nvidia-driver-535-server

ubuntu-drivers

一键自动安装推荐的驱动版本：

# 查看系统推荐的驱动
ubuntu-drivers devices

# 自动安装推荐版本
sudo ubuntu-drivers autoinstall

显卡压测

sudo snap install gpu-burn
gpu-burn 600

显卡掉卡

https://blog.csdn.net/qq_44850917/article/details/135431204

症状与文中描述一模一样

找出故障显卡

weidows@ds-8x3090:~$ lspci | grep 3090
01:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
21:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
22:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev ff)
41:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
42:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
61:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
a1:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)
a2:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)

weidows@ds-8x3090:~$ sudo dmesg -l err
[57393.518301] nvidia-modeset: ERROR: GPU:5: Failed detecting connected display devices
[57393.659658] nvidia-modeset: ERROR: GPU:5: Failed detecting connected display devices
[57393.659752] nvidia-modeset: ERROR: GPU:5: Failed detecting connected display devices
[57400.600835] nvidia-modeset: ERROR: GPU:5: Error while waiting for GPU progress: 0x0000c67d:0 2:0:4048:4040
[57405.600800] nvidia-modeset: ERROR: GPU:5: Error while waiting for GPU progress: 0x0000c67d:0 2:0:4048:4040
[57410.600741] nvidia-modeset: ERROR: GPU:5: Error while waiting for GPU progress: 0x0000c67d:0 2:0:4048:4040
[57415.600674] nvidia-modeset: ERROR: GPU:5: Error while waiting for GPU progress: 0x0000c67d:0 2:0:4048:4040

Xid 79 诊断

如果日志中出现 Xid 79: GPU has fallen off the bus，说明显卡从 PCIe 总线上"掉线"了。以下是系统化的诊断流程。

日志抓取

# 查看当前内核日志
dmesg | grep -iE "NVRM|nvidia|XID"

# 或查看上一次开机的日志（需 journald 持久化）
journalctl -b -1 -k | grep -iE "NVRM|XID"

典型报错：

NVRM: Xid (PCI:0000:22:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:22:00): 154, GPU recovery action changed from 0x0 to 0x1

原因排查（按可能性排序）

原因	可能性	说明
PCIe Riser/转接板故障	80%	8 卡集群常用转接板，电容老化或金手指氧化导致信号丢包
供电线/接口松动	15%	3090 瞬时电流极高，8-pin 接头松动或分线器质量差导致掉压重置
显卡硬件损坏	5%	电源管理芯片（PWM）损坏，待机功耗异常（如 35W），内部逻辑崩溃

处理步骤

第一步：物理插拔与清洁

1. 彻底关机并断电
2. 拔下故障卡的所有电源线，检查 8-pin 接口有无发黄或烧焦痕迹
3. 拔下显卡或转接板，用酒精或橡皮擦擦拭金手指
4. 重新插紧，确保听到"咔哒"声

第二步：交叉火力测试
将故障卡与正常卡的 PCIe 转接板 和 电源线 互换：

• 如果下次掉的是另一张卡 → 线或转接板坏了，换线即可
• 如果下次掉的还是同一张卡 → 显卡本身硬件有问题

第三步：BIOS 降级 PCIe
进 BIOS 找到故障卡所在插槽，将 Link Speed 从 Auto/Gen4 强制改为 Gen3，牺牲极小带宽换取更高的信号鲁棒性。

报修建议：把 dmesg 中 Xid 79 的日志片段直接贴给供应商，要求更换转接线或显卡。

暂时禁用故障显卡

sudo nvidia-smi drain -p 0000:22:00.0 -m 1

查看和限制功率

https://zhuanlan.zhihu.com/p/1929467664155276914

对于大规模 GPU 集群（特别是包含 RTX 3090/4090 这种消费级卡的混搭集群），默认驱动设置是为单卡桌面环境设计的。在多卡并行或 7x24 小时运行的 AI 任务中，需要进行深度调校。

持久化模式 (Persistence Mode)

默认情况下，没有任务运行时 NVIDIA 驱动会卸载，新任务启动时重新加载，导致数秒延迟和电压跳变。3090 对电压波动极度敏感，频繁加载/卸载会增加掉卡概率。

# 开启持久化模式（驱动常驻显存，保持稳定）
sudo nvidia-smi -pm 1

建议写入系统启动脚本（如 crontab 或 rc.local），确保每次开机自动开启。

功耗限制 (Power Limit)

3090 默认功耗 350W，瞬时峰值可能冲到 450W+，导致电源保护掉卡。

# 查看当前功耗限制
nvidia-smi -q | grep 'Power Limit'

# 将所有卡限制在 300W（性能损失 2-5%，发热显著降低）
sudo nvidia-smi -pl 300

锁定核心频率 (Lock GPU Clock)

AI 推理负载不平稳时，GPU 频繁变频会导致延迟抖动和 XID 错误。

# 锁定在 1200MHz 到 1500MHz 之间
sudo nvidia-smi -lgc 1200,1500

显存散热与风扇策略

3090 背板显存极易过热（Junction Temp）。不要依赖驱动的自动风扇曲线（通常很保守），建议将风扇转速固定在 70% - 80%。

PCIe 链路降级

8 卡环境中 PCIe 信号干扰严重。如果某张卡频繁掉线，在 BIOS 中将其插槽改为 Gen3，牺牲极小带宽换取极高的信号鲁棒性。

故障排查

# 收集 bug 报告
sudo nvidia-bug-report.sh

# 跟踪显卡温度日志
nohup nvidia-smi -q -l 2 -d TEMPERATURE -f nvidiatemp.log > /dev/null 2>&1 &
tail -f nvidiatemp.log

|   2  NVIDIA GeForce RTX 3090        Off | 00000000:22:00.0 Off |                  N/A |
| 30%   30C    P8              36W / 350W |     10MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |

待机功耗 35W 说明显卡即便不跑任务也在"发烧"，优先排查散热和供电。把侧板拿掉后如果不再掉卡，可以 99% 确认是温度问题。

集群管理核查表

参数/操作	推荐设置	目的
Persistence Mode	ON (-pm 1)	保持驱动常驻，稳定电压
Power Limit	300W (针对 3090)	防止瞬时功耗过高导致掉电
PCIe Speed	Gen3 (若不稳定)	减少电磁干扰导致的掉线
ECC Mode	OFF (针对 3090)	3090 是软 ECC，开启会损耗 10% 性能
Compute Mode	Default	允许多个进程（如 vLLM）共享 GPU

查看-PCIE

# 查看PCIE设备
lspci | grep -i nvidia

# 查看 PCIe 链接速率和宽度
sudo lspci -s 01:00.0 -vv | grep -i 'LnkSta'

# 查看支持的最大带宽
sudo lspci -s 01:00.0 -vv | grep -i 'LnkCap'

• 2.5GT/s → PCIe 1.0
• 5.0GT/s → PCIe 2.0
• 8.0GT/s → PCIe 3.0
• 16.0GT/s → PCIe 4.0
• 32.0GT/s → PCIe 5.0

有时会看到显卡降级到了 PCIE1, 有可能是因为物理层面线路问题 (一般这样会直接死机了), 更可能的是省电策略导致的

Device 0 [NVIDIA RTX A6000] PCIe GEN 3@16x RX: 771.8 MiB/s TX: 4.150 MiB/s
GPU 1905MHz MEM 7600MHz TEMP  54°C FAN  79% POW 134 / 300 W
GPU[|||||||||||||||||||||||||||| 86%] MEM[||||||||||||  18.252Gi/47.988Gi]

Device 1 [NVIDIA RTX A6000] PCIe GEN 3@16x RX: 34.67 MiB/s TX: 815.5 MiB/s
GPU 1740MHz MEM 7600MHz TEMP  76°C FAN  78% POW 187 / 300 W
GPU[||||||||||||||||||||||||||||100%] MEM[||||||||||||||25.149Gi/47.988Gi]

Device 2 [NVIDIA RTX A6000] PCIe GEN 1@16x RX: 2.393 MiB/s TX: 50.00 KiB/s
GPU 0MHz    MEM 405MHz  TEMP  37°C FAN  78% POW  16 / 300 W
GPU[                              0%] MEM[               0.474Gi/47.988Gi]

Device 3 [NVIDIA RTX A6000] PCIe GEN 1@16x RX: 50.00 KiB/s TX: 50.00 KiB/s
GPU 0MHz    MEM 405MHz  TEMP  33°C FAN  78% POW  24 / 300 W
GPU[                              0%] MEM[|||||          7.291Gi/47.988Gi]

terminal

tmux

Tmux 使用教程 - 阮一峰的网络日志

可以保持程序运行(即使断了 ssh), 也可以多人共享终端

# 创建一个新的会话，命名为 monitor
tmux new -s monitor

# 横向拆分
tmux split-window -h
# 纵向
tmux split-window

# 切换 pane (ctrl+b o)

# list sessions
tmux ls
# 连接 session
tmux attach -t monitor
# 断开 (ctrl+b d)
tmux detach

btop

locale

root@ds-8x3090:~# btop
ERROR: No UTF-8 locale detected!
Use --utf-force argument to force start if you're sure your terminal can handle it.



# 1. 看看系统支持哪些 locale
locale -a

# 2. 如果你看不到 UTF-8 生成一个最通用的
locale-gen en_US.UTF-8

# 3. 设置系统默认
update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8

但问题一般不会出现在上面几条, 直接去查这里

nano /etc/ssh/sshd_config

改为 UsePAM yes

systemctl restart ssh

其他

pwm-风扇调控

https://docs.coolercontrol.org/installation/debian.html

英伟达的显卡温度控制比较极限, 默认 target temperature 到 80 度时风扇还在悠哉, 大概到 85 度就会开始大幅下压功率, 少见会到 90 度

然而即使到 90 度, 风扇也就 90%尔尔, 压功率 > 提转速为原则避免硬件损坏, 坏得很

用软件调控显卡风扇, 调高转速, 装好 coolercontrol

1. 新建传感器, 勾上所有显卡 (选项选最高值)
2. 新建配置, 温度源选上面的传感器
3. 把所有显卡的 fan 切换 profile 为上面的配置

实测虽然还是会破 80, 但基本不怎么会撞墙了, 降个 5 度左右

借物表

[1]: ChatGPT

[2]: PVE + TrueNAS + 算力节点架构实践踩坑记录