Don’t be alarmed by super large VSIZE on OS X

(Also at https://github.com/urbancoding/jenx/issues/32)

Don’t freak out too much if 64-bit processes on OS X have a VSIZE of 10 GB or more.

    marca@SCML-MarcA:~$ cat macruby_test.rb 
    print "What's your name? "
    name = gets.chop
    puts "Hi, #{name}!"

    marca@SCML-MarcA:~$ psgrep macruby
    USER    PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
    marca 76551   0.0  0.3 10899176  12272 s004  S+    9:09PM   0:00.06 macruby macruby_test.rb

    marca@SCML-MarcA:~$ top -pid 76551 -l 1 | tail -2
    PID    COMMAND %CPU TIME     #TH #WQ #PORTS #MREGS RPRVT  RSHRD RSIZE VPRVT VSIZE PGRP  PPID  STATE    UID       FAULTS COW  MSGSENT MSGRECV SYSBSD SYSMACH CSW PAGEINS USER 
    76551  macruby 0.0  00:00.06 1   0   40+    131+   5640K+ 15M+  12M+  323M+ 10G+  76551 72846 sleeping 346486362 3266+  189+ 234+    115+    254+   157+    35+ 0       marca

What this shows is a ridiculously simple Ruby program (running under MacRuby) having a VSIZE of 10 GB.

OTOH, Activity Monitor shows up a much more sane “Virtual Mem” of 315.0 MB for this process:

http://cl.ly/3F3N0P2M0l2O3q0b280Y

Also, vmmap seems to indicate that most of the virtual memory comes from “reserved VM address space (unallocated)” and it seems to consider this as unimportant:

    marca@SCML-MarcA:~$ vmmap 76551
    Virtual Memory Map of process 76551 (macruby)
    Output report format:  2.2  -- 64-bit process
    
    ...
    
    ==== Summary for process 76551
    ReadOnly portion of Libraries: Total=68.5M resident=59.0M(86%) swapped_out_or_unallocated=9792K(14%)
    Writable regions: Total=8.1G written=5068K(0%) resident=5164K(0%) swapped_out=0K(0%) unallocated=8.1G(100%)
    
    REGION TYPE                      VIRTUAL
    ===========                      =======
    MALLOC                            286.3M        see MALLOC ZONE table below
    MALLOC (reserved)                   7.8G        reserved VM address space (unallocated)
    ...
    ===========                      =======
    TOTAL                               8.2G
    TOTAL, minus reserved VM space    463.3M

                                         VIRTUAL ALLOCATION      BYTES
    MALLOC ZONE                             SIZE      COUNT  ALLOCATED  % FULL
    ===========                          =======  =========  =========  ======
    auto_zone_0x100bbd000                 256.0M      10635       680K      0%
    DefaultMallocZone_0x100b5b000          29.2M      28569      3207K     10%
    DispatchContinuations_0x100bfe000      1024K          1         32      0%
    ===========                          =======  =========  =========  ======
    TOTAL                                 286.3M      39205      3887K      1%

This issue, by the way, is not specific to MacRuby (my initial suspicion). I saw a similar pattern with Xcode, which also has a VSIZE of around 11 GB. I did not see this pattern with MRI Ruby [ruby 1.9.3p0 (2011-10-30 revision 33570)], Mail.app, Finder, iTerm, Alfred, Safari, or mysqld — these apps all have a much lower VSIZE of around 3 or 4 GB each. I have no idea why.

OS X appears to “reserve” a large amount of virtual memory for 64-bit processes, but they are not necessarily using it just because it’s been reserved for them.

3 thoughts on “Don’t be alarmed by super large VSIZE on OS X

  1. Pingback: See details of an app’s virtual size | On weighted, bloom filter-based congestion-control protocols

  2. Pingback: See details of an app’s virtual size « Registry Fix Blog

  3. Pingback: Witch and RAM usage—both real and not so real · Tales of a Running Bird

Leave a Reply

Your email address will not be published. Required fields are marked *