I started unarchiving a RAR file that this several gigabytes big. The computer is now going really slow, it's almost frozen. Sometimes I can move the mouse a little, but that's it. The unarchiving process seems to have halted, so now all I can do is restart the system. I don't think I can unarchive this file in Linux.

I never had this problem in Windows. How can this be fixed?

8 Answers 8


The slowdown is probably happening because of iowait. The ionice command should allow you to continue working:

ionice -c3 command

  • ionice -c 3 -n 7 command is better, where -n means priority levels from 0 to 7, and 0 presents the highest priority level, 7 is the lowest
    – Happy
    Sep 23, 2020 at 20:38

Try running the command with a lower priority using the nice utility. Uncompressing large files can be demanding on the CPU, hence why it is typically one of the tools used to measure performance in CPU benchmarks and reviews.


$ nice -15 ./myprogram

The number you specify is an adjustment of the default nice level. -20 being the highest priority and 19 being the lowest. Negative numbers are reserved for the root user.

  • You mean -20 being the lowest, not highest. :) Fixed it for you. Aug 4, 2010 at 5:06
  • Don't forget ionice command. Aug 4, 2010 at 6:57
  • @musicfreak I meant what I said... -20 is the highest priority you can give a process, not the lowest. Hence why only root can assign negative priorities because they have the highest precedence.
    – user1931
    Aug 5, 2010 at 0:36
  • Oh, I see. You should reword that sentence, then, because it doesn't make much sense as it stands. (Nevertheless, reverted, my mistake.) Aug 5, 2010 at 3:30
  • Does nice only work when running programs or does it work on programs that are already running?
    – Phenom
    Aug 15, 2010 at 6:51

I also had this same phenomenon but I think I have found the answer. I used to use unrar on 1 disk, reading and writing. Since this is a lot, all other processes got no time to work on the disk. Now I let unrar place the unpacked items onto another disk, not another partition, no another physical disk. It has several advantages:

  1. it goes much faster so the time you have a slower computer is less.
  2. the computer does not come to a halt as it did before, because it now reads on 1 disk and writes on the other. In other words the disks divide the total amount of work.

It's a simple solution, but it works.

  • Can you share an example command? Feb 18, 2021 at 10:47

I had a similar problem with a big .zip file (1.4 Gb) which contains almost 200.000 small files. My Ubuntu 13.10 64 bit would have taken over 10 hours. No freezes, the system doesn't really slow down, it is just that the uncompressing is incredibly slow.

I tried the virtual machine solution mentioned above, with Virtualbox and W7 64. Here comes the surprise:

1) at first, I shared the folder to the virtual machine and tried to unzip it there, in the same location (a virtual F: unit in W7) with 7-zip. No luck, same crappy speed which would take forever. 7-zip reported an initial output of 200 Kb/s, but it kept slowing down until I stopped it (less than 100 kb/s and an ETA of 7 hours, but it probably would have slowed down more and taken way longer).

2) then I moved the .zip file to inside the virtual machine's "hard disk drive" (what the vm believes to be a HDD). So the file was not in a shared folder with Ubuntu. Surprise, surprise, it works great, at around 2000 Kb/s output, so it took less than 15 minutes.

3) anecdotally, a 32-bit Windows 7 system (not a virtual machine) with exactly the same hardware took around one hour, with a stable output around 500 kb/s, according to 7-zip. I have no idea how the 32 to 64 bit change affects uncompressing of files, just thought it'd be good to mention to compare.

Ubuntu 13.10 64 bit with ext4, W7 with NTFS both the vm 64bit and the 32 bit normal system. What really bewilders me is the fact that the W7 vm is really using the underlying ext4 file system, because it is a vm, and still achieves those speeds.

I hope some gurus read this and figure this out, this is extremely annoying and intriguing.


I found the solution. I have a Windows virtual machine already installed in Linux. I shared the the folder where the archive is with the virtual machine. Then inside Windows, I unarchived the file using 7-zip and everything went smooth. It took a long time, but I didn't see any noticeable difference in system performance. 7-zip is not available for Linux. Windows can still be useful sometimes!


Unarchiving a big archive should not be a problem, you are just seeing symptoms of something else.

  • Is your Linux partition near its capacity? Like 95% full or more? If that's the case, then many filesystems (including ext3, ext4 and reiserfs) will get a lot slower.

  • Is the disk I/O speed otherwise OK in Linux? Will the programs start in reasonable time, does browsing around the directories with a file manager feel snappy or slow? Have you tried some benchmarking program, such as bonnie++ or ionice?

  • Does the unarchiver allocate all the available memory? See top while trying to unarchive that package.

Sometimes the default cfq disk I/O scheduler can lead to odd problems during the long-running disk activity bursts. You might try deadline or anticipatory schedulers instead. For example deadline tends to be quite good with database workloads, so it might work in this case, too.

echo deadline >/sys/block/sda/queue/scheduler


echo anticipatory >/sys/block/sda/queue/scheduler

Replace sda with the name of your hard disk.

This will be a temporary change and normally I would not recommend changing the cfq in desktop use, but if you are having other I/O problems than this unarchiving thing, it could be worth a shot. Unless all this is just because unrar ate up all the RAM... :-)


It's probably because you're out of RAM. You could repartition your hard drive to include a large swap partition, but that's about it, AFAIK.

  • I unarchived it successfully in Windows without having to upgrade RAM or mess with swap partitions.
    – Phenom
    Aug 4, 2010 at 4:58
  • It's unlikely RAM but rather a slow CPU. Aug 4, 2010 at 5:07
  • Hmm. If it's not a RAM problem, perhaps it would be easy to simply go to the gnome-system-monitor and give the unarchiving process a lower priority (higher number). Then, it won't slow the whole system down.
    – xsznix
    Aug 4, 2010 at 20:23
  • My CPU isn't slow. It has four cores.
    – Phenom
    Aug 5, 2010 at 3:37

So i've been experiencing a similar issue on Ubuntu 16.04. This answer seemed to work once, but then not again. Maybe it will help someone with a bit more understanding of what these fields do. Showing instructions below but it's taken directly from the answer referenced.

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

into /etc/sysctl.conf. Then

sudo sysctl -p

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .