VV
HomeWeeklyFriendsAboutMusic追番

gpu服务器IDC运维

Published 2026-07-14 19:34 4678 words 24 min read ... Page views

Vullfin avatar

Vullfin

欢迎来到Vullfin的个人博客

80 Articles

25 Categories

105 Tags
Home Weekly
Categories Tags Archives
Friends About Music 追番
润建服务台面试经验gpu服务器IDC运维美团网工面试经验
This post is not yet available in English. Showing the original.
gpu服务器IDC运维面试经验

了解 Zabbix 监控”，那用 Zabbix 监控 GPU 服务器的显存使用率，需要怎么做？具体步骤说清楚

“用 Zabbix 监控 GPU 显存使用率的步骤：

  1. 被监控机安装 Zabbix Agent，并确保nvidia-smi命令可执行；
  2. 在 Agent 端编写脚本（如gpu_memory.sh），通过nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits提取显存使用值；
  3. 在 zabbix_agentd.conf 中添加UserParameter=gpu.memory.used,/path/to/gpu_memory.sh；
  4. 重启 Zabbix Agent 使配置生效；
  5. Zabbix Server 端创建监控项（键值为 gpu.memory.used，类型为 Zabbix 客户端）；
  6. 设置触发器（如当使用率 > 90% 时告警）；7. 创建图形关联该监控项，实现可视化展示。”

“参与过 IDC 机房设备上架”，那你说一下服务器上架前需要做哪些检查？上架时的操作规范是什么？

“服务器上架前检查：

    1. 外观检查（机身无磕碰、接口无损坏、螺丝无松动）；
    1. 资产核对（SN 号、配置参数与工单一致）；
    1. 功能预检测（BMC 管理口 ping 通、硬盘 / 内存通过预启动检测工具验证、电源模块测试）；
    1. 机柜适配性检查（服务器尺寸与机柜 U 位匹配、PDU 功率满足设备功耗需求、导轨型号兼容）。

上架操作规范

    1. 双人协作（一人托举服务器保持水平，一人引导入导轨，禁止单手拎拽）；
    1. 固定规范（用指定规格螺丝对角锁紧服务器与导轨，扭矩符合要求）；
    1. 布线要求（强弱电分离走槽，线缆标签朝向一致，不遮挡服务器散热孔，冗余线缆捆扎整齐）；
    1. 电源规范（双电源分别接入不同 PDU 回路，确保冗余）；
    1. 上架后验证（上电检查指示灯状态，通过 BMC 确认硬件识别正常，登记资产到 CMDB 系统）。

用 Ansible 批量升级 NVIDIA 驱动的 playbook，核心模块和任务是什么？至少 3 个关键任务

核心模块

  • apt / dnf（包管理）
  • systemd（服务管理）
  • command / shell（执行驱动校验）

关键任务（3 个）

  1. 停止图形 / 显卡相关服务，卸载旧驱动
  2. 安装指定版本 NVIDIA 驱动及 DKMS 依赖
  3. 加载 nvidia 内核模块，验证 nvidia-smi 正常

标准答案：“Ansible playbook 批量升级 NVIDIA 驱动的核心模块包括 yum/apt（依赖安装）、 copy（传输驱动包）、 command（执行驱动安装命令）、 systemd（管理服务）。

关键任务：

  1. 禁用 nouveau 驱动（用lineinfile模块修改黑名单配置，command模块执行dracut -f更新 initramfs）；
  2. 卸载旧驱动（command模块执行nvidia-uninstall --silent）；
    1. 安装依赖（yum模块安装gcc、kernel-devel、dkms）；
    1. 安装新驱动（command模块执行sh NVIDIA-Linux-x86_64-xxx.xx.run --silent）；
    1. 验证驱动（command模块执行nvidia-smi，检查输出的驱动版本是否正确）。”

岗位要求里提到需要 “处理简单的突发故障”，如果 IDC 机房某机柜突然断电，你的第一反应和处理步骤是什么？

第一反应

立即确认是单柜空开跳闸还是上游配电柜 / 市电故障，禁止盲目合闸。

