How to list LWPs and processes in Linux and control them in detail

If you manage servers or work frequently with Linux, sooner or later you're going to need List processes, lightweight threads (LWPs), and monitor their resource consumptionKnowing what is running, how many resources it uses, and how each process is organized is key to detecting bottlenecks, service outages, or unusual system behavior.

In the following lines you will find a very complete guide in which we will see What are processes and LWPs, how to list them, how to view their limits, and how to monitor them in real timeWe will use classic commands (ps, top, htop…) as a base, and also some more advanced techniques with /proc, diagnostic tools and priority settings, all explained in straightforward, local Spanish.

Processes, threads, and LWPs in Linux: basic concepts

In Linux, when you run a program, a process that is the instance of that program in memoryalong with all the resources it needs: code, data, file descriptors, stack, etc. Each process receives a unique identifier called a PID (Process ID), which is the number we then use to monitor or kill it.

In addition to the “normal” or heavyweight processes, the kernel handles the so-called light threads or LWPs (LightWeight Processes)A long-window thread (LWP) shares many resources (code, data, open files, signals, etc.) with other threads in the same process, but maintains its own stack and execution context. This makes context switching between threads much cheaper than switching between independent processes.

One curious thing about Linux is that, internally, It does not strictly differentiate between process and thread.Both are managed as kernel tasks, and a thread is essentially a "process" that shares resources with others. There are no special kernel-level thread structures like in other systems. OSHowever, in practice we can use LWPs to achieve real parallelism in multi-core systems.

This parallelism is achieved by distributing the work of an application across multiple threads. Each LWP can run on a different processor coreThis allows the program to utilize all available cores. Because the cost of creating and switching LWPs is low, Linux is very efficient at running large numbers of threads, provided we respect system limits.

Process and thread limits in Linux

As with any operating system, there is a maximum number of tasks that the kernel can handle simultaneously. In Linux, these Process and thread boundaries are exposed as kernel parameters within the pseudo-file system /proc, in the route /proc/sys/kernel/.

The global limit of threads that the kernel can support is stored in the file /proc/sys/kernel/threads-maxIf you check the contents of that file with cat o sysctlYou will get the maximum number of LWPs that the system is capable of creating before refusing to launch any more tasks.

That value is usually quite high in modern servers with multiple cores and plenty of RAM, while in modest teams or Virtual machines small You may encounter lower numbers. If that limit is reached and no processes terminate, the kernel will be unable to create new processes or threads, which can lead to errors when launching services or commands.

There is another important limit in /proc/sys/kernel/pid_maxThis indicates the maximum process ID that can be assigned. This value also acts in practice as a limit for the number of processes (and by extension, threads) that can coexist, since Linux treats both in a unified way. When the PID counter reaches this maximum, it starts again from the bottom, and it's common to see "repeated" PIDs. Therebut belonging to completely different processes.

Calculating the maximum number of threads and adjusting the stack

The actual number of LWPs you can have on a Linux system depends not only on those kernel parameters, but also on la virtual memory available and the size of the stack of each threadA commonly used approximate formula is:

maximum number of threads ≈ virtual memory / (stack size × 1024 × 1024)

In that expression, the stack size per thread is usually queried with the command ulimit -sThis value indicates how many kilobytes of memory are reserved for the stack of each LWP that is created. A larger stack size provides greater protection against overflows, but also You will be able to have fewer simultaneous threads for the same amount of memory.

If you need to run an application with thousands or tens of thousands of threads, it might be of interest. reduce the stack size per thread using again ulimit (for example in scripts of Boot or system services), as long as the application code does not require huge stacks.

In summary, the number of LWPs in Linux is limited by: kernel parameters (threads-max, pid_max), stack size per thread, and total available memoryBy carefully adjusting these factors, you can scale the number of concurrent threads without compromising system stability.

Basic commands for listing processes and LWPs

To start working with processes and threads in Linux, the classic tool is the command ps, which shows the status of the processes It's a snapshot in time (not real-time). Unlike a graphics monitor, its output is static: if you want updated information, you simply restart it.

With ps no options You will only see processes linked to the current shell. To obtain all system processesincluding those who do not have terminal associated, the usual thing to use is:

ps aux

In that output you will see, among other data, the owner user, the PID, the percentage of CPU and RAM used, the execution time, and the command with which each process was launched. It's a lot of information, but it's essential for locating tasks that are consuming a lot of the machine's resources.

Some useful combinations of ps To have more control over what appears, the following are used:

• ps -e o ps -A: lists all active processes in generic format UNIX.
• ps -u nombre_usuario: shows only the processes of a specific user.
• ps -axjf: displays the output in a hierarchical format, nesting child processes under their parents.
• ps -C nombre_proceso: filters by command name and includes associated child processes.

