Hi Mike :-) Am 09.09.2004 um 02:25 schrieb Mike Laster <mike@marketocracy.com>: I've wanted similar information in the past. In my case, I was debugging what appeared to be a weird memory leak. The number of swapfiles in /var/vm would grow to the hundreds, and eventually the system would run out of drive space and crash. Even after killing off all of our server processes we had a large number of files. It would have been handy to figure out which processes had active blocks in the swapfiles to know which process was the culprit. The problem seemed to have mysteriously went away when we disabled some unused system services in /etc/hostconfig. It would have been useful if there were some sort of "reverse" vmmap tool that would walk a swapfile and report the owner of each page contained in it. Feel free to look at the darwin sources to get a definite answer. Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ darwin-development mailing list | darwin-development@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development Do not post admin requests to the list. They will be ignored. Interesting. I thought I'd read somewhere that Mac OS X would only allocate about 2x the physical memory as swap space. Hundreds of swap files, assuming the 10.2. default settings, would mean hundreds of 80MB files which would amount to at least 16GB of swap space. (Hundreds <=> 2 or more times 100 <=> at least 200.) In Panther hundreds of swap files would probably mean even more space due to their increasing size. This sounds like it was either on a pre Panther system or you modified your dynamic_pager settings. I have modified my system to use a separate partition for swap files (on a second HD) and that partition is 2GB in size. I currently have 960MB of physical RAM installed. So far I have managed to reach the limit only using default settings from Panther. And that was because the next swap file to be allocated would have been at least 512MB in size which didn't quite fit in the remaining free space of slightly under 512MB. (Mac OS X showed a nice warning though, advising me to quit some applications.) After changing my dynamic_pager settings to use constant size 64MB swap files I have never filled my swap volume completly. (Older versions of Safari under 10.2 had some leaks though, which required a restart of Safari every 1-2 weeks. This seems to be fixed in the current version.) I use Alex Harpers excellent MenuMeters to monitor my machines memory usage among other things. BTW: I noticed that swap files are not freed instantly after the memory is freed. I recently had a situation where I had accumulated about 25 64MB swap files and then quit almost all user visible applications (lots of them and some with a heavy memory footprint). For the next couple of minutes I would see disk activity every few minutes after which another swap file was gone. So it looks like there is some sort of timer task, checking every so often if enough memory is free that another swap file can be removed. If so dynamic_pager will get the trigger and a single swap file is emptied and removed. This is repeated until the remaing free space in the swap files falls under the theshold (128MB in my case). For some rough information top is a good tool to use. Look at the RPRVT, RSHRD, RSIZE and VSIZE columns. Also ps could help, especially if you know which process is the culprid. (See <x-man-page://top> and <x-man-page://ps>.) ?! Can't help you there but it sounds like a bug to me. Did you report it in <https://bugreporter.apple.com>? I currently only know about a strange memory issue with lookupd which slowly grows its memory usage over time. But that is much less dramatic than what you describe and mostly it only seems to leak address space (not actual memory). I don't think the swap file contains this information. The table (or tree or whatever structure is used) of mappings is maintained by the vm subsystem and is most probably located in physical RAM at all times. There might be a way to access this information or you could build a modified version of the kernel if not. For the general case I can see no real advantage in knowing this much detail about the current vm state unless you are debugging the vm system itself. Also, since the kernel is free to change things behind your back, any data you could get would be stale the moment you (your user-space process) see it.