处理步骤

  1. 先检查机柜有无焦糊味、短路、打火，排除硬件故障
  2. 查看 PDU、列头柜空开状态，确认非设备短路后再试合闸
  3. 上电后逐台启动服务器，避免瞬间大电流再次跳闸
  4. 检查业务、BMC、网络连通性，同步上报故障与恢复情况
  5. 收尾：记录断电原因、处理时长、受影响设备和业务，同步书面上报给主管，协助分析跳闸根本原因（如是否因设备过载、线缆老化等）。

你简历里写 “了解常见网络协议（TCP/IP, HTTP, DNS 等）”，那你说一下 TCP 三次握手的具体过程，以及为什么需要三次而不是两次？

一、TCP 三次握手过程

  1. 第一次（SYN）：客户端向服务器发送连接请求，报文标志位SYN=1，并生成一个初始序列号ISN，客户端进入SYN_SENT状态。
  2. 第二次（SYN+ACK）：服务器收到请求后，确认收到（ACK=1，确认号 = ISN+1），同时也发送连接请求（SYN=1），生成自己的ISN，服务器进入SYN_RCVD状态。
  3. 第三次（ACK）：客户端收到服务器的确认与请求，发送确认报文（ACK=1，确认号 = 服务器 ISN+1），客户端进入ESTABLISHED；服务器收到确认后也进入ESTABLISHED，连接建立。

二、为什么需要三次而不是两次？

核心是防止失效的连接请求报文段被服务器接收，导致建立错误连接。

若只用两次：

  • 若客户端的连接请求因网络延迟滞留（未丢失），延迟到达服务器时，服务器会误建立连接，而客户端已废弃该请求，造成资源浪费与连接异常。
  • 三次握手通过双向确认，既能建立双方可靠的发送与接收能力，又能避免这种历史无效请求导致的误连接。

假设你负责维护的某台服务器突然出现 CPU 占用率持续 100% 的情况，且暂时无法重启，你会分步骤怎么做来排查和缓解这个问题？

  • 用 top 定位占用最高的进程与 PID
  • 查看进程详情 ps -fp PID，判断是否为异常 / 恶意进程
  • 查看线程 / IO / 网络情况，确认是计算密集还是死循环
  • 必要时 kill 或 kill -STOP 暂停异常进程缓解 CPU
  • 查看日志 / 应用状态，定位业务逻辑死循环或漏洞
  • 观察负载回落，确认业务影响范围并上报

假设现在需要你排查一台服务器的网络故障：ping 网关不通，但本机网卡灯亮着，网线也插紧了。你会按什么步骤排查？从硬件到软件，说清楚每一步的操作和判断依据

  • 检查网卡状态：ip addr 看网卡是否 UP、IP 是否正确配置
  • 检查路由：ip route 确认默认网关存在且正确
  • 检查 ARP：arp -n 或 ip neigh 看能否解析网关 MAC，不能则二层不通
  • 检查端口配置：确认交换机端口未 shutdown、未错配 VLAN、速率双工不协商异常
  • 检查防火墙：iptables -L / firewall-cmd --list-all 看是否禁 ICMP 或拦截出站，因为 ping 依赖 icmp
  • 测试链路：用其它设备接同网线 / 同端口，判断是服务器问题还是线路 / 交换机问题

你在联通实习的时候，负责过网络设备巡检，那巡检服务器的时候，你怎么判断服务器硬件有没有故障？别废话，直接说步骤

标准答案是：服务器硬件巡检要按 “先远程监控、后本地检查” 的流程来：

  1. 先通过 IPMI/BMC 系统查看硬件监控数据：包括 CPU / 内存 / 硬盘的健康状态、电源模块冗余状态、风扇转速与温度阈值、硬盘 SMART 信息（坏道 / 掉线）；
  2. 查看系统日志（如 dmesg）中是否有硬件报错（比如 PCI 设备异常、硬盘 IO 错误）；
  3. 本地巡检时检查机箱物理状态：电源指示灯是否正常、有无异响 / 异味、散热口温度是否过高、线缆连接是否松动。

