Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
add comment

7 Answers

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.

share|improve this answer
    
I unarchived it successfully in Windows without having to upgrade RAM or mess with swap partitions. –  Phenom Aug 4 '10 at 4:58
    
It's unlikely RAM but rather a slow CPU. –  Sasha Chedygov Aug 4 '10 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 '10 at 20:23
    
My CPU isn't slow. It has four cores. –  Phenom Aug 5 '10 at 3:37
add comment

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.

share|improve this answer
    
You mean -20 being the lowest, not highest. :) Fixed it for you. –  Sasha Chedygov Aug 4 '10 at 5:06
    
Don't forget ionice command. –  Janne Pikkarainen Aug 4 '10 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. –  John T Aug 5 '10 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.) –  Sasha Chedygov Aug 5 '10 at 3:30
    
Does nice only work when running programs or does it work on programs that are already running? –  Phenom Aug 15 '10 at 6:51
show 1 more comment

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!

share|improve this answer
    
Check out p7zip: p7zip.sourceforge.net –  John T Aug 5 '10 at 4:03
add comment

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

share|improve this answer
add comment

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

ionice -c3 command

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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