Another common option is to use ps aux | grep patrón to keep only the processes that contain that text, for example a web daemon, a database engine, or a script Specifically, it's a very convenient way to find what you're looking for at a glance without getting lost in pages and pages of results.

Real-time monitoring with top and htop

When you need to see how processes change in real time, the star command is top, which displays a dynamic monitor of the system's activity. Unlike psThe output is continuously updated, showing CPU usage, memory usage, average load, number of active tasks, and an ordered list of processes.

By simply running topYou'll see the processes ordered by CPU usage. You can reorder by other fields, filter, kill processes, or change priorities by pressing different keys within the interface itself (the combinations may vary slightly depending on the version, but are usually indicated at the bottom).

A typical way to focus on the heaviest processes is to use a command like:

top -o %CPU

This is how you place it on top the processes that are consuming the most CPUwhich is very useful when something has started to spike processor usage and you want to find the culprit quickly.

If you prefer something more visual, you can install htop, an improved version of top with an interactive interfaceColor bars and keyboard and mouse navigation. On many distributions you will have to install it first using the package manager, for example:

sudo apt-get install htop

Once installed, you run htop and you'll have a color-coded view of the load per core, memory, swap, and a process table where you can Scroll vertically and horizontally, filter by user, change priorities, or kill processes without manually typing the PID..

Resource monitoring with atop

For more in-depth performance analysis, especially on servers, there is the tool atop, which records and displays the activity of all processes with a high level of detail. It is a full-screen, text-mode utility that focuses on the evolution of load and resource usage over time.

When you throw atopYou'll see statistics of CPU, memory, swap, disks and network which typically refresh every 10 seconds. Furthermore, it can remain active in the background for days, saving histories that you can later review to analyze a problem that occurred in the past.

Among its advantages, the ability to group consumption by user or by process nameHighlight in red the critical resources that are running low, show processes that have already finished but are still relevant in the log, and monitor internal threads (LWPs) within each process.

In many distributions it is installed with specific packages; for instance:

sudo apt install atop
sudo dnf install atop

After installation, simply run atop to start seeing at the process level the consumption of CPU, memory, disk and network, and thus be able to detect with considerable accuracy which component is saturating the system.

How to view the number of threads (LWPs) per process

If what you're interested in is knowing how many Lightweight yarns have a specific process.Linux offers several ways to obtain this information. The first involves inspecting the pseudo-file system. /proc, where the kernel exposes internal data for each task.

Within /proc/<PID>/ you will find the file status, which includes the Threads fieldBy reading that file, you can quickly see how many LWPs the process with that particular PID has created, along with many other details such as status, memory consumption, and capabilities.

Another way using /proc It's about looking at the contents of the directory /proc/<PID>/task/In this path, the kernel creates a subdirectory for each thread belonging to the process. So the directory count within task matches the number of threads. You can use ls combined with wc to perform the count automatically.

In addition to the approach with /proc, the command itself ps can return information at the thread levelUsing the option -H you enter "threaded mode", and with -p You filter by a specific PID. If you add -h You avoid headlands, which makes it easier to channel the flow towards wc and obtain the number of lines, that is, the number of LWPs listed for that process.

In all these methods, if you apply them to the same PID, the thread count must match: the Threads field of status, the number of subdirectories in task and the starting lines of ps In thread mode they should give the same figure, except for slight variations if the process is creating or destroying threads at that exact moment.

Filtering and searching for processes with pgrep and grep

When there are hundreds or thousands of processes running on the machine, finding the one you're interested in by scrolling is a waste of time. This is where it comes in handy. pgrep, which searches for processes by name or pattern and directly returns the matching PIDs.

With a simple pgrep apache You'll see on screen the identifiers of all processes whose name includes that text. And if you need to refine your search further, you can combine pgrep with user filtersFor example, with the option -u to limit the search to the processes of a specific account.

Another commonly used tactic is to rely on grep to filter the output of psA typical command might be ps aux | grep apache, which will show you only the process lines that contain the word "apache", along with their PIDs, resources, and full commands.

Keep in mind that this type of piping adds extra processes (such as the one itself) grep or wc) to the list, so when you do things like ps r | wc -l The counter is incremented by the header row and by the processes that are part of the pipeline itself. It's important to interpret these results correctly to avoid surprises with the total number of tasks.

In general, master ps + grep, pgrep and filtering options It allows you to focus on what interests you without being overwhelmed by system processes that, most of the time, you can ignore in a first analysis.

Control and completion of processes

Listing and monitoring processes is great, but often what you need is complete problematic tasks or monitor their status To free up resources or restore system stability, Linux offers several straightforward tools for this purpose.

