Nicing and Submitting Background/CPU Intensive Jobs

Only one background job per user per machine!

Nicing Jobs

All background / CPU intensive jobs submitted on the ENET managed computers generally must be niced by at least 4 (this policy is necessary to ensure that all our users make efficient use of limited resources). Nicing a job reduces its priority level and preferrentially allocates the CPU to interactive processes. Please note that in the absence of any other interactive or un-niced jobs maximum CPU is allocated to the niced job.

If "a.out" is your executable then the following command may be used to nice the process:

nice +9 a.out

where the nice value (9 in the example) may be any number between 4 to 19. Higher the value of n, the lower the priority for the job. Note that on Enet machines, a job must be niced by at least a level of 4 before it is considered 'niced'.

Note that, somewhat confusingly, the system '/usr/bin/nice' command uses a somewhat different syntax. So for more information on 'nice' you should 'man csh' or 'man tcsh' instead of 'man nice'.

That is why in the following exampes we will use renice (which is very similar on all platforms). Repeating the previous example:

renice 9 $$
a.out

The renice command sets the nice value of your current process (and all process that you start from it) to 9 ($$ is an environment variable in both sh and csh that is the Current Process ID).
Note renice commands are NOT cumulative (the value is added onto the system default nice value). So this has EXACTLY the same effect as the above example:

renice 9 $$
renice 9 $$
a.out

Also note that, especially when starting out, it is important that you double-check that your job is indeed 'nice'd.

On all our Unix/Linux platforms, the 'psu' command (a perl script we wrote) will tell you the 'nice' value of your program, check the "NI" column - a value of 20 is normal on Solaris and Irix (0 is normal on Linux), a larger value means the program has been niced (e.g. 24 or higer on Solaris/Irix, 4 or higher on Linux).

If you are submitting a background job, it is often easiest to nice it and nohup it at the same time:

renice 9 $$
nohup a.out &

Note that all un-niced background jobs may be killed.

Renicing Background Jobs

Additionally,, if you already have jobs running (either in the foreground or in the background, you can 'renice' them with

renice 9 pid

where "pid" is the process id of the process (PID not PPID) obtained from the "psu" command.

You can also renice ALL your processes on a machine with

renice 9 -u $USER

Submitting Background Jobs

If "a.out" is your executable then the following command may be used to nice and put the job in the background.

renice 9 $$
a.out &

If you need to supply an input file to your executable do the following:

renice 9 $$
a.out < INPUTFILE &

If you also have output being written to the screen you need to use the following:

renice 9 $$
a.out < INPUTFILE >& outputfile &

Submitting Background Matlab Jobs

File I/O intensive processes

When running programs that require the manipulation of large files (good examples are ANSYS and matlab) , it is best to run the jobs from /scratch/$user (see below for more info) instead of your home directory. /scratch/$user is located on the local drive, so that when the program is loading the files it does not have to move the data over the network.

The result is that your calculation will run faster (since large amounts of data are not being passed over the network), the machine will be less burdened by the job, and the network response will be much better. Everyone benefits.

Note that when your job is finished, you must move the results and any other files to your home directory, since /scratch/$user is only meant for temporary data storage (although we will tend to leave them alone for at least 10 days). Files left in /usr/tmp are subject to deletion at any time.

On Most machines, you can put your temporary stuff in "/scratch/$user" (you should make a personal folder under "/scratch" with your username as in "/scratch/paulfm" for your use - DO NOT put files directly in "/scratch"). This directory is not automatically emptied on reboot (Please remove your stuff when you are done). Enet may remove any file under "/scratch" that is over 10 days old to make space for other users, so make sure you don't leave anything there that can't be re-created Note that scratch is LOCAL to the machine and you will be able to access files there at a much higher speed than files in your home directory (plus the space is only limited by the space available on scratch - not by quotas) - so this is a good place to have background jobs write and read data (to speed them up).