The command-line tool "top" provides real-time resource utilization reports, but may inaccurately reflect CPU usage within Docker containers. An experiment showed "top" reported 25% CPU utilization instead of 100%. To obtain accurate metrics in containers, alternative tools like Docker stats, cAdvisor, and yCrash should be utilized for improved monitoring.
What are the process states in Unix/Linux?
Unix/Linux processes can be in various states: RUNNING & RUNNABLE, INTERRUPTABLE_SLEEP, UNINTERRUPTABLE_SLEEP, STOPPED, and ZOMBIE. Each state indicates a different condition of process activity and resource waiting. The article also explains how to terminate processes in different states and methods to find their current state using command-line tools.
How to Kill a Process in Unix/Linux? (kill, killall, pkill, top)
This article provides an overview of various methods to terminate processes in Unix/Linux systems. It explains commands like 'kill', 'killall', and 'pkill', detailing how to use them effectively. The 'top' command is also discussed for process termination. Key differences between these commands are highlighted for user clarity.
Load Average – indicator for CPU demand only?
The 'Load Average' metric, often mistaken as solely CPU demand, also reflects I/O demand. A case study using BuggyApp demonstrated this, showing high disk I/O operations led to a Load Average of 5.0 on a single CPU system, despite low CPU utilization. Thus, Load Average encompasses both CPU and I/O activity.
I/O waiting CPU time – ‘wa’ in top
The article discusses the metric of 'waiting CPU time' in Unix/Linux systems, which measures how long the CPU waits for I/O operations. High waiting time suggests inefficiencies, requiring investigation if exceeding 10%. It offers solutions to minimize this time, emphasizing root cause analysis and optimization techniques to improve performance and resource management.
User CPU time – ‘us’ time in top
The article explores 'User CPU time' in Unix/Linux systems, emphasizing its distinction from 'System CPU time.' It details how to measure and simulate high 'User CPU time' using tools like yCrash and BuggyApp. Solutions for high usage include restarting processes or optimizing code, and ensuring adequate compute capacity through upgrades or resource distribution.
System CPU time – ‘sys’ time in top
The article discusses System CPU Time in Unix/Linux, explaining its relation to User CPU Time. It describes how System CPU Time measures processor time spent on operating system functions necessary for application operations, such as network calls. Tools like yCrash and the 'top' command can monitor System CPU Time, and simulations for high consumption are demonstrated using BuggyApp. Solutions for excessive System CPU Time include restarting processes and ensuring updated OS versions.
Steal CPU time – ‘st’ time in top
The article examines 'steal' or 'stolen' CPU time in cloud and virtualized environments, highlighting its significance when multiple virtual machines share CPU resources. It describes how high steal time indicates an overloaded physical host and outlines methods to monitor, simulate, and resolve high steal time issues, including upgrading instances and optimizing applications.
Software Interrupt time – ‘si’ time in top
The article discusses Software Interrupt CPU time in Unix/Linux systems, detailing its definition and occurrence based on exceptional software conditions and deferred hardware interrupts. It describes methods to find this time using tools like yCrash and the 'top' command. Solutions for high software interrupt times include rebooting and code optimization.
nice CPU time – ‘ni’ time in top
The article examines 'nice CPU time' in Unix/Linux, which represents CPU time spent on low-priority processes. It explains how to adjust process priorities using the 'nice' command and discusses methods to monitor and manage CPU consumption. Recommendations are provided for maintaining optimal performance levels and addressing high 'nice CPU time' issues.
