Time Machine is a Resource Hog
in [Mac Applications]
|
From: nospam on 9 Mar 2010 04:52 In article <slrnhpc3k4.gpu.g.kreme(a)cerebus.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > First, find a file that exists on your computer. Any file. Say it is > named 'Xyzzy.txt' and it is somehwere on your machine, but you have no > idea where it is. > > this command in the terminal will search your entire computer for this > file (the bit at the end is to redirect the errors, and the 'time' is to > time the time it takes to execut the command.) > > $ time find / -type f -name "Xyzzy.txt" 2>/dev/null that's probably the worst possible way to find a file somewhere on a hard drive. > Now, this is going to take a while, so I am going to go fix dinner, eat > it, and wash the dishes. Then I'm going to go watch all the Prime Time > Television shows on two different networks. Then I'll come by and check > if the fin has finished. If it hasn't (probable) then I will go to bed > and see if it's finished by morning. > > Ok, I finally gave up. It's ran for nearly 8 hours and never did find > the file. SPotlight finds the file in under 5 seconds. Do you really > want that simple search that actually worked from 20 years ago? yes, i do. the utility find any file scans the directory (not the entire drive) and it just found a random file in about 1 second and took about 4-5 seconds to finish searching over 1 million files on my hard drive. i should mention that's on a laptop drive and i'm watching a video when the search was going on. cpu load is actually fairly high, independent of the search. so yes, in fact i do want how it was just 5 years ago, before apple axed the old method of searching. it was *fast* and it worked reliably, which is a lot more than i can say for spotlight. > Keep in mind this is not some ancient lowly piece of iron either, this > is a decently fast quad-core Xeon Mac Pro. I do have a lot of storage > space, but then again, so do a lot of people. At least the disks are > fast SATA II drives. it doesn't matter what the hardware is if you pick a shitty search algorithm.
From: nospam on 9 Mar 2010 05:51 In article <slrnhpc98n.2b82.g.kreme(a)cerebus.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > You said you wanted a search like you had 20 years ago. `find` is that > search. no it isn't. i had a much better one than find.
From: isw on 9 Mar 2010 12:44 In article <slrnhpbucg.1j9t.g.kreme(a)cerebus.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > In message <1jf1wda.ycki74bau6roN%nospam(a)see.signature> > Richard <nospam(a)see.signature> wrote: > > Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > > >> In message <1jf17w7.1v1q9551p0p1cqN%nospam(a)see.signature> > >> Richard <nospam(a)see.signature> wrote: > >> > Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > >> > >> >> And how do you propose to throttle the file copying when it's a backup > >> >> as opposed to any other time? > >> > >> > It is common enough with other kinds of backup software. My mozy remote > >> > backup has an option to throttle the bandwidth it uses. > >> > >> Bandwidth != writing to disk > > > Sure it does. The term bandwidth is not restricted to networks. I'm > > guessing that must be what you are thinking because I can't imagine any > > other reason why one might say that that disk I/O does not have a > > bandwidth. *ANYTHING* that involves data transfer has a bandwidth; that > > includes disk writes. For that matter, since TM commonly runs over a > > network connection, limitting its network bandwidth directly limits its > > disk writes. > > TM doesn't commonly run over network connections though. For most users > it is writing to an attached hard drive. I doubt very much the people > complaining about time machine throttling their machiens are backing up > over the network because those backups on my LAN are completely > transparent, even from my ancient iBook G4, it will happily, albeit > slowly, backup tens of GB of data and not impact the processor *at all*. > > And really, when people talk about 'limiting bandwidth' they are not > talking about Disk IO, they are talking about networks. This is because > there is no good way to limit the bandwidth of Disk IO without crippling > the entire system. All it would take is the backup app running a timer and sending metered quantities of data to the disk only when it ticked. Disk IO (not burst, but average, which is what bogs the system) could be throttled as desired simply by tweaking the timer. Isaac
From: Kevin McMurtrie on 11 Mar 2010 12:49 In article <slrnhpc3k4.gpu.g.kreme(a)cerebus.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > In message <080320101135372551%nospam(a)nospam.invalid> > nospam <nospam(a)nospam.invalid> wrote: > > > what does slow a machine down is spotlight, even after the initial > > index. unfortunately, turning it off causes a lot of problems. it's > > unfortunate that there is no fallback to a simple search that actually > > worked, like what had been in place for nearly 20 years. > > Ah yes, the good old days of 20MB hard drives containing a couple of > thousand files. > > Disks contain a lot more information than they did. If you would like to > see what a non-indexed search is light, you can find out very easily > yourself from the command-line. > > First, find a file that exists on your computer. Any file. Say it is > named 'Xyzzy.txt' and it is somehwere on your machine, but you have no > idea where it is. > > this command in the terminal will search your entire computer for this > file (the bit at the end is to redirect the errors, and the 'time' is to > time the time it takes to execut the command.) > > $ time find / -type f -name "Xyzzy.txt" 2>/dev/null > > Now, this is going to take a while, so I am going to go fix dinner, eat > it, and wash the dishes. Then I'm going to go watch all the Prime Time > Television shows on two different networks. Then I'll come by and check > if the fin has finished. If it hasn't (probable) then I will go to bed > and see if it's finished by morning. > > Ok, I finally gave up. It's ran for nearly 8 hours and never did find > the file. SPotlight finds the file in under 5 seconds. Do you really > want that simple search that actually worked from 20 years ago? > > real 471m55.788s > user 5m0.192s > sys 129m17.441s > > > Keep in mind this is not some ancient lowly piece of iron either, this > is a decently fast quad-core Xeon Mac Pro. I do have a lot of storage > space, but then again, so do a lot of people. At least the disks are > fast SATA II drives. Are you sure your search didn't wander into automount directories or a Bonjour listing? A brute-force search on my 2.66GHz quad core Xenon Mac Pro covers 500000 filenames per minute. That search on my Mac Mini Server covers 260000 filenames per minute (a Drobo FW800 is dragging that speed way down). -- I won't see Google Groups replies because I must filter them as spam
From: Jamie Kahn Genet on 11 Mar 2010 14:58
isw <isw(a)witzend.com> wrote: > When I'm doing something like photo editing that takes a lot of > processing, and Time Machine kicks in, things get more than a little > sluggish on my 1.8GHz Core Duo MacBook. > > Is there some way to tell Time Machine to play better with others? I > really don't care how long it takes to do a backup, but I want it to be > a *background* task, not the one the Mac spends most of its time on. > > Isaac Sadly no, TM is a hog and as a result I use TimeMachineEditor <http://timesoftware.free.fr/timemachineeditor/> to set them to every six hours instead. I had hoped it would be improved in 10.6, but I still hear people saying TM is a PITA when it runs. -- If you're not part of the solution, you're part of the precipitate. |