欢迎你，初级系统管理员！这是「LabEx」一个忙碌的周一早晨，你刚刚收到一条紧急警报：主应用服务器运行速度显著变慢，影响了所有用户。资深管理员们正在参加紧急会议，现在轮到你来调查并稳定系统了。
这是你大显身手的时刻。你的任务是深入服务器的命令行，通过检查运行中的进程来诊断问题，清除任何占用资源的「元凶」，并确保核心服务保持运行。完成本次挑战后，你将证明自己在压力下管理 Linux 生产环境的能力，这是每一位系统管理员的核心技能。
作为进程监察员，你的第一步是全面了解服务器上当前正在运行的情况。获取所有活跃进程的静态快照将帮助你开始调查并识别任何异常情况。
运行命令后，你应该看到类似如下的输出：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 169848 9064 ? Ss 08:30 0:02 /sbin/init
labex 1234 0.0 0.0 2324 564 pts/0 S+ 08:35 0:00 bash /home/labex/project/resource_hog.sh
labex 1235 0.0 0.0 2324 564 ? S 08:35 0:00 bash /home/labex/project/critical_service.sh
...输出将显示多个进程，包含用户、进程 ID、CPU 占用、内存占用以及启动每个进程的命令等列。
ps。ps 命令的哪些选项可以显示所有（all）用户的进程、使用用户（user）友好格式，并包含未连接到终端（terminal）的进程。来自 ps 的静态列表是一个很好的开始，但服务器的负载每秒都在变化。你需要一个实时的动态视图来观察哪个进程正在主动导致系统变慢。是时候祭出更强大的监控工具了。
启动监控工具后，你应该看到一个自动更新的交互式界面，显示内容如下：
top - 09:15:30 up 1:45, 1 user, load average: 1.50, 1.20, 0.85
Tasks: 105 total, 2 running, 103 sleeping, 0 stopped, 0 zombie
%Cpu(s): 45.0 us, 5.0 sy, 0.0 ni, 50.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 2048.0 total, 850.4 free, 950.2 used, 247.4 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used, 0.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1234 labex 20 0 12884 1564 1320 R 95.0 0.1 2:15.30 bash /home/labex/project/resource_hog.sh
1235 labex 20 0 12884 1564 1320 S 0.0 0.1 0:00.00 bash /home/labex/project/critical_service.sh
1 root 20 0 169848 9064 6868 S 0.0 0.4 0:02.15 systemd
...界面顶部会显示系统统计信息，下方是按 CPU 占用率排序的进程列表，CPU 消耗最高的进程排在最上方。
q 键退出此交互式工具。你已经找到了捣蛋鬼：resource_hog.sh。然而，一名优秀的系统管理员不会盲目地终止进程。你还注意到了 critical_service.sh 正在运行。在对资源占用者采取任何行动之前，你应该识别并了解系统中运行的所有关键进程。
critical_service.sh 脚本的进程 ID（PID）。pgrep 命令来查找运行 critical_service.sh 的进程 PID。使用 pgrep 找到 PID 后，你应该看到如下输出：
1235这个数字（在本例中为 1235）就是关键服务进程的进程 ID。
你可以使用以下命令验证进程详情：
ps -p 1235 -o pid,ppid,cmd输出应类似于：
PID PPID CMD
1235 1 /bin/bash /home/labex/project/critical_service.shpgrep 可以根据进程名称查找 PID。pgrep -f 可以匹配完整的命令行。现在你已经识别了关键进程，是时候处理那个拖慢服务器速度的 resource_hog.sh 了。你需要终止这个进程以恢复正常运行。
resource_hog.sh 进程。pkill 命令停止 resource_hog.sh 脚本。要验证进程是否已终止，你可以在操作后检查进程列表。在终止之前，你可能会看到：
labex 1234 95.0 0.0 2324 564 pts/0 R+ 09:15 5:00 bash /home/labex/project/resource_hog.sh成功终止后，运行相同的检查命令应该看不到匹配的进程（除了 grep 命令本身）：
labex 2345 0.0 0.0 2324 564 pts/0 S+ 09:20 0:00 grep resource_hogpkill 命令根据名称向进程发送终止信号。ps aux | grep resource_hog 来验证该进程是否已不再运行。服务器再次恢复稳定！干得漂亮。正当你准备休息一下时，一位开发人员给你发来消息。他们需要你在服务器上运行一个长时间运行的脚本 data_processor.sh。你不能为了这个脚本让终端会话一直开启好几个小时。你需要让它在后台运行，这样即使你退出登录，它也会继续执行。
data_processor.sh 脚本，使其在后台运行且不受挂断影响（即关闭终端后不会停止）。~/project 目录下。nohup 命令运行脚本。& 运算符将进程发送到后台。processor.log 的文件中。成功在后台启动脚本后，你应该看到类似如下的输出：
[1] 3456
nohup: ignoring input and appending output to 'processor.log'[1] 3456 表示作业编号和进程 ID。你可以通过检查日志文件来验证脚本是否正在运行：
cat processor.log这可能会显示如下输出：
Starting data processing at Mon Sep 11 10:30:00 UTC 2025你还可以确认进程是否仍在运行：
ps aux | grep data_processor这应该显示后台进程处于活跃状态。
nohup 命令代表「不挂断」（no hang up）。& 符号告诉 Shell 将其作为后台作业运行。> 重定向标准输出，使用 2>&1 重定向标准错误。恭喜你，管理员！你已成功处理了关键的服务器性能问题，并展示了对 Linux 进程管理的精湛掌握。现在服务器运行稳定，关键服务得到了优先保障，长时间运行的任务也在后台平稳进行。
在本次挑战中，你证明了自己具备以下能力：
ps 列出并检查所有运行中的进程。top 实时监控系统资源。pgrep 识别重要进程。pkill 干净地终止异常进程。nohup 和 & 运行并管理在退出登录后依然持续的后台作业。这些都是系统管理、DevOps 或后端开发岗位中必不可少的核心高价值技能。你将一次潜在的危机转化为了展示专业能力的绝佳机会。做得好！
