limiting CPU usage

  • Is it possible to limit an apps CPU usage to under a certain
    percentage using cocoa?

    thanks

    AC
  • On 30 Nov 2007, at 13:53, Alexander Cohen wrote:

    > Is it possible to limit an apps CPU usage to under a certain
    > percentage using cocoa?

    Someone may want to correct me, but I'm pretty sure that that goes
    against the way the scheduler works -- if there's spare CPU and
    something can use it, it will give it.

    What you can do, is use nice to lower your priority in the scheduler.

    Tom Davie
  • On 30-Nov-07, at 9:41 AM, Thomas Davie wrote:

    >
    > On 30 Nov 2007, at 13:53, Alexander Cohen wrote:
    >
    >> Is it possible to limit an apps CPU usage to under a certain
    >> percentage using cocoa?
    >
    > Someone may want to correct me, but I'm pretty sure that that goes
    > against the way the scheduler works -- if there's spare CPU and
    > something can use it, it will give it.
    >
    > What you can do, is use nice to lower your priority in the scheduler.

    In that case, maybe you have an idea for me. I have a daemon that runs
    and indexes all the images on a system. For each image, it needs to
    open it up, get some info, close it and store that info. This is very
    CPU consuming and can pretty much bring the system to a halt after a
    while.

    thanks

    AC
  • I think the correct API to use would be the BSD setpriority() call,
    which is similar to nice-ing a process. This would not limit the CPU
    usage your daemon would see to always less than some percentage, but
    would make sure that it's priority is lower than other processes in
    the system.

    I suppose the very hackerish way would be to sleep between images, but
    that seems kinda dumb.

    On Nov 30, 2007 10:36 AM, Alexander Cohen <alexcohen...> wrote:
    >
    > On 30-Nov-07, at 9:41 AM, Thomas Davie wrote:
    >
    >>
    >> On 30 Nov 2007, at 13:53, Alexander Cohen wrote:
    >>
    >>> Is it possible to limit an apps CPU usage to under a certain
    >>> percentage using cocoa?
    >>
    >> Someone may want to correct me, but I'm pretty sure that that goes
    >> against the way the scheduler works -- if there's spare CPU and
    >> something can use it, it will give it.
    >>
    >> What you can do, is use nice to lower your priority in the scheduler.
    >
    > In that case, maybe you have an idea for me. I have a daemon that runs
    > and indexes all the images on a system. For each image, it needs to
    > open it up, get some info, close it and store that info. This is very
    > CPU consuming and can pretty much bring the system to a halt after a
    > while.
    >
    > thanks
    >
    > AC
    >
  • On 30 Nov 2007, at 16:36, Alexander Cohen wrote:

    > In that case, maybe you have an idea for me. I have a daemon that
    > runs and indexes all the images on a system. For each image, it
    > needs to open it up, get some info, close it and store that info.
    > This is very CPU consuming and can pretty much bring the system to a
    > halt after a while.

    Are you sure it's the CPU usage that's the problem here?  The kind of
    thing you're talking about sounds like it should be I/O limited, not
    CPU limited on modern machines.  If it really is CPU limited, you may
    be using the wrong algorithm somewhere; try using Shark to find where
    the machine is spending its time.

    Anyway, NSThread has -setThreadPriority:, which you can use.  If you
    aren't using Cocoa (in which case what are you doing posting this
    question to cocoa-dev?), you can also use various UNIX APIs (nice(),
    getpriority()/setpriority(), pthread_getschedparam()/setschedparam()).

    Whatever you choose, you should be running at a low priority if you're
    CPU-bound (and contrary to popular belief, this will not make your
    code run slower... it just means that if the user wants to do
    something else at the same time, it will work better; if they don't,
    your program will take the same amount of time to run that it would
    have done before).

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Nov 30, 2007, at 8:36 AM, Alexander Cohen wrote:

    > In that case, maybe you have an idea for me. I have a daemon that
    > runs and indexes all the images on a system. For each image, it
    > needs to open it up, get some info, close it and store that info.
    > This is very CPU consuming and can pretty much bring the system to
    > a halt after a while.

    That doesn't seem right. Your daemon shouldn't be able to monopolize
    the CPU. Are you sure that's what's going on?

    I wonder if what is really happening is that you're memory usage is
    getting out of hand and causing virtual memory thrashing.

    _murat
  • On 30-Nov-07, at 3:05 PM, Murat Konar wrote:

    >
    > On Nov 30, 2007, at 8:36 AM, Alexander Cohen wrote:
    >
    >> In that case, maybe you have an idea for me. I have a daemon that
    >> runs and indexes all the images on a system. For each image, it
    >> needs to open it up, get some info, close it and store that info.
    >> This is very CPU consuming and can pretty much bring the system to
    >> a halt after a while.
    >
    > That doesn't seem right. Your daemon shouldn't be able to monopolize
    > the CPU. Are you sure that's what's going on?
    >
    > I wonder if what is really happening is that you're memory usage is
    > getting out of hand and causing virtual memory thrashing.

    What im doing is pretty simple. I have a loop that for each iteration,
    opens an image, gets some info, then closes it down ( using CG of
    course ). Everything is released correctly and there are no leaks. BUt
    after a while, the system gets unresponsive.

    AC
  • On Nov 30, 2007 12:05 PM, Murat Konar <murat...> wrote:
    >
    > On Nov 30, 2007, at 8:36 AM, Alexander Cohen wrote:
    >
    >> In that case, maybe you have an idea for me. I have a daemon that
    >> runs and indexes all the images on a system. For each image, it
    >> needs to open it up, get some info, close it and store that info.
    >> This is very CPU consuming and can pretty much bring the system to
    >> a halt after a while.
    >
    > That doesn't seem right. Your daemon shouldn't be able to monopolize
    > the CPU. Are you sure that's what's going on?
    >
    > I wonder if what is really happening is that you're memory usage is
    > getting out of hand and causing virtual memory thrashing.

    Likely because the image files he is processing are being loading into
    the UBC (universal buffer cache) when they don't really need to be
    (forcing user related items out of the cache).

    man fcntl and look at F_NOCACHE

    Review...

    <http://developer.apple.com/documentation/Performance/Conceptual/FileSystem/
    Articles/FilePerformance.html#//apple_ref/doc/uid/20001987-99732
    >

    -Shawn
  • On Nov 30, 2007, at 12:19 PM, Alexander Cohen wrote:

    > What im doing is pretty simple. I have a loop that for each
    > iteration, opens an image, gets some info, then closes it down
    > ( using CG of course ). Everything is released correctly and there
    > are no leaks. BUt after a while, the system gets unresponsive.

    But *when* are things being released?

    A common problem when running in a loop is that objects that are
    autoreleased (so-called temporary objects) aren't actually
    deallocated until the end of the current run-loop. Often, these
    temporary objects aren't ones you've created; they're created as a
    side effect of code that you're calling.

    You can avoid the build-up of temporary objects by using your own
    auto-release pool thusly (typed in Mail, this is just pseudo code to
    illustrate the concept):

    NSAutoreleasePool * autoreleasePool = [[NSAutoreleasePool alloc]init];

    while (keepLooping)
    {
        do stuff...

        if (number of loops since the last time we released the
    autoreleasePool is above some threshold)
        {
            [autoreleasePool release];
            autoreleasePool = [[NSAutoreleasePool alloc]init];
        }
    }

    [autoreleasePool release];

    How often you release the autorelease pool depends on how memory
    heavy your operations are.

    _murat
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today