What to do when your mac slows to a crawl?

Madhav

Registered
I am stuck, on a PC I would have done a spyware/adware clean, maybe a virus check? Whats the standard procedure for OS X10.4.1?
I read about repairing permissions, what else?
 
Reboot. Everything speeds up again. Happens when you leave it on for weeks. Also, running the cron scripts helps. Get cocktail, and run the pilot every few days. It automatically repairs permissions, cleans caches, runs cron scripts, and rotates log files. If safari is the slow one, clear your history and empty out the icons folder. Its easy if you set it on read-only, because it clears out on every safari restart.

Also, see how much ram you have. If its all being used, get more. Activity moniter lets you see what processes are hogging the CPU. If something unexpected is taking up the cpu, either kill it or ask on this forum. If its mdimport, its spotlight indexing, let it do its thing for a while.
 
are you sure it's slowed down? i found that i imagined it to be slowing down.

but anyway, try stopping programs running in the background:

Sys Preferences>Users/Accounts>your account>Login Items. delete everything you don't want - this is like a nicer version of msconfig
 
Thanks for all the help, will definitely apply it step by step.

Heres a glimpse of take my activity monitor at the moment.

292 Activity Monitor user 6.80 2 10.95 MB 134.19 MB
67 WindowServer windowserver 2.10 2 18.36 MB 147.73 MB
293 pmTool root 1.80 1 1.07 MB 36.44 MB
0 kernel_task root 0.60 45 70.25 MB 788.96 MB
38 configd root 0.10 3 1.79 MB 28.97 MB
137 Dock user 0.00 2 6.63 MB 121.72 MB
42 securityd root 0.00 1 1.57 MB 28.51 MB
50 netinfod root 0.00 1 568.00 KB 26.93 MB
130 pbs user 0.00 2 1.85 MB 54.04 MB
28 dynamic_pager root 0.00 1 172.00 KB 26.61 MB
51 syslogd root 0.00 1 420.00 KB 26.63 MB
138 SystemUIServer user 0.00 2 9.83 MB 124.35 MB
197 automount root 0.00 3 1.05 MB 28.71 MB
44 notifyd root 0.00 2 464.00 KB 27.19 MB
289 coreservicesd root 0.00 3 2.48 MB 30.88 MB
52 cron root 0.00 1 508.00 KB 26.87 MB
190 rpc.lockd root 0.00 1 192.00 KB 26.65 MB
45 DirectoryService root 0.00 3 1.86 MB 29.44 MB
89 loginwindow user 0.00 4 8.75 MB 108.59 MB
53 xinetd root 0.00 1 628.00 KB 26.74 MB
243 lookupd root 0.00 2 1.01 MB 28.07 MB
277 Safari user 0.00 8 32.26 MB 160.22 MB
39 coreaudiod root 0.00 1 3.96 MB 82.77 MB
47 distnoted root 0.00 1 784.00 KB 27.00 MB
48 KernelEventAgent root 0.00 2 748.00 KB 27.57 MB
278 mdimport user 0.00 4 5.88 MB 61.97 MB
49 mDNSResponder root 0.00 2 1.05 MB 27.39 MB
114 mds root 0.00 8 3.61 MB 43.03 MB
57 update root 0.00 1 220.00 KB 26.59 MB
167 ntpd root 0.00 1 372.00 KB 26.84 MB
1 launchd root 0.00 3 424.00 KB 27.66 MB
73 crashreporterd root 0.00 1 220.00 KB 27.10 MB
193 automount root 0.00 3 1.09 MB 29.00 MB
272 mdimport nobody 0.00 4 2.12 MB 38.98 MB
82 ATSServer user 0.00 2 2.77 MB 66.06 MB
102 integod root 0.00 1 1.45 MB 28.03 MB
181 nfsiod root 0.00 5 184.00 KB 28.60 MB
32 kextd root 0.00 2 920.00 KB 27.54 MB
248 Finder user 0.00 3 14.38 MB 132.08 MB
40 diskarbitrationd root 0.00 1 1.05 MB 27.11 MB
41 memberd root 0.00 3 588.00 KB 27.64 MB
123 cupsd root 0.00 2 1.32 MB 27.82 MB
241 pppd root 0.00 1 1.02 MB 27.33 MB
143 Speech Synthesis Server user 0.00 5 9.97 MB 147.44 MB
 
My brother-in-law told me last week when I was over at his firm that his new G5 iMac starts crawling like a snail when Spotlight updates the DB. He added all his hard-drives in the 'Private Space' in the Spotlight PrefPane and all seemed much more fluent and constant in terms of performance.

Maybe you could try that as well in addition to the stuff mentioned above.
 