The most well-known is kill, which sends signals to processes identified by their PIDIf you don't specify a signal, a SIGTERM is sent, requesting the process to terminate in an orderly fashion. If it resists, you can use the SIGKILL signal (option -9), which forces the process to end immediately without giving the option to clear resources.

When you don't want to collect PIDs one by one, you have pkill y killall, which operate under the name. With pkill firefox You will kill all processes whose name matches “firefox” for your user, while killall It tends to be more aggressive and can affect all instances of the program on the system, including those of other users, depending on permissions.

It's also very useful to understand how they work fg y bg to play with foreground and background processesWhen suspending a task with Ctrl+Z and then using bgYou send it to the background so it continues running while you recover the terminal. If you then need to interact with it again, fg brings her back into the spotlight.

Finally, when you want to run something that continues running even after you log out, you can combine nohup with sending to the background, for example nohup script.sh &This way, the process will not be aborted even if you close the terminal or the connection is lost. SSHThis is very useful for long-duration tasks. If you prefer to schedule it, see how to schedule tasks with cron and at.

Setting priorities with nice and renice

In multi-user systems or systems with many concurrent tasks, it is not enough to know how many processes or LWPs there are; it is also important to know how many processes or LWPs there are. decide which processes are given priority in CPU usageThat's where the commands come into play. nice y renice.

When you start a process with nice -n valor comando You are setting its relative priority. The typical range is from -20 (highest priority) to 19 (lowest priority), with 0 being the default. A higher nice value means the process will be more considerate and yield CPU time to others when competing for resources.

For example, if you have a resource-intensive script that isn't urgent but you want it to run in the background without interfering, you can launch it with nice -n 10 ./script.shThis assigns it a low priority so that it does not monopolize the processor while other interactive processes are working.

If instead of adjusting the priority at startup you need modify the priority of a process that is already underway, you use reniceWith something like renice -n 5 -p PID You change the nice value of the process with that PID, adapting it to current needs (raising or lowering its priority).

Managing priorities correctly with Nice and Renice help prevent a single process or set of threads from It takes away the system's responsiveness, especially in shared servers or production environments with many simultaneous loads.

Advanced tools for debugging and analyzing processes

When a process or one of its LWPs behaves strangely, crashes, or seems to freeze the system, it's often necessary to bring out more advanced diagnostic tools. One of the most powerful is stracewhich allows you to monitor in real time the system calls made by a process. For deeper kernel faults, there is a guide on use crash and kdump.

With a command like strace -p PID can to get involved in a process that is already running and see what syscalls it performs (file reads, writes, network operations, signals, etc.). This is especially useful for figuring out why a process is waiting for "something": perhaps it's blocked trying to open a file that doesn't exist, waiting on a socket, or stuck with insufficient permissions.

Another classic diagnostic tool is lsof (List Open Files)This tool displays the files opened by each process, including disk files, network sockets, devices, and more. It's very useful for detecting which process is occupying a specific port, which service is holding a file locked, or which tasks are reading a particular log.

Complementing lsof, fuser It tells you which processes use a file or a port. Specifically, for example, with a command on a TCP port you can quickly find out which daemon is listening on that number and act accordingly, either by reconfiguring it or stopping it.

To take performance analysis a step further, you have pidstatwhich offers detailed statistics of CPU, memory, and I/O per process, and with watchwhich allows you to periodically execute commands such as ps -e o netstat to observe on screen how processes or connections evolve over time.

Service management and overall system status

Many important processes in Linux are actually services or daemons that run in the background, such as web servers, databases or task schedulers. In modern systems with systemd, the central tool for managing these services is systemctl.

With systemctl start nombre_servicio You can start a service, while systemctl stop, restart y status They allow you to stop it, restart it, or view its current status. You can also enable or disable its automatic startup at system boot, which directly impacts which processes appear in the list after a reboot.

In older distributions or configurations that still use SysVinit, it is common to find the command service for managing services. Although in many cases it has been superseded by systemd, it is still useful as a compatibility layer for starting, stopping, or restarting specific daemons.

Beyond the services, it's worth having a global view of the state of the system. The command uptime It shows how long the machine has been on, how many users are connected, and the recent average load, giving a quick idea of ​​whether the system is comfortable or overloaded.

For a more detailed performance analysis, vmstat It provides statistics on CPU, memory, processes, and swap.While iostat It focuses on disk I/O, showing reads, writes, and response times of the devices. storageThese tools are invaluable for detecting whether problems originate from the CPU, RAM, disk, or a combination of all of them.

Combining all of the above—listing processes and LWPs with ps and /proc, real-time monitoring with top, htop, or atop, filtering with pgrep, control with kill, and tuning with nice, along with diagnostic utilities like strace and lsof—makes it possible to understand and control very precisely what is happening in a Linux system at any time, identify problematic processes and threads and keep performance in check even in demanding environments.