Slowdown in launching Terminal...Is it SWAP problems?

[jtrascap]

Hey all,

Is anyone else having a slowdown in launching some of the basic apps in OSX? For an example, if I'm in my admin (everyday) account, I can click on Terminal or CPU Monitor or even TextEdit and watch it bounce, 6..8..10 times (on some apps, even more!)

If I switch accounts to a little-used account (like root, which is enabled) and restart, these apps are up in a bounce or two.

This does happen to different apps at different times, and I guess I worry about something like "Windows creep" slowing my OS X system down.

I have 640MBs of RAM (upgraded since purchase from 128 - you HAVE to get more RAM!) so I wonder if the swap space is slowing it down...

Under Linux, which I knew better than BSD, you partitioned swap to roughly twice that of your RAM. 64MBs RAM, 128MBs assigned swap. I don't see an equivilent of the SuSE or RH table partitioning tools (yeah, like I'd even know how to use them!) so I don't know if SWAP in OS X is dynamic or something...

This is possibly a red herring. SWAP may not be the issue, but I have deleted the .plist preference and history files for Terminal and have found no difference.

Ideas??

[smintz]

After making a dedicated SWAP partition, I noticed terminal now only bounces 1..2 times no matter what. Made a big difference to me.

stu

[aalegado]

Originally posted by jtrascap
Under Linux, which I knew better than BSD, you partitioned swap to roughly twice that of your RAM. 64MBs RAM, 128MBs assigned swap. I don't see an equivilent of the SuSE or RH table partitioning tools (yeah, like I'd even know how to use them!) so I don't know if SWAP in OS X is dynamic or something...


The equivalent you're looking for is "Disk Utility" which is part of the default installation of OS X. It's not a perfect "equivalent" because the Linux partitioning utilities have so many more filesystem choices to offer including that required fstype swap. OS X's VM doesn't work like Linux VM so the swap fstype is unknown and unnecessary in X.

Linux's VM requires a swap partition that is identified as having fstype "swap." This doesn't mean there's an actual filesystem on it and it doesn't even have to be formatted. What it means is that the kernel recognizes what the partition is used for and can read/write raw data to it without worrying about the semantics of a interfacing with a real filesystem. OS X's VM doesn't work this way: It expects to read/write "normal" files in "normal" filesystems which is why it's in /var/vm right along with everything else on the / partition.

It's a hold-over from the OpenStep days but all swapfiles are the same size: 80,000,000 bytes (not 80MB which is 80 x 1024 x 1024 bytes). It's dynamic but not in the obvious sense: When more VM is needed, additional swapfiles are allocated rather than enlarging the existing file. When less is needed, the files are deleted to recover the space. You always have one swapfile, 'swapfile0'.

[jtrascap]

So SWAP is fixed in that it's an 80MB file, but variable in that it will assign more 80MB files as it need to.

So, were I to back-up the volume safely (HAH!) and reformat to 3 partitions (MacOSX, SWAP and one for digital media that I can reformat often...just should anyone ask why 3), then I should have a more maintainable SWAP space? One-two bounces are possible again?

I guess I should start rootin-around here for info on backup and redirecting swp to a seperate partition. Any idea how large it should be? 500MB is probably overkill, but I've a 30GB drive and I don't care to do this again anytime soon...

[yuriwho]

I doubt the swap file is related to your issue.

Try

http://www.versiontracker.com/moreinfo.fcgi?id=10451&db=mac

instead.

Re-locating the swap file is only useful if you have a separate drive to mount it on.

I'll bet that pre-binding is the issue. Try the above linked app to address this issue.

Y

[shreddies]

Can't remember where I read it but the problem lies with your postscript fonts, try disabling them and terminal will load much faster. I'd suggest a search over at macfixit.

[aalegado]

Originally posted by jtrascap
So SWAP is fixed in that it's an 80MB file, but variable in that it will assign more 80MB files as it need to.

So, were I to back-up the volume safely (HAH!) and reformat to 3 partitions (MacOSX, SWAP and one for digital media that I can reformat often...just should anyone ask why 3), then I should have a more maintainable SWAP space? One-two bounces are possible again?

I guess I should start rootin-around here for info on backup and redirecting swp to a seperate partition. Any idea how large it should be? 500MB is probably overkill, but I've a 30GB drive and I don't care to do this again anytime soon...

I don't put much value in having a separate swap partition although many on this site seem to focus on it endlessly. OS X VM is NOT at all like OS 9 VM so the superstitions that surround it should not be applied to OS X's VM.

Such a partition is ONLY meaningful if its on it's own drive because a swap partition that is on the same drive as your boot partition or an active data partition will result in drive contention whenever VM needs to page while you are doing any other kinda of disk read/write to a partition on the same spindle.

