Who’s hogging the network? Bandwidth usage on a Linux system

There are a lot of reasons why systems slow down.

Some process might be bogging down the CPU, you may be seeing a lot of disk contention, or maybe memory is in high demand and a lot of swapping is going on. Then again, the system may be slowed down because of network bandwidth contention.

Like a busy door with too many people wanting to enter and exit at the same time, a system’s network connection can represent a serious limiting factor in how well it performs. That said, if you’re looking for good, real-time insights on how a system is using its network bandwidth — in particular which processes may be using far more than their fair share — you’re going to have a hard time beating nethogs.

What is nethogs?

Different than commands such as iftop (for checking bandwidth usage), netstat (for looking at interface statistics), and top (for examining process resource usage as well as CPU and memory usage), the nethogs command provides real-time bandwidth per process statistics that can help you nail down and resolve network interface contention problems.

This open source, command-line tool lets you spot right away what process is responsible when you notice that your network interface is bogged down and you want to pin down what’s going on.

Getting nethogs

The nethogs tool is very likely already installed on your system. It’s included in most Linux distributions today. A quick which nethogs command will let you know for sure. If it isn’t installed, a sudo yum install nethogs of sudo apt install nethogs command will quickly set it up for you. As with tools like top, nethogs runs on the command line, but it requires that you use sudo or run as root.

Using nethogs

Using nethogs is easy, but there are some options worth looking into.

For one thing, you can have the stats updated less frequently than the default once/second with -d option if you’d like to slow things down a bit.Example:

Example: nethogs -d 5

The -r and -s options allow you to sort by the sent or received values instead of overall bandwidth.

If you have multiple network interfaces and just want to examine one of them, use a command such as nethogs eth0. You can specify more than one interface with this option if you like (e.g., nethogs eth0 eth1). The default is to look at all of them.

The output from nethogs will look something like this:

NetHogs version 0.8.5-2

    PID USER   PROGRAM                    DEV      SENT    RECEIVED
   6245 _apt   ..sr/lib/apt/methods/http  enp0s2    0.977    36.629 KB/sec
   6244 _apt   ..sr/lib/apt/methods/http  enp0s2    0.786    18.305 KB/sec
   6243 _apt   ..sr/lib/apt/methods/http  enp0s2    1.507     3.018 KB/sec
   2837 shs    /usr/lib/firefox/firefox   enp0s2    0.403     0.711 KB/sec
   5949 shs    sshd: shs@pts/2            enp0s2    3.368     0.627 KB/sec
   6183 root   dirmngr                    enp0s2    0.000     0.000 KB/sec
      ? root   ..2.168.0.26:46186-91.189            0.000     0.000 KB/sec
      ? root   ..2.168.0.26:48030-91.189            0.000     0.000 KB/sec
   6169 root   /usr/bin/python3           enp0s2    0.000     0.000 KB/sec
      ? root   unknown TCP                          0.000     0.000 KB/sec

  TOTAL                                             7.040    59.290 KB/sec

This should all be fairly straightforward — PID, username, process, and network interface, followed by the bandwidth consumed in both the outgoing and incoming directions. The summary line gives you an easy view of how the outgoing and incoming data flows compare.

As you can see, the name of the process that is running is truncated). The network interface may also be truncated (as it is in the example above where the interface is actually enp0s25).

Looking more closely, you will also likely notice that two of the lines in the output above show a truncated rendition of the IP addresses and ports for two of the connections. Were the PROGRAM column wider, we might see something like “192.168.0.26:46186-91.189.11.12:80“.

You can also use trace mode with the -t option to watch network connections as they occur.

shs@stinkbug:~$ sudo nethogs -t
[sudo] password for shs:
Adding local address: 192.168.0.26
Adding local address: fe80::5408:90e7:c23d:6bae
Ethernet link detected
Waiting for first packet to arrive (see sourceforge.net bug 1019381)

Refreshing:
unknown TCP/0/0 0       0

Refreshing:
sshd: shs@pts/0/8130/1000       0.114063        0.0234375
unknown TCP/0/0 0       0

Refreshing:
sshd: shs@pts/0/8130/1000       0.185156        0.0351562
unknown TCP/0/0 0       0

The nethogs output above shows fairly modest network usage. The system is working, but not working up a sweat. If the total bandwidth is considerably higher, you might want to look more deeply into what’s going on. But, as I’ve said before, knowing how your system normally works is key to understanding when it’s under unusually high demand. The data below would indicate a considerably busier system with respect to its network usage.

NetHogs version 0.8.5-2
  PID USER   PROGRAM                          DEV      SENT    RECEIVED       
?     root   192.168.0.11:2049-192.168.0.2:67        406.888  559.587 KB/sec
2861  jdoe   /usr/bin/gnome-shell             eth1     0.264    2.196 KB/sec
?     root   unknown TCP                               0.000    0.000 KB/sec

  TOTAL                                              407.196  561.816 KB/sec 

Wrap-Up

The nethogs command is a great tool for looking at one important aspect of system performance. It can be used with other important commands to get a clear idea how systems are working and can be invaluable in nailing down performance problems when the network interface is what’s slowing things down.