How much ram do you have?

Are you in Tiger or Panther?

Clean your caches (cocktail is very good, so it onyx), repair permissions, etc.
 
You need to keep at least 10% free on you start up drive, if possible try to keep 15% free. Mac OS X uses virtual memory, which means it will use your hard drive to swap out chunks of from RAM when they aren't being used.

If your hard drive gets too full, you'll start noticing a real slow down, as the free space gets more and more fragmented, leaving less room for your swap files. My personal rule of thumb is to keep at least 10 to 15 GB free on my startup volume at all times.

A nice utility that can show in what shape your hard drive is is ShowVolumeFragmentation.

http://people.freenet.de/amichalak/page1/page1.html
 
Haven't tried this mentioned defrag program...
My ways to speed up the system:

In terminal
Code:
sudo periodic -daily -weekly -monthly
It prompts for your password, and then it will do some of the builtin cleaning scripts and that does essentially guiless what MacJanitor does (a nice freeware app you will like for speeding up and cleaning the system).

Also as mentioned, reboot.. however I am a really lazy person to shut down my Macs, as well for most of them performing some server utilities as well, so typically my uptime reaches at least 3 months before a shutdown.. :D
 
Mac OS X caches every application the first time you run it so that the application will load faster the next time. But all of this is kept in memory and can have a tendency to slow a system down over time.

Many people restart to clear this memory, but actually logging out and logging back in does the same thing.

I log out of my account once every 48-72 hours, and I've had uptimes as high as 231 days.

Of course having my system running 24-7 means that all the cron jobs are done on a regular schedule.

As for defragging your drive... I'll give my standard warning: Defragging a Mac is the single worse thing you can do. There are very few circumstances where it helps and tons more where it can hurt. Defrag Utilities will defrag a volume at the expense of fragmenting files (which is far far worse than any volume fragmentation). What looks pretty to human eyes can be really screwed up from your system's point of view.

But, it is your system and your data.

Best of luck.
 
RacerX said:
As for defragging your drive... I'll give my standard warning: Defragging a Mac is the single worse thing you can do. There are very few circumstances where it helps and tons more where it can hurt. Defrag Utilities will defrag a volume at the expense of fragmenting files (which is far far worse than any volume fragmentation). What looks pretty to human eyes can be really screwed up from your system's point of view.

Ahem. No. Defragging does not lead to fragmentation of files, exactly the opposite is true. It is seldom necessary in OS X though. The following is quoted from this page:
http://www.kernelthread.com/mac/apme/fragmentation/
While Apple does not provide a defragmentation tool, they introduced a few HFS+ optimizations in "Panther", two of which play important roles in countering (even undoing) the fragmentation of files that are below a certain size, and are frequently accessed.

On-the-fly Defragmentation
When a file is opened on an HFS+ volume, the following conditions are tested:

If the file is less than 20 MB in size
If the file is not already busy
If the file is not read-only
If the file has more than eight extents
If the system has been up for at least three minutes
If all of the above conditions are satisfied, the file is relocated -- it is defragmented on-the-fly.

Hot File Clustering
This optimization is currently available only on boot volumes. Hot File Clustering is a multi-staged clustering scheme that records "hot" files (except journal files, and ideally quota files) on a volume, and moves them to the "hot space" on the volume (0.5% of the total filesystem size located at the end of the default metadata zone, which itself is at the start of the volume). The files are also defragmented. The various stages in this scheme are DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION, and ADOPTION. At most 5000 files, and only files less than 10 MB in size are "adopted" under this scheme.
...
...
Defragmentation on HFS+ volumes should not be necessary at all, or worthwhile, in most cases, because the system seems to do a very good job of avoiding/countering fragmentation.

It is risky to defragment anyway: What if there's a power glitch? What if the system crashes? What if the defragmenting tool has a bug? What if you inadvertently reboot? In some cases, you could make the situation worse by defragmenting.
 
what i think RacerX meant was what you confirmed. macos HFS+ defrags itself on the fly - it places everything where it should be. the system does it so you don't have to, and also so it knows where everything is, and it needs to know because it is... it.

get a 3rd party defrag on it and it moves all the files into a neater, tetris like structure, but then macOS doesn't know where the hell it's system went. problems ensue.

Giaguara said:
In terminal
Code:
sudo periodic -daily -weekly -monthly
It prompts for your password, and then it will do some of the builtin cleaning scripts and that does essentially guiless what MacJanitor does (a nice freeware app you will like for speeding up and cleaning the system).

what does this do?
 
Dunno but it didn't work for me :p

Something to do with those maintenance scripts mentioned beforehand?
 
I would like to voice my experience on defragmentation...

