[Drakino]

Ok, not sure what is happening, but I've got 8.5 gigs of virtual memory allocated. Activity monitor shows kernel_task with 650 megs of it, and firefox taking 413. Every process in the system, even every konfabulator process is allocating way more virtual memory then it needs, taking up now more then 10% of my hard drive space.

Anyone seen this happen with 10.3.4?

[Busemann]

Originally posted by Drakino:
Ok, not sure what is happening, but I've got 8.5 gigs of virtual memory allocated. Activity monitor shows kernel_task with 650 megs of it, and firefox taking 413. Every process in the system, even every konfabulator process is allocating way more virtual memory then it needs, taking up now more then 10% of my hard drive space.

Anyone seen this happen with 10.3.4?

7GB here!

This is believed to be the cause of the system freezes many report having (including moi)

[Fonzie]

yeah, I have alot of vmem allocated too. And it's striking that Konfabulator uses ~100mb vmem per widget. What's that all about? I only have a Clock, itunes remote, Weather and ftp widget. all about 100mb real memory and >400mb vmem. And they are just being idle.

[wataru]

That's all normal. You can't necessarily get an accurate picture of memory usage from those numbers because they include shared libraries.

Do a search. You'll find plenty of threads about this topic, with better explanantions than I can give you.

[someone_else]

A processes VM really means next to nothing. There could be sparse holes in a processes VM map that actually have no backing, plus any shared libs are included in that #. The only # that means anything useful on an application level is RPRVT (private memory). That is the only stat that can even come close to telling you how much memory is being used by an app.

As for the lockups, VM has nothing to do with those. Most likely it is the known lookupd bugs in Panther: 1) There is a known memory leak (a pretty big one too) 2) lookupd can still go south (even though this was supposed to have been fixed in 10.2) .. if it does, then the whole system will become "locked" because a whole bunch of syscalls rely on lookupd (such as finding the logged in user and their home dir) -- this is proably the cause of all lockup problems, including the recent spat of iTunes lockups

Again system VM above 8GB is normal, in fact I've had VM above 15GB and there are no problems. It all depends on how many apps you have running and what their memory usage patterns are like (which no one can predict).

HTH.

[Graymalkin]

Here's a diagram to help explain what was mentioned.

[msuper69]

8.12 gb of VM here. Whoop-de-do.

Unless you're having a problem, don't get all bent out of shape about the size of VM. OS X's memory managment system is tried and true and it's very doubtful (although not impossible) that a serious bug exists that's going to cause your system to die. It's much more likely that a haxie or a poorly written app with a memory leak will munge things up. Or removing files from System or Library.

[Drakino]

Ok, how do I then tell how much disk space is actually used by virtual memory? I got warnings yesterday twice about low disk space, and sure enough I was at 0k each time. The first time I has 600 mb free before the warning, the second time I had another 500 freed up.

Found it
du -ha /var/vm
results in a nice readable display. I've rebooted since the disk space issue, will see how it gets again near 7 days of uptime.

[someone_else]

Originally posted by Drakino:
Ok, how do I then tell how much disk space is actually used by virtual memory? I got warnings yesterday twice about low disk space, and sure enough I was at 0k each time. The first time I has 600 mb free before the warning, the second time I had another 500 freed up.

Found it
du -ha /var/vm
results in a nice readable display. I've rebooted since the disk space issue, will see how it gets again near 7 days of uptime.

MenuMeters <http://www.ragingmenace.com/software/menumeters/>, is also an excellent free, open-source utility that will show you how much disk backing store is in use. It sits in your Menu Bar, and shows all types of memory stats (page in/out, etc). In addition, it has optional cpu, disk and network modules. No need to use Terminal and it's always a click away.

HTH

[wataru]

Originally posted by Drakino:
Ok, how do I then tell how much disk space is actually used by virtual memory? I got warnings yesterday twice about low disk space, and sure enough I was at 0k each time. The first time I has 600 mb free before the warning, the second time I had another 500 freed up.

Found it
du -ha /var/vm
results in a nice readable display. I've rebooted since the disk space issue, will see how it gets again near 7 days of uptime.

You should never run OS X with less than 1GB of free disk space.

[Truepop]

My swap file once reported to the finder 14.5TB but I only have 160GB between two hard drives. I don't worry about it.

[Drakino]

Originally posted by wataru:
You should never run OS X with less than 1GB of free disk space.

The problem is, I did have a gig free before swap seemed to run away.

Right now at almost 2 days uptime of doing the exact same tasks, swap is now at 1 gig. At the end of day 1, it was only 512mb. It created a new 512 mb swap file sometime today for some reason. And even with all apps closed for a few hours, it didn't clean up.

I don't trust finder 100% on file sizes, but I do trust commands at the Unix level.

64M /var/vm/swapfile0
64M /var/vm/swapfile1
128M /var/vm/swapfile2
256M /var/vm/swapfile3
512M /var/vm/swapfile4
1.0G /var/vm

lets see how long I can keep this thing up before things go badly. I have 5.9 gigs free. Thus far, I haven't broken 8 days of uptime, and I think this is finally the reason why.

[Drakino]

64M /var/vm/swapfile0
64M /var/vm/swapfile1
128M /var/vm/swapfile2
256M /var/vm/swapfile3
512M /var/vm/swapfile4
1.0G /var/vm/swapfile5
2.0G /var/vm
up 17 days, 13:18


Weee....

I wonder if the servers have such a problem.