Tell me more ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.
up vote 13 down vote favorite
5

I'm at a bit of a loss about this.
I'm running a big import in aperture, and it's causing my system to slow down to a complete crawl, basically rendering it unusable for anything, even browsing the web. Since this seems a bit unnatural, I spent a little time looking around.

Running ps -Al shows that, apparently by default, the Dock, Finder, and SystemUIServer all seem to run at a priority far lower then userland applications. While user applications typically have a priority of 33, the Dock, Finder, etc have a priority of 53.

The end result, is ANY processor intensive task completely clobbers the UI, and renders the system unusable until it finishes.

Anyways, using renice -20 -p <prid> bumps them up to the same priority as the rest of the userland UI, and results in not having to wait 1-3 seconds (!) for the UI to respond to something as simple as a mouse click.

Thad said, I have two questions:
Is there any reason I shouldn't be altering the thread priority of the finder like this?
Is there any way to make the priority change persistent, e.g. so it stays that way after reboot.

share|improve this question
9  
I've typically found that it's the disk i/o, not the cpu load, that causes my system to crawl. Finder and the other applications you mention are probably waiting on reads/writes when they appear to not be responding. I don't really have a solution to this (other than getting a fast disk like an SSD), though, so I'm going to post this as a comment instead of an answer. – Kyle Cronin♦ Nov 16 '10 at 6:32
5  
I would have thought so too. However, changing the thread priority does affect the UI behavior, which makes me think that either the thread priority also affects IO queue handling, or it is indeed CPU limited. – Fake Name Nov 16 '10 at 8:37
1  
As an example, with the dock priority left as stock, it takes 5-10 seconds to react to the mouse being moved over it. With it manually bumped up to the same 33 as everything else, it reacts immediately (though there is a little bit of choppiness). – Fake Name Nov 16 '10 at 8:39
3  
Update: The nice command affects both CPU and IO queue handling: insanelymac.com/forum/lofiversion/index.php/t164156.html – Fake Name Nov 16 '10 at 8:44
2  
The problem is not a memory/disk space limitation. I am running processes that intentionally take all the resources they can. A proper mutitasking scheduler should let the system remain perfectly responsive (or at least only cause a minor performance hit) despite this, provided the prioritization is set right. However, for some insane reason, the most important aspect of the UI is set to the lowest priority possible, and the whole system therefore basically is rendered unusable. – Fake Name Nov 22 '10 at 5:23
show 9 more comments

3 Answers

up vote 1 down vote

I'm not sure anyone short of Apple's own developers would be able to answer this question, Finder's inner secrets are their domain. If you do think there are some noticeable lag problems with the UI you might want to submit a bug report to Apple about it.

Judging from the sound of things (processes intentionally taking up all resources) this is a bit of an edge case for memory management. I've yet to see a system perform at their best without somewhere around 10-20% resources free, as a buffering aid.

Just curious, what are these processes you're running?

share|improve this answer
Python, primarily. Doing some heavy recursive computation. – Fake Name Dec 14 '10 at 1:25
Also, batch image processing – Fake Name Dec 14 '10 at 1:25
That sounds more like a RAM usage problem than a CPU problem. I've had something like git use tons of CPU without lagging the UI, but when something starts eating up all the RAM then the UI takes a major hit. What's your RAM usage like during these processes? – Tim Dec 17 '10 at 0:43
up vote 1 down vote

"I'm running a big import in aperture, and it's causing my system to slow down to a complete crawl"

Then Aperture is (probably) the program you want to renice, not the others. The processes you mentioned are tuned relative to average user applications, so that user applications get higher priority and remain responsive, since they are what users use most of the time.

Your case is the less-common one, where an application is performing a long-term, intensive task and the user wants to do something else at the same time. By default, it's the user's applications that get priority so that these intensive tasks get more resources and complete sooner.

For every user that complains that other applications aren't being responsive enough, there is another user complaining that the active application isn't running fast enough.

If you are running a long, resource intensive task and you know you want it to have lower priority so you can use other processes while the task completes—and you don't mind if the intensive task takes longer—you should lower the priority of the process running the intensive task.

As for your second question, there are several possible solutions for making the renice more automatic. For example, you could create a script applet that runs Aperture at a lower priority and use that to start Aperture. Or you could start Aperture via a shell script stored in a *.command file (however, that will open Terminal and run the command in a terminal window, which may not be what you want). Each of these is a little involved. If you would like examples, I can see about providing them later.

share|improve this answer
Background tasks, by definition, should be at a lower priority then foreground tasks. The most important foreground task in the entire system is the GUI, which is largely the Finder process. I may be able to patch threads on a process-by-process basis by renicein things, but the actual problem is finders priority. – Fake Name Aug 26 '11 at 6:03
For example, in Windows 7, which has one of the most responsive GUIs around, the Window-Manager automatically runs with a priority of "High". Now, this means that misbehavior of this process will cause the system to lag, but it also means that misbehavior elsewhere will not. I have had applications crash to using 100% of every CPU core, and the UI on windows still remains extremely responsive. – Fake Name Aug 26 '11 at 6:07
1  
@Fake Name: The Finder does not handle any aspect of the UI other than its own windows (folders and desktop icons). (It is possible to quit the Finder; it's actually gone, and everything else still works.) SystemUIServer handles the menu bar right-side items and the "bezel" overlays (volume/brightness, etc) only. Window rendering and events are handled entirely by the WindowServer processes. – Kevin Reid Aug 26 '11 at 20:04
@Fake Name, as a point of clarification: renice operates on processes, not threads. – Chris Page Aug 28 '11 at 1:50
up vote 1 down vote

I posed a similar question - long ago, on ServerFault - though not as specifically focused on the Finder (although I DO find the Finder to be intolerably slow, as well). How to permanently “renice” a process on Mac OS X (or iOS, etc)? Not much info was gleaned there - as to a good way to do this… or as to why it is such..

I still think about this often, and there are actually a few ways to muss with the "basics" if you so dare. As previously mentioned, you can do various shell chicanery.. but a good place for such misdeeds are the various /etc/rc* boot routines.. which are already up in there.. setting all sorts of arbitrary (apple-defined) system parameters for you. either edit those, or lookup how to add your own routines to the boot process.

also, if you really want to make your head explode..

sudo sysctl list and it's key to pandora's box, aka /etc/sysctl.conf

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.