Recently decided to do a big clean up. (Now don't get me wrong - my system wasn't that untidy - but after 4 months of heavy use, it was needing a good spring clean...) Having sorted things out (and against better judgement) I decided to use the 'defrag/optimize' tool in SpeedTools after it notified me that my volume was 23% fragmented. Sure... I thought... why not... what harm could it do... - big mistake.

First the drive had trouble booting. Seems like it didn't like the new "fragmented" start-up disk. Soon after when ever there was disk activity in Safari (and other applications) - my hard drive started making the most chilling, god-awful, drilling noise. And it was loud. It really sounded bad. System was working fine (not really that much faster than before I started cleaning it). To me it sounded like the heads in the disk drive were having to jump some distance in order to access files - and was doing so very fast. And this was a brand new ibm SCSI drive too! Rechecked the defrag program - it said fragmentation was almost zero. But from the way the drive was sounding this wasn't the case...

In the end - I had to wipe the drive and do a clean install. I couldn't leave the drive like that because not only was the noise unbearable, but my new (expensive) ibm drive wasn't going to last long if it kept going like that...
 
One of the big problems with 3rd party defragmentation tools is that they need updating as soon as there is a change in the system layout. The system is built on several files, and some of them get replaced on system updates. It is VERY difficult for a third party developer to keep track of that, and to calculate the best placement on you disk for optimal performance.

When you update your system, deprecated files disappear, and new files appear. The defrag tool probably won't recognise the new files as belonging to the system, and might therefore move them to inappropriate places on your drive. They'll still be in the same logical place (i.e the path will be the same), but they will be moved to a new physical place. This degrades performance, and can lead to the condition cited above in tumbleguts example.

Defrag tools need system profile files for each and every system they are supposed to support. SpeedDisk from SpeedTools doesn't support Tiger for this reason, as they don't have a new profile yet.
 
Without rereading the whole thread, whomever mentioned MacJanitor is Godsend. I was ready to put Panther back on my PowerBook, but ran MacJanitor first, and now my machine flies. What a difference.

THANKS!
 
elander said:
Ahem. No. Defragging does not lead to fragmentation of files, exactly the opposite is true.
Ahem... yes it does.

Defrag utilities are known to break up large files to get all the blocks to line up nicely while getting rid of volume fragmentation.

Sorry. :D
 
RacerX said:
Ahem... yes it does.

Defrag utilities are known to break up large files to get all the blocks to line up nicely while getting rid of volume fragmentation.

Sorry. :D
Not really, although it might seem as if they did in some cases (more below this paragraph). Defragmentation tools do two things: defragment all files, and move them so that all free space is contiguous. The very process of moving them to "get all blocks to line up nicely" is precisely what creates defragmented files.

And, to be more to the point here: what we are interested in isn't really "physical defragmentation", as much as "logical defragmentation" or rather "perceived defragmentation". What we really want is maximum transfer rates, the ability to read and write data as fast as the drive will allow.

In the old days, some tools would let you "optimize" file locations, to make reading and writing faster. Maybe some still do. This takes into account the speed of the hard drive, its physical size and the size of allocation blocks. Optimization is performed in such a way as to minimize the amount of lateral movement the head needs to do in order to read files, and to minimize switching between surfaces, to optimize reading time. What happens is simply that files are broken into chunks large enough to fill the read buffer. The chunks are then moved apart a certain distance, just enough to let the head be perfectly positioned to start reading the next chunk as soon as the buffer has been read. Note that this needs to be done differently on different computers, as you also need to take the external transfer rate into account, i.e. how fast the buffer can be read.

This was especially common practice on drives with low sustained transfer rates, say <10 MB/s, and was often called "optimize for video production" or something similar in the settings of the defrag tools.

Although a physical inspection of the platters in the drive would indeed show that the files had become fragmented, they would actually be read faster than if they weren't. In fact, just about every hard drive today does this automatically. The logic needed is built-in to the controller.

So, while "fragmentation" indeed could be introduced on the physical level, it lead to a perceived "defragmentation" on the logical level, and increased transfer rates. A bit like denormalizing a database from fourth normal form to third, second or even first normal form, to increase performance.

This is probably where the notion that "defrag tools actually fragment some files" came from.

As for using these tools, I just don't. When editing media files (sound, video) I simply use a fast, large, external drive that I never fill up and always reformat between jobs. It's faster and more reliable than defragging. Other than that, I simply make it a point to always leave about 20% free on the startup drive, that takes care of most of the risk of (perceived) fragmentation.

You can read more about hard drives and performance issues here:
http://www.storagereview.com/map/lm.cgi/str
 
