ExamFinch.com My Study

Study guide

9.1 Identify and Kill CPU/Memory Intensive Processes

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

9.1 Identify and Kill CPU/Memory Intensive Processes

Key Takeaways Explain This Topic AI

Use top, ps (especially ps aux and ps -eo with sort), pgrep, and /proc to identify processes that consume CPU or memory on RHEL 10.

Match processes by name or pattern with pgrep/pkill; confirm the PID before sending a signal with kill or killall.

Default kill sends SIGTERM (15) for graceful stop; SIGKILL (9) forces termination and should be a last resort; SIGHUP (1) often reloads or restarts behavior depending on the program.

Exam tasks grade the end state: the named process is gone or no longer runaway—verify with pgrep, ps, or top after you act.

Killing a process is not a reboot-time configuration; if a service restarts on boot, fix enablement or unit health in related objectives rather than only killing once.

Last updated: August 2026

9.1 Identify and Kill CPU/Memory Intensive Processes

Quick Answer: Find hot processes with top , ps , and pgrep . Stop them with kill / pkill using the right signal—usually SIGTERM (15) first, SIGKILL (9) only if needed. Confirm with pgrep or ps that the process is gone. On EX200 you prove the end state , not that you memorized every ps flag.

Why this skill appears on EX200

Under Operate running systems , Red Hat expects you to identify CPU- and/or memory-intensive processes and kill processes . Typical lab wording looks like:

  • “A process named runaway is consuming excessive CPU—stop it.”
  • “Find the process using the most memory and terminate it.”
  • “End all processes matching pattern X owned by user Y.”

You are graded on whether the process is no longer running (or no longer matching the problem description), not on which pretty TUI you preferred. Work fast, verify twice, and avoid killing critical system daemons unless the task clearly targets them.

Process identity basics

Every process has a PID (process ID). Child processes have a PPID (parent). You send signals to a PID (or to a process group). Tools that accept a name still resolve names to PIDs under the hood.

Useful views of the same truth:

  • Source What you see
  • ps Snapshot of processes at that instant
  • top / htop Continuously updating view (htop may need install)
  • /proc/<pid>/ Kernel’s live process directory (status, cmdline, fd)
  • pgrep PIDs matching criteria

On RHEL 10, ps , top , kill , pgrep , and pkill from procps-ng are the exam-safe toolkit. Prefer them over exotic tools that might not be installed.

Live overview with top top

# Inside top (common keys):

  • # P sort by CPU% M sort by memory%
  • # k kill (prompts for PID and signal)
  • # 1 toggle per-CPU lines
  • # q quit

Header lines show load average, task counts, CPU breakdown, and memory/swap. The process table columns that matter most on the exam:

  • Column Meaning
  • PID Process ID to pass to kill
  • USER Effective user
  • %CPU Recent CPU share
  • %MEM Physical memory share
  • TIME+ Cumulative CPU time
  • COMMAND Command name/line (truncated in default view)

Exam tip: Sort by CPU ( P ) or memory ( M ), note the PID and COMMAND , then quit and use shell kill if you prefer a reproducible audit trail. Killing from inside top is valid if you are careful with the PID prompt.

  • Batch (scriptable) snapshot without interactive UI: top -b -n 1 | head -n 20
  • Snapshots with ps
  • Classic BSD-style full list: ps aux
  • ps aux --sort=-%cpu | head
  • ps aux --sort=-%mem | head
  • Field (aux) Use
  • USER Who owns the process
  • PID Kill target
  • %CPU / %MEM Intensity
  • VSZ / RSS Virtual size vs resident (RSS closer to “real RAM”)
  • STAT State: R running, S sleep, D uninterruptible, Z zombie, T stopped
  • COMMAND Full-ish command
  • POSIX/System V style and custom formats: ps -ef
  • ps -eLo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
  • ps -eo pid,user,pcpu,pmem,stat,comm --sort=-pcpu | head
  • ps -eo pid,user,pcpu,pmem,rss,comm --sort=-rss | head
  • ps -u student # processes for one user
  • ps -C httpd -o pid,user,cmd # by command name

Zombies ( Z ): Already dead; parent has not wait() ed. You cannot “kill” a zombie usefully—fix or kill the parent if the task is about cleaning zombies. Most EX200 tasks target runaway live processes, not zombies.

D state: Uninterruptible sleep (often I/O). SIGKILL may not clear it until the underlying wait ends. Do not burn all exam time on a stuck D-state process if the task can be satisfied another way.

  • pgrep and pkill
  • When the task gives a name or pattern , these are faster than scrolling ps : pgrep runaway
  • pgrep -a runaway # PID + full command line
  • pgrep -u student stress
  • pgrep -f "python3 /opt/job.py" # match full command line (-f)
  • pkill runaway # SIGTERM to matches
  • pkill -u student runaway
  • pkill -f "python3 /opt/job.py"
  • pkill -9 runaway # SIGKILL by name—double-check pattern first

