I have been wondering this for quite a while, thought I might give a shot asking it here.


  1. I use an application that used a lot of resources (for example image batch processing or compiling/running a lot of apps)

  2. Close the resource-hungry apps

  3. Ubuntu still significantly slower than before the resource-hungry apps were started*

* I mean, 'top' indicates low cpu usage, until I do something (as trivial as opening a tab or something) and my cpu usage spikes instantly. I noticed this on a multiple of Ubuntu boxes I own.

A reboot is the only solution I found. What's the reason behind this?

EDIT: a bit more info about my laptop: Dell Studio 1558, Intel i5, 8GB DDR3 Ram, 7200 rpm HDD

  • 1
    Have you checked your what processes are hogging your resources (maybe with the top command) and then killing them manually? They might still be hogging it even after they are closed (it happens sometimes, processes go rogue). – Nitin Venkatesh Dec 18 '11 at 12:54
  • You haven't noted your processor's type, hardware info, or anything, so I've given a rather general answer. I could expand if you give more detail. – RolandiXor Dec 18 '11 at 13:02
  • @nitstorm: I have tried killing the processes, I don't think it has to do with rogue processes. – RVH Dec 18 '11 at 13:18
  • @RolandTaylor I added some hardware specs to the original post. Thanks! – RVH Dec 18 '11 at 13:18

This is indeed a typical situation and the most likely cause is memory swapping. Look at the memory usage.

Your resource-hungry task A has probably used a significant amount of RAM. Consequently, an other application B has been swapped to disk. The CPU can quickly change it context back from A to B, you should not feel any delays caused the CPU load after quitting A. However, application B is no longer completely hold in physical RAM. Thus, a trivial tasks inside A may require loading the memory used by application A back into the physical RAM.

A similar situation occurs when the the resource-hungry task reads and writes many/large files from/to the HDD since Linux generally uses memory to cache disk I/O. (That means, task A will quit before the files have been committed to the physical HDD. The slow writing process is delayed until Linux needs to free memory for other applications.)

Both processes (swapping and disk caching) are I/O-bound (limited by your HDD read/write rate, not the CPU). However, they may cause a certain computational overhead.

Theoretically, some time after quitting A, application B should automatically come back to normal speed. Instead of rebooting it may help to restart application B.

  • Well, I have 8GB of RAM, your answer seems logical. However it is annoying the amount of time it needs to be fully responsive again, especially things like switching workspaces etc – RVH Dec 18 '11 at 13:20

There are several likely causes for this. If you have a single core processor and relatively low RAM this is even more likely to happen.

What is probably happening is:

  • Your system begins to use swap when the RAM becomes overloaded, it might be "thrashing" (dumping RAM to the disk) before you close the heavy applications, and then has a hard time recovering.
  • You might be experiencing high levels of I/O wait (the processor waiting on a response).
  • The heavy applications you quit be getting cleaned up. The best thing to do is to leave the system for a bit - and wait for it to recover.

Tweaking the swappiness value might help if your system is swapping too aggressively. It won't help if you're actually running out of memory and the kernel is forced to swap, but if you have enough memory and the kernel is starting to swap unnecessarily, it can.

See the Ubuntu SwapFaq. Excerpt below:

The swappiness parameter controls the tendency of the kernel to move processes out of physical memory and onto the swap disk. Because disks are much slower than RAM, this can lead to slower response times for system and applications if processes are too aggressively moved out of memory.

  • swappiness can have a value of between 0 and 100
  • swappiness=0 tells the kernel to avoid swapping processes out of physical memory for as long as possible
  • swappiness=100 tells the kernel to aggressively swap processes out of physical memory and move them to swap cache

The default setting in Ubuntu is swappiness=60. Reducing the default value of swappiness will probably improve overall performance for a typical Ubuntu desktop installation. A value of swappiness=10 is recommended, but feel free to experiment. Note: Ubuntu server installations have different performance requirements to desktop systems, and the default value of 60 is likely more suitable.

  • Thanks! I have changed my value to 10, I rather have the processes take some more time, than to have an unresponsive desktop, I will report my findings later on – RVH Dec 18 '11 at 16:16

There is a similar question about consuming all memory here.

As one answered,

It seems that once Ubuntu starts using swap, it doesn't release RAM easily even after the operation is finished.

To force system to release everything in swap partition back to memory, there are many similar answers to do this:

According to the answers above, you can clear swap by:

sudo swapoff -a
sudo swapon -a

This disables swap during which anything in swap is transferred in RAM and re-enables it. Computer's performance should be back to normal now.

For more information about swapoff and swapon, see the man page in the following link:

Ubuntu Manpage: swapon, swapoff - enable/disable devices and files for paging and swapping

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.