Given how few drive bays the towers have, dedicating one small disk to swap (say a 4GB -- that's a pretty good size for a small drive of which you probably end up using 80MB most of the time!) is a waste of expandability. If you used a large drive, say a 40GB, then you know you're going to use the rest of the space for something and then you've got drive contention again.

All you get with this type of partitioning is avoidance of file fragmentation since it's not part of the file churn you would get if you had everything in one big partition. Still, you don't gain much by this for several reasons:

1. Your computer is relatively fast.
2. Your hard drive is relatively fast.
3. The "chunks" of memory that are paged out of RAM and into the swapfiles aren't necessarily large so it's usually not important that the hard drive be able to read/write in large, unbroken swaths. Given how much real RAM you have, you'd have to be pushing something really huge (RAM-wise) to force a large page.
4. The paged-out data wasn't written out in any particular order nor will it be read in a particular order so it's not important where the data is within the swapfile. It's the nature of the VM system to have to hunt all over the swapfiles to read/write the pages.
5. File fragmentation is an overrated issue. Excessive fragmentation is the real problem and that occurs because a partition experiences too much file churn. Separate your data by how often it changes and you avoid the worst part of the fragmentation phenomenon.
6. If you're segregating your swap file for performance reasons then you should be segregating it for real(i.e. dedicated drive). Anything less is a compromise.

Consider this alternative: Make a boot partition for all your software and the OS files (including the swap) and a data partition. Naturally, your boot partition will change but it will do so relatively slowly since the greatest amount of change (i.e. "file churn") is on the data partition.

Something to think about: When you're looking for info about moving the swap partition look for empirical data from those posters as to how much performance they're squeezing out of the work they did. Anecdotal evidence like, "It seems to be faster" or "After I did this, it got faster" is totally subjective. Maybe the "cure" doesn't address the symptoms and the improvement is a coincidence.

There's a big difference between something that actually improves the situation and something that makes the user think the situation is improved.

I think many of the "move the swap files" posters want the cushion of "knowing" the swapfiles are somewhere else. Whether or not they're seeing any real improvement isn't an issue.

If you do decide to go with a separate swap partition, whatever you do, DO NOT USE THE DISK IMAGE SWAP FILE LOCATION. That hint is brain dead because it takes a kernel-level task and hobbles it putting it through a user-land task (the drive image). The VM system is supposed to operate independently of the users so doing anything that makes it dependent on a given users login is asking for trouble.

[robh]

Originally posted by jtrascap
Hey all,

I have 640MBs of RAM (upgraded since purchase from 128 - you HAVE to get more RAM!) so I wonder if the swap space is slowing it down...


Since you have 640mb of RAM, it's highly unlikely you're hitting swap space slowdowns.

I've seen people mention font issues for slowing down terminal launching. Someone brought up that topic in this thread too.

Did you change the terminal font for your admin user, but not root ?

[jtrascap]

Originally posted by yuriwho
I doubt the swap file is related to your issue.
...
I'll bet that pre-binding is the issue. Try the above linked app to address this issue.
Y

Well, I've tried the prebinding thing - I've tried the online Word demo. Maybe fonts there have ruined the speed of the system, as one of the other hints have suggested. I'll try that next...

[jtrascap]

Alex, thanks greatly for a lucid explaination to someone who knows enough to screw-up a system. I think thre are plenty of us out there who know chunks of anectodtal information on Linux or Solaris, and hope to apply this to OS X.

Which means now I need you to respond to a few things: :)

Originally posted by aalegado
I don't put much value in having a separate swap partition although many on this site seem to focus on it endlessly. OS X VM is NOT at all like OS 9 VM so the superstitions that surround it should not be applied to OS X's VM.

Such a partition is ONLY meaningful if its on it's own drive because a swap partition that is on the same drive as your boot partition or an active data partition will result in drive contention whenever VM needs to page while you are doing any other kinda of disk read/write to a partition on the same spindle...


I should have better explained my system as it isn't the usual high-end system we ended up talking about:

1: iBook 600 (November issue)
B: 640 MB RAM
iii: 30GB drive in 2 partitions:
- 9GB boot and apps volume, with all OSX & 9.2 apps, user dirs, etc.
- 19GB project and coldstorage volume (I do dig video and need to reformat the volume often)

So as you can tell, it's not a powerhouse - it's a comfort machine, made for portability and couch-crunching. (I'm waiting for a G5 to replace the Sun 10 I have as the home machine). But is has been getting slower and slower, and occasionally seems to freeze enough that I have to Telnet in to shut it down, do an fsck -y and restart. Bah! I can't wait for Norton.


Consider this alternative: Make a boot partition for all your software and the OS files (including the swap) and a data partition. Naturally, your boot partition will change but it will do so relatively slowly since the greatest amount of change (i.e. "file churn") is on the data partition.
[/B]

And I think file churn has something to do with it since for all intents and purposes (or for that matter, porpoises) all apps, OSX and OS9, all VM (OSX & 9), all user files and all life in general go on in that one volume. The second volume is really for waste and overwriting large files, where I need to grab gigs from the camera contiguously.

So I guess you'd suggest not making a third partition for swap but rather one for the User experience or perhaps OS 9, where either experience can be backed up and restored seperate from the general system, where VMs won't collide, where we (borrowing from TWW) "let OSX be OSX".

Sound like a plan?


If you do decide to go with a separate swap partition, whatever you do, DO NOT USE THE DISK IMAGE SWAP FILE LOCATION. That hint is brain dead because it takes a kernel-level task and hobbles it putting it through a user-land task (the drive image). The VM system is supposed to operate independently of the users so doing anything that makes it dependent on a given users login is asking for trouble.

And I throughly agree with this, so it really bears repeating...