你简历里写了 “处理过高中校园网故障”，当时 2 小时内恢复了全网，那你排查网络故障的第一步是做什么？别再扯没用的

标准答案是：整网中断故障排查第一步是 “确认故障影响范围 + 验证网络出口连通性”：

  1. 先通过终端设备（比如随便找个学生电脑）ping 网关、ping 外网 DNS，判断是内网故障还是出口故障；
  2. 再检查机房核心设备的物理状态（电源灯、运行灯是否正常），排除硬件宕机的情况；
  3. 最后才是登录核心交换机查看端口状态、VLAN 配置、链路聚合是否异常。

你简历里写了 “熟悉 Linux Shell 脚本”，那你写过批量检查服务器硬盘状态的 Shell 脚本吗？脚本里核心命令用什么？别告诉我你没写过

标准答案是：批量检查服务器硬盘状态的 Shell 脚本，核心命令分两类：

  1. 查看硬盘物理健康状态：用smartctl -a /dev/sdX（获取 SMART 信息）；
  2. 查看 RAID 阵列状态（如果有）：用对应阵列卡工具，比如 LSI 的megacli64 -LDInfo -Lall -aALL，或者 HPE 的hpssacli controller all show config。

再问你：招聘要求里要做 GPU 服务器部署，你知道安装 NVIDIA 驱动前，需要先禁用 Linux 系统里的哪个默认驱动吗？说全称，别缩写

需要禁用 nouveau 驱动。

步骤是：

  1. 编辑/etc/modprobe.d/blacklist.conf，添加blacklist nouveau和options nouveau modeset=0；
  2. 重建 initramfs 镜像（比如dracut -f或update-initramfs -u）；
  3. 重启系统后，用lsmod | grep nouveau确认驱动已禁用。

再问你：IDC 驻场时服务器上架，你知道机柜里服务器的安装顺序有什么要求吗？别跟我说随便装

标准答案是：服务器上架核心原则是 “安全第一、散热优先”：

  1. 按重量分层：下部放重型设备，上部放轻型设备，且单柜承重不超过机柜额定负载；
  2. 按散热布局：设备间距预留至少 1U 空间，前方对应冷通道、后方对应热通道，避免阻挡气流；
  3. 按线缆规划：先固定机柜 PDU 电源，再安装设备，确保电源线、网线从机柜两侧理线架走，避免缠绕。

再问你：用 Prometheus 监控 GPU 服务器时，需要部署什么 exporter？它采集的核心指标有哪些？别想蒙混过关

  1. 首先，监控的是NVIDIA GPU，用的是 NVIDIA 官方的dcgm-exporter
  2. dcgm-exporter 采集的 GPU 核心指标包括：GPU 利用率、显存使用率、显存带宽、GPU 温度、功耗、ECC 错误计数等

再问你：用 Ansible 批量给 100 台 GPU 服务器安装 NVIDIA 驱动，需要写哪些核心模块？步骤是什么？别再东拉西扯

正确的核心模块和步骤是：

  1. 用yum或apt模块安装依赖（如 gcc、kernel-devel）；
  2. 用copy模块上传 NVIDIA 驱动.run 文件到目标服务器；
  3. 用command或shell模块执行驱动安装命令（需添加--silent等参数实现无交互安装）；
  4. 用modprobe模块加载nvidia内核模块；
  5. 用shell模块执行nvidia-smi命令验证驱动是否安装成功；
  6. 若需重启，用reboot模块

最后问你：IDC 机房里，服务器突然出现频繁掉电，你第一步要排查什么？说不出来就直接走人

标准答案是：

  1. 第一时间冲到 UPS 机柜，查看 上层供电 UPS 是否报警、指示灯状态（市电是否中断、电池是否在放电）；检查上层 UPS 可以瞬间判断是单台还是系统性风险
  2. 检查总 PDU 输入空开是否跳闸，排除供电链路故障；
  3. 若 UPS 正常，再排查单台服务器的 PDU 端口和电源模块；
  4. 全程同步通知业务团队，优先通过备用机切换保业务，而非傻等着查原因。

