Using the nethogs command in Linux

Nethogs is a command line utility for linux that displays the network bandwidth used by each application or process in realtime. It is useful in situations when a certain process uses up too much of the bandwidth and needs to be caught.

Project website

The website describes the tool as

NetHogs is a small 'net top' tool. Instead of breaking the traffic down per protocol or per subnet, like most tools do, it groups bandwidth by process. NetHogs does not rely on a special kernel module to be loaded. If there's suddenly a lot of network traffic, you can fire up NetHogs and immediately see which PID is causing this. This makes it easy to indentify programs that have gone wild and are suddenly taking up your bandwidth.

Install Nethogs on Ubuntu/Debian/Mint

Debian and related distros like Ubuntu and Mint already have nethogs in their repositories so its a single step installation via the apt command.

sudo apt-get install nethogs

Install Nethogs on CentOS/Fedora

On Fedora nethogs is available in the fedora repository, so install it from yum directly.

$ sudo yum install nethogs

On CentOS the default repositories do not have nethogs, but can be installed from the epel repositories. So first enable epel repository and then use yum command like shown above.

Using Nethogs

Nethogs is quite simple to use. Just run nethogs with root privileges and it would show the bandwidth used by each process.

$ sudo nethogs

The output would be something like this

NetHogs version 0.7.0

  PID USER     PROGRAM                      DEV        SENT      RECEIVED       
2367  enlighten/opt/google/chrome/chrome    eth0       3.341      20.948 KB/sec
2196  enlighten/usr/lib/firefox-7.0.1/fire  eth0       0.871       0.422 KB/sec
3723  enlighten/usr/bin/pidgin              eth0       0.028       0.098 KB/sec
2206  enlighten/usr/bin/skype               eth0       0.033       0.025 KB/sec
2380  enlighten/usr/lib/chromium-browser/c  eth0       0.000       0.000 KB/sec
0     root     unknown TCP                             0.000       0.000 KB/sec

  TOTAL                                                4.274      21.493 KB/sec

It shows the PID, username, process, network interface being used, data sending speed and data receiving speed.

Other options

$ nethogs -h
usage: nethogs [-V] [-b] [-d seconds] [-t] [-p] [device [device [device ...]]]
                -V : prints version.
                -d : delay for update refresh rate in seconds. default is 1.
                -t : tracemode.
                -b : bughunt mode - implies tracemode.
                -p : sniff in promiscious mode (not recommended).
                device : device(s) to monitor. default is eth0

When nethogs is running, press:
 q: quit
 m: switch between total and kb/s mode

Change the update delay

The frequency at which nethogs updates the data can be changed using the d switch. Lets say we want nethogs to update every 5 seconds, then issue the following command

$ sudo nethogs -d 5

Use specific device

Nethogs supports the option to specify the device to monitor on. For example

$ sudo nethogs eth0

If no device is specified, the nethogs monitors the default device on the system. To monitor multiple devices simply add the device names together.

$ sudo nethogs eth0 eth1


In trace mode it outputs the connections one by one. Check the following example.

$ sudo nethogs -t
[sudo] password : 
Adding local address:
Ethernet link detected
Waiting for first packet to arrive (see bug 1019381)

unknown TCP/0/0 0       0

/usr/lib/firefox-7.0.1/fire/2196/1000   0.771094        0.119922
unknown TCP/0/0 0.0105469       0.0117188
Unknown connection:

/usr/lib/firefox-7.0.1/fire/2196/1000   0.781641        0.232617
unknown TCP/0/0 0.0105469       0.0117188
Unknown connection:

/usr/lib/firefox-7.0.1/fire/2196/1000   0.781641        0.232617
unknown TCP/0/0 0.0105469       0.0117188
Unknown connection:

/usr/lib/firefox-7.0.1/fire/2196/1000   0.781641        0.232617
unknown TCP/0/0 0.0105469       0.0117188
Unknown connection:

/usr/bin/pidgin/3723/1000       0.0115234       0
/usr/lib/firefox-7.0.1/fire/2196/1000   0.0105469       0
unknown TCP/0/0 0       0
Unknown connection:

Nethogs also supports promiscuous mode with the p flag.

Selecting a PHP Handler for Apache

PHP handlers are a link between a webserver(say Apache) and the PHP libraries. PHP handlers enable a webserver to load the PHP library in a certain manner and execute the PHP code and return the output to the webserver.

There are many different kind of PHP handler setups available. Each has its own advantages and disadvantages.

Mod_php (DSO)

