Absolutely Ridiculous Virtual Memory Size in Leopard...
http://farm3.static.flickr.com/2033/...62f888fd_o.jpg
As you can see in the link, the VM of each app is off the scale. What could possibly cause this? I have secure VM turned off...
Any help would be appreciated.
As you can see in the link, the VM of each app is off the scale. What could possibly cause this? I have secure VM turned off...
Any help would be appreciated.
Comments
Bear in mind that virtual memory allocated does not equal swap space or memory in use, it's just allocated.
It's interesting that iScrobbler bills itself as 'An alternative to the bloat-ware that is the "official" last.fm client.' when it appears to have allocated 2.8GB of VM space for itself. Let's hope it never wants to use it all!
Leopard does indeed seem to allocate more virtual memory than real memory now, which is probably a better scheme than Tiger.
Bear in mind that virtual memory allocated does not equal swap space or memory in use, it's just allocated.
It's interesting that iScrobbler bills itself as 'An alternative to the bloat-ware that is the "official" last.fm client.' when it appears to have allocated 2.8GB of VM space for itself. Let's hope it never wants to use it all!
My thoughts exactly... That's why I thought it was so weird.
Also: Adium uses 80Megs? Damn, I'll stick to MSN messenger then...
"It's not using that much, those VM stats are not particularly meaningful. If you want to see how much space is being used exactly, use the Finder go menu and go to folder /private/var/vm. I removed the virtual memory column from the Activity Monitor because it gives me no useful info at all. Stick with real memory and the real memory is high, it's likely the virtual memory is too but usually it's no more than about 2-3 GB total."--Marvin
http://forums.appleinsider.com/showp...4&postcount=13
Yeah I had installed iScrobbler but removed it after 10 minutes when I noticed it had only 10MB less memory uses than the normal Audioscrobbler... I just don't see the point of using it then, besides it's not like Audioscrobbler is slowing my system down and I "only" have 1 GB of RAM...
Also: Adium uses 80Megs? Damn, I'll stick to MSN messenger then...
On Tiger Adium uses 11mb. like I said, something's wrong.
1) EVERY 32-bit process in OS X has a 4GB address space, 64-bit address spaces are a whopping 16 exobytes. No mater what. That isn't reported anywhere because it is a by definition kind of thing. That is how much VM you have available. No mater what.
2) That screenshot reported VM doesn't really exist, or better put isn't really used. It is just a sum of the size of the addresses available on the currently held memory map pages. Notice those screenshot VM numbers are nowhere near the 4BB->16EB VM that is actually available.
3) The only relationship the reported VM size has to the actual memory in use is that the reported VM will ALWAYS be FAR LARGER than used memory. It is just a list of immediately assignable logical addresses. Meaning whenever your program wants to use more memory, it will be assigned from that set of addresses already held in the memory maps. This is done for efficiency, waiting to make memory map pages until they are actually needed is criminally negligent.
4) Unless you are an app designer or OS programmer, ignore those VM numbers. They mean absolutely less than nothing to a user. App programmers will only care if the numbers are too small for what they want accomplished, too big isn't possible from their perspective. The OS designer will try to balance the VM size to always have assignable addresses available, but not map too many pages which just wastes time creating the extra maps and uses extra disk space for the backing store where those over-allocated maps would end up.
5) The Real Memory line also includes shared regions, meaning it is also a fairly useless number on it's own. Some amount of that memory was already there in RAM before that app even opened up because the OS frameworks are designed that way. Very efficient. An app with a lower real memory reported may actually use more RAM if it uses all it's own libraries, rather than using the shared frameworks that are already resident. Not to mention most application sizes today are the result of the graphical elements, not the code. Second guessing app memory requirements is wasted energy unless you are able to identify memory leaks.
6) Looking at that screenshot you are not running anywhere near the number of apps you need to be running simultaneously. You have too much free memory and free memory is wasted memory. The OS is trying to use it but you don't seem to be leaving enough apps open. I'm completely serious, just leave apps running, unless that app has proven to be a poor citizen and not sleep properly when not in use. A sleeping app in memory awakens several hundred thousand times faster than launching it all over again.
7) The only number on that screenshot which has any real meaning is the zero page-outs. That tells you you have not required VM to actually swap anything to the backing store on the HD. As long as that number, a running total since the last reboot, stays below a few thousand a day you don't need more RAM and haven't put the first bit of stress on the memory manager.
If you're interested in why a process seems to be using a lot of memory, start with these:
vmmap - Prints out a low-level map of a process's entire virtual address space.
heap - Prints out application-level memory allocation statistics.
Apparently nobody here really has a grip on what virtual memory actually is or what the stats mean.
1) EVERY 32-bit process in OS X has a 4GB address space, 64-bit address spaces are a whopping 16 exobytes. No mater what. That isn't reported anywhere because it is a by definition kind of thing. That is how much VM you have available. No mater what.
2) That screenshot reported VM doesn't really exist, or better put isn't really used. It is just a sum of the size of the addresses available on the currently held memory map pages. Notice those screenshot VM numbers are nowhere near the 4BB->16EB VM that is actually available.
3) The only relationship the reported VM size has to the actual memory in use is that the reported VM will ALWAYS be FAR LARGER than used memory. It is just a list of immediately assignable logical addresses. Meaning whenever your program wants to use more memory, it will be assigned from that set of addresses already held in the memory maps. This is done for efficiency, waiting to make memory map pages until they are actually needed is criminally negligent.
4) Unless you are an app designer or OS programmer, ignore those VM numbers. They mean absolutely less than nothing to a user. App programmers will only care if the numbers are too small for what they want accomplished, too big isn't possible from their perspective. The OS designer will try to balance the VM size to always have assignable addresses available, but not map too many pages which just wastes time creating the extra maps and uses extra disk space for the backing store where those over-allocated maps would end up.
5) The Real Memory line also includes shared regions, meaning it is also a fairly useless number on it's own. Some amount of that memory was already there in RAM before that app even opened up because the OS frameworks are designed that way. Very efficient. An app with a lower real memory reported may actually use more RAM if it uses all it's own libraries, rather than using the shared frameworks that are already resident. Not to mention most application sizes today are the result of the graphical elements, not the code. Second guessing app memory requirements is wasted energy unless you are able to identify memory leaks.
6) Looking at that screenshot you are not running anywhere near the number of apps you need to be running simultaneously. You have too much free memory and free memory is wasted memory. The OS is trying to use it but you don't seem to be leaving enough apps open. I'm completely serious, just leave apps running, unless that app has proven to be a poor citizen and not sleep properly when not in use. A sleeping app in memory awakens several hundred thousand times faster than launching it all over again.
7) The only number on that screenshot which has any real meaning is the zero page-outs. That tells you you have not required VM to actually swap anything to the backing store on the HD. As long as that number, a running total since the last reboot, stays below a few thousand a day you don't need more RAM and haven't put the first bit of stress on the memory manager.
Bingo. And apparently very few people have a C background or a UNIX Systems Programming background of classes to know what the hell VM means. Glad I didn't write this one. Very well written.
This falls into the same bin as defragging: poorly understood, often freaked out over, and rarely important to worry about.