On Wed, 2006-03-08 at 09:14 -0800, Troy Engel wrote: > William (Bill) Triest wrote: > > > > I am not a kernel hacker, so I'm hoping you will end up with a more > > informed opinion, but it seems to me the real limiting factor would be > > IO. Disks are slow, and you claim you're writing to the disk. IMHO, an > > 800 MHz system should be able to handle ssh and gzip far easier then the > > IO. > > I concur -- gzip is a beast on the IO, this is most likely where your > perceived lag is. Install the "sysstat" RPM on your machine (and make > sure it's started) and let the 'sa' processes gather data for you. I think you mistake uncompressing for compressing. Compressing is usually CPU bound on most machines, and this is no exception. The volume of data being written is small (it's compressed) and the data being read is read from the network, not from disk. For fun, create a large tar file WITHOUT compression. Next, gzip it, and see whether vmstat shows 100% cpu utilization. Bet it will. The machine is writing only approx. 1MB/s and can sustain over 15MB/s raw I/O througput (when unloaded). The reason it is writing so little is because the kernel is stealing cpu cycles AWAY from gzip (and ssh). A quick test on another machine with the same cpu shows that raw gzip speed on that cpu (with similar data and same gzip options) should be about 5MB/s. Take 50% cpu away because the kernel is stealing it. Take 20% away for ssh (according to 'top'; it's doing decryption of all the data) you're left with 30%, which comes quite close to my 1MB/s estimate above. Another datapoint: vmstat is reporting 100% cpu utilization (split 50/50 between user and system), 0% idle, 0% iowait. The concern I have is that instead of burning cpu in user space (running gzip) it's burning it in kernel space (and even worse, the kernel function burning my cpu is default_idle!). Good suggestion with sysstat though, just to gather some more information about the problem. Maybe something will turn up. David