modphp or the Apache 2 Handler is a apache module for running PHP scripts. modphp runs PHP in a persistent manner like fastcgi. modphp runs all PHP as the Apache user or “nobody”. It keeps worker processes running instead of starting and stopping PHP. There are file permission issues since files belong to the user nobody.

Opcode cache engines like APC and eAccelerator will work with mod_php since it keeps persistent workers alive.
mod_php is faster than CGI , fastCGI , and mod_suphp.


CGI runs PHP scripts as CGI module , instead of Apache module. CGI by default will run the scripts as the Apache/nobody user. However if suexec is installed then the scripts will be run as the user of the website/account. CGI is slow compared to modphp, because for every request “PHP” is started and stopped.

Opcode caching solutions will not work with CGI.


Suphp is an apache module (mod_suphp) and it also runs php scripts as CGI. suphp does not need configuration for each virtual host. It simply runs a php script with the user permissions of the owner. suphp is much slower than mod_php (upto 25 times) and even CGI. However it might be faster than suexec. suphp is easy to setup and is secure in the sense that it keeps track of which user executed the script. Since it requires little configuration it is quite popular with cPanel hostings.

Since suphp starts a PHP process upon each request, it cannot work with any opcode caching solution like APC or eAccelerator. Also suphp does not support FastCGI. It uses no resources when no pages are being requested. Ideal for low traffic websites.


Documentation :

mod_fastcgi is an Apache module that uses FastCGI to run the PHP scripts. FasCGI is faster than CGI and nearly as fast as modphp. It save CPU usage but uses more memory since it keeps PHP processes alive in background to process requests, instead of starting new processes.

Opcode cache engines like APC and eAccelerator can be used with fastcgi since it keeps persistent processes.


Suexec is an Apache module (mod_suexec) that allows CGI scripts to run as a particular user. Suexec needs the user to be configured for each virtual host. suexec is slower than mod_php and mod_suphp. suexec can be used with mod_fastcgi.

Conclusion :

Modphp is ideal for moderate traffic websites, whereas suphp can be used on low traffic websites.
For high traffic websites FastCgi should be considered as it can handle multiple requests better than the rest.
suphp and fastcgi are more secure compared to modphp and plain cgi.

Using the fastest DNS servers

The speed of your internet browsing depends on the dns servers to a certain extent. Whenever a url is opened in the browser, the browser has to first perform a dns request to get the ip address of that particular url’s domain name. For example It is only after the ip address is found, can the browser proceed further with loading the web page by sending http requests.

So the speed factor depends on how fast the dns server responds with the ip details. Now it is understood that the browser/system already knows the ip address of the dns servers (otherwise how would it contant them). The most commonly used dns servers are :

1. Opendns –
2. Google dns –
3. Your isp’s dns servers

The main factor on which the speed of the dns server depends is, that how far is it from your computer in terms of network hops. If you are somewhere in India, then a server in Singapore will be nearer than a server in the US. This distance can be found out by doing a traceroute to the target system. More the hops, farther away it is.

To measure the speed of the dns server, all that needs to be done is to find out its response time. This can be done very easily using the ping command in the terminal/console. So lets ping each of the dns servers listed above one by one and see their ping response times.

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=52 time=362 ms
64 bytes from icmp_req=3 ttl=52 time=362 ms
64 bytes from icmp_req=4 ttl=52 time=362 ms
64 bytes from icmp_req=5 ttl=52 time=362 ms

So the opendns server has a ping response time of 362ms. Ok, lets try the next one.

Google Dns server

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=57 time=128 ms
64 bytes from icmp_req=2 ttl=57 time=132 ms
64 bytes from icmp_req=3 ttl=57 time=127 ms
64 bytes from icmp_req=4 ttl=57 time=129 ms
64 bytes from icmp_req=5 ttl=57 time=131 ms

Google dns server have a ping response time of around 130ms average. Now that is nearly 3 times faster than the open dns server. Many articles out there talk about using opendns for improving dns speed, but first the speed has to be tested, since opendns may not always be the fastest one.

My isp dns –

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=251 time=6.30 ms
64 bytes from icmp_req=2 ttl=251 time=6.16 ms
64 bytes from icmp_req=3 ttl=251 time=6.01 ms
64 bytes from icmp_req=4 ttl=251 time=6.45 ms
64 bytes from icmp_req=5 ttl=251 time=6.25 ms

ISP dns server has a ping response time of around 6.5ms. This is the fastest so far and around 20 times faster than even google dns. This is because this dns server is located very near (may be in same city) to my internet connection.