你简历写 “参与过 Linux 服务器系统安装”，那安装 CentOS 7 时，如何通过 kickstart 文件实现自动化分区？要求根分区 50G，swap 分区 8G，剩余空间给 /data 分区。写关键配置段，别漏参数

# 清除旧分区，初始化磁盘 
clearpart --all --initlabel 
# 分区配置 
part /boot --fstype=xfs --size=1024 
part swap --size=8192 
part / --fstype=xfs --size=51200 
part /data --fstype=xfs --grow

下一个问题，在 GPU 服务器上进行 CUDA 安装，安装完成后如何验证 CUDA 是否成功安装并能正常使用？要说出具体命令和验证要点。别答错，再给你一次机会，这都答不好就真没机会了

# 1. 查看 CUDA 版本
nvcc -V

# 2. 查看 GPU 状态和驱动版本
nvidia-smi

# 3. 运行官方样例测试
cd /usr/local/cuda/samples/1_Utilities/deviceQuery
make
./deviceQuery

# 4. 带宽测试（可选）
cd ../bandwidthTest
make
./bandwidthTest
检查项通过标准
nvcc -V显示 CUDA 版本号，无报错
nvidia-smi显示 GPU 型号、驱动版本、温度、功耗，无 ERR!
deviceQuery最后一行显示 Result = PASS
bandwidthTest显示 Result = PASS，带宽数值符合预期
关键细节
  • nvidia-smi 正常但 nvcc -V 报错 → CUDA Toolkit 未正确安装或环境变量未配（PATH 需包含 /usr/local/cuda/bin）
  • deviceQuery 失败 → 驱动与 CUDA 版本不匹配，或 GPU 未识别
  • 多 GPU 环境：检查 nvidia-smi 是否列出全部卡

下一个问题，在 GPU 服务器的运维中，当发现 GPU 利用率长时间过高，且显存也几乎占满，你从软件层面会如何排查原因？要说出至少三个排查方向和具体操作。这次一定要回答好，别再掉链子

排查方向一：定位占用进程

# 查看具体进程占用
nvidia-smi pmon -s um -o T

# 或详细模式
nvidia-smi -q -d PIDS | grep -A 5 "Process ID"

# 获取 PID 后查进程详情
ps -ef | grep <PID>
lsof -p <PID> | head -20

排查方向二：分析显存泄漏

# 实时监控显存变化（每秒刷新）
watch -n 1 nvidia-smi

# Python 程序用 torch 查显存分配
python -c "
import torch
print(f'Allocated: {torch.cuda.memory_allocated()/1024**3:.2f} GB')
print(f'Reserved:  {torch.cuda.memory_reserved()/1024**3:.2f} GB')
print(f'Max:       {torch.cuda.max_memory_allocated()/1024**3:.2f} GB')
"

# 启用显存分析（针对 PyTorch）
export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:51200

排查方向三：检查任务调度与并发

# 查看是否有多个任务挤占单卡
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# 检查容器/K8s 资源限制
docker stats --no-stream | grep <container_id>
kubectl top pod <pod_name> --containers

# 查看任务是否超发
cat /proc/<PID>/cgroup | grep gpu

再问一个实际操作题：你们团队在维护 GPU 服务器时，突然收到告警，某台机器的 GPU 温度飙升至 95℃，且显存占用异常，同时 ssh 连接频繁断开。请分步骤说明排查思路和解决措施

  1. 保连接：IPMI/iLO 带外登录，绕过 SSH，确认非网络问题

  2. 看现场：nvidia-smi -q -d TEMPERATURE 确认真实温度，查风扇转速是否归零

  3. 杀进程：nvidia-smi pmon 定位高显存占用 PID，kill -9 强制终止，降温优先

  4. 查根因：

    • 风扇故障 → 报硬件更换
    • 散热片堵塞 → 清灰
    • 程序死循环 → 查代码日志

  5. 防复现：临时降频 nvidia-smi -pl 200（限制功耗），迁移业务到备用机

一句话：带外保命，杀进程降温，查风扇/散热/代码，降频迁移保业务。

