On 27/01/2007, at 4:09 PM, Andy Dent wrote:
Check in /var/vm as to the number of swapfiles being created. If
you have very little free space then maybe the OS is having trouble
creating them as RB requires.
Just to provide more details, as I have read in my exploration of VM
on OS/X that the OS refuses to allocate fragmented swapfiles, that is
not actually the case and I just proved it.
For some reason, RB, deemed my plugins needed recompiling so I left
the Mac going for the several hours it took to do so for PEF, Mach-O
and Windows. I have MBS and Einhugur suites installed.
On my 1.25GB RAM PPC, my /var/vm folder went up to 8 swapfiles, a
total of 2.5GB allocated, increasing mostly in a few minutes from the
128MB allocated prior to RB starting the plugin prep.
andeo-mac:/var/vm andydent$ ls -al
total 5242880
drwxr-xr-x 11 root wheel 374 Jan 27 17:20 .
drwxr-xr-x 24 root wheel 816 Jan 25 19:24 ..
drwx--x--x 14 root wheel 476 Jan 25 17:22 app_profile
-rw------T 1 root wheel 67108864 Jan 25 17:21 swapfile0
-rw------T 1 root wheel 67108864 Jan 26 12:13 swapfile1
-rw------T 1 root wheel 134217728 Jan 27 16:12 swapfile2
-rw------T 1 root wheel 268435456 Jan 27 16:12 swapfile3
-rw------T 1 root wheel 536870912 Jan 27 16:13 swapfile4
-rw------T 1 root wheel 536870912 Jan 27 16:15 swapfile5
-rw------T 1 root wheel 536870912 Jan 27 16:33 swapfile6
-rw------T 1 root wheel 536870912 Jan 27 17:10 swapfile7
Using hfsdebug (*1), I found that the last four of these swapfiles
were in two extents, rather than being contiguous. Previously, when I
was very low on disk space and the free space was extremely
fragmented, I had seen iDefrag report a massive number of extents for
the swapfiles and my machine became utterly bogged down.
Something which is quite fascinating and also contrary to common web
reports - the last three of these swapfiles later vanished after I
had quit RB. Everything I've read says that OS/X won't reclaim
swapfiles until you reboot. In this case it appears the only thing
with a claim on those files was RB and so OS/X did in fact remove
them when they weren't needed.
During the plugin preparation time, and the relatively small amount
of time building the app, I continued trying to use the computer for
some mild browsing activity. I was running the Activity Monitor at
the time on another window and could see that the machine was flat
out doing IO and with a massive amount of paging activity but
certainly not CPU-bound.
I know from VMS experience (*2) that page thrashing can cause a
normal user-priority process to bring a multi-tasking OS to its knees
and it appears that OS/X is certainly not immune. This behaviour was
like the worst I've experienced with Visual Studio compiling whilst
trying to use Windows (I have no RB200x comparison possible on
Windows as haven't bothered buying a Windows license for it).
These results actually give me some hope that RS can do something to
improve the problem - apart from the possibility that there is a
significant memory leak whilst compiling there is also the hope they
can improve the locality of references made by the compiler (written
in c++ so they have more control over such niceties).
http://en.wikipedia.org/wiki/Locality_of_reference
-----
(*1)
hfsdebug comes from http://www.osxbook.com/software/hfsdebug/
It allows you to quickly check the fragmentation of a single file,
rather than using something like iDefrag which scans the entire disk.
(it also does many other reports).
eg:
andeo-mac:/var/vm andydent$ sudo hfsdebug swapfile4
<Catalog B-Tree node = 116 (sector 0xaf50)>
path = MacintoshHD:/private/var/vm/swapfile4
# Catalog File Record
type = file
file ID = 5153585
flags = 0000000000000010
. File has a thread record in the catalog.
reserved1 = 0
createDate = Sat Jan 27 16:13:20 2007
contentModDate = Sat Jan 27 16:13:21 2007
attributeModDate = Sat Jan 27 16:13:21 2007
accessDate = Sat Jan 27 16:13:20 2007
backupDate = Fri Jan 1 00:00:00 1904
# BSD Info
ownerID = 0 (root)
groupID = 0 (wheel)
adminFlags = 00000000
ownerFlags = 00000000
fileMode = -rw------t
linkCount = 0
textEncoding = 0
attrBlocks = 0
# Finder Info
fdType = 0
fdCreator = 0
fdFlags = 0000000000000000
fdLocation = (v = 0, h = 0)
opaque = 0
# Data Fork
logicalSize = 536870912 bytes
totalBlocks = 131072
fork temperature = no HFC record in B-Tree
clumpSize = 0
extents = startBlock blockCount % of file
0x262e24 0x18662 76.25 %
0x463c2e 0x799e 23.75 %
131072 allocation blocks in 2 extents total.
65536.00 allocation blocks per extent on an
average.
# Resource Fork
logicalSize = 0 bytes
----
(*2)
When I was a VMS sysadmin, about 20 years ago, we had a scientific
programmer write some COBOL code. She didn't realise that FORTRAN
accesses its arrays in the opposite order to COBOL and so her
manipulation in arrays of about 4MB of data caused massive amounts of
thrashing of pages as her code was having to page in memory every few
instructions due to extremely poor locality of reference.
It brought an 80-user machine to its knees for about 2 hours as the
code tried to do a series of filters and sorts in-memory. Nothing I
could do with permissions or job priority control would stop this - I
had to rewrite the program. The replacement as a pipeline using a
series of simple filter programs and use of the Sort utility program,
all on sequential files on disk, ran in a few seconds.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
