Linux slows to a crawl when unarchiving a big file

Question

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?

Answer 1

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.

example:

$ 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.

Answer 2

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

ionice -c3 command

Answer 3

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!

Answer 4

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

or

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... :-)

Answer 5

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.

Answer 6

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.