DarkFame

Q: Large swap file (900MB), but no pageouts

My MacBook Air 13" with 4GB of RAM accumulates a large swap file over time, but pageouts are 0 (page ins: 1.1million). Anyone know why? Is it possible to see which process/application currently have pages stored in the swap file?

MacBook Pro 13", Mac OS X (10.6.5), Intel Core2 Duo 2.53GHz, 4GB DDR3

Posted on Jan 24, 2011 2:04 PM

Close

Q: Large swap file (900MB), but no pageouts

  • All replies
  • Helpful answers

Page 1 Next
  • by Whitecity,

    Whitecity Whitecity Jan 24, 2011 2:16 PM in response to DarkFame
    Level 2 (340 points)
    Jan 24, 2011 2:16 PM in response to DarkFame
    If you're not seeing any performance problems then don't worry about it. OSX is very good at managing the back end of this, and unless you're having issues leave well enough alone.
  • by DarkFame,

    DarkFame DarkFame Jan 24, 2011 2:23 PM in response to Whitecity
    Level 1 (0 points)
    Jan 24, 2011 2:23 PM in response to Whitecity
    No performance issues that I've noticed (and as I mentioned there are no pageouts, it's zero), but as my diskspace is 128GB I notice that the swapfile is about 1GB.
  • by noondaywitch,

    noondaywitch noondaywitch Jan 24, 2011 2:29 PM in response to DarkFame
    Level 6 (8,147 points)
    Jan 24, 2011 2:29 PM in response to DarkFame
    Fairly small as swap files go. Worry not, as long as you have sufficient free space for swap files (about 10-15% of the total disc capacity) there\s nothing to worry about.
  • by The hatter,

    The hatter The hatter Jan 24, 2011 2:46 PM in response to DarkFame
    Level 9 (60,935 points)
    Jan 24, 2011 2:46 PM in response to DarkFame
    Restart, and it should be back to default 64MB.
    Repair Permissions also.

    The way it use to work was create 64MB, then larger files, and you would have multiple swap files.
  • by DarkFame,

    DarkFame DarkFame Jan 24, 2011 3:44 PM in response to The hatter
    Level 1 (0 points)
    Jan 24, 2011 3:44 PM in response to The hatter
    Reboot is not an option.
  • by Whitecity,

    Whitecity Whitecity Jan 24, 2011 3:54 PM in response to DarkFame
    Level 2 (340 points)
    Jan 24, 2011 3:54 PM in response to DarkFame
    Then learn to live with it.
  • by Lyssa,

    Lyssa Lyssa Jan 24, 2011 4:02 PM in response to DarkFame
    Level 6 (17,893 points)
    Jan 24, 2011 4:02 PM in response to DarkFame
    DarkFame wrote:
    Reboot is not an option.


    Surely you don't mean you never restart your computer. I can understand rebooting being somewhat inconvenient, or not being the answer you like, but a restart is the only way to clear out the swap files.

    ~Lyssa
  • by The hatter,

    The hatter The hatter Jan 24, 2011 4:22 PM in response to DarkFame
    Level 9 (60,935 points)
    Jan 24, 2011 4:22 PM in response to DarkFame
    My point, which seems to have been too deep, was only by restart, and seeing if it was normal single 64MB swap file in /Var would you know if it is normal or not, or something else.

    So do it, part of the normal trial and error of troubleshooting anything and everything, and monitor the behavior and symptoms.

    900MB and a single swap file was never normal, not with one file, and not with zero page outs.

    Laptops do have a hibernation file which if memory serves me right is normal and is the same size (4GB in your case) of the amount of installed physical RAM. Not sure where it is stored, probably hidden though ".hibernate" or something.

    http://www.apple.com/support/macbookair/
    http://www.apple.com/support/macosx
  • by Lyssa,

    Lyssa Lyssa Jan 24, 2011 4:36 PM in response to The hatter
    Level 6 (17,893 points)
    Jan 24, 2011 4:36 PM in response to The hatter
    Hatter,

    The file is stored in the same place as the swapfiles in a file named "sleepimage." At least, this is the case in 10.5. I would assume the same is true for 10.6.

    ~Lyssa
  • by DarkFame,

    DarkFame DarkFame Jan 25, 2011 11:52 AM in response to Lyssa
    Level 1 (0 points)
    Jan 25, 2011 11:52 AM in response to Lyssa
    I already knew that a reboot would solve the problem. Of course I reboot at times (for example updates requring a reboot). The files in /var/vm are correct in size, starting at 64MB and doubling as a new swapfile is created. I see now that I shouldn't have typed swap file, but total swap size. My mistake

    Message was edited by: DarkFame
  • by ajduguid,

    ajduguid ajduguid Jan 25, 2011 12:14 PM in response to DarkFame
    Level 3 (650 points)
    Jan 25, 2011 12:14 PM in response to DarkFame
    Well you've made me curious now. What are you doing on a MacBook Air, a device surely aimed at portability, that means rebooting isn't an option? It isn't exactly the first device that would spring to mind if you're looking for something to be running all the time.
  • by DarkFame,

    DarkFame DarkFame Jan 25, 2011 1:09 PM in response to ajduguid
    Level 1 (0 points)
    Jan 25, 2011 1:09 PM in response to ajduguid
    I hope you noticed the smiley behind the comment "reboot is not an option".
  • by filker0,

    filker0 filker0 Feb 27, 2011 8:31 AM in response to DarkFame
    Level 1 (0 points)
    Feb 27, 2011 8:31 AM in response to DarkFame
    I don't know a lot about OS X 10.6 internals, but I do have an idea why you have the page-ins but no page-outs.

    Many "modern" operating systems do not load an entire executable image when a program is started; instead, they set up the page tables for the process such that the backing store for all ".text" segment data (that is, the instructions and read-only data) is the program image file. Read-write segments are copied from the program image file into RAM and have their backing store set to indicate that there is no current backing store and that they are modified (dirty), and the "blank" (or .bss) is created in the page tables and marked as "zero" and "clean" with no current backing store.

    The Task Control Block (or the local OS equivalent) is then set to "ready", and when the task gets control, a page fault occurs that the OS then interprets as "load the page", and more pages of instructions are loaded as needed. When a page is reclaimed (swapped out), if it's not been modified (not dirty), it is simply marked as non-resident in the page tables without writing to to the swap file; the OS will read it back from the image file the next time it needs it. For modified (dirty) pages, such as the read/write data segments, the OS sees that the page is dirty, allocates a page in the swapping file, writes the data to the backing store, and marks the page table entry as non-resident with the location of the backing store. For the initial accesses to the ".bss" segment, the page fault handler notes that the page is "zero", so it finds a page of physical memory, sets the page table entry as resident and clean, and zeros out the memory before returning control to the process. Once such a page is modified, it is treated exactly like the initialized read/write segment (.data) pages. (In some systems, the .bss is not distinguished from the initialized data, but this varies by OS.)

    The above scheme means that only read/write data (code being non-writable unless you're debugging) ends up in the swap file. With a page-out strategy that uses LRU (least recently used), and is weighted toward clean page page-out (that is, pages that are already in the backing store and don't have to be written out), you're going to see mostly instruction pages going non-resident; and even if you never discard a clean page within a process lifetime, just loading and executing the program is counted as page-ins.

    So, given the above model, millions of page-ins with no page-outs is quite normal.

    I hope this is both clear enough and accurate.
  • by nalundgaard,

    nalundgaard nalundgaard Jul 13, 2012 7:38 PM in response to filker0
    Level 1 (5 points)
    Jul 13, 2012 7:38 PM in response to filker0

    Sorry to dig this old thread up, but I am seeing an identical behavior to the original poster, and I just wanted to say—you did an excellent job of explaining how page ins can be very large with no pageouts, but I don't think this explains the real mystery, which is that there is a large amount of swap space, and a large amount the system says is used, but there are no page outs. You have not explained how a swap file gan grow in usage with no page outs, and if I understand things correctly, this should not be possible.

     

    I'm having the same issue on my new MacBook Pro with Retina display. I have 16GB of RAM and for the most part I don't use more than 4-6GB of that—I bought it for the occasional times I need to do a lot of VM testing, but I haven't needed to do that yet. I consistently see my swap usage grow to be as large as 2-3GB with a total size for all the swapfiles in /var/vm being 3-4GB.

     

    I don't need the space, and the system isn't slow or anything. I just want to know how this is possible. I have been using Mac OS X for 10 years now, and working on linux servers for 5 years or so. I've never seen swap usage be more than 0KB when there are no page outs.

     

    I've attached some screenshots of what I am seeing:

     

    weird-swap-usage.png

    Screen capture from Activity Monitor.


    swap-file-space.png

    Screen capture from Terminal executing 'du -hsc /var/vm/swapfile*' to tally the total size of the swapfiles.

     

    I should note that it tends to take a day or two of use to start to see this, in a series of sleep cycles here and there. I put my laptop to sleep at night as well as to and from work, etc. It probably sleeps/wakes 5-7 times a day in all. I tend to notice that the usage creeps up, starting atound 50 MB, then I will notice it being a few hundred some time later. It really makes me wonder if this has to do with some kind of discrete vs. dedicated graphics switching or something, perhaps a very low level operation that is somehow avoiding getting counted by the system's resource tracking facilities. I have no idea, but I would love it if there were someone out there who could explain it or point me in the right direction.

     

    Thanks for your time.

Page 1 Next