Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a VPS on Open-VZ, and the server is supposed to have 4 cores 3.0Ghz Xeon CPU. The usage is normally close to zero. When I compress a file (using zip, tar.gz, or 7z) it take too long for such CPU power.

What is the problem? And how can I get rid of it?


Folder Name: CentOS-6.2-x86_64-bin-DVD1to2

1) CentOS-6.2-x86_64-bin-DVD1.iso : 4.1 GB
2) CentOS-6.2-x86_64-bin-DVD2.iso : 1.2 GB
3) 6 Small files : 6.9 KB
Total 5.3 GB

Compression type: zip (using Ubuntu 10.04 integrated Archive Manager)
Compression time: 12 Minutes 55 Seconds

The server is said to have a Xeon CPU (4 Cores, 3.0 Ghz)
Available to me: 4 cores.

Memory available is 1GB, with "burst" (which is actually vSwap) another 1GB.

$ vmstat -s
  2097152 K total memory
   757260 K used memory
        0 K active memory
        0 K inactive memory
  1339892 K free memory
        0 K buffer memory
        0 K swap cache
        0 K total swap
        0 K used swap
        0 K free swap
    21980 non-nice user cpu ticks
       48 nice user cpu ticks
     4919 system cpu ticks
   850244 idle cpu ticks
    44279 IO-wait cpu ticks
        0 IRQ cpu ticks
        0 softirq cpu ticks
        0 stolen cpu ticks
 66334788 pages paged in
121362728 pages paged out
        0 pages swapped in
        0 pages swapped out
        0 interrupts
328969420 CPU context switches
1339502619 boot time
197583383 forks
share|improve this question

closed as not constructive by Sven, mdpc, Scott Pack, rnxrx, Magellan Oct 25 '12 at 2:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

So, maybe you can start by giving us some useful data. How about a range of files, their size, and the total time taken to compress. Also, how about data from sar, vmstat, etc. during the compression process. Also, can you confirm whether you mean the physical server on which your VPS is housed has 4 cores, or whether your VPS is entitled to use all of those 4 cores. – EightBitTony Jun 12 '12 at 12:11
I'll do that now. – wajed Jun 12 '12 at 12:14
"Computational performance on a virtualised server is less than expected" - This could be a generic question title, like "MySQL behaves in an unexpected way", or if a newspaper "Pope denounces gay marriage" – Tom O'Connor Jun 12 '12 at 12:51
That is because I don't know what the problem is. I'll edit the question as I get more pointers. – wajed Jun 12 '12 at 12:57
Please include the output from sar, iostat, or vmstat, running, during the compression. Not snapsnots, something like vmstat 1 50 – EightBitTony Jun 12 '12 at 13:13

Compression is very FPU intensive, they may not give you enough power to do that. It may make sense to do that locally or break it up into smaller files to compress

share|improve this answer

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