elander said:
Although a physical inspection of the platters in the drive would indeed show that the files had become fragmented, they would actually be read faster than if they weren't. In fact, just about every hard drive today does this automatically. The logic needed is built-in to the controller.
We are talking about HFS+ volume formatting... which is not your everyday hard drive.

When you introduce physical fragmentation to files, their entries within the volume catalog grow. The HFS+ specification will only allow those entries to grow to a certain point before moving the rest of the physical addresses to an overflow area.

You obviously don't service Macs for a living... that is all I do.

When the catalog becomes corrupt or the entries for the physical addresses stop matching with the actual physical position of the file elements on a disk... lets just say you're in for a REALLY bad day.

I have serviced hundreds of Macs and the only ones which have run into these issues fell under two criteria:
  • Disks that were more than 95% full (I urge all my clients to never exceed 85% capacity)
  • Disks of people who use defragmentation software (regardless of how full the volume was)

It is nice that you do all this reading on all these other sites, but Apple has always had excellent documentation on this stuff (which I believe has been open for public viewing for most of the last 10 years... although part of that time I was part of Apple's development community and I don't know if I had more access than Apple gives the public today).

So why not go to the source?

:rolleyes:

I don't mind going around on this again if you want :D , but nothing is going to change the fact that file fragmentation (physical fragmentation of files on a volume) put stress on the volume resources and in extended cases can lead to data loss.




For those of you wondering about some of the more interesting types of problems that can come from this type of stuff, I had one client who's directory structure... exploded. Most of his files ended up on the root level of his hard drive.

Let the system take care of it's self and make sure it has the room to do this. It is the best recommendation I can make for caring for Mac volumes.
 
RacerX said:
We are talking about HFS+ volume formatting... which is not your everyday hard drive.

Actually, it is. Any everyday drive can be formatted as a HFS+ volume.

When you introduce physical fragmentation to files, their entries within the volume catalog grow. The HFS+ specification will only allow those entries to grow to a certain point before moving the rest of the physical addresses to an overflow area.
Partly true, anything beyond eight extents goes to the extents overflow file. Anyhow, still no explanation as to why defragmentation tools would introduce fragmentation.

You are however completely missing the point. The kind of physical fragmentation I mentioned in my post is no longer necessary as drives now are fast enough. I might not have pointed that out clearly enough in my previous post.

Also, as you should know as an experienced service technician, this type of physical fragmentation is totally invisible to the operating system, since the physical addressing is handled by the controller, not the file system. The file system only sees the logical addresses, not the physical addresses. And the logical addresses will show the file as contiguos.

You obviously don't service Macs for a living... that is all I do.
Pulling ranks? ;)
(I started in the computer business in '76, was a teacher at a local university '81-'87 and a Mac developer/consultant/tech since.:))
When the catalog becomes corrupt or the entries for the physical addresses stop matching with the actual physical position of the file elements on a disk... lets just say you're in for a REALLY bad day.
Yep. That really sucks. Happens a lot when things go wrong with defragmentation tools, one of the reasons I never use them.
I have serviced hundreds of Macs and the only ones which have run into these issues fell under two criteria:
  • Disks that were more than 95% full (I urge all my clients to never exceed 85% capacity)
  • Disks of people who use defragmentation software (regardless of how full the volume was)
Almost in total agreement with my own observations. A good reason to stear clear of defragmentation software. I've seen drives fail for other reasons too, though. Especially Macs in the late eighties and early nineties kept messing up the extents records, when HFS+ came ('97/'98?) a lot of those problems vanished. And don't get me started on DOS/Windows...

It is nice that you do all this reading on all these other sites, but Apple has always had excellent documentation on this stuff (which I believe has been open for public viewing for most of the last 10 years... although part of that time I was part of Apple's development community and I don't know if I had more access than Apple gives the public today).

So why not go to the source?

:rolleyes:

I don't mind going around on this again if you want :D , but nothing is going to change the fact that file fragmentation (physical fragmentation of files on a volume) put stress on the volume resources and in extended cases can lead to data loss.

Yeah, but that wasn't the issue. The issue was wether defragmentation software introduces fragmentation or not. It doesn't, and nothing you've written in this or previous posts provides any explanation as to why they would. Only reiterating that they are bad for you, and in that we agree.

For those of you wondering about some of the more interesting types of problems that can come from this type of stuff, I had one client who's directory structure... exploded. Most of his files ended up on the root level of his hard drive.

Let the system take care of it's self and make sure it has the room to do this. It is the best recommendation I can make for caring for Mac volumes.

Yep, agree on that, but then again, we've agreed on that from the start, and now we are just nitpicking... :D
 
Back
Top