Danger: pkill -f patterns can match more than you intend (including your own shell history or scripts). Always pgrep -a the same pattern before pkill . # Safe pattern

pgrep -a -f "/usr/local/bin/runaway"

# If the list is only the intended targets:

  • pkill -f "/usr/local/bin/runaway"
  • killall (from psmisc, often present) kills by process name: killall runaway
  • killall -9 runaway

Prefer exact name awareness : killall bash is catastrophic on a multiuser system. On the exam, use the name the task specifies and verify with pgrep afterward.

  • kill and signals kill PID
  • kill -15 PID # same as default: SIGTERM
  • kill -TERM PID
  • kill -9 PID # SIGKILL
  • kill -KILL PID
  • kill -1 PID # SIGHUP
  • kill -HUP PID
  • kill -SIGNAL PID1 PID2 ... # multiple PIDs
  • List names and numbers: kill -l
  • Signal Number Typical use
  • SIGHUP 1 Hangup; many daemons reload config ; shells may exit
  • SIGINT 2 Interrupt (like Ctrl+C)
  • SIGQUIT 3 Quit with core (policy-dependent)
  • SIGKILL 9 Force kill ; cannot be caught or ignored
  • SIGTERM 15 Default polite terminate ; can be caught for cleanup
  • SIGSTOP 19 Pause (cannot be caught); kill -STOP
  • SIGCONT 18 Resume after STOP
  • Practical signal strategy on EX200

Identify PID(s) with top / ps / pgrep -a .

Send SIGTERM : kill PID or pkill name .

Wait a second; re-check pgrep / ps -p PID .

If still alive and the task requires it gone: kill -9 PID .

Re-verify. Document nothing fancy—just leave the system correct.

Why not always -9? Well-written programs flush data and release locks on SIGTERM. SIGKILL skips cleanup. Graders usually only care that the process is gone, but good habit is TERM first unless the task says “force” or the process ignores TERM.

Permissions

You can signal your own processes. Signaling another user’s processes requires root (or appropriate capability). Exam tasks that target system-wide runaways imply root on the VM. sudo kill 1234

  • sudo pkill -u alice stress-ng
  • /proc quick checks ls /proc/1234
  • cat /proc/1234/cmdline | tr '\0' ' '; echo
  • cat /proc/1234/status | egrep '^(Name|State|Uid|VmRSS|Threads):'
  • If /proc/PID vanishes, the process already exited. Useful when kill returns “No such process.”
  • Memory vs CPU: what “intensive” means

CPU intensive: High %CPU in top / ps , climbing TIME+ , often state R .

  • Memory intensive: High %MEM or RSS ; system may use swap ( free -h , si / so in vmstat ). free -h
  • ps aux --sort=-%mem | head -n 15

A process can be memory-heavy while mostly sleeping ( S ). Still a valid kill target if the task says “memory intensive.”

  • End-to-end exam scenarios
  • Scenario A — Named runaway on CPU
  • Task: Process burncpu is consuming CPU. Terminate it. pgrep -a burncpu
  • # e.g. 44821 burncpu
  • sudo kill 44821
  • sleep 1
  • pgrep burncpu || echo "gone"

# if still present:

  • sudo kill -9 44821
  • pgrep burncpu || echo "gone"
  • Scenario B — Highest memory consumer

Task: Identify the non-kernel process using the most RAM and kill it (wording varies—read carefully if system processes are excluded). ps -eo pid,user,pmem,rss,comm --sort=-rss | head -n 10

  • # Choose the PID the task intends (often a user job, not kthreadd)
  • sudo kill PID
  • ps -p PID || echo "terminated"
  • Scenario C — All matching jobs for a user pgrep -a -u student jobworker
  • sudo pkill -u student jobworker
  • pgrep -u student jobworker || echo "none"
  • Scenario D — Service vs stray process

If httpd is “bad” only because of a task to stop the service , prefer systemctl stop httpd (later objectives) so unit state is clean. If the task literally says kill process evil.py , use kill / pkill —do not over-engineer.

Common traps

Killing the wrong PID after the process already exited and the PID was reused—re-run pgrep -a immediately before kill .

pkill java matching more JVMs than intended—use a full-path -f pattern after dry-run pgrep -a .

Assuming SIGKILL failed when the process is in D state—note it and move on if required work is done.

Killing PID 1 ( systemd )—do not; you will destabilize the system.

Forgetting verification —always pgrep / ps after kill.

Treating kill as persistent config —if a enabled service respawns after reboot, that is a services problem, not solved by a one-time kill alone.

Persistence and scoring notes

Process death is immediate and does not need a reboot to “take effect.” Reboot may restart enabled services or @reboot jobs. For pure “kill this process now” tasks, success is: process absent before you leave the station . If a later task requires a service up, do not leave critical units dead.

Section checkpoint

You should open top or ps , sort or filter by CPU and memory, resolve names with pgrep -a , send SIGTERM then SIGKILL as needed with kill / pkill , avoid over-broad patterns, and verify the process is gone. That is the EX200 standard for identifying and killing intensive processes.