[Rubygems-developers] Slow gem Update

Farhan Ahmad farhan at thebitguru.com
Sun Aug 19 09:45:49 EDT 2007


Sorry, I should have started off with a time output.  Thanks for 
pointing this out Eric.  Here are my time output.

A basic gem list.
$ /usr/bin/time -v gem list -r

[...]

    A simulation/game with autonomous creatures
        Command being timed: "gem list -r"
        User time (seconds): 34.23
        System time (seconds): 2.52
        Percent of CPU this job got: 28%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:10.74
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 507
        Minor (reclaiming a frame) page faults: 19980
        Voluntary context switches: 8424
        Involuntary context switches: 19218
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

...and here is the output with an actual update. Note how this took 
almost 41 minutes.
# /usr/bin/time -v gem update
Updating installed gems...
Bulk updating Gem source index for: http://gems.rubyforge.org
Gems: [] updated
        Command being timed: "gem update"
        User time (seconds): 56.06
        System time (seconds): 19.18
        Percent of CPU this job got: 3%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 40:51.63
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 147876
        Minor (reclaiming a frame) page faults: 303281
        Voluntary context switches: 307667
        Involuntary context switches: 19396
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
#

...and here are the specs on this machine.
# hwd -s
HARDWARE DETECT ver 4.8.2 (simple mode)
  Kernel     : 2.6.20-ARCH
  CPU & Cache: Processor 0 is Pentium III (Katmai) 515MHz, 512 KB Cache

[...]

#

Apparently, it seems that the system only has 128MB RAM instead of the 
original 512MB that I was thinking.
# free -om
             total       used       free     shared    buffers     cached
Mem:           123        120          2          0         20         72
Swap:          956         84        872
# cat /proc/meminfo
MemTotal:       126072 kB
MemFree:          2176 kB
Buffers:         20616 kB
Cached:          74416 kB
SwapCached:       7984 kB
Active:          85792 kB
Inactive:        17432 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       126072 kB
LowFree:          2176 kB
SwapTotal:      979924 kB
SwapFree:       893748 kB
Dirty:            2748 kB
Writeback:           0 kB
AnonPages:        8096 kB
Mapped:          64828 kB
Slab:            12572 kB
SReclaimable:     3912 kB
SUnreclaim:       8660 kB
PageTables:       1160 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1042960 kB
Committed_AS:   281076 kB
VmallocTotal:   901112 kB
VmallocUsed:      6284 kB
VmallocChunk:   894544 kB



Thanks,

Farhan



Eric Hodel wrote:
> On Aug 18, 2007, at 23:21, Eric Hodel wrote:
>   
>> On Aug 18, 2007, at 14:28, Farhan Ahmad wrote:
>>     
>>>     I have been looking into why 'gem update' has been taking hours
>>> and hours on my computer to complete.  Given that it's only a 700Mhz
>>> machine with 512MB RAM I still didn't think that would qualify it  
>>> for such
>>> slow updates.
>>>       
>> How much RAM is it using?  I see about 120MB max with a bulk update
>> on OS X.
>>     
>
> Second data point, ~20 minutes and ~70MB resident on a machine that  
> should be at least an order of magnitude, possibly two, slower than  
> yours.
>
> CPU: Geode(TM) Integrated Processor by National Semi (266.66-MHz 586- 
> class CPU)
>    Origin = "Geode by NSC"  Id = 0x540  Stepping = 0
>    Features=0x808131<FPU,TSC,MSR,CX8,CMOV,MMX>
> real memory  = 134217728 (128 MB)
> avail memory = 126078976 (120 MB)
>
> $ /usr/bin/time -l gem list -r
>
> *** REMOTE GEMS ***
> Bulk updating Gem source index for: http://gems.rubyforge.org
>
> [...]
>       1223.66 real       508.13 user        62.21 sys
>       71700  maximum resident set size
>           3  average shared memory size
>       34417  average unshared data size
>         127  average unshared stack size
>      158228  page reclaims
>       51651  page faults
>           0  swaps
>          13  block input operations
>          40  block output operations
>           9  messages sent
>        1291  messages received
>       52739  signals received
>       51681  voluntary context switches
>      142100  involuntary context switches
>
> --
> Poor workers blame their tools. Good workers build better tools. The
> best workers get their tools to do the work for them. -- Syndicate Wars
>
>
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>   


More information about the Rubygems-developers mailing list