linux-admin

Start with top -bn1 and ps aux --sort=-%cpu to identify consuming processes, then check vmstat for I/O wait. If user CPU is high, use strace -p PID -c for syscall breakdown; if system CPU is high, check for I/O wait, softirq, or steal time indicating a noisy neighbor.

Run iostat -xz 1 5 and examine %util, await, and avgqu-sz. Utilization near 100% with high queue depth indicates saturation; small avgrq-sz with high IOPS means random I/O limits, while large request sizes indicate throughput limits.

This usually means the wrong user, wrong key, or incorrect key permissions. Verify the AMI default user (ec2-user for Amazon Linux, ubuntu for Ubuntu), run chmod 600 on the private key, and use ssh -v to see which keys are offered and rejected.

The OOM killer scores processes by RSS relative to total RAM plus an oom_score_adj value ranging from -1000 to 1000. Higher scores are killed first; setting oom_score_adj to -1000 makes a process immune, which is useful for protecting critical databases.

Yes, use AWS Systems Manager Session Manager with aws ssm start-session, or configure SSH over SSM using a ProxyCommand with the AWS-StartSSHSession document. This requires the SSM agent and an IAM instance role but no inbound port 22.

Run journalctl -u service_name --since "10 min ago" to see recent logs, check dmesg for OOM kills, and use coredumpctl list for segfaults. Also inspect the exit code with systemctl show -p ExecMainStatus and verify dependency ordering.