假设现在你负责的 GPU 服务器集群突然出现批量进程无响应，监控面板显示 GPU 显存占用为 0 但节点状态为 “忙碌”，同时机房反馈部分机柜电源指示灯闪烁。结合之前的操作经验，从硬件到软件，分步骤说明你的排查逻辑，以及每一步的核心命令或操作依据

  1. 硬件：IPMI 查电源日志 ipmitool sel list，机房确认 PDU 波动
  2. 总线：lspci | grep nvidia 验 GPU 是否掉卡，dmesg 看 PCIe 报错
  3. 驱动：nvidia-smi 空白则 modprobe nvidia 重载，或重装驱动
  4. 进程：ps aux | awk '$8~/D/' 抓 D 态僵死进程，kill -9 清理

最后问你：IDC 机房巡检时，发现某机柜温湿度超标，你的处理流程是什么？这次再答不出来，直接淘汰

  1. 确认范围：确认是是不是传感器异常，然后再排查单柜超标还是整列超标，看相邻机柜传感器数据
  2. 定位热源：该机柜哪台设备温度最高，ipmitool sensor list 查服务器进风/出风温度
  3. 应急降温：临时调高冷通道空调出风量，打开机柜盲板疏通气流，高热设备关机或迁移
  4. 查根因：空调故障？冷热通道封闭失效？设备超配密度过高？
  5. 同步记录：报工单给设施团队，并说明紧急程度。持续监控直到恢复正常阈值

一句话：定范围、找热源、应急降温、查根因、报工单盯恢复。

现在请你回答：在 GPU 服务器运维中，若通过命令行发现某块 GPU 持续高负载（超过 90%）但无实际任务运行，可能的原因有哪些？应如何排查处理？

可能原因

  • 僵尸进程：任务已退出但驱动未释放 GPU 上下文
  • 驱动异常：内核模块卡住，GPU 处于忙等状态
  • 硬件故障：GPU 内部错误导致 SM 持续占用
  • 挖矿木马：隐藏进程占用算力

排查步骤

  1. 查进程：nvidia-smi pmon -s um 和 fuser -v /dev/nvidia* 确认无 PID 占用，但 nvidia-smi 显示高负载 → 僵尸/驱动问题
  2. 查显存：nvidia-smi 显存占用为 0 但利用率 90% → 典型驱动卡死
  3. 查日志：dmesg | grep -i nvidia 看 Xid 错误，/var/log/nvidia-installer.log 查驱动报错 cps aux | grep -E "miner|xmr|pool"，netstat -tulnp 看异常外连
  4. 重置 GPU：nvidia-smi -r -i <GPU_ID> 热重置，或 rmmod nvidia; modprobe nvidia 重装驱动
  5. 硬件隔离：重置无效则 nvidia-smi drain -p <PCI_BUS> 标记不可用，迁移业务后换卡

一句话：无进程高负载 = 僵尸/驱动/硬件/木马，先查 PID 和显存，再扫日志和隐藏进程，重置无效换硬件。

你简历里写 “掌握 RHCSA 级核心技能”，那 RHCSA 里配置 iptables 规则时，怎么限制特定 IP 的 SSH 访问？别给我背命令，要讲实际操作中怎么验证规则生效了！

配置思路：默认拒绝，仅允许白名单 IP。

验证规则生效的方法：

  1. 本地验证：iptables -L -n -v看规则是否加载，计数器是否有流量（pkts/bytes 非 0 说明命中）
  2. 对端测试：从允许 IP SSH 连接应成功，从拒绝 IP 连接应超时或拒绝（Connection refused/timeout）
  3. 抓包确认：tcpdump -i eth0 port 22看被拒绝 IP 的请求是否到达本机但被丢弃
  4. 日志追踪：开iptables -A INPUT -j LOG看/var/log/messages记录 DROP 行为
  5. 保存验证：service iptables save后重启服务，确认规则持久化未丢失

If you enjoyed this, leave a comment~

... Page views
© 2021 - 2026 Vullfin @VV
Powered by theme astro-koharu · Inspired by Shoka