Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Increasing CPU Usage/Decreasing Run Time

by hakkr (Chaplain)
on Jul 26, 2005 at 07:42 UTC ( #478082=note: print w/replies, xml ) Need Help??


in reply to Increasing CPU Usage/Decreasing Run Time

On linux/Unix you should be able to 'nice' the process to affect the scheduling priority of the process(how much cpu time).

You usually have to be root to nice upwards and increase priority. So try 'nice -19 script.pl' the max value for nice is -20 so that should give your script priority over whatever is hogging cpu. You can nice processes via 'top' interface as well. update as pointed out below nice rather annoyingly uses -20 as the highest priority
  • Comment on Re: Increasing CPU Usage/Decreasing Run Time

Replies are listed 'Best First'.
Re^2: Increasing CPU Usage/Decreasing Run Time
by anonymized user 468275 (Curate) on Jul 26, 2005 at 08:13 UTC
    Firstly, the numbers for nice work the other way round, i.e. 20 means run at the lowest priority. Secondly, this can do no good -- programs don't slow down to be awkward so that a nice priority can persuade them to hurry up or something -- there is always some other reason for it.

    In this case the process is spending too much time waiting for database interactions to complete and change of priority cannot change that behaviour. But if it hadn't been that it would have been some other I/O activity.

    Finally, on unix, 20 or more is equivalent to 19, which is the maximum-valued i.e. lowest priority.

    One world, one people

      I know programs don't slow down to be awkward but they do slow down if another process with a higher priority is hogging the cpu.
        In a way, but perhaps its more accurate to think of priority as a last resort scheduling mechanism. A computer system has one or more processors each of which has only one program counter (the register that holds the address of the next instruction to be executed). Execution (=occupation of the program counter) will continue for a time slice, at which point another process is allowed in. But these days processes are likely to be waiting on I/O far more often than they are occupying memory, in which case they let other processes have their turn at a slice and are unlikely to block another process even for one turn. So in practice, it is extremely unlikely that a process will hog the CPU, unless either it is erroneously looping, which should not in any case be solved by adjusting priorities, or unless the system is truly saturated with many demanding processes, in which case only a system administrator can affect things with a negative (realtime) priority and of course he shouldn't do so, because slowing a host of processes for the sake of just one is unlikely to be desirable.

        Thus, what I am saying is that from a development/support perspective, process priority should also be about the last place to look for the problem.

        One world, one people

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://478082]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2023-02-05 19:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer not to run the latest version of Perl because:







    Results (32 votes). Check out past polls.

    Notices?