DEPRECATED Pantheon

Bug #574910
Comment #30

Comment 30 for bug 574910

Revision history for this message

Chris (nakota07) wrote on 2010-07-30:

#30

Not that this will do much to track down the issue, but I have some more case history.

Today I was tidying up some vdi disks on my host system (work system running 10.04 w/ 2.6.31-17 on Core2 Duo E6750 2.66GHz 4GB ram). A disk to disk (two physical disks) copy of a 7.5GB vdi caused the load average to climb up to about 8 today. An rzip of the vdi image caused the load average to climb to about 6. It slowed down the primary system, and the virtual boxes. The system s that shared the spindle where the data was being compressed was worst of all (obviously). All systems were sluggish but not unusable.

So I bought the vdi image home. My home system (black) is an AMD Athlon(tm) II X2 250 Processor at 3GHZ with 4 GB of ram and two 250GB (hardware) mirrored disks where Ubuntu 9.10 w/Kernel 2.6.31-20 lives. During the entire time that rzip was running the load average never went about 1.7. When it was finished it sank very fast to 0.14 whereas on my work system after a peak it takes about 3 min to reach a "normal" level of load of at least . I know this is kind of like comparing apples to hammers. I don't have a "pure" 10.04 system at work or at home that has enough disk space free do uncompress a 7gb image with out doing some work to create a new disk and attach it to an existing system.

So I did the next best thing I could come up with. On Violet (guest on black) my 10.04 that has not had the kernel retrograded, I did a tar of a folder containing 1.9GB of PDFs, images, mp3s, text, etc. Almost instantly violet went from 1.03 to 3.83. Firefox had ha hard time keeping up with my typing and right clicking for spelling checks. It took from 21:34 to 21:38 (while I was doing nothing but watching top) for the loadavg1 to drop from 3.72 to 1.08. I then did an rzip on the tar file. at 21:40 with a loadavg1 of 1.29 I started the test. It is with great interest that I only saw the loadavg1 go to about 4.33 (max) but the system was far more sluggish (a right click was a 4-5 second delay) and top would freeze up for several updates (2s/update) and then rush to catch up. It sopped zipping at 22:01. Watching top I saw most of the time %us was between 40 and 70, %sys was about 5-15. The amount of time needed to rzip the smaller 2GB of data was much longer (many minuets) than it took to unrzip 7gb of data. I know that zip and unzip are not symmetrical, but 20 minuets to about 5 and only dealing with about 28% of the data? It just doesn't seem right.

Not that this will do much to track down the issue, but I have some more case history.

Today I was tidying up some vdi disks on my host system (work system running 10.04 w/ 2.6.31-17 on Core2 Duo E6750 2.66GHz 4GB ram).   A disk to disk (two physical disks) copy of a 7.5GB vdi caused the load average to climb up to about 8 today.  An rzip of the vdi image caused the load average to climb to about 6.  It slowed down the primary system, and the virtual boxes.  The system s that shared the spindle where the data was being compressed was worst of all (obviously).  All systems were sluggish but not unusable.

So I bought the vdi image home.  My home system (black) is an AMD Athlon(tm) II X2 250 Processor at 3GHZ with 4 GB of ram and two 250GB (hardware) mirrored disks where Ubuntu 9.10 w/Kernel 2.6.31-20  lives.  During the entire time that rzip was running the load average never went about 1.7.  When it was finished it sank very fast to 0.14 whereas on my work system after a peak it takes about 3 min to reach a "normal" level of load of at least .    I know this is kind of like comparing apples to hammers.   I don't have a "pure" 10.04 system at work or at home that has enough disk space free do uncompress a 7gb image with out doing some work to create a new disk and attach it to an existing system.

So I did the next best thing I could come up with.  On Violet (guest on black) my 10.04 that has not had the kernel retrograded, I did a tar of a folder containing 1.9GB of PDFs, images, mp3s, text, etc.   Almost instantly violet went from 1.03 to 3.83.  Firefox had ha hard time keeping up with my typing and right clicking for spelling checks.  It took from 21:34 to 21:38 (while I was doing nothing but watching top) for the loadavg1 to drop from 3.72 to 1.08.  I then did an rzip on the tar file.  at 21:40 with a loadavg1 of 1.29 I started the test. It is with great interest that I only saw the loadavg1 go to about 4.33 (max) but the system was far more sluggish (a right click was a 4-5 second delay) and top would freeze up  for several updates (2s/update) and then rush to catch up.  It sopped zipping at 22:01.   Watching top I saw most of the time %us was between 40 and 70, %sys was about 5-15.  The amount of time needed to rzip the smaller 2GB of data was much longer (many minuets) than it took  to unrzip 7gb of data.    I know that zip and unzip are not symmetrical, but  20 minuets to about 5 and only dealing with about 28% of the data?  It just doesn't seem right.