The top command in Linux is a powerful utility that provides realtime information about system performance, including CPU usage, memory usage, running processes, and more.

It is an essential tool for system administrators to monitor system health and manage resources effectively.

1. Basic Usage

Simply running top without any arguments displays an interactive screen showing system statistics and a list of running processes:

$ top

2. Understanding the top Output

The top interface is divided into multiple sections

Header Section

This section provides an overview of the system status, including uptime, load averages, and system resource usage.

• Uptime and Load Average – Displays how long the system has been running and the average system load over the last 1, 5, and 15 minutes.
• Task Summary – Shows the number of processes in various states:
  • Running – Processes actively executing on the CPU.
  • Sleeping – Processes waiting for an event or resource.
  • Stopped – Processes that have been paused.
  • Zombie – Processes that have completed execution but still have an entry in the process table. These occur when the parent process has not yet read the exit status of the child process. Zombie processes do not consume system resources but can clutter the process table if not handled properly.
• CPU Usage – Breaks down CPU utilization into different categories:
  • us (User Space) – CPU time spent on user processes.
  • sy (System Space) – CPU time spent on kernel operations.
  • id (Idle) – Time when the CPU is not being used.
  • wa (I/O Wait) – Time spent waiting for I/O operations to complete.
  • st (Steal Time) – CPU cycles stolen by a hypervisor in a virtualized environment.
• Memory Usage – Shows the total, used, free, and available RAM.
• Swap Usage – Displays total, used, and free swap memory, which is used when RAM is full.

Process Table

The table below the header lists active processes with details such as:

• PID – Process ID, a unique identifier for each process.
• USER – The owner of the process.
• PR – Priority of the process, affecting its scheduling.
• NI – Nice value, which determines how favorable the process scheduling is.
• VIRT – The total virtual memory used by the process.
• RES – The actual RAM used by the process.
• SHR – The shared memory portion.
• S – Process state:
  • R – Running
  • S – Sleeping
  • Z – Zombie
  • T – Stopped
• %CPU – The percentage of CPU time used.
• %MEM – The percentage of RAM used.
• TIME+ – The total CPU time consumed by the process.
• COMMAND – The command that started the process.

3. Interactive Commands

While running top, various keyboard shortcuts allow dynamic interaction:

• q – Quit top.
• h – Display help.
• k – Kill a process by entering its PID.
• r – Renice a process (change priority).
• z – Toggle color/monochrome mode.
• M – Sort by memory usage.
• P – Sort by CPU usage.
• T – Sort by process runtime.
• 1 – Toggle CPU usage breakdown for multi-core systems.
• u – Filter processes by a specific user.
• s – Change update interval.

4. Command-Line Options

The top command supports various options for customization:

• -b (Batch mode): Used for scripting to display output in a non-interactive mode.$ top -b -n 1-n specifies the number of iterations before exit.
• -o FIELD (Sort by a specific field):$ top -o %CPUSorts by CPU usage.
• -d SECONDS (Refresh interval):$ top -d 3Updates the display every 3 seconds.
• -u USERNAME (Show processes for a specific user):$ top -u john
• -p PID (Monitor a specific process):$ top -p 1234

5. Customizing top Display

Persistent Customization

To save custom settings, press W while running top. This saves the configuration to ~/.toprc.

Changing Column Layout

• Press f to toggle the fields displayed.
• Press o to change sorting order.
• Press X to highlight sorted columns.

6. Alternative to top: htop, btop

For a more user-friendly experience, htop is an alternative:

$ sudo apt install htop  # Debian-based
$ sudo yum install htop  # RHEL-based
$ htop

It provides a visually rich interface with color coding and easy navigation.

Today, i came across a video on ByteMonk on Event Sourcing. In that video, they mentioned about CQRS, then i delved into that. This blog is on understanding CQRS from a high level. I am planning to dive deep into Event Driven Architecture conceptually in upcoming weekend.

In this blog, i jot down notes for basic understanding of CQRS.

In the world of software development, there are countless patterns and practices aimed at solving specific problems. One such pattern is CQRS, short for Command Query Responsibility Segregation. While it might sound complex (it did for me), the idea is quite straightforward when broken down into simple terms.

What is CQRS?

Imagine you run a small bookstore. Customers interact with your store in two main ways

1. They buy books.
2. They ask for information about books.

These two activities buying (command) and asking (querying) are fundamentally different. Buying a book changes something in your store (your inventory decreases), whereas asking for information doesn’t change anything; it just retrieves details.

CQRS applies the same principle to software. It separates the operations that change data (called commands) from those that read data (called queries). This separation brings clarity and efficiency (not sure yet )

In simpler terms,

• Commands are actions like “Add this book to the inventory” or “Update the price of this book.” These modify the state of your system.

• Queries are questions like “How many books are in stock?” or “What’s the price of this book?” These fetch data but don’t alter it.

By keeping these two types of operations separate, you make your system easier to manage and scale.

Why Should You Care About CQRS?

Let’s revisit our bookstore analogy. Imagine if every time someone asked for information about a book, your staff had to dig through boxes in the storage room. It would be slow and inefficient!

Instead, you might keep a catalog at the front desk that’s easy to browse.

In software, this means that,

• Better Performance: By separating commands and queries, you can optimize them individually. For instance, you can have a simple, fast database for queries and a robust, detailed database for commands.

• Simpler Code: Each part of your system does one thing, making it easier to understand and maintain.

• Flexibility: You can scale the command and query sides independently. If you get a lot of read requests but fewer writes, you can optimize the query side without touching the command side.

CQRS in Action

Let’s say you’re building an app for managing a library. Here’s how CQRS might look,

• Command: A librarian adds a new book to the catalog or updates the details of an existing book.

• Query: A user searches for books by title or checks the availability of a specific book.

The app could use one database to handle commands (storing all the book details and history) and another optimized database to handle queries (focused on quickly retrieving book information).

Does CQRS Always Make Sense?

As of now, its making items complicated for small applications. As usual every pattern is devised for their niche problems. Single Bolt can go through all Nuts.

In upcoming blogs, let